How to test if a print was made at 16 bit?

[Aram Hăvărneanu]

If one can't see any difference between 8-bit printing a gradient and 16-bit printing the same gradient, it doesn't mean there's no difference, it simply means something in the 8-bit pipeline is dithering the image.

Visually inspecting prints for determining if the pipeline is 8 or 16 bit is not a good strategy.

(By the way, the 16-bit pipeline is dithered as well).

[Doug Gray]

If one can't see any difference between 8-bit printing a gradient and 16-bit printing the same gradient, it doesn't mean there's no difference, it simply means something in the 8-bit pipeline is dithering the image.

Visually inspecting prints for determining if the pipeline is 8 or 16 bit is not a good strategy.

(By the way, the 16-bit pipeline is dithered as well).

If the "dither" option is set in Photoshop->edit->Color settings then your 16 bit prints will be dithered when printed with an 8 bit driver. Even when printing through a null transform. With it off they will not be dithered. I don't know what LightRoom does.

Printers have to dither just to print 8 bit images since they only have 8 or 10 inks to work with to create 16M different possible colors over a very small area. Just turning on the dither option eliminates any advantage 16 bit driver paths provide which is mostly theoretical in any case.

[elliot_n]

Not sure how unchecking the 16-bit box when you print saves hard drive space. The file is simply going to a cache and clears when the print data is sent.

Saving the retouched file as an 8 bit file saves a lot of hard drive space.

[elliot_n]

Just turning on the dither option eliminates any advantage 16 bit driver paths provide which is mostly theoretical in any case.

Ah, I didn't know that. When I did my tests, the dither option was checked. Please ignore my results.

[Mark D Segal]

"Viewed at 200% in Photoshop, and toggling between the 8 bit and 16 bit print, there are very slight differences when looking at the big square with colour gradients. But nothing significant"

Of course I cannot speak for Mark, and he can certainly correct me if I have misinterpreted the above quote.  However, I believe he was referring to examining the actual prints magnified instead of the image files enlarged in Photoshop.  As with most cases, when one is trying to determine a difference in a particular method of image file processing and or printing, the proof is in the print.  Of course that also depends on whether or not a print will be the end product.  Yes, the numbers are useful on some level, but in the end the print tells the tail, does it not?  I have yet to sell the image on my display to one of my customers, but they are very happy and satisfied with the prints I produce from their files.

Just wondering .... 

Gary     

 

Yes, of course, I was referring to magnified prints - the question is about whether 16-bit is being sent through to the printer driver and presumably whether the driver uses it in that format to mix the recipe for making the print.

[JRSmit]

I just printed Andrew's test file on my Epson 3880, with the 16bit checkbox checked, and then unchecked. I couldn't see any difference in the resulting prints. I scanned the prints, layered them in photoshop, and toggled between them. I still couldn't see a difference.

Cannot see hoe a scan with 600ppi van show minuten difference of a print printed with 1440 dpi. Also sometimes small irregularities in the dit pattern is easy to see at normal viewing. Others only with Magnification. For intance small variations  in the dotpattern due to the paper slightly ondulating on the platen because of the paper suction being too high for the given paper.

[elliot_n]

Banding from 8 bit drivers can easily be demonstrated.

Simplest way to demonstrate banding in 8 bit printer drivers, as well as how well 16 bit ones perform is to print the attached gradient without color management (direct to the printer driver just as one would print patches for profiling).

Print the very dark strip, Cut off the white borders. Hold it up to a bright light. You will see the banding from 8 bit drivers and less from 16 bit ones but will likely see some there as well since printers have to convert the image to a printed dot pattern.

However, you will search long and hard to find a photo that shows this unless it is very heavily processed. Even then it would be rare. I've never seen this. Actual photo images have at least a bit or two of noise and, since there are thousands of printed pixels in even a tiny area. The effect is blended and so not seen.

I just tried this. It's hard to see any difference, but with the prints backlit with a bright light, I can make out a couple of bands in the 8 bit print that aren't present in the 16 bit print. (Epson 3880, Epson Semigloss paper, printed through Adobe Colour Printer Utility, toggling the 16 bit checkbox.)

[elliot_n]

If the "dither" option is set in Photoshop->edit->Color settings then your 16 bit prints will be dithered when printed with an 8 bit driver. Even when printing through a null transform. With it off they will not be dithered. I don't know what LightRoom does.

Printers have to dither just to print 8 bit images since they only have 8 or 10 inks to work with to create 16M different possible colors over a very small area. Just turning on the dither option eliminates any advantage 16 bit driver paths provide which is mostly theoretical in any case.

This has got me confused (I'm not very tech-minded). You're saying that to enable a 16 bit printing workflow, the Photoshop Colour Settings dither checkbox must be switched off? As it is not in any of the print dialogs, it is an easy thing to overlook. I've always assumed that for day-to-day colour space conversions (e.g. converting AdobeRGB images to sRGB for a client) it should be switched on (to avoid banding). I'm not confident that I can remember to toggle this setting on/off depending on whether I'm printing or converting files for clients.

I've been doing some further tests, printing some gradients (white to mid grey) with my normal print workflow (i.e. with a print profile (in this case, the Epson 3880's canned profile for Semigloss), 2880 dpi, high speed off).

I made 4 prints, all of the same 16 bit file (i.e. I'm not converting the file in Photoshop to 8 bit for the 8 bit tests - I'm just unchecking the 16 bit checkboxes in the Epson dialogs.)

1) Epson 16 bit. Photoshop Colour Setting = no dither
2) Epson 16 bit. Photoshop Colour Setting = dither
3) Epson 8 bit. Photoshop Colour Setting = no dither
4) Epson 8 bit. Photoshop Colour Setting = dither

They all look the same, with smooth gradients, except for (3) which shows some slight banding.

[elliot_n]

Cannot see hoe a scan with 600ppi van show minuten difference of a print printed with 1440 dpi. Also sometimes small irregularities in the dit pattern is easy to see at normal viewing. Others only with Magnification. For intance small variations  in the dotpattern due to the paper slightly ondulating on the platen because of the paper suction being too high for the given paper.

I felt that the 600dpi scan was showing me at least as much as I could see with my loupe, but perhaps I should have scanned at a higher res.

[elliot_n]

Just turning on the dither option eliminates any advantage 16 bit driver paths provide which is mostly theoretical in any case.

In Adobe's description box for the 'Use Dither (8-bit/channel images)' checkbox, it says 'Use Dither: Controls whether to dither colors when converting 8-bit-per-channel images between color spaces. Dithering greatly reduces banding artifacts, but may increase file size.'

It seems clear that this dithering function is restricted to 8-bit color space conversions. Why do you think that it still applies to the 16-bit color space conversion in the Epson 16-bit printing pipeline?

[Mark D Segal]

It seems to me that there are many steps in the printing process after a 16 bit image is created and sent to the printer via the printer driver, each may or may not be truly 16 bit.  I am not sure when the printer manufacturer says their printer can print in 16 bit, which or all of of the steps below they mean:

1) Accepting the 16 bit image by the OS and the printer driver
2) Computing in the printer driver in 16 bit to prepare data to be sent to the printer such as re-sampling and icc profle conversion, etc
3) Sending the data to the print-head in 16 bit
4) Accepting the data in 16 bit by the print head
5) Printing 16 bit data without truncating

Looks like the printer manufacturers might have addressed the first two issues, but what about the rest.  If all of these are done in 16 bit, there is still a question whether the 16 bit signal is lost in the normal printer noise introduced at the nozzle/paper level.

The final issue will be the ability to discern the difference with human eye or with  measurements by scanning or spectrophotometer.  And if the discrepancy is noticed between an 8 bit print and a 16 bit print, would we know where it was introduced in the process.

Just some thoughts....

:Niranjan.

Looking at your list of steps above it's clear that you don't know - and very few people in the world (myself included) actually know - (a) whether those descriptions of the steps make technical sense to start with, and (b) where in the print pipeline specific computations for making a print are done, be it from the image editing application, the computer operating system (especially CMM) and the printer driver. And who knows (and how) whether there is such a thing as "normal printer noise introduced at the nozzle paper level" Where did you get that from? Unless we know these things, this kind of attempted analysis is pointless. And it becomes even more pointless when really the only thing that matters is whether one sees a difference in a print whether the image is sent to print in 8-bit or 16-bit computational format. The balance of evidence so far suggests that if there are differences they are invisible under normal print viewing conditions, so that to me seems to be the bottom line.

[faberryman]

The balance of evidence so far...

...is comprised of a few anecdotal reports on a photography forum.

[Mark D Segal]

Yes, that is correct, but perhaps not insignificant. :-)

[digitaldog]

In Adobe's description box for the 'Use Dither (8-bit/channel images)' checkbox, it says 'Use Dither: Controls whether to dither colors when converting 8-bit-per-channel images between color spaces. Dithering greatly reduces banding artifacts, but may increase file size.'

It seems clear that this dithering function is restricted to 8-bit color space conversions. Why do you think that it still applies to the 16-bit color space conversion in the Epson 16-bit printing pipeline?

Your understanding and mine jive.

[felixpq]

Check your calculations. dE00 for those triplets is 0.15, not .51.

Further, Lab=(100,100.5,100) is not even possible on a perfectly reflective print. Even theoretically, as it requires spectral reflectance to exceed 100% at one or more wavelengths.

Let's look just at neutrals. The  dE00 over the neutrals from L*=0 to 100 for unit changes in L* is maximum at L*=50 where it exactly matches deltaE1976 which is 1.0 and decreases on either side of L*=50.

There are only about 72 (IIRC) JND's from L*=0 to 100 based on delta E 2000.

I used that metric (CIEDE2000) only because I found 3 sources to calculate it and one of them is basically copied from http://www.brucelindbloom.com/. The results are different for all 3, go figure. I'm not an expert at this for sure and I just noticed, I never said LAB(100, 100.5, 100) as above or anywhere else, if I did it was a mistake, I meant RGB(100, 100.5, 100), I hope this will propagate.

I found a couple of source for the JND one says CIEDE2000 of 1 the other says 0.5. If it's truly 1 it is most likely we won't be able to see at least visually if there is a difference between 8 and 16 printing but if it's 0.5 it could mean we could.

I also found the a 1 unit change on one single channel of an 8 bit (0..255) RGB triplet is not uniform. It the same for 16 bit RGB triplet.

YG

[felixpq]

Though I didn't read all of your replies, from the many I've seen, I think I should refine my question a little bit more.

Let assume we have a Raw image taken with a 14 bit sensor which implies quite a few possible colors, right? In other words, the source image as a higher bit depth then  8 bit.

We enter this image into a black box or in other words we don't care of what happens in there.

A print comes out from this black box and my original question was basically can we figure out if this was done at 16 bit without a picoliter of a doubt.

It's kind of a detective work if you which, can we prove this or not just from the print? There are way to many variables inside the black box, just leave them out please.

Thanks.
YG

[digitaldog]

Let assume we have a Raw image taken with a 14 bit sensor which implies quite a few possible colors, right? In other words, the source image as a higher bit depth then  8 bit.

Nope. You're again 'confusing' bit depth with color despite the URL article provided.
Take a 14-bit raw capture of a gray card. Now take a 12-bit capture of a field of colorful flowers. Then consider that until the image is rendered, there's not even a full set of color numbers (and then from that colors) to even evaluate. Not if you agree that this is raw data:

[Doug Gray]

In Adobe's description box for the 'Use Dither (8-bit/channel images)' checkbox, it says 'Use Dither: Controls whether to dither colors when converting 8-bit-per-channel images between color spaces. Dithering greatly reduces banding artifacts, but may increase file size.'

It seems clear that this dithering function is restricted to 8-bit color space conversions. Why do you think that it still applies to the 16-bit color space conversion in the Epson 16-bit printing pipeline?

It doesn't affect 16 bit to 16 bit conversions. However, the dithering selection does affect 16 bit conversions to 8 bits in the same colorspace. Say from Adobe RGB 16 bits to Adobe RGB in 8 bits. Easy to see just in Photoshop. It also applies to conversion from 16 bits to 8 bits when printing/

[Mark D Segal]

I would agree with your bottom line although I didn't say in those words.  I am sure you are in a better position to assess that based on the vast experience you have had in this area.  Also, my steps were based on what might be happening under printer managed option so I assumed that those pre-printing computations were handled by the print driver.  This was my own layman's perspective on looking under the black box (mixing metaphors) and conjecturing what all might be happening.  So yes I don't know all of those things per se.   But my general idea was even if the printer manufacturer says their printers are able to print at 16 bit - it may not mean anything.  Does it mean they are able take 16 bit data, or handle 16 bit data or do everything from start to finish in 16 bit. 

Regarding the printer noise, what I meant was that if one were to print same block of color 10 different times at the same bit depth under identical conditions and measure, there will be be statistical variability in those measurements within the block and from block to block.  This is what I have seen in my own limited measurements, although I have not done any sort of statistical analysis. 

:Niranjan.

Again, what's happening under the "Managed by Printer" option is a whole other treatment in the driver and those of us on the outside of the driver design team would be going down a rabbit hole trying to parse the internals of this.

What you are seeing in your own measurements most likely has nothing whatsoever to do with bit depth. It is more likely some variability of measurement from the spectrophotometer, and some variability in the ink laydown from the printer, both of which effects occur and are normally minuscule.

[Mark D Segal]

Though I didn't read all of your replies, from the many I've seen, I think I should refine my question a little bit more.
................

It's kind of a detective work if you which, can we prove this or not just from the print?

Thanks.
YG

Highly unlikely to be possible.