[argyllcms] Re: Verifying profile quality of LUT-based scanner and printer profiles
- From: Graeme Gill <graeme@xxxxxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Mon, 20 Mar 2006 00:29:28 +1100
Milton Taylor wrote:
Having created an apparently -qu [i.e. high quality] LUT profile for my
film scanner, it reports a very low avg dE (around 0.3) for the IT8
target slide. This sounds pretty good to me. (The peak was about 3).
With the currently available release of Argyll, it is probably advisable
to specify a fairly high level of smoothing, by using -r 1.0 or so.
The next version will have better defaults in this regard, and
shouldn't usually need a -r parameter. This should result in a smoother
profile with a higher self fit dE.
But is there any way to verify the 'smoothness' of the profile? In
particular, I'm thinking about the discontinuities that might exist in
the LUT tables.
The interpolation algorithm doesn't really allow discontinuities,
but it can have "overshoot" or "ringing".
This thought came to me whilst profiling my cheap and nasty Canon i865
printer using the 'poor man's method'. (Using my Epson 2450 flatbed as a
'colorimeter'). After profiling the printer, again as a high quality LUT
profile, I printed a scan of my IT8 reflective target, and was very
amazed at how close the print is to the actual target visually.
However, I then printed a different sort of test chart from Norman
Koren, both through the new printer profile and also straight to the
printer as raw unmodified RGB. (The chart is at
http://www.normankoren.com/Stepchart_large_HSL.jpg)
The one that went straight to the printer was interesting. The hues are
not evenly represented in terms of their 'share' of the 360 degree hue
spectrum. Yellows and cyans are quite skinny compared to blues, reds and
greens. However, at least it came out with very even colour progressions
and shifts in the Hue/Sat and Hue/Light charts. The colours are of
course just reflecting raw RGB inputs, so I would expect it to look
smooth, even if these are non-managed colours.
Actually, it's not something you should expect would always come out
smooth, because the printer isn't an RGB device, and (assuming Canon isn't
using a simple 1.0 - RGB type conversion to CMY), mapping the RGB gamut
onto the quite differently shaped CMY(K) gamut, while maintaining
some degree of absolute and relative color matching, together
with smoothness, is not that easy.
However, when printing the same chart through the new profile, (using
sRGB as the assigned source profile), the result looks pretty awful.
There are clearly serious discontinuities in the LUT tables, as you can
lots of banding and distinct edges and steps at numerous points in the
HSL charts.
It depends rather critically what intent you were using, and what source
gamut the profile was setup for. To have a hope of a smooth result for
the sort of "RGB rainbow" tests in the above chart, all this has to
be right. (The printer is effectively using a device link when it's
running in "RGB" mode, so that it can get it right.)
So, you need to generate the profile using -S srgb.icm (or -s srgb.icm),
and then have srgb.icm as the source profile, and use perceptual
intent for the destination (printer) profile when converting the test chart.
(or you need to convert using a device link with the right intent).
Now, assuming you did set it up this way, it might still give a
disappointing result. The "rainbow" tests are pretty tough, and
not often reflected in real world images, since the rainbow
is the surface of the gamut, and few colors in a real image
are on the gamut surface. All I can say is, that this particular
aspect will be much improved in the next release of Argyll,
since it's something I've been working on.
Generally the result through the relative colorimetric intent
will produce banding type artefacts, due to the effects of gamut
clipping. You shouldn't expect smoothness for any intent except
perceptual. Even saturation may be a bit bumpy at the source gamut
surface, since it prioritizes saturation over other qualities.
Now of course, this could be due to:
(a) It being a cheap printer, with 3 dye-based inks plus photo black
(b) It being an RGB interface
(c) Using the flatbed scanner to profile the printer
All these factors can of course, exacerbate banding effects.
So here are my questions:
1. I assume a LUT approach is always going to show discontinuities in an
HSL chart like this. Is it something to be overly concerned about? Am I
seeing something here that is much worse than normal because of (a), (b)
and (c) above? I imagine it would be a problem if you were printing
anything that had a smooth gradient in it, like a skin tone or a blue
sky...I'm sure unwanted banding would be the result. I once saw this
happen on some lab proofs from a commercial colour lab, and they
couldn't explain why it happened. But I think I can now!
It depends a lot on whether this effect is confined to source gamut
surface colors, or whether it also occurs for blends of in-gamut colors.
2. Do commercial inkjets (such as Epson 7800, 9800) use LUT profiles or
shaper/matrix? (When I softproofed the Koren chart in Photoshop using
the Epson printer profile it looked pretty good to me).
They will all use LUT type profiles (or their equivalent) since they are
all CMYK/subtractive devices. A matrix only gives reasonable accuracy
for additive devices.
3. How much better would the result be if I had measured the printed
charts with a real spectrophotometer?
Possibly more accurate colorimetrically, and possibly smoother if the
limitations of the scanner & scanner profile are quantizing the
patch values, or adding noise to the readings.
4. How can I be sure that my film scanner profile doesn't show similar
disturbing discontinuities...is there a way to visualise this? Once
again, I'm worried about banding when it's scanning anything with a
smooth tone progression in it. Perhaps I should try making a
shaper/matrix profile for it to see what that produces.
You could try running a similar "rainbow" test chart through the
scanner profile, and see what sort of effects you get in the output.
It is a bit difficult separating where an effect comes from though. Is
it in the scanner profile, or in the way the output colors are being
represented on the display ? You wouldn't expect any sort of color
accuracy with this test of course, unless you had a way of
converting back to the scanner colorspace without introducing
banding effects.
5. Why is it not possible to produce a shaper/matrix profile for an
output profile? I assume it would have to be CMYK so that the real ink
channels were being directly controlled by the printing application.
You can attempt to do so for a printer that emulates an RGB device,
and if it's emulation was very very good, and it compressed the gamut
sufficiently to emulate an additive device (leading to a poor gamut),
the matrix might fit reasonably well. But if the emulated RGB
at all reflects the behaviour of the underlying CMYK printer and
its gamut, the matrix will be a very poor fit to the device
(ie. 10+ delta E errors is the sort of thing I'd expect).
Graeme Gill.
Other related posts:
