16 Bit Printing

[cybis]

But that attachment shows the only option related to dithering (CS6 Extended) in the Color settings dialog, and it only applies to conversions from 8-bit to 8-bit ... Do you have another option in your version, if so could you post a screen capture so I can see what you are referring to?

I have PS CC and it has the same dither settings as CS6. The 'Use Dither' in 'Color Settings...' also impacts the 16>8-bit conversion. As it is a global setting, not specific the active image, it's never greyed out (unlike the identical option in the 'Convert to Profile...' dialog box).

To demonstrate:

• 1. create a 16-bit partial ramp
  • a. File>New... 1000x300, RGB Color>16-bit, Color Profile: Don't Color Manage this Document
  • b. Gradient Tool: Dither off. Create a linear gradient from say RGB 120,120,120 to 130,130,130
• 2. The result on a 8-bit display is a grey ramp with lots of banding due the 8-bit display pipeline. But if you look in the info tool in RGB 16-bit, you can confirm that the ramp is indeed a smooth 16-bit gradient.
• 3. Image>Mode>8-bit/Channel. The result on display is a smooth gradient. It is smooth only because it is dithered and the 8-bit display is able to display the 8-bit dither. If you look very carefully, you can actually see the dithering pattern.
• 4. Undo the 8-bit conversion. Deselect Dither in 'Color Settings...'. Convert to 8-bit again and observe the dither free, but full of banding result.

[Bart_van_der_Wolf]

I have PS CC and it has the same dither settings as CS6. The 'Use Dither' in 'Color Settings...' also impacts the 16>8-bit conversion.

Hi,

Okay, with such a low gradient delta (1:100) as per your suggested settings, I now do see a bit of dithering of a few lines. It apparently is also controlled by that same dither option (even no restart required), even if it doesn't tell us that it will. Oddly, also the help files seem to do not mention that behavior. Good to know, thanks.

Cheers,
Bart

[cybis]

I did some test to see if the dithering pattern introduced by PS when converting from 16-bit to 8-bit could ever be visible in the final print.

The preliminary results are that the dithering pattern is totally unnoticeable (with one caveat). Meaning, printing in Mac Epson 16-bit mode, versus dithered 8-bit, produces the same results as far as smoothness and as far as the number of possible shades are concerned. You can print all the shades possible in 16-bit between any two consecutive 8-bit values using dithered 8-bit. The dithering disappears in the intrinsic dithering used by the printer to lay individual ink droplets.

The one big caveat, is that the dithering should be performed at the final output resolution of the printer. In Epson's case at 360 or 720 dpi. Unfortunately, if one let the PS printer module perform the pixel size upsampling (I assume the module does that, right? Or is it the driver?) and the bit depth downsampling, it seems the module does the bit depth downsampling before the pixel upsampling. That means the dithering could be upsampled and can become visible.

I haven't tested LR. And I haven't test the potential effect of the dithering on sharpness.

And yes I'm aware I'm deep inside pixel peeping territory, but once this is done my goal is to find out what does or doesn't make a difference whatsoever.

[cybis]

You can print all the shades possible in 16-bit between any two consecutive 8-bit values using dithered 8-bit.

I should really research that further. I suppose it depends on cell size, etc. But it's good enough for all intents and purposes.

[Bart_van_der_Wolf]

I should really research that further. I suppose it depends on cell size, etc. But it's good enough for all intents and purposes.

Hi Luc,

If you, or any of the other readers of this thread, have an image that's very sensitive to posterization/banding due to profile conversion or bit depth reduction, it might also help to let Mike Chaney have a go at it. He is asking for images, in order to see if he can find a further optimization for Qimage (which only converts between colorspaces as a last step, after upsampling and output sharpening). Maybe adding some dithering during that last step, with the most recent LCMS engine, can help? It apparently used to cause occasional issues with an older version of LCMS), but maybe he can make it work better now?

Cheers,
Bart

[Schewe]

Okay, with such a low gradient delta (1:100) as per your suggested settings, I now do see a bit of dithering of a few lines. It apparently is also controlled by that same dither option (even no restart required), even if it doesn't tell us that it will. Oddly, also the help files seem to do not mention that behavior. Good to know, thanks.

In addition to adding a dither to color space transforms, PS also adds a dither to 8-bit gradients. I can't remember exactly when this was put into Photoshop (I think it came AFTER PS 5, maybe PS 6-pre-suite numbering). I do remember a lot of discussion going on between Bruce Fraser and Mark Hamburg along with Chris Cox about why. As I recall, adding even a tiny bit of noise into the conversion/gradient less likely to posterize with subsequent edits...

Now, it's on by default for both conversions and gradients...and you have to actively turn it off in the main Color Settings prefs...

[digitaldog]

Dither is used for other functions than just conversions even though the controls for it's use is in the Color Settings.

According to Chris Cox:

There is dithering happening in 16 bit/channel gradients -- at an amount appropriate for the least significant bit in 16 bit/channel.

But that’s a dither of 1/32768 instead of the 1/256 you see in 8 bit/channel documents.
So that dithering helps the 16 bit data, but won’t show up on your 8 bit display.
Using an 8 bit dithering amount on a 16 bit gradient would trash the quality of the gradient, making the use of 16 bits pointless.

According to Dave P:

We generally don't dither when printing (except to PostScript printers), since Photoshop never resamples when printing, and if there's a down-conversion from 16-bit to 8-bit (when a printer doesn't support 16 bit printing, or the checkbox is turned off), you should get exactly the same effect as if you'd selected image>mode>8 bit. Any dithering would be performed by the printer driver (which in many cases just calls back to the OS to do the dithering).

According to Roy Harrington on the ColorSync list:

The Dither option in Color Settings applies to all conversions that result in an 8bit file. This would include 8-bit to 8-bit color profile conversions and all conversions of 16bit to 8bit -- i.e. explicit Mode conversions and Printing to an 8 bit driver. The effect of the dithering is to preserve more of the 16bit data in the 8 bit file. While this may seem like an impossible task it in fact does this very well because adjacent pixels are averaged.  For example consider all the 16-bit values between 127 and 128, without dither you'll get all the same 8bit values. But with dither you can represent a patch of 127.3 with 30% 127 and 70% 128, and so forth.

So if you spend the effort to use a 16bit workflow in general it's well worth using the Dither on the way to the printer.  There is no negative side effect of multiple dithers -- it's a negative if you don't use it.  I'd consider it a mandatory option for just about all PS work.
Roy

And I agree, the dither setting should always be one for most uses. I turn it off if I'm doing some kinds of analysis where ultimately I'll put a color list in ColorThink to get a dE report and the resulting differences are expected to be tiny (for example, you're using the same profiles but testing differing CMM's).

[cybis]

According to Dave P:

... if there's a down-conversion from 16-bit to 8-bit (when a printer doesn't support 16 bit printing, or the checkbox is turned off), you should get exactly the same effect as if you'd selected image>mode>8 bit. Any dithering would be performed by the printer driver.

Except the effect you get when selecting image>mode>8 bit is dithering.
If I understand correctly, he's also saying PS Print module does not resample the image pixel size to fit the native dpi of the printer driver. Is that correct? The resize is left to the driver?

[Schewe]

If I understand correctly, he's also saying PS Print module does not resample the image pixel size to fit the native dpi of the printer driver. Is that correct? The resize is left to the driver?

Correct...you CAN alter the final output resolution, but you must actively do that–it doesn't happen in PS nor LR by default.

[cybis]

Correct...you CAN alter the final output resolution, but you must actively do that–it doesn't happen in PS nor LR by default.

How do you do that in PS print module?

EDIT: added 'print module'.

[Schewe]

How do you do that in PS print module?

You change the Scaled Print Size in the Print dialog...if you alter the Scale, you can see the image size & Print Resolution. It's not "optimal" but it's usable...LR is easier to deal with (no surprise). Alliteratively, you can use Image Size before going into the Print dlog...the downside is you'll need to run some sort of output sharpening after the image resize :~(

In LR, you can do everything at once (another benefit of LR).

[cybis]

You change the Scaled Print Size in the Print dialog...if you alter the Scale, you can see the image size & Print Resolution. It's not "optimal" but it's usable...

Wait. I must be missing something. If I increase the scale, the Print Resolution goes down accordingly. It doesn't seem to resample.

[Schewe]

Wait. I must be missing something. If I increase the scale, the Print Resolution goes down accordingly. It doesn't seem to resample.

You are missing the fact you were talking about the output resolution (not resampling) and I showed how you can alter the final output resolution (and yes, if you change the output resolution, the image size changes–doooh).

That's also why I mentioned Image Resize–if you needed to do more (resizing & resampling).

Edit: Sorry, wasn't trying to be snarky, just showing that the Print dlog in PS can do some things in the dlog...

[cybis]

Hi Luc,

If you, or any of the other readers of this thread, have an image that's very sensitive to posterization/banding due to profile conversion or bit depth reduction, it might also help to let Mike Chaney have a go at it. He is asking for images, in order to see if he can find a further optimization for Qimage (which only converts between colorspaces as a last step, after upsampling and output sharpening). Maybe adding some dithering during that last step, with the most recent LCMS engine, can help? It apparently used to cause occasional issues with an older version of LCMS), but maybe he can make it work better now?

This photo exhibits lots of posterization/banding when printed in Qimage but none in PS and LR.

I don't know that adding dithering after the 8-bit conversion makes sense. Actually it would just be like adding noise since there would be nothing to dither at that point.

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.

[Bart_van_der_Wolf]

This photo exhibits lots of posterization/banding when printed in Qimage but none in PS and LR.

Hi Luc,

I saw that image on your website, and thought it would be a good candidate, but I didn't know if the specific output profile you converted to caused any issues. Since it apparently does, I think it would be very useful to send both (image+output profile) to Mike Chaney, so he can find a solution. We can only gain from such an exchange, you get better output results when you want to use the benefits of Qimage (nesting/interpolation/output sharpening/re-using prior print jobs for identical copies, etc.), and Mike is eager and motivated to improve output quality, which will push competition to improve their quality as well.

I don't know that adding dithering after the 8-bit conversion makes sense. Actually it would just be like adding noise since there would be nothing to dither at that point.

No, that's not what he is going to look at, he is going to look at the dither option of profile conversions after the image is already resized and sharpened, as the final step before sending the bytes to the printer driver. The dither would break up posterization at the 600/720 PPI level, beyond normal visual acuity. It would be similar in effect to the 16-->8 bit mode change dither, although it is not clear how the microweaving / color dithering / uni- or multidirectional printing / etc. of the printer driver interacts with such dithering (also depends on the dither algorithm, which may have changed since LCMS version 1).

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

I agree, if it produces better results. Maybe the paper structure and print process (dithered colors with blending/overlapping of multiple ink droplet sizes that diffuse in the medium, in the case of inkjet output) has a larger influence.

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.

I agree that a optional dither would probably be best, but it should be done as a final step, after resizing and output sharpening and colorspace conversion, otherwise the effect will vary all over the image. Until then, just adding some noise at the 600/720 PPI level is probably also effective enough for pathological cases, but it would be nice to have a slightly more elegant solution. Adding noise can help with other (lack of resolution) issues, so it's best to only use it for that purpose.

Cheers,
Bart

[cybis]

Hi Luc,

I saw that image on your website, and thought it would be a good candidate, but I didn't know if the specific output profile you converted to caused any issues. Since it apparently does, I think it would be very useful to send both (image+output profile) to Mike Chaney, so he can find a solution. We can only gain from such an exchange, you get better output results when you want to use the benefits of Qimage (nesting/interpolation/output sharpening/re-using prior print jobs for identical copies, etc.), and Mike is eager and motivated to improve output quality, which will push competition to improve their quality as well.

Yes it seemed like a good candidate for the posterization hall of fame, but it actually prints just fine out of the box. To make it really challenging I applied strong noise reduction, which really help show the potential problems associated with converting to 8-bit by rounding instead of dithering. Also I pushed the saturation a bit; the image's gamut is now outside AdobeRGB but inside the printer gamut. This might help show further posterization during the color profile conversion (I'll experiment later to see if it's actually happening).

To be clear the test image does not reflect my aesthetic choices; I've pushed it to the limits for demonstration purposes.

I also downsampled its pixel size. So if it's printed to letter size or bigger it might show the problem associated with dithering before enlarging (PS?). 

Right now, out of PS, LR, and QI, only LR does all the steps in the right sequence, i.e. 8-bit-with-dither last.

Also, I hear you, I'm a big fan of Mike and QI. Even if this minor problem is never fixed (which I doubt, knowing Mike), given that the chance of actually visibly occurring in a real world print is very low, and now that I know what to watch for,  QI remains my favorite tool for the job. For the pathological cases (as you say ), it's always possible to alter the normal workflow by performing the steps 'manually' in PS.
 

No, that's not what he is going to look at, he is going to look at the dither option of profile conversions after the image is already resized and sharpened, as the final step before sending the bytes to the printer driver. The dither would break up posterization at the 600/720 PPI level, beyond normal visual acuity. It would be similar in effect to the 16-->8 bit mode change dither, although it is not clear how the microweaving / color dithering / uni- or multidirectional printing / etc. of the printer driver interacts with such dithering (also depends on the dither algorithm, which may have changed since LCMS version 1).

I agree, if it produces better results. Maybe the paper structure and print process (dithered colors with blending/overlapping of multiple ink droplet sizes that diffuse in the medium, in the case of inkjet output) has a larger influence.

Ah ok, I understand now. It would be interesting to see if dithering introduced in the last step from 8-bit-source-profile > 8-bit-printer-profile would help hide the posterization introduced in the first step. I'll test this approach to see if it could help.

Regarding the question of whether a 8-bit dithering pattern will be visible if performed at output resolution, there is no worries there; it won't. The max amplitude of the dithering is half an 8-bit step in this case; it's totally invisible against the background noise intrinsic to the printer unless it's enlarged by a large factor.

We should probably continue the QI specific discussion over at ddisoft forum?

[cybis]

ProPhoto is currently the only space available in ACR that doesn't clip the gamut of the printer.

Turns out ACR let you choose whatever profile you desire; at least in CC. Not sure if it's a relatively new feature or if I've I just always assumed wrong.

[Schewe]

Not sure if it's a relatively new feature or if I've I just always assumed wrong.

Yes, it's new to ACR 8.x in Photoshop CC.

[William Walker]

As a complete layman when it comes to this type of discussion, would I be wrong in suggesting that this extract from Andrew's link to "Real World Adobe Photoshop" is the simplest argument for using ProPhoto RGB?
 

This question seems to have been "lost" in the ongoing debate - Jeff, Andrew, anyone...?
To me, the key is: "It needs these extreme primaries to accommodate the dark, saturated colors we can readily achieve in print that get clipped by smaller spaces."

Thanks
William

[digitaldog]

Simple matrix profiles of RGB working spaces when plotted 3 dimensionally illustrate that they reach their maximum saturation at high luminance levels. But the opposite is the case with print (output) color spaces. Printers produce color by adding ink or some kind of colorant while working space profiles are based on building more saturation by adding more light due to the differences in subtractive and additive color models. To counter this, you need a really big RGB working space like ProPhoto RGB. All RGB working space's shapes are simple as seen as you plot them. Then there is the issue of very dark colors of intense saturation which do occur in nature and we can capture with many devices. Many of these colors fall outside Adobe RGB (1998) and when you encode into such a space, you clip the colors to the degree that smooth gradations become solid blobs in print, again due to the dissimilar shapes and differences in how the two spaces relate to luminance.