- This topic has 22 replies, 2 voices, and was last updated 1 year, 2 months ago by
.
-
Posts
-
In the beginning I assumed that the measured values in testing is with the current display output with profile applied, compared versus the predicted custom profile output. I am understanding from your earlier reply that this is not correct, and that it measures “raw output” ignoring applied profile. I applied Windows’ default srgb profile and ran no-sim verification to check if it was really measuring raw display output ignoring profile. But the verification is very different (attached), and the only thing I changed was the applied profile. Therefore the measured values do use the applied profile in this test type. This test also showed the display’s factory 7000K whitepoint.
And just for clarity, I did not change any settings in DisplayCAL when testing a different profile. I made sure to start verification with the same Settings selection, and applying the different profile with the Profile Loader. This was to test if applied profile was being ignored or not in measured values
-**************Report values are writen on PCS colorspace****************, you are making all the numerical comparisons wrong. Read previous messages.
-no sim, raw values outputed, 255 blue output to display 255 blue (+ VCGT correction if applies), Measure & compare to predicted color coords by display ICC
-sim with no sim as display profile: read display profile, read sim, get color coors of patch RGB number sin sim colorspace, reencode coords to equivalent RGB number in display profile, send to display & measure.
-predicted color coords & rgb numbers can be spoted individually by using argyllcms comandline xicclu. Read its doc.
Individual patches can be read with “spotread”. Patches in a PS window (centered) are color managed, for raw RGB patches can ue MS PAINTI understand that everything is written in PCS colorspace, but I don’t see how it makes the numbers between the same test modes incomparable. If all reports are in the same colorspace, then they should be comparable? But I see now measured values should be different in the two test modes as they don’t display patches the same.
-sim with no sim as display profile: read display profile, read sim, get color coors of patch RGB number sin sim colorspace, reencode coords to equivalent RGB number in display profile, send to display & measure.
I understand now, no raw RGB output is being measured here.
Patches in a PS window (centered) are color managed, for raw RGB patches can ue MS PAINT
Aha I see. The measured value blue in MS Paint matches the srgb managed Photoshop 255 blue. And the MS Paint 255 blue is what I expect raw blue to look like and matches my other reference display much better.
But that comes back to the original post question, I understand srgb 255 blue lies outside of the Kamvas’ volume. The 3D volume shows srgb blue is very slightly outside the display gamut surface. And I already understood native blue is not srgb blue.
However, I am still not sure why the measured srgb sim 255 blue is so bad/worse when the native blue is much closer to srgb blue. Viewing raw 255 blue in MS Paint on the display is far more accurate to srgb 255 blue which I’m viewing in Photoshop on a separate reference monitor with full srgb coverage. The blue dE of the Windows srgb test was <4 while the custom profile is nearing 5 (attached previously). Verified a second time by using sim profile as display profile (same as applying manually) that blue dE is improved without custom profile. I could only narrow the cause down to the unknown characteristics of the display/backlight type or possibly the etched glass affecting shorter blue wavelengths as stated previously.
I will try calibrating and profiling with CIE 2012 to check if there is just something with my display type that is unknown (I understand report files use 1931 and have different whitepoint) It may also explain why the device 6500K setting is closer to 7000K CIE 1931.
Thank you for clarifications on the test modes
I understand that everything is written in PCS colorspace, but I don’t see how it makes the numbers between the same test modes incomparable. If all reports are in the same colorspace, then they should be comparable?
I meant your L*a*b* values in your screenshot, or xyY.
But I see now measured values should be different in the two test modes as they don’t display patches the same.
-sim with no sim as display profile: read display profile, read sim, get color coors of patch RGB number sin sim colorspace, reencode coords to equivalent RGB number in display profile, send to display & measure.
I understand now, no raw RGB output is being measured here.
Patches in a PS window (centered) are color managed, for raw RGB patches can ue MS PAINT
Aha I see. The measured value blue in MS Paint matches the srgb managed Photoshop 255 blue. And the MS Paint 255 blue is what I expect raw blue to look like and matches my other reference display much better.
Is your PS setup misconfigured? Create a sRGB image, put 255 green or 255 red. Are those xyY expected for sRGB? (measure). If not your PS setup is wrong. Check color preferences.
Also images SHOULD have a colorspace. Do not create a new image without color profile… it will work as MS paint.But that comes back to the original post question, I understand srgb 255 blue lies outside of the Kamvas’ volume. The 3D volume shows srgb blue is very slightly outside the display gamut surface. And I already understood native blue is not srgb blue.
However, I am still not sure why the measured srgb sim 255 blue is so bad/worse when the native blue is much closer to srgb blue.
Relative colorimetric closest color in gamut, explained before.
If wanna do the maths use “xicclu” tool.Viewing raw 255 blue in MS Paint on the display is far more accurate to srgb 255 blue which I’m viewing in Photoshop on a separate reference monitor with full srgb coverage.
Why do you say is more accurate? measure. calculate dE.
The blue dE of the Windows srgb test was <4 while the custom profile is nearing 5 (attached previously). Verified a second time by using sim profile as display profile (same as applying manually) that blue dE is improved without custom profile. I could only narrow the cause down to the unknown characteristics of the display/backlight type or possibly the etched glass affecting shorter blue wavelengths as stated previously.
out of gamut => closest relative colorimetric (matrix profile) or if you had a XYZLUT table with default perceptual intent and photoshop is using it, it is desaturating blue ramp to fit. IDNK which one did you use.
As a general rule if display is well behaved (close to perfect additivity, whatever gamut it has), create a matrix profile + single curve + bpc.
Table/XYZLUT is for capturing irregular behavior or perceptual oog.I will try calibrating and profiling with CIE 2012 to check if there is just something with my display type that is unknown (I understand report files use 1931 and have different whitepoint) It may also explain why the device 6500K setting is closer to 7000K CIE 1931.
Thank you for clarifications on the test modes
out of gamut => closest in gamut. observer won’t change OOG treatment.
Is your PS setup misconfigured?
It’s using the the preset North America Web/Internet configuration which is using srgb. All files also created with srgb. Resetting Photoshop to its default configuration (North America General Purpose 2) still uses the srgb color space. No differences occurred.
Why do you say is more accurate? measure. calculate dE.
It’s a very obvious difference to the eye. I can hold the display side by side with MS Paint blue on the Kamvas and Photoshop on my reference monitor and see it is visually nearly identical. Moving Photoshop to the Kamvas changes Photoshop to the measured bright purplish blue. i.e. Kamvas Raw blue is very good relative to reference monitor Photoshop srgb blue. Photoshop on Kamvas displays indigo.
What’s stopping me is Windows srgb profile having a smaller blue dE than the custom profile, which tells me that’s its capable of closer blue color, but somehow in the calibration and profiling process is making it worse, maybe as a result of tuning the other parameters.
As a general rule if display is well behaved (close to perfect additivity whatever gamut it has), create a matrix profile + single curve + bpc.
Table/XYZLUT is for capturing irregular behaviorInteresting, I’ll try that
As a general rule if display is well behaved (close to perfect additivity, whatever gamut it has), create a matrix profile + single curve + bpc.
Table/XYZLUT is for capturing irregular behavior or perceptual oog.Success– blue dE reduced to <2 with very fast setting. Still noticeably bit lighter purple but not nearly as bad before at dE 5. Photoshop also shows much closer to raw blue and reference monitor srgb blue. 3D volume coverage is much better too. Will run a larger set later with warmed up hardware.
Thanks for your help and information– I’ll keep that profiling option in mind. I’ll have to try it for some of my other displays now…
out of gamut => closest relative colorimetric (matrix profile) or if you had a XYZLUT table with default perceptual intent and photoshop is using it, it is desaturating blue ramp to fit. IDNK which one did you use.
Looks like you created and XYZLUT with default intent to perceptual + whatever config. AFAIK PS will use rel colorimetric by default. A matrx profile is only colorimetric.
From your lastreport your display seems well behaved so it does not need a 3d mesh porfile (xyzlut/table) but if youe ever need it for other displays and in default validation OOG colors show high deviation but PS does not (rel col), just redo profile as a xyzlut table but with rel col. The drawback is that rel col will clip OOG.
