- This topic has 83 replies, 4 voices, and was last updated 6 months, 1 week ago by
.
-
Posts
-
Check if stored WP+CHAD is different (WTPT). For example one storing PCS white always and then CHAD to actual white while the other storing actual white. Maybe current macOS does not like one of those combinations.
Report to benq + attach them the two profiles + macoS version
Since I have to post something here not to be removed from the forum, here’s my verification report.
Since I have to post something here not to be removed from the forum, here’s my verification report.
Why is failing now to achieve desired whitepoint? Is it reproducible between 2 consecutuive calibrations? Did you try to add an xy offset to target whitepoint?
Is almost negible, but it has started to behave a little weirdor…. is it a verification made now for a previous calibration?
(show statistics in HTML) “Measured vs. display profile whitepoint ΔE*00 = 1.62”
That would mean some kind of drift in WP several days after calibration due to poor panel behavior or just maybe because you measured after powering on (that would be expected display & measurement device behavior).Since I have to post something here not to be removed from the forum, here’s my verification report.
Why is failing now to achieve desired whitepoint? Is it reproducible between 2 consecutuive calibrations? Did you try to add an xy offset to target whitepoint?
Is almost negible, but it has started to behave a little weirdor…. is it a verification made now for a previous calibration?
(show statistics in HTML) “Measured vs. display profile whitepoint ΔE*00 = 1.62”
That would mean some kind of drift in WP several days after calibration due to poor panel behavior or just maybe because you measured after powering on (that would be expected display & measurement device behavior).I’m not OP.
But on the same subject, maybe I could use the new feature of PMU to adjust the colors before calibration to achieve better WP? Just need to know which way to adjust them.
I’m not OP.
But on the same subject, maybe I could use the new feature of PMU to adjust the colors before calibration to achieve better WP? Just need to know which way to adjust them.
The point of PMU is that you need to do nothing (excluding “enhanced gamma calibration” if your unit showed poor grey range on previous PME versions). Since it has PFS EDR it should be able to measure your SW240 properly.
Anyway, if you are not OP, apply 2nd one:
or…. is it a verification made now for a previous calibration?
(show statistics in HTML) “Measured vs. display profile whitepoint ΔE*00 = 1.62”
That would mean some kind of drift in WP several days after calibration due to poor panel behavior or just maybe because you measured after powering on (that would be expected display & measurement device behavior).Since profile WP and measure WP have a significative drift and profile WP is not a standrad generic one but a WP measured after calibration.
So:
you may have modified some settings (like brightness, some monitors drift WP as you change brightness setting)
or calibration ages soon (VERY SOON, SW240_Cal2_L120_D65_Native_G220_K0_20230811)
or it is not applying the same EDR (are you using PMU?)
Anyway, if you are not OP, apply 2nd one:
or…. is it a verification made now for a previous calibration?
(show statistics in HTML) “Measured vs. display profile whitepoint ΔE*00 = 1.62”
That would mean some kind of drift in WP several days after calibration due to poor panel behavior or just maybe because you measured after powering on (that would be expected display & measurement device behavior).Since profile WP and measure WP have a significative drift and profile WP is not a standrad generic one but a WP measured after calibration.
So:
you may have modified some settings (like brightness, some monitors drift WP as you change brightness setting)
or calibration ages soon (VERY SOON, SW240_Cal2_L120_D65_Native_G220_K0_20230811)
or it is not applying the same EDR (are you using PMU?)
I didn’t change any settings.
The verification was made the next day to the calibration and profiling made with PMU.
I made another calibration with PMU to different specifications and verified with displayCAL (attached). The results are similar.
And the validation report from PMU.
Maybe PMU measures differently despite using the same EDR?
Maybe PMU measures differently despite using the same EDR?
No, it is measuring properly (display profile WP vs measured WP vs assumed WP) … its just failing to achieve desired WP target, although by an small margin.
It happens with other HW cal software from other low cost vendors like Benq (Dell, LG, MSI…).
A typical scenario is a low cost monitor with a high drift in WP as backlight brightness changes. For example, let’s assume an extreme scenario where a display at 0% OSD is ~40nits (a* +10) and 50% OSD brightness is 250 nit (a* 0 , our reference) and at 100% OSD is 400 nit (a* -10). In this example you can see a 20 a* axis (green -pink) variation across all OSD brightness setting. Changing brightness will also change white color to pink-green.
Some of these vendor HW cal apps calibrate to some default OSD brightness, write LUT info to monitor and then try to fix brightness to calibration target because this way its jobs is simpler. If you had bad luck with panel QC, if WP drifts too much with OSD brightness setting this may introduce some mild to severe mismatch between WP target and the WP you get.
i1d3 Device + SDK +EDR is measuring the actual CIE xyY coords… but calibration app is unable to aim properly due to some oversimplification in calibration process. It works with a highly idealized behavior, but on real low QC low cost monitors it may fail by some margin. It’s a close situation with grey range issues before PMU wich are also present in other low cost manufacturers HW cal solutions.IDNK if PMU suffers from that on your particular unit. If you are suffering from this the solution is simple, apply a mild xy offset (opposite sign of what you got) to target WP.
Calibrite Display Pro HL on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.Did you actually aim for 200:1 contrast on latest calibration or is it another issue with PME/PMU?
Maybe PMU measures differently despite using the same EDR?
No, it is measuring properly (display profile WP vs measured WP vs assumed WP) … its just failing to achieve desired WP target, although by an small margin.
It happens with other HW cal software from other low cost vendors like Benq (Dell, LG, MSI…).
A typical scenario is a low cost monitor with a high drift in WP as backlight brightness changes. For example, let’s assume an extreme scenario where a display at 0% OSD is ~40nits (a* +10) and 50% OSD brightness is 250 nit (a* 0 , our reference) and at 100% OSD is 400 nit (a* -10). In this example you can see a 20 a* axis (green -pink) variation across all OSD brightness setting. Changing brightness will also change white color to pink-green.
Some of these vendor HW cal apps calibrate to some default OSD brightness, write LUT info to monitor and then try to fix brightness to calibration target because this way its jobs is simpler. If you had bad luck with panel QC, if WP drifts too much with OSD brightness setting this may introduce some mild to severe mismatch between WP target and the WP you get.
i1d3 Device + SDK +EDR is measuring the actual CIE xyY coords… but calibration app is unable to aim properly due to some oversimplification in calibration process. It works with a highly idealized behavior, but on real low QC low cost monitors it may fail by some margin. It’s a close situation with grey range issues before PMU wich are also present in other low cost manufacturers HW cal solutions.IDNK if PMU suffers from that on your particular unit. If you are suffering from this the solution is simple, apply a mild xy offset (opposite sign of what you got) to target WP.
I’ll have to try that offset later, thanks. I calibrated again yesterday and now the assumed WP vs measured WP deltaE00 was smaller, i.e. 1.25. I verified right after the calibration.
I guess the WP brightness problem sort of explains why the brightness/contrast settings are unavailable in calibrated screen modes in my monitor.
Did you actually aim for 200:1 contrast on latest calibration or is it another issue with PME/PMU?
Yes, I aimed for that by setting a 80 to 0.4 target in PMU for softproofing purposes.
Hmm, but the white balance has very little difference in K … Maybe it’s because it shines in a slightly different color, hence so much delta?
My SW240 monitor does not have these problems, it is as faithful as Eizo. However, I know that it’s a lottery and you can get different results…
Did you actually aim for 200:1 contrast on latest calibration or is it another issue with PME/PMU?
Yes, I aimed for that by setting a 80 to 0.4 target in PMU for softproofing purposes.
Why not using actual L* of printer profile + actual L* (700-1000:1 contrast) of monitor?
DisplayCAL & ColorNavigator can store actual L* of black. CN7 by default RGB0 L*=0 but can be configured to store actual L* of black.
Dell stores actual black on table (3d mesh) profile, ideal black on matrix profile. MSI & LG did the same (matrix), at least in past versions.
Default setting in PMU seems to behave the same, BPC, fake infinite contrast. Check if there is some configuration to store actual TRC in black.I guess the WP brightness problem sort of explains why the brightness/contrast settings are unavailable in calibrated screen modes in my monitor.
You can test WP variation with OSD brightness in User/Custom color, the one with manual RGB gains. Measure xyY at 10 or 20% step.
Also you can check if PMU stores some kind of lohg, ask @nick234 if he found something. Other vendors like Dell had extensive text log of HW cal process where people could find the source of innacuracies => excesive idealiztion of the process runing on low cost displays statistically not ideal by far.
Hmm, but the white balance has very little difference in K … Maybe it’s because it shines in a slightly different color, hence so much delta?
CCT (kelvin) ~ b* axis (yellow-blue).
CCT has no info about a* axis (pink -green) whats why we look at “assumed vs measured” test in DisplayCAL report.Anyway, a small offset in calibration target (may be different for each luminance target!) should do the job
Vincent, I can’t find anything now because I’m away from the office. If you or someone else wants to check the information in the ICC profile, I can share the profile. I think I already have a method for trimming the animation. SpectraView II only saves profiles in version 2. This version of the default profiles is probably also on the Mac. ColorNavigator 7 has selection options, and Palette Master Ultimate does too. So I have to change the profile version from 4 to 2 in PMU and check the effects.
Vincent, I can’t find anything now because I’m away from the office. If you or someone else wants to check the information in the ICC profile, I can share the profile. I think I already have a method for trimming the animation. SpectraView II only saves profiles in version 2. This version of the default profiles is probably also on the Mac. ColorNavigator 7 has selection options, and Palette Master Ultimate does too. So I have to change the profile version from 4 to 2 in PMU and check the effects.
It is not ICCv2 vs ICC v4. It’s about storing the actual L* of black in ICC profile.
Argyll is ICC v2 and you can choose to store actual black luminance or put a fake infinite contrast (BPC). CN7 can do the same. Dell uses BPC in matrix profiles and I’d say that actual black on “table” type but I do not remember that behaviopr, same for LG & MSI.
Benq PMU at default setting uses BPC, so it does not store it
In your report profile black is L*=0. PMU may have matrix profiles w or w/o BPC. IDNK if current macOS desktop color management will work with table profiles from Xrite or PMU.
