Hi Luc,

Indeed, I think it would be a mistake to dither this soon in the processing pipeline (upon opening the file), even before resampling to output size and output sampling.

It may also be useful to send Mike a copy of your Output profile, although you say that with that same output profile PS/LR do not exhibit as much posterization/banding. It might also be interesting to try Raw converting the image to pRGB or BetaRGB instead of ProPhoto RGB (PPRGB), and see if that makes a lot of difference in this particular case.

Cheers,
Bart

There is so much going on in this debate that I can't possibly cover it without writing an entire article.  I'll answer a few questions but first I'll just cut to the chase and say... the best solution is to stop using color spaces that are much too large for the job (ProPhoto)!  Just use Printer RGB (pRGB) and be done with it.  It is significantly larger than Adobe RGB, large enough to hold the gamut of any inkjet printer, and not so large that it requires 16 bits/channel.  That said, the need for something any bigger than Adobe RGB is more rare than you think.  There are a lot of factors to consider:

(1) Changing from an 8 bit to 16 bit pipeline isn't like flipping a switch.  The entire internal code base has to be changed.  All Windows graphics API's are 8 bit based so the code has to be completely rewritten and many third party modules have to be dumped and custom code written.  Then you have to deal with bugs and the fact that some people are already feeding QU 1GB and larger images and now with the innards being 16 bit, memory requirements double so without a major rewrite of the memory management, you can only load images half the size.  There will be a speed slowdown as well.  All... for nothing really.

(2) To your point about the gamuts, for a photograph, you only need a gamut large enough for the union of your camera's sensor gamut (yes, they have gamuts) and your printer gamut, not their "universe" (both combined).  If your camera can't reproduce it, it isn't there to map to your printer's gamut.  If your camera can produce it but the printer can't, it'll map to the printer's gamut hull never to exceed it (physically impossible to reproduce).  I get your point about taking the camera image and editing it so that the colors in the photo ARE outside both of those gamuts but honestly, where are you going to edit that?  On your screen which has a smaller gamut than even Adobe RGB?  I don't think that's realistic.  To actually need ProPhoto, you need all of four things to happen: (a) you need a subject to photograph that actually has colors outside the Adobe RGB or Printer RGB gamuts [or something you intend to cleverly modify beyond those gamuts - although then it becomes something other than a photograph IMO], (b) that color has to be inside the camera sensor's usable gamut, (c) the color has to also be inside the printer's gamut for the ink/paper, and (d) you'll have to print using relative colorimetric intent else the color you want won't print anyway due to scaling... and with RC intent, if there are any colors in your image that are outside your printer's gamut, your posterization in those areas is likely to be worse than if you had just rendered in a smaller gamut and used perceptual intent!  It's a complicated scenario: kinda damned if you do and damned if you don't.  99% of the people who are using ProPhoto are using it because they heard some blogger say it's good.  And he said it's good because "bigger is better".  And their images are likely no better (probably worse) as a result.

(3) ICM is not a "smart model".  There is so much fluff going on inside profiles WRT gamut mapping (particularly with perceptual intent) that using an overly large gamut like ProPhoto for your photos can actually cause some images to look worse.  The ICM model doesn't look at image content so it'll always assume you need as much "room" as is in the source profile whether it is used or not: so "making" colors that look as vibrant as ProPhoto can contain just for the heck of it isn't a good idea.

All that said, I did already build in one level of dithering into 217 which should be out later today, giving us 9 bits (512 virtual levels as opposed to 256).  It's limited in that we're still starting with 8 bits but being able to render the output of the final profile conversion into 9 bits dithered does help smooth out posterization in those ProPhoto torture tests.  But you really have to make a deliberate effort to find a man-made mathematical gradient that shows posterization even with ProPhoto.  So I end how I started: by saying if it hurts when you poke yourself in the eye, perhaps glasses aren't the answer, meaning... use Printer RGB and deal with the problem at the source: you won't have to deal with the 16 bit conundrum and the extra space and time needed to store/process them.

Mike

Hi Dennis,
It's in the main Qimage folder. Comes with Qimage, and it automatically is selected when you invoke Let Printer Manage Color.
Fred

Just a note: all versions starting with 2014.213 will automatically install Printer RGB in your system color folder.  So it should be visible in any other program after install.

Mike

Hi Mike,

On the release notes of v2.18 it is mentioned:
v2014.218 offers improved dithering for 16 bit images and profiles plus some bug fixes.

This adds the following Dithering options to the Color management panel:

• None
• 16 bit images only
• Full (16 bit images and profiles)

Could you elaborate about the 16-bit images option. Does that dither 16-bit/channel images on input conversion to 8-b/ch? If so, doesn't that carry the risk of magnifying/enlarging whatever dither there might be visible when adding a filter sharpening in the image editor, and enlarging that with output upsampling?

I've also seen that the output dither has a checkerboard pattern. Is that part of the LCMS colorspace dither option? Is a checkerboard pattern safer than a stochastic pattern to avoid clashes with the printer dither pattern, or just faster? It may not matter much at the native printer driver resolution (600/720 PPI), although we have the option to use a lower resolution and the printer driver may be set-up to a maximum of 300/360 PPI, but I'd like to understand the pros and cons.

Thanks for the additions.

Cheers,
Bart

Hi Mike,

I agree, the likelihood of spotting it is slim, and if only a single bit in an RGB triplet is affected it's even less likely. I have however seen in the output dither that R and G and B were all affected in the same way. Maybe I need to check some more samples of both input (16 -> 8 bit) and output (profile) dither to see if that was an accident or not.


Okay, I thought there was something in LCMS 2 because in my perusals on the LCMS site, I couldn't find anything about the dithering, yet in the source-code there was a Boolean Dither Flag or something like that. Maybe it's a remnant of the previous version.


Yes, chance has it that it's gone due to interpolation. However, if the resampling factor effectively is 1.0 (image 600 PPI, output also 600 PPI) or something very close, the Smart output sharpening might enhance the earlier image dither, and add another layer of dither after that. To avoid the reinforcement of the dithers, maybe a fourth option would be safe to cover all grounds?

Something like:

• None
• 16 bit images only
• Profile conversions only
• Full (16 bit images and profiles)

Agree, it's just something one should be aware of when creating a filter that sharpens.

Thanks again for providing some more insight into the inner workings.

Cheers,
Bart

I just wanted to say - great info!