YAAW - Yet Another Argyll Wrapper

[rjanowsky]

which Argyll version are you running Ron?

V3.5.0

 

[riclin]

FWIW - YAAW is now on github:

https://github.com/riclin-au/YAAW-Yet-Another-ArgyllCMS-Wrapper-Workflow-

Future updates will be maintained there.

r/

 

[rjanowsky]

Richard, would you like to keep this thread active to communicate about YAAW or is the use of Issues at github the way to go?

 

[riclin]

Richard, would you like to keep this thread active to communicate about YAAW or is the use of Issues at github the way to go?

I don't think that one precludes the other Ron - we can maintain the thread here with the only change being that I'll house any updates or upgrades on Github rather than using my personal Google Drive. I think that's a more robust storage solution. That said, there doesn't seem to be much interest in yaaw - I think that you've just about been the only person trying it out. Oh well - I like it anyway - I've run up almost 30 profiles now and yaaw handled each task cleanly and without a single glitch!

 

[rjanowsky]

I also did a good bunch of profiling with YAAW and can confirm that everything is going smooth and works as expected. But for me a Step 5 : Analyse & Compare Profile would be high on my wishlist. A section to get detailed reporting on the profiles quality and the possibility to visually compare with another profile. Something like Check & Refine in ChromIQ. Not really needed, but - for me - very helpful.

 

[riclin]

I also did a good bunch of profiling with YAAW and can confirm that everything is going smooth and works as expected. But for me a Step 5 : Analyse & Compare Profile would be high on my wishlist. A section to get detailed reporting on the profiles quality and the possibility to visually compare with another profile. Something like Check & Refine in ChromIQ. Not really needed, but - for me - very helpful.

In the interests of my KISS objectives I deliberately opted to not include a rotatable 3D html viewer. However I assume that you have noticed the static "View Gamut" tab at the bottom of the Execution page? That displays a visual representation of the profile's L*a*b* parameters compared to both sRGB and aRGB gamut limits, as well as pertinent profile metrics for the ICC being reviewed. To facilitate profile comparisons, the gamut viewer window can be left open and a different config loaded, with the "View Gamut" also applied to that other profile which then opens another "View Gamut" window for direct side by side comparison,

 

[rjanowsky]

In the interests of my KISS objectives I deliberately opted to not include a rotatable 3D html viewer. However I assume that you have noticed the static "View Gamut" tab at the bottom of the Execution page? That displays a visual representation of the profile's L*a*b* parameters compared to both sRGB and aRGB gamut limits, as well as pertinent profile metrics for the ICC being reviewed. To facilitate profile comparisons, the gamut viewer window can be left open and a different config loaded, with the "View Gamut" also applied to that other profile which then opens another "View Gamut" window for direct side by side comparison,

The "View Gamut" is really helpful in comparing two profiles. On macOS I can use the ColorSync Tool to get a rotatable 3D view. For me that's fine.

But additionally I would like to get an info about the worst 10 or 15 patches. Now I have to use an extra shell command like

profcheck -v2 -k -s target.ti3 target.icc | head -15

to get that data. Would be nice to have this automatically displayed at the end of Step 4 on screen and written to the log.

 

[riclin]

The "View Gamut" is really helpful in comparing two profiles. On macOS I can use the ColorSync Tool to get a rotatable 3D view. For me that's fine.

But additionally I would like to get an info about the worst 10 or 15 patches. Now I have to use an extra shell command like

profcheck -v2 -k -s target.ti3 target.icc | head -15

to get that data. Would be nice to have this automatically displayed at the end of Step 4 on screen and written to the log.

The addition you suggest is relatively trivial, but I don't think that the resulting data would be particularly useful. Graeme Gill notes:

".... lower delta E values are not always a better measure of how good a profile is. The aim of a profile is to model the underlying characteristics of a device, not to slavishly reproduce the sampled data point values. Sampled data point values contain device variation and instrument reading inaccuracies, and a good profiler will try and filter out this noise, resulting in some deliberate differences between the profile and the sample points used to create it."

So I have doubts regarding the additional information that would result from your suggestion, and suspect that data could be of dubious value and may be potentially misleading. Fortunately it is a simple matter to construct a shell script to run profcheck outside of YAAW if you think that the additional information is genuinely useful to you - in which case I would be interested to read how you are using it. You may yet convince me

r/

 

[itsab1989]

I have read those notes as well. But especially if you are an unexperienced user and maybe are a little nervous when doing your first measurements your handling of the device might not be as steady as required. In this case you might have a shaky hand and ruin the readings on some patches. I personally had some very high deltaE (I am talking about somethin like in the 15 area) values for a few patches on my first attempts. Thanks to the profcheck report I knew which ones thise were and it allowed me to measure the strips with the highest deltaE patches again. When I then rebuilt the profile this was very noticable in the prints.

 

[rjanowsky]

Well, I think both sides have valid arguments. For me it's merely out of interest how far my printed target is away from the expected values. Using an i1pro with the standard ruler/jig doesn't give much room for user created mis-measurement, but that might be completely different with other devices. Way off values might indicate reading errors, but also - perhaps - problems with the printer (i. e. nozzles not firing). Ultimately it's a personal preference, how one would like to interpret the values. As you already stated: No big effort to run a shell script afterwards and also append the data to the existent log file.