[argyllcms] Re: Difficulty shaping Black ink curve for CMYK profile
- From: Graeme Gill <graeme@xxxxxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Wed, 19 Dec 2018 16:06:54 +1100
Samuel Chia wrote:
That's interesting. I actually see tonal reversals in gradients which was why
I didn't
assume it was only interpolation limitation.
Without specific examples, nothing like that is obvious to me.
It also seems to be greatly affected by the profile ink limit setting. I
suppose that's
tied to the interaction with the device response.
In what way is it affected by the ink limit setting ? - your example only used
400%.
This profile was already built with "-qh" (33 CLUT points). I'll certainly
try "-bu". Is
that the same as using "-qu"? How many CLUT points would it create?
-bu is a way of setting a B2A table resolution that is independent of the A2B
table.
I think -bu is 45.
Unfortunately, as I have mentioned to you before, specifying the source gamut
and using
the device link workflow you taught me still does not allow me to fully
specify the
luminance vs saturation tradeoff for gamut mapping.
I'm not aware of anything that colprof can do that collink can't in that area.
In addition, ArgyllCMS crashes with
the large TIFF files that I work with to make large prints.
Standard tiff is limited to 2GB or less, but if your files are less than that,
I'm not aware of any problems with cctiff and large files, unless libtiff
itself simply
runs out of memory.
I am thus prevented from using
this otherwise higher precision method.
I understand Photoshop can use device links.
It's also strange that the i1Profiler profiles
never suffer from this Mach banding interpolation issue, but I've seen it
rear itself with
Argyll for both RGB and CMYK printer profiles. Makes one wonder why.
I've never seen this problem to the same degree in RGB profiles.
Since I'm not privy to the workings of i1Profiler, or even have easy access to
profiles created with it, I can only speculate that it goes about things in
a different way. For instance, if you aren't concerned about the device
behavior being non-monotonic, don't mind loosing some accuracy, and don't mind
loosing some control over clipping behavior, you could apply an ink rule to the
CMYK values and simply treat the B2A PCS -> CMYK the same way as the A2B table,
and model it with scattered point grid fitting. Or maybe they have some hand
crafted per channel input and output curves. Or maybe they better fit
the expected PCS source gamut to the table. Or something else more clever, I
don't know.
If there were any simple improvement to ArgyllCMS in this area that
I'm aware of, then I'd make it. Maybe someone with access to i1Profiler could
do the necessary technical investigation of the contents of their B2A tag to
give me the essential hint. But short of ArgyllCMS miraculously becoming
financially
self sustaining, I don't currently have the leisure to investigate this in
the depth needed to solve this limitation, particularly when it can be avoided
by the superior device link workflow.
Cheers,
Graeme Gill.
Other related posts:
