It seems my early enthusiasm was a little misplaced, as "some degree of driver-side color management/mapping" became considerably more involved than I'd first expected.
It turns out that rather than the subtractive Cyan/Magenta/Yellow primary data sent to the earlier CP-series printers, or even the additive Red/Green/Blue primary data used by many others, The CP820 and CP910 expect their data in a perceptual, Luminance-based format, not unlike what one finds in television and video formats.
My best guess is that the printers use the JPEG YCbCr444 format and coefficients (as opposed to the ITU-R BT.601, BT.709, or BT.2020, or various YUV color spaces). Conversion between these color spaces is fairly straightforward. Here's the code for the JPEG transformations:
/* All values are in the range of 0-255 */ Y = R * 0.29900 + G * 0.58700 + B * 0.11400 Cb = R * -0.16874 + G * -0.33126 + B * 0.50000 + 128 Cr = R * 0.50000 + G * -0.41869 + B * -0.08131 + 128 R = Y + + (Cr - 128) * 1.40200 G = Y + (Cb - 128) * -0.34414 + (Cr - 128) * -0.71414 B = Y + (Cb - 128) * 1.77200
Unfortunately, due to Gutenprint's internals and the fact that the printer expects the YCbCr data in a plane-interleaved format, this will be a little more invasive to implement. Consequently, it will likely not land in Gutenprint until after the 5.2.10 release.
In other photo printer news:
- Multi-cut support for selected printers is in the works
- Support for the Sony UP-CR10L (and DNP DS-SL10) is in the works
- Improved Kodak 6800/6850 status reporting
- I'm awaiting sniffs from Mitsubishi CP-K60DW-S and CP-D9550DW-S printers, which should lead to improved support
- The Mitsubishi CP-D70W is confirmed to work, but apparently needs major color curve tweaking
As always, the best way to improve a printer's support is to send one my way, preferably accompanied by programmer documentation. :)