- This topic has 23 replies, 3 voices, and was last updated 6 years, 11 months ago by
.
-
Posts
-
- Offline
@fhoech hi Florian !
i recently got a brand new ASUS PA24AC. i would like to calibrate/profile it to my custom ambient light but i’m not sure if the WLED correction is the one i should be using.
running DisplayCAL 3.8.2 + ArgyllCMS 2.1.1 (latest if i’m not mistaken) under ubuntu 19.04 gnome/wayland with the AMD Vega open source driver stack from the Linux kernel 5.0.0-17-generic.
this display panel has a nice 100% sRGB coverage but it’s not wide gamut although it’s rated VESA 400 and HDR10. overall pretty nice uniformity and <2 deltaE color accuracy on a 14 bit LUT.
i’d like to calibrate/profile it to my custom ambient light (300 lumen 4000k whitepoint single LED strip light source behind the monitor stand).
what settings do you suggest i use for a general replacement to the built in OSD “Reading-Mode” factory calibration of the monitor ? i see this monitor has two blank “User Mode 1” “User Mode 2” configurable through the OSD.
i was thinking of having a general browsing-reading configured to the User Mode 1 and keep the second for a special 3D LUT type scenario. is it neccesary to also separately profile my dGPU LUT when using one of the sRGB/rec709 built in from the monitor?
one final question – how do i figure out what internal LUT a radeon pro WX 8200 graphics card uses ? is it 8 bit limited with the open source driver and only 10 bit decode capable when in video x265 playback in HDR streams? what i’m trying to say is this – would it make a difference if i ran the open source driver vs the proprietary driver to acces 10 bit LUT everywhere ? my understanding is that calibrations are more accurate if a higher than 8 bit iLUT is used in combination with the 14bit of the monitor iLUT.
LED sRGB = WLED CCSS correction for i1d3 colorimeters
Since monitor seems to be sRGB like and 1000:1 static contrast ratio, advertised “HDR” features are mostly useless. Your displays supports that yu feed it with an HDR signal… internally it will “cut” out of gamut colors and remap grey scale to fit in colorspace provided by its SDR panel.
Also it is possible that if you make a LUT3D HDR with DisplayCAL for software like WIndows madVR you’ll get better results.“Factory calibration” usually means nothing. <2dE in grey scale could be noticeable & disgusting, that’s why DisplayCAL shows you a*/b* deviations and a*b* range when you verify a profile.
You want to be able to load >8bit/entry in GPU LUTs so if GNU driver does not allow it, use the AMD driver.
Viewing a smooth black to white 8bit gradient in a non color managed enviroment (it is very important that it is smooth and that there is no color management , like in MS Paint) with a GPU calibration loaded usually is the smoking gun to test if your GPU LUT contents are truncated to 8bit or not.If you want 2 white point settings it makes sense to use “User mode 1” and “2” to store different RGB gain settings (and even gamma presets if that display has that feature)
PS. This displays seem to have HW calibration, but you’ll need MS Win or macOS to use HW calibration software from Asus.
Unfortunatelly Asus calibration software for ProArt series(v1.09) is very limited (white point and brightness selection) and not acurate for all Asus LED series (it lacks of proper spectral corrections for your i1d3).Calibrite Display Pro HL on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.
- Offline
hello Vincent and thank you for your quick response !
yes about “User mode 1” and “2” from the OSD it seems it is greyed out unlike rec.709 which i found offers the most customisability in the Asus PA24AC OSD (maybe this is because it is suplimented through their proprietary HW calibration from macOS and windows).
i will not go to macOS/windows for any reason as i can do pretty well on the GNU/Linux/Ubuntu side for now. i would have gone with a FSF vetted gnu/libre-linux distribution but the GPU firmware issues of nVidia/AMD are a no-no so far.
forgive me for repeating this – i did not understand correctly – do i need to perform that black to white 8-bit gradient test in GIMP to see if it gets truncated in the mesa open source implementation for AMD Vega radeon pro wx8200 graphics card ? some people have said that lately there is no difference between the FOSS and Proprietary drivers from AMD. Phoronix benchmarks for the AMD vega 64 have shown that on the gaming side the open-source driver behaved even better than the proprietary one but i’m not sure how this applies to the GPU iLUT ? i mean if it’s a radeon-pro it should have the firmware tunned for 10-bit accros the board not just limited to video decoding as i understand it is with the gaming counterparts (maybe i’m wrong here).
what would be a good non-color managed application in for GNU/Linux ? the default installed one maybe ?
i also use darkroom RAW editing applications like Dark-Table/Raw-Therapy to do light editing on my RAW sensor data even if i don’t have a full 10bit color-workflow (can’t afford a good 10bit HDR monitor right now)
PS: applied the 130cd/m2 4000k rec.709 tone curve with ambient corrections with WLED corrections to the GPU LUT corresponding to my custom rec.709 OSD calibration (matched the targets almost perfectly with the RGB gains/brightness haven’t touched the rest – disabled HDR/Dynamic-dimming/power-saving/Adaptive-Sync/Eco-Mode). don’t know what DDC/CI means in OSD setup
i still feel it’s bullshit that they chose to partially/fully lock-down some OSD calibration modes. for example sRGB is completely locked (well i guess it makes sense since that one is more or less for web-content but i don’t like not beeing able to match my monitor to my ambient at all even though the after calibration/profile self report shows that the sRGB gamut is closer to 90 % rather than 95%> as it is recommened by displayCAL in the html self-report.
excuse my rant !
hello Vincent and thank you for your quick response !
yes about “User mode 1” and “2” from the OSD it seems it is greyed out unlike rec.709 which i found offers the most customisability in the Asus PA24AC OSD (maybe this is because it is suplimented through their proprietary HW calibration from macOS and windows).
Ok, use other OSD for DisplayCAL.
forgive me for repeating this – i did not understand correctly – do i need to perform that black to white 8-bit gradient test in GIMP to see if it gets truncated in the mesa open source implementation for AMD Vega radeon pro wx8200 graphics card ? some people have said that lately there is no difference between the FOSS and Proprietary drivers from AMD. Phoronix benchmarks for the AMD vega 64 have shown that on the gaming side the open-source driver behaved even better than the proprietary one but i’m not sure how this applies to the GPU iLUT ? i mean if it’s a radeon-pro it should have the firmware tunned for 10-bit accros the board not just limited to video decoding as i understand it is with the gaming counterparts (maybe i’m wrong here).
You need to:
1-make a GPU calibration, like in your Rec709 OSD mode and DisplayCAL GPU calibration.
2-load that calibration (VCGT tag in profile to GPU LUT) to GPU
3-Open a smooth gradient in a enviroment WITHOUT color management
Then, do you see banding in gradient? If you see it LUT stored calibration truncated to 8bit (and/or dithering is not working)
So *if* you see that banding on that setup, move to AMD propietary driver. It should have the same features as Windows driver (high bitdepth in LUTs + dithering)what would be a good non-color managed application in for GNU/Linux ? the default installed one maybe ?
I think that GIMP or firefox could be configured to disable all color management. Check documentation.
i also use darkroom RAW editing applications like Dark-Table/Raw-Therapy to do light editing on my RAW sensor data even if i don’t have a full 10bit color-workflow (can’t afford a good 10bit HDR monitor right now)
Some RAW editors do not need 10bit: Lightroom or Capture One. They use temporal dithering. Maybe some GNU editors do it too but AFAIK their windows versions are not able to do it.
PS: applied the 130cd/m2 4000k rec.709 tone curve with ambient corrections with WLED corrections to the GPU LUT corresponding to my custom rec.709 OSD calibration (matched the targets almost perfectly with the RGB gains/brightness haven’t touched the rest – disabled HDR/Dynamic-dimming/power-saving/Adaptive-Sync/Eco-Mode). don’t know what DDC/CI means in OSD setup
i still feel it’s bullshit that they chose to partially/fully lock-down some OSD calibration modes. for example sRGB is completely locked (well i guess it makes sense since that one is more or less for web-content but i don’t like not beeing able to match my monitor to my ambient at all even though the after calibration/profile self report shows that the sRGB gamut is closer to 90 % rather than 95%> as it is recommened by displayCAL in the html self-report.
Ask somebody with a WIndows laptop, install Asus ProArt software and try… but since it lacks of spectral corrections results could be not very good.
Blame asus for no Linux support and for lacking of proper spectral corrections.
- Offline
most of all i blame ASUS for the two distinct but far away always-on-red-pixels of this unlucky panel. they only accept RMAs if the pixels are in close proximity to one another.
i thought about doing this test here > https://displaycal.net/icc-color-management-test/
would that work ? i’ve applied all the calibrations/profiling on the dGPU with the open source driver saved the atached test images and opened them in gnome 3.32.1 “image viewer” app. i don’t believe it’s color managed since it is so basic. so far i see no pronounced banding (maybe a little down in the very dark grey almost black area) but i believe i need to investigate this further.
do you think AMD would be willing to offer a side by side comparison of the features of the open vs closed driver ?
do you have a better smooth gradient to illustrate this than the one attached above ? @vincent
I’ve not tested in depth color management under Linux. Try with GIMP/Firefox disabling color management.
This one is smooth, “save as” and test without color management:
“http://www.lagom.nl/lcd-test/img/gradient-h.png”
- Offline
so what i ended up doing was a fresh-install of ubuntu 18.04 LTS so i could install the amdgpu-pro-driver (closed-source-proprietary) following these instructions (easy enough to follow).
i installed in normal mode not headless.
i ended up recalibrating/measuring/profiling from scratch in displayCAL (advanced-mode this time). i reconfigured the OSD preset “darkroom” because it had the color-temperature unlocked unlike the rec.709 preset that i used before.
this time i set the Black Level from the OSD from 50 to 0 which i think ended up requiring me to set the brightness from 50 to 72 (i think i should have left the BL to 50 as was default to all presets). left gama and color temperature as they were (2.2 6500k) just modified the RGB gains again from the Advanced Settings in the OSD.
attached screenshots for the Display&Instrument – Calibration – Profiling tabs inside displayCAL to better ilustrate what i used. also when i enabled the installed the profile it gave me an error (included that too).
tested the smooth gradient you attached above. with the vcgt .icc applied from the calibration i made with the settings (seen from the attachents) the banding is very strong towards the dark end not so much to the white.
with the vcgt-cLUTs (applied) from Florians suggested testing color management attachments the banding is still visible but not as pronounced but not with his gradients.
what to do next ?
That low constrast at what looks like native white?, from your text log capture, it does no look good. Check your configuration: osd, contrast OSD @ default value, ouput range…
Also 4000K daylight calibration gives you an abnormal low number of grey unique levels… like if you corrected white in GPU instead of using OSD gains.
Take a look on your display profile calibration curves with DisplayCAL.Check what you did… also I see no point using your calibration configuration. Just set white point, set gamma, set speed to low or medium and you are done.
Anyway:
-in non color managed enviroment and AMD drivers working properly (effective LUT x bits) you should not have banding in that gradient (unless something is wrong from start in you configuration, check what I wrote)
-in color managed enviroment like GIMP (color management on) showing that gradient as an sRGB image it is very likely that you will have some kind of banding (unless GIMP for Linux has evolved so much!). Blame your image editor.
- Offline
what do you think that error i attached above means (the 1st attachment i believe) ?
(it lacks of proper spectral corrections for your i1d3).
do you mean i should set spectral corrections in displayCAL to “none” rather than have it on “White LED Familiy” for this panel ?
what do you think that error i attached above means (the 1st attachment i believe) ?
IDNK, maybe others can help you.
(it lacks of proper spectral corrections for your i1d3).
do you mean i should set spectral corrections in displayCAL to “none” rather than have it on “White LED Familiy” for this panel ?
No, it just means that Asus HW calibration software is using “none”, or a “wrong one”, so it will “fail” to some extent.
But you are not using Asus ProArt software, you are using DisplayCAL so use WLED.
- Offline
@fhoech Florian if you don’t mind could you give us your input on this issue ?
- Offline
i mean about this error.
- Offline
@fhoech i’ve tought about it but i’m not sure … could this error be caused by not giving the profile permission to install system-wide (just current user in gnome settings 2.8.2 > color > monitor panel profile)
i’ve enabled “set for all users” and it seems to not error anymore when installed from the displayCAL side. it might be a conflict with setting permissions individually from within the displayCAL GUI and just manually doing it from the settings > color. i’ve done it from both places and voila no more error.
on the other hand the issue remains where i can only calibrate/measure/profile from the Gnome/X11 side not wayland (seems to error out because of unpredicatable and unstable window placements happening during calibration – luckily after that is over one can apply profiles and work safely from within wayland/xwayland but the hard part must be carried out from the x11 side.
That’s an error from colord. There’s not much you can do about it. Just assign the profile manually in GNOME color control panel.
Btw, even though the option exists in DisplayCAL, “system-wide” installation (read: install as default for new users, or users who have never changed their color profile) for colord will always only install for the current user, 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”.
