[argyllcms] Re: Average bug/Density curves/ xicclu -g predictability issue
- From: Graeme Gill <graeme@xxxxxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Mon, 24 Jan 2011 11:25:52 +1100
Elena [service address] wrote:
Hi,
Now assume (by axurdity) that you convert and print the source RGB image
from the so computed RGBxCMYK lut without any interpolation, i.e resulting
in severe quantization bands (I don't remember right now what the used grid
resolution was, but surely not 256^3 !): no noticeable glitches were seen.
Yes, that's what I would expect. Same with the Argyll code. If you were to
convert each pixel using xicclu -fif, and print it with a printer that
can print each pixel (ie. not a printing press that could have registration
problems), then the problem would not be evident, since there is no
interpolation in device space.
It may then be worth spending two more words on how I then decided to fix the
problem.
I choose to get rid of K for how many problems a 4D space is prone to give: too
many
combinations with the (almost) same visual result, and so the risk of the above
mentioned discontinuities. I limited the problem in the 3D space. The RGB->CMYK
conversion was performed algorithmically, in an idealized fashion, applying a
rigid
mathematical GCR toward a well extabilished and unchangeable mathematically
defined K
curve, taking just the total ink limit into account.
Then I "profiled" the RGB side (using the same bruteforce search method of
above)
generating the RGBxRGB LUT. I was quite happy with the results for those times.
Sure. That will solve this particular problem. The problem is that it
(typically)
compromises the gamut severely. This article
<http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.28.47>,
illustrates the problem. The classic result of a poor choice of separation (ie.
using the one in the PostScript Red Book, 7.2.3 in the 3rd edition), is a gamut
that
looks like the CMY cube with the addition of a thin "spike" at the black end,
where
the K has an effect. What's missing is the dark saturated colors.
Now I'm sure that you could hand tweak the separation to improve on this,
but that's the point: the ideal separation depends on the characteristic
of the device. So to get a good gamut and smoothness, you need to first
characterize the device as CMYK, determine the largest possible gamut
that will be smooth enough to avoid problems due to the device interpolation
in the B2A table. Having determined this separation, you can then process
the CMYK characterization to create the profile, or you could print a
new 3 dimensional test chart to characterize the device in more detail
using the chosen separation (a two pass approach that becomes a necessity
for more than 4 inks).
In general I (and perhaps everybody I think) want a profile to be reliable on
the most different situations. Bumps/discontinuities will show up when printing
synthetic graphics with gradients rather than photos. But they can show up even
in real world photos, if you're unlucky enough to hit some troublesome slice
(maybe
a yellow hat showing colored bands in the shadow areas, or distorted green
shadows in
foliage, etc.)
They can show up, but mostly they don't. With well behaved devices (CMY + 100K
cube
contains the CMY cube), it will never show up. I would love to fix this
problem, and I have a plan about how to tackle it, but that's not what
I'm working on at the moment.
Graeme Gill.
Other related posts:
