- This topic has 7 replies, 2 voices, and was last updated 2 years, 11 months ago by
.
-
Posts
-
I used disptools_V2.1.3beta_osx64.tgz for the displayCAL test, and added EIZO ColorNavigator and X-rite i1profiler for ICC production comparison
They all encountered the same problem. The color management system on the M1 seems to lock the GAMMA value and maintain it at the value of 2.2; even if I change the value with different calibration software, the image always maintains a similar appearance (but the program’s UI will change)
In addition, i1profiler seems to be facing the problem of chromaticity conversion. Only the ICC produced by this software has obviously wrong chromaticity, and the color becomes yellower.
In addition, I also compared different ICCs. Under the same gamma setting, DisplayCAL writes the curve data into the TRC tag, while the i1profiler’s TRC always maintains linearity, and the curve data is written into the VCGT tag (I’m not sure if this understanding is correct. Please refer to the picture)
Basics of color management:
two displays with the same white point and different colorspace that cover 100% of the same smaller colorspace (sRGB) should render an image encoded in that smaller colorspace in the same way
It does not matter if your display has 1.0 or 2.2 or 2.4 gamma, as long as profile stores that info on TRC, color management apps will “deform/transform” RGB values in image colorspace to equivalent color in display colorspace.
the image always maintains a similar appearance (but the program’s UI will change)
It is working as intened.
BTW, I won’t set g 1.0 in CN for image editing. It’s pointless, you’re loosing unique grey levels in color management for nothing since most content colorspace are “close” to 1.8-2.4 range: sRGB, AdobeRGB, eciRGBv2, ProPhotoRGB, ProStarRGB…
Maybe it has some utility for video editingHI Vincent,
first of all thank you for your contribution to software development and instructionsIt does not matter if your display has 1.0 or 2.2 or 2.4 gamma, as long as profile stores that info on TRC, color management apps will “deform/transform” RGB values in image colorspace to equivalent color in display colorspace.
This is my mistake, thank you for correcting it.
The problem should be changed to sometimes switch ICC, the application does not change, the image is always uncertain, and sometimes flickers.BTW, I won’t set g 1.0 in CN for image editing. It’s pointless
Gamma 1.0 setting,it is just to test. But it seems to be the wrong way to test CMS.
In addition, using the Validation CMYK function of EIZO ColorNavigator, errors will always occur on the M1 model; the same settings can be passed on the PC.I believe it is caused by the unstable conversion conditions mentioned above
HI Vincent,
first of all thank you for your contribution to software development and instructionsDisplayCAL or this web are not mine. It is Florian Hoch’s.
This is my mistake, thank you for correcting it.
The problem should be changed to sometimes switch ICC, the application does not change, the image is always uncertain, and sometimes flickers.AFAIK if you switch default OS display profile you need to restart color managed app (excluding apps relying on macOS color engine). At least for windows it works that way: on app startup, app ask OS for default display profiles, only once, since apps use their own color engine. So if you change displayprofile you need app restart to notice change.
Oh….I see, Thanks for your reply, again~
and I have one more question,When making software ICC with displayCAL, there is an option of “tone curve” in the “Calibration” section,
According to my understanding, this should be the expected response curve after correction; the smaller the value, the brighter the picture.If I made two ICCs，they had different gamma 2.2 and 2.6, used on the same screen.
Should the same picture still look the same?If the answer is “yes”, what is the function of “tone curve” really done?
I am confused.Should the same picture still look the same?If the answer is “yes”,
On color managed apps, yes
what is the function of “tone curve” really done?
“Gamma” in non color managed apps:
-like a TV which is expected to behave (in some OSD preset) as the content encoded in signal sent to TV
-like a monitor on a non color managed video player (display is expected to behave like a Rec709 g2.2 or 2.4 display)
-like in non color managed games on windows, display is pexpected to behave once calibrated like rec709 g2.2 displayFor color managed apps you can choose in TRC
-value closer to expected in faulty color management engines like macOS (default values in DisplayCAL for general purpose -non davinci resolve- displays on macOS)
-same/close value as TRC in most common image colorspace, so color management rounding errors in color managed apps are minimized. For example 2.2 (sRGB/AdobeRGB) or L* (eciRGBv2/ProStarRGB). It may be a headache on B&W with gradients.
-value closer to native display behavior, so when calibration is done thorugh GPU LUTs (no HW cal like your CG) corrections are smaller and you loose lesser unique grey levelsTRC= gamma 2.2 is a sweet spot for most requirements. It won’t matter on image apperance (color managed) but minimizes issues, specially with lesser monitors.
Thank you for your explanation. I thought I have a general understanding of how to use DisplayCAL,
but I am very unfamiliar with the ICC format, and I have never thought about the real function of “tone curve”;
Because I am also calibrating the TVs, when you mentioned TV, I suddenly understood.Thanks again for your clarification.
In addition, for the ICC produced by different programs,
the same calibration target (gamma value) has different TRC and VCGT tags.
(In the discussion part of the first message, there are pictures attached)
Do you have any ideas?
