- This topic has 35 replies, 2 voices, and was last updated 3 years, 5 months ago by
.
-
Posts
-
Thank you for your patience Vincent, time for me to digest and implement. Thanks again, no doubt i’ll be back 🙂
Hi Vincent
Me again. So this morning, I’ve just started from fresh and attempted with DUCCS. It’s working fine in terms of actually getting the program to work. But I have a question regarding the white point setting.
When I calibrate to D65 it appears to give a major pink cast to the whites. If I start another fresh and calibrate to ‘Native’ whitepoint, it seems fine.
Are you able to help me understand why D65 would send things in the pink direction? I was under the impression D65 would be the closest to what I deem as ‘white’
Easy => DUCCS does not work well. Check in DispayCAL report “profile whitepoint” vs meassured whitepoint (using proper spectral correction in DisplayCAL).
DUCCS should be able to measure OK (DUCCS profile whitepoint ~ measured wt pt in displaycal). Just happens that DUCCS is not able to gte that white
because DUCCS modifies brightness AFTER fixing white point in LUT. White is fixed at 50% brightness.
White can change if you modify brightness setting. You can even predict it, go to Standrad mode. raise brightnes from 15 to… 40%, plot measured xy coordinates. Find a drift pattern. Set xy coordinates to white in DUCCS compensating for this issue.If DUCCS does not measure OK then measured WT in Displaycal won’t match internal ICC white. It should not happen AFAIK. That’s a point for Dell if you compare Dell or Viewsonic to Benq, LG and their HW cal solutions (these later ones DO NOT measure OK, regardless of other errors or simplifications like this one relative to modifu brightness after calibration).
In the same way DUCCS may be not able to correct grey color cast. Why? just 20 measurements in gamma ramp per channel ~ “fast” calibration in displaycal. It was worse in the past, just 10, solved in v1.6.6 or something like that.
That is another good reason to move to Eizo: grey neutrality is perfect out of the box, hence all these “speed” simplifications made in vendor HW cal solutions work in Eizo because it has little to correct, just grey brightness (gamma).
If monitor vendor cannot say fro sure uncalibrated grey is neutral any of these solutions from Dell, benq, etc may fail to get neutral colorless grey.Just to double check the DisplayCAL setup for verification – should it look like this. I haven’t done anything since calibrating using DUCCS. Open DisplayCAL, load user 3nm correction I downloaded for my monitor. Make sure it says ‘Current’ at the top, then just hit ‘Measurement Report’
Yes, but check on 1st screenshot that Spectral Power Distriution (CCSS) is not from an emulated gamut, “(i)” button. Is not uncommon that people upload wrong CCSS. Gamut triangle should be more or less green AdobeRGB, red P3.
Ah so I assume this is wrong then. In that case that was the only user profile available so which would be the best default one inside DisplayCal to use?
sRGB emulation.
Go to https://colorimetercorrections.displaycal.net/ and check all 3.3nm CCSS for UP2716D or UP2516D, same display tech.
or
My 1st answer in this threadI’ve checked and it didn’t appear any were suitable. So I went with the HP z24 one as you suggested. I’ve attached the results. This is where my technical knowledge lets me down.
From this point, I don’t really know how to read the report and then how to fix it.
“Measured vs. display profile whitepoint ΔE*00” => DUCCS seems to be reading +- OK using “WLED PFS P3 95%” or GB-LED (which are the only ones in DUCCS).
Hence all the issues are caused by program itself as stated in previous messages: wrong whitepoint, color tints in grey…#27099
Ok so I’m not going mad, final question then. Can this now be fixed in DisplayCAL and if so, how – apologies if you’ve already answered this – it’s just taking me a while to get my head round without getting too lost and taking one step at a time.
If it can’t be fixed, I’m going to revert to Reset to Factory Default – then sRGB mode in OSD and load standard windows sRGB ICC into Windows Colour Management (this is what I’ve been doing to date) until I can get my hands on a new monitor.
Can I verify the OSD sRGB Emulation in anyway? Have I already asked this?
The last part of this sentence “White should be “white”. if it is not “white” you can apply a GPU calibration with displayCAL on top of that CALx, white will be corrected on GPU since OSD RGB gains are locked.”
Is this something I have to do manually?
Assuming my whites aren’t white after the DUCCS calibration (they’re not as I’ve shown), what process/settings do I need in DisplayCAL to perform the GPU calibration over the top that doesn’t result in me having to change the OSD RGB gains manually?
Ok so I’m not going mad, final question then. Can this now be fixed in DisplayCAL and if so, how – apologies if you’ve already answered this – it’s just taking me a while to get my head round without getting too lost and taking one step at a time.
Yes, it will correct white & grey on GPU. Banding is expected unless you have an AMD card.
Set white D65, when asked about RGB gains ignore it and clck continue.
Can I verify the OSD sRGB Emulation in anyway? Have I already asked this?
Yes, same for your CALx. Simulation profile “XXXXXXXXX”, “use display profile as display profile”.
Another way to get sRGB is to use saturation controls & HCFR. But grey needs to be corrected on GPU after that.
I think I figured it out by just unticking ‘Interactive Display Adjustment’?
Or ignoring it when popup shows.
