Próbowałeś? To może jednak spróbuj.
Szukaj
Próbowałeś? To może jednak spróbuj.
Jacek
Oczywiście.
Jak widać - krzywe korekcyjne dopasowują natywną TRC oraz temperaturę monitora do danego standardu. Natomiast kolorantów monitora już nie zmienią, bo to niepodobieństwo. Na dobrym monitorze normalnogamutowym skalibrowanym pod sRGB różnice między obrazem wyświetlanym wg. liczb a korygowanym przez CMM są niewielkie - ale bynajmniej są (a jeśli wyświetlimy wg. liczb zdjęcie w sRGB na monitorze szerokogamutowym, to już wyraźnie wychodzą totalne pierdoły). Jeśli nie próbowałeś - to może jednak spróbuj
No przecież napisałem, że szopki zaczynają się wtedy, kiedy ktoś chce rozszerzyć zakres pracy monitora (te szeroko-gamutowe cudaki). Tam właśnie potrzebna jest modyfikacja danych przed ich przsłaniem do monitora. Dla sRGB tego problemu nie ma (tzn. jest, ale wynika tylko z drobnych wad monitora).Zamieszczone przez Czornyj
Oczywiście.
Jak widać - krzywe korekcyjne dopasowują natywną TRC oraz temperaturę monitora do danego standardu. Natomiast kolorantów monitora już nie zmienią, bo to niepodobieństwo. Na dobrym monitorze normalnogamutowym skalibrowanym pod sRGB różnice między obrazem wyświetlanym wg. liczb a korygowanym przez CMM są niewielkie - ale bynajmniej są (a jeśli wyświetlimy wg. liczb zdjęcie w sRGB na monitorze szerokogamutowym, to już wyraźnie wychodzą totalne pierdoły). Jeśli nie próbowałeś - to może jednak spróbuj
Możesz sobie uzywać dowolnie mądrych terminów (tak między nami - wychodzi z tego kompletny bełkot, którego nie da się czytać), ale wszystko i tak sprowadza się do tego, że trzeba poprzeliczać składowe koloru, czyli te Twoje numerki wysyłane do monitora. I wbrew pozorom są to bardzo proste operacje.
Jeśli jakiś ściśle określony kolor w definicji sRGB ma składowe (50,80,120), a monitor sRGB ma drobne wady, to w jego profilu masz zapisane, że trzeba te składowe zmodyfikować i przesłać do monitora inne wartości, na przykład składowe (48,79,124). Wtedy na monitorze z wadami zostanie wyświetlony taki kolor jaki chcemy uzyskać - jaki mamy zapisany w standardowym pliku z obrazkiem. Dla innego monitora, z innymi wadami, będzie to na przykład (52,76,119). Reguły tych modyfikacji są właśnie zapisane w profilu konkretnego monitora. I całe to kalibrowanie i profilowanie urządzeń sRGB sprowadza się do korekty drobnych wad i odstępstw od standardu sRGB i to właśnie robi Windows we własnym zakresie - poza aplikacją.
Ale jeśli monitor ma większy zakres kolorystyczny, to kolory sRGB o wartościach składowych z zakresu (0-255) będą na nim odpowiadały kolorom z zakresu, na przykład, (0-199) - reszta jest tą szeroko-gamutowością. Trzeba je więc przeskalować, bo inaczej kolorystyka będzie się znacznie różnić (kolory będą "wyprane"). Na dodatek powstaną nieciągłości gradientu i inne takie drobiazgi, bo monitor zamiast 256 jasności składowej dla sRGB, wyświetli tylko 200 swoich jasności (pozostałe, czyli 200-255 mogą być poza przestrzenią sRGB). To chyba oczywiste? Jeśli opracujemy odpowiedni profil, to na tym szeroko-gamutowym zobaczymy praktycznie to samo co na normalnym monitorze. Tyle, że cała ta szeroko-gamutowość weźmie w łeb, a kasa na monitor pójdzie w błoto, bo standard zapisu plików obejmuje mniejszy zakres, niż możliwości takiego monitora. Dlatego wykombinowano różne AdobeRGB i inne cudaki, w których wartości z zakresu (0-255) reprezentują zupełnie inne jasności składowych koloru niż to ma miejsce w standardowym sRGB. Tylko takie podejście pozwala wykorzystać możliwości monitora o szerszym gamucie w standardowym systemie komputerowym (np. zwykły PC-et). W konsekwencji jednak powoduje to, że standardowe aplikacje i standardowe (prawidłowo skalibrowane i oprofilowane) monitory sRGB wyświetlają te obrazki źle, bo to nie jest sRGB, bo w takim pliku do poszczególnych kolorów przypisane są zupełnie inne wartości składowych RGB. Całe zarzadzanie kolorem robi więc teraz robotę odwrotną, czyli próbuje na monitorze sRGB wyświetlić (upchnąć) to szeroko-gamutowe coś. W prosty sposób nie ma możliwości, bo się nie da (to jest chyba oczywiste). Dlatego stosowane są różne metody (kolorymetryczne, percepcyjne, i jakieś tam jeszcze inne cudowne recepty), które to robią mniej więcej, jako tako. Ale żeby mogły to zrobić, to w pliku z obrazkiem musi być zapisana informacja o tym, jak ten obrazek został przygotowany. Musi być informacja, czy to jest sRGB, AdobeRGB, czy jeszcze coś innego (praktycznie zupełnie dowolnego). Jeśli takiej informacji nie ma (obrazek jest jej pozbawiony), to zakłada się, że jest to standardowe sRGB. Dlatego właśnie można przekonwertować obrazek do sRGB i wywalić profil przed oddaniem go do labu. Oczywiście najlepiej mieć profil labu, ale jeśli go nie ma, to korzystamy ze starego dobrego sRGB, eliminując te wszystkie szeroko-gamutowe wynalazki. Tak to robią te cudowne magiczne aplikacje "zarządzajace kolorem" i to, że to robią, jest właśnie jedyną różnicą pomiedzy aplikacjami "zarzadzającymi kolorem" i tymi standardowymi, które zakładają, że wszystkie obrazki są zapisane standardowo, czyli w sRGB i żadnym kolorem zarzadzać nie trzeba, a odpowiednie korekty podczas wyświetlania obrazków na różnych (lepszych lub gorszych) monitorach wprowdzi sam system operacyjny. Po to właśnie ten system operacyjny jest.
Ostatnio edytowane przez JK ; 24-10-2008 o 11:41
Jacek
Czytam, kombinuję i narysowałem taki schemat:
W przypadku a) obraz sRGB wyświetlany jet błędnie na monitorze o szerokim gamucie. Zamiast czerwonego mamy super hiper czerwony.
Przypadek b) to dla mnie zagadka. Czy tak da się zrobić w systemie za pomocą profilu monitora? (Jacku, zrobiłeś mi nadzieję, że tak). Tracimy wtedy zalety szerokiego gamutu, ale mamy poprawny obraz w systemie. Wymyśliłem jeszcze jedno rozwiązanie. Można wtedy wykorzystać drugi profil, ręcznie ustawiony w aplikacjach z CMS, który by pozwalał korzystać z pełnego zakresu monitora.
I znowu moje laickie pytanie: Da się tak?
Oczywiście, że się da. Te Twoje schemaciki zawierają oczywiście pewne uproszczenia, ale ogólnie mówiąc jakoś tak to można schematycznie przedstawić. A profil, o którym mówisz w punkcie B, zrobisz sobie bez trudu za pomocą każdego kalibratora. Program kalibrujący i kalibrator robą to tak:
- program zadaje monitorowi jakiś kod koloru (składowe RGB),
- monitor go wyświetla,
- kalibrator odczytuje to, co jest wyświetlone,
- porównuje ze wzrocem,
- zwraca odpowiednie kody do programu kalibrującego.
Program kalibrujący wie, że zamiast koloru, który zadał do wyświetlenia, na monitorze pojawiło się coś innego i na tej podstawie może wyznaczyć odpowiednie korekty. Tak właśnie powstaje profil dla konkretnego monitora. Oczywiście, jeśli mamy dobry monitor i odpowiedni program, to znaczną część tych korekt można zpisać nie w profilu, tylko w wewnetrznej pamięci monitora, ale cel jest zawsze ten sam - zapewnienie tego, żeby wyświetlany kolor odpowiadał kolorowi zadanemu.
Ostatnio edytowane przez JK ; 24-10-2008 o 13:25
Jacek
Nie da się. Jacek wymyślił sobie jakieś partyzanckie zarządzanie barwą. Nie bierze pod uwagę, że koloranty mogą się różnić nie tylko nasyceniem - ale i tonem, nie wie o tym, że sRGB ma TRC które nie do końca odpowiada gammie 2,2. Chciałby kalibracją obciąć nasycenie kolorantów monitora, tymczasem kalibracja nie służy ustawieniu odpowiednich nasyceń i tonów kolorantów, tylko ustawieniu odpowiedniej temperatury bieli i gradacji.
Jeszcze raz podkreślam - oprócz kalibracji KONIECZNE jest stosowanie w czasie wyświetlania modułu zarządzania barwą. Jest to w oczywisty sposób widoczne dla użytkowników monitorów szerokogamutowych, ale nawet monitory o normalnym gamucie praktycznie nigdy idealnie nie odpowiadają przestrzeni sRGB i również zawsze wymagają pewnych korekt. I bynajmniej nie chodzi tu o korekty, które można załatwić jakąkolwiek kalibracją.
Te przeliczenia nie są tak proste, by można było pogmerać sobie wagami RGB i uzyskać poprawne rezultaty. Zawsze potrzebne są profile wejściowy i wyjściowy, które przeliczane są na wartości przestrzeni CIE XYZ lub L*a*b - będącą mapą wszystkich wrażeń barwnych z zakresu widzialnego. Mówiąc obrazowo - geometria przestrzeni barwnych różnych urządzeń jest zbyt skomplikowana, by można było w prosty sposób przeliczać jedną na drugą.
Monitory szerokogamutowe nie powstały dla jaj, a przestrzeń AdobeRGB nie jest fanaberią wynikającą z powstania monitorów szerokogamutowych - przestrzeń ta powstała w 1998 roku, kiedy monitory szerokogamutowe nikomu się nawet nie śniły.
Nie mam zamiaru z Tobą dyskutować o sprawach, o których pojęcie masz dość mgliste i głównie zasłyszane. Napisałeś kiedyś samodzielnie jakiś program? A może napisałeś program, który wyświetla (przetwarza) obrazy? Jak znam życie, to nie napisałeś. Wiesz jak są sterowane na poziomie sprzętowym karty graficzne instalowane w komputerach, o których tu mówimy? Pewnie nie wiesz. Wiesz na czym polega przetwarzanie sygnałów analogowych na cyfrowe i odwrotnie oraz jak to się robi? Pewnie też nie wiesz, bo i skąd miał byś to wiedzieć. A ja takich programów napisałem w życiu sporo, zarabiam tym na życie od dwudziestu lat z całkiem niezłymi efektami. Niektóre programy obsługiwały karty graficzne z pominięciem systemu operacyjnego (miały własne sterowniki), inne korzystały z mechanizmów oferowanych przez systemy operacyjne (np. przez Windows). Napisałem też trochę programów dla mikrokontrolerów, przetwarzałem tam, między innymi, sygnały analogowe na cyfrowe i odwrotnie, zajmowałem się odszumianiem tych sygnałów i ich wykorzystywaniem do sterowania pracą różnych dziwnych urządzeń przemysłowych (skomplikowanych urządzeń). Jednym słowem trochę wiem o tym, jak to się robi, bo robię takie rzeczy dość często (ostatnio trochę rzadziej, ale już szykuje się nastepna okazja). O czym więc chcesz dyskutować? Rozumiem, że dla kogoś, kto nigdy tego nie robił, całe to zagadnienie może się wydawać bardzo skomplikowane i prawie nie do pojęcia, ale zapewniam cię, że wszystko jest dla ludzi, a jak się trochę zastanowić, to całe to "zarządzanie kolorem" sprowadza się do algorytmów o przeciętym stopniu złożoności, a w konsekwencji do kilku podstawowych działań arytmetyczno-logicznych.
Jeśli masz ochotę, to nadal pisz te swoje historyjki. Nie mój problem.
Ostatnio edytowane przez JK ; 24-10-2008 o 16:09
Jacek
Jacku - z całym szacunkiem - mogłeś sobie napisać nawet milion programów z interfejsem graficznym nie mając zielonego pojęcia o zarządzaniu barwą.
Prezentujesz tutaj podejście do zarządzania barwą, które było modne za pierwszych Macintoshów - wtedy monitor kalibrowany był pod drukarkę Apple LaserWriter, a przestrzeń edycyjna (ColorMatchRGB) odpowiadała przestrzeni monitora Apple (natenczas monitory Apple były robione wyłącznie na kineskopach Trinitron, co dodatkowo ułatwiało sprawę). Niestety, od lat osiemdziesiątych trochę się pozmieniało.
Nie uważam siebie za jakiegoś wielkiego megaeksperta, a im bardziej interesuję się tematem, tym bardziej uświadamiam sobie jak niewiele wiem - ale to, o czym tutaj mówię to - doprawdy - color managementowe przedszkole. Nie ma to również zbyt wiele wspólnego z programowaniem, a więcej z teorią barwy, matematycznymi modelami percepcji, kolorymetrią i spektrofotometrią.
wieści z placu boju
Kalibrowałem monitor i zauważyłem, że zmiany są widoczne w całym systemie operacyjnym. Aplikacja do kalibracji na końcu procesu ma możliwość porównania "before - after" i efekt widoczny jest wszędzie. Natomiast nie zauważyłem żadnego wpływu na problem z szerokim gamutem.
Chyba jednak jedynym wyjściem jest używanie aplikacji z CMS. W związku z tym mam pytanie: Jakie przeglądarki obrazków obsługują zarządzanie kolorem? Wiem, że XnView (mój ulubiony), FastStone, ACDSee niestety nie. ACDSee Pro działa poprawnie, ale trochę za drogi. Znacie jakieś inne?
Czy mnie się wydaje, czy Firefox po włączeniu zarządzania działa zauważalnie wolniej?
Zgadzam się z tym stwierdzeniem.
Testowałem wszystkie wspomniane przez ciebie przeglądarki i zarządzanie kolorem działa niestety tylko w ACDSee Pro, choć chwalą się tym XnView, FastStone(oooookropnie wolny), IrfanView i parę innych. Jedyny problem jaki zauważam w ACDSee Pro to widoczna posteryzacja przy pracy w trybie CMS, przede wszystkim w cieniach (wygląda to jakby kontrast został podniesiony i cześć szarości jest po prostu zamieniana na czerń). Nie wiem, czy to tak ma być, czy też jest to efekt używania fabrycznego profilu (póki co nie dorobiłem się kalibratora).
FF musi działać wolniej po włączeniu CMSa. W końcu CMS to całkiem sporo dodatkowego przetwarzania.
Uprawnienia umieszczania postów
Odpowiedz z cytatem
Skontaktuj się z nami