[argyllcms] Re: Black turning down problem - help!
- From: Graeme Gill <graeme@xxxxxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Tue, 11 Jan 2011 10:51:03 +1100
Elena [service address] wrote:
See my other mail also. And please forgive me if I sound repetitive or
just chaotic =)
Thanks for your suggestions.
Looking things from the point of view of a non-experienced or little-experienced
user (experienced here is relative to argyll skill, not to CM in general!) - one
would expect a correct result already with some default parameter - and correct
here doesn't mean perfect, just overall correct and without major visual issues.
Most of the time, this is the case. I think that you have just started
with a particular device/paper/ink combination that highlights the current
shortcomings.
Now, when an user makes a choice on the K generation, usually this choice is
driven by factors such 1) I prefer a moderate or almost null K in the light
tones
because I don't want to see rosettes (or pepper) too early 2) I use a fine
screen so I want my neutrals being composed as most as possible by black, so I
minimize metamerism issues 3) I prefer a purer K at deep blacks rather than
a heavily composed one because my paper behaves better this way - EVEN IF
THAT WON'T PERHAPS RESULT IN MAXIMUM (measured) DEPTH, an aware choice, etc,
etc, etc.
Sounds reasonable.
One turns out instead to have to play heavily with xicclu just for eliminating
visual bumps or irregularities.
It depends heavily on the device/paper/ink. Many devices give very good
results without great sensitivity to the black curve.
Now, don't just consider my experience with plain paper any longer. Those
or even worse things do happen, with many different substrates. Think of people
who need to profile solvent printers, or to print on aluminium!
As I already said in the other msg, I think colprof should be wise enough to
detect major visual irregularities, and in the case, suggest a number of
patches to add to a new target trying to correct the problem. This could be
a file automatically generated, to be integrated in the previous ti1 target.
I'm telling that, of course, without having never written profiling code,
of course, so be tolerant... :-)
If it were just a matter of the number of patches, then this would be
reasonable.
But if it's really a problem with trading off gamut size for K smoothness,
then I have no means currently of addressing this, since fundamental
changes to the code are needed. Even if there was a means of automatically
solving the problem, you would find that this device/paper/ink combination
has a poorer gamut than ideal, since some of it would have to be avoided
to avoid the black smoothness problems.
What I suggest, is that -k parameters should be taken literally, within the
total responsability of the user, even if that won't perhaps lead to 100%
accurate results (note that one thing is accuracy, while smoothness and
continuity is another thing).
It's fundamental to the current code, that accuracy has priority over
desired K level. I don't think that simply having this the other way
around would really work, as it would then be a return to "open loop"
color, rather than measured color. It's possible perhaps to better
smooth the K generation curve to the K values at the gamut edge,
but this wouldn't solve the problem of the gamut edge itself
containing sudden changes of K value. The ultimate solution is to
trade gamut for K level smoothness/consistency, and in that sense
make K a priority over accuracy.
Graeme Gill.
Other related posts:
