- This topic has 23 replies, 3 voices, and was last updated 6 years, 11 months ago by
.
-
Posts
-
- Offline
and the only way to set it system-wide for colord is to go into the GNOME color control panel and click “set for all users”.
ya it took me a while to figure that out but i’m glad you confirmed it. that means i’m not crazy 😉
i’ve done several uncalibrated-reports on the current out of the box OSD profiles from the ASUS PA-24-AC and have a few questions regarding them.
first. i’ll mention that all the OSD “modes” seem to prefer gamma 2.2 with 6500k white point with a 50% white level and 50% black level. currently only the “Scenery mode” is set by default to 100% white level and “Darkroom mode” seems to prefer 0% white level by default. only the “Reading mode” is a little different – 9% white level with 5000K white point locked(greyed out).
second. i choose the “Darkroom mode” OSD preset to set my target measurements from displayCAL since that has ALL the individual parameters open (the rest have ALL or SOME locked). what is the best way to do target-measuring ? leave black-level and gamma set to 2.2 (as is set by default in the OSD after reset) and only change brightness and individual RGB gains ? or is it better to only change the CMY gains through the OSD ?
third. i attached my current displayCAL profile together with the self-check-report and the rest of them for comparison. is it normal that the contrast ratio is so low after calibration/profiling and the black-point is so high compared to the uncalibrated-report ? what can i do to make it closer to the 1000:1 native and lower black level ?
fourth. with the amdgpu-pro-install driver for the radeon pro wx 8200 some of the reports show:
dispcal: Warning – new_dispwin: Expected VideoLUT depth 8 doesn’t match ↲
↳ actual 10what does this mean ?
Effective Video LUT entry depth seems to be 10 bits
but some others say it’s 11 bits or 12 bits. the icc profile info shows that vcgt is 16 bit-depth.
i know the ASUS PA-24-AC monitor panel uses real 8-bit with no FRC +or- .
what do these numbers corelate to ?
i hope i explained myself well enough if not i’ll try again.
Effective Video LUT entry depth seems to be 10 bits
but some others say it’s 11 bits or 12 bits. the icc profile info shows that vcgt is 16 bit-depth.
i know the ASUS PA-24-AC monitor panel uses real 8-bit with no FRC +or- .
what do these numbers corelate to ?
i hope i explained myself well enough if not i’ll try again.
ArgyllCMS/DisplayCAL compute a 16bit/entry 3×256 LUT tables and stores them in VCGT in your ICC profile. That table is loaded in to GPU LUT tables for calibration. GPUs usually do not have 16bit/entry, not even 10 so there is truncation. Other GPU have 10-12bit/entry but driver or the app that loads VCGT data to GPU LUT may truncate it to 8bit.
ArgyllCMS effective LUT entry is a “test” to verify if you have more than 8bit, so it is possible that you can get a GPU calibration without banding (if driver and LUT doader app do not mess).
In GPU outputs it can be downgraded to 8bit and still be bandless if you have ditheringThis is not related to monitor input bitdepth or monitor panel bitdepth., it applies to profiles an GPU.
Monitors with HW calibration play a similar trick that in GPU, and it does not matter if they are actually 6+2, 8, 8+2 or 10bit.
You get an input at 8-10bit, you (should have) have a LUT with more bits per entry than input and you have an output (that could be dithered to less bits)… but DisplayCAL/ArgyllCMS cannnot write date there, you should use vendor app… which is Asus in your monitor, so you requiere Windows… and vendor app is not very good as explained before.
- Offline
dispcal: Warning – new_dispwin: Expected VideoLUT depth 8 doesn’t match ↲
↳ actual 10why does it expect a depth 8 VideoLUT and complains that it’s 10. what is 10 in this context ? the vcgt ?
what also confuses me is that the attached uncalibrated-reports do not match. if you check at the end each-of-them (more or less) vary. some say “Effective Video LUT entry depth seems to be 10 bits” and a few others report it as 11 or 12 (haven’t seen 13, 14 ,or more reported) and one of them i think is the “Scenery-mode” says “dispcal: Warning – Unable to determine effective Video LUT entry bit depth”
this is nonsense to me – if they are all uncalibrated reports and pertain to the same monitor done with the same software on the same machine/same components why don’t they ALL report the same value or report no value. what determines this inconsistency in the reports ?
is it normal that the contrast ratio is so low after calibration/profiling and the black-point is so high compared to the uncalibrated-report ? what can i do to make it closer to the 1000:1 native and lower black level ?
sorry i know i ask a lot of questions – it’s just that these things confuse me as i’m trying to figure out if something is wrong either with the software or the instruments.
Take LUT test as a yes/no > 8bit. It does not mean anything else.
Regarding reports:
Dark mode no calibration
14:09:26,074 Uncalibrated response:
14:09:26,074 Black level = 0.0485 cd/m^2
14:09:26,075 50% level = 11.43 cd/m^2
14:09:26,075 White level = 52.57 cd/m^2
14:09:26,075 Aprox. gamma = 2.20
14:09:26,075 Contrast ratio = 1083:1
14:09:26,075 White chromaticity coordinates 0.3064, 0.3227
14:09:26,075 White Correlated Color Temperature = 6925K, DE 2K to locus = 4.6
14:09:26,075 White Correlated Daylight Temperature = 6928K, DE 2K to locus = 0.0
14:09:26,075 White Visual Color Temperature = 6729K, DE 2K to locus = 4.4
14:09:26,075 White Visual Daylight Temperature = 6928K, DE 2K to locus = 0.0
14:09:26,075 Effective Video LUT entry depth seems to be 10 bitsDark mode calibration:
17:46:35,518 Current calibration response:
17:46:35,518 Black level = 0.1664 cd/m^2
17:46:35,518 50% level = 27.62 cd/m^2
17:46:35,518 White level = 128.88 cd/m^2
17:46:35,518 Aprox. gamma = 2.22
17:46:35,518 Contrast ratio = 775:1
17:46:35,518 White chromaticity coordinates 0.3781, 0.3801
17:46:35,518 White Correlated Color Temperature = 4087K, DE 2K to locus = 3.7
17:46:35,518 White Correlated Daylight Temperature = 4087K, DE 2K to locus = 1.0
17:46:35,518 White Visual Color Temperature = 4026K, DE 2K to locus = 3.5
17:46:35,518 White Visual Daylight Temperature = 4102K, DE 2K to locus = 0.9The culprit is you, since you choose a white point far from what seens to be native whitepoint. It is expected.
Choose D65 white, or D50 white and you’ll get better contrast.
- Offline
It is expected.
Choose D65 white, or D50 white and you’ll get better contrast.
that confirms my theory then – setting white point to 4000k does have a detrimental effect to contrast ratio (but it does make it a little easier on the eyes in regards to my ambient)
i’ll just have to suck it up and have two different icc profiles (one for reading and one for rec709 native d65) + the ones for editing/work etc.
no matter – i figured out the banding issue also. installed GIMP set it to “no-color-management” in preferences and performed both the lagom.nl test and Florians with all OSD presets no custom icc profiles loaded in the vcgt and everything seems to be buttery smooth on the amdgpu-pro-install driver. NO BANDING happening and all results seem to align to the expected results in Florians test.
all good so far ! but those report-uncalibrated inconsistencies regarding 10/11/12 bits reporting (the last line) still bug me. they should all report one single bit depth not to mention one doesn’t even report back. weird !
GIMP set it to “no-color-management”
Non-color-managed is probably not what you want.
but those report-uncalibrated inconsistencies regarding 10/11/12 bits reporting (the last line) still bug me
Why? Even a very sensitive and repeatable instrument will have some margin of error and likely struggle to determine a difference when the signal level is 1 / 1024 or even 1 / 2048, and that is not even taking display stability into account (temporal dithering, backlight flicker etc).
GIMP set it to “no-color-management”
Non-color-managed is probably not what you want.
Florian is right.
GIMP with no color management + Gradient was a test configuration, to see if your AMD propietary driver is working as expected (>8bit LUT + dithering).
Your normal work with images should be color managed… unless you know what you are doing, like assuming that your display is a perfect “sRGB” display (even you know it is not) and choosing smooth gradients over accuracy (like a web designer may choose as the lesser evil).
And if you want to avoid banding in color managed application, work with high bitdepth images (e.g. 16 bit per channel) and/or use dithering (if available).
- Offline
thank you guys for your input !
i do use GIMP color-managed and Darktable also. i set it to non-color-manage just for testing purposes.
i do like to use 32-bit linear exports from Blender with .exr and gradually drop down to 8 bit as i edit in post. it’s the best control i have in this regard. it’s still a pain not having a real 10-bit monitor but yeah all your advice has been helpful to me and i’ve come to understand how this process works a little better regarding this panel.
ps: i wonder when we’ll get a fully open “pipe” between the monitor hardware and the gpu/displayCAL so as to not require the use of proprietary OSs for dedicated manufacturer software …
