- This topic has 29 replies, 4 voices, and was last updated 9 years ago by
.
-
Posts
-
It works in fullscreen exclusive mode only when using the -nogammaramp option in Dota 2. The game starts with the gamma reset, but DisplayCAL is able to override it. Without the -nogammaramp option DisplayCAL cannot override it.
I have another problem now. When I use DisplayCAL to load the profile, the blacks are crushed and it’s darker than usual. I can see every black square and every white square on this page when using the Windows calibration, but the same profile in DisplayCAL crushes the last black square to fully black. I am also able to see weird black patches in images when using DisplayCAL.
Don’t use these test images, they are ill-conceived. A square with RGB 2, 2, 2 in sRGB color space has a relative luminance of 0.06 (on a scale from 0 to 100). Now you add in the black level of the display, and the difference becomes imperceptible. It is not supposed to be visible in a typical viewing situation. If you want to view something with such a low relative luminance against a black background, you need to view it in isolation in a dimmed room.
Don’t use these test images, they are ill-conceived. A square with RGB 2, 2, 2 in sRGB color space has a relative luminance of 0.06 (on a scale from 0 to 100). Now you add in the black level of the display, and the difference becomes imperceptible. It is not supposed to be visible in a typical viewing situation. If you want to view something with such a low relative luminance against a black background, you need to view it in isolation in a dimmed room.
Yes, with the Windows calibration I am only able to see the 2,2,2 square when looking at the monitor from a steep angle so that the TN panel gamma shift makes it visible. It is not visible head-on. When creating the profile I adjusted the gamma slider one notch at a time until the 2,2,2 square just abruptly lit up from being completely black at an extreme viewing angle. However with DisplayCAL it is perfectly black even at an extreme viewing angle, and I presume crushed to 0,0,0. The point is there is a non-negligible difference when loading the same profile using DisplayCAL.
How do you view the image? In a color-managed browser (i.e. Firefox with gfx.color_management.enablev4 true and gfx.color_management.mode 1)?
The point is there is a non-negligible difference when loading the same profile using DisplayCAL.
Which profile compared to what?
How do you view the image? In a color-managed browser (i.e. Firefox with gfx.color_management.enablev4 true and gfx.color_management.mode 1)?
Yes, exactly those settings in Firefox. I believe other browsers should work fine too for that page since it’s an untagged image and the display profile is based on sRGB.
Which profile compared to what?
The one you modified for me. I deleted the Windows’ generated one and replaced it with your modified profile. So I can use the same profile either with Windows calibration or with DisplayCAL. I’m comparing the visibility of the 2,2,2 square when using Windows calibration vs DispalyCAL, for the same profile.
I originally created the profile by adjusting the slider until the 2,2,2 and 254,254,254 squares just popped into visibility when looking at the TN panel at an extreme angle. The 2,2,2 square is visible when using Windows calibration, but not when loading the same profile with DisplayCAL.
The 2,2,2 square is visible when using Windows calibration, but not when loading the same profile with DisplayCAL.
Probably a difference in quantization. DisplayCAL quantizes vcgt to 16 bits using rounding, Windows quantizes to 8 bits and scales wrongly (max value 254 instead of 255). The accurate value for RGB 2,2,2 after the 1.28 gamma expansion applied by the calibration is 0.5126, which can either be truncated to 0 or rounded to 1. It seems the graphics driver just truncates the 16-bit value to 8-bit zero instead of using rounding. I stand by what I said though, this RGB being visible or not is insignificant (RGB 1,1,1 would have a relative luminance of 0.0003, RGB 0.5126,0.5126,0.5126 would have a relative luminance of 0.00016 in sRGB).
Lots of people on other forums are having this same issue of the gamma resetting in the Creators Update. It would helpful if DisplayCAL could parse the Windows generated profiles directly without conversion.
Thank you for this thread and the great software. I recently purchased a Dell S2417DH with disappointing color representation even for a recreational TN display but was able to calibrate it with DisplayCAL and an Eizo EX-3 (Spyder5 equivalent). I’m more than pleased with the result even though it seems like a significant amount of contrast was lost when trying to adjust the whitepoint to 6500k via OSD, but that’s a price I am willing to pay.
Using a Nvidia GTX1060 with latest drivers and the latest Windows 10 Creators update, I had to use
profile_loader.buggy_video_drivers = nvidiato make profiles work with 3D Fullscreen apps like games. It now seems to apply the desired profile within seconds of launching or quitting a game.
I too have noticed that profiles loaded via DisplayCAL Profile Loader seem to crush blacks ever so slightly but I lack the expertise to figure out what is at fault there — Windows, the Graphics Driver, my Calibration, the DisplayCAL loader or any other component.
I too have noticed that profiles loaded via DisplayCAL Profile Loader seem to crush blacks ever so slightly but I lack the expertise to figure out what is at fault there
I don’t see any indication for fault here. You can usually trust Argyll’s calibration result.
Can you add support for the Windows generated profiles without having to convert them? I just updated to Windows 10 Redstone 3 and the profile reloading issue is still not fixed. It looks like we will be dependent on DisplayCal Profile Loader for a long time.
What does the “profile_loader.buggy_video_drivers” do exactly? Should it really be required for NVIDIA?
It works around a bug where reloading a calibration would not actually update the values in the videoLUT, by first loading a slightly altered calibration. And yes, if you’re using the Creators Update with recent NVIDIA drivers, this is needed.
