- This topic has 4 replies, 2 voices, and was last updated 1 year, 8 months ago by
.
-
Posts
-
Hello,
I am new to Displaycal having come from Calman and Colourspace CMS. I have had very good – excellent, infact – success with the Argyll/Displaycal calibration LUTs on my LG C3 OLED. I have been verifying using my Colourspace CMS workflow and am getting a dE average of .34 over a 10^3 cube against rec 709, which is quite amazing for this display. I am using this in an editing/colour suite as a client monitor/4K pixel checking monitor. My reference monitor is a Flancers Scientific DM250.
I am working with a video signal path, using video legal levels, REC709 (black magic design SDI and HDMI out) and not a display card.
I have been trying to use the verification tab in displaycal and feel that I am looking at a completely different monitor. It seems that in order to verify in a way that see even remotely correct, I need to load the profile I created of the monitor. Even then I see a dropoff in the gamma above 90% which is not present when verifying with colourspace cms.
I have read through the forum and have worked through a number of the workflows suggested. None of them seem to work for my usecase.
When I look at my reports, it appears that displaycal is outputting full-range triplets as opposed to legal range triplets. Given this, switched my resolve TPG (pgen_client with rPi4 pgen installed) to legal range and the resulting verification still looks incorrect.
Ultimately, I would love to be able to use displaycal to verify LUTs loaded to my display made in other software, too. it would be ideal if I could just verify the display in its current state against a standard.
I have tried so many combinations of setting all with mixed results.
Currently I am trying to use-
Setting: Video for 3D LUT for Resolve,Video Verification test chart, Sim Profile: Rec709, Use sim profile as display profile, and unmodified tone curve.
This is clearly incorrect.
How can I use displaycal to verify the current state of my video display against a standard (IE Rec709, 2.4) without having a profile. How can i ensure that Displaycal is respecting the legal range when outputting patches for verification?
You are mixing several configuration issues into one subject.
If pgenclient + rpi PGen reports weird results while using external pattern generator, it’s a pgen client issue (or user missconfiguration). It only uses Argyll’s spotread for its internal pattern generation. So if you are using resolve as TPG, you’ll have to open an issue in pgenclient github or post your issue in AVS foroum thread about pgen client.
Regarding DisplayCAL unfortunatelly it is meant to be used with color managed apps so on a clean instalation it requires to create and install a profile for each display output (*).
Once this is done “on a regular GPU” simulate profle + use simulated profile a display profile + nominal gamma/TRC works to verify HW/factory calibration.
So te easy way to enable verification is to create a simple matrix profile. It will not be taken into account when use simulation as display profile.
Full vs range can be selected on 1st tab.Your situation looks like an user misconfiguration issue since rec709 TRC in ICM is not 2.4. It seems that you are missing target TRC step (do not use unmodified).
But the lack of information on your side makes imposible a better diagnosis. HTML report could help to see more issues.Anyway as a general rule if you encounter some problems likely to be caused by user missconfiguration, switch all gear & soft to full level, verify and if all is OK, then you can try to find which step in the pipeline is causing issues with legal.
(*) features like “verification without 1st profile” and “use simulation profile as display profile but keeping VCGT” should be requested to DisplayCAL-p3 modernization project.
It works for macOS sonoma but there is no Windows version yet.
https://github.com/eoyilmaz/displaycal-py3Thank you, Vincent, for your detailed response. It’s been very helpful in clarifying some issues. Let me address the key points and share my findings:
1. Working Environment: I work with a video signal path where color management is handled by software/hardware transforms in the video pipeline, not the OS. This makes VCGTs and ICCs somewhat unfamiliar territory.
2. DisplayCAL Profile Requirement: I understand from your post that DisplayCAL needs an ICC profile loaded to initiate verification, even when using “use simulated profile as display profile”. Can you confirm if a “dummy” matrix profile for each attached monitor would suffice for this purpose?
3. Legal/Full Range: I apologize for conflating issues earlier. After adjusting settings based on your advice, I’ve achieved more reasonable verification results.
4. RGB Triplet Reporting: I’ve noticed that DisplayCAL reports RGB triplets in full range (0-255) in verification reports and logs, while actually sending legal range (16-234). Is this a known reporting quirk where patch % values aren’t scaled to signal range?
5. Gamma Curve Discrepancy: I’ve run a 10^3 cube verification in ColorSpace CMS and a 1000 patch verification in DisplayCAL using the same calibration LUT and probe match. DisplayCAL shows a rolloff at the top end of the gamma curve not present in ColorSpace CMS reports. I’ve attached both reports for reference. Could you help explain this discrepancy?
6. Technical Setup: I’m using the Python 3 version of DisplayCAL on Linux, as I couldn’t get Resolve functionality working on Windows.
Lastly, as you have suggested, I’ll request the “verification without 1st profile” and “use simulation profile as display profile but keeping VCGT” features for the DisplayCAL-py3 project.
Any insights on these points, particularly the gamma curve discrepancy, would be greatly appreciated.
1-2: on regular GPU+Windows it asks to install a display profile from DisplayCAL one. IDNK why this requierement. On DisplayCAL-py3 IDNK if it is mandatory
On “other outputs” (Resolve/madVR) it asks for a display profile made or at least installed from within DisplayCAL to ensure actual nits are taken into account even if it is not needed for SDR Rec709. I do not remember the exact cause of that requierement but Florian wrote it somewhere in this forum4: Patches on reference testchart are 0-100 then scaled to video or full levels. Only Florian or Erkan known from source code in the HTML report
5: Maybe caused by 4 when apply log()/log() but colorspace report do not go over 0.9 plotting EOTF and there it is going down at 0.9.
Also DisplayCAL gamma plot is in “Y” grayscale value, not on each color/channel bc it is useless. Per channel is seen in RGB balance or a*b* axis deviations.
To make an actual comparision you should take actual Colorspace readings for grayscale color and plot EOTF… since those data is mssing in colorspace report, it not seems possible. Maybe on Colorspace “measured values table”, in its GUI, not in report, you can see these values.
I do not see a discrepancy between these 2 tools on EOTF“7”: I’ll add a request to write actual levels on HTML report so comparisons could be done easily whithout rescaling manually by you. It’s impractical.
Rember that DisplayCAL is a GUI, ArgyllCMS show the patches. But testchart reference files are 0.00-100.00 range so DIsplaYCAL-py3 will be forced to trace the same exact scalling as dispread.exe to avoid +-1 error in HTML report in RGB tiplet. That could be an ugly dependecy if argyllCMS changes the rounding error truncation between versions.
Ask Erkan, but this solution seems “ugly” and I’ll put in the bottom of TODO list.Thanks-you again for sharing your insight, Vincent.
I reviewed all the charts again and do see the rolloff in the upper values in the “DIF EOTF” graph in the Colourspace report. I am usually just looking at the GUI EOTF graph and the “Greyscale dE distribution” chart which looks very good on the Argyl calibration. I do see what you are saying: that the verifications are similar.
I have another question regarding the differences between a calibraiotn done using colourspace cms and argyll/displaycall cms. I will open another theread for this.
Thanks again for helping me sort through the correct way to use dislplaycal verificaition in a video signal-chain.
