W dniu 2014-05-15 11:13, XX YY pisze:

> nic nie trace. wszyszto jest przemyslane. nie mam problemu
> zamieszczenia zdjecia w tiffie 16 b w argb lub dowolnej innej
> przestrzeni barwnej dostepnej na poziomie obrobki .

Hmmm. Nie bardzo sobie wyobrażam sens regulacji kolorów w jakiejś
aplikacji stosując monitor monochromatyczny. Podobnie nie wyobrażam
sobie sensu pracy w aRGB gdy monitor mamy sRGB lub pracy w sRGB używając
nie przystosowany (czyli nie oprofilowany) monitor aRGB, a ten ostatni
wariant uprawiasz. Kolory są wtedy z d... wzięte. Jak w takich warunkach
pracować?

16b to inne zagadnienie nie mające nic wspólnego z powyższym.Na zwykłych
monitorach tego nie zobaczysz. 16b używa się wyłącznie przy edycji
obrazu gdyż wtedy np. zjawisko posteryzacji przy przekształceniach jest
zmniejszone. Do tego istnieją inne reprezentacje koloru takie jak
ProPhoto czy L*a*b pracujące wyłącznie w większej ilości bitów więc
wyboru nie masz. Niektóre operacje graficzne (np. powszechną
desaturację) da się osiągnąć prawidłowo tylko w tych przestrzeniach.
Produkt końcowy powinien być zapisany w standardowych 8b.

> tyle , ze nikt nie bedzie mial cierpliwosci cos takiego ladowac i
> ogladac.
> transfer danych jest zbyt wolny mimo, ze stosuje najszybsze
> dostepne aktualnie ogolnie techologie ulatwiajace szybki zaladunek
> zdjecia , procesory zbyt wolne , by plynnie zobaczyc zdjecie w 100 %
> wielkosci , monitory i tak maja 8 bitow.

Już ten ostatni argument przekreśla sens umieszczania w sieci 16 bitów.
Znów nadinterpretowujesz moje słowa. 16 bitów ma sens WYŁĄCZNIE przy
przetwarzaniu obrazu. Nie myl tego z aRGB czy sRGB. To inne zagadnienia.

> dlatego robie w jpeg do sieci - i problem jest rozwiazany.

I tak masz robić dalej. Ani ja ani nikt z kolegów nie zachęcał Cię do
zwiększania wielkości plików! Tracisz czas na udowadnianie, że jest to
pozbawione sensu skoro wszyscy o tym wiemy. Jeszcze raz moja opinia w
punktach:

- przetwarzamy zdjęcia w możliwie dużych przestrzeniach barw i dynamikach
- w internecie publikujemy 8b sRGB bo niektóre przeglądarki z aRGB sobie
nie radzą od lat


> na swoj wlasny uzytek wystarcza mi monitor sprzed 10 lat za 200
> zlotych. zdjecia widze w glowie.
>
> ludzie ktorzy kupili monitory za 7000 euro naturalnie, ze sa
> przekonani, ze widza lepiej kolory , dzieki temu zakup ich mniej
> boli.

Dlatego pisałem: monitor dla Ciebie to tani monitor sRGB.

> byloby fajnie gdybys pokazal jakies wlasne zdjecie , ktore dzieki
> monitorowi uzyskalo nieporownywalna kolorystyke.

Pokazałem przecież ten kwiat bordowy, nie widziałeś linków? Pokazałem
też, które kolory na tym konkretnym zdjęciu byłyby zmienione w sRGB.
Praktycznie każde zdjęcie zyskuje kolorystykę. Rzadko zdarza się, ze
kolorystyka mieści się w 100% w sRGB.

--
Pozdrawiam
Marek

do góry

Trochę OT:

On Thu, 15 May 2014, Marek wrote:

> http://www.sim2.com/HDR/hdrdisplay/hdr47e_s_4k

Hm... w cywilizowanych warunkach podaje się całkowity strumień
w lumenach, tak po prostu, ew. w lumenach na metr kwadratowy powierzchni
świecącej, zamiast epatować kandelami.
Zakładać tę 1/600 000 m^2 i szacować z pierwszego przybliżenia? :>
Czy ktoś od ręki zapoda (zakładając jaką taką równomierność świecenia
w kąt przestrzenny) ile to lumenów wyjdzie z tych 4000cd/m^2?

> Choć i tu mam zastrzeżenia bo raczej tu chodzi o dynamikę (którą zwykle
> w pracy biurowej tłumimy) a nie gamut.

Chodzi, bo choć byle monitor zostawia papier sporo w tyle, to do
odwzorowania naturalnych warunków ciągle daleko.
I tak właśnie - to na monitorze da się oglądać co bardziej kontrastowe
zdjęcia, nie na papierze.
A do TEGO celu, owszem, brakuje powrotu do starych LCD z 1000 lumenów
na metr kwadratowy :>
Co ciekawsze, za każdym razem napotykałem na opór mocno przekonanych,
że monitor MUSI dawać obraz "białej kartki". Tak jakby aparatem
nigdy nie robiło się zdjęć z źródłami swiatła w kadrze.

pzdr, Gotfryd

do góry

W dniu 2014-05-17 00:05, Gotfryd Smolik news pisze:

> Hm... w cywilizowanych warunkach podaje się całkowity strumień
> w lumenach, tak po prostu, ew. w lumenach na metr kwadratowy powierzchni
> świecącej, zamiast epatować kandelami.

Tak czy owak z pewnością będzie relatywnie sporo lepiej z dynamiką niż w
tradycyjnych rozwiązaniach.

>> Choć i tu mam zastrzeżenia bo raczej tu chodzi o dynamikę (którą zwykle
>> w pracy biurowej tłumimy) a nie gamut.
>
> Chodzi, bo choć byle monitor zostawia papier sporo w tyle, to do
> odwzorowania naturalnych warunków ciągle daleko.

Właśnie się zastanawiam czy ten kierunek jest właściwy. Albo inaczej,
może jest właściwy ale potrzebny jest pewien kompromis trudny do
zrealizowania. O tym dalej.

> Co ciekawsze, za każdym razem napotykałem na opór mocno przekonanych,
> że monitor MUSI dawać obraz "białej kartki". Tak jakby aparatem
> nigdy nie robiło się zdjęć z źródłami swiatła w kadrze.

I tu ciąg dalszy. Poniekąd rozumiem Microsoft (bo chyba to oni
wyskoczyli z pomysłem białej kartki). Oni nie widzą świata spoza ram
Worda i wydruków. Ja z kolei oscyluję głównie amatorsko między
zastosowaniem sprzętu komputerowego przy druku zdjęć jak i technik HDR -
nie tylko w sensie fotografii. Doświadczam na styku tych 2 światów
pewnych sprzeczności. Mianowicie gdy zależy mi na wydrukowaniu z
maksymalną jakością materiału zdjęciowego, to spłaszczam dynamikę zdjęć
do tego co monitor potrafi. Drukarką mniej się martwię bo tam niby jest
wymagane jeszcze większe spłaszczenie dynamiki i to różne dla różnych
kolorów ale wymyślono odwzorowanie percepcyjne albo relatywistyczne (czy
jakoś tak to się nazywa), które całkiem dobrze sobie radzi w
zdecydowanej większości przypadków. Tylko czasem trzeba ręczne korekty
nanosić. Mało tego, jasność monitora tłumię do 80cd/m2 (z 400cd/m2
możliwych do uzyskania) dla białego koloru (0xFFFFFF) bo oślepłbym. W
tym zastosowaniu koncepcja białej kartki byłaby słuszna i jednocześnie
wykluczająca pracę z HDR.

No i tu zaczyna się druki aspekt: obrazy o wyższej dynamice, nawet nie z
pełnym HDR. Chciałoby się mieć możliwość zobaczenia sceny taką jaka w
rzeczywistości była robiąc zdjęcie czy jaką mamy w głowie renderując. W
tym momencie kolor biały powinien być gdzieś pewnie w 18% dynamiki
monitora po to aby móc jakoś wyświetlić blask. W tym też momencie
otrzymujemy barierę w postaci powszechnie przyjętej definicji białego
koloru jako 0xFFFFFF. Po drugie mamy za mało bitów na kolor by móc
operować w tak przyjętej dynamice. A nawet jeśli się znajdzie kiedyś
karta i monitor więcej bitowe, to co z tego skoro aplikacje
oprogramowane są tak a nie inaczej i biały zawsze będzie 0xFF....
niezależnie od ilości bitów. Nawet gdyby jakiś cud się stał i weszłyby w
życie monitory i karty 16-bitowe, to do pracy w Wordzie potrzebowałbyś
ciemne gogle i kremy z maksymalnym filtrem UV aby się nie osmalić :-D

Nie wiadomo jak wybrnąć z tego konfliktu.

--
Pozdrawiam
Marek

do góry

On Sat, 17 May 2014, Marek wrote:

> W dniu 2014-05-17 00:05, Gotfryd Smolik news pisze:
>
>> Co ciekawsze, za każdym razem napotykałem na opór mocno przekonanych,
>> że monitor MUSI dawać obraz "białej kartki". Tak jakby aparatem
>> nigdy nie robiło się zdjęć z źródłami swiatła w kadrze.
>
> I tu ciąg dalszy.
> Poniekąd rozumiem Microsoft (bo chyba to oni wyskoczyli z pomysłem białej kartki).
> Oni nie widzą świata spoza ram Worda i wydruków.

Otóż to.

> Chciałoby się mieć możliwość zobaczenia sceny taką jaka w rzeczywistości
> była robiąc zdjęcie czy jaką mamy w głowie renderując.
> W tym momencie kolor biały powinien być gdzieś pewnie w 18% dynamiki monitora
> po to aby móc jakoś wyświetlić blask.
> W tym też momencie otrzymujemy barierę w postaci powszechnie przyjętej
> definicji białego koloru

To "powszechnie" oznacza "przez Microsoft"? :>

Wyważanie otwartych drzwi nie jest potrzebne - te DCE w "profi" systemach
(nie, nie graficznych, systemach operacyjnych ogólnego zastosowania)
miały właśnie kolor bazowy w okolicach tych 18%.

> Po drugie mamy za mało bitów na kolor

Ale tu sytuacja nie różni się wiele od stanu, kiedy to karty graficzne
z wielkim hukiem zaczęły umożliwiać dawanie więcej niż 1 bitu na kolor :>

Już objaśniam: jestem pewien, że był to Corel, prawie na pewno Corel 3.
"Umiał" (sam z siebie, bez wsparcia systemu i driverów) "porozkładać"
dightering tak, żeby wyglądało to całkiem znośnie.

I nie bez powodu rzuciłem tematem z monitorem o plamce 0,13mm :>,
właśnie taki sprzęt *daje* taką możliwość, przy zakładaniu oglądania
z ponad pół metra.

> A nawet jeśli się znajdzie kiedyś karta i monitor więcej bitowe, to co z tego
> skoro aplikacje oprogramowane są tak a nie inaczej

O toto.
Wystarczy aby TYLKO aplikacje graficzne umiały sobie z tym radzić.

> i biały zawsze będzie 0xFF.... niezależnie od ilości bitów.

Kiedy to jest wyłącznie konwencja :> i to wcale nie "wszędzie".

> Nawet gdyby jakiś cud się stał i weszłyby w życie monitory
> i karty 16-bitowe, to do pracy w Wordzie potrzebowałbyś ciemne gogle

Niekoniecznie.
Wystarczy żeby "bazowy" system miał rozsądnie ustawione parametry
a emulator wirtualnej karty komputera wirtualnego z Wordem umiał
przeskalować jasność o parę bitów w dół.
Wiadomo że na przerobienie Worda nie ma co liczyć, więc trzeba mu
"przeskalować" cały system :>

> Nie wiadomo jak wybrnąć z tego konfliktu.

Poczekać, aż większa liczba ludzi dojdzie do wniosku, że sławne
"640kB każdemu wystarczy" nie było wcale jedyną wdrożoną przez MS
głupotą.

pzdr, Gotfryd

do góry

W dniu 2014-05-17 15:42, Gotfryd Smolik news pisze:
>
> To "powszechnie" oznacza "przez Microsoft"? :>

Swoją drogą ciekawe pytanie. Kto wymyślił, że biel kartki to ma być 100%
jasności?

> Wyważanie otwartych drzwi nie jest potrzebne - te DCE w "profi" systemach
> (nie, nie graficznych, systemach operacyjnych ogólnego zastosowania)
> miały właśnie kolor bazowy w okolicach tych 18%.

Łoł! Nie sądziłem, że ktoś już robił takie przymiarki... Szkoda, że to
się nie upowszechniło.

>> Po drugie mamy za mało bitów na kolor
>
> Ale tu sytuacja nie różni się wiele od stanu, kiedy to karty graficzne
> z wielkim hukiem zaczęły umożliwiać dawanie więcej niż 1 bitu na kolor :>
>
> Już objaśniam: jestem pewien, że był to Corel, prawie na pewno Corel 3.
> "Umiał" (sam z siebie, bez wsparcia systemu i driverów) "porozkładać"
> dightering tak, żeby wyglądało to całkiem znośnie.

Tzn masz na myśli "dithering"? Corel robił to na monitorze? Coś w
rodzaju algorytmu Floyda-Steinberga jak w przypadku drukarek?
>

>
> O toto.
> Wystarczy aby TYLKO aplikacje graficzne umiały sobie z tym radzić.

Ale to niesie za sobą spore problemy. Choćby miniaturki w folderach
wyświetlanych systemowo będą wyglądały dziwacznie. I pewnie mnóstwo
innych aspektów wynikłoby. Wydaje mi się, że jedyna droga rozwiązania
problemu to rozwiązanie kompleksowe - systemowe. Nie wiem... jasność
procentowa kolorów zamiast w wartościach bezwzględnych? Wtedy uwalniamy
się od bitowości i możemy skalować jasności, przesuwać i co tam się chce
dla poszczególnych aplikacji. I nawet jeśli jakiś Word twierdzi, że 100%
to biel, to w jakiś ustawieniach systemowy można by ustawić, że Word się
myli i że jego 100% to de facto 18%.

> Niekoniecznie.
> Wystarczy żeby "bazowy" system miał rozsądnie ustawione parametry
> a emulator wirtualnej karty komputera wirtualnego z Wordem umiał
> przeskalować jasność o parę bitów w dół.
> Wiadomo że na przerobienie Worda nie ma co liczyć, więc trzeba mu
> "przeskalować" cały system :>

Ha, no to mamy podobną koncepcję :-) Trzeba patent wykupić :-D

>> Nie wiadomo jak wybrnąć z tego konfliktu.
>
> Poczekać, aż większa liczba ludzi dojdzie do wniosku, że sławne
> "640kB każdemu wystarczy" nie było wcale jedyną wdrożoną przez MS
> głupotą.

Faktycznie coś takiego było... już zapomniałem.

--
Pozdrawiam
Marek

do góry

Gotfryd Smolik news <s...@s...com.pl> writes:

> Już objaśniam: jestem pewien, że był to Corel, prawie na pewno Corel 3.
> "Umiał" (sam z siebie, bez wsparcia systemu i driverów) "porozkładać"
> dightering tak, żeby wyglądało to całkiem znośnie.

W każdym razie w tamtych czasach praktycznie wszyscy (przynajmniej
graficy itp.) mieli karty, które mogły wyświetlać przynajmniej 256
kolorów (z palety 2^(3*6)). Niektórzy pewnie mieli karty high/true
color, np. CL-GD 5422 albo Tridenty 8900 z odpowiednimi literami.

Oczywiście Corel pewnie robił dithering z 16 kolorów, zresztą chyba nie
był wyjątkiem.

> I nie bez powodu rzuciłem tematem z monitorem o plamce 0,13mm :>,
> właśnie taki sprzęt *daje* taką możliwość, przy zakładaniu oglądania
> z ponad pół metra.

No tak. Ale obawiam się, że taniej zrobić taki 10-bitowy o plamce 0,23 mm.

> Niekoniecznie.
> Wystarczy żeby "bazowy" system miał rozsądnie ustawione parametry
> a emulator wirtualnej karty komputera wirtualnego z Wordem umiał
> przeskalować jasność o parę bitów w dół.
> Wiadomo że na przerobienie Worda nie ma co liczyć, więc trzeba mu
> "przeskalować" cały system :>

Nie, no bez przesady. Każdy program powinien być w stanie korzystać
z takich okienek, jakie mu się podobają. Jeśli Word lubi 8-bitowe, to
niech takich używa, a inny program może używać 10-bitowych itp. Nie ma
najmniejszego problemu, by OpenGLowa karta graficzna połączyła okienka
o różnych liczbach kolorów w całość (w górę, bo w dół to może bez
sensu).

Zresztą, ten Word to chyba binarnie nie pisze do tych swoich okien?
Myślę, że bez OpenGL/DirectX by się też obyło.
--
Krzysztof Hałasa

do góry

On Sat, 17 May 2014, Marek wrote:

> W dniu 2014-05-17 15:42, Gotfryd Smolik news pisze:
>>
>> To "powszechnie" oznacza "przez Microsoft"? :>
>
> Swoją drogą ciekawe pytanie. Kto wymyślił, że biel kartki to ma być 100%
> jasności?

Nie wiem, ale co poniektórzy uznają to za oczywistość.
A mnie to... dziwi.
Jest nowe medium, trzeba je wykorzystać - przecież nikt nie usiłował
ograniczać filmu (jak już nastał) do prezentacji gazet.

>>> Po drugie mamy za mało bitów na kolor
>>
>> Ale tu sytuacja nie różni się wiele od stanu, kiedy to karty graficzne
>> z wielkim hukiem zaczęły umożliwiać dawanie więcej niż 1 bitu na kolor :>
>>
>> Już objaśniam: jestem pewien, że był to Corel, prawie na pewno Corel 3.
>> "Umiał" (sam z siebie, bez wsparcia systemu i driverów) "porozkładać"
>> dightering tak, żeby wyglądało to całkiem znośnie.
>
> Tzn masz na myśli "dithering"?

Tak, przekręciłem pisząc "z głowy czyli z niczego" :)

> Corel robił to na monitorze? Coś w rodzaju
> algorytmu Floyda-Steinberga jak w przypadku drukarek?

Tak, AFAIR na karcie grafiki z 16 kolorami (8 kolorów plus jeden bit
na jaskrawość, razem cztery bity na piksel) dawało się oglądać zdjęcia.
Fakt, dobrze było się odsunąć nieco ;)
Różnica była jednak porażająca (przy karcie "4 bit" i porównywaniu
przeglądarką systemową a Corelem).
A w trybie 256 kolorów nieuważny oglądacz mógł nie zauważyć, że
to nie jest karta "65536 kolorów".

>> O toto.
>> Wystarczy aby TYLKO aplikacje graficzne umiały sobie z tym radzić.
>
> Ale to niesie za sobą spore problemy. Choćby miniaturki w folderach
> wyświetlanych systemowo będą wyglądały dziwacznie.

W części formatów miniaturki mogą być zapisane jako odrębny obrazek,
z powodu szybkości ładowania oczywiscie.
Co mnie zaskoczyło - rzuciłem guglowi ten dithering :) - to fakt,
że z zupełnie innego powodu, formatu mianowicie, część programów
nadal "umie" posługiwać się rozrzucaniem:
http://www.home.unix-ag.org/simon/gimp/fsdither.html
(to jest uwaga o ulepszeniach w GIMPie głównie!)

I teraz hit numeru:
http://docs.gimp.org/en/glossary.html
+++
Dithering
[...]
Also note that although GIMP itself uses 24-bit colors, your system may
not actually be able to display that many colors. If it doesn't, then the
software in between GIMP and your system may also dither colors while
displaying them.
---

Może mnie ktoś oświecić o które "software between GIMP and your system"
może chodzić?
Najprościej by było, jakby (wzorem CORELa 3) po prostu istniała opcja
obsługi tego przypadku przez GIMPa.
Źle gadam?

> I pewnie mnóstwo innych
> aspektów wynikłoby. Wydaje mi się, że jedyna droga rozwiązania problemu to
> rozwiązanie kompleksowe - systemowe. Nie wiem... jasność procentowa kolorów
> zamiast w wartościach bezwzględnych?

Jakbyś się nie obrócił, to plecy i inne takie zostają z tyłu.
Problemem jest zaakceptowanie iż "8 bit każdemu wystarczy".
Cały tor trzeba by zmienić na 12-bit albo nawet 16-bit i tyle.

> Wtedy uwalniamy się od bitowości i możemy skalować jasności, przesuwać
> i co tam się chce dla poszczególnych aplikacji.

Moment, ale to przy założeniu, że grafika ma odrębne parametry dla
każdego okna. Nie jest niemożliwe, ale np. przy konstrukcji Windows
dość zabójcze (okno może nie być widoczne, ale informację o nim
trzeba trzymać, a każdy proces ma minimum jedno).

> I nawet jeśli jakiś Word twierdzi, że 100% to biel, to w jakiś
> ustawieniach systemowy można by ustawić, że Word się myli i że jego 100% to
> de facto 18%.

Jestem za ;)

>> Niekoniecznie.
>> Wystarczy żeby "bazowy" system miał rozsądnie ustawione parametry
>> a emulator wirtualnej karty komputera wirtualnego z Wordem umiał
>> przeskalować jasność o parę bitów w dół.
>> Wiadomo że na przerobienie Worda nie ma co liczyć, więc trzeba mu
>> "przeskalować" cały system :>
>
> Ha, no to mamy podobną koncepcję :-) Trzeba patent wykupić :-D

Pocieszające jest, że nie tylko samememu pewne ograniczenia przeszkadzają :)

pzdr, Gotfryd

do góry

On Sun, 18 May 2014, Krzysztof Halasa wrote:

> Gotfryd Smolik news <s...@s...com.pl> writes:
>
>> Już objaśniam: jestem pewien, że był to Corel, prawie na pewno Corel 3.
>> "Umiał" (sam z siebie, bez wsparcia systemu i driverów) "porozkładać"
>> dightering tak, żeby wyglądało to całkiem znośnie.
>
> W każdym razie w tamtych czasach praktycznie wszyscy (przynajmniej
> graficy itp.) mieli karty, które mogły wyświetlać przynajmniej 256
> kolorów (z palety 2^(3*6)). Niektórzy pewnie mieli karty high/true
> color, np. CL-GD 5422 albo Tridenty 8900 z odpowiednimi literami.

Już zdążyłem napisać obok - pewnie, ale:

> Oczywiście Corel pewnie robił dithering z 16 kolorów, zresztą chyba nie
> był wyjątkiem.

...właśnie. A dziś "nikt" nie usiłuje walczyć z 8-bit (no, na kolor)
ograniczeniem? Dziwne.

>> I nie bez powodu rzuciłem tematem z monitorem o plamce 0,13mm :>,
>> właśnie taki sprzęt *daje* taką możliwość, przy zakładaniu oglądania
>> z ponad pół metra.
>
> No tak. Ale obawiam się, że taniej zrobić taki 10-bitowy o plamce 0,23 mm.

Ale już nie jest taniej przepisać cały tor grafiki, od aplikacji do
drivera z karty, o pośrednich bibliotekach nie wspominając :)

pzdr, Gotfryd

do góry

Gotfryd Smolik news <s...@s...com.pl> writes:

> Tak, AFAIR na karcie grafiki z 16 kolorami (8 kolorów plus jeden bit
> na jaskrawość, razem cztery bity na piksel) dawało się oglądać
> zdjęcia.

Nie pamiętam dokładnie, ale tak było gdzie - w CGA? Bo chyba w EGA to
były palety, tylko nie pamiętam dokładnie jakie.
W VGA na pewno były palety od początku, więc po prostu było 16 kolorów
z palety 260 tysięcy.

> Also note that although GIMP itself uses 24-bit colors, your system
> may not actually be able to display that many colors. If it doesn't,
> then the software in between GIMP and your system may also dither
> colors while displaying them.
> ---
>
> Może mnie ktoś oświecić o które "software between GIMP and your system"
> może chodzić?
> Najprościej by było, jakby (wzorem CORELa 3) po prostu istniała opcja
> obsługi tego przypadku przez GIMPa.

To byłoby kiepskie rozwiązanie, gdyż należałoby to implementować
w każdym programie, który tego wymaga. Lepszym rozwiązaniem byłoby
takie, w którym program specyfikowałby np. wielkość (pod)okna i schemat
kolorów (np. RGB888), a system/sprzęt dokonywałby przekodowania w locie.

Tak się zresztą robi, z tym że niekoniecznie z ditheringiem.

> Jakbyś się nie obrócił, to plecy i inne takie zostają z tyłu.
> Problemem jest zaakceptowanie iż "8 bit każdemu wystarczy".
> Cały tor trzeba by zmienić na 12-bit albo nawet 16-bit i tyle.

W obecnej chwili używa się różnych przestrzeni/schematów wyświetlanych
barw, nie tylko sRGB 888. W szczególności często używa się np. YUV4:2:0
(średnio typowo 16-bit/piksel), ale także YUV4:4:4, 4:2:2 itp. Były
także formaty monochromatyczne. Nie wydaje mi się, by np. RGB 3 * 12 lub
3 * 16 było czymś trudnym do zaakceptownia.
Do tej pory nikt nie miał takich potrzeb, bo nie było sprzętu, który by
to wyświetlił (monitory 10-bitowe to ostatnie lata).

> Moment, ale to przy założeniu, że grafika ma odrębne parametry dla
> każdego okna. Nie jest niemożliwe, ale np. przy konstrukcji Windows
> dość zabójcze (okno może nie być widoczne, ale informację o nim
> trzeba trzymać, a każdy proces ma minimum jedno).

Nie widzę tu tego zabójstwa. Wątpię też, by MS Windows jako system
przechowywały informację o zawartości wszystkich okien. Nie żeby to był
problem.
--
Krzysztof Hałasa

do góry

Gotfryd Smolik news <s...@s...com.pl> writes:

> ...właśnie. A dziś "nikt" nie usiłuje walczyć z 8-bit (no, na kolor)
> ograniczeniem? Dziwne.

Nie wiem czy nie usiłuje. Kwestia potrzeb może. Jakbym ja miał takie
potrzeby (prawdziwe, nie jako sztuka dla sztuki), to bym pewnie
"powalczył".

>>> I nie bez powodu rzuciłem tematem z monitorem o plamce 0,13mm :>,
>>> właśnie taki sprzęt *daje* taką możliwość, przy zakładaniu oglądania
>>> z ponad pół metra.
>>
>> No tak. Ale obawiam się, że taniej zrobić taki 10-bitowy o plamce 0,23 mm.
>
> Ale już nie jest taniej przepisać cały tor grafiki, od aplikacji do
> drivera z karty, o pośrednich bibliotekach nie wspominając :)

Ogólnie rzecz biorąc, to pewnie (znacznie) taniej. Ale przyznaję, że
nigdy nie interesowały mnie szczegóły grafiki w MS Windows.
Swoją drogą, jasne jest że aplikacja musiałaby być napisana odpowiednio
w obu przypadkach. Pośrednie biblioteki wydają mi się nie mieć z tym
związku (a jeśli mają, to jaki i jakie?). Drivery, no raczej muszą to
obsługiwać, ale to jest prosta sprawa (w szczególności, jeśli mamy kartę
ze sprzętowymi teksturami i z transformacjami macierzowymi kolorów
w locie).
--
Krzysztof Hałasa

do góry