- This topic has 22 replies, 2 voices, and was last updated 1 year, 3 months ago by
.
-
Posts
-
Trying to profile a Huion Kamvas Pro 16 with a Colormunki Display. The device has an anti-glare etched glass.
My process:
- First brought the RGB grey balance as close to 100% level using HCFR measurements by adjusting user temperature setting on the display (RGB 128, 117, 112). Measured black had very high blue, otherwise pretty good.
- Calibration with CIE 1931, 6500K, gamma 2.2, BPC on, low speed, assuming PFS Phosphor WLED family. I couldn’t find any information on the actual type other than its IPS.
- Skipped initial whitepoint RGB balancing due to step 1. Reported levels were okay, dE 2.3. Measured blackpoint around 5-6 iirc. Seemed normal in the process for my other displays.
Got good results except for the pure blue dE, which is around 5. Verifications attached. Factory 6500K stock setting, user temp no profile, and user temp + profile
Ran calibration twice, but I can’t figure out what’s causing the blue to shoot up. It’s worse with the profile than without. Viewing the charts (and just filling blue in Photoshop) on the display show its clearly capable of showing actual 255 blue, so I’m not sure why its measuring so lightly.
Is the 0% blue balance shooting to the moon a sign of anything in particular? Wrong display type correction? Black point correction affecting it? The etched glass?
I don’t think it’s the colorimeter. I’ve profiled and verified other displays of various types recently with it no problems. The only distinct features of this is the etched glass and unknown LCD type.
Thanks in advance
Calibrite Display SL on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.Disable profile simulation, validate if display profile matches display.
The results of that is the previously attached “kamvas-user-temp-calibrated.html”. All results look good except for 255 blue. The results chart reports a lighter blue, but at the same time the same display is able to produce a distinct difference between 255 blue and the measured blue.
Disable profile simulation, validate if display profile matches display.
The results of that is the previously attached “kamvas-user-temp-calibrated.html”.
No, it has simulation profile. Re run without it.
Device:
Kamvas Pro 16 @ 734, 1440, 1536×864
Instrument:
i1 DisplayPro, ColorMunki Display — LCD (generic)
Correction:
LCD PFS Phosphor WLED family <PFS_Phosphor_Fa…ly_31Jan17.ccss>
Display profile:
Pro 16 #1 2023-01-17 13-47 D6500 2.2 S XYZLUT+MTX
Display profile luminance:
156.5 cd/m²
Display profile whitepoint:
xy 0.3133 0.3297 (XYZ 95.02 100 108.29), CCT 6467K
Measured luminance:
157.6 cd/m²
Measured whitepoint:
xy 0.3127 0.3314 (XYZ 94.34 100 107.38), CCT 6487K
Assumed target whitepoint:
6500K daylight, xy 0.3128 0.3292 (XYZ 95.02 100 108.77)
Measured black luminance:
0.1907 cd/m²
Contrast:
826.7:1
Testchart:
verify.ti1
Simulation profile:
sRGB IEC61966-2.1All results look good except for 255 blue. The results chart reports a lighter blue, but at the same time the same display is able to produce a distinct difference between 255 blue and the measured blue.
You’ll be checking if display profile is accurate with that small testchart. Maybe blue primary was recorded accurately but some point in 3d mesh for XYZLUT table was of in the less sturated blues.
Try that first.Run a bigger patch set, you need to see if “inside gamut” 3dmesh stored as XYZLUT table profile is innacurate even if primaries (gamut boundaries) are ok.
I made a new calibration and profile with same inputs for a sanity check. Same results as before
Attached verifications for 325 patch no sim and 51 patch srgb sim.
I notice the values for 255 blue measurement looks and display correct in the no sim test and only measures wrong and displays distinctly in the srgb test. The gamut ab chart seems to show it as well
Did you check gamut intersection in a 3D VRML/HTML? Maybe even if display is >100% srGB in volume its intersection is not 100 and sRGB 255 blue falls outside. 2D projection shows it’s in but in 3D there is brightness diff in 3D sooli volume and 4dE is relative coorimetric best neighbour inside gamut.
In displayCAL profile info, 3D view and play with sRGB as reference,I see in the 3D view the srgb blue face of the volume lies very slightly outside the measured volume– I understand that coverage and volume are not the same.
I’d like to understand why the measured output without simulation is closer to srgb blue than the measurement during srgb profile simulation which is more purple. It’s visible on the display that it can produce a truer 255 blue closer to srgb blue, just not during srgb sim for some reason.Measured LAB values without sim: 255 blue is 29.25, 81.01, -116.58.
With srgb sim: 35.5, 61.02, -105.62.
HCFR shows similar during color testing.Essentially, why are the non-sim and srgb sim measurements different? Shouldn’t the measured values be the same in both instances since the same custom profile is being measured? I assume only the nominal values should change as the reference profiles are different.
Is it something to even worry about if the display can show a closer blue normally and to just ignore the srgb measurement?
no sim=> RGB patches are set raw, in monitor’s colorspace . Then measure & compare to values preticted by ICC
sim (no sim as display profile) => RGB numbers in sim colorspace are reencoded (I assume) relative colorimetric in display colorspace. Then measure & compare to predicted by sim ICC
All done in PCS (D50)
Hence if 255 sRGB blue is out of gamut, measured value ideally will be relative colorimetric closest color in your display colorspace.
That’s the reason to check in a 3D VRML/HTML if sRGB blue peaks out of your display colorspace.Hm, that doesn’t quite line up with what I’ve been testing between DisplayCAL and HCFR, but I may be mixing some things up
HCFR I know tests with raw RGB output, and it measures the same light purplish blue primary (35.5, 61.02, -105.62) like in the srgb sim test, which seems correct since I had to turn the display’s blue output down from 128 to 112, and green from 128 to 117, for RGB greyscale balance before profiling with DisplayCAL.
The no sim test is measuring a truer 255 blue, so that led me to believe it’s testing with the custom profile (with corrected 255 blue) against itself with new measurements, which would be used to check for color drift.
But if it like you say and the no sim measurement is using raw RGB output, and it measures a better raw blue, it’s strange that DisplayCAL calibration and profiling (3 times) is not using that better raw blue output during creation as it is perfectly capable of displaying it.
Hm, that doesn’t quite line up with what I’ve been testing between DisplayCAL and HCFR, but I may be mixing some things up
HCFR I know tests with raw RGB output, and it measures the same light purplish blue primary (35.5, 61.02, -105.62) like in the srgb sim test, which seems correct since I had to turn the display’s blue output down from 128 to 112, and green from 128 to 117, for RGB greyscale balance before profiling with DisplayCAL.
No:
All done in PCS (D50)
Values in report are PCS, if you wihs to compare readings with HCFR raw readings use HTML absolute and XYZ or xyY.
The no sim test is measuring a truer 255 blue, so that led me to believe it’s testing with the custom profile (with corrected 255 blue) against itself with new measurements, which would be used to check for color drift.
No, custom profile stores native blue. It does not correct blue. It stores “where” is blue 255.
But if it like you say and the no sim measurement is using raw RGB output, and it measures a better raw blue, it’s strange that DisplayCAL calibration and profiling (3 times) is not using that better raw blue output during creation as it is perfectly capable of displaying it.
No. Native blue != sRGB blue.
“measurement report with Sim sRGB” = test how it behaves in photoshop showing sRGB colors.
“measurement report with Sim sRGB as display profile” = test is display with no GPU calibration matches exactly sRGB.
Hence is 255 sRGB blue is out of gamut PS will show closest relative colorimetric…. and the way to show if it is OOG is a 3D plot because 2D plot in report (at the boton) is not showing L*.
I factory reset my display to its default which includes a “6500K” setting and ran a new calibration, profile, and verifications. Same results. (The 6500K setting actually outputs 7000K, more on that at the end)
So if I follow your statements,
no sim=> RGB patches are set raw, in monitor’s colorspace . Then measure & compare to values preticted by ICC
Sounds like in no-sim, the nominal values are the predicted ICC values, and the measured values are the raw display colorspace/output ignoring profile, which can be used to measure drift of the raw output vs the predicted/nominal output according to the documentation.
sim (no sim as display profile) => RGB numbers in sim colorspace are reencoded (I assume) relative colorimetric in display colorspace. Then measure & compare to predicted by sim ICC
And with srgb sim the nominal values are predicted, transformed srgb ICC values using the display’s raw output, and the measured values are still raw display output? Is this correct?
In that case, why are the measured display values different in both tests? Raw measurements should be the same raw measurements no? Regardless of the verification test? If the previous statements are true then only the reference/nominal values should be changing based on test type.
Also for testing’s sake, the nominal 255 blue in srgb sim blue is very close to what Photoshop displays, and not the measured blue. It’s actually a little bit better than both, image attached.
It’s also strange since the display’s factory “6500K” setting actually outputs around 7000K, measured with the visual whitepoint editor (let alone less than great color accuracy out of the box). Both the no sim and srgb sim tests measure 6458K and 6465K respectively. Shouldn’t the raw measurements also show the raw 7000K output?
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.
Measuring Windows srgb applied profile with srgb sim, (apply to display unchecked in DisplayCAL) also results the same as the custom profile verification.
Sorry for the continued questions, I just want to understand the source of the differences and my testing not aligning with what I’m reading/interpretation
