-
Data: 2014-05-11 23:39:40
Temat: Re: monitor do pracy po ciemku
Od: Marek <p...@s...com> szukaj wiadomości tego autora
[ pokaż wszystkie nagłówki ]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
Następne wpisy z tego wątku
- 12.05.14 19:02 Krzysztof Halasa
- 12.05.14 20:19 Marek
- 12.05.14 23:04 Krzysztof Halasa
- 12.05.14 23:50 Marek
- 13.05.14 10:10 Sylwester Zarębski
- 13.05.14 11:40 Marek
- 13.05.14 12:14 Jakub Witkowski
- 13.05.14 13:29 XX YY
- 13.05.14 19:08 Sylwester Zarębski
- 13.05.14 19:40 Krzysztof Halasa
- 13.05.14 21:40 Krzysztof Halasa
- 13.05.14 22:21 Marek
- 13.05.14 22:40 Marek
- 14.05.14 00:06 Marek
- 14.05.14 00:44 Marek
Najnowsze wątki z tej grupy
- Nikon D5500 i wyzwalanie migawki
- Canon 550D
- EOS 600D i balans bieli w filmach
- EOS 90D i sentymenty
- Skanowanie: Canon MG2550S vs HP OfficeJet 6950
- czas exif a czas modyfikacji pliku
- karta SD po formacie odzyskiwanie zdjęć i filmów
- Chess
- Vitruvian Man - parts 7-11a
- Eltec nie zyje?
- Steve McCurry
- Light - lajkowe klasyki od Chinczykow
- Forum o Sony serii A (alfa)?
- obrobka RAW na konputerze
- Sklejanie bracketowanych JPGów
Najnowsze wątki
- 2024-11-17 7. Raport Totaliztyczny: Sprawa Qt Group wer. 424
- 2024-11-18 Gdynia => Spedytor Międzynarodowy <=
- 2024-11-18 Białystok => Full Stack web developer (obszar .Net Core, Angular6+) <
- 2024-11-18 Białystok => Programista Full Stack (.Net Core) <=
- 2024-11-18 Kraków => Business Development Manager - Dział Sieci i Bezpieczeńst
- 2024-11-18 Kraków => Business Development Manager - Network and Network Security
- 2024-11-18 Kraków => Network Systems Administrator (IT Expert) <=
- 2024-11-18 Kraków => Administrator Systemów Sieciowych (Ekspert IT) <=
- 2024-11-18 Zdunowo => Senior PHP Symfony Developer <=
- 2024-11-18 Łódź => QA Inżynier <=
- 2024-11-18 Lublin => Senior PHP Developer <=
- 2024-11-18 Gliwice => Specjalista ds. public relations <=
- 2024-11-18 Gdynia => Front-End Developer (React/Three.js) <=
- 2024-11-18 Gdańsk => Specjalista ds. Sprzedaży <=
- 2024-11-18 Gdańsk => Kierownik Działu Spedycji Międzynarodowej <=