[argyllcms] Re: Printer gamut

Milton Taylor wrote:

 Having regenerated my profile for the i865, this time using the
 Canon's own profile as a starting point, and also putting some
 channel step wedges into the targets, I got some interesting results:


Milton,

by the way, have you also tried to play with different print modes and driver settings?

For instance, with Canon's bjfilterpixus Linux driver for the i850 in conjunction with 3rd party inks and paper, I eventually got noticeably better results with "--renderintent graphics" than with "--renderintent photo".

This driver's "graphics" mode seems to result in a larger gamut and also seems to be more suitable for profiling than the photo mode; it looks like the graphics mode is rather some kind of "raw RGB" mode, while photo mode rather implements a perceptual intent, accepting sRGB input - at least in conjunction with original Canon consumables.

In photo mode, I got for instance very weak blue tones. Moving up the cyan slider in the driver improved the gamut in the blue region, but on the other hand this resulted in posterization artifacts (actually I guess, that the root cause of these artifacts is the use of only 8 bits, where 16 bits would be more appropriate; but this happens somewhere inside the driver, so there's no way to exert influence from outside, expect not moving up the slider and living with the limited gamut).

With the driver's "graphics" mode, I'm now more satisfied (though still not 100% perfect), but I still don't know, whether I have found the optimal settings for my paper and inks yet, since there are a couple of driver settings, sliders, etc. which can be combined, and nobody knows, what exactly a particular slider really does (e.g. does the cyan slider affect cyan gamma? Or does it set an ink limit for cyan? etc.). Thus finding the optimal settings is a tedious try-and-error procedure, which can waste a large amount of time and consumables ...

With an RGB printer driver, unfortunately the achievable results depend heavily on the driver's behaviour and the used driver settings (-> i.e. how the driver creates the CMYK separations from RGB). The ability of a color profile to compensate flaws in the driver is quite limited; for instance if the driver already truncates the gamut, the profile can't bring the lost regions back, or if the driver introduces too steep dLab/dRGB gradients in some regoins of the gamut, the color space probably cannot be profiled very well, etc.

Regards,
Gerhard


 1. I think the profile gamut now is a broader and smoother
 representation than what I had earlier. (I also dropped back to -qm
 -r 0.8). So posterisation in the sRGB hue/sat rainbows due to gamut
 clipping time is not nearly as bad, and at perceptual intent it's now
 much better than my earlier result which lost the best greens.

 2. Examining the printed channel steps is quite revealing: red and
 green both range tonally quite well, but blue is a big problem.
 There's not that much tonal variation in it. Also, the profile maker
 came up with the warning about the gamut being non-monotonal. I had
 already suspected this was the case, but this just confirms it.
 (Could be the scanner too I guess, but less likely?)

 3. The greys are less neutral now...the profile is pushing them too
 far off course into green territory. It raises another question in
 my mind about how the printer decides when to use 'black' ink instead
 of a mix of CYM. I would say now that it's not using black at all.

 4. A more general question that applies to any printer: assuming that
 a printer is reasonably well calibrated to start with, and can be
 trusted to be come up with decent greys when raw device values for
 each channel are equal (ignoring paper color and uneven spectrum
 lighting for the moment), is there any way to give more weight to
 those points at profile generation time, to avoid this sort of shift?
 Of course, it's possible that the error is coming from the
 flatbed...easy to tell: I'll just compare the readings of a true grey
 scale with a black-only grey-scale that comes from the printer.

 I accept that I'm fighting an up-hill battle here, as obviously the
 RGB->CMYK algorithm in the printer is going interfere a lot, and
 using the flatbed is a poor way to reliably measure colors this way,
 but I'll keep pushing the envelope as far as it can go, for the pure
 fun of it of course.

Milt


Other related posts: