- This topic has 9 replies, 3 voices, and was last updated 8 months, 3 weeks ago by
.
-
Posts
-
I was trying to create a profile with excessive neutral patches, and found that profiles created with DisplayCAL differ from profiles created with ArgyllCMS command line in some aspects:
1. DisplayCAL yields jagged tone curves
Given the same measurement data (.ti3) file, DisplayCAL-generated tone curves are jagged, while ArgyllCMS colprof generates smooth tone curves on all channels.
(see image and related files in attachments, since embedding image puts my previous post into moderation)
2. DisplayCAL calibrated white point slightly off from the specified white point
When I specify the sRGB (x=0.3127, y=0.3290) white point in DisplayCAL, the white point in generated profile is at approx. 7000K (in several runs).
I cannot exclude measurement errors here, but ArgyllCMS dispcal and X-rite software can generally achieve a better white point match (again, in several runs).
Logs from DisplayCAL show it altered ArgyllCMS-generated tone curves, and DisplayCAL-generated calibration curve file (.cal) also differs from ArgyllCMS-generated one in digit counts (0.12345000 vs 0.12345), which supposes it may be altered by DisplayCAL.
Does anyone know the purpose of such behavior? Is it a workaround for some specific issue?
DisplayCAL uses an outdated version of Argyll.
- Go to File > Locate ArgyllCMS executables…
- Navigate to the bin directory in the Argyll folder and click “Select Folder”.
First of all test ArgyllCMS command with the same TI3 generated by DisplayCAL. Since Displaycal is a front end and your logs had colprof command with full params… it’s likely that maybe full patch measurement is done in a different way, whcih is not in your logs.
Same TI3 with same -as param (3 xTRC matrix) sghould render same TRC.Regarding WP make sure you have not used alt observer, that you do not use native/as measured for one app and specific coordinates for another. DIsplayCAL 1st tab + check additional params on advanced options
First of all test ArgyllCMS command with the same TI3 generated by DisplayCAL.
How excatly do I do it?
it’s likely that maybe full patch measurement is done in a different way, whcih is not in your logs.
DisplayCAL will copy and reformat the input ti3 file. I rechecked the copy and it did contain the same measurement data.
I also rechecked the logs and found that the jagged TRCs is generated by DisplayCAL in a “Creating shaper tags in separate step” stage and it discarded(?) all single-channel patches.
First of all test ArgyllCMS command with the same TI3 generated by DisplayCAL.
How excatly do I do it?
Feeding the same file, from the logs we can see:
colprof -v -qh -as -D sample_argyll -O sample_argyll.icm sample
vs
2023-01-06 10:08:53,019 Command line:
2023-01-06 10:08:53,019 D:\dant\Downloads\DisplayCAL-3.8.9.3-win32\DisplayCAL-3.8.9.3\Argyll_V2.3.1\bin\colprof.exe
2023-01-06 10:08:53,019 -v
2023-01-06 10:08:53,020 -qh
2023-01-06 10:08:53,020 -as
2023-01-06 10:08:53,022 -C
2023-01-06 10:08:53,023 “No copyright. Created with DisplayCAL 3.8.9.3 and ArgyllCMS 2.3.1”
2023-01-06 10:08:53,023 -M
2023-01-06 10:08:53,023 Untethered
2023-01-06 10:08:53,025 -D
2023-01-06 10:08:53,025 sample_displaycal
2023-01-06 10:08:53,026 sample_displaycalTI3 files are different files.
it’s likely that maybe full patch measurement is done in a different way, whcih is not in your logs.
DisplayCAL will copy and reformat the input ti3 file. I rechecked the copy and it did contain the same measurement data.
Same data as argyll file or same data as pre formated file? I was asking for the 1st check.
I also rechecked the logs and found that the jagged TRCs is generated by DisplayCAL in a “Creating shaper tags in separate step” stage and it discarded(?) all single-channel patches.
TRC measurements on device seems as bad as stored in Displaycal profile:
2023-01-06 10:09:14,823 Warning: Skipping RGB 72.16 72.16 72.16 XYZ 47.036018 48.636582 40.340933 because Y is not monotonically increasing
2023-01-06 10:09:14,825 Warning: Skipping RGB 99.22 99.22 99.22 XYZ 96.831811 100.398993 82.856352 because Y is not monotonically increasing
2023-01-06 10:09:14,825 Warning: Skipping RGB 99.61 99.61 99.61 XYZ 97.548420 101.249438 83.537573 because Y is not monotonically increasing2023-01-06 10:09:15,397 Adding rTRC from interpolation to sample_displaycal
2023-01-06 10:09:15,398 Adding gTRC from interpolation to sample_displaycal
2023-01-06 10:09:15,398 Adding bTRC from interpolation to sample_displaycalPlot 2D data from this onwards:
2023-01-06 10:09:14,598 Creating shaper tags in separate step
2023-01-06 10:09:14,598 Using chromatic adaptation transform matrix: Bradford
2023-01-06 10:09:14,648 Extracting neutrals from c:\users\dant\appdata\local\temp\DisplayCAL-ho2ioc\sample_displaycal.ti3
2023-01-06 10:09:14,783 NUMBER_OF_FIELDS 7
2023-01-06 10:09:14,785 BEGIN_DATA_FORMAT
2023-01-06 10:09:14,785 SAMPLE_ID RGB_R RGB_G RGB_B XYZ_X XYZ_Y XYZ_Z
2023-01-06 10:09:14,785 END_DATA_FORMAT
2023-01-06 10:09:14,785
2023-01-06 10:09:14,785 NUMBER_OF_SETS 259If TRC from Ti3 is jagged and TI3 file has such data… display behavior is jagged. This may happen on displays that have bad RTC response (overshoot / undershoot).
That’s why the first check should be performed: does argyll input ti3 stores the same data as displaycal?Same applies for VCGT+bitdepth applied to display. Make sure that you are not measuring with a VCGT truncated by Windows display going to standby (even in user logon screen) on one app and not truncated in the other.
If TI3 data is real, jagged, then maybe you should aim for -aS or tweak delay on DisplayCAL 1st tab to avoid the RTC overshoot error when chanuing from oen color to another.
if VCGT data cannot be loaded properly due to windows standby / windows VCGT load (truncation to 8bit untill you restart, no matter what you put in displaycal tray app, OS limitation) you’ll have to repeat the process from start.Same data as argyll file or same data as pre formated file? I was asking for the 1st check.
The “ground truth” file is sample.ti3, which is measured by argyll dispread without VCGT some time before.
After loading into DisplayCAL, sample_displaycal.ti3 and sample_displaycal.bpc.ti3 are generated.
The sample_displaycal.ti3 file contains same RGB/XYZ data as sample.ti3 file (except number formats) and is used in DisplayCAL-initated colprof call.
Even if I use the exactly same colprof command line in DisplayCAL logs, it still have different output (matrices, gammas, and self check result in the last line), but the output is exactly the same as sample_argyll.log.
Well, I’m running out of ideas now…
Even if I use the exactly same colprof command line in DisplayCAL logs, it still have different output (matrices, gammas, and self check result in the last line), but the output is exactly the same as sample_argyll.log.
Well, I’m running out of ideas now…
Is data jagged or not? plotting it.
If actual data shows such TRC errors (as logs shows) then “Creating shaper tags in separate step” done by DisplayCAL may be revealing the true behavior of display when you request (“3 curves + matrix”) while default -as in argyll is smoothing it, like a mix between -as and -aS. If thta is what it is happeing and you do not want actual TRC to be captured then you should use -aS.Is data jagged or not? plotting it.
Yes, it is some sort of jagged.
If actual data shows such TRC errors (as logs shows) then “Creating shaper tags in separate step” done by DisplayCAL may be revealing the true behavior of display when you request (“3 curves + matrix”) while default -as in argyll is smoothing it
Sounds reasonable. I will try another run with larger delay later.
