- This topic has 3 replies, 2 voices, and was last updated 5 years, 5 months ago by
.
-
Posts
-
Given most Mac displays (mine iMac 27″ 2013) have no RGB gain controls, I noticed that the measured luminance is less by 10-15% from the desired white level set in “Calibration->White Level”, reason explained here by dev.
Aside from offsetting the desired white level to account for this, any other tips to deal with this ?
In the case where I set 90cd/m2, the measured is 76 cd/m2.
Aside from offsetting the desired white level to account for this, any other tips to deal with this ?
No, but you may guess an aproximate value about how much cd/m2 do you need to configure your screen over your desired target.
–Some LED screens do not vary too much WP xy coords with OSD brightness control changes. Use DisplayCAL, calibrate WP using GPU LUT as you did, then turn up brigtness control until you get what you want (tools, calibrated screen report or using ArgyllCMS console readings), then verify if WP xy /dE variation is acceptable.
-Do a fast calibration (low number of grey patches) with the simplest profile. See the change in luminance, calculate inverse ratio from starting luminance and do the actual calibration with your desired grey accuracy (speed) and profile type.
-Maybe it is possible to guess the brightness drop from XYZ readings of native R, G and B since there must be a linear combination of native RGB numbers (native gamma encoded) that get you close to your desired xy target at some (the highest possible) Y’ value => This is what calibration compute, the 0..255 LUT output for 255 input in VCGT.
Maybe it would be very easy to compute those “gains” linear gamma encoded for the highest possible Y’, measure in a very fast way aproximate native (per channel?) gamma value and try to find the “step error” caused because VCGT output for 255 input is native gamma encoded.
With native white Y and this estimation for Y’, get the inverse ratio and proceed as explained above (a 2nd check may be needed if WP drifts with changes in brightness OSD control).I have not do the maths but this feature would be a great update to DisplayCAL (but maybe it should be an ArgyllCMS functionality, maybe part of some existing ArgyllCMS app).
“If RGB gains control is not present in OSD or it is locked in your setup, you should set brightness to XXX cd/m2 to get your desired luminance”.
AFAIK propietary/rival solutions do not offer this feature.…
..then verify if WP xy /dE variation is acceptable.
-Do a fast calibration (low number of grey patches) with the simplest profile. See the change in luminance, calculate inverse ratio from starting luminance and do the actual calibration with your desired grey accuracy (speed) and profile type.
Thank you for your reply 🙂 Not sure I follow how to verify if WP xy/dE variation is acceptable. It is what it will be, no ?
I are trying to digest if you are proposing a different method than what I discovered and did, basically increase the desired WP so I end up with a measured WP that matches my goal.
As to your feature suggestion, that sounds like a good idea, but it all depends on the dev and the target market.
PS: sorry, I am complete noob and your color theory is lost on me, but one day I may brush up on it !
–Some LED screens do not vary too much WP xy coords with OSD brightness control changes. Use DisplayCAL, calibrate WP using GPU LUT as you did, then turn up brigtness control until you get what you want (tools, calibrated screen report or using ArgyllCMS console readings), then verify if WP xy /dE variation is acceptable.
Thank you for your reply
Not sure I follow how to verify if WP xy/dE variation is acceptable. It is what it will be, no ?What it put is a basic laptop (with good display) for everyday use appoach:
Calibrate without worrying too much about luminance, set target luminance as native/as measured because you do not care.
Once you get your calibration & profile track how much it drifts as OSD brightness goes up/down (measure against your xy WP target).
If drift is low (<X dE), congratulations: once calibrated use it with whetever OSD brightness value you need since it seems to be stable (based on your own X dE margin)iMacs are like big not moveable laptops in every sense, including screen. It may be worth testing.
I are trying to digest if you are proposing a different method than what I discovered and did, basically increase the desired WP so I end up with a measured WP that matches my goal.
What you did is like my 2nd one but with an intuitive approach (guessing & setting +15% for example) instead doing a previous calibration in order to “do not guess” how much extra luminace you need.
And your approach is a good one too for native WLEDs vs D65, they are close in more or less well behaved screens.
I would even say that yours (guessing a default +15% for example) is a much better one than mine unless you work with some 3rd party and have an agreement to work in a set of particular conditions at “X” whitepoint and “Y” luminance with tiny tolerance margins.
In that particular situation you may want to “guess less” or to have an screen with low whitepoint drift with brightness OSD control variations… or to do not use “locked” WP screens like Macs & laptops.
