- This topic has 12 replies, 3 voices, and was last updated 3 years, 5 months ago by
.
-
Posts
-
Hello,
I’m using Displaycal with the Spyder X and I have an LG 32uk550-B. It’s a 4k 60hz monitor with freesync and VA panel. (WLed panel settings into DisplayCal)
I have 95 dci-p3 coverage on my display and I can also select “rec709” mode into its settings menu if needed. With the normal mode I can change RGB value where in Rec709 preset i can only change screen brightness, nothing more.
BTW, what’s the right calibration settings for both screen profile?
I want to stay in the srgb range accuracy, so no problem if I have to lock the monitor in rec709 mode and use less color gamut.
This monitor is connected via Dp cable and AMD rx580 gpu, it works as Rgb Full Range 10bit.
I usually set this Rec709 profile on the monitor, then into displaycal I activate white and black drift, rgb 0-255. White point at 6500K/6504 and 85cd (the best for me, eye stress and the ambient light), gamma 2.2 and I do not touch anything else. I create xyz LUT. I can get pretty good accuracy around 98% SRGB. If I use the same calibration settings, but using the full color range on the monitor itself, I tweak the RGB for the white point and I can get 100% srgb accuracy, but it’s bad to have more color coverage on not color managed application.
Am I doing it right? Can you send a screenshot of the right settings for me? Thank you
SpyderX Pro on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.As you may have read since it’s a veeeeeeeeeeery common topic:
-Spyders are not accurate. Consider an i1d3 colorimeter from Xrite. “Pro” if you plan to have a display with HW calibration or make profiles with vey high number of patches, “Studio” otherwise and you need to save money.
-If your display is 95% P3 it is not White led (LED sRGB common display) … it’s something else like “W-LED PFS”: Phosphors change and you get that extra color space. Try with that.
-in locked OSD modes just let DisplayCAL correct white in GPU (ignore that popup says “White if off in XXX color bar”). Your AMD card should give you bandless calibration and if native white at that OSD preset and target white are not too close you should not loose too many unique grey levels.
-no drift. It’s a LED VA/IPS.
The display coverage suggest its needs PFS Phosphor WLED correction. The Rec709 mode comes with some more drawbacks in that the backlight correction wont be valid anymore so your whites might be off if profiled that way. Check if your measured contrast ratio roughly matches the specs, Spyders are known to be inaccurate near black. EDIT:Ninja’d by Vincent.
Yes, sorry. It was WLED PFS in fact. So it’s better to lock the monitor setting to REC 709 as expected.
A quick recap..“REC 709” Monitor
WLED PFSWHITE POINT 6500/6504K
WHITEPOINT LEVEL “native”
BLACK LEVEL “native”
On the RGB screen when calibration start I ignore it and set the screen brightness according to what I need (85cd reading), right?
GAMMA 2.2 (but I can’t select the gamma mode with REC 709 enabled in my monitor, don’t know what’s the default inside)Black and White Drift enabled?
Black Correction untouched or auto/100%?As you may have read since it’s a veeeeeeeeeeery common topic:
-Spyders are not accurate. Consider an i1d3 colorimeter from Xrite. “Pro” if you plan to have a display with HW calibration or make profiles with vey high number of patches, “Studio” otherwise and you need to save money.
-If your display is 95% P3 it is not White led (LED sRGB common display) … it’s something else like “W-LED PFS”: Phosphors change and you get that extra color space. Try with that.
-in locked OSD modes just let DisplayCAL correct white in GPU (ignore that popup says “White if off in XXX color bar”). Your AMD card should give you bandless calibration and if native white at that OSD preset and target white are not too close you should not loose too many unique grey levels.
-no drift. It’s a LED VA/IPS.
I know also Spyder X is not perfect, I don’t need pro result, just a good color balance compared to defaults.
I’m attaching the export of calibration and tone response after the slow calibration with the settings above. Please let me know if is needed anything else to verify a good calibration result.
I’m attaching the export of calibration and tone response after the slow calibration with the settings above. Please let me know if is needed anything else to verify a good calibration result.
By the way DeltaE it’s around 5 near blacks, when I remember it was everything fine when checking calibration via measurement report in the past. Something is strange now, without the Drift settings.
I was doing the wrong verification check. Now its all green “ok”. By doing a calibration for rec 709 D65 and gamma 2.4 I can see it’s very similar in performance and delta if compared to REC 709 or SRGB (with different gamma) then. Don’t know what are the practival differencies by the way considering it’s fine with both format after verification as deltaE average and 6500K target whitepoint. I’ll do more profile with different settings, no drift and slower process to be more accurate. I’ll post here the results for your verification then 🙂 thank you.
As you may have read since it’s a veeeeeeeeeeery common topic:
-Spyders are not accurate. Consider an i1d3 colorimeter from Xrite. “Pro” if you plan to have a display with HW calibration or make profiles with vey high number of patches, “Studio” otherwise and you need to save money.
-If your display is 95% P3 it is not White led (LED sRGB common display) … it’s something else like “W-LED PFS”: Phosphors change and you get that extra color space. Try with that.
-in locked OSD modes just let DisplayCAL correct white in GPU (ignore that popup says “White if off in XXX color bar”). Your AMD card should give you bandless calibration and if native white at that OSD preset and target white are not too close you should not loose too many unique grey levels.
-no drift. It’s a LED VA/IPS.
Well, I’ve done all my test and calibration. I’ve ocked my monitor osd settings to REC 709 and did one calibration for REC 709 curve and another for gamma 2.2 curve (srgb).
Here’s the main settings:
-1st page
WLED PFS
no drift
RGB 0-255 (result were worse on the black at deltaE with 16-255)
-2nd page
White Point 6504K – daylight
White Point Level 85 cd
Tone Curve: gamma 2.2 + black compensation 100% (for SRGB) and REC 709 curve (for REC 709 calibration) < this is the only difference between the 2 calibrations
Calibration: Low speedI’ve create also the x+y+z 3D lut + matrix and Large testchart for every preset.
I attach files for both of the verification, results seems very good on both with very low Delta by using Gamma 2.2 during calibration.
I’ve also verified cross settings, I mean:
REC 709 tone curve profile with REC 709 target and REC 709 with SRGB target profile.
SRGB gamma 2.2 tone curve profile with REC 709 and SRGB target profile.
The lower overall deltaE seems to be on the SRGB gamma 2.2 whilte targeting REC 709 profile.
I can say btw that REC 709 with gamma 2.4 has more “open” blacks”.. I mean with gamma 2.2 blacks seems more crushed but similar to other devices with srgb profile active.Contrast is around 3000:1 when using gamma 2.4 and around 2000:1 when using 2.2 curve calibration. (display official specs says 3000:1 static contrast)
For better accuracy is better to work with SRGB 2.2 profile for me?
Thank youDo not use Rec709 TRC. It is not what you think it is, just look at TRC. Use 2.2 or (for video in a not color managed app on a sRGB display or sRGB preset) 2.4
So the preset with 6504K and GAMMA 2.2 tone curve is the right choice? Files is attached in the post before (the first on the list). 🙂
Is it working also for gaming and other 3d application? Have to use another software for overal profile usage?Calibration (GPU caibration) only fixes white point and grey (grey color & gamma). That’s all. If you want full gamut correction/simulation to something else you cannot do it in GPU LUT ( ~ “traditional” calibration).
Some apps may clean GPU LUT caibration. Old games did because they use GPU LUT for their gamma setting, this way of doing things should be avoided in newer ones… but who knows. DisplayCAL tries to reload VCGT tag data in ICC into GPU LUT every X secs.
