Home › Forums › Help and Support › Extra patches in testcard
- This topic has 3 replies, 2 voices, and was last updated 5 years, 1 month ago by Florian Höch.
-
AuthorPosts
-
2019-02-07 at 23:50 #15634
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.
2019-02-08 at 1:14 #15636Hi,
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).
2019-02-08 at 11:37 #15662OK, 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.2019-02-08 at 19:05 #15666image#,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.
-
AuthorPosts