- This topic has 134 replies, 21 voices, and was last updated 1 week, 2 days ago by
.
-
Posts
-
Is there a way that the clamp can be applied only in SDR mode and disabled in HDR. It is the only thing stopping me using what could be an extremely useful piece of software.
I don’t have access to a monitor that supports HDR at the moment, so it’s kinda hard for me to add proper support for something like that. I can give it a shot (but can’t guarantee that it’ll work properly and reliably).
I’ve had one user report that when enabling HDR in Windows, novideo_srgb would then show the clamp as being enabled even though it was disabled previously. IIRC that might have been caused by/related to the Night Light feature in Windows? I’d appreciate it if you could try to reproduce that, so I can get a better idea of how I have to handle HDR.
I tried it and it does clamp even in HDR. I noticed that the colours change when i enable/disable.
My monitor has 92% P3 coverage. I expected things to look roughly the same under these conditions:
1. I set my OS display profile to my DisplayCal profile and disable novideo_srgb.
2. I set my OS display profile to a synthetic Display P3 profile, novideo_srgbs enabled with target set to Display P3.
But #2 looks more saturated to me subjectively. I can accept that #1 should be more accurate but I’m looking for an explanation to why #2 looks different.
Thanks for the latest update. The new default icon is great and the About button is a nice edition to help me keep track of revisions.
1. I set my OS display profile to my DisplayCal profile and disable novideo_srgb.
This means that the VCGT calibration curves from the ICC profile will be loaded into your GPU, which fixes white point/gramma/grayscale to the tone curve you chose when calibrating (or, if you chose “As measured”, nothing happens). Other than that, setting a profile in Windows just means that when applications ask for a profile to perform color management with, that’s the one they’ll get. But everything is still oversaturated, with the exception of applications that take care of color management themselves.
When you do a measurement report with your monitor’s ICC profile selected, DisplayCAL uses the information from the ICC profile to transform the patch values before sending them to the display, so those values are “color managed”. This means that the measurement report is not representative of what anything non-color managed looks like.
So #2 should look similar to #1 in color managed applications only.
That helps confirm my basic assumptions.
I hope this isn’t taken as a critique of the app, it’s most likely working as expected.An unrelated side note, I prefer the look of the left display transformed to sRGB vs. the right display transformed to sRGB. The reason is the left side is looks less saturated which is paradoxical according to the verification report .
Before sRGB
After sRGB
I wonder if it’s an common experience for this type of color transformation or if my eyes are the outlier?
I’m testing your tool in my laptop and an external display. It seems to work pretty well! At first I was going to follow the recommendations:
Tone curve: As measured
Profile type: Curves + Matrix
Black point compensation: Disabled
Custom testchart with a high number of grayscale patchesBut I didn’t figure how to add the custom testchart with grayscales patches, and the default is only 34 patches (when I move the slider, it changes again to XYZ LUT + Matrix). So I ended up using the default “sRGB” DisplayCAL preset but with 800 patches. To verify the calibration, I used the following configuration:
The results seems to be quite good, passing the recommended tolerance in both display devices. I can try to improve the results if you can explain me better how to set the custom testchart. Also, I would like to ask if you have any advice and if I’m doing the verification properly. Thanks for the software, it seems very useful and it has some advantages over other methods!
Those verification settings are almost correct. You should have the profile you created selected under the “Settings” dropdown at the top, so that the right tone curve including the black point of your display can be calculated (unless your display is e.g. OLED and has perfect blacks). If you used sRGB gamma in novideo_srgb, select “Apply black output offset”, otherwise use the bottom option and set that to the same values as you used in novideo_srgb.
For creating a custom testchart: Select “Default testchart” in the testchart dropdown, then click the square icon next to it to open the testchart editor. In there, set Neutral patches to a high value (256 seems to work well, but I’m not sure if this could lead to overfitting), Create testchart, Save as…, and then make sure it’s selected.
If you want, you can see if you can maybe get even lower errors by doing a grayscale calibration, by setting Tone curve to anything other than As measured (preferably the same option as you’ll then select in novideo_srgb). If your display is well-behaved, the results should be about the same though.
I’m trying the Curves + matrix profile without Black point compensation and with a custom testchart with 256 Neutral patches. I also selected the settings that you mentioned on the Verification tab. The result seems to be slightly better, but almost the same. Since you said on the readme that “a grayscale calibration should be unnecessary and might even be detrimental to the accuracy”, I tried to avoid it, but then I realized that the whitepoint was not calibrated (since I’m on a laptop right now) :^) so I did it with the sRGB tone curve (because I’m calibrating to sRGB). I’m quite happy with the results so far! This tool is so handy, it really seems to be underrated.
Hi there,
I have the LG 32UN650 which is a 95% DCI-P3 monitor but which doesn’t come with an sRGB mode. I am using novideo sRGB with the ICC profile installed.
I noticed that with novideo sRGB enabled, my color gamut coverage drops from 99.8% sRGB to 90.88% sRGB, and gamut volume drops from 143% to 91%. Is there any way to make this as close to 100% as possible?
I noticed that with novideo sRGB enabled, my color gamut coverage drops from 99.8% sRGB to 90.88% sRGB, and gamut volume drops from 143% to 91%. Is there any way to make this as close to 100% as possible?
That sounds weird… Maybe something is wrong while doing the verification? Are you using the same colorimeter correction for profiling and verification? Maybe it can help if you can attach here both the ICC profile and a verification file of that profile.
Thanks! I figured it out. My initial calibration used Generic instead of Phosphorus WLED and when I applied the ICC profile to novideo it affected the gamut coverage. I redid the calibration and now I’m getting about 98% or 99%.
I noticed that when clamping to sRGB using EDID, I get sRGB of about 99%+ whereas it drops to about 97 to 98% when clamping using an ICC profile. Is this unavoidable due to the nature of calibration?
I noticed that when clamping to sRGB using EDID, I get sRGB of about 99%+ whereas it drops to about 97 to 98% when clamping using an ICC profile. Is this unavoidable due to the nature of calibration?
I believe calibrating to a whitepoint different than the native of the display (for example, D65) can affect the gamut coverage. I don’t think 97% of coverage is going to be an issue, though.
A great utility, thanks! I was wondering, though – any plans of adding some kind of command line control? I have to switch back and forth quite frequently because of the non-ideal HDR implementation on my monitor (and the fact the clamp affects HDR mode, which already has correct colors by default, so it just desaturates it further) and I thought it would be great if the switching could be automated in some way by writing a script, a batch file, macro or something like that. Cheers.
Just updated from a really outdated version that didn’t have any options to v3.0 (v3.1 refuses to launch on my system for some reason). Man, this tool is so cool!
I wonder whether there are any downsides to using dithering? Is there any place I can read about the difference between all these options? I’ve read the README.md on GitHub, but it’s not very detailed. I figured I should match my display bit depth (8-bit in my case) cause both 6-bit and 10-bit gave me even worse results than no dithering at all.
