Getting Artefacts when using "Calibrate gamma to sRGB"

[Sandro555Gonzo]

Hi, im new here and already posted on this in the displaycal forum (https://hub.displaycal.net/forums/topic/calibration-of-asus-pg279qm/#post-35376). i put myself into the calibration jungle recently. ;) novideo_srgb is a great software. I try to use it with my ASUS PG279QM. So i created an ICC profile set to sRGB in DisplayCal (Monitor set to widegamut) and loaded that icc in novideo_srgb. im using this profile: PG279QM #1 2022-05-10 21-35 D6504 sRGB F-S XYZLUT+MTX.zip

Unfortunatly my Monitor has 2.3 Gamma from the factory. Therefore i tried to set the gamma in novideo_srgb to: calibrate to sRGB -> but the result is that its too bright an i get artifacts in game in color gradients.: When i deactivate the gamma feature in novideo_srgb i get this (how i should look), but Gamma is 2.3 instead auf 2.2... ;(

What can i do to use novideo_srgb an get perfect 2.2 Gamma as well?

Thank u very much

Sandro

[nicko88]

Are you using the dithering settings? I would try those using SpacialDynamic2x2 which should eliminate banding artifacts.

It doesn't matter what your monitor gamma is by default. After you create a profile with DisplayCAL and load it in novideo_srgb, your gamma should track accurately whatever you choose for the gamma in novideo_srgb.

You will want to turn on Options -> Show advanced options (in DisplayCAL)

These are the settings I use to get great results:

For this screen, I would recommend adjusting your display's whitepoint during the interactive display adjustment at the start. This will mean there will be less adjustment being made in software by the profile in the GPU.

If you don't have the ability to adjust the white point in the display (like a laptop) then choose color temperature 6500 for the whitepoint instead.

Here are the settings I use for the profile, and I use a custom testchart with 256 neurtal patterns, plus R, G, and B primaries.

Here is the testchart you can import:

novideo_srgb_testchart.zip

[ledoge]

I looked at a bunch of test images using your profile, novideo_srgb v3.0 and gamma calibrated to sRGB, however, I was unable to reproduce those artifacts. Do they show up when you take a screenshot and then view that? If so, please upload such an image.

[Sandro555Gonzo]

I looked at a bunch of test images using your profile, novideo_srgb v3.0 and gamma calibrated to sRGB, however, I was unable to reproduce those artifacts. Do they show up when you take a screenshot and then view that? If so, please upload such an image.

Thank you. Here is the screenshot. I even can reproduce this in MS Paint, when switching the gamma calibration feature from novideo_sRGB on and off (using v3.0). using dithering doesnt make any difference.

[aufkrawall]

Did you set black output offset to 0%? I think these artifacts are in the source and bright gamma makes them visible (also without any conversion active by novideo_srgb). Though they are hardly visible to me with gamma 2.2 and 100% black output offset. Also, unclamped colors oversaturation with wide gamut displays seems to cause clipping, which practically turns those blocking artifacts into more banding instead.

[James-F2]

Almost looks like there was an error during XYZ patches measurement or calculation.

Use the recommended settings posted by @nicko88 above.

[ledoge]

I think these artifacts are in the source and bright gamma makes them visible (also without any conversion active by novideo_srgb). Though they are hardly visible to me with gamma 2.2 and 100% black output offset.

I came to the same conclusion. Those blocks have green values of 1 or 2, while the surrounding pixels have 0. Due to how fast sRGB gamma comes out of black (+ potentially also the limited near-black accuracy of novideo_srgb, as the re-gamma LUT doesn't have enough entries to map linear light values to gamma-encoded ones accurately), that tiny green difference turns into a rather noticeable color difference. With 2.2 relative gamma and 100% output offset, it looks fine to me.

[aufkrawall]

I missed the crucial part in the title. :/

I think there is a misunderstanding though, as the issue reporter says he wants to achieve gamma 2.2, but apparently selects the sRGB gamma curve. sRGB gamma curve is not pure power 2.2 curve, it has much steeper rise for dark shades that makes content look ugly that is meant to be viewed in pure power gamma ~2.2 curve (which should apply to web content ~entirely, as almost every monitor is pure power ~2.2 by default). sRGB gamma curve apparently is one of those failed standards that hasn't got picked up in practice (the actual standard for SDR movies is BT.1886 anyway) and thus should be avoided, as per my understanding.

I can see the blocky artifacts too with sRGB and BT.1886 curve, and I can also see them with BT.1886 3D LUT applied via dwm_lut.

[Sandro555Gonzo]

Hi, thank you. I now unterstand that sRGB gamma is not the right way and that these artifacts come from the source. But what should i set to get perfect 2.2 gamma with novideo_sRGB. When i select: calibrate gamma to relative 2.2 with 100% offset the lagom black level test gets to dark. same with "absolute". My main goal ist to compensate my monitors 2.3 factory gamma systemwide. Color accuracy with loading the icc profile in novideo_srgb seams good when i do the verification report in display cal. But gamma is still to low.

[aufkrawall]

I wouldn't pay too much attention to synthetic test pictures that only work with certain display gamma settings such as sRGB curve and rather trust your colorimeter and DisplayCal if there is nothing obviously wrong. You can always verify with 3D LUTs via dwm_lut if you suspect the result with novideo_srgb might not be optimal.

We discussed that one might achieve better gamma accuracy with novideo_srgb when using curves + matrix format ("blackpoint compensation" disabled) in DisplayCal with gamma "as measured" for VCGT and adding more grayscale patches to the profiling color chart instead. But chances are your results are already quite good. It is just the normal trade-off with LCD displays to trade near-black clipping against elevated near-blacks that destory average scene contrast ratio. Just configure what you think looks best for a given content (this would be the very short answer).

[Sandro555Gonzo]

Ok, thanks. im still confused why the black level test looks like this when "calibrate gamma to 2.2" is checked in novideo_srgb:

And when i uncheck it i get this:

In displaycal i used these settings:

When i load that profile into novideo_srgb and check "calibrate gamma to 2.2" i get this verification report: Measurement Report.zip

thanks

[aufkrawall]

Valid question, I think also your gamma curve deviations in your measurement report are way too much off. Do your photographs represent well what you see? I find the sudden difference between the 3rd and the 4th dark gray patch without novideo_srgb calibration a bit too weird.

Can you try 3D LUT in dwm_lut with calibration speed set to medium and XYZ + matrix profile? You can also run a verification report with this like with novideo_srgb: https://github.com/ledoge/dwm_lut

[Sandro555Gonzo]

Valid question, I think also your gamma curve deviations in your measurement report are way too much off. Do your photographs represent well what you see? I find the sudden difference between the 3rd and the 4th dark gray patch without novideo_srgb calibration a bit too weird.

Can you try 3D LUT in dwm_lut with calibration speed set to medium and XYZ + matrix profile? You can also run a verification report with this like with novideo_srgb: https://github.com/ledoge/dwm_lut

what settings should i use creating the 3D LUT?

[Sandro555Gonzo]

i tried somethin else as well: i set the black output offset to 50 % and now i get this gamma curve: Is that a legit method? or is anthing else fucked up then. Measurement report looks likes this now: Measurement Report 2.zip

Thanks!

[erusapien]

how is OP? have you found a way to fix the artifact? Im getting it too.