Dear ColorSync specialists, I want to recheck with you is my understanding of ColorSync displays principals is correct. Is it correct that for any desktop window in the macOS ColorSync make next color transformation: - transform RGB to XYZ via "Generic RGB profile.icc" with relative colorimetric intent - transform XYZ to RGB' via display profile with the intent from profile header (display that contain most part of window) - show RGB' - Additionally VCGT tag used to apply graphics-board LUT And all that transformations made without using chad (chromatic adaptation). Please point me if there is something wrong in this statements. And maybe i missed something. Also I'm interested to hear ColorSync developers what is their expectations to displays profile. Is display profiles can be used only for display matching in macOS? Or there is correct combination of accurate profile and vcgt that can describe and calibrate display in same time? The problem that i see here is next. If I have profile built by the display measurements and then add vcgt tag to change color or gamma of the display, then profile is not describing current display state anymore. In such case i feel that color-managed software can't rely on such profile anymore. With opposite approach we also have a problem: If I build profile with the applied vcgt to have accurate display profile and then apply it to the display, then macOS use it to match colors to generic rgb. So vcgt calibration lost in result. Maybe you have some described recipes how to create correct display ICC profile that change display gamma and in same type describe new state. One more question. Is it possible to end-user and to developers to change main color space (Generic RGB be default)? And why was Generic RGB chosen, not Apple RGB for example? Any help very appreciated. Thank you. Best regards, Vitaly Bondar
Hi, Am 25.07.2017 um 14:14 schrieb Vitaly Bondar:
The problem that i see here is next. If I have profile built by the display measurements and then add vcgt tag to change color or gamma of the display, then profile is not describing current display state anymore.
That's not how it's supposed to be done though. Calibration (which is what may be stored in a profile's 'vcgt' tag and then loaded into the graphics card videoLUT) is the first step, it needs to be active during profile measurements and profile use for the profile to produce the intended result. Changing gamma or other display adjustment parameters after the fact invalidates the profile (in the sense that it'll no longer accurately describe the display response). Florian.
Dear Florian, Thank you very much for your answer. The way you described (first calibrate, then profiling with adding same vcgt) works perfect on windows and linux. But for macOS things changes. Once you apply this profile you lost your calibration as system use this profile in color transformation chain. That is main question for me, what is the main idea behind this. And what profiles colorsync developers expect to have installed on the system. Best regards, Vitaly Bondar
Hi,
Am 25.07.2017 um 14:14 schrieb Vitaly Bondar:
The problem that i see here is next. If I have profile built by the display measurements and then add vcgt tag to change color or gamma of the display, then profile is not describing current display state anymore. That's not how it's supposed to be done though. Calibration (which is what may be stored in a profile's 'vcgt' tag and then loaded into the graphics card videoLUT) is the first step, it needs to be active during profile measurements and profile use for the profile to produce the intended result. Changing gamma or other display adjustment parameters after the fact invalidates the profile (in the sense that it'll no longer accurately describe the display response).
Florian. _______________________________________________ Do not post admin requests to the list. They will be ignored. Colorsync-users mailing list (Colorsync-users@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/colorsync-users/vitaly%40qubyx.com
This email sent to vitaly@qubyx.com
Am 26.07.2017 um 09:55 schrieb Vitaly Bondar:
But for macOS things changes. Once you apply this profile you lost your calibration as system use this profile in color transformation chain.
I do not know why you think that Mac OS does not correctly use the calibration when the profile is used. Florian.
Hello,
I do not know why you think that Mac OS does not correctly use the calibration when the profile is used.
Sorry, for unclean explanation. I will try in more details. Lets assume i want to have calibration to sRGB and to have accurate display profile. I do next steps: 1. apply "generic rgb profile" to display 2. make calibration to sRGB 3. apply copy of generic profile + vcgt 4. measure everything and calculate icc v4 profile 5. apply icc v4 profile + vcgt After point 3 i have calibrated display, but not accurate profile. After this point the profile does not describe display, but just a copy of Generic RGB profile. After point 5 my display is not sRGB anymore. It is gamma 1.8, the same as in Generic RGB profile This happens because XYZ->RGB transformation from my profile is now used before graphics-board will apply LUTs from vcgt. I will appreciate much if somebody will explain what is wrong in my sequence and understanding of ColorSync approach. Thank you. Best regards, Vitaly Bondar
Am 26.07.2017 um 15:18 schrieb Vitaly Bondar:
Lets assume i want to have calibration to sRGB and to have accurate display profile.
I do next steps: 1. apply "generic rgb profile" to display 2. make calibration to sRGB 3. apply copy of generic profile + vcgt 4. measure everything and calculate icc v4 profile 5. apply icc v4 profile + vcgt
After point 3 i have calibrated display, but not accurate profile.
Is your goal to implement a calibration/profiling solution? I guess what you're trying to achieve in steps 1 through 3 is a 'null' transform, but technically you can just tag the pixel buffer of your test patch window with the current display profile color space (CGColorSpace derived from ColorSyncProfileRef) and then set the gamma table using CGSetDisplayTransferByTable (as long as you remember that this is transient while the calling process is alive, not persistent), without first changing the actual display profile.
After point 5 my display is not sRGB anymore. It is gamma 1.8, the same as in Generic RGB profile.
Well, no. If you look at the tone response graph of the generated profile, you should see it follows the sRGB curve (at least it should if a null transform was used and the calibration was set during the characterization measurements).
This happens because XYZ->RGB transformation from my profile is now used before graphics-board will apply LUTs from vcgt.
And this is how it needs to be for the profile to produce the intended result, because the correct RGB numbers that need to be sent to the display to produce the intended intensity (or color) will only be arrived at after going through the videoLUT. Florian.
Hello Florian,
Is your goal to implement a calibration/profiling solution?
Yes, but i want calibration+profiling. But now i have feeling that my expectation is go against macOS logic. I expect to have sRGB+D65 not only on my patch or on some applications (will Adobe do trick that you described?). But to have sRGB+D65 on every window - on desktop, in image viewer, in some color unrelated software and so on. So if by my calibration calculations for point (128, 128, 128) i want to have XYZ triple like (96.8785, 100, 112.1183). I expected to see this XYZ on any picture for this ddl. And for sure i expect that in my display profile i will have next: RGB(.5,.5,.5)->XYZ(96.8785, 100, 112.1183). But now if i put such values in profile, then on my desktop i will have different color for this rgb.
I guess what you're trying to achieve in steps 1 through 3 is a 'null' transform, but technically you can just tag the pixel buffer of your test patch window with the current display profile color space (CGColorSpace derived from ColorSyncProfileRef) and then set the gamma table using CGSetDisplayTransferByTable (as long as you remember that this is transient while the calling process is alive, not persistent), without first changing the actual display profile.
Thank you for tip.
After point 5 my display is not sRGB anymore. It is gamma 1.8, the same as in Generic RGB profile.
Well, no. If you look at the tone response graph of the generated profile, you should see it follows the sRGB curve (at least it should if a null transform was used and the calibration was set during the characterization measurements).
This is only for my window, while i'm care about OS-wide colors.
This happens because XYZ->RGB transformation from my profile is now used before graphics-board will apply LUTs from vcgt. And this is how it needs to be for the profile to produce the intended result, because the correct RGB numbers that need to be sent to the display to produce the intended intensity (or color) will only be arrived at after going through the videoLUT.
As i described before, I expected to find a way to have situation close to Windows - profile describe current state of display, which is calibrated to my target. So, is it not what ColorSync expect? Is color-related software tries to suppress colorsync transformations on their windows? Thank you very much again to answering all these questions. Best regards, Vitaly Bondar
participants (2)
-
Florian Höch
-
Vitaly Bondar