Nie ma najmniejszej różnicy między profilami .icc a .icm, to tylko debilny wymysł M$.
Wystarczy zmienić rozszerzenie.
Nie ma najmniejszej różnicy między profilami .icc a .icm, to tylko debilny wymysł M$.
Wystarczy zmienić rozszerzenie.
W świecie Microsoftu, wszystko musi być własną odmianą standardów. System CMM w Windows to ICM, a nie ICC i choć oprogramowanie poprawnie widzi ICC/ICM to pewna odmienność, poprawna politycznie, musi być. Podobnie jak w przypadku Java/Vitrualna maszyna Microsoft, czy SQL/Microsoft SQL.Zamieszczone przez Tomasz Urbanowicz
Z tego co mi wiadomo nie ma żadnej potrzeby konwertować profili, bo w aplikacjach CMM są one zamienne. Ewentualnie konwerter, to rename nazwa_pliku.icm nazwa_pliku.icc. :-)
Ostatnio edytowane przez Tom01 ; 20-02-2008 o 12:38
Masz problem z kolorem, wal śmiało!
e-mail: color@mastiff.pl
Jeszcze Was pomorduję
Tak dzisiaj sobie przebadałem różne profile pod kątem widzialności w głębokich cieniach (input R=G=B od 0 do 10 i odpowiedzi w profilu). W profilach z Match 3, Spyder, EZcolor, PM, ColorEyes Display, BasICColor wersja 4.0.2, no praktycznie wszystkich za wyjątkiem Lafota i BasICColor w wersji najnowszej, odpowiedź profili na zadaną wartość RGB=1 była wartość RGB=6 (przy wartości 0 było 0), przy zadanej wartości RGB=10 było średnio RGB=18.
W profilu Lafota i basICColor 4.1.8 przy RGB=1 jest RGB=2, przy RGB=10 jest:
- w Lafocie: 13
- w basICColor: 16.
Do czego zmierzam, otóż w teście "czerni":
http://www.drycreekphoto.com/Learn/C...itor_black.htm
w profilu z basICColor 4.1.8 trzeba się naprawdę wgapiać żeby móc odróżnić 0 od 1 - praktycznie nie do odróżnienia (Firefox 3 beta 3 z włączonym CM).
W profilach pozostałych odróżnić można dość wyraźnie.
Pytanie: jak jest poprawnie?
Profil referencyjny monitora EIZO S1931 ze strony EIZO również przy wartościach RGB=1 daje wartosć RGB=6, czyli między zadaną wartością RGB=0 i 1 mamy sporą przerwę, bo RGB=0 i 6.
Krzywa korekcyjna do LUT (VCGT) z profili z basICColor 4.0.2 i 4.1.8 jest praktycznie taka sama.
Co o tym sądzicie?
Obawiam się, że bez dobrego wzornika, pliku testowego, sprzętu i soft'u do próbkowania pojedynczych odcieni, nie sposób dać wiarygodnej odpowiedzi.
Masz problem z kolorem, wal śmiało!
e-mail: color@mastiff.pl
Poprawność kalibracji punktu czerni sprawdza się przy wyłączonym CM (RWCM, strona 241)Jeszcze Was pomorduję
Tak dzisiaj sobie przebadałem różne profile pod kątem widzialności w głębokich cieniach (input R=G=B od 0 do 10 i odpowiedzi w profilu). W profilach z Match 3, Spyder, EZcolor, PM, ColorEyes Display, BasICColor wersja 4.0.2, no praktycznie wszystkich za wyjątkiem Lafota i BasICColor w wersji najnowszej, odpowiedź profili na zadaną wartość RGB=1 była wartość RGB=6 (przy wartości 0 było 0), przy zadanej wartości RGB=10 było średnio RGB=18.
W profilu Lafota i basICColor 4.1.8 przy RGB=1 jest RGB=2, przy RGB=10 jest:
- w Lafocie: 13
- w basICColor: 16.
Do czego zmierzam, otóż w teście "czerni":
http://www.drycreekphoto.com/Learn/C...itor_black.htm
w profilu z basICColor 4.1.8 trzeba się naprawdę wgapiać żeby móc odróżnić 0 od 1 - praktycznie nie do odróżnienia (Firefox 3 beta 3 z włączonym CM).
W profilach pozostałych odróżnić można dość wyraźnie.
Pytanie: jak jest poprawnie?
Profil referencyjny monitora EIZO S1931 ze strony EIZO również przy wartościach RGB=1 daje wartosć RGB=6, czyli między zadaną wartością RGB=0 i 1 mamy sporą przerwę, bo RGB=0 i 6.
Krzywa korekcyjna do LUT (VCGT) z profili z basICColor 4.0.2 i 4.1.8 jest praktycznie taka sama.
Co o tym sądzicie?
To ja wiem, ja chciałem pokazać, jaki sens jest podbijanie tak drastycznie cieni szarości w profilu, skoro za to odpowiada krzywa VCGT?
Ostatnio edytowane przez Tomasz Urbanowicz ; 21-02-2008 o 21:51
A czy jest Pan pewien, że w nowym 4.1.8 ustawił Pan kalibrację do gammy 2.2?
Oczywiście.
W wersjach 4.1.7 i 4.1.8 odpowiedź profilu na wartości RGB=1 jest RGB=2 - podobnie jak w Lafocie, jednak w Lafocie krzywa VCGT w tym miejscu jest wygięta troszkę "do góry" i stąd zmiana wartości z RGB=0 i RGB=1 jest widoczna bez CM bez specjalnego wgapiania się. W BasICColor bez CM jest nie do odróżnienia do nawet wartość RGB=3 (RGB=4 już tak).
Dodam, że różnica w cieniach szarości jest dość wyraźnie widoczna przełączając się z profilem i bez profilu. Zastanawiam się grubo, czy nie zastosować tylko wczytywania do LUT poprzez xcalib profilu którego nie umieszczę w zarządzaniu kolorami w Windowsie - wtedy znikną dwa problemy:
- nie będę już się przejmował CMS w przeglądarkach (np. w PS i IrfanView będzie tak samo),
- nie będzie takiej rozbieżności w cieniach szarości w PS i IrfanView,
a deltyE w kolorach bez profilu są do zakceptowania tak mi się wydaje...
Ostatnio edytowane przez Tomasz Urbanowicz ; 22-02-2008 o 07:07
1. Takie numery można robić z monitorem sprzętowo kalibrowanym.
2. A i to nie do końca bo PS nie będzie miał informacji o gamucie monitora.
3. Co to znaczy "W BasICColor bez CM"? Moim zdaniem zachodzi tu dysjunkcja.
4. Odpowiedź w profilu nie daje żadnych miarodajnych wniosków. Jak już pisałem wcześniej, podstawą, jest wyłącznie zmierzenie konkretnego zadanego odcienia na monitorze.
Ostatnio edytowane przez Tom01 ; 22-02-2008 o 08:38
Masz problem z kolorem, wal śmiało!
e-mail: color@mastiff.pl
To wiadomo, jednak dE*94 z pominieciem profilu w moim monitorze wydają się do zaakceptowania:
- największa w szarości RGB=32 wynosi 1.29
- w czerwieni wynosi 2.5
- niebieski 3.8 (ale z profilem wychodziła tutaj ok. 2)
Nie musi mieć informacji - niech traktuje to jako sRGB
Być może niejasno się wyraziłem. Jeśli otworzę test czerni w przeglądarce np. Opera to jest problem z odróżnieniem wartości od 0-3. Z profilem jest do odróżnienia z racji tego, że sam profil podbija cienie, a to powinno być zadaniem krzywej VCGT - tak jak ma to miejsce w Lafocie.
Dlatego wspomniałem o podpatrzeniu tej "czerni" z profilem, aby pokazać jaka różnica jest z i bez niego mimo wczytania krzywej do LUT.
Uprawnienia umieszczania postów
Odpowiedz z cytatem