W dniu 2014-05-13 13:29, XX YY pisze:

> tak jest - to jest jeden z aspektow.
>
> a teraz proponuje prosty experyment.
>
> zapisz obraz w srgb , otworz go programem odczytaj jako srgb i
> odczytaj w programie ilosc kolorow. bedzie iles tam dziesiat
> tysiecy.
>
> a teraz to smao zdjecie przekowertuj z SRB do aRGB i odczytaj w
> programie czytajacym aRGB ilosc kolorow. Bedzie ich mniej niz w
> oryguinalnym sRGB. roznice w zasadzie niewiduoczne - zamiast np 130
> 000 bedzie ich 80000 .

Zachowanie prawidłowe przy założeniu przeprowadzenia poprawnej konwersji
w/g profili. Powstają dwa zjawiska:

1) aRGB pokrywa większą przestrzeń barw więc sRGB jest jego podzbiorem.
Czyli z przestrzeni wszystkich możliwych kolorów w aRGB, tylko część
można użyć do zmapowania takiej konwersji. Z samej definicji tracisz ok
20% kolorów.

2) Tak jak Krzysiek powiedział: powstają błędy dopasowania koloru w
kolor przy palecie 8 bitowej. Zdarza się więc, że nieco różne kolory
sRGB stają się tym samym kolorem w aRGB (bo masz ich mniej o 20% do
dyspozycji). Przejście na 16 bitowy kolor rozwiąże ten aspekt ale nie
uzyskasz z tego większej ilości barw.

Reasumując: sens takiej konwersji jest więc średni. To tak jakbyś chciał
skonwertować czarno-białe zdjęcie do kolorowego. Problem jest analogiczny.

> z praktyki: przestalem sie fetyszowac monitorem. jesli wysylam
> zdjecia do sieci , czyli teoretycznie do milionow to nalezaloby tak
> skalibrowac moniotor jak maja odbiorycy , czyli jak te miliony. jak
> maja skalibrowane ? - w zdecydowanej wiekszosci fabrycznie + na oko ,
> tak by kolory wygladaly w miare naturalnie.

Ale nie o tym mówimy, bo tu masz rację. Jeśli ograniczasz się wyłącznie
do WWW, to szeroki gamut jest nawet szkodliwy w Twoim przypadku.
Fałszuje kolory przy braku kalibracji poprawnej (zwróć uwagę, ze użyłem
słowa "poprawnej" bo sama kalibracja nie wystarcza), a z kolei gdy
dokonasz poprawnej kalibracji, to ograniczasz sobie paletę barw o jakieś
20% w tym co karta podaje do monitora. Powstają wtedy problemy z
przejściami tonalnymi itp. Tak więc w takim przypadku powinieneś kupić
sobie tani monitor sRGB.

Jeśli natomiast chcesz tworzyć wierne wydruki i dysponujesz sensowną
drukarką, to nie wyobrażam sobie pracy w sRGB. Mnóstwo kolorów tracisz
względem aRGB. W takich przypadkach (to jest mój przypadek właśnie) rób
zdjęcia w aRGB, przetwarzaj w aRGB a do sieci zawsze możesz potem je
skompresować w sensie barw do sRGB. I ja tak robię. Kolory będą
intensywniejsze niż żywcem przesłany aRGB.


> I to wystarcza. Jezeli
> cos limituje jakosc mojej obrobki , to nigdy nie byl to monitor.
> Inaczej jest jesli bede chcial zdjecia obrabiane na moim monitorze
> wydrukowac w laboratorium zewnetrznym - wowczas trzeba sie
> doktoryzowac z "colormenagment" , zeby dostac wydruki identyczne jak
> obraz na monitorze.

Przesadzasz. To nie takie trudne ale jedynie fatalnie opisane w sieci.
Przynajmniej ja nie znalazłem podręcznika wyjaśniającego jak "to" działa
i sam musiałem dociekać (sporo czasu). Do tego jest usterka w Windows 7
i 8, którą trzeba umieć obejść (profilowanie nie zaskakuje samo z siebie
- trzeba pewną opcję włączyć i wyłączyć). Tymczasem wystarczy
wypunktować zasady a są one banalne. Jeśli nie rozumiesz zagadnienia i
nie zamierzasz zrozumieć - pozbądź się monitora szerokogamutowego bo
sobie tylko krzywdę robisz :-)

> w praktyce stwierdzam ze sredniej klasy monitor WG za ok 3500 zlotych
> nie wnosi mi nic istotnego , akurat u mnie ( ale to rzecz
> indywidualna) wywoluje tylko szybsze zmeczenie oczu.

Przyszło mi do głowy skojarzenie z powiedzeniem: wpuść chłopa do biura,
to atrament wypije :-D Nie jest moją intencją urażenie Ciebie. Chciałem
tylko przekazać, że nie powinno się używać rzeczy, których nie potrafimy
obsłużyć a już w szczególności, gdy nie chcemy umieć ich obsługiwać.

> Jesli przelaczyc
> na " eye care " , jakosc obrazu spada do jak kazdego innego taniego
> monitorka. kolor moze i lepszy , ale nie jest to roznica zasadnicza.
> w sumie w calkowitym bilansie wady zalety dostrzegam jednak wiecej
> wad.

Wreszcie :-)

> Praktyczna zaleta - ....mniej klikania . poniewaz monitor jest
> wiekszy i w proporcjach 16:10 , obok zdjecia jest troche miejsca na
> narzedzia programowe.

Monitory sRGB 16:10 też istnieją. Po drugie: czy w swoim monitorze nie
masz opcji "sRGB mode"? W swoich Dellach mam coś takiego. Opcja
wystarczająco skutecznie redukuje gamut.

--
Pozdrawiam
Marek

do góry

Am Dienstag, 13. Mai 2014 21:40:27 UTC+2 schrieb Krzysztof Halasa:
> XX YY <f...@g...com> writes:
>
>
>
> > zapisz obraz w srgb , otworz go programem odczytaj jako srgb i
>
> > odczytaj w programie ilosc kolorow.
>
> > bedzie iles tam dziesiat tysiecy.
>
> >
>
> > a teraz to smao zdjecie przekowertuj z SRB do aRGB i odczytaj w
>
> > programie czytajacym aRGB ilosc kolorow. Bedzie ich mniej niz w
>
> > oryguinalnym sRGB.
>
> > roznice w zasadzie niewiduoczne - zamiast np 130 000 bedzie ich 80000
>
> > .
>
>
>
> Kwestia zaokrągleń. Przekonwertuj wcześniej do sRGB 16-bit (i następnie
>
> do aRGB 16-bit) i tego efektu nie będzie.
>
> Po prostu przestrzeń sRGB w aRGB, jeśli można tak napisać, jest mniejsza
>
> niż 2^24.
>
> --
>
> Krzysztof Hałasa

to nie jest wyjasnienie ani srodek zaradczy.
ogladam zdjecia z sieci one sa w 8 bitach.

zrobilem prosciutki doswiadczenie.

zdjecie zapisane w sRGB 8 bit ma jak pomierzylem 460 000 kolorow
to samo zdjecie przekonwertorowane do aSRB ma 316 000 kolorow.

jesli masz w sieci zdjecia 8 bitowe w sRGB ( zdecydowana wiekszosc ) i je ogladasz na
monitorze o profilu aRGB to konwersja sRGB to aRGB prowadzi do utraty koloru (
zreszta podobnie a do s)

przy 16 bitach straty sa rowniez , choc mniejsze , ale takich zdjec w sieci sie nie
oglada ( pisze glowenie o jpeg - zdecydowana wiekszosc).

w dodatku to nie jest tak ze przestrzen s zawiera sie dokladnie w przestrzeni A -
w pewnej czesci sie nie pokrywaja.
monitory WG nie maja dokladnie przestrze aRGB , lecz do niej zblizona.

zeby podsumowac :

na eizo kalibrowanym widze kolory w zakresie ok niebiesko- zielonym nieco inaczej
niz na normalnych monitorach . Na eizo zielonkawo- niebieski jest widocznie mocniej
zaakcentowany. w praktyce na zdjeciach z siecie niebo wpada w lekki seledynek.
Czasami wyglada to glupawo - mialbym ochote posadzic autora o zly balans bieli , ale
wiem ze to nie jego wina.

do góry

> na eizo kalibrowanym widze kolory w zakresie ok niebiesko- zielonym nieco inaczej
niz na normalnych monitorach . Na eizo zielonkawo- niebieski jest widocznie mocniej
zaakcentowany. w praktyce na zdjeciach z siecie niebo wpada w lekki seledynek.
> Czasami wyglada to glupawo - mialbym ochote posadzic autora o zly balans bieli ,
ale wiem ze to nie jego wina.

Oddaj ten monitor w moje ręce. Z pewnością lepiej go wykorzystam :-D

--
Pozdrawiam
Marek

do góry

Am Mittwoch, 14. Mai 2014 10:53:55 UTC+2 schrieb Marek:
> > na eizo kalibrowanym widze kolory w zakresie ok niebiesko- zielonym nieco
inaczej niz na normalnych monitorach . Na eizo zielonkawo- niebieski jest widocznie
mocniej zaakcentowany. w praktyce na zdjeciach z siecie niebo wpada w lekki
seledynek.
>
> > Czasami wyglada to glupawo - mialbym ochote posadzic autora o zly balans bieli ,
ale wiem ze to nie jego wina.
>
>
>
> Oddaj ten monitor w moje r�ce. Z pewno�ci� lepiej go wykorzystam :-D
>
>
>
> --

a co stoi na przeszkodze zebys wykorzystal ten , ktory juz masz?
Twoich zdjec jakos nie widac.?

do góry

W dniu 2014-05-14 11:02, XX YY pisze:

>
> a co stoi na przeszkodze zebys wykorzystal ten , ktory juz masz?
> Twoich zdjec jakos nie widac.?
>

Ależ ja je widzę i wykorzystuję to tego celu obecne monitory. Jednakże
podniesienie komfortu pracy zawsze mile widziane.

--
Pozdrawiam
Marek

do góry

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

>> Nie musimy zgadywać, wiadomo że tak jest, bo to jest esencja LUTa.
>> Gdyby tam tego nie było, nikt by tego nie nazwał LUTem.
>
> No chwila, a jak się ma do tego to co sam zauważyłeś, że scalak ma od
> groma pinów? Jaki jest ich cel?

Idea LUTa to jest np. taki EEPROM, ma np. 28 pinów w obudowie DIP28
i kasuje się go ultrafioletem. No dobrze, niech będzie flash i DIP40.
I tak kiedyś LUTy wyglądały (pomijając takie programowe, bo też są
używane).
W tej chwili nie opłaca się wstawiać osobnego scalaka do takich rzeczy
(są duże i musielibyśmy użyć ich sporo). Wstawia się ASIC, albo w wersji
eksperymentalnej np. FPGA, i to robi wszystko - oprócz LUTów także
np. skaluje obraz, ew. rozmywa go itd. Częścią takiego ASICa jest także
procesor, np. jakiś ARM albo inny microblaze, więc od razu mamy OSD i co
tam jeszcze trzeba. Pewnie dostajemy tam wejściowe i wyjściowe serdesy,
GPIO do mrugania lampkami, i jeśli nie potrzebujemy dużo RAMu ani
flasha, to nic (dużego) tam już nie musimy wkładać (no może jakiś układ
do wyłączania/włączania zasilania).

Usera to pewnie niespecjalnie interesuje, ale można łatwo otworzyć
obudowę i samemu obejrzeć. Tylko ostrożnie, i po wypięciu kabla
zasilającego.

> Dlatego stosuje się procesory sygnałowe. Zwykłe CPU nie mają tu
> zastosowania. Kiedyś (dawno temu) oprogramowywałem procesory sygnałowe
> związane z akustyką. Już wtedy bez problemu dawały one radę robić FFT
> 1024 punktowe w czasie rzeczywistym.

LUTów nie robi się na procesorach sygnałowych, bo i po co? FFT nie
zrobisz LUTem. LUTy sprawdzają się tam, gdzie masz stosunkowo mało bitów
wejściowych (niezależnych od wcześniejszych i późniejszych danych),
a w FFT używa się długich ciągów bitów.

No i wymagania akustyczne, nawet takie 7.1 96 kHz 24-bit są minimalnie
mniejsze niż w monitorze.

Tak samo np. skalera nie robi się jako LUT, bo skaler musi (typowo)
buforować dwie linie obrazu. Załatwia się to właśnie czymś w rodzaju
prostego DSP. Oczywiście nie jest to oddzielny scalak, bo i po co.

> Żadne procesor nie był w stanie
> dorównać. Zapewne w tej chwili różnice prędkości specjalizowanych
> procesorów są znacząco większe względem zwykłych. Patrz Open GL itp.

OpenGL akurat jest złym przykładem, jest zbyt specjalizowany. OpenCL
może. Z drugiej strony, zwykłe procesory także są w tym dużo szybsze
- SIMD oraz specjalizowane rozwiązania (np. crypto, video
encoding/decoding itd). Ale obawiam się, że optymalna implementacja LUTa
w monitorze to będzie jednak LUT.
--
Krzysztof Hałasa

do góry

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

>> Kwestia zaokrągleń. Przekonwertuj wcześniej do sRGB 16-bit (i następnie
>> do aRGB 16-bit) i tego efektu nie będzie.
>> Po prostu przestrzeń sRGB w aRGB, jeśli można tak napisać, jest mniejsza
>> niż 2^24.

> to nie jest wyjasnienie ani srodek zaradczy.

To jest wyjaśnienie, dodatkowo oczywiste, ale przyznaję, że to nie jest
środek zaradczy. Jeśli możesz, skalibruj/przełącz monitor na sRGB,
a jeśli nie da się tego zrobić, a masz kartę graficzną, która to umie
(i monitor z 10-bitowym wejściem), to zrób to na karcie. Jeśli tego też
nie da się zrobić, to może rzeczywiście lepszym wyjściem będzie inny
monitor.

Inna sprawa, że mi akurat takie drobne zmiany koloru nie przeszkadzają.
W końcu kolor w komputerach zawsze jest skwantowany.

> zdjecie zapisane w sRGB 8 bit ma jak pomierzylem 460 000 kolorow
> to samo zdjecie przekonwertorowane do aSRB ma 316 000 kolorow.
>
> jesli masz w sieci zdjecia 8 bitowe w sRGB ( zdecydowana wiekszosc ) i
> je ogladasz na monitorze o profilu aRGB to konwersja sRGB to aRGB
> prowadzi do utraty koloru ( zreszta podobnie a do s)
>
> przy 16 bitach straty sa rowniez , choc mniejsze , ale takich zdjec w
> sieci sie nie oglada ( pisze glowenie o jpeg - zdecydowana wiekszosc).

Nie ma "strat", jeśli oryginalne zdjęcie było 8-bitowe. Chyba że później
znów przekonwertujesz to do 8 bitów, np. w celu wyświetlenia.

> w dodatku to nie jest tak ze przestrzen s zawiera sie dokladnie w przestrzeni A -
> w pewnej czesci sie nie pokrywaja.

No jak to nie:
http://en.wikipedia.org/wiki/Adobe_RGB_color_space
http://en.wikipedia.org/wiki/SRGB_color_space
Wierzchołki R i B są identyczne, G jest dużo niżej w sRGB.

> monitory WG nie maja dokladnie przestrze aRGB , lecz do niej zblizona.

Owszem. Podobnie zwykłe monitory są tylko zbliżone do sRGB.
--
Krzysztof Hałasa

do góry

Krzysztof Halasa <k...@p...waw.pl> writes:

> OpenGL akurat jest złym przykładem, jest zbyt specjalizowany. OpenCL
> może. Z drugiej strony, zwykłe procesory także są w tym dużo szybsze
> - SIMD oraz specjalizowane rozwiązania (np. crypto, video
> encoding/decoding itd).

Tzn. mam na myśli to, że są dużo szybsze niż kiedyś, nie tylko ze
względu na MHz ale także na wewnętrzną, równoległą budowę.
--
Krzysztof Hałasa

do góry

W dniu 2014-05-13 21:40, Krzysztof Halasa pisze:

> Kwestia zaokrągleń. Przekonwertuj wcześniej do sRGB 16-bit (i następnie
> do aRGB 16-bit) i tego efektu nie będzie.

Krzysiek, bierz jeszcze pod uwagę inne zjawisko, które nie pozwoli na
całkowite znikniecie efektu. Kolory są wartościami dyskretnymi a nie
ciągłymi. Tylko część kolorów z aRGB pokrywa się z sRGB. Więc
konwertując sRGB do aRGB mamy mniej sztuk kolorów w palecie do
obstawienia. No i w efekcie dwa nieznacznie różniące się kolory w sRGB
mogą otrzymać tą samą wartość w aRGB bo zabrakło wartości pomiędzy.


--
Pozdrawiam
Marek

do góry

>
> Inna sprawa, że mi akurat takie drobne zmiany koloru nie przeszkadzają.
>
> W końcu kolor w komputerach zawsze jest skwantowany.
>
>

no wlasnie
to nie sa jakies duze odchylki. w sumie widze niewielkie roznice , ale to nie
zakloca rzeczywiscie odbioru.

do góry