TI1, TI2, CSV and printtarg target files for SpyderPrint Targets

[knowing]

OK, I tried to scan the targets but unfortunately the same error happens:

View attachment 17971

I will try to read every row and save the file and see how the profile is generated.

Hi @pharmacist ,
I am still pondering on what could be wrong with the ti1 files for the images and have not yet found an answer. I was wondering if you could tell me the steps you take when you take the example ti1 file that my script read_image_patch_colors generates (modified to get 975 patches) until you start reading with chartread?

I have a lot of open questions in my mind because I do not understand your process:

• You use the ti1 file with printtarg and make a tif file.
• Then you do something to the image to make your printscreen, which has colors that seem duller on the image?
• Is that image (the printscreen image) that you print for scanning with the colorimeter?
• When that image is changed from the original colors, are you also creating a ti2 file that matches the colors in the printscreen?
• Which ti2 file are you using as input to chartread? The one generated from printtarg, or another ti2 file that is adapted to the printscreen image?
• Did you use the latest ti1 file from the example folder "A4-Expert Target Plus Grays (1 page - 975 patches)-SS" when making your i1 image? Or did you use an old one, and just copying the second table in the new ti1 file? I ask because I did several fixes on the last script that might have had some effect on the ordering of the til1 list colors. If you give me the ti1 file you use I could compare them to check.

Could you upload any files that you make at every step, so I could investigate further?

Sidenote:
In the printing industry, the term "printscreen" generally refers to screen printing (also known as silkscreen printing or serigraphy). I assumed it is something like this you are doing, but it dawned on me that you might just refer to the "print screen" button on the keyboard, but that should not create such bland colors compared to the original images I posted earlier. Which is why I assumed some other process done here.

Also, you attached this image earlier, with an error from Qimage:

I assume this is coming from the image that you create from printtarg? Is printtarg embeding an icc profile on the image generated that is corrupted?
When I search for this error message: "Qimage has encountered a corrupted or incompatible ICC profile while processing the file:"
Google AI is instructing to try to strip or convert the color profile on the image to sRGB in photoshop or GIMP etc (save with or without profile).
Have you opened this image in photoshop or other software to see if the same error is there, or if the error is removed if you remove any profile or save the image with sRGB profile?

If you have that image it would be interesting to look at it. I do not get any similar error when opening images from printtarg that was generated using the ti1 files made by my script.

I would really appreciate your input to understand what is happening here.

Thanks,
K

 

[Epatcola]

Also, you attached this image earlier, with an error from Qimage:
View attachment 18008

Qimage had what I consider to be a bug or at best a useless error message. I don't know if it got fixed in the current version. If the Job Profile | Printer Profile drop down contains an icc profile Qimage attempts to read it even when OFF is selected in the drop down.

If that profile is missing you get this error message implying there is something wrong with the profile in the file you are printing.

 

[knowing]

Qimage had what I consider to be a bug or at best a useless error message. I don't know if it got fixed in the current version. If the Job Profile | Printer Profile drop down contains an icc profile Qimage attempts to read it even when OFF is selected in the drop down.

If that profile is missing you get this error message implying there is something wrong with the profile in the file you are printing.

Thanks for letting us know

 

[knowing]

Hi @pharmacist and others interested,
I have now verified the following:
1. When targen is used with argument -d2 and -c sRGB.icm profile, for example:

targen -v -d2 -f480 -c sRGB.icm TargetOutput

Then all XYZ values in output ti1 file is identical to following xicclu command:

xicclu -ff -ia -pX -s100 -v0 sRGB.icm

2. Current read_image_patch_colors.py script matches exactly the calculation in point 1, when sRGB.icm profile is used (default and used in example files). I use the same exact xicclu command to calculate XYZ values, but also use the following command for making the LAB values (if specified to include them):

xicclu -ff -ia -pl -s100 -v0 sRGB.icm
(you may add:
< inputvalues.csv > outputvalues.csv
at the end to read a list of values and output the converted list to a file.
This makes it easy to compare files.)

Sidenote: This might be wrong if ti2 file is requested with LAB values, as I have seen some unverified indications that printtarg uses relative colorimetric D50, not absolute colorimetric intent as above command for LAB values. This is though unrelated to your chartread issue, as you create ti2 file using printtarg (not using the ti2 file that my script makes).

3. When printtarg is used with ti1 file, the ti2 file has exact copy of XYZ values from ti1 file, and in most cases also the RGB values. In some cases the RGB values are recalculated from the XYZ values, which causes the RGB values to differ on the two smallest decimal values, which is insignificant. This means that the printtarg generated ti2 file, when using ti1 file from my script as starting point, should have all RGB and XYZ values correct and in sRGB space. If chartread and the colorimeter also expects sRGB values, then that should be correct. Since the ti2 file has XYZ values that are absolute colorimetric intent with D50 white, i do not know if it would be correct to use the -e or -d argument with chartread? (I noticed that your command did not have that)... What do I know, I never used chartread...

So, currently, I have not found any issue with the read_image_patch_colors.py script and why you would get such messages when using chartread. I am however aware that some other people on argyllcms on freelists.org are struggling with similar chartread messages with other targen and printtarg generated targets, unrelated to my examples and this script. This may point to some other issue, but may also be a distraction.

Thus, I find the best course forward would be if you could be so kind to attempt to answer as many questions as possible of those I posted this weekend (Saturday at 9:45 AM). That would help me a lot to understand better things. I would highly appreciate your feedback.

Alternatively, if anyone else could test using the it1 file from one of my examples, then generate ti2 file with printtarg and then try reading the target with chartread. That would also be awesome. I do not have that option myself, as I only have a SpyderPrint colorimeter, not usable for this.

Cheers,
K

 

[knowing]

Hi everyone,
Is there anyone that would be kind enough to test using one of the example ti1 files to create a printtarg target and read it with chartread (possibly with M1 setting, as target is D50 white point)? I don't have a i1 colorimeter my self.

That would be of great help to verify the experience that @pharmacist is having and if there is something wrong with the ti1 files.

One thing I noticed: If I use command

targen -v -G -d2 -f900 Printer

(example 900 patches generated)
then, the only line in the ti1 file that is present, which my generated ti1 files do not have, is:

TOTAL_INK_LIMIT "300.0"

It could be an idea to test making the target (using printtarg) with my example ti1 files with or without this TOTAL_INK_LIMIT line.

Anyone feeling up to it?

Thanks alot for any help.

Cheers,
K

 

[knowing]

Hi everyone,
I used some time lately to measure the SpyderPrint Target "High Quality Target (225-patches)" to test if I could use the SpyderPrint colorimeter to do the following:

1. Read the target "High Quality Target (225-patches)"
2. Create ICC profile in SpyderPrint for comparison
3. Then export scanned LAB values
4. Then use generated ti2 file from script read_image_patch_colors.py for the "High Quality Target (225-patches)" and combine with scanned LAB values to create a ti3 file
5. Then generate ICC profile with ArgyllCMS colprof

I wanted to see if it was possible and ask if anyone would be kind enough to give their thoughts and expert feedback on the result below. Really appreciate it.

I have attached the files used if anyone wants to take a look.

For anyone wondering, I used the following colprof command:

colprof -v -D"Printer Brother-Plain90g-White-225Patches-2026-01-16, Quality Med" -qm -S sRGB.icm -cmt -dpp Lab-cLUT_Med

When I compare the 3D Lab Plots in ColorSync Utility there is a difference between the Argyll generated profiles and the SpyderPrint generated profiles. I show these below.

The first ICC image is of the Argyll colprof profile (Screenshot Argyll ICC-FrontView.png):

Next images use the first image as reference and compares with the SpyderPrint generated ICC profile.
(Screenshot Argyll ICC (wirebox) vs SpyderPrint ICC (colors)-FrontView.png):

Screenshot Argyll ICC (wirebox) vs SpyderPrint ICC (colors)-BottomFrontView.png:

Last image: Screenshot Argyll ICC (wirebox) vs SpyderPrint ICC (colors)-BackView.png

As you can see the Argyll profile seems to have slightly larger gamut Reds, greens, oranges. However, the SpyderPrint profile (colors) has lager gamut especially for darker greens, blues and blacks. The dark colors go deeper.

It almost seems to me, if it is possible, that the whole block has been shifted in the 3D space, so that the two cubes are not aligned two each other.

I was wondering if it is possible that the created RGB values, read from the original SpyderPrint target image, using script read_image_patch_colors.py, is slightly shifted from the values that the SpyderPrint software uses internal in their profiling generation. Thus giving a result from SpyderPrint that is similar to Argyll colprof, but slightly shifted?

Is this possible, or logical?

Any idea on how to improve this?

If you look at the attached ti2 files the RGB values look quite organized, but could logically be rounded to a more perfect distribution and selection. That could be one cause, but those are only decimal changes.

Another issue is that the XML file exported from SpyderPrint has a few tags:

<RefWhite>9233    410    -866</RefWhite>
<RefBlack>2273    192    6</RefBlack>
(the values are devided by 100 to get Lab)

These reference values I could not find how to use when making ti3 file for Argyll colprof, thus I suspect that SpyderPrint makes use of these resulting in a darker profile.

Does anyone know how one may include Lab reference white and black values when making a profile using colprof?

I was hoping that I would be able to make a better profile using ArgyllCMS, despite using SpyderPrint colorimeter scanner. If Datacolor is doing something odd in the process, then maybe even the exported Lab values is difficult to use in other ways???

The Argyll made profile has an ok accuracy (given it is a laser printer), which is measured as follows:

From colprof: peak err = 8.923135, avg err = 1.235774, RMS = 1.646434

profcheck -v -k -h Lab-cLUT_Med.ti3 Lab-cLUT_Med.icc
No of test patches = 225
Bin 0, 0.000000 - 0.150261,  9.2219%, count 18
Bin 1, 0.150261 - 0.307838,  17.0991%, count 35
Bin 2, 0.307838 - 0.464531,  15.7216%, count 32
Bin 3, 0.464531 - 0.625249,  11.9749%, count 25
Bin 4, 0.625249 - 0.784371,  9.6760%, count 20
Bin 5, 0.784371 - 0.933125,  9.8329%, count 19
Bin 6, 0.933125 - 1.083777,  6.1320%, count 12
Bin 7, 1.083777 - 1.241904,  6.8158%, count 14
Bin 8, 1.241904 - 1.407517,  6.5077%, count 14
Bin 9, 1.407517 - 1.580047,  4.4620%, count 10
Bin 10, 1.580047 - 2.003044,  1.8199%, count 10
Bin 11, 2.003044 - 3.212793,  0.6364%, count 10
Bin 12, 3.212793 - 7.850738,  0.0996%, count 6

Thanks for your time and feedback

Rgs,
K