DisplayCAL-generated profile differs from ArgyllCMS

Home Forums Help and Support DisplayCAL-generated profile differs from ArgyllCMS

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • #38434

    dant mnf
    Participant
    • Offline

    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?

    Attachments:
    You must be logged in to view attached files.
    #38441

    Kuba Trybowski
    Participant
    • Offline

    DisplayCAL uses an outdated version of Argyll.

    1. Go to File > Locate ArgyllCMS executables…
    2. Navigate to the bin directory in the Argyll folder and click “Select Folder”.
    #38443

    Vincent
    Participant
    • Offline

    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

    #38444

    Kuba Trybowski
    Participant
    • Offline

    First of all test ArgyllCMS command with the same TI3 generated by DisplayCAL.

    How excatly do I do it?

    #38445

    dant mnf
    Participant
    • Offline

    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.

    #38446

    Vincent
    Participant
    • Offline

    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_displaycal

    TI3 files are different files.

    • This reply was modified 3 weeks ago by Vincent.
    #38449

    Vincent
    Participant
    • Offline

    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 increasing

    2023-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_displaycal

    Plot 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 259

    If 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.

    #38451

    dant mnf
    Participant
    • Offline

    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…

    #38453

    Vincent
    Participant
    • Offline

    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.

    #38459

    dant mnf
    Participant
    • Offline

    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.

Viewing 10 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic.

Log in or Register

Display Calibration and Characterization powered by ArgyllCMS