Extra patches in testcard

Home Forums Help and Support Extra patches in testcard

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #15634

    grahamh
    Participant
    • Offline

    I have a 325-patch test card cloned from verify-large.ti1 that I’m using for verification.  When I start it up DisplayCAL inserts four white patches at the beginning of the sequence, making 329 patches in all.  That is throwing out the synchronisation between DisplayCAL and the pngs I made from the same test card, which I’m displaying with the -C ‘command’ option.

    I’m sure those extra four white patches weren’t there a couple of weeks ago when I set up this testing method.  Is there a setting that could have changed the behaviour? White level drift and Black level drift are off.

    Update: now it’s inserting 6 white patches.

    • This topic was modified 5 years, 1 month ago by grahamh.
    #15636

    Florian Höch
    Administrator
    • Offline

    Hi,

    I’m sure those extra four white patches weren’t there a couple of weeks ago when I set up this testing method.

    This has been the case since the very first version of DisplayCAL (back then dispcalGUI) that offered verification measurements. It’s arguable whether it needs to be four or if one would suffice, but the methodology is always the same: The testchart is checked whether it contains the minimum amount of “true” white (= device RGB 255 255 255) patches. If that’s not the case, any existing device RGB white patches are filled up to make a total of four. Using a simulation profile or device link influences this (because those may turn patches in the testchart from true white to some other shade after the various color transforms that may be applied).

    #15662

    grahamh
    Participant
    • Offline

    OK, thanks, but there’s something I’m still not getting.  Attached is what one of my testcharts looks like in the editor.  There are 4 white patches in the first 7 patches. My script captures the parameters sent with the -C command and this is the result:

    image#,R,G,B,X,Y,Z
    1 , 255, 255, 255, 1.000000, 1.000000, 1.000000 
    1 , 255, 255, 255, 1.000000, 1.000000, 1.000000 
    1 , 255, 255, 255, 1.000000, 1.000000, 1.000000 
    1 , 255, 255, 255, 1.000000, 1.000000, 1.000000 
    1 , 255, 255, 255, 1.000000, 1.000000, 1.000000 
    2, 250, 0, 65, 0.982057, 0.000000, 0.254727 
    3, 255, 255, 255, 1.000000, 1.000000, 1.000000 
    4, 20, 167, 154, 0.078719, 0.656523, 0.605107 
    5, 255, 255, 255, 1.000000, 1.000000, 1.000000 
    6, 252, 0, 158, 0.989140, 0.000000, 0.618032 
    7, 255, 255, 255, 1.000000, 1.000000, 1.000000 
    8, 141, 137, 127, 0.552721, 0.538867, 0.497965 
    9, 5, 4, 5, 0.019726, 0.016181, 0.019791 
    10, 72, 173, 0, 0.281020, 0.677676, 0.000000 
    11, 7, 6, 7, 0.028279, 0.023902, 0.027728 
    12, 74, 171, 58, 0.289714, 0.671660, 0.226576 
    13, 9, 8, 9, 0.036872, 0.032580, 0.035301

    Are you saying those XYZs are not the actual values being sent through the profile under test when a simulation profile is used?  Otherwise, what is the difference between the 4 existing whites and the 4 which DisplayCAL has added?  Why are they added?

    For scripting purposes, can I rely on those extra whites always being sent first?

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

    Florian Höch
    Administrator
    • Offline

    image#,R,G,B,X,Y,Z

    Those are not XYZ, but RGB in the range [0, 1].

    For scripting purposes, can I rely on those extra whites always being sent first?

    I think it is guaranteed that the very first patch is always full device RGB white. Following patches may differ depending on many factors.

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

You must be logged in to reply to this topic.

Log in or Register

Display Calibration and Characterization powered by ArgyllCMS