[argyllcms] Re: Average bug/Density curves/ xicclu -g predictability issue

  • From: Elena [service address] <1007140@xxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Sun, 23 Jan 2011 15:00:18 +0100

Hello Gerhard

On 23-Jan-2011, Gerhard Fuernkranz wrote:

> Iin case of your particular device (i.e. the ofps2.ti3 you had posted) I
> wonder, though, whether a black generation which attempts to maximize
> overall smoothness mightn't possibly decide not to use black ink at all
> (or to use it just rarely in some regions)?
> [ Btw, would you be willing to renounce the usage of black ink, and to
> print with CMY inks only, if this would be the case? ]

Good point :-)
Firstly I must specify that I also tried to generate a profile with
the -kz option to check the result. The result was very smooth and without
any noticeable bumps [btw the data I posted links of are already obsolete,
a bigger target was then created, measured and averaged].

But I'm not sure however if dropping K is a good choice or just a Pyrrhic 
victory!
After all the inks I'm using are highly metameric: the prints look very 
different
when viewed in sunlight, dayshadow, fluorescent light or incandescent light.
Using K gives dramatic improvements in metamerism.

Btw, don't think my concerns of continuity/smoothness are just related to
the tests I'm making on plain paper, of course! As I told, this is just a
way to amplify conceptual problems, to make them more detectable and to
understand and try to fix them. From what I found now (more and more tests
have to be done of course) the smoothness problem arises anyway, even on
papers where I can reach 100% K in the blacks. The fact that with plain paper
and these inks you are forced to keep K at 20% or so at the ramp end is
not of course the primary cause of problems: once you select the proper
curve you obtain a smooth behaviour - but IN THE GREYS at best.

>> course] using link profiles or some other argyll tool [I'm not very expert 
>> here...]
>> to create an abstract (idelized ?) CMY->CMYK separation, then profiling the
>> CMY side and then linking the two profiles together... not sure I could 
>> explain
>> well
>
> Didn't you say, that you did implement the driver yourself? You are
> certainly free to change it so that it expetcs CMY or RGB input, doing
> the desired CMY -> CMYK (or RGB -> CMYK) separation internally. Then you
> can profile it simply as CMY or RGB device.

Oh yes, of course, surely :) Just it's not the way I like to work to
send RGB or CMY values to the driver. I like the versatility of
working in CMYK - for example in documents editors when you are mixing
maybe photos and text and graphics, and you think in CMYK terms of course, not
RGB. You there will choose maybe clean K for text, C for blue shapes, etc.
As usually graphicians do. The generated A2B table is very reliable and precise
with this respect and gives very predictable results. Just, I'd like B2A tables 
to
work in a more smooth manner. I don't like to be doing too many things "by 
hands":
since they invented the ICC profiles, it's a right thing using them.

But when I see severe channel swappings analyzing a slice I'm concerned that
something at the orygin is perhaps wrong and could be seriously optimized.
I have collected many slices showing troublesome areas, even from quality
papers profiles where there's not that K turning down issues.

So I'm currently stuck with this idea, that colprof should calculate a
K curve based on the given parameters, but then it should really KEEP
that K shape thru all tints as a main reference rule for separation,
not for neutrals only, being at most allowed to drift just SLIGHTLY
from it if it thinks it's good to, but always keeping it as a main reference,
to detect whether severe discontinuities will be introduced or not.

/&

Other related posts: