[argyllcms] Re: Black turning down problem (the -r trick)
- From: Nikolay Pokhilchenko <nikolay_po@xxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Wed, 12 Jan 2011 20:36:07 +0300
Elena, I'd recommend You try another instrument for judging is the -r level
appropriate: the invprofcheck. Unfortunately it works only with "full" profiles
with valuable B2A table. I recommend -h key for invprofcheck too.
When the -r parameter is increases, the error is decreases. Error shows You
degree of "notsmoothness" of B2A table in whole gamut, not only on gray axis as
xicclu and at gamut edges as an RGB gradient test.
IMHO.
Wed, 12 Jan 2011 17:27:05 +0100 письмо от Elena [service address]
<1007140@xxxxxxxx>:
> 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:
