[argyllcms] Re: Colprof feature request: amount of black point hue correction control

Graeme Gill wrote:
> Nikolay Pokhilchenko wrote:
>> I've built many profiles for "RGB" inkjet printers and struck the
>> black point hue shift
>> problem many times. When there is no any printer RIP control (just
>> RGB-driver only)
>> it's impossible to control printer black point (R=G=B=0). The problem
>> is aggravates by
>> the lack of contrast on some media. Usually, the colprof is aspiring
>> to the black
>> neutrality at the cost of maximum b/w contrast. But in some cases the
>> higher contrast
>> (*L range) is more desirable than black neutrality or color mapping
>> tolerance. May be
>> the feature, similar the "-k" in dispcal will be usefull for colprof
>> too. It may
>> control black "fake" level for perceptual and saturation rendering
>> intents. For
>> example, with "1" value the black point is about neutral, but lighter
>> than darkest. The
>> mapping is performing as usual. With "0" value the intended black
>> point is shifted to
>> match the darkest device combination. There will be tone shift on
>> print, but the
>> contrast may be visibly higher.
>
> Hi,
>
> What you describe is already what is meant to happen. By default when
> using gamut mapping the neutral axis mapping uses "extend and bend"
> at the black point to get neutrality without compromising contrast
> ratio. It seemed to be working last time I checked, but that was a
> while ago.
>
> I think you need to send me an example (.ti3, profile, options
> used etc.) so that I can reproduce the problem you are seeing.
>
> Graeme Gill.

I think to remember that quite some time in the past I had encountered
an issue where obviously an ink limit of 290% prevented the B2A tables
from outputting low RGB numbers close to [0,0,0]. Supplying the option
-l300 to profile and icclink solved the problem. I still don't know why
an ink limit was used for RGB at all (does this make sense?), and why
profile was assuming an ink limit of just 290%, when no explicit -l
option was specified on the command line. I don't know, whether this is
still a potential issue with recent 1.0 versions.

Regards,
Gerhard

Other related posts: