Mike,

Your points are all valid. We are really in the domain of the improbable and the diminishing returns.

One small point about those colors outside the display gamut but inside the printer gamut. Out of gamut warning or iterative printing can help with the dead reckoning. Also your software could be used by people who create images that are outside your definition of a photograph, no?

Where can I find more info on PrinterRGB?

And for those using ACR, as of ACR v8.x (PS CC), it let you choose whatever profile you want to work in, including PrinterRGB if installed. Previous version only have the choice between sRGB, AdobeRBG and ProPhotoRGB.

I'm looking forward to 217.

Hi Mike,

There is a similar conversation taking place coincidentally right now over at Luminous Landscape about 16-bit printing and Bart made me aware of the discussion here yesterday. So I'll jump in.


Ideally, it would be best if the 8-bit conversion was happening last. It wouldn’t affect compatibility with any Windows drivers and would result in a higher quality print.


At least in the case of the Epson x900, the printer gamut portion outside AdobeRGB is significant, not just in the yellow and magenta but also in the blue, cyan, and green. So IMO there is a strong case for operating in a larger gamut. A lot of us are using ProPhoto for that reason or because they've been told it's the 'best' profile for that reason.  As long as one operate in 16-bit, there is no drawback to it.


Actually, you want a profile that fully encompasses both the source and the output, in our case the camera and the printer.
This is because processing could expend the source image gamut.

But the real issue, IMO, is not the volume of the gamut but the conversion to 8-bit. Even a grayscale image could potentially suffer if the conversion to 8-bit isn’t done at the last possible step.

Banding can easily be seen in dither free, noise free, 8-bit grayscale ramp.


I agree that noticeable banding/posterization caused by 16 to 8-bit conversion or by profile conversion with rounding without dithering will be very rare in real world photographs due to the presence of noise. Though it can make synthetic gradients and nearly noise free images look awful.
 
8-bit dithering performed at output resolution (e.g. 360 dpi) is invisible in inkjet prints. The dithering blends in the background noise intrinsic to the inkjet droplets dithering pattern.  Even under a loupe there is no difference between 8-bit-dither and a pure 16-bit print.
Now, you may run into problems if the dithering is done before pixel size upsampling.  At what enlargement factor does it become a problem? Don’t know…

To me, of all the software options out there, QU is by far the best solution because of its ease of use, versatility, quality of its upsampling algorithm, quality of its sharpening, etc.

But the 8-bit pipeline is Qimage’s weak spot, although it only shows in a tiny fraction of prints if ever. That's the cost of being nearly perfect in all other aspects.

Hi Mike,

Here is one: http://lucbusquin.com/sites/default/files/torture_test.tif.

It's in 16-bit ProPhoto. It exhibits lots of posterization/banding when printed in Qimage but none in PS and LR. Most of it because QI does the conversion to 8-bit without dithering while LR & PS use dithering.

Ideally you want to upsample the pixel size first and downsample the bit-depth last.

If that can't be done, a second best, would be to downsample to 8-bit with dither, and hope that all the pixel size upsampling and sharpening won't make the dithering pattern visible. Maybe make the dithering a selectable option? Not sure. And let's not forget that it's a non issue with the vast majority of real world photos.

Ernst,
I was the one pointing out the issue to Mike, so I hope he doesn't mind me answering here. Basically QI had a bug with how it handled ICC convertion of grayscale images. For instance, when a QTR printer profile was applied to a grayscale image, the prints were slightly off. In my experience the shadows were slighlty too light and midtone too dark. (It took Mike a whole 16hr to fix and post a new release...   Thanks Mike!)