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