[argyllcms] Re: Black turning down problem (the -r trick)

  • From: Elena [service address] <1007140@xxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Wed, 12 Jan 2011 17:27:05 +0100

Hello Graeme

On 11-Jan-2011, Graeme Gill wrote:

> The level of accuracy of the forward (A2B) characterisation of the device
> is quite important of course, but it comes down to judging where the
> color errors are being introduced. "Bumpiness" in the darker areas, 
> particularly
> near the gamut edges, with a visibility that is heavily influenced by
> the B2A grid resolution and black generation curve level, are a hint that
> there are black topology problems. Currently, grid point accuracy and maximum
> gamut size have priority over the black curve, and it is only the black curve
> smoothness that results in B2A table smoothness of K value. So nothing 
> prevents
> sudden transitions in the black level at grid points at the gamut edge,
> and the resulting device value interpolations of the B2A table can reveal that
> the device value interpolated color is very far from the color of the two grid
> points that are being interpolated between. Currently the best that can be 
> done
> is to choose a black generation curve that minimises sudden transitions at the
> gamut edges. Ink limits (total and black) may also have an influence.

Well, accidentally I found now a terrible trick which allows me to generate
profiles with a never seen smothness.
I know it may sound a blasphemy and it will hurt purists... the trick is
simply using an arbitrarily high level for -r in colprof, eg. -r5.
I know the major side effect here is having a generated A2B table which
won't follow so precisely the device response anymore, and I could hate
that... but I tried such a profile for my plain paper tests made with
the "offending" -kx and -r5: I don't see the bumps anymore ! And xicclu
now shows a K which is monotonically increasing.

I'm perfectly aware of what I'm doing: I'm tricking colprof to think the printer
combination has a more smooth and predictable behavior, when actually it's not 
so.

I admit this is somehow "hacking", and I know I'm perhaps lossing precision,
but I then generated a profile made with the -r5, -qh and a reasonably
well chosen k curve (just reasonably, not paranoically): well, I'm perhaps
lossing some dE, but when I saw my pictures and graphs printed out FAITHFULLY
and COLORFULLY, without any noticeable error, WHO cares of numbers ???

I'm almost convinced I will use this trick, even if to a lesser extent (r=1.5 
or so)
for quality paper profiles also, to generate smoother profiles, searching for
the best compromise between smothness and precision.

So I now wonder (since other people might want to follow this approach more
or less at their own "risk") if it could make sense for you to "split"
the -r behaviour independently for A2B and B2A tables generarion. So one
could still chose precise A2Bx tables (eg -r1 =0.5) and artificially smoothed
B2Ax ones (eg -r2 =4 or 5).

Couldn't this be at least a first, trivial but functional approach to the 
profile
smoothness problem (I read other people too on this ML discussing this topic) ?

/&

Other related posts: