Many thanks for the detailed reply Graeme. Some followup
questions/comments then:
I will rebuild the profile, but other than seeing what effect it has on dE (I would expect it might go up slightly?), I'm not really sure how to verify if it's any better.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.
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).
I use Photoshop so I'm not sure how this works with device links?
Interestingly, I did a soft proof of Canon's own icm profile for this printer, and the rainbow test shows reasonably well on that one...still gamut clipping of sRGB range, but only slight banding visible on the rainbow really. Even at Rel Col 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.
Fortunately I never need to use saturation, and as said before would probably not use perceptual much either.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.
I will check that out....if it's doing it with in-gamut colors I would be more worried.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.
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).
