- This topic has 16 replies, 3 voices, and was last updated 5 years, 8 months ago by
.
-
Posts
-
First let me start by saying I feel completely stupid because I have NEVER understood how to use the “Verification” tab in DisplayCAL (more on this later).
Display is an LG OLED E6 (2016 model)
Calibration Tab: I’m using a custom white point (x0.3039, y0.3214) and White/Black/Tone Curve is “As Measured”
3D LUT tab: Rec.709, bt.1886@Absolute, Relative colorimetric for MadVRAs you can see, I’m wanting to use a custom white point for rec.709.
I have pre-calibrated the white point via HCFR and verified via interactive adjustment during profiling (they match in any pattern generator–default renderer and/or MadTPG).
Typically for purposes like mine, only 100% white is adjusted and the 3D LUT will correct everything else. I’ve never had good results doing this on any of my displays, not just this OLED.
I’ve pre-calibrated with my displays 20-point controls via HCFR which makes very easy to see where my profiles+LUTs fail to keep a neutral grayscale.Once the profile is created, I noticed “profile info” shows the “PCS illuminant XYZ” to be a different white point (ex: PCS illuminant XYZ 96.42 100.00 82.49 (xy 0.3457 0.3585, CCT 5000K)).
Shouldn’t this be my target white point? I assume this is the “absolute” white point, so shouldn’t this be D65/x0.3127 y0.3290?
I do see that the “relative” white point, the “Illuminant-relative XYZ” (?), seems to be correct (ex: Illuminant-relative XYZ 93.82 100.00 115.60 (xy 0.3032 0.3232)).Which leads me to wanting to verify with DisplayCAL and not using HCFR+MadVR+3D LUT, which is how I’ve been doing it. But I…. that tab does not make sense to me, at all.
No offense, but not a single reply to anyone else confused about this tab has made sense to me either, nor does the documentation, and Florian has explained this so many times over the years and yet it still simply fails to click with me for whatever reason. Perhaps this would make more sense to me if I was more familiar with ArgyllCMS and terms and processes techniques for calibrating other things like print/cameras/painting/etc?In any case, I feel bad for making yet another post about it.
Anyways, playing around with the Verification tab to try and wrap my head around this convoluted mess, I’ve… *facedesk*
1) Set the profile I want to use (Settings drop down at the top, next to 5 button icons for opening, archiving, deleting, installing and checking profile info).
2) selected a test chart (ex: made one to check a 20-point grayscale to crosscheck results with HCFR)
3) This is where nothing makes sense to me…
I thought I could figure out what to expect by looking at results of various configurations. Unfortunetly it makes even less sense to me now.
As such I’ll just go over ALL of them.
I’ll describe each config which will be attached in .zip and named in the order listed below.*Report 01*
I assume having simulation profile UNCHECKED means that the RGB values of the test chart will be the RGB values of the profile in 1)?
Doing so, reports shows
Display profile whitepoint: xy 0.3032 0.3232 (XYZ 93.82 100 115.6), CCT 7108K
Measured whitepoint: xy 0.3048 0.3212 (XYZ 94.89 100 116.45), CCT 7039K
Assumed target whitepoint: 7000K daylight, xy 0.3054 0.3216 (XYZ 94.94 100 115.96)
Again my desired white point is x0.3039 y0.3214 so Display/Measured values appear to be ok I think, but the assumed target? Should it not be what is in the Calibration tab (my desired white point)?BUT here is what is listed in measurement results (Overview) section.
Color is 255,255,255 x=0.3457 y=0.3585 Y=100.0005
Measured Color is x=0.3457 y=0.3585 Y=100When I enable “Use Absolute Values” (use display profile whitepoint as reference white is UNCHECKED) it becomes…
Color is 255,255,255 x=0.3032 y=0.3232 Y=100.0004
Measured Color is x=0.3048 y=0.3212 Y=100
The target (Nominal) xy values varies too, so am I correct in assuming that these target values were calculated from their resultant location in the profile selected in 1). Does this basically mean the test chart is using said profile as if it was an option in the simulated profile?Uh… what is this? I don’t even… That is not the white point I defined nor is it the profile/measured/assumed target white point. Where did x=0.3457 y=0.3585 even come from???
I hope you can understand why I’m confused. Again no offense.*Report 02*
If I ENABLE a simulation profile, Rec709 selected with same tone curve settings ([email protected]), with Use simulation profile as display profile UNCHECKED, the same test chart visually looks completely wrong below 255,255,255 white.
255,255,255 x=0.3457 y=0.3585 Y=100
measures as x=0.3457 y=0.3585 Y=100
and
128,128,128 x=0.3457 y=0.3585 Y=18.9462
measures as x=0.3724 y=0.3588 Y=21.3294, which is visually quite red.
I have NO idea what the purpose of this configuration is and don’t know how to interperet it (this goes for the next one, too).*Report 03*
If I ENABLE a simulation profile with Simulate whitepoint ENABLED, the same chart looks even more wrong (more red than previous).
255,255,255 x=0.3555 y=0.3629 Y=100.1955
measures as x=0.3491 y=0.3618 Y=97.6517
Test chart values appears to be D65 in 709, as ENABLING use absolute values has white at x=0.3127 y=0.329.
With Use display profile whitepoint as reference white ENABLED,
Target/measured xyY values did NOT change but the DELTA ERRORS did change, which I don’t understand either.
Could this be a bug in this configuration (values not changing but DE did)?*Report 04*
If I ENABLE a simulation profile with Simulate whitepoint AND Relative to display profile whitepoint are ENABLED…
255,255,255 x=0.3217 y=0.329 Y=100
measures as x=0.3436 y=0.3599 Y=99.0417
except the targets are actually VERY BLUE despite having the same xyY as the previous with Absolute set. Visually they’re more magenta than red or blue.
With Absolute ENABLED,
255,255,255 x=0.2717 y=0.2893 Y=100.7706
measures as x=0.3029 y=0.322 Y=99.0713
xyY in this configuration is completely wrong, they do not visually match. The previous config was visually too war while this was is too cool.*Report 05*
Now when Use simulation profile and use it as a display profile without specifing a device link…
255,255,255 x=0.3457 y=0.3585 Y=100
measures as x=0.3457 y=0.3585 Y=100
and with Absolute ENABLED,
255,255,255 x=0.3127 y=0.3290 Y=100
measures as x=0.3049 y=0.3210 Y=100
Visually and measurements looks like the first configuration (no simulated profile).
But for some reason the delta errors and RGB balance are quite a bit different when Use Absolute Values is enabled in comparison to the first configuration that had the same target xyY.*Report 06*
Finally, with a simulation profile AND a device link are used
255,255,255 x=0.3457 y=0.3585 Y=100
measures as x=0.3457 y=0.3585 Y=100
For some reason delta errors are HIGHER than they were in the previous configuration.
RGB balance, gamma, color temperature don’t match the previous configuration either (balance has some unusual spikes).
This matches what I see and measure with HCFR+MadTPG+3D LUT–massive red spike at 5% and a few other red spikes at 25%, 35% and 75%, and gamma looks suspicious (2.42-2.55).THIS. IS. SO. CONFUSING.
I simply can’t wrap my head around how all these options work together and what to expect from each configuration. Once more, no offense.The profile used for this example is attached and the zip includes the reports.
The main purpose of this thread is NOT about the verification tab despite writing so many questions about it, and instead about that “PCS illuminant XYZ” listed in the profile info and why it is not x0.3039 y0.3214 or even close to it.
Once the profile is created, I noticed “profile info” shows the “PCS illuminant XYZ” to be a different white point (ex: PCS illuminant XYZ 96.42 100.00 82.49 (xy 0.3457 0.3585, CCT 5000K)).
Shouldn’t this be my target white point? I assume this is the “absolute” white point, so shouldn’t this be D65/x0.3127 y0.3290?No, the PCS illuminant is always D50 (and doesn’t really matter).
What you want to look at is the whitepoint illuminant-relative XYZ, that is the “absolute” (as measured, but scaled to Y=100) whitepoint.
Again my desired white point is x0.3039 y0.3214 so Display/Measured values appear to be ok I think, but the assumed target? Should it not be what is in the Calibration tab (my desired white point)?
Assumed target is always the correlated daylight or black body temperature rounded to multiples of 100. You can ignore that if you’re using a specific target.
Color is 255,255,255 x=0.3457 y=0.3585 Y=100.0005
Measured Color is x=0.3457 y=0.3585 Y=100Nominal and measured adapted to D50. Allows you to assess color differences irrespective of whitepoint (the actual adapting whitepoint doesn’t really matter much).
Report 02/03/04
If I ENABLE a simulation profile, Rec709 selected with same tone curve settings ([email protected]), with Use simulation profile as display profile UNCHECKED, the same test chart visually looks completely wrong below 255,255,255 white.
This test goes through the display profile PCS to device tables, which are usually low quality (to save time) when creating a 3D LUT. Not the right option to choose when verifying a 3D LUT (always enable “Use simulation profile as display profile” in that case).
Report 05
Almost correct setup, except the 3D LUT (or devicelink) isn’t used so you’re verifying the native display response. The OLED does follow nicely the BT.1886 gamma 2.4 response.
for some reason the delta errors and RGB balance are quite a bit different when Use Absolute Values is enabled in comparison to the first configuration that had the same target xyY.
Yes, because the target (nominal) is D65 (from the simulation profile), but you have calibrated to a different whitepoint xy. In that case, “Use absolute values” needs to be unchecked to take that into account (by default, use absolute is always unchecked on the reports).
Report 06
This is the only correct configuration for verifying a 3D LUT.
The result is OK, but you can see that the LG OLED doesn’t have a very smooth response in the profile already (profile info, tone curve, set “device <- A2B <- PCS” direction), so what you can do with a 3D LUT is limited (the same is apparent in the 3D LUT tone curve, it is almost linear because the TV already follows a 2.4 gamma, but the bumps in the measured response are apparent).Once the profile is created, I noticed “profile info” shows the “PCS illuminant XYZ” to be a different white point (ex: PCS illuminant XYZ 96.42 100.00 82.49 (xy 0.3457 0.3585, CCT 5000K)).
Shouldn’t this be my target white point? I assume this is the “absolute” white point, so shouldn’t this be D65/x0.3127 y0.3290?
I do see that the “relative” white point, the “Illuminant-relative XYZ” (?), seems to be correct (ex: Illuminant-relative XYZ 93.82 100.00 115.60 (xy 0.3032 0.3232)).No, PCS is Profile Connection Space, the “lingua franca” for profiles to translate to/from. It is D50.
*Report 01*
I assume having simulation profile UNCHECKED means that the RGB values of the test chart will be the RGB values of the profile in 1)?
Doing so, reports shows
Display profile whitepoint: xy 0.3032 0.3232 (XYZ 93.82 100 115.6), CCT 7108K
Measured whitepoint: xy 0.3048 0.3212 (XYZ 94.89 100 116.45), CCT 7039K
Assumed target whitepoint: 7000K daylight, xy 0.3054 0.3216 (XYZ 94.94 100 115.96)
Again my desired white point is x0.3039 y0.3214 so Display/Measured values appear to be ok I think, but the assumed target? Should it not be what is in the Calibration tab (my desired white point)?No, it’s daylight curve at XXXX Kelvin “Correlate Daylight Temperarture”. If you used a custom white point the just check measured vs profile WP.
DisplayCAL chooses daylight curve as assumed white since for Web/photo/design you want a “white” (not green, not pink) white… a “natural white”. Since you choosed “whatever” other WP, you not look at that particular verification. It’s explained in the report, there is a check to choose what “whiteness” you choose as reference thermal or daylight. If you choose other WP… ther is no way to draw a curve for each warmer/cooler white with the same “whiteness” (as green or as pink as your reference).This way is much more functional that just profile WP verification because calibration may fail (and it is likely to fail in some HW calibration solutions like the ones from Dell/Benq/Lg etc…) so it is very useful default “whiteness” test.
BUT here is what is listed in measurement results (Overview) section.
Color is 255,255,255 x=0.3457 y=0.3585 Y=100.0005
Measured Color is x=0.3457 y=0.3585 Y=100When I enable “Use Absolute Values” (use display profile whitepoint as reference white is UNCHECKED) it becomes…
Color is 255,255,255 x=0.3032 y=0.3232 Y=100.0004
Measured Color is x=0.3048 y=0.3212 Y=100
The target (Nominal) xy values varies too, so am I correct in assuming that these target values were calculated from their resultant location in the profile selected in 1). Does this basically mean the test chart is using said profile as if it was an option in the simulated profile?Uh… what is this? I don’t even… That is not the white point I defined nor is it the profile/measured/assumed target white point. Where did x=0.3457 y=0.3585 even come from???
I hope you can understand why I’m confused. Again no offense.Absolute is just raw values without translating measured XYZ to PCS and profile to PCS to do the checking. Color managed apps work in PCS (try to simulate printer profile paper white ~5300K in Photoshop while in a D65 calibration and you will see what happens).
Keep in mind that L*a*b* still are refered to PCS white (D50), so a perfect D65 calibration won’t have a*b*=0 if you use absolute.*Report 02*
If I ENABLE a simulation profile, Rec709 selected with same tone curve settings ([email protected]), with Use simulation profile as display profile UNCHECKED, the same test chart visually looks completely wrong below 255,255,255 white.
255,255,255 x=0.3457 y=0.3585 Y=100
measures as x=0.3457 y=0.3585 Y=100
and
128,128,128 x=0.3457 y=0.3585 Y=18.9462
measures as x=0.3724 y=0.3588 Y=21.3294, which is visually quite red.
I have NO idea what the purpose of this configuration is and don’t know how to interperet it (this goes for the next one, too).Simulation profile clears GPU LUT calibration (3 x 1D LUT) then validates. This is for testing HW calibrations or out of the box behaviour.
THIS. IS. SO. CONFUSING.
I simply can’t wrap my head around how all these options work together and what to expect from each configuration. Once more, no offense.The profile used for this example is attached and the zip includes the reports.
The main purpose of this thread is NOT about the verification tab despite writing so many questions about it, and instead about that “PCS illuminant XYZ” listed in the profile info and why it is not x0.3039 y0.3214 or even close to it.
Look at first answer. PCS is D50… a “common language” profile coordinates translate to/from.
Hmmm lat’s say that I’m native chinese speaker and you are native protuguese speaker, we do not know each other languages but we should know how to speak english (“PCS”).Just do a few examples to understand PCS concept better: Create a eciRGBv2/ProphotoRGB image in PS in a D65 calibrated& profile screen. Image profile white is D50… but you see it as “just screen white” (D65). Conversions (color management) are done at PCS. then back to sceen at relative colorimetric.
Then try to sofproof simulating paper white. It will be corrected in PCS D50… but it won’t be corrected back to what paper should look under D50 lamp but instead to actual display illuminant hece image usually looks much more blue.Sorry, still kind of struggling to understand what it going on.
The common language makes total sense, thanks for phrasing it like that Vincent.Still, in Reports 05 and 06, I’m not quite understanding why the non-absolute white point is different (x0.3457 y0.3585) than what I pre-calibrated to (x0.3039 y0.3214).
As far as I can tell, defining a white point simply isn’t doing what I expect, and white points of LUTs generated do not match. I’m starting to think that I’m doing something wrong as none of my profiles have not produced results I expect want when checked via HCFR unless I pre-calibrate to D65, which I DON’T want for because of metameric failure.
Surely I shouldn’t need to create a synthetic profile for rec.709 with my desired white point (x0.3039 y0.3214) since I’m pre-calibrating to this AND defining this as my target for my profile?
I see I can’t even do that on the 3D LUT tab, but can do it with the stand alone 3D LUT Maker, and results are completely different than if I use this synthetic 709 profile for verification (below 255,255,255 is very red, with white being green in regardless of rendering intent used).To be clear, basically all I’m trying to do is have results that are rec.709 primaries relative to a custom non-D65 white point of x0.3039 y0.3214.
Still, in Reports 05 and 06, I’m not quite understanding why the non-absolute white point is different (x0.3457 y0.3585) than what I pre-calibrated to (x0.3039 y0.3214).
Have you read my answer?
Yes I did, and again I thank you both for putting up with my question.
No offense, but it is still unclear to me hence the “I’m not quite understanding why”.The profile itself states:
Measured whitepoint: xy 0.3048 0.321 (XYZ 94.95 100 116.56), CCT 7039KIf I use the Report 05 configuration to check the native display response of the test chart values of rec709, I am expecting the report to show that I was measuring a 255,255,255 at x0.3039 y0.3214, but instead it is x0.3457 y0.3585.
If I understand what you’ve said, those listed target and measured xyY have been “adapted to D50” to make it easier “to assess color differences”. To me this causes me even MORE confusion. How is verifying white at x0.3457 y0.3585 going to tell me anything about the x0.3039 y0.3214 white point that I’m concerned about?
If I understood what Vincent was saying, these target/measured values are being done in the PCS and D50 just happens to be the 100% white xy. So this means any white point, like say x0.123 y0.666, would be assigned to D50 and show as D50 xy but is really still x0.123 y0.666?
If so, this is so confusing but makes sense.
Why show target/measured xy values in this psuedo white point instead of actual target xy as expected?If I understand what you’ve said, those listed target and measured xyY have been “adapted to D50” to make it easier “to assess color differences”.
Yes, but note that “color differences” also includes achromatic colors (i.e. grayscale).
How is verifying white at x0.3457 y0.3585 going to tell me anything about the x0.3039 y0.3214 white point that I’m concerned about?
But you aren’t, using relative colorimetric intent means exactly that you do not care what the whitepoint is, because the 3D LUT will not change it. Or was your original intent to have the 3D LUT affect the whitepoint (e.g. display is some white A, but you want the 3D LUT to correct it to a different white B)? Then, you should use absolute colorimetric + whitepoint scaling as rendering intent.
Why show target/measured xy values in this psuedo white point instead of actual target xy as expected?
Because it allows you to subtract and judge white drift independently of the actual calibration (remember, the whitepoint difference is shown as the profile white vs measured white in an extra row, so you’re not missing out on anything).
If I understand what you’ve said, those listed target and measured xyY have been “adapted to D50” to make it easier “to assess color differences”.
Yes, but note that “color differences” also includes achromatic colors (i.e. grayscale).
How is verifying white at x0.3457 y0.3585 going to tell me anything about the x0.3039 y0.3214 white point that I’m concerned about?
But you aren’t, using relative colorimetric intent means exactly that you do not care what the whitepoint is, because the 3D LUT will not change it. Or was your original intent to have the 3D LUT affect the whitepoint (e.g. display is some white A, but you want the 3D LUT to correct it to a different white B)? Then, you should use absolute colorimetric + whitepoint scaling as rendering intent.
I’m terrible at explaining and putting my thoughts into words, so bear with me as I attempt to go over what I’ve been doing and what my goal is.
I’ve pre-calibrated my display using internal display calibration controls to rec709 but with a white point of x0.3039 y0.3214 and NOT D65. This was done with HCFR, and double checked with DisplayCAL’s visual white point editor and checking xy of different levels of R=G=B. Resultant xy pairs measured for the same R=G=B used by HCFR are copacetic for the same white point (my x0.3039 y0.3214).
White point of Rec.709 is D65/x0.3127 y0.3290, so if rendering intent is set to “Absolute colorimetric with white point scaling” my pre-calibrated white point would be “corrected” back to D65.
I do NOT want that white point for metameric purposes (to perceptually match another display which IS at D65).
So I should use a relative colorimetric intent for creating 3D LUTs from my profile made with my desired white point, yes? This is what I’ve been using.But I DO care about the white point and I DO want the 3D LUT to make adjustments to keep the whole grayscale as close as possible to x0.3039 y0.3214 to compensate where my display’s internal controls fail (you can only do so much with 20 point controls).
I’ve been assuming that defining a white point xy on the calibration tab instead of setting it to “as measured” would make the relative colorimetric intent adjust and scale so R=G=B would be that xy for the whole grayscale as much as possible. I’ve been avoiding setting white point to be “as measured” with relative colorimetric with the assumption that this would NOT correct to any specific xy and simply be whatever xy was measured for R=G=B, which I don’t want because my display’s have poor internal calibration controls that make very coarse adjustments in 0-30% range.
If I wasn’t using this custom white point I don’t think I would have any problems understanding how everything on the verification tab interacts thanks to both of yous explanations.
I’m just confused as to why I can’t see my xy as the target and the measured xy results for it.Seeing a different xy that means the same thing just feels wrong to me, so I started to assume I didn’t set up the verification tab properly. I tried every combination of configuration options with a rec.709 simulated profile and then again with a synthetic rec.709 profile using my white point (x0.3039 y0.3214). After looking at all of the reports and combinations of options in said reports, I simply couldn’t figure out what process(es) was being used for each report nor figure out the intent of what each combination was trying to verify. Seeing some reports had the same xy values as another but visually obviously wrong, I simply gave up at that point, nothing made any logical sense anymore.
Perhaps I should create a matrix as to make my white point (x0.3039 y0.3214 after ccss correction file I’m using) measure as D65? Seems like a silly thing to do just to feel comfortable using DisplayCALs verification reports just for this though.
Why show target/measured xy values in this psuedo white point instead of actual target xy as expected?
Because it allows you to subtract and judge white drift independently of the actual calibration (remember, the whitepoint difference is shown as the profile white vs measured white in an extra row, so you’re not missing out on anything).
By calibration you mean calibration done by DisplayCAL, the 1D LUTs yes?
If so I don’t think it makes sense to show those target xy values if a profile does not have a calibration or is linear.
I mean if I am targeting say D93, I would want to know I’m measuring x0.284863 y0.293221 as my 255,255,255 white, and compare measurements to that xy. How else would I know what the actual differences are?
To me this is like using International feet (0.3048 meters) instead of US Survey feet (0.3048006096 meters). This difference is very important in my field of work as a land surveyor, where simply estimating differences using the wrong “foot” WILL cause problems on the ground out in the real world and further exacerbate differences when transforming (converting) from ground-to-grid coordinates (ground x,y is always relative to 0,0 and grid x,y coordinates start in the millions as defined by the state Plane Coordinate System (sPCS). Applies to any coordinate systems for that matter.
Interestingly there are a lot of similarities between this and color science (ground-to-grid is practically the same as something like CIExy-to-CIEa*b*, both convert coordinates to a psuedo workspace for adjustments/processing and then converted to different coordinate system). Which is another reason I feel stupid for not understanding DisplayCAL’s verification reports.Again, thanks for putting up with my inability to comprehend what is happening here.
But I DO care about the white point and I DO want the 3D LUT to make adjustments to keep the whole grayscale as close as possible to x0.3039 y0.3214 to compensate where my display’s internal controls fail (you can only do so much with 20 point controls).
I’ve been assuming that defining a white point xy on the calibration tab instead of setting it to “as measured” would make the relative colorimetric intent adjust and scale so R=G=B would be that xy for the whole grayscale as much as possible. I’ve been avoiding setting white point to be “as measured” with relative colorimetric with the assumption that this would NOT correct to any specific xy and simply be whatever xy was measured for R=G=B, which I don’t want because my display’s have poor internal calibration controls that make very coarse adjustments in 0-30% range.
Look at the profile you made:
DisplayCAL-profile-info.exe “<YOUR PATH>\PC12 DARK 0-255 2.4 – LG E6 0.3039x 0.3214y 2018.icm”If you look at that profile you’ll see that its stores no calibration… just stores display behavior description.
Just look at calibration curves, linear = no grey ramp calibration and look at TRC curves (they drift from each other so it stores “actual” display behavior in grey … WOLED may be not very stable hence “actual” quotes).So once you made a preconditioning of your TV gain and OSD control you “did not calibrate” with DisplayCAL… you just measured and stored its behavior in an ICM file.
That’s equivalent to set “as measured”/”native” for everything.LUT3D creation stage is where you define actual target to match, if you want to change WP… etc.
From THAT description you want a LUT3D that transform your display behavior to Rec709 without changing your display white. That means:
-relative colorimetric white
-you do not need to apply VCGT to LUT3D since your profile stores no calibration.Also:
-Since Rec709 profile has neutral grey if your profile shows no neutral grey LUT3D will try to correct it… so it does not matter want you configured in calibration tab for YOUR display. LUT3D creation willl try to correct it because “source profile” (Rec709) has neutral grey.
-It can also correct white and neutrals to Rec709 white but you do not want it => relative colorimetric, keep “my” white.
-If you had a desktop profile (with GPU calibration) for that display to use in Windows desktop then it is very likely that display profile shows near neutral TRC curves (since it stores GPU calibration). So you need to apply to LUT3D the same kind of calibration (apply VCGT), this is not your situation, this is just general explanation. So if you has not configured some calibration parameters as measured, GPU calibration (VCGT) will store that correction you made in calibration stage of profile creation. Not your situation… you just measured your TV response (from profile info data, VCGT=linear=o calibration).So LUT3D creation take two inputs, your display behaviour (calibrated -with VCGT data- or not) stored in a ICM profile and the behavior you want to “emulate” (ICM profile, Rec709 in your example)…and a set of rules about how to make such transformation (gamma you want to emulate, rendering intent abs or relative.. etc)
I hope that you understand now what you did to create your LUT3D for madVR.
***
Now verification:
-asumed whitepoint curve of whites was explained above. If you use custom white do not look at it since it is not intened for you. Look at profile whitepoint against measured.
-by default evaluation is done in transformed values => xyY coordinates will be “moved” to PCS. Explained above. By default usually we just want to look at grey values a*b* deviations from 0,0. If you want to see measured values in xy do not use this.
-use abs values means “no transformed values”, that means “YOUR”/”ACTUAL” xyY values. (but L*a*b* values willl be refered to PCS white).
-for a D65 calibration if you see delta b=20 and delta a=1 (an aproximation) that means that you messed up with something related to actual white vs PCS white… or that the profile you are using for simulation/comparison has white defined as PCS D50 white (with some matrix tag to recover actual white if this profile was meant to be D65).
For your situation with custom white, just compute that distances from custom white to D50. Each time you see that kind of erros you’ll know what is happening.So look again to your reports and you’ll see what’s happening.
It makes sense to create a Rec709 synth profile with your custom white, measure madVR test pattern transformed colors (LUT3D active) and evaluate them against it. Using abs values xyY they should look as you expect IF your display profile is an accurate description of your TV (no drift .. etc).
Just use that. Other verification options won’t do what you want… but they make sense for other scenarios.For example, let’s say that I have a widegamut monitor configured to native gamut, D50, 2.2 gamma neutral grey and I have a profile that stores that behavior. I want to see how good is my setup to show an sRGB image in Photoshop or orther color managed apps (Photoshop WON’T show a sRGB image 255 white as “D65” white but as “display’s current white”). I won’t be using madVR output.
Then just validate my profile against sRGB profile simulation, but dont’ use it as display profile. This way you can check the accuracy of profile in color managed apps while showing sRGB images (relative colorimetric transformation from image to display). Same for AdobeRGB.Another example: evaluate out of the box factory calibration of one OSD mode of a particular display against sRGB for general use (again no LUT3D, just desktop behavior)
Do a verification against simulated sRGB, use that simulated profile as my display profile.White point of Rec.709 is D65/x0.3127 y0.3290, so if rendering intent is set to “Absolute colorimetric with white point scaling” my pre-calibrated white point would be “corrected” back to D65.
If you have set calibration whitepoint to those xy coordinates as you have, they will be carried over to the 3D LUT input profile (this hasn’t been the case until v3.3, but was a change I made because people sometimes wanted to skip interactive adjustment, but still have a way to target a different whitepoint without having to create a synthetic profile and go through the standalone 3D LUT maker). Note though that this means, if your display already is at these xy coordinates for white (i.e. through adjustment of display controls), that it doesn’t really matter if you use any combination of whitepoint “as measured”, those xy cooridinates, relative or abs + wtpt scaling, as the result will be all the same (as long as the display didn’t drift).
But I DO care about the white point and I DO want the 3D LUT to make adjustments to keep the whole grayscale as close as possible to x0.3039 y0.3214
No, by using relative colorimetric, you tell the 3D LUT to only make adjustments to keep grayscale neutral with respect to the measured whitepoint, whatever that may be (and it doesn’t matter).
By calibration you mean calibration done by DisplayCAL, the 1D LUTs yes?
No, in this case I meant the overall calibration (which includes the 3D LUT when used).
I mean if I am targeting say D93, I would want to know I’m measuring x0.284863 y0.293221 as my 255,255,255 white, and compare measurements to that xy. How else would I know what the actual differences are?
By looking at the profile vs measured whitepoint row. I think your confusion comes from the fact that the simulation profile whitepoint is still D65 (which, again, doesn’t really matter, because the values are chromatically adapted to a common ground white anyway).
you do not need to apply VCGT to LUT3D since your profile stores no calibration.
Yes, but since the calibration is linear, it doesn’t matter (typically you should always leave “Apply calibration (vcgt)” on the 3D LUT tab checked).
It makes sense to create a Rec709 synth profile with your custom white
Careful: Creating a synthetic profile with a changed whitepoint is not the same as using chromatic adaptation to adjust the primaries for a new whitepoint (the latter is the more scientifically correct approach that is implicitly used when you create a 3D LUT with relative colorimetric rendering intent). I could add this as a feature to the synthetic ICC profile creator, to have feature parity between standalone 3D LUT maker and main application.
White point of Rec.709 is D65/x0.3127 y0.3290, so if rendering intent is set to “Absolute colorimetric with white point scaling” my pre-calibrated white point would be “corrected” back to D65.
If you have set calibration whitepoint to those xy coordinates as you have, they will be carried over to the 3D LUT input profile (this hasn’t been the case until v3.3, but was a change I made because people sometimes wanted to skip interactive adjustment, but still have a way to target a different whitepoint without having to create a synthetic profile and go through the standalone 3D LUT maker). Note though that this means, if your display already is at these xy coordinates for white (i.e. through adjustment of display controls), that it doesn’t really matter if you use any combination of whitepoint “as measured”, those xy cooridinates, relative or abs + wtpt scaling, as the result will be all the same (as long as the display didn’t drift).
But I’m not using the D65 xy, nor using a “calibration” (see next comment).
I’ve been defining my xy here assuming this “target” would carry over to the 3D LUTs instead of setting it to “as measured”.
To clarify your statement, are you saying I can define a custom white point this way and set the 3D LUT rendering intent to “Absolute with white point scaling” and it will correct the whole grayscale and scale to my desired white point (x0.3039 y0.3214 and NOT D65)? If so, that is exactly what I’d want. OLED metameric failure at D65 is very obvious which is why I DON’T want to use it and why I’m being very particular about the white point.
I was assuming setting white point to “as measured”, with the display pre-calibrated to my desired xy within the limits of the displays internal controls, with a 3D LUT rendering intent being Relative colorimetric, that the end result would have a gamut following my display’s grayscale AS MEASURED which would NOT correct where internal controls could not be closer to x0.3039 y0.3214.
Sorry if that doesn’t make sense, I’m not satisfied with how I’m describing what I’m trying to say here.
LG has never had good internal display controls, not granular enough or poor coverage. The OLEDs are known for having poor quantization in the 0-30% range, and mine also has spiky luminance 0-10%, banding/quantization worst around 5%, 35%, 50% and 65%, and uncorrectable colorization 3-10% (alternating red and blue spikes, very challenging to distribute error here OLED image persistance behavior, applies to manual calibration and LUT corrections).
0-5% is still troublesome, but getting stable measurements is NOT a problem with inserting black patterns after every other pattern. The profile attached earlier does not have those so measurements are bad, I was only using that profile for the report examples by happenstance.
But I DO care about the white point and I DO want the 3D LUT to make adjustments to keep the whole grayscale as close as possible to x0.3039 y0.3214
No, by using relative colorimetric, you tell the 3D LUT to only make adjustments to keep grayscale neutral with respect to the measured whitepoint, whatever that may be (and it doesn’t matter).
I was simply saying that I do care about what end result white point is for the whole grayscale, and that I do want the grayscale to be corrected like it would be if I was using D65 and Absolute colorimetric with white point scaling… only for a different white point. Just letting you and others know what my goal is so you can hit me with a stick if what I’ve been doing so far has been wrong or could be improved, or what have you.
I mean if I am targeting say D93, I would want to know I’m measuring x0.284863 y0.293221 as my 255,255,255 white, and compare measurements to that xy. How else would I know what the actual differences are?
By looking at the profile vs measured whitepoint row. I think your confusion comes from the fact that the simulation profile whitepoint is still D65 (which, again, doesn’t really matter, because the values are chromatically adapted to a common ground white anyway).
Yes, exactly. This is the confusion I was trying to describe at the beginning, and tried to explain why I would have liked to see the reports using my white points because of metameric matching purposes.
This OLED at x0.3039 y0.3214 is matching my Kuro at D65. OLED at D65 looks sickly green to me side by side at the same level of nits, hence why I’m being particular about the grayscale white point.
It makes sense to create a Rec709 synth profile with your custom white
Careful: Creating a synthetic profile with a changed whitepoint is not the same as using chromatic adaptation to adjust the primaries for a new whitepoint (the latter is the more scientifically correct approach that is implicitly used when you create a 3D LUT with relative colorimetric rendering intent). I could add this as a feature to the synthetic ICC profile creator, to have feature parity between standalone 3D LUT maker and main application.
IMO feature parity is always a good idea. However I didn’t have good results creating a 3D LUT with it. I did do this for verification purposes where I could use absolute white point xy being my desired xy. I didn’t want to rely on that synthetic profile because it wasn’t an option in the main exe and I simply assumed this was for good reason (made this thread after seeing I couldn’t select this synthetic profile within the main exe).
If I was to use the synthetic profile, should I be telling DisplayCAL to be using D65 white point (display is still pre-calibrated to x0.3039 y0.3214) for profiling and create the 3D LUT using absolute colorimetric with white point scaling so final grayscale would be x0.3039 y0.3214 (or whatever the synth profile uses)? The only configuration I tried was with the profile created with DisplayCAL set to x0.3039 y0.3214 and used the absolute colorimetric with white point scaling which did not look right at all (255,255,255 was ok but everything else was VERY red as if I was using pink sunglasses. Didn’t bother to test if it was a bogus profile or not).
To clarify your statement, are you saying I can define a custom white point this way and set the 3D LUT rendering intent to “Absolute with white point scaling” and it will correct the whole grayscale and scale to my desired white point (x0.3039 y0.3214 and NOT D65)?
Yes.
Yes, exactly. This is the confusion I was trying to describe at the beginning, and tried to explain why I would have liked to see the reports using my white points because of metameric matching purposes.
Ok.
If I was to use the synthetic profile, should I be telling DisplayCAL to be using D65 white point (display is still pre-calibrated to x0.3039 y0.3214) for profiling
Profiling is just characterization. It just records the display state. It will record whatever whitepoint your display has in its current state. You have the option to adjust the whitepoint prior to profiling via display controls, 1D calibration curves, or you can skip that step and let the 3D LUT handle everything later. It won’t really make a difference for the 3D LUT (as long as you set the desired target xy and use abs. col + wtpt scaling).
The only configuration I tried was with the profile created with DisplayCAL set to x0.3039 y0.3214 and used the absolute colorimetric with white point scaling which did not look right at all
You probably forgot to enable “Use simulation profile as display profile” (and use the devicelink, i.e. 3D LUT). See my comment above re low quality PCS to device tables.
To clarify your statement, are you saying I can define a custom white point this way and set the 3D LUT rendering intent to “Absolute with white point scaling” and it will correct the whole grayscale and scale to my desired white point (x0.3039 y0.3214 and NOT D65)?
Yes.
Then I’ve totally misunderstood the documentation. So for futher clarification…
I interpreted it as implying that if my white point was different than the selected 3D LUT <Source colorspace>, so the rec.709 is doing to use D65 which is what I DON’T want in my case, then the 3D LUT would make adjustments to match THAT colorspace when using Absolute colorimetric (+white scaling).
And to use a different white point, in my case x0.3039 y0.3214, I need to use relative colorimetric.
Setting white to “As Measured” or entering the specific xy (x0.3039 y0.3214 in my case) would be passed along to the 3D LUT if the intent is Relative colorimetric or otherwise not an “absolute”.
So to rephrase if I understood you correctly, does this mean ANY white point defined here (or “as measured”) would override the white point used by the 3D LUT <source colorspace> option? I’m assuming this also adapt primaries xy to be relative of the new white point xy based on your warning for the stand alone 3D LUT maker.
Example: I pre-calibrate my display to x0.3459 y0.6666 (random numbers), and in DisplayCAL set the white point to x0.3039 y0.3214 (not “as measured”, but also without “calibrating”), profile, then create a MadVR/eeColor LUT (source colorspace is rec.709, intent is absolute with white point scaling), and the end result would be that the 3D LUT would try to correct the display’s white point (x0.3459 y0.6666) to x0.3039 y0.3214 as much as possible and NOT to D65?
If this is true, I wouldn’t know because the verification reports use a different xy. I’ll need to make a new “real” profile (with alternating black patterns; changed white balance controls since my previous “real” profile) to check this out with HCFR+MadVR.
I apologize if you feel as if you’re simply repeating yourself, some things simply don’t click with me unless it’s done a specific way that I can’t predict. Like street addresses, I have to go the same way from point A to point B at least 5 times in a row before I could find with even one road of difference (so embarrassing for a “land surveyor” with so much road work done for the city/highway department…)Profiling is just characterization. It just records the display state. It will record whatever whitepoint your display has in its current state. You have the option to adjust the whitepoint prior to profiling via display controls, 1D calibration curves, or you can skip that step and let the 3D LUT handle everything later. It won’t really make a difference for the 3D LUT (as long as you set the desired target xy and use abs. col + wtpt scaling).
Perhaps I did misinterperet what you just said about the xy being passed along to the 3D LUT?
I know I’m terrible at putting my thoughts into words, so if it might help…
Every time I’ve been talking about defining my white point xy THIS is the part I was referring to, as it is the only place to manually enter xy cordinates in the main exe. I’ve never been using DisplayCALs “calibration” in any other way (all “as measured” except for white point being defined), and I was trying to avoid using the stand alone 3D LUT maker because synthetic profiles were not an option to use for the 3D LUT tab’s “source colorspace”.The only configuration I tried was with the profile created with DisplayCAL set to x0.3039 y0.3214 and used the absolute colorimetric with white point scaling which did not look right at all
You probably forgot to enable “Use simulation profile as display profile” (and use the devicelink, i.e. 3D LUT). See my comment above re low quality PCS to device tables.
That’s what I thought too, but this was not the case. I didn’t investigate to see what was really happening but I suspect it was just a random fluke.
Sort of like when I randomly get DisplayCAL to go into a loop trying to calculate new iterative points with the chart editor, where +1 or -1 of the total iterative points to generate are fine but a specific one will just flat out cause DisplayCAL to calculate…. forever. I had it sitting at “addining ###/####” for over 24 hours once. Process didn’t crash, I could cancel and everything worked normally and trying again it would do the same thing. Hitting cancel and changing iterative patch count by +/-1 and it would work just fine.
This was repeatable only with one of my computers, and only that one with the exact same pre-condition profile, adaption/neutral axis/dark region%. Moving the files to a different computer and no problems. If I can ever re-produce this with my other computers and/or work stations I’ll be sure to give you reports on it but so far it’s just a random thing. I’ll need to use DisplayCAL more on the other computers to see if this truly is only this one computer or if it’s a combination of variables that cause this that would be different for different computers.
So to rephrase if I understood you correctly, does this mean ANY white point defined here (or “as measured”) would override the white point used by the 3D LUT <source colorspace> option?
Yes, with the exception of “As measured” (that’s what relcol is for).
I’m assuming this also adapt primaries xy to be relative of the new white point xy based on your warning for the stand alone 3D LUT maker.
Yes.
Example: I pre-calibrate my display to x0.3459 y0.6666 (random numbers), and in DisplayCAL set the white point to x0.3039 y0.3214 (not “as measured”, but also without “calibrating”), profile, then create a MadVR/eeColor LUT (source colorspace is rec.709, intent is absolute with white point scaling), and the end result would be that the 3D LUT would try to correct the display’s white point (x0.3459 y0.6666) to x0.3039 y0.3214 as much as possible and NOT to D65?
Yes.
If this is true, I wouldn’t know because the verification reports use a different xy.
You will not see the different target (nominal) xy because I haven’t implemented that, but the results will still be correct due to the “common ground” whitepoint adaptation (the only thing you won’t be able to see is your target whitepoint vs measured).
I apologize if you feel as if you’re simply repeating yourself, some things simply don’t click with me unless it’s done a specific way that I can’t predict.
No, it’s fine. I already got a good impression on what I might need to improve/implement (i.e. including 3D LUT target whitepoint and not original simulation profile target whitepoint in reports).
Every time I’ve been talking about defining my white point xy THIS is the part I was referring to, as it is the only place to manually enter xy cordinates in the main exe.
I was just pointing out that it doesn’t influence the profile, obviously. The profile needs to record whatever the current white is so the 3D LUT can later correct it.
That’s what I thought too, but this was not the case.
At least for the reports you attached it was (02/03/04).
Sort of like when I randomly get DisplayCAL to go into a loop trying to calculate new iterative points with the chart editor, where +1 or -1 of the total iterative points to generate are fine but a specific one will just flat out cause DisplayCAL to calculate…. forever.
That could be a bug in Argyll’s targen then. Did this happen with your custom charts or during the “auto-optimized” mode of DisplayCAL? Did you use a preconditioning profile (using LUT-based profiles for pre-conditioning can cause this to happen if the recorded response is not well-behaved enough, so one way to avoid it is to only used shaper + matrix based pre-conditioning profiles)?
