Pages: [1]   Go Down

Author Topic: Measuring Printer Dither or Don't Fear the Dither  (Read 1664 times)

Doug Gray

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2197
Measuring Printer Dither or Don't Fear the Dither
« on: October 21, 2018, 09:01:56 pm »

Printers must dither the way they lay down ink.  A lot. Printers only have a limited number of inks, usually 8 or a bit more. But one can request 16M colors in 8 bit RGB on a single print area of, perhaps 1/360th or 1/720th inch on a side. At best they can plop down a variety of inks but are limited to, perhaps 50 combinations in such a small area. So what do drivers do? Well, for black, or pure cyan, etc., they can fully populate with black or cyan ink. But what about colors inside the gamut that require some mixing?

What they do is print a dithered pattern of dots based on the RGB values. With 16M RGB combos they lay down a statistical spread of colors that will, on average, produce the desired color and the color will be quite inaccurate if you look too close and start to see the variation from individual ink dots. Further, the dot pattern a printer may print in one place can be and is quite different from the dot pattern in another place even though the RGB values may be identical!

Here's what about a .2" portion of "gray" looks like blown up 20x:


It's a mix of different inks, not just neutral ones.

This was all printed with exactly the same RGB value (105,105,105) at 720DPI so it's pretty apparent that what gets printed varies considerably and is not limited to squares that are 1/720th inch on a side.

So an Experiment on my 8 bit 9800!

Let's print an RGB  gradient from 100 to 110 in ProPhoto RGB high (16) bits and do the following.

Convert the 16 bit image to 8 bits, print, and look for banding.
Create images that have decreasing levels of actual RGB bits by forcing all values to integers and zeroing the lower order bits producing increasing coarseness.

One image, the second stripe, uses all 8 bits but the low order bit was statistically altered to be either 0 or 1 based on the value at that location. Thus RGB values of 105.25 would be printed at 105 75% of the time and 106 75% of the time.

Next, on the third strip, we limit the RGB range to values with the lowest order bit set to 0. Now we only have RGB 104 and 106 available. So to "print" 105.25 we will need to have 104 37.5% of the time and 106 62.5% of the time/

Then we do the same for RGB values restricted to:

0,4,8,12, …
0,8,16,32...
0,16,32,48...
0,32,64,96...

And then adjust the printed values proportionally so that the we get the proper average.

That last one is very coarse, with the lowest 5 bits zeroed, allowing only 9 levels: 0,32,64,96,128,160,192,224,255. Printed, it produces significant additional noise. Here's what that looks like using the same area:




Here's an image of the full experiment, downsized to 120 DPI for posting:
The first strip is printed directly with no dithering using the full 8 bits. The rest use dithering too. The second uses 8 bits, the third uses 7 bits, fourth 6 bits, fifth 5 bits, 6th 4 bits, 7th 3 bits.





Amazing how good it looks using only 4 bits of RGB but, with dithering. And the last with only 3 bits, is better than one might expect.


To make the noise more apparent, I used curves to boost the contrast about 10x around the gray. Here's what that same image looks like with heavily boosted contrast:



And here's a graph of the accumulated power noise for each of the strips that shows that there is no difference beyond 4 bits of depth.



The X axis is cycles (aka lines and called LPI hereafter) per inch on the print. The Y axis is accumulated noise power so the slope is the noise power at each LPI. Units on the Y axis are arbitrary and used to compare strips. Interesting that the noise is essentially independent of LPI. Human vision is much more sensitive to noise at low LPIs and insensitive at high LPI levels. So the lines below about 20 LPI are most meaningful.

The top blue outlier line shows is that of last strip. Its dithering uses only 3 bits of RGB and so injects considerable excess noise. The 6th strip (green with 4 bits) has much less noise, and the fifth strip (purple with 5 bits) is extremely close and contributes almost no additional noise. The rest are grouped together and not significantly different from each other.

Conclusion: If your system uses 8 bits, just enable dither on printing. For Photoshop this is the Edit->Settings->Use Dither. It prevents truncation to 8 bits which can create visual banding under unusual circumstances. The printer itself is dithering far more that what Photoshop or Lightroom introduce when converting 16 bit data to 8 bits with dithering enabled.

And, it turns out Lightroom does this automatically.
« Last Edit: October 21, 2018, 11:56:11 pm by Doug Gray »
Logged

elliot_n

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1219
Re: Measuring Printer Dither or Don't Fear the Dither
« Reply #1 on: October 22, 2018, 06:21:21 am »

I wish I could understand what you are doing here, and how you are doing it.

How are you manipulating the gradient?
« Last Edit: October 22, 2018, 09:48:28 am by elliot_n »
Logged

Doug Gray

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2197
Re: Measuring Printer Dither or Don't Fear the Dither
« Reply #2 on: October 22, 2018, 10:54:16 am »

I wish I could understand what you are doing here, and how you are doing it.

How are you manipulating the gradient?
The original gradient is from RGB(100,100,100) to about RGB(110,110,110) in ProPhoto RGB over 6" at 720DPI in 16 bits. My references are to fractionals rather than scaling to 16 bits since it's easier to relate to standard, 8 bit RGB levels. IE, 100.01, 100.02, etc. It is then saved in 8 bits. The first strip is just saved by rounding. So 103.51 is saved as 104 while 103.49 is saved as 103.

Taking the example of 103.49:
For the second strip, the RGB value is saved as either 103 or 104 by randomly selecting such that the statistical average of all the 8 bit values is 103.49.

The third strip has the LSB zeroed. That is the RGB values are limited to even values. So we only have 102 and 104 available. Like the prior strip, the values of 102 and 104 are randomly selected for each pixel such that the average is 103.49. So there are a hair under 75% of the pixels that wind up 104 and a hair over that are 102.

And so on with fewer available bits for subsequent strips.

Since the printed image is 720DPI, there are a bit over 500,000 pixels in every square inch. So things average out nicely in a visual sense. This creates visually smooth gradients when printed even though fewer than 8 bits were actually used in constructing the image.

I hope that is clearer. This was coded in Matlab and is quite easy to do. Perhaps if I post the section of code used to create this it would help.
Logged

elliot_n

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1219
Re: Measuring Printer Dither or Don't Fear the Dither
« Reply #3 on: October 22, 2018, 11:09:19 am »

Thanks for the explanation. I'm not a mathematician (and I'm not familiar with Matlab), but I do now understand your tests.
Logged

elliot_n

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1219
Re: Measuring Printer Dither or Don't Fear the Dither
« Reply #4 on: October 22, 2018, 11:22:54 am »

Is dithering from 16bit to 8bit a straightforward mathematical formula?

In my tests on the recent long thread about 16 bit printing I found that if Photoshop converted the 16 bit file to 8 bit (with dither), then the resulting printed gradient was totally smooth. However, if I had Photoshop send the 16 bit file to the printer, but then deselected '16 bit output' in the print driver (Epson 3880), then the resulting gradient displayed (very faint) banding.

This suggests to me that Photoshop has a better dithering algorithm than the Epson print driver. Is that possible?

Logged

Doug Gray

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2197
Re: Measuring Printer Dither or Don't Fear the Dither
« Reply #5 on: October 22, 2018, 12:18:53 pm »

Is dithering from 16bit to 8bit a straightforward mathematical formula?

In my tests on the recent long thread about 16 bit printing I found that if Photoshop converted the 16 bit file to 8 bit (with dither), then the resulting printed gradient was totally smooth. However, if I had Photoshop send the 16 bit file to the printer, but then deselected '16 bit output' in the print driver (Epson 3880), then the resulting gradient displayed (very faint) banding.

This suggests to me that Photoshop has a better dithering algorithm than the Epson print driver. Is that possible?

No, Your results are exactly what I would expect. The problem is that if you just chop the 16 bit data to 8 (or round - it doesn't make any difference) then you see the slight banding that is also evident in the first strip of the contrast enhanced scan I posted. Dithering is a way to create a more accurate average over an area large enough to be able to perceive tiny differences. From my experiment it's clear the printer has to dither and does so beyond the first 4 or so bits in order to create colors perceptually different over a larger area using a limited set of inks and discrete dots.

For an application that sends out 8 bit values, dithering has to be applied to the image in high resolution when it's converted to 8 bits in order for its average values to effect fractional RGB values (beyond the 8 bits of standard RGB 0:255). Whether dithering happens in the driver's 16 bit path, or in the application's 16 bit to 8 bit print path first makes no material difference.

Dithering has to be applied at that time an image is converted to 8 bits. If it's rounded or truncated to 8 bits then there will be banding because dithering isn't possible post conversion to 8 bits. The printer will dither but it can't produce fractional dither statistics from 8 bits because that fractional information is lost.

The algorithm used here is very basic. Error diffusion dithering is better and widely used in printing but dithering the half bit max error from high precision to 8 bit transforms doesn't require anything beyond basic, statistical (noise) dithering.

For those interested, here's a good reference paper and one with code.

https://lspwww.epfl.ch/publications/colour/davdsp_96.pdf
http://www.tannerhelland.com/4660/dithering-eleven-algorithms-source-code/
« Last Edit: October 22, 2018, 02:04:20 pm by Doug Gray »
Logged

John Hollenberg

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1185
Re: Measuring Printer Dither or Don't Fear the Dither
« Reply #6 on: October 22, 2018, 02:24:45 pm »

"I gotta have more dither!"  ;)
Logged
Pages: [1]   Go Up