Re: Custom ICC Profiles/Conversion Rending Intents
Re: Custom ICC Profiles/Conversion Rending Intents
- Subject: Re: Custom ICC Profiles/Conversion Rending Intents
- From: Graeme Gill <email@hidden>
- Date: Mon, 20 Jun 2005 14:31:19 +1000
- Organization: Argyll CMS
Chris Murphy wrote:
Perhaps :) But it's not wrong for the UI to suggest, for a given data
set and GCR that there is no point in requesting a higher ink limit
because you aren't going to get any further increase in density, just
use more ink. In fact, it's entirely possible by using more ink, you'd
end up with a lower density.
It's possibly profiling package dependent, but I don't think it
should that way either. It's unlikely that an increased ink limit
won't change the gamut in some way, either increasing it
(albeit only slightly), or making it ill-behaived ("non-monotonicity",
"aliasing", or "folding"). If increasing an ink limit increases the gamut
in a well behaved way, then in principle there is nothing
wrong with using the extra gamut (color wise), and it's really up
to human judgement whether the ink limit is a reasonable one.
At the gamut edge the GCR should have no effect, since (it can
reasonably be assumed), achieving a given target color is a higher
priority than the GCR preference.
If increasing the ink limit results in responses with a lower density,
then ideally the profiling package would not make use of such aliases,
but would naturally stop at the foldover edge.
What sort of criteria would one use to automatically compute
a reasonable ink limit, based on the device response (and ignoring
other factors like ink running off the page etc.) ? The ink
limit has an effect on multiple ink combinations, so examining
any sort of 1D plot though the colorspace may miss things.
Generally it is assumed that the ink limit is a much
higher priority than the GCR, so it should be adhered to under all
circumstances. GCR is a preference, adhered to if possible (at least
that's how my software works.)
They're absolutely related. So long as CMY alone won't produce as dark
and neutral a color as 100K, some black generation is necessary, even
at a 400% ink limit. But as ink limit decreases, by definition black
generation increases, and vice versa.
Yes, the actual GCR will change with a decreasing ink limit, but this
is driven by the ink limit, not the target GCR. I guess it comes
down to how the concepts are presented. In my software the right way
to present it (I think) reflects what actually happens. It's a set
of targets in order of priority:
1) remain below the total ink limit
2) reproduce the target color
3) reproduce it with the given GCR
Now the actual result will depend on applying these rules
to a real device response, so while the ink limit
will always be adhered to (as the highest priority), the
target color may not get reproduced (It's out of gamut),
and it may not use the target GCR (the color can't be reproduced
with the target GCR).
Now you can argue that it would help if a GUI would present
the resulting behaviour of applying the set of objectives, so
that the user can interact with the real device response to
get the closest to their desired behaviour, and I would
agree with you. (in fact I've allowed for such a possibility in my
software, in a crude way. See <http://www.argyllcms.com/doc/xicclu.html#g>)
> Most packages consider it a
relative value leading one to believe the difference between a light
GCR and heavy GCR is the same for a 240% ink limit and 350% ink limit.
But that's not how it works. There really is no such thing as light GCR
for a 240% ink limit, if you're going to accept the status of black
generation as being a singular event. And for a heavy GCR, and ink
limit of 350% is probably never going to be reached (and if it is
reached, I wonder where the heavy black generation is!)
What you say may be generally true, although only at or near the gamut
surface. The GCR choice will have an effect in other areas of the gamut,
and won't be affected by the ink limit. I'd really ask "so what ?" though.
GCR is a secondary preference, that shouldn't affect the gamut size
or color reproduction. It may affect many other things (banding,
stability, sensitivity to lighting, black screen visibility), but
not the color reproduction (that's the whole point behind
a closed loop system.)
The ink limit should not be exceeded, but so long as the same black
point can be achieved with lower values, that's traditionally been
acceptable. The question is, do profiling packages adequately sample
enough black patches to do a stellar job of determining the black
point, or is this being interpolated and hence possible for it to be
wrong? My experience is when they produce an area of coverage less than
the ink limit, it's often not achieving the best possible black point
within the ink limit I've specified.
There is a set of difficulties to be dealt with (one way or another)
at the black end of a CMYK gamut. This is due to the nature of
the mapping. A 4D cube is being mapped into 3D colorspace by the device, and
while the geometry is plain and simple at the light end (7 vertices,
white, C, M, Y, CM, CY, MY), the geometry is very confused and overlapping
at the dark end (9 vertices, CMY, K, CK, MK, YK, CMK, CYK, MYK, CMYK),
and topologically, it can't be any other way.
The overlapping/interpenetrating geometry makes for poor behaviour that
is often difficult to manage given the sampling nature of the measurement
charts, and the discrete nature of the CLUTs, and with the interpolation
between CLUT nodes in device space.
(Currently my software doesn't handle this very well. It's something
I'm still working on.)
And if a light GCR isn't possible for a given data set, and ink limit,
I argue the UI shouldn't let me choose it. I agree that ink limit
should not be busted.
Technically it's possible to find output of a B2A table that exceeds
the ink limit, due to the nature of the interpolation. Just because
all the nodes of the multidimensional grid are at or under the ink
limit, doesn't ensure that the interpolated device values between the
nodes of a cell are going to be under the ink limit.
Wow, that's pretty silly.
It's not silly, it's the nature of the maths. Example, say
I've got an ink limit of 280%, and I've got a per channel
device lookup table curves that have a square root shape.
I could have a node with (output) CMYK values 70 70 70 70 %
next to a node with (output) value of 0 80 100 100 %.
This means that my raw CLUT node values would be:
49 49 49 49 % and 0 64 100 100 % respectively.
At 50% interpolation between these nodes, we would
get a raw CLUT CMYK of 24.5 56.5 74.5 74.5 %, and
output CMYK of 49.5 75.2 86.3 86.3 %, giving a total
ink of 297%, exceeding the limit.
It might be possible for a profiling package to ensure that
such things don't happen, but I'm not sure any package
is currently that sophisticated.
Maybe CMYK output device profiles need a
required black point tag, including both a device independent and
dependent value, so that the CMM can ensure the ink limit isn't busted.
It's not clear to me how that would help the situation.
I'd certainly like to see a total ink limit tag in profiles, as
this is essential in defining the gamut of the device.
Graeme Gill.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Colorsync-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden