[argyllcms] Re: using REFINE with ICCLINK to achieve -G results with -g parameter for original black generation
- From: Graeme Gill <graeme@xxxxxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Mon, 12 Feb 2007 18:23:57 +1100
Roberto Michelena wrote:
I want to use ICCLINK to create a link from an RGB space (typically,
AdobeRGB) to an offset printer profile.
I'd naturally want to use -G for best accuracy and detail, but I do
have some fears about the quality of the black generation done by
Argyll. The offset profile is generated by Monaco, which is reputedly
one of the best black generations (at least better than ProfileMaker).
It'd be a shame to lose it.
My first reaction is that mixing an RGB source profile with "refine"
is probably not going to work very well, simply because of
the white point and gamut issues. "refine" is only really intended
to be used in an absolute colorimetric workflow, although
your scenario may avoid these issues.
My second reaction is that it's hard to separate out the black
generation from inverting the AtoB table, without changing some
code. The only thing that currently does this type of thing is revfix,
where you can use the existing separation to determine the black
for the new separation. The current release icclink -G doesn't provide
the same facility at the moment, although my current development version
now does.
My third reaction is that you might be best trying icclink's black
generation first, before going to huge efforts to work around it.
To get a reasonably nice curve is a bit of a fiddle, but the results
in many cases are perfectly usable.
So I was thinking... if I do the link using -g, and then pass a large
set of RGB equal-step values (ideally corresponding to the gridpoints
of the input side of the link) through it, and pass the resulting CMYK
values through the original offset profile in reverse (abscol), end up
with a set of Lab values.
Which are not going to match exactly the ones obtained by RGB->Lab on
the same set of points and the same RGB (input) profile ; so then I
use REFINE on those two sets of Lab values, and do the ICCLINK -g
again but this time with -p (and the results from REFINE)... and so
on...
After some iterations I might end up with results similar to -G, but
having the black generation of the original CMYK profile, right?
I'm not sure you will. I suspect that whatever artefacts are introduced in
the -g linking are not going to be taken out again by refine, simply
because it isn't really feasible to do a refine in enough detail (high
enough resolution) to have this effect. The major attributes that
link -G has is that the output lookup is done by inverting the A2B
table. Generally the A2B table is reasonable smooth and accurate, because
the domain exactly covers the gamut of the device, making good use of
every grid point, and hence it's inverse is smooth and accurate.
One of the reasons that output lookups using the B2A table are bumpy is
that the grid resolution is poorly used, since only a small proportion of
the PCS domain is in gamut. That bumpiness is at the order of the grid
resolution, so you'd need a refine grid even finer, and it's effect
would then be swamped by the very coarseness you are trying to remove
by the next icclink -g step. Also, refine only attempts to correct PCS errors,
and a lot of the bumpiness in the icclink -g is in the separation, which
refine won't see.
> Is there a better/shorter way?
If you're using MSWindows you can try out the current development
version of icclink at <http://argyllcms.com/icclink.zip>, and see
if it does what you want. You're looking for the -ke option.
Hey, furthermore, if I do all the conversions via another (target) CMM
such as for example the beta Adobe CMM, then refine will also
compensate for CMM differences and I'd end up with a link optimized
for that target CMM...! ?
Again, most of the differences between CMM's are very fine grained, and
refine isn't likely to be practical at correcting such errors. Refine
is likely to be better at correcting overall shifts and inaccuracies, than
any "texture" errors that arises from the color machinery. The
latter is best tackled by changing the algorithms (ie. different
types of interpolation), or the approach (ie. inverting the A2B
rather than pre-computing the B2A table).
Graeme Gill.
Other related posts:
