XX YY <f...@g...com> writes:

> podam inny moze bardziej zrozumialy przyklad zeby wyjasnic o co chodzi
>
> kapela ngrywa kawalek w studio.
> rezyser nagrania zaklada sluchawki przenoszace pasmo od 1000 hz do 10000 hz

No nie, słuchawki z pasmem od 1 kHz? Może proszę o jakiś bardziej
realny przykład.

> ktos inny odsluchuje to samo nagranie przez sluchawki o pasmie 20-20000 hz.
> uslyszy za glosno bardzo niskie dzwieki 16-1000 HZ , ktorych rezyser
> nie slyszal, gdyz sluchawki nie mogly ich odtworzyc.
> rezyser chcac uslyszes owe harmoniczne przy okazji wielokrotnie musial
> przekrecic dzwiek podstawowy .

Tak w ogóle to nie ma czegoś takiego jak dźwięki, których słuchawki nie
mogą odtworzyć (pojęcie "dźwięki" zakłada, że mieszczą się w widmie
słyszalnym, w przeciwnym przypadku są to "infradźwięki"
i "ultradźwięki"). Może być tak, że dźwięk jest odtwarzany silniej lub
słabiej (a nawet bardzo baaaardzo słabo) - ale odtwarzany jest zawsze.
Normalnie pasmo podawane jest dla spadku o 3 dB.

> te przekrecony basy beda slyszalne na innym urzadzeniu - dopiero
> trzebaby zastosowac jakies urzadzenie , ktore rozpozna ze nagranie
> jest robione dla innych sluchawek i odpowiednio skoryguje odbior.

Takim urządzeniem jest equalizer i on po prostu koryguje właściwości
wzmacniaczy i słuchawek itp. Po stronie nośnika są/były układy robiące
preemfazę/deemfazę. Ale to nie ma wielkiego związku z aRGB/sRGB,
z powodu, który opisałem.

> szerokogamutowiec , gdyby pokazal barwy dokladnie identycznie jak
> zwykly monitor nie mialby najmniejszego sensu , gdyz wowczas moznaby
> ogladac kolor na zwyklym monitorze.

Owszem. Dlatego taki monitor pokazuje kolor taki sam jak na zwykłym
monitorze wtedy, gdy ten kolor "mieści się" w możliwościach zwykłego
monitora. W przeciwnym przypadku to ten sRGB "oszukuje" (BTW aRGB też
"oszukuje", tylko mniej).
--
Krzysztof Hałasa

do góry

Am Sonntag, 11. Mai 2014 21:00:39 UTC+2 schrieb Krzysztof Halasa:
> XX YY <f...@g...com> writes:
>
>
>
> > podam inny moze bardziej zrozumialy przyklad zeby wyjasnic o co chodzi
>
> >
>
> > kapela ngrywa kawalek w studio.
>
> > rezyser nagrania zaklada sluchawki przenoszace pasmo od 1000 hz do 10000 hz
>
>
>
> No nie, słuchawki z pasmem od 1 kHz? Może proszę o jakiś bardziej
>
> realny przykład.
>
>
>
> > ktos inny odsluchuje to samo nagranie przez sluchawki o pasmie 20-20000 hz.
>
> > uslyszy za glosno bardzo niskie dzwieki 16-1000 HZ , ktorych rezyser
>
> > nie slyszal, gdyz sluchawki nie mogly ich odtworzyc.
>
> > rezyser chcac uslyszes owe harmoniczne przy okazji wielokrotnie musial
>
> > przekrecic dzwiek podstawowy .
>
>
>
> Tak w ogóle to nie ma czegoś takiego jak dźwięki, których słuchawki nie
>
> mogą odtworzyć (pojęcie "dźwięki" zakłada, że mieszczą się w widmie
>
> słyszalnym, w przeciwnym przypadku są to "infradźwięki"
>
> i "ultradźwięki"). Może być tak, że dźwięk jest odtwarzany silniej lub
>
> słabiej (a nawet bardzo baaaardzo słabo) - ale odtwarzany jest zawsze.
>
> Normalnie pasmo podawane jest dla spadku o 3 dB.
>
>
>
> > te przekrecony basy beda slyszalne na innym urzadzeniu - dopiero
>
> > trzebaby zastosowac jakies urzadzenie , ktore rozpozna ze nagranie
>
> > jest robione dla innych sluchawek i odpowiednio skoryguje odbior.
>
>
>
> Takim urządzeniem jest equalizer i on po prostu koryguje właściwości
>
> wzmacniaczy i słuchawek itp. Po stronie nośnika są/były układy robiące
>
> preemfazę/deemfazę. Ale to nie ma wielkiego związku z aRGB/sRGB,
>
> z powodu, który opisałem.
>
>
>
> > szerokogamutowiec , gdyby pokazal barwy dokladnie identycznie jak
>
> > zwykly monitor nie mialby najmniejszego sensu , gdyz wowczas moznaby
>
> > ogladac kolor na zwyklym monitorze.
>
>
>
> Owszem. Dlatego taki monitor pokazuje kolor taki sam jak na zwykłym
>
> monitorze wtedy, gdy ten kolor "mieści się" w możliwościach zwykłego
>
> monitora. W przeciwnym przypadku to ten sRGB "oszukuje" (BTW aRGB też
>
> "oszukuje", tylko mniej).
>
> --
>
> Krzysztof Hałasa

jesli liczba 1000 jest problemem to zamien ja sobie na np 600 albo 200 albo 100 albo
80.

chodzi o to, ze obrabnaiajac obraz na monitoszr sRGB obraz moze zawierac pewne kolory
ktorych nie zobaczysz na monitorze srgb a zobaczysz na monitorze WG .
i to nie jest mozliwosc teoretyczna - tak jest .
zebym nie musial pisac wiele bezproduktywnych postow znalazlem pierwszy lepszy link ,
w ktorym osoba postronna pisze to samo - zobacz do wnioskow.

transpozycja kolorow pomiedzy roznymi przestrzeniami barwymi , a w szczegolnosci
pomiedzy monitorami o roznych wlasnosciach fizykalnych nie jest wcale taka
jednoznaczna.

poczytajcie o przestrzeniach barwnych - w sieci powinno byc cos na ten temat.

moze byc tak, ze zobaczysz na monitorze WG obraz identycznie jak na monitorze sRGB
jesli akurat obraz ten posiada dokladnie te kolory , ktore mieszcza sie w przestrzeni
barwnej , moze byc tak ze na WG zobaczysz kolory , ktorych na monitorze sRGB nie da
sie zobaczyc.

jest to czesty przypadek jesli obrabiasz zdjecia w aRGB na monitorze sRGB.

Panowie ,
mam monitor WB , mama kalibrator i b czesto , dla wiekszosci dla wiekszosc zdjec z
sieci rozpoznaje , ze kolor niebieski jest obciazony seledynem.

rozumiem ze na forum nic sie ciekawego nie dzieje , wiec mozna na ten temat
dyskutowac do woli - why not ?

jeszcze raz odsylam do artykulu wskazanego pod linkiem.
o ile prawidlowo kojarze , pisal go fachowiec w sposob przystepny.

do góry

Marek <p...@s...com> writes:

>> Mylisz się. LUT w monitorach nie operuje na floatach, i nie używa
>> żadnych zaokrągleń. Po prostu masz tablicę np. [256] -> [1024], albo
>> [256] -> [256] itp. Wartością np. koloru wejściowego adresujesz tablicę,
>> wynik wysyłasz np. do matrycy. To są wszystko wartości całkowite.
>
> Obaj się mylimy.

Mogę się z Tobą zgodzić, ale tylko w połowie :-)

> Proces jest dużo bardziej złożony.

Oczywiście. Przecież monitor robi jeszcze wiele innych rzeczy,
np. korektę temperatury barwowej, która wymaga obliczeń na wszystkich
kolorach jednocześnie. Ale zasada jest dokładnie taka, jak napisałem -
LUTy są tablicami liczb całkowitych.

> Już wiem dlaczego
> LUT jest 8 lub 16 bitowy. Nie ma to nic wspólnego z bitowością matrycy
> monitoira.

Przeciwnie, przynajmniej na tyle, na ile mówimy o obrazkach reklamowych
tamtego monitora, liczba bitów wyjściowych LUT = liczba bitów matrycy.

> LUT może być też wstępnie przekalkulowany i
> zapisany jako statyczna pamięć (i pewnie tak jest w monitorach)

Tylko niektóre LUTy mogą takie być. LUTy związane z kalibracją -
oczywiście nie.
Nie wiem jak dokładnie jest to zrobione w konkretnym monitorze
(możliwości są różne). Ideologicznie najprościej byłoby zrobić
pojedynczą tablicę np. [2^30] -> 3 * [1024] (jedną dla całego monitora
i wszystkich kolorów, w wersji wejściowo 8-bitowej [2^24] -> 3 * [1024])
- taka tablica niestety zajęłaby sporo miejsca - np. 4 GB - i samo
policzenie jej chwilę by trwało (a trzeba to robić po każdej zmianie
parametrów, i liczenie może używać floatów). Dlatego robi się to w kilku
mniejszych etapach - jest kilka razy wolniej, ale zespół LUTów jest
znacznie mniejszy i znacznie szybciej się go liczy.

> lub
> można też przypisywać procedury w różnych językach do przetwarzania na
> żywo obrazu.

Nie wiem co masz na myśli, ale z pewnością nie można w czasie
rzeczywistym przeliczać kolorów tymi procedurami.

> W monitorach, statyczna pamięć też nie jest też prostym
> konwerterem wartości na wartość.

Przeciwnie, jest właśnie czymś takim.

> De facto od strony hardwarowej to
> jest multiplekser programowalny, który wewnętrznie na bieżąco
> przelicza wartości w oparciu o statyczne dane i zewnętrzny sygnał.

Ten opis może odpowiadać rzeczywistości.
Kiedyś LUTy robiło się po prostu na kawałku pamięci, np. ROM, EPROM lub
RAM (jeśli potrzebne były zmiany). Do wejść adresowych doprowadzało się
sygnał wejściowy, zaś wynik dostawało się natychmiast z wyjść danych.
Konwersja trwała np. 100 ns (należy zauważyć, że nie było to podpięte do
przestrzeni adresowej żadnego procesora, pomijając ew. modyfikacje).
Oczywiście do obecnych zastosowań video to jest za wolne. Teraz takie
rzeczy można zrobić np. na układzie CPLD, albo w jakimś większym
projekcie np. na FPGA lub innym ASICu.

W pewnym sensie można napisać, że pamięć jest multiplekserem - na
podstawie wejść adresowych przecież multipleksuje dane ze swojego
wnętrza.

Wbrew pozorom, nie ma w tym nic skomplikowanego.
--
Krzysztof Hałasa

do góry

W dniu 2014-05-11 20:23, XX YY pisze:

> jezeli na szerokogamutowcu obraz ma wygladac tak samo jak na dowolnym
> innym monitorze czyli no srgb za 600 zl to po co go kupowac?

Po to aby zdjęcia sRGB wyglądały jak sRGB a zdjęcia aRGB jak aRGB. Na
monitorze sRGB uzyskasz tylko to pierwsze a przy drugim będzie masakra.

Tymczasem widzę, ze traktujesz przebarwienia jakie widzisz jako zaletę
posiadania aRGB.

> przeczytaj jeszcze raz artykul pod wskazanym linkiem. dzisiaj i tak
> jestesmy w lepszej sytuacji , gdyz aktualne browsery potrafia
> interpretowac obraz aRGB , przed paru laty to bylo zrodlem
> dodatkowego bledu.

Nie do końca. IE nie radzi sobie w wielu sytuacjach. Nie badałem w
jakich. FF bez większego problemu o ile w obrazach PNG webmaster zadba o
ustawianie flagi S.

> nawet jesli sie bedziesz upieral, ze tak nie ma prawa byc , to tak
> jest. mam pare monitorow i wlasnie w obrzarze koloru niebieskiego
> szerokogamutowiec najbardziej odbiega od pozostalych ogladajc obrazy
> z sieci.

Przyczyny tego błędnego zachowania to albo brak osadzonego profilu w
obrazkach (temu mozna zaradzić dając default = sRGB) albo brak
przypisanego profilu do monitora. A to podstawy kalibracji.

> w sumie - wszystko jedno. przy nastepnym monitorze
> niekoniecznie musze miec szerokogamutowca.Roznice do klasycznych nie
> sa jakies powalajace. Inne cechy sa mi wazniejsze .

Nie, to nie tak. Ty po prostu ich nie dostrzegasz bo tak masz środowisko
ustawione. Różnice są spore. Gdybyś zadbal o właściwą konfigurację to z
pewnością nigdy by Ci do głowy nie przyszło powrócenie do sRGB. Coś Ci
ucieka w niebieskie lub zielone, to porażka. Obraz ma być zawsze
PRAWDZIWY niezaleznie czy jest to bitmapa sRGB czy aRGB. Powiem Ci, że
osobiscie głównie dostrzegam różnicę w czerwieniach jeśli o zdjęcia
chodzi. Niby tam jest najmniejsza różnica ale dla mnie jest ona kluczowa
a już w szczególności na wydrukach. Tego za diabła przeskoczyć nie
potrafiłem ale udało się w końcu. Dobór odpowiedniego sprzętu plus
zrozumienie zasad profilowania. Nigdzie nie są one opisane więc nie
dziwię Ci się, że błądzisz. Eksperymentalnie musiałem dochodzić do wniosków.

--
Pozdrawiam
Marek

do góry

Nie baw się w takie porównania z dźwiękiem bo do żadnej rozsądnej
analogii nie dojdziesz. Musiałbyś w jakieś abstrakcyjne kompresje
częstotliwości wejść aby zobrazować działanie profilowania ICC.

Generalnie XX YY widzi zafarby bo coś sknocił z profilowaniem. Zapewne w
ogóle go nie ustawił w systemie operacyjnym. Dlatego gdy ogląda
wąskogamutowe obrazki na szerokogamutowym monitorze, to tak musi się
wtedy dziać bez profilowania. Np. zielone z sRGB wtedy staje się
mega-zielonym na aRGB i stąd przebarwienia. Dobrze ustawiony ICC
powinien to wyeliminować.

--
Pozdrawiam
Marek

do góry

W dniu 2014-05-11 21:27, Krzysztof Halasa pisze:
>>
>> Obaj się mylimy.
>
> Mogę się z Tobą zgodzić, ale tylko w połowie :-)

Lubisz się licytować :-D

> Przeciwnie, przynajmniej na tyle, na ile mówimy o obrazkach reklamowych
> tamtego monitora, liczba bitów wyjściowych LUT = liczba bitów matrycy.

Tak, ale LUT 16 bitowy może mieć np. 10 bitów wyjściowych. LUT 16 bitowy
to de facto definicja struktur jakie przechowuje, która nie ma nic
wspólnego z bitowością sygnału wejściowego i wyjściowego. A już w
szczególności nie ma to nic wspólnego z 16 bitami :-) Równie dobrze może
mieć 8 bitów wejściowych i 10 wyjściowych. Podobnie jak LUT 8bitowy. To
tylko umowna nazwa.

> Nie wiem jak dokładnie jest to zrobione w konkretnym monitorze
> (możliwości są różne). Ideologicznie najprościej byłoby zrobić
> pojedynczą tablicę np. [2^30] -> 3 * [1024] (jedną dla całego monitora
> i wszystkich kolorów, w wersji wejściowo 8-bitowej [2^24] -> 3 * [1024])
> - taka tablica niestety zajęłaby sporo miejsca - np. 4 GB - i samo
> policzenie jej chwilę by trwało (a trzeba to robić po każdej zmianie
> parametrów, i liczenie może używać floatów). Dlatego robi się to w kilku
> mniejszych etapach - jest kilka razy wolniej, ale zespół LUTów jest
> znacznie mniejszy i znacznie szybciej się go liczy.

Ja tylko przytoczyłem informacje zasięgnięte organizacji tworzącej ICC
wraz z powiązanymi technologiami. Oni twierdzą, że to nie takie proste
jak zakładamy.

>
>> lub
>> można też przypisywać procedury w różnych językach do przetwarzania na
>> żywo obrazu.
>
> Nie wiem co masz na myśli, ale z pewnością nie można w czasie
> rzeczywistym przeliczać kolorów tymi procedurami.

No coś Ty. Już w Atari wykorzystywałem przerwania synchronizacji
poziomej do tego aby procedury assemblerowe ustawiały inaczej rejestry
koloru w celu zwiększenia ilości dostępnych kolorów w obrazie. A wtedy
nie istniały żadne specjalizowane GPU. Wszystko procesor robił i nie
obciążało go to nadmiernie. GPU spokojnie poradzi sobie w dzisiejszych
czasach z takimi bajerami.



--
Pozdrawiam
Marek

do góry

Marek <p...@s...com> writes:

> Tak, ale LUT 16 bitowy może mieć np. 10 bitów wyjściowych.

Przyznaję, że określenie "LUT 16-bitowy" nie jest jednoznaczne, bo LUTy
mają określoną liczbę bitów na wejściu (typowo, może to być także zakres
o liczbie elementów nie będącej potęgą dwójki) oraz na wyjściu. Ale
żeby nazwać LUT 16-bitowym, te 16-bitów musi być na wejściu lub na
wyjściu, nie ma rady.

Chyba że to jest 16-bitów marketingowych, to wtedy oczywiście wszystko
jest możliwe. Tak w ogóle, 16-bitowe (i szersze) elementy zapewne są tam
wykorzystywane, ale nie o tym mówił obrazek.

> Ja tylko przytoczyłem informacje zasięgnięte organizacji tworzącej ICC
> wraz z powiązanymi technologiami. Oni twierdzą, że to nie takie proste
> jak zakładamy.

Problem w tym, że ja akurat _wiem_ jakie to jest. Tzn. nie znam
konkretnej implementacji konkretnego monitora, ale wiem jak to działa,
i sam używałem takich konstrukcji (nie w monitorze, ale połączenie tej
dość elementarnej zresztą wiedzy z wiedzą o przekształceniach systemów
kolorów wystarczy by to ocenić).

> No coś Ty. Już w Atari wykorzystywałem przerwania synchronizacji
> poziomej do tego aby procedury assemblerowe ustawiały inaczej rejestry
> koloru w celu zwiększenia ilości dostępnych kolorów w obrazie. A wtedy
> nie istniały żadne specjalizowane GPU. Wszystko procesor robił i nie
> obciążało go to nadmiernie. GPU spokojnie poradzi sobie w dzisiejszych
> czasach z takimi bajerami.

Ale w monitorze nie ma GPU. No i Atari nie robił tego jednak po każdym
pikselu.
Oczywiście, takie LUTy, albo np. inne patenty do mnożenia macierzy,
znajdują się w kartach graficznych. Nie jest to robione programowo,
byłoby za wolne, a nawet gdyby nie, to pobierałoby zbyt dużo prądu.
Koszt zrobienia takich rzeczy na elementach (względnie) dyskretnych
(np. SRAM, CPLD) to są może jakieś pojedyncze złotówki i będzie to
pobierać pewnie poniżej wata czy jakoś tak (dla producenta monitorów
będzie to jeszcze tańsze, i zapewne będzie to element skalera).
--
Krzysztof Hałasa

do góry

W dniu 2014-05-12 19:02, Krzysztof Halasa pisze:
>
> Przyznaję, że określenie "LUT 16-bitowy" nie jest jednoznaczne, bo LUTy
> mają określoną liczbę bitów na wejściu (typowo, może to być także zakres
> o liczbie elementów nie będącej potęgą dwójki) oraz na wyjściu. Ale
> żeby nazwać LUT 16-bitowym, te 16-bitów musi być na wejściu lub na
> wyjściu, nie ma rady.

hahahaha to nie tak :)
LUTy występują 2 w przyrodzie.

Znalazłem dokumentację oficjalną odnośnie LUT:
http://www.color.org/specification/ICC1v43_2010-12.p
df

Właśnie dowiedziałem się, że poza typami 8 i 16 (nie mylić z bitami 8 i
16), o których pisałem i które to nie mają nic wspólnego z ilością
przetwarzanych kolorów (i tym samym pinów w układzie scalonym) są
jeszcze 2. Czyli w sumie 4:

lut16Type
lut8Type
lutAtoBtype
lutBtoAtype


>> No coś Ty. Już w Atari wykorzystywałem przerwania synchronizacji
>> poziomej do tego aby procedury assemblerowe ustawiały inaczej rejestry
>> koloru w celu zwiększenia ilości dostępnych kolorów w obrazie. A wtedy
>> nie istniały żadne specjalizowane GPU. Wszystko procesor robił i nie
>> obciążało go to nadmiernie. GPU spokojnie poradzi sobie w dzisiejszych
>> czasach z takimi bajerami.
>
> Ale w monitorze nie ma GPU.

LUT jest urządzeniem ogólnym. Monitor to szczególne jego zastosowanie.

> No i Atari nie robił tego jednak po każdym
> pikselu.

Przerwania H i V. Paleta wystarczała na pokrycie 1 linii
niepowtarzalnymi kolorami. Więc za pomocą przerwań podmieniałem paletę
na wymaganą w kolejnej linii.

> Oczywiście, takie LUTy, albo np. inne patenty do mnożenia macierzy,
> znajdują się w kartach graficznych. Nie jest to robione programowo,
> byłoby za wolne, a nawet gdyby nie, to pobierałoby zbyt dużo prądu.

Zgadza się.



--
Pozdrawiam
Marek

do góry

Marek <p...@s...com> writes:

> hahahaha to nie tak :)
> LUTy występują 2 w przyrodzie.
>
> Znalazłem dokumentację oficjalną odnośnie LUT:
> http://www.color.org/specification/ICC1v43_2010-12.p
fd
>
> Właśnie dowiedziałem się, że poza typami 8 i 16 (nie mylić z bitami 8
> i 16), o których pisałem i które to nie mają nic wspólnego z ilością
> przetwarzanych kolorów (i tym samym pinów w układzie scalonym) są
> jeszcze 2. Czyli w sumie 4:
>
> lut16Type
> lut8Type
> lutAtoBtype
> lutBtoAtype

LUT to jest pojęcie definiowane nie przez "www.color.org", LUT = look-up
table, i ludzie tego używali w czasach, gdy kolorem świecenia monitorów
komputerowych był głównie zielony. Zapewniam Cię, że jest dużo więcej
rodzajów takich tablic, dużo więcej niż 2, niż 4, i niż 24.

LUT może być także np. w formie papierowej :-)

Natomiast wygląda na to, że rzeczywiście znalazłeś formalne opisy jak to
jest liczone w standardowych monitorach (np. obrazki od strony X). W te
obrazki to ja mogę uwierzyć, pisałem że to musi działać mniej-więcej
w taki sposób. Natomiast tamten obrazek, w którym bity wejściowe (nie
pamiętam już czy było ich 8 czy 10) wchodzą w "16-bitowy" LUT i wychodzą
do 10-bitowej (efektywnie) matrycy, to wybacz, nie przedstawia niczego
sensownego. Podobnie, nie ma tu żadnych dodatkowych bitów, które miałyby
służyć do określenia kierunku zaokrąglenia - takie operacje przeprowadza
się tylko na liczbach całkowitych (bo jak zaadresować tablicę
ułamkiem?).

Te "typy" LUTów to nie są żadne prawdziwe typy czegokolwiek, tylko tagi
w systemie definiowania, jak się okazuje, ustandaryzowanych profili. To
może nie mieć nic wspólnego z prawdziwym sprzętem dokonującym obliczeń,
to jest tylko formalna postać przekształceń matematycznych.

>> No i Atari nie robił tego jednak po każdym
>> pikselu.
>
> Przerwania H i V. Paleta wystarczała na pokrycie 1 linii
> niepowtarzalnymi kolorami. Więc za pomocą przerwań podmieniałem paletę
> na wymaganą w kolejnej linii.

Owszem, ale tu nie ma żadnej palety (i nie może być), obliczenia
(lookupy) są przeprowadzane oddzielnie dla każdego piksela. Może być
wprowadzone pewne opóźnienie, ale przepustowość musi być wystarczająca.

BTW w tamtych czasach różne cuda się robiło, nie wiem czy ktoś by teraz
uwierzył, że np. debugger (prosty) mieścił się w ok. 2 KB. Ale true
colory i setki milionów pikseli/sekundę to nieco inna bajka jednak.
--
Krzysztof Hałasa

do góry

W dniu 2014-05-12 23:04, Krzysztof Halasa pisze:
>
> Natomiast wygląda na to, że rzeczywiście znalazłeś formalne opisy jak to
> jest liczone w standardowych monitorach (np. obrazki od strony X). W te
> obrazki to ja mogę uwierzyć, pisałem że to musi działać mniej-więcej
> w taki sposób.

No ok.

> Natomiast tamten obrazek, w którym bity wejściowe (nie
> pamiętam już czy było ich 8 czy 10) wchodzą w "16-bitowy" LUT i wychodzą
> do 10-bitowej (efektywnie) matrycy, to wybacz, nie przedstawia niczego
> sensownego. Podobnie, nie ma tu żadnych dodatkowych bitów, które miałyby
> służyć do określenia kierunku zaokrąglenia - takie operacje przeprowadza
> się tylko na liczbach całkowitych (bo jak zaadresować tablicę
> ułamkiem?).

Jeśli grzebiesz w sprzęcie to pewnie wiesz lepiej jak wygląda taka
pamięć. W katalogu znajdziesz odpowiedź czy jest to zwykła pamięć, czy
bardziej zaawansowany układ.

A co do konwersji, to opisałem Ci jak to się dzieje. Kolor wejściowy i
wyjściowy zawsze są bitami (całkowite liczby). Wewnątrz następuje
przeksztłcenie do praktycznie nieograniczonej przestrzeni barw i
wyrażonej wartościami całkowitymi w dodatku (jak w RGB). Poczytaj sobie
o tych 3 stosowanych. Nawet domyślam się dlaczego zastosowano takie
właśnie. W Photoshopie nawet zwykła desaturacja może dać tragiczny efekt
jeśli robisz to w trybie RGB. Natomiast gdy przełączysz się w tryb
którejś z w/w przestrzeni, tam zrobisz desaturację i potem wrócisz do
RGB to efekt będzie zupełnie inny. Dlatego w Photoshopie masz oddzielną
funkcję desaturacji mimo iż pozornie duplikuje ona inne filtry. Kiedyś
prowadziłem wątek w tej sprawie na forum bodajże DTP. Tam mnie
uświadomiono w czym rzecz.

Przeliczeń trzeba dokonywać z wykorzystaniem szerokich

> Te "typy" LUTów to nie są żadne prawdziwe typy czegokolwiek, tylko tagi
> w systemie definiowania, jak się okazuje, ustandaryzowanych profili.

Być może. Zapewne w monitorach są wstępnie przeliczone multipleksery na
bazie tych zawiłych operacji. Tego nie zgadniemy.

> Owszem, ale tu nie ma żadnej palety (i nie może być), obliczenia
> (lookupy) są przeprowadzane oddzielnie dla każdego piksela. Może być
> wprowadzone pewne opóźnienie, ale przepustowość musi być wystarczająca.

Zgadza się. Jednakże w praktyce już dość dawno temu widziałem na uczelni
jak koledzy pracowali nad przetwarzaniem wizji w czasie rzeczywistym.
Analiza była na poziomie pikseli właśnie. Sprzęt się wyrabiał. Pewnie
istnieją jakieś specjalizowane procesory sygnałowe.

> BTW w tamtych czasach różne cuda się robiło, nie wiem czy ktoś by teraz
> uwierzył, że np. debugger (prosty) mieścił się w ok. 2 KB.

Ba! Napisałem kiedyś w assemblerze procedurę do analizy FFT w podobnej
objętości.

> Ale true
> colory i setki milionów pikseli/sekundę to nieco inna bajka jednak.
>

To się jednak jakoś robi w elektronice biomedycznej czy przy zdjęciach
satelitarnych zbieranych z kilku urządzeń, składanych do kupy (pewnie to
złożone analizy) i wysyłanych live na Ziemię.

--
Pozdrawiam
Marek

do góry