Luminous Landscape Forum
Raw & Post Processing, Printing => Printing: Printers, Papers and Inks => Topic started by: felixpq on October 13, 2018, 10:40:51 am
-
I've contacted many companies, Canon, Adobe and Microsoft and they all say yes you can print with a 16 bit depth. But after trying to find the answer on this for a while, I think it would be nice to know for sure if it is actually the case, so anyone knows of any test one could use to know for sure?
I'm convinced a paper like the one in this image I've attached, the solid is the paper gamut and the mesh is Adobe RGB. This paper and many others would surely benefit from 16 printing.
Thanks
-
Very, very few print drivers pass high bit data to the printer. And it’s unnecessary too.
-
The O/P didn't indicate whether he/she contacted the appropriate source for such information, which would be the designers of the printer drivers, which would be the printer manufacturers. Looking at Epson, this older web page Epson - 16-bit support (https://www.epson.com.mt/viewcon/corporatesite/products/mainunits/faq/1228/21266), they say they support a full 16-bit workflow through the printer driver and illustrate the benefits of 16-bit processing. They also list the professional printer models before the latest SC-P series supporting 16 bit printing. As this is an older web page, it must be assumed that all the most recent Epson professional printers also support 16-bit printing. As I have an SC-P5000 printer, I know its driver offers the choice to send 16-bit data. It's highly unlikely any of the others in this line do not.
-
Very, very few print drivers pass high bit data to the printer. And it’s unnecessary too.
Canon assures me that their XPS drivers for windows allow this. Microsoft say yes as well since 2008 and I even check with Adobe if Lightroom and or Photoshop change the bit depth at any time during the printing process and they say no but yes I'm skeptic as well, so I'd like to know if there is a way one could verify if my setup print 16 bit or not.
Whether it's useful or visible is not the point. I just want to prove if it is possible or not.
Regards,
YG
-
I've contacted many companies, Canon, Adobe and Microsoft and they all say yes you can print with a 16 bit depth. But after trying to find the answer on this for a while, I think it would be nice to know for sure if it is actually the case, so anyone knows of any test one could use to know for sure?
I'm convinced a paper like the one in this image I've attached, the solid is the paper gamut and the mesh is Adobe RGB. This paper and many others would surely benefit from 16 printing.
Thanks
I should add, I'm not sure from what you write above whether you understand what the benefit of a 16-bit data flow really is. You will not see it in gamut pictures because it does nothing for gamut; the Epson page I referenced above says it mainly influences the smoothness and accuracy of tonal transitions.
-
Canon assures me that their XPS drivers for windows allow this. Microsoft say yes as well since 2008 and I even check with Adobe if Lightroom and or Photoshop change the bit depth at any time during the printing process and they say no but yes I'm skeptic as well, so I'd like to know if there is a way one could verify if my setup print 16 bit or not.
Whether it's useful or visible is not the point. I just want to prove if it is possible or not.
Regards,
YG
If you just want to see what difference it makes, download a large high bit image of a B&W tone ramp, or colour tone ramps, or construct your own in Photoshop using a gradient on a layer mask and then print it first with the driver set to 8 bit, then with the driver set to 16 bit and see whether you notice a difference. It is often the case that things which should look different in theory don't in practice, depending on a number of variables that you can either control for or not.
I should add: it's not clear to me how important it is to know whether something is possible if you aren't concerned about whether the results are useful and visible. Isn't the end-point of making a print how it looks?
-
Under Windows, the surecolor sc-p drivers are 16bit and primting from Lightroom. I checked this by looking at the spoolfiles, and compared with the 9900 . The spoolfiles are twice the size in MB.
I cannot choose 8 of 16 bit, so no comparison possible.
-
I should add, I'm not sure from what you write above whether you understand what the benefit of a 16-bit data flow really is. You will not see it in gamut pictures because it does nothing for gamut; the Epson page I referenced above says it mainly influences the smoothness and accuracy of tonal transitions.
What they show on that page is relatively old but still pretty relevant and it's all in the size of the steps. Today one can find papers, inks and printer combination that provide way to small a gamut to be useful for photographic images taken in raw for example. But on the other end of this we have other combination of paper, inks and printer that offer a pretty large gamut. Kind of what you can see in my post above. The gamut doesn't change in no way because I would use 8 or 16 bit pipeline to print it but the measures like the Delta E of image printed at 16 bit should be much smaller then those printed at 8 bit, just because the step size is much smaller at 16 bit then at 8 bit like it's shown in the link you provided.
-
Under Windows, the surecolor sc-p drivers are 16bit and primting from Lightroom. I checked this by looking at the spoolfiles, and compared with the 9900 . The spoolfiles are twice the size in MB.
I cannot choose 8 of 16 bit, so no comparison possible.
That's the closest thing to a proof I've seen so far that at minimum what goes to the printer is a 16 bit file. Now just have to check what comes out of the printer is still truly 16 bit?
Thanks,
-
From the tests I've done (using my landscape shots), on a completely finished file "ready to print" the difference between printing 16 bit vs 8 bit and tiff vs jpeg does not show up in the final print. So now after I've done all my PP in PS I convert it to the highest jpeg file and use that to print with as it loads into the printer much faster.
-
Whether it's useful or visible is not the point. I just want to prove if it is possible or not.
Of course it's possible, I didn't say otherwise. I said very, very few print drivers provide this data to be fully passed onto the printer. And I said, based on my testing of this, it's not at all useful; it's invisible!
My Epson 3880 driver (on Mac OS ONLY) has a check box for passing 16-bit data. Using this very wide gamut test file, filled with images and synthetic constructs, I sent the image to the driver in 16-bit. Then converted to 8-bit per color and turned the check box off to be sure. There is NO visible difference in the two prints under my best loupe. Nada, nothing, zero.
Try it for yourself using this test image:
http://www.digitaldog.net/files/Gamut_Test_File_Flat.tif (http://www.digitaldog.net/files/Gamut_Test_File_Flat.tif)
Now even more interesting is that my newer P800 driver no longer has this option (check box). What does that tell you?
Some Canon print drivers (the PS plug-in) also allow this option. So yeah, it's possible. And thus far, I've seen no one that has provided data it's at all necessary.
High bit data is about editing overhead. Then all you need to do is send the best 8-bits per color to the driver. And when you don't, most drivers convert the high bit data to 8-bits per data behind your back.
-
I should add, I'm not sure from what you write above whether you understand what the benefit of a 16-bit data flow really is.
I agree so I'll add this for him:
http://digitaldog.net/files/TheHighBitdepthDebate.pdf
-
Now just have to check what comes out of the printer is still truly 16 bit?
Printers don't output bits. Look at the prints. Then you'll know.
-
There is a current discussion of just this issue on the ArgyllCMS email forum: https://www.freelists.org/post/argyllcms/testing,1075
-
Sorry I have to go for now I'll be back later I just I'll be able read all your messages
Thanks
-
I have a Canon Pixma Pro 1 (discontinued) and I run it in Windows. The XPS drive can print in 16 bits. However, Lightroom only works at 8 bits with this combination (unless any recent update had changed that, I haven't checked recently). Luckily, the Canon plug-in Print Studio Pro does work (the only reason I have to use this plug in).
I've noticed the difference in black and white pictures showing a smooth gradient, like a clear sky. Most people won't realize the difference, but I don't like it if I see the resulting banding in 8 bits. Most of my pictures, however, do not require 16 bits printing, so I stick to the Lightroom print module.
Sent from my Nokia 6.1 using Tapatalk
-
Of course it's possible, I didn't say otherwise. I said very, very few print drivers provide this data to be fully passed onto the printer. And I said, based on my testing of this, it's not at all useful; it's invisible!
My Epson 3880 driver (on Mac OS ONLY) has a check box for passing 16-bit data. Using this very wide gamut test file, filled with images and synthetic constructs, I sent the image to the driver in 16-bit. Then converted to 8-bit per color and turned the check box off to be sure. There is NO visible difference in the two prints under my best loupe. Nada, nothing, zero.
Try it for yourself using this test image:
http://www.digitaldog.net/files/Gamut_Test_File_Flat.tif (http://www.digitaldog.net/files/Gamut_Test_File_Flat.tif)
Now even more interesting is that my newer P800 driver no longer has this option (check box). What does that tell you?
Some Canon print drivers (the PS plug-in) also allow this option. So yeah, it's possible. And thus far, I've seen no one that has provided data it's at all necessary.
High bit data is about editing overhead. Then all you need to do is send the best 8-bits per color to the driver. And when you don't, most drivers convert the high bit data to 8-bits per data behind your back.
Thanks for the file, it seems super at first glance, I'm curious about one little thing though, at the top of the sheet it says ProPhoto RGB 16 bit data, so why the file profile is Adobe RGB?
I especially love this one, "... most drivers convert the high bit data to 8-bits per data behind your back." and it is exactly why I would like to be able to know if they did this to me or not?
When most people here say there is no visible difference between a 16 and a 8 bit print and suggest strongly don't waste your time on this, could it be because someone is playing in their back?
Since every one seems to agree that I waste my time and yours with my questions and that whether or not the companies do stuff behind our backs. You are correct in saying there is no noticeable difference but for the wrong reason unfortunately.
Here is an answer that everyone can verify probably even with a scanner, using the CIE76 Delta E metric and even considering that this metric is not uniform across the spectrum, ie we can see some color difference better then others and that I tested only a few RGB triplets by changing just on color by one 8 bit level say (100, 100,100) compared to (100,101,100), I converted each of those to (XYZ) and then to L*A*B* then applied both CIE76 Delta E and CIEDE2000 and the result are under the just discernible threshold according to my reference, in other words we can't see it. That being said, with an instrument like the I1Studio spectrometer or whichever, again this as to be taken with a grain of salt because we don't know what companies do in our backs and I didn't read all the fine print. The RGB triplets above give a DE2000 of about 1 unit, to be honest I used an Excel sheet to do these calculation and I don't know which colorspace these RGB values are treated as, nor the illuminant and which observer so your mileage will vary that's for sure. The good news is a spectrometer like the one in the I1Studio product can in theory measure a 0.1 DeltaE*2000 under an illuminant of D50 and assuming a 2 degrees observer. In other words if you have one of these to make your profiles you can check if you've been screwed or not.
Same goes for your supposedly 10 bit quasi full (95% plus) covering of the AdobeRGB gamut display, some companies play in your back here as well , I forgot many paper, ink and printer combo bust the AdobeRGB colorspace but it doesn't matter, no monitor is likely to show these color anyway and since you can't see them in your workflow, why bother. I think Ansel Adams wouldn't like this kind of thought but who knows.
Think of this, suppose that on this or that print, you have say in 16 bit a value just barely above the 8 bit level of say 100 and the value of next pixel to it is halfway between 101 and 102. According to most of what you say, in this situation your driver may very likely convert these 16 bit values to 100 and 101 and yes we won't see a noticeable difference we agree 100 % but at a true 16 bit values of 100 to 101 + 126/255 the Delta E increases by 50%, again it may not be noticeable visually. But it will at some point even if it's barely noticeable overall your image will definitely have smoother gradient at 16 bit then at 8 bit, it's a fact.
Have a nice day all and thanks for the inspiration.
-
I forgot to give you my reference.
https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=2ahUKEwju9r7JiIbeAhUJy1kKHZbsBWIQFjAAegQICBAC&url=http%3A%2F%2Fdownloads.hindawi.com%2Fjournals%2Fam%2F2012%2F273723.pdf&usg=AOvVaw1HXAF_E3_h05C3WykeKaLa
And its seem I use a DE2000 of 1 unit as JND ( just noticeable difference) and this paper suggest a value 0.5 is more appropriate. We can argue that if we can see a pretty small color difference, assuming a true 16 bit pipeline no in your back dropping of bit and pieces here and there, now my worksheet give me a 0.51 DE2000 for these 2 RGB triplets (100.100.100) and (100,100.5,100). This would suggest we are able to discern more then the 256 tones of an 8 bit print. But wait the paper says this is partly subjective partly objective base data. I think only the spectrometer will be able to definitely put and end to this. Lastly I don't know all the facts about the tool I use to evaluate the DE2000 to begin with, it may off or not I have no clue.
Thanks,
YG
-
"But it will at some point even if it's barely noticeable overall your image will definitely have smoother gradient at 16 bit then at 8 bit, it's a fact".
Keeping the above quote in mind it seems to me that this thread has become somewhat convoluted with overlapping references to both 16bit processing and 16bit printing(if there is indeed such a thing). I will freely admit that the possibility that I have misread some of the thread is quite likely, but I do believe that the above quote seems to prove my theory of overlapping subjects. I just checked again to verify the intention of the OP and I was correct. It was not aimed at the value of processing a file in 16bit, it was instead aimed at printing in 16bit -- again, if that is at all possible, which would seem to be in question here. In this case I believe it would probably have been a good idea to address this difference early in the thread, so that we wouldn't be talking apples and oranges as has been the case in some replies. YES INDEED, we do ALL realize and appreciate the advantage(s) of processing a file in 16bit. However, that was never part of the initial question as I read it. It was all about printing in 16bit and whether or not it actually makes any difference in the final outcome. Unfortunately the lines/curves have become crossed and the final outcome is in doubt as I see it.
My rant for the day. Likely nothing of any value, which I imagine will be pointed out soon, and welcomed ;)
Gary
-
Still others variables like pixels per inch or printer settings like fine details for Epson or variations in distances paper to print head hava a greater impact in my opinion.
Must say that my Printing platform had been Lightroom predominantly now for years.
Still looking for a better in terms of printquality, not yet found.
-
…
now my worksheet give me a 0.51 DE2000 for these 2 RGB triplets (100.100.100) and (100,100.5,100). This would suggest we are able to discern more then the 256 tones of an 8 bit print.Thanks,
...
YG
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.
-
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.
-
"But it will at some point even if it's barely noticeable overall your image will definitely have smoother gradient at 16 bit then at 8 bit, it's a fact".
Keeping the above quote in mind it seems to me that this thread has become somewhat convoluted with overlapping references to both 16bit processing and 16bit printing(if there is indeed such a thing). I will freely admit that the possibility that I have misread some of the thread is quite likely, but I do believe that the above quote seems to prove my theory of overlapping subjects. I just checked again to verify the intention of the OP and I was correct. It was not aimed at the value of processing a file in 16bit, it was instead aimed at printing in 16bit -- again, if that is at all possible, which would seem to be in question here. In this case I believe it would probably have been a good idea to address this difference early in the thread, so that we wouldn't be talking apples and oranges as has been the case in some replies. YES INDEED, we do ALL realize and appreciate the advantage(s) of processing a file in 16bit. However, that was never part of the initial question as I read it. It was all about printing in 16bit and whether or not it actually makes any difference in the final outcome. Unfortunately the lines/curves have become crossed and the final outcome is in doubt as I see it.
My rant for the day. Likely nothing of any value, which I imagine will be pointed out soon, and welcomed ;)
Gary
It's always good to be brought back to the original question, as discussions can and do meander and I may have been one to contribute to the meandering for all I know!
So, the O/P was asking whether there is a way to test for sure that a 16-bit data stream is being sent to and used in the printer. For a fulsome discussion of the matter, (perhaps more than the O/P originally intended!), there are perhaps three questions in one here: (1) Is it happening (16-bit data going right through the processing to the print head)? (2) How can I find out for sure? and (3) Does it matter? The conversation here has pointed to ways of trying to answer all three, which I think makes it a more interesting discussion. I don't know where that leaves us, or whether the O/P is satisfied with the feedback.
Personally, on this one, I would be prepared to accept the technical representation, for example from Epson and Adobe, that 16-bit means 16-bit - that the data being processed through the editing software and handed over to the printer driver is 16 bit data, and the printer driver then uses this data, inter alia, for determining the ink recipe being laid down on paper. I don't believe there is such a thing as 16 bit printing, but there is 16-bit data being processed.
-
Thanks for the file, it seems super at first glance, I'm curious about one little thing though, at the top of the sheet it says ProPhoto RGB 16 bit data, so why the file profile is Adobe RGB?
The document absolutely isn't in Adobe RGB (1998). I downloaded it again, it's in ProPhoto RGB. Sounds like your Photoshop color settings are set to automatically Convert and your RGB working space is set to Adobe RGB (1998) or you're converting this elsewhere but no, it's in ProPhoto RGB.
Here is an answer that everyone can verify probably even with a scanner, using the CIE76 Delta E metric and even considering that this metric is not uniform across the spectrum, ie we can see some color difference better then others and that I tested only a few RGB triplets by changing just on color by one 8 bit level say (100, 100,100) compared to (100,101,100), I converted each of those to (XYZ) and then to L*A*B* then applied both CIE76 Delta E and CIEDE2000 and the result are under the just discernible threshold according to my reference, in other words we can't see it
You're getting yourself into a bit of a rabbit hole here. First, dE 76 isn't an ideal formula for reporting small differences in color distance. The scanner isn't the appropriate tool, a Spectrophotometer is. And you can take a very high quality Spectrophotometer like my iSis XL and measure the same print containing solid patches and you'll NEVER see anything close to dE 0.00 due to noise inherent in the device. A fraction of one dE sure, on a good unit. And a dE of 1 or less may or may not be visually perceptual; as a 'rule', we state that less than one isn't a visible difference but it depends again on where in color space you examine the distance. It's why an average dE report, with a good amount of sampling (hundreds or perhaps thousands of measurements) along with the max dE of one patch is useful here. If you measure 500 colors and 499 are all under a dE of 1, but one patch is dE 1.6, that's quite telling. Lastly, consider few targets for creating actual ICC profiles for print are high bit but rather 8-bit per color. Why? Because of the facts outlined already: few printers will use the extra precision of numeric data (device values), and it's just not necessary. If the people making software to create profiles don't feel the need for the extra precision, why go there?
Next, I can't fathom how you'd need to measure solid color patches this way after printing with 16-bit vs. 8-bit. Just output a print and look at it.
Think of this, suppose that on this or that print, you have say in 16 bit a value just barely above the 8 bit level of say 100 and the value of next pixel to it is halfway between 101 and 102.
You're mixing up device values with measured colors and the distance between adjacent colors based on Lab and dE (and the various possible formula). See:
http://digitaldog.net/files/ColorNumbersColorGamut.pdf (http://digitaldog.net/files/ColorNumbersColorGamut.pdf)
You can see how two sRGB values can have differing device values and be the same color with tiny dE differences. Two differing values in 8-bit per color might and can produce a dE higher than 1. Depends on the color space, depends on the two sets of triplets and which differ by one value. But this is really again, a rabbit hole that isn't necessary in confirming if or if not, 16-bit vs. 8-bit per color makes a difference visually or even if the driver did or didn't convert the data from high bit to 8-bits per color somewhere in the print path.
Can you output 16-bits of data to a printer? Well yes you can. Can you see a difference doing so? I don't believe you can. Is this really even 16-bits of data or instead 10, 12- or 14-bits of data? If you're using Photoshop, you're not even truly working in 16-bit!
The high-bit representation in Photoshop has always been "15 + 1" bits (32767 (which is the total number of values that can be represented by 15 bits of precision) 1). This requires 16 bits of data to represent is called "16 bit". It is not an arbitrary decision on how to display this data, it is displaying an exact representation of the exact data Photoshop is using, just as 0-255 is displayed for 8 bit files.
High bit (what some are calling 16-bit but probably isn't that specific encoding) is about editing overhead. All you need is the best 8-bits per color to be sent to an output device. Often, very often, that's all you can send to the hardware anyway. But you have a document you can test to visually see if there's a difference you see printing both ways as I outlined. You don't have to measure anything especially if you don't have the correct measuring device to do so; a high 'accuracy' auto Spectrophotometer.
-
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.
-
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.
How about if you were to examine them considerably magnified? Any difference then?
-
How about if you were to examine them considerably magnified? Any difference then?
The prints were scanned at 600dpi on an old and dusty Epson flatbed scanner (Perfection V30). 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 - it's not that the 8bit has lots of banding, and the 16 bit print has none... rather the placement of the banding seems to change slightly between the prints. The real-life images (fish, boat, textiles) look identical.
-
Make two subsequent scans of THE SAME print. Dollars to doughnuts you'll see differences due to minor registration differences. This is noise. Different in production but not in the results of scanning the same set of targets two times in a row on an auto Spectrophotometer. Which is why if you examine a dE report of two such scans on an auto Spectrophotometer, you'll again NEVER get a 0.00 dE report. 0.09, fine. 0.00, never.
-
Yeah, I figured it was noise.
-
We all know that drum scanning in 16 bit or dslr shooting in raw, then processing outputting these files in 16 bit recorded more tonal data, but no one has done a definitive test that I know of that shows an obvious ( perceivable) difference in print output as a result of checking any 16 bit driver box. I’ve done comparisons with Epson 9890, Canon IpF 8300, and HP z3200, with Oem drivers and third party monochrome rips and I can’t see any improvements from a visual standpoint. ( have not tried with Studio Print or Image Print comparisons though ).
So my question to the software specialists is - why do all the top three printer manufacturers even offer it as an option at all? We’ve been asking this question for about 5 years now and I’ve never learned a logical answer.
John
Yeah, I figured it was noise.
-
If you can edit and print in 16-bit, there is no reason not to. Most people can with the software and hardware they have, so its free. Do so, and avoid all the hand-wringing and angst.
-
So my question to the software specialists is - why do all the top three printer manufacturers even offer it as an option at all? We’ve been asking this question for about 5 years now and I’ve never learned a logical answer.
John
Marketing! Because 99% of people that buy or specify printers just assume 16 bits is better than 8. It's very logical from the point of view of keeping your production line humming.
-
We all know that drum scanning in 16 bit or dslr shooting in raw, then processing outputting these files in 16 bit recorded more tonal data, but no one has done a definitive test that I know of that shows an obvious ( perceivable) difference in print output as a result of checking any 16 bit driver box. I’ve done comparisons with Epson 9890, Canon IpF 8300, and HP z3200, with Oem drivers and third party monochrome rips and I can’t see any improvements from a visual standpoint. ( have not tried with Studio Print or Image Print comparisons though ).
They record finer encoding of numbers. That doesn't necessarily mean anything else visible or otherwise. Improvements in output from what you call RIPs (which may not be but are 3rd party drivers) are not necessarily due to anything having to do with encoding and it's darn difficult if not impossible to pinpoint why one driver produces visually superior prints than another. Just look at say the linearity of output from say an Epson native driver and that from ImagePrint. Can be significant and have absolutely nothing to do per se with bit depth.
Again (and again), high bit data is about data overhead for editing our data. There's always data loss from the rounding errors when we edit numbers. Which is all computers understand. When you aggressively edit an 8-bit per color image in Photoshop or similar, the rounding errors can (repeat can but may not) reduce the data to far less than 8-bits of good data and the result is banding in smooth gradients like a sky, chrome bumper etc. Do so in high bit, it's moot; more than enough data to produce 8-bits of good data for print.
-
The prints were scanned at 600dpi on an old and dusty Epson flatbed scanner (Perfection V30). 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 - it's not that the 8bit has lots of banding, and the 16 bit print has none... rather the placement of the banding seems to change slightly between the prints. The real-life images (fish, boat, textiles) look identical.
"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
-
I was looking at 'the actual prints magnified' — I was just using a scanner instead of a loupe to do the magnification.
(I've also looked at the prints with my eyes (with and without a loupe), and again, I can see no difference.)
-
(I've also looked at the prints with my eyes (with and without a loupe), and again, I can see no difference.)
I'm curious what printer you are using. Is there an advantage to printing 8-bit?
-
I'm using an Epson 3880. I normally print in 16-bit, and I will probably continue to do so (even though my quick test has revealed that there's no advantage to it).
Depending on one's workflow, printing 8-bit might save some hard drive space.
-
I know all that about editing. My point is why do these printers even have that 16 bit output option if their color scientists know there is no point in offering it as an option?
They record finer encoding of numbers. That doesn't necessarily mean anything else visible or otherwise. Improvements in output from what you call RIPs (which may not be but are 3rd party drivers) are not necessarily due to anything having to do with encoding and it's darn difficult if not impossible to pinpoint why one driver produces visually superior prints than another. Just look at say the linearity of output from say an Epson native driver and that from ImagePrint. Can be significant and have absolutely nothing to do per se with bit depth.
Again (and again), high bit data is about data overhead for editing our data. There's always data loss from the rounding errors when we edit numbers. Which is all computers understand. When you aggressively edit an 8-bit per color image in Photoshop or similar, the rounding errors can (repeat can but may not) reduce the data to far less than 8-bits of good data and the result is banding in smooth gradients like a sky, chrome bumper etc. Do so in high bit, it's moot; more than enough data to produce 8-bits of good data for print.
-
I'm using an Epson 3880. I normally print in 16-bit, and I will probably continue to do so (even though my quick test has revealed that there's no advantage to it). Depending on one's workflow, printing 8-bit might save some hard drive space.
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.
-
I know all that about editing. My point is why do these printers even have that 16 bit output option if their color scientists know there is no point in offering it as an option?
Doug explains it in post #32 perfectly.
In the future, depending on the improvements in printer technology, it's possible we may see a difference.
-
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 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.
-
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.
-
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.
-
"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.
-
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.
-
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.)
-
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.
-
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.
-
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?
-
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.
-
The balance of evidence so far...
...is comprised of a few anecdotal reports on a photography forum.
-
Yes, that is correct, but perhaps not insignificant. :-)
-
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.
-
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
-
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
-
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:
(http://www.digitaldog.net/files/raw.jpg)
-
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/
-
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.
-
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.
-
It also applies to conversion from 16 bits to 8 bits when printing/
Does it? Even if it does, one can still test this by:
1. Convert in high bit to the output color space to avoid dither, print the image in the output color space using ACPU, an older version of Photoshop that allows this or another utility similar to ACPU.
2. Keep everything in 16-bit, turn off the 16-bit check box in the printer dialog box.
3. I'd submit that such testing at the very least should be done, on the Mac (for Epson) using a driver that specifically has this check box because newer drivers have no such option and despite my questions to Epson, I haven't received an answer if the newer drivers still pass all high bit to the driver or not. I kind of suspect not, here's why and yes, it's a massive assumption: the high bit check box wasn't available on Windows. This probably didn't make Windows user aware of this happy. It makes some sense to remove it on the Mac as they've done with my P800. That doesn't mean on either Mac or Windows, newer drivers don't 'detect' 16-bit and pass it along if found. But since no one here has provided much proof it makes a visual difference, it would make some sense to simply make it all disappear.
YEARS ago when I was working on the Epson Print Academy I asked the product manager in the US for pro printers why the check box was there if I couldn’t see any difference. He said that 'someday' in the future, the printers might be able to use this additional data and it could be seen on output. I don't believe that day's arrived yet.
-
It doesn't affect 16 bit to 16 bit conversions
So I don't understand why you said:
'Just turning on the dither option eliminates any advantage 16 bit driver paths provide.'
-
Does it? Even if it does, one can still test this by:
1. Convert in high bit to the output color space to avoid dither, print the image in the output color space using ACPU, an older version of Photoshop that allows this or another utility similar to ACPU.
2. Keep everything in 16-bit, turn off the 16-bit check box in the printer dialog box.
3. I'd submit that such testing at the very least should be done, on the Mac (for Epson) using a driver that specifically has this check box because newer drivers have no such option and despite my questions to Epson, I haven't received an answer if the newer drivers still pass all high bit to the driver or not. I kind of suspect not, here's why and yes, it's a massive assumption: the high bit check box wasn't available on Windows. This probably didn't make Windows user aware of this happy. It makes some sense to remove it on the Mac as they've done with my P800. That doesn't mean on either Mac or Windows, newer drivers don't 'detect' 16-bit and pass it along if found. But since no one here has provided much proof it makes a visual difference, it would make some sense to simply make it all disappear.
YEARS ago when I was working on the Epson Print Academy I asked the product manager in the US for pro printers why the check box was there if I couldn’t see any difference. He said that 'someday' in the future, the printers might be able to use this additional data and it could be seen on output. I don't believe that day's arrived yet.
Andrew, just so you'll know, for the Epson SC-P5000, released some time after the SC-P800, driver for OSX, the "Send 16-bit data" checkbox is alive and well - I see it here staring me in the face. We don't know in any detail what happens process-wise under the hood if one leaves it checked or unchecked, but it's there as an option to exercise. There is no guidance in the Manual about what to do with this option; however the link to an Epson support page I provided many posts back explains the principle behind it; now we all know there can be big disconnects between principles and perception, but at least it probably tells us why they think it's a good idea to provide it. Once it's there, I see no downside to just leaving it checked.
-
Andrew, just so you'll know, for the Epson SC-P5000, released some time after the SC-P800, driver for OSX, the "Send 16-bit data" checkbox is alive and well - I see it here staring me in the face.
So much for consistency in drivers. ;)
So does the P800 not do this or it does behind the scenes of Epson decided to bring it back?
Also, you're on a Mac right? Any idea if that option shows up on the Windows driver?
-
Once it's there, I see no downside to just leaving it checked.
Also, there is no apparent upside to leaving it unchecked. Perhaps that's why it has been eliminated in some versions.
-
It also applies to conversion from 16 bits to 8 bits when printing
Yes, this was the only way I could get banding when printing my 16 bit grey gradient: deselect the 16 bit checkbox in the Epson driver, and also deselect the dither checkbox in Photoshop's colour settings.
-
Yes, this was the only way I could get banding when printing my 16 bit grey gradient: deselect the 16 bit checkbox in the Epson driver, and also deselect the dither checkbox in Photoshop's colour settings.
Yet dither should reduce banding.
-
Andrew, yes I'm on OSX 10.11.6 (El Capitan). I have no idea what the situation is with Windows - left that world in 2010. You know, just to show how unimportant this whole question is, you'd have a very hard time discerning a quality difference between a P800 print and a P5000 print unless your photo had a significant presence of colour that is outside the P800 gamut potential but inside that of the P5000 (because of the orange and green inks). That, based on observation when I was doing side-by-side evaluation.
-
Yet dither should reduce banding.
It did.
-
Andrew, yes I'm on OSX 10.11.6 (El Capitan). I have no idea what the situation is with Windows - left that world in 2010. You know, just to show how unimportant this whole question is, you'd have a very hard time discerning a quality difference between a P800 print and a P5000 print unless your photo had a significant presence of colour that is outside the P800 gamut potential but inside that of the P5000 (because of the orange and green inks). That, based on observation when I was doing side-by-side evaluation.
I think it's a useful question to see if indeed Epson is going back to 2010 by providing a driver that does or doesn't allow this option on both platforms, but I absolutely agree the entire discussion is moot because it doesn't matter.
-
It did.
Begging the question then, why did high bit data produce the banding you see? That shouldn’t be the case.
All this stuff about dither is only important IF we know it appears or not when measuring the output to see if high bit vs. 8-bit per color printing produces a visible or measurable difference alone. Dither adds another component into the mix, making it much harder to do an Apples to Apples analysis. IF indeed Dither is being used for a print.
With high bit data, we should never see banding anywhere (in the image, on a print, on a display). With 8-bit per color, that's a possibility. So we're hearing, if I understand you correctly, that with presumably dither added to 8-bit per color output, no banding but with 16-bit printing we do? That doesn't sound right to me..... ;)
-
Begging the question then, why did high bit data produce the banding you see? That shouldn’t be the case.
Hmm, something is getting lost in translation :)
Here's the test I did (pasted from the post I made earlier):
----
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.
-----
-
Hmm, something is getting lost in translation :)
Here's the test I did (pasted from the post I made earlier):
----
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.
-----
But we're being told Dither is taking place at the print path IF I understand correctly, so I don't see how you've altered #3 differently than #4. Now for the color space conversions from working space to output space, that WOULD apply. Which again is why I'm suggesting the only 'fair' test here is to convert to the output color space in high bit, then pass the data to the driver when it's converted in such a fashion OR it's not a fair apples to apples test to determine what the driver, not Photoshop (which isn't the only product that we can print from or has such dither features) is doing.
-
I have always been under the impression, based on stuff I've read previously, that dithering takes place in the printer driver as part of the recipe for laying down the ink. Or is this about some other kind of dithering? This thread on our Forum may help: Doug Grey on Dithering (https://forum.luminous-landscape.com/index.php?topic=120802.0)
-
Once it's there, I see no downside to just leaving it checked.
Also, there is no apparent upside to leaving it unchecked. Perhaps that's why it has been eliminated in some versions.
-
I'm somewhat out of my depth here :)
I performed these tests as Doug Gray suggested that by having dither selected, I was throwing a spanner into the 16 bit printing pipeline.
I couldn't see any evidence of that.
I did see that having dither UNSELECTED, caused banding when sending a 16 bit file into an 8 bit printing pipeline.
(FWIW, I'm using 'Photoshop Manages Colors' in the Epson print driver, Relative Colorimetric, and BPC.)
-
I have always been under the impression, based on stuff I've read previously, that dithering takes place in the printer driver as part of the recipe for laying down the ink. Or is this about some other kind of dithering?
Yes, this is about another kind of dithering.
-
Yes, this is about another kind of dithering.
OK, what kind of dithering is this and where do I find it?
-
it's dithering of the image file to prevent banding.
-
OK, what kind of dithering is this and where do I find it?
Yes, I know what it's for - that's one reason amongst others depending on the printer; but I'm asking WHERE you control whether it is active or not.
-
Yes, I know what it's for - that's one reason amongst others depending on the printer; but I'm asking WHERE you control whether it is active or not.
Exactly. There may indeed be dithering happening in the print path alone and we can't control that. But we can control dither in Photoshop depending on one setting and what edits we apply on what kinds of data. That IMHO invalidates all this talk since the OP is asking about 16-bit printing and we all know (hate that term, most of us know) that not everyone is printing in Photoshop.
-
Yes, I know what it's for - that's one reason amongst others depending on the printer; but I'm asking WHERE you control whether it is active or not.
It's not a print-specific thing. It's a photoshop thing to prevent banding when converting between colourspaces, and when converting from 16 bit to 8 bit. It's here:
Photoshop > Color Settings > Conversion Options > Use Dither
-
It is checked by default (I believe), and I can't see any reason to uncheck it.
-
Ah, yes indeed - and it is specified for 8-bit images in brackets beside the option, and it is checked by default, which I too have never touched. I hardly ever work with 8-bit images so it's irrelevant, and for the odd 8-bit JPEG I may work with, it's best left checked. And it has nothing to do with the original question of this thread.
-
And it has nothing to do with the original question of this thread.
Not so, according to Doug Gray, who earlier in the thread said:
'Just turning on the dither option eliminates any advantage 16 bit driver paths provide which is mostly theoretical in any case.'
-
Not so, according to Doug Gray, who earlier in the thread said:
'Just turning on the dither option eliminates any advantage 16 bit driver paths provide which is mostly theoretical in any case.'
That may well be the case but not related to the O/P's question about how to detect whether 8 or 16 bit data is being used in the printer driver. That's what I was getting at.
-
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:
I know your right and everyone else knows your right, it's just semantics. You did as I do very often unfortunately, you took what you wanted to see in my phrase and wrote what you did. But I used "possible colors" in my phrase which is also inaccurate, as you mention nothing in a raw file is truly a color value if you want to be very strict.
All of this still doesn't answer my question that I'll simplify even more here.
Is it possible or not to tell if a print was made (I don't know the proper word(s) to use here, so Ill' try) from a 16 bit image file?
Regards,
YG
-
............
Is it possible or not to tell if a print was made (I don't know the proper word(s) to use here, so Ill' try) from a 16 bit image file?
Regards,
YG
I think you've already been advised here - in spades - that the answer is "very unlikely". What else do you want to know?
-
I know your right and everyone else knows your right, it's just semantics. You did as I do very often unfortunately, you took what you wanted to see in my phrase and wrote what you did. But I used "possible colors" in my phrase which is also inaccurate, as you mention nothing in a raw file is truly a color value if you want to be very strict.
All of this still doesn't answer my question that I'll simplify even more here.
Is it possible or not to tell if a print was made (I don't know the proper word(s) to use here, so Ill' try) from a 16 bit image file?
The answer was provided days ago, along with the warning this was a rabbit hole.
No, it's not semantics, some color numbers are not colors, no matter how fine you divide them up.
Mark just before I also answered the question.
All this stuff about Dither in PS is just more dirt beside the hole.
Lastly, you were told how you can test this, on your end with whatever printer and software you might be using. Once you figure out how (IF so) you converted that data to Adobe RGB (1998) which would alone, invalidate the testing before even pressing the "Print" button.
Are you getting more acceptable answers to the same question over on DP-review? (https://www.dpreview.com/forums/post/61797451)
-
That may well be the case but not related to the O/P's question about how to detect whether 8 or 16 bit data is being used in the printer driver. That's what I was getting at.
It seems closely related to the OP's question. Doug is saying that by having 'Use Dither' checked, the 16 bit pipeline is invalidated. 99.9% of photographers have 'Use Dither' checked, as this is the Adobe default. Therefore, when they say that it is impossible to distinguish a 16 bit print from an 8 bit print, they are making that judgement based on incorrect Photoshop settings.
But I think Doug is wrong about this. I don't think the 'Use Dither' checkbox has any effect on the 16 bit print pipeline.
16 bit prints look the same as 8 bit prints. That's just how it is.
-
I think you've already been advised here - in spades - that the answer is "very unlikely". What else do you want to know?
All answers I've seen so far are like yours, "very unlikely" and though it may be right, it still doesn't answer the question since none of you can say for sure they are printing at 16 bit or not.
Like others, I've been going at Canon because I have a Canon but some of you went to Epson for the same reasons and they all came back with the same answer, yes we have a 16 bit driver for that printer (in my case) So I ask again why would a company like Canon and probably like Epson as well would spent money on a useless project like making a 16 bit driver for a printer?
My answer is I really don't see why those company would waste money on something that is "very unlikely" to make any difference whatsoever. It simply doesn't make sense.
Please help me figure that one out?
edit: from https://www.epson.com.mt/viewcon/corporatesite/products/mainunits/faq/1228/21266 almost last line.
"Epson's 16-bit printer drivers are compatible with virtually any application software for an end-to-end 16-bit workflow."
Why in the world would a company like Epson waste it's time and especially it's money to be able to do just that (if "very unlikely to be useful" is beyond me, please explain?
Thanks in advance,
YG
-
It seems closely related to the OP's question. Doug is saying that by having 'Use Dither' checked, the 16 bit pipeline is invalidated. 99.9% of photographers have 'Use Dither' checked, as this is the Adobe default. Therefore, when they say that it is impossible to distinguish a 16 bit print from an 8 bit print, they are making that judgement based on incorrect Photoshop settings.
But I think Doug is wrong about this. I don't think the 'Use Dither' checkbox has any effect on the 16 bit print pipeline.
16 bit prints look the same as 8 bit prints. That's just how it is.
I would be grateful if you can explain what OP's mean? I'm useless with these, sorry.
-
OP is the Original Post(er)
-
OP is the Original Post(er)
Thank you very much.
-
It seems closely related to the OP's question. Doug is saying that by having 'Use Dither' checked, the 16 bit pipeline is invalidated. 99.9% of photographers have 'Use Dither' checked, as this is the Adobe default. Therefore, when they say that it is impossible to distinguish a 16 bit print from an 8 bit print, they are making that judgement based on incorrect Photoshop settings.
But I think Doug is wrong about this. I don't think the 'Use Dither' checkbox has any effect on the 16 bit print pipeline.
16 bit prints look the same as 8 bit prints. That's just how it is.
I also think Doug is incorrect. It's pretty clear that whether or not it is checked the option only applies to 8-bit image files. It does not mean this is an option to select an 8 or 16 bit file format. This is my interpretation of what Adobe means in that option dialog.
The OP - my understanding- only asked whether it's possible to see on the print whether the printer is using 16-bit data when that option is selected in the printer driver. I don't see how this relates to the Photoshop option, especially if given my understanding of what that option is for. Anyhow, it doesn't matter. I think we've beaten this topic to death.
-
All answers I've seen so far are like yours, "very unlikely" and though it may be right, it still doesn't answer the question since none of you can say for sure they are printing at 16 bit or not.
If you tell us what answer you'll like and accept, maybe someone (probably over on DPR) will make such a statement.
Like others, I've been going at Canon because I have a Canon but some of you went to Epson for the same reasons and they all came back with the same answer, yes we have a 16 bit driver for that printer (in my case) So I ask again why would a company like Canon and probably like Epson as well would spent money on a useless project like making a 16 bit driver for a printer?
You were provided steps to do your own testing. I suggest you do so, then come up with whatever conclusions you desire.
My answer is I really don't see why those company would waste money on something that is "very unlikely" to make any difference whatsoever. It simply doesn't make sense.
So that's the answer you want someone else to produce?
Doug's answer, concerning marketing IMHO explains to pretty well. And I can site a lot of other similar marketing created features that really are nothing more than marketing.
Please help me figure that one out?
You were.
-
All answers I've seen so far are like yours, "very unlikely" and though it may be right, it still doesn't answer the question since none of you can say for sure they are printing at 16 bit or not.
Doug Gray, with his dark gradient, has demonstrated that there IS a difference - i.e. that there IS a 16 bit print path. But in normal printing scenarios it makes no discernible difference to the final print.
I really don't see why those company would waste money on something that is "very unlikely" to make any difference whatsoever. It simply doesn't make sense.
It might not have cost very much money at all. After all, it's only numbers. And it's good marketing.
-
It seems closely related to the OP's question. Doug is saying that by having 'Use Dither' checked, the 16 bit pipeline is invalidated. 99.9% of photographers have 'Use Dither' checked, as this is the Adobe default. Therefore, when they say that it is impossible to distinguish a 16 bit print from an 8 bit print, they are making that judgement based on incorrect Photoshop settings.
But I think Doug is wrong about this. I don't think the 'Use Dither' checkbox has any effect on the 16 bit print pipeline.
16 bit prints look the same as 8 bit prints. That's just how it is.
This exactly why I keep asking the question, most say it's "very unlikely" the print will show some difference and I believe it's "very likely" they are not printing on a full fledged 16 bit pipeline, for whatever the reasons like discuss here.
I don't see companies wasting money it it was as useless as the replies here suggest. It makes no sense whatsoever.
My personal belief is that companies don't waste money for useless thing for so long. There must be a benefit both for them and for the resulting prints.
YG
-
Anyhow, it doesn't matter. I think we've beaten this topic to death.
Indeed, we have :)
-
It's more likely internal marketing by zealous engineers.
-
Good grief, this thread is posted faster than I can type.
Doug is saying that by having 'Use Dither' checked, the 16 bit pipeline is invalidated.
Why is it invalidated? Dithering (and noise shaping) is an essential step of digital filters, especially for bit-depth changes. It is unclear why Adobe even lets you turn it off. Perhaps for scientific applications.
99.9% of photographers have 'Use Dither' checked, as this is the Adobe default. Therefore, when they say that it is impossible to distinguish a 16 bit print from an 8 bit print, they are making that judgement based on incorrect Photoshop settings.
From a signal processing point of view, having dithering on is the only "correct" setting.
Is it possible or not to tell if a print was made (I don't know the proper word(s) to use here, so Ill' try) from a 16 bit image file?
If dithering is correctly applied (ON both in Photoshop and internally in the printer driver and printer hardware), no, you can't tell.
If dithering is not applied (OFF both in Photoshop and internally in the printer driver and printer hardware), yes, you can tell very easily.
If dithering is not applied in Photoshop (OFF) but it is applied internally in the printer driver and printer hardware (ON), maybe you can see it, maybe not.
Not so, according to Doug Gray, who earlier in the thread said: 'Just turning on the dither option eliminates any advantage 16 bit driver paths provide which is mostly theoretical in any case.'
Noise shaped dithering allows to encode signal amplitudes below the naive noise floor of N stops of dynamic range, where N is the bit depth. So yes, dithering allows to encode signals of less than 1 bit of amplitude with an 8 bit signal, so less than 8 bits of amplitude with a 16 bit signal. It's a similar effect to increasing bit depth. Dithering does this at the expense of noise, but the assumption is that printer noise dwarfs dithering noise.
There may indeed be dithering happening in the print path alone and we can't control that.
Yes, almost certainly it has to be. The printer head/mechanics are driven by an analog signal that is generated by DACs on the printers. The digital input to these DACs is not the image file, it's some other kind of digital signal derived from the image file (either in the driver, or in the hardware itself). This signal processing involved in generating these digital signals most certainly applies dithering (and very likely involves bit depth conversions) because there is no reason why it would not.
-
Good grief, this thread is posted faster than I can type.
Why is it invalidated? Dithering (and noise shaping) is an essential step of every digital filter, especially for bit-depth changes. It is unclear why Adobe even lets you turn it off. Perhaps for scientific applications.
Yes! Those of us that use Photoshop for colorimetric testing need such an option. And more to the point, not all software products that can print photos provide this option or control. So unless we know the OP is only using Photoshop and only cares about this so called 16-bit print path, then we either need to address or ignore it's use.
From a signal processing point of view, having dithering on is the only "correct" setting.
Except when it isn't. ;)
If dithering is correctly applied (ON both in Photoshop and internally in the printer driver and printer hardware), no, you can't tell.
Dither can be applied, on some kinds of data in Photoshop. I don't believe Photoshop has any such control over the print driver (which driver?). And even if they do, we have no idea if the dither is the same when used to make say colors space conversions which is WHY we see the option where it resides.
The key word above and below it s IF!
-
Good grief, this thread is posted faster than I can type.
LOL!
Why is it invalidated? Dithering (and noise shaping) is an essential step of digital filters, especially for bit-depth changes. It is unclear why Adobe even lets you turn it off. Perhaps for scientific applications.
Right. it's not invalidated, it's just superfluous. The printer driver does its own dithering when it comes up with a recipe for a small set of inks.
From a signal processing point of view, having dithering on is the only "correct" setting.
Right. The only disadvantage is that the image can be less compressible because it has higher entropy. However, as a practical matter, there is usually little difference since photo images normally have significant bit noise in them already. Mostly the size difference shows up when converting synthetic images.
If dithering is correctly applied (ON both in Photoshop and internally in the printer driver and printer hardware), no, you can't tell.
If dithering is not applied (OFF both in Photoshop and internally in the printer driver and printer hardware), yes, you can tell very easily.
If dithering is not applied in Photoshop (OFF) but it is applied internally in the printer driver and printer hardware (ON), maybe you can see it, maybe not.
Noise shaped dithering allows to encode signal amplitudes below the naive noise floor of N stops of dynamic range, where N is the bit depth. So yes, dithering allows to encode signals of less than 1 bit of amplitude with an 8 bit signal, so less than 8 bits of amplitude with a 16 bit signal. It's a similar effect to increasing bit depth. Dithering does this at the expense of noise, but the assumption is that printer noise dwarfs dithering noise.
Well stated.
Yes, almost certainly it has to be. The printer head/mechanics are driven by an analog signal that is generated by DACs on the printers. The digital input to these DACs is not the image file, it's some other kind of digital signal derived from the image file (either in the driver, or in the hardware itself). This signal processing involved in generating these digital signals most certainly applies dithering (and very likely involves bit depth conversions) because there is no reason why it would not.
-
The printer driver does its own dithering when it comes up with a recipe for a small set of inks.
And we have no control over that dither. Is it different if someone sends 16-bit or not? How to know?
The dither option in PS is a red herring rabbit hole. Unless again the OP wants some answer that only applies to Photoshop. And someone can demonstrate what's really happening which is the crux of this discussion as the hole gets deeper.
Why not make two prints, look at em and move on?
-
I quoted you just so you know I'm trying to talk to you. Someone said you replied with something about dark gradient. Can you or someone else give me the number of the post, just to make sure I have the right one, thanks.
-
Someone said you replied with something about dark gradient.
Post #21
-
Are you getting more acceptable answers to the same question over on DP-review? (https://www.dpreview.com/forums/post/61797451)
They did show one image where banding was visible on an 8-bit print but not a 16-bit print, so why not print in 16-bit and avoid the issue, even if it rarely comes up? There doesn't appear to be any downside. How much effort does it take to check a box and then not worry about it?
-
This has to be one of the most pointless, in a practical sense, discussions ever. No one here has ever claimed, or can even point to anyone, that sees a difference between printing a 16 bit, non-synthetic, photo image using either an 8 bit path or 16 bit path at the driver.
None the less it appears to be an interesting technical discussion.
So, in honor of Bill Atkinson, I have created an image I call Bills Black Ball. The reason that Bill's set of color gradient balls were created was because Bill felt that banding was easier to see in circles rather than linear gradients.
The attached tiff image, in ProPhoto RGB, has RGB values ranging from RGB(20,20,20) to RGB(35,35,35) at the outer edges. It is quite suitable for demonstrating 8 bit or higher paths for both monitors and printers.
For Monitors:
View this in Photoshop with the background set to black and full press the 'F' key so the screen menus don't show. Banding on 8 bit displays should be quite obvious. It's even more obvious if you use a display setting at max cd/m^2 and/or if you make a special monitor profile using gamma=1.5 or lower. It's a good way to tell if your Monitor/CPU/Display driver is actually producing 30 bit image results.
For Printers:
Print with a 8 bit driver using Null-Transform or RelCol on a glossy type paper or anything with Dmax of 2 or higher. Make sure the Edit->Photoshop->Dither option is off. It's best to print this w/o using color management using the Null-Transform technique but it can be printed normally too. The banding will be more regular with the Null Transform but will occur with both. You should then trim the white borders of the print and examine the print in a bright light. The banding will be quite obvious.
This can be repeated with the Dither selected and all or most all of the visible banding will disappear.
-
They did show one image where banding was visible on an 8-bit print but not a 16-bit print, so why not print in 16-bit and avoid the issue, even if it rarely comes up? There doesn't appear to be any downside. How much effort does it take to check a box and then not worry about it?
+1 and none.
-
They did show one image where banding was visible on an 8-bit print but not a 16-bit print, so why not print in 16-bit and avoid the issue, even if it rarely comes up? There doesn't appear to be any downside. How much effort does it take to check a box and then not worry about it?
+1 and none.
Yup. I just wouldn't pick a printer based on whether it supported 16 bit or 8 bit printer paths. It's got to be one of the most insignificant specs ever.
-
Yup. I just wouldn't pick a printer based on whether it supported 16 bit or 8 bit printer paths. It's got to be one of the most insignificant specs ever.
It looks like the Canon, Epson, and HP photo printers support 16-bit, so you don't really have to make a choice, other than to check the box. And it looks like with the Windows versions you don't even have the choice not to.
-
Now that we have what to print next thread should be about how to test if a scan of that print was really made at 48 bit or not! Then we need to print the scan again, just to make sure.
-
Now that we have what to print next thread should be about how to test if a scan of that print was really made at 48 bit or not! Thrn we need to print the scan again, to make sure.
Just to anticipate that discussion, what if I told you my 48-bit scanners actually uses 64-bit when the infra-red channel is activated? ;D
-
This has to be one of the most pointless, in a practical sense, discussions ever. No one here has ever claimed, or can even point to anyone, that sees a difference between printing a 16 bit, non-synthetic, photo image using either an 8 bit path or 16 bit path at the driver.
None the less it appears to be an interesting technical discussion.
So, in honor of Bill Atkinson, I have created an image I call Bills Black Ball. The reason that Bill's set of color gradient balls were created was because Bill felt that banding was easier to see in circles rather than linear gradients.
The attached tiff image, in ProPhoto RGB, has RGB values ranging from RGB(20,20,20) to RGB(35,35,35) at the outer edges. It is quite suitable for demonstrating 8 bit or higher paths for both monitors and printers.
For Monitors:
View this in Photoshop with the background set to black and full press the 'F' key so the screen menus don't show. Banding on 8 bit displays should be quite obvious. It's even more obvious if you use a display setting at max cd/m^2 and/or if you make a special monitor profile using gamma=1.5 or lower. It's a good way to tell if your Monitor/CPU/Display driver is actually producing 30 bit image results.
For Printers:
Print with a 8 bit driver using Null-Transform or RelCol on a glossy type paper or anything with Dmax of 2 or higher. Make sure the Edit->Photoshop->Dither option is off. It's best to print this w/o using color management using the Null-Transform technique but it can be printed normally too. The banding will be more regular with the Null Transform but will occur with both. You should then trim the white borders of the print and examine the print in a bright light. The banding will be quite obvious.
This can be repeated with the Dither selected and all or most all of the visible banding will disappear.
So this test demonstrates that it's a bad idea to turn off 'Use Dither' in Adobe's Colour Settings when printing a 16 bit file to an 8 bit print pipeline? Hmm, I'm not sure if anyone would have even considered turning it off unless you had brought it up.
With 'Use Dither' turned on, prints from an 8 bit and 16 bit pipeline look the same - no banding.
And prints using the 16 bit pipeline loos identical, regardless of whether 'Use Dither' is on or off.
-
..................
And prints using the 16 bit pipeline loos identical, regardless of whether 'Use Dither' is on or off.
........which confirms my above-mentioned interpretation of what that option applies to - 8-bit only.
-
Just to anticipate that discussion, what if I told you my 48-bit scanners actually uses 64-bit when the infra-red channel is activated? ;D
I've actually looked at the effective bit depth of 48 v 24 bit reflective scans on the V850. Turns out there is only a slight gain with 48 bits however if one does multiple scans and averages the result some additional bit depth can be discerned. On average individual pixels in an 8 bit channel have rounding noise that is about twice that of the same pixels in 16 bit channels where photon noise dominates for an effective bit depth of 9. Averaging 4 scans together and comparing them to another 4 scans reduces the pixel variations by about 40% which is just under 10 effective bits.
However, there is considerable variation from one pixel to another that seems to be due to slight variations in the CFAs and this is on the order of an lsb of an 8 bit channel. So only a little is gained since the CFA effect is stationary and not improved by averaging. However, I don't know if this applies to transmission scans.
In any case I see no value in 48 bit reflective scans v 24 bit ones. Higher DPI scans are another story though there is significant rolloff above 300DPI on reflective scans though it's quite gradual. It requires sharpening for scanning images with fine detail to recover the detail.
-
In any case I see no value in 48 bit reflective scans v 24 bit ones.
Until you begin to edit the scans after scanning them (if you do). Again, the added precision is about editing the data, if the data is edited.
-
........which confirms my above-mentioned interpretation of what that option applies to - 8-bit only.
Right. The dither option affects conversions from different 8 bit colorspaces as well as conversion from 16 bits to 8 bits in the same colorspace. It doesn't affect 16 bit to 16 bit conversions at all.
It appears to quite a smart "dither." For instance if you have an RGB value of (127.25, 127.25,127.25) in 16 bits and convert to 8 bits it will populate with approx. 25% (127,127,127) and 75% (128,128,128) rather than just adding a low level of noise. It's likely it does the exact same thing when converting to an 8 bit printer driver.
-
Until you begin to edit the scans after scanning them (if you do). Again, the added precision is about editing the data, if the data is edited.
Agreed about the editing which should always be done in 16 bits if possible. One can introduce significant artifacts editing in 8 bits. Especially if one has a heavy hand. It would be interesting technically to try editing both an 8 bit scan and a 16 bit scan but initially converting the 8 bit to 16. Not sure any visible difference would show up. But it's also a pointless exercise since just scanning to 16 bits/ch is simpler.
-
They did show one image where banding was visible on an 8-bit print but not a 16-bit print, so why not print in 16-bit and avoid the issue, even if it rarely comes up?
I'm not so sure.
This is their example (Doug's example?):
https://www.dpreview.com/forums/post/61793580
It is not clear how it was printed.
I can only induce banding like that if I print a 16 bit gradient with either:
1. Adobe Color Print Utility, with 16 bit unchecked
or:
2. Photoshop, with 16 bit unchecked, AND 'Use Dither' unchecked (in Photoshop's Color Settings)
Neither of these printing methods represent a set-up that would be used to make a normal 8-bit print. In a real-world scenario Photoshop would be used, '16 bit' would be unchecked, and 'Use Dither' would be checked. The resulting 8 bit print would be indistinguishable from a 16 bit print.
-
I'm not so sure.
This is their example (Doug's example?):
https://www.dpreview.com/forums/post/61793580
It is not clear how it was printed.
I can only induce banding like that if I print a 16 bit gradient with either:
1. Adobe Color Print Utility, with 16 bit unchecked
or:
2. Photoshop, with 16 bit unchecked, AND 'Use Dither' unchecked (in Photoshop's Color Settings)
Neither of these printing methods represent a set-up that would be used to make a normal 8-bit print. In a real-world scenario Photoshop would be used, '16 bit' would be unchecked, and 'Use Dither' would be checked. The resulting 8 bit print would be indistinguishable from a 16 bit print.
Adobe Print Utility only works with 8 bit images. I'm just guessing but there is a simplified TIF reading C utility shown in libtiff. It can read virtually any tiff format file but has the downside that it converts anything not in 8 bit to 8 bit.
I recommend Bills Black Ball that I posted earlier to verify 16 bit paths. It's in ProPhoto and doesn't need to be printed w/o color management to show banding from an 8 bit printer path where dither wasn't selected. Can be printed from LR too using RelCol w BPC. I have no idea if LR automatically dithers when printing to an 8 bit driver from a 16 bit gradient like Bills Black Ball. Perhaps someone will test it.
Printing from a 16 bit file w/o color management and w/o converting to 8 bits is done by most using older Photoshops that allowed it. They removed it years ago because of compatibility issues with Macs.
-
Adobe Print Utility only works with 8 bit images.
My copy prints 16-bit images, no problem. What makes you say this and why would Adobe not allow 16-bit images to be printed?
Just output my Gamut Test File in high bit to the 3880 using ACPU.
-
My copy prints 16-bit images, no problem. What makes you say this and why would Adobe not allow 16-bit images to be printed?
Yeah, mine too
Just output my Gamut Test File in high bit to the 3880 using ACPU.
So did I :) I was interested to see if there is any difference between selecting 8 bit or 16 bit, but I can't really see it (I do see it with Doug's Ball image).
-
In a real-world scenario Photoshop would be used, '16 bit' would be unchecked, and 'Use Dither' would be checked. The resulting 8 bit print would be indistinguishable from a 16 bit print.
Why, in a real world scenario, would 16-bit be unchecked?
-
Why, in a real world scenario, would 16-bit be unchecked?
I imagine it would only be unchecked in a situation where a photographer was trying to establish whether there's a difference between printing in 8 bit and 16 bit.
-
I don't understand how apps relate to the Epson print driver.
Is the print dialog in ACPU a barebones version of the Epson print driver?
If it is, then when we use it to print Doug's ball target (or a slither of it, to save ink), at 8 bit and at 16 bit, we thereby demonstrate (to the OP) that there is a visible difference in Epson's 8 bit and 16 bit printing pipeline.
We can't do this with Photoshop*, because when printing from Photoshop, the Epson driver utilises Photoshop's dithering algorithm, which makes an 8 bit print of a 16 bit file looks identical to a 16 bit print. (*Unless we switch off dithering in Color Settings.)
Right?
(All my test prints from Photoshop have been done using 'Photoshop Manages Colors'. Whether 'Printer Manages Colors' handles 16 bit gradients in the same way is another can of worms.)
-
I imagine it would only be unchecked in a situation where a photographer was trying to establish whether there's a difference between printing in 8 bit and 16 bit.
Or for the marketing department to show it as a "feature' that most of us have found, doesn't do anything. ;)
If I had a dollar for every marketing dept at a display company telling us their displays produce billions of colors.... It's rubbish. But people see the 'spec's for a 10 bit display, then a 12 bit one and think the higher value is a spec that's important in buying said display.
-
Is the print dialog in ACPU a barebones version of the Epson print driver?
Not at all. More like a barebones copy of Photoshop that does one thing: Print an image. Using a print driver.
-
Until you begin to edit the scans after scanning them (if you do). Again, the added precision is about editing the data, if the data is edited.
That's correct. Depending on the quality of the profiling, the media, the scanner and the initial rendition from the scan software, scans can require some substantial pixel-bending and the 48 bit files are definitely more robust.
-
That's correct. Depending on the quality of the profiling, the media, the scanner and the initial rendition from the scan software, scans can require some substantial pixel-bending and the 48 bit files are definitely more robust.
Certainly when one needs a selective edit rather than a global one that should be doable in the scanner software.
-
Not at all. More like a barebones copy of Photoshop that does one thing: Print an image. Using a print driver.
Andrew, did we ever receive a definitive explanation of how ACPU really works? It definitely reaches into the printer driver, but once there, offers only a limited menu of options that the user can adjust (such as in the Printer Settings tab and the Advanced Media Control tab in OSX), on purpose, because the whole idea is to use it for printing a file that is both unedited and without colour management, the question being exactly how it gets around colour management in OSX. Some opinion suggests it uses the null transform method that Eric Chan developed before Adobe offered ACPU. Do you know the underlying principles of its structure?
-
Andrew, did we ever receive a definitive explanation of how ACPU really works?
I have absolutely no idea. For that or any other software product. So few of us need it anyway and it hasn't been updated for so long, I'm surprised it still runs (but it does).
-
Not at all. More like a barebones copy of Photoshop that does one thing: Print an image. Using a print driver.
But whose driver? Adobe's? Apple's?
It has a 16 bit option, but I'm assuming that when it is unchecked, it doesn't apply dithering (to the 16 bit file). Hence the banding.
-
Certainly when one needs a selective edit rather than a global one that should be doable in the scanner software.
Sure. Well, in SilverFast 8 Ai Studio one can do a considerable range of high quality global and selective editing, and under the hood SilverFast automatically always processes the file in 48 bit to preserve quality, but will then output the file to a 24-bit format if one so chooses.
-
Agreed about the editing which should always be done in 16 bits if possible. One can introduce significant artifacts editing in 8 bits. Especially if one has a heavy hand. It would be interesting technically to try editing both an 8 bit scan and a 16 bit scan but initially converting the 8 bit to 16. Not sure any visible difference would show up. But it's also a pointless exercise since just scanning to 16 bits/ch is simpler.
As I just mentioned, with SilverFast edits are always automatically processed in 16-bit per channel and this is under the hood - no user control; but the user can select an 8-bit output format if desired. It saves storage space, but there is no other advantage to it.
-
But whose driver? Adobe's? Apple's?
I don't understand the question. It is Adobe's baby no question. It uses any number of print drivers AFAIK. Why would there be any limitation for it to pass data (not color managed) to any driver? I can do the same with the ColorSync utility and a few other pieces of software not from Adobe.
Adobe didn't want to allow non color managed data to sent through it to a driver but we need that for printing targets (send the numbers as is to the driver). So around what was it, CS5, they didn't allows this rare print process. Because some complained or just to be good guys, the provided this utility. Something a color management software product should handle anyway to print a target. To allow this limited need, they provided the free ACPU. But it's not the only software that can do this.
-
I don't understand the question.
i'm asking whose 16 bit checkbox is that? Is it Adobe's? Or Epson's? Does it appear with whatever printer you have hooked up?
-
I have absolutely no idea. For that or any other software product. So few of us need it anyway and it hasn't been updated for so long, I'm surprised it still runs (but it does).
For Epson printers ACPU is the only thing I use for printing the targets, albeit aged but thank goodness still workable. It produces really correct results to judge from the multiple profiles I have generated from those targets, providing impressive accuracy of colour rendition and tone ramp on paper. If it stops working, one could of course also print the targets from i1Profiler. For the new generation of Canon large format Pro printers neither does well for profiling - it is better to use Canon's Print Studio Pro.
-
i'm asking whose 16 bit checkbox is that? Is it Adobe's? Or Epson's? Does it appear with whatever printer you have hooked up?
Sorry, which check box? Can you post a screen capture?
-
i'm asking whose 16 bit checkbox is that? Is it Adobe's? Or Epson's? Does it appear with whatever printer you have hooked up?
It's Epson's - at least with the SC-P5000 printer. I don't know for other printers but I would assume likewise as long as the printer supports it.
-
Sorry, which check box? Can you post a screen capture?
Got it - here you go.
-
Is this where I found out I'm doing something wrong?!
-
I don't understand how apps relate to the Epson print driver.
Is the print dialog in ACPU a barebones version of the Epson print driver?
If it is, then when we use it to print Doug's ball target (or a slither of it, to save ink), at 8 bit and at 16 bit, we thereby demonstrate (to the OP) that there is a visible difference in Epson's 8 bit and 16 bit printing pipeline.
We can't do this with Photoshop*, because when printing from Photoshop, the Epson driver utilises Photoshop's dithering algorithm, which makes an 8 bit print of a 16 bit file looks identical to a 16 bit print. (*Unless we switch off dithering in Color Settings.)
Right?
(All my test prints from Photoshop have been done using 'Photoshop Manages Colors'. Whether 'Printer Manages Colors' handles 16 bit gradients in the same way is another can of worms.)
Let's be clear: ACPU is used only for printing profiling targets - or at least that's the only use for it I'm aware of. Do not use it for normal photographic printing. It does not open Photoshop. No Photoshop settings are relevant. It handles 16-bit data between itself and the drivers of supported printers. It moves the file onto paper somehow neutralizing colour management so that only the native behaviour of the printer and the target media are being characterized. This is what is needed for building a printer profile.
-
Is this where I found out I'm doing something wrong?!
I see nothing wrong there - looks like best practice choice of options.
-
I think I'm clear about ACPU's use. Before today, I've only ever used it to print profile targets.
What I'm curious about is that if you use it to print a 16 bit gradient, and don't check '16 bit', then the resulting print displays banding. This doesn't happen if you do the same thing when printing from Photoshop.
-
But it's not meant for printing gradients, why even try. I'd just use it for its intended purpose and forget about playing with it for unintended uses; I value my time - a lot.
-
But it's not meant for printing gradients, why even try.
Doug Gray suggested it.
I'm trying it because I think it demonstrates to the OP that there is a genuine 16 bit Epson printing pipeline (rather than a cosmetic 16 bit checkbox that does nothing).
The reason that the 16 bit checkbox appears to have no beneficial affect when printing from Photoshop, is that Photoshop's 8 bit pipeline utilises a very sophisticated dithering algorithm that successfully masks any banding.
-
Is this where I found out I'm doing something wrong?!
That is 100% Epson. I have it on my 3880 but not on my newer P800 and as mentioned, the 3880 only on Mac OS had it hence my question to Mark about the newer printer he owns. But he’s on a Mac too. So I would love to know if someone on Windows has such an option.
-
Doug Gray suggested it.
I'm trying it because I think it demonstrates to the OP that there is a genuine 16 bit Epson printing pipeline (rather than a cosmetic 16 bit checkbox that does nothing).
The reason that the 16 bit checkbox appears to have no beneficial affect when printing from Photoshop, is that Photoshop's 8 bit pipeline utilises a very sophisticated dithering algorithm that successfully masks any banding.
That makes sense.
-
My copy prints 16-bit images, no problem. What makes you say this and why would Adobe not allow 16-bit images to be printed?
Just output my Gamut Test File in high bit to the 3880 using ACPU.
Yeah. Mine prints 16 bit images too. Nothing I said suggests it doesn't print 16 bit images. It just converts them to 8 bits first and produces exactly the same banding as printing BillsBlackBall in Photoshop w/o dither and no color management to my 8 bit driver.
I just did it on my Windows 10 x64.
And selecting dither fixes it.
Keep in mind this is hard to see. You have to print the Ball out, trim the white edges, and view it under a strong light - a flashlight works pretty well. But only illuminate the print. if you have anything nearby that the strong light hits it will keep your eyes from adapting.
Recall that creating an image that can actually detect 16 bit v 8 bit printer paths is not easy. In fact the bands are only .4 dE00 apart. This is why they aren't normally visible. However, if you follow the instructions to remove the white borders and look at the print under a strong light, this has the effect of multiplying the dE00 separations and makes the banding visible. This is also why to check a monitor one has to get rid of the white background and ideally use a black one.
The dE00 metric assumes one is viewing two patches, close but not touching, against a neutral L*=50 background. The relative brightness overwhelms the banding. But viewing against a black background brings it out because the eye adapts to the lower illumination and smaller dE00s become magnified and visible.
But this is with Windows and it's possible the Mac ACPU differs.
-
Yeah. Mine prints 16 bit images too. Nothing I said suggests it doesn't print 16 bit images.
I must have misunderstood this:
Adobe Print Utility only works with 8 bit images.
-
I must have misunderstood this:
Adobe Print Utility only works with 8 bit images.
The full quote was this:
Adobe Print Utility only works with 8 bit images. I'm just guessing but there is a simplified TIF reading C utility shown in libtiff. It can read virtually any tiff format file but has the downside that it converts anything not in 8 bit to 8 bit.
My bad. Poor phrasing. It only prints images using 8 bit paths. It converts 16 bit ones to 8 bits then prints it. This is very annoying if you have a 16 bit image and are trying to print fractional RGB values. OTOH, I1Profiler converts fractionals to ints before printing or saving a tiff so it's also limited to 8 bit precision. Such is life in our little narrow color management niche.
-
Here's a scan of the 16 bit circular gradient BillsBlackBall printed w/o color management using 3 different techniques to an 8 bit driver.
Top one: This is using Photoshop. No dither selected. No color management.
Middle one: Same as above with dither selected.
Lower one: This is with ACPU.
Two images are provided showing the 3 prints. One is the B&W scans unadjusted. The second has contrast boosted very strongly using curves.
This also illustrates why you need to view the trimmed prints under a strong light w/o any nearby bright objects to see the banding visually.
Again, it's worth repeating that if one sees banding from an 8 bit driver with any normal image one enters unicorn territory.
-
The full quote was this:
Adobe Print Utility only works with 8 bit images. I'm just guessing but there is a simplified TIF reading C utility shown in libtiff. It can read virtually any tiff format file but has the downside that it converts anything not in 8 bit to 8 bit.
My bad. Poor phrasing. It only prints images using 8 bit paths. It converts 16 bit ones to 8 bits then prints it. This is very annoying if you have a 16 bit image and are trying to print fractional RGB values. OTOH, I1Profiler converts fractionals to ints before printing or saving a tiff so it's also limited to 8 bit precision. Such is life in our little narrow color management niche.
This is not how it works on a mac.
With ACPU and an Epson 3880 there is a 16 bit checkbox. One can thereby choose between an 8 bit or a 16 bit print pipeline.
With the 8 bit pipeline, your ball image prints with visible banding (subtle, but clearly visible under a bright light - no need to trim off the prints white edges). With the 16 bit pipeline the image prints smoothly.
-
I must have misunderstood this:
Adobe Print Utility only works with 8 bit images.
There is so much confusion on this thread that it is difficult to figure out what to comment on. ACPU will work with 16 bit images. I can prepare profile targets using ArgyllCMS with either 8 or 16 bit imaging but I suspect that for my Epson 3880 with the Epson driver on Win 8.1, that the final print is done using an 8 bit pipeline.
As I noted earlier in this thread, there is an ongoing discussion on the ArgyllCMS email group. Graeme Gill posted this comment yesterday which might be of interest (perhaps he will weigh in on this thread if he has time):
Yves Gauvreau wrote:
> At first, I kind of wondered if in a forensic kind of way it was
> possible to distinguish between a 8 and a 16 bit print. It seem, it
> could be a waste of time to even try. But I’ll still get myself an I1
> Studio and try my best to get the most out of my work at least color wise.
should be possible, but it depends on how much trouble you are prepared to go to. i.e., rough outline:
If you assume that the gamut of a printer roughly spans 150 delta E units, then 8 bit precision amounts to 0.6 delta E if the space was perceptually uniform. So you might aim for a measurement precision of 0.2 delta E or better, so as to be able to distinguish 0.6 delta E steps.
Say you pick a test color which you guess will be sensitive to quantization, and print and measure it 10 times, and then calculate the standard deviation as 0.9 delta E. To get a standard error of 0.2 you will need to measure and average (0.9/0.2)^2 = 20 or more samples.
So then you would print a series of test patches,
(say) 10 that span two 8 bit precision values, print and measure each 20 times (total 200 patches to print and measure on 10 sheets) and plot the average of each 20. If the graph is continuous, you can assume that the printing system has better than 8 bit resolution. If the graph has one distinct step in it, then the printing system has 8 bit resolution.
Some of the quandaries are that the space may not be very uniform, and you really want to test a color that is most likely to be quantized than not.
You also can't really be certain if a quantization step you have found is in the the input to the printing system or is generated within the printing system itself in the process of screening etc.
Cheers,
Graeme Gill.
-
It's Epson's - at least with the SC-P5000 printer. I don't know for other printers but I would assume likewise as long as the printer supports it.
For the Epson 3880 printing under WinOS with the most current driver, only 8 bit printing is supported. There is no checkbox for 16 bit printing. I cannot remember whether for THIS printer 16 bit printing is/was supported under MacOS. It may be that the current Epson printers support 16 bit printing under WinOS but I don't have one of those.
-
I cannot remember whether for THIS printer 16 bit printing is/was supported under MacOS.
Er, read my previous post.
-
For the Epson 3880 printing under WinOS with the most current driver, only 8 bit printing is supported. There is no checkbox for 16 bit printing
Why do you say that only 8-bit printing is supported? Maybe without a checkbox, 16-bit is now always selected. That certainly makes more sense. There never was any good reason to uncheck the box to begin with.
-
Er, read my previous post.
Sorry, I posted before reading your post. ;D I just checked the Epson 3880 manual and 16 bit printing is supported for MacOS but not WinOS. Here is the statement about MacOS and 16 bit printing,
If you are printing 16-bit color miages, select 16 Bit Channel for most accurate transitions and gradations.
Of course the software you are using to prepare the image must save it as a 16 bit image.
-
Why do you say that only 8-bit printing is supported. Maybe without a checkbox, 16-bit is now always selected. There never was any good reason to uncheck the box to begin with.
I think Doug Gray has demonstrated that that is not the case. His print has banding, whilst mine does not (when '16 bit' is checked).
-
Why do you say that only 8-bit printing is supported. Maybe without a checkbox, 16-bit is now always selected.
It was my understanding from some posts on LuLa several years ago when this topic was discussed and the point was made at that time that WinOS only supported 8 bit printing. As I noted in my previous post, there is no check box for 16 bit printing in the Epson driver for WinOS that I use (and it is the most current driver).
Earlier thread: https://forum.luminous-landscape.com/index.php?topic=89357.0
-
Why do you say that only 8-bit printing is supported? Maybe without a checkbox, 16-bit is now always selected. That certainly makes more sense. There never was any good reason to uncheck the box to begin with.
As I understand it, Epson's replacement for the 3880, the P800, no longer has a 16 bit checkbox on MacOS. I think with that set-up, it is valid to ask whether 16 bit is selected by default (for the reasons you state).
-
As I understand it, Epson's replacement for the 3880, the P800, no longer has a 16 bit checkbox on MacOS. I think with that set-up, it is valid to ask whether 16 bit is selected by default (for the reasons you state).
Interestingly, the P7000 initially used a driver version that dates back to Mavericks at least. When I upgraded to High Sierra about 6 months ago the first thing I did was check the Epson site for a new driver for the P7000. At that point it was still the same driver I had already installed (v9.89) and it still works very well. When Andrew mentioned a few days ago that the "P" series drivers now have no 16Bit availability I immediately checked my driver and it still has the 16Bit checkbox, which I have never used. I was about to question Andrew on that but decided to first check the Epson site again. Low and behold there was a shinny new driver for my P7000, which I downloaded but have not yet installed. I will install the new driver on a Boot-Clone drive and test it before I apply it to my Main Work Drive, a procedure I always follow when upgrading any very important app. I expect that the new driver will not include the availability of 16Bit printing, which I will not miss at all.
Gary
-
As I displayed many posts back, the SC-P5000 driver for Mac does have the 16-bit option in the Printer Settings tab. It is therefore likely that the sister models (SC-P7000/9000) also have it. But you'll see soon Gary. I have no idea about the set-up for Windows - nothing in the product manual for Printing with Windows mentions it.
-
This is not how it works on a mac.
With ACPU and an Epson 3880 there is a 16 bit checkbox. One can thereby choose between an 8 bit or a 16 bit print pipeline.
With the 8 bit pipeline, your ball image prints with visible banding (subtle, but clearly visible under a bright light - no need to trim off the prints white edges). With the 16 bit pipeline the image prints smoothly.
Good to know that it works on a Mac. Or at least that one. It indicates ACPU likely does not automatically convert 16 bits to 8 before printing and when it appears to do so the problem is elsewhere. It's likely ACPU source code is not doing it. Thanks for testing it!
-
Here something to reflect on for all of us I would assume. The quote is from (Graeme Gill)
"If you assume that the gamut of a printer roughly spans 150 delta E units, then 8 bit precision amounts to 0.6 delta E if the space was perceptually uniform. So you might aim for a measurement precision of 0.2 delta E or better, so as to be able to distinguish 0.6 delta E steps."
A true 16 bit pipeline would imply something in the order of 0.002 to 0.005 DE range which is mostly likely beyond the range of most instrument to begin with. Based on that I'll let you draw your own conclusions.
That's all for me on this subject.
YG
-
Here something to reflect on for all of us I would assume. The quote is from (Graeme Gill)
"If you assume that the gamut of a printer roughly spans 150 delta E units, then 8 bit precision amounts to 0.6 delta E if the space was perceptually uniform. So you might aim for a measurement precision of 0.2 delta E or better, so as to be able to distinguish 0.6 delta E steps."
A true 16 bit pipeline would imply something in the order of 0.002 to 0.005 DE range which is mostly likely beyond the range of most instrument to begin with. Based on that I'll let you draw your own conclusions.
That's all for me on this subject.
YG
It's very much a function of the printer's device space. Printers are typically pretty non-linear over their space and what happens is the average dE00 doesn't change much for in-gamut colors but you get some areas where the printer has 8 bit space steps that exceed 1 dE00 while the large majority are under .4 dE00. By analyzing a given printer's profile you can find the region that is most sensitive and can show banding in color areas. But those regions are small and the combination of factors required to produce visible results are such that it is likely very rare to ever encounter them even with synthetic images.
Banding seen in real life is a function of hitting gamut edges and how smoothly profiles transition requested colors at those edges where 8 bits or 16 bits is irrelevant. This is a function of the software that creates profiles and is to some degree an esthetic choice. This is the real value of images that stress printer/profile limits. It's the real value of images like Andrew Rodney's gamut test images.
-
For the Epson 3880 printing under WinOS with the most current driver, only 8 bit printing is supported. There is no checkbox for 16 bit printing. I cannot remember whether for THIS printer 16 bit printing is/was supported under MacOS. It may be that the current Epson printers support 16 bit printing under WinOS but I don't have one of those.
Correct, I'm aware of that on Windows for the 3880 but I'm wondering about the newer printer Mark is using. On my Mac, P800, the option for 16-bit is gone now. But it's available on his newer printer. I was wondering if that's the case on Windows.
-
Correct, I'm aware of that on Windows for the 3880 but I'm wondering about the newer printer Mark is using. On my Mac, P800, the option for 16-bit is gone now. But it's available on his newer printer. I was wondering if that's the case on Windows.
I checked the Windows section of the SC-P5000 Manual and there is nothing said about a 16-bit checkbox for printing with Windows, so I assume the option is not provided in the Epson 5000 driver for Windows operating systems. Nor do I understand why the option should be provided on the 5000, but not on the 800. There has to be an explanation - I just don't know what it is!
-
Yeah. Mine prints 16 bit images too. Nothing I said suggests it doesn't print 16 bit images. It just converts them to 8 bits first and produces exactly the same banding as printing BillsBlackBall in Photoshop w/o dither and no color management to my 8 bit driver.
I just did it on my Windows 10 x64.
And selecting dither fixes it.
Keep in mind this is hard to see. You have to print the Ball out, trim the white edges, and view it under a strong light - a flashlight works pretty well. But only illuminate the print. if you have anything nearby that the strong light hits it will keep your eyes from adapting.
Recall that creating an image that can actually detect 16 bit v 8 bit printer paths is not easy. In fact the bands are only .4 dE00 apart. This is why they aren't normally visible. However, if you follow the instructions to remove the white borders and look at the print under a strong light, this has the effect of multiplying the dE00 separations and makes the banding visible. This is also why to check a monitor one has to get rid of the white background and ideally use a black one.
The dE00 metric assumes one is viewing two patches, close but not touching, against a neutral L*=50 background. The relative brightness overwhelms the banding. But viewing against a black background brings it out because the eye adapts to the lower illumination and smaller dE00s become magnified and visible.
But this is with Windows and it's possible the Mac ACPU differs.
Contrary tot Lightroom, when Printing from Photoshop the spoolfiles does not double in size. So yes i Think that PS is still 8bit of was when i tested this, about a year ago.
-
For Printers:
Print with a 8 bit driver using Null-Transform or RelCol on a glossy type paper or anything with Dmax of 2 or higher. Make sure the Edit->Photoshop->Dither option is off. It's best to print this w/o using color management using the Null-Transform technique but it can be printed normally too. The banding will be more regular with the Null Transform but will occur with both. You should then trim the white borders of the print and examine the print in a bright light. The banding will be quite obvious.
I just tried this test. First, awesome and useful new testing image (Bill's black ball).
I used an Epson 3880 on Mojave where one can select a 16-bit check box in the driver. I set the driver for 2880, finest detail is off.
I made the first print with check box on, 16-bit, used my output profile (cause why would I print without it and Doug said it's OK). This is premium luster. RelCol for RI.
I see NO banding.
I converted this to 8-bits per color in PS. I immediately see banding on-screen. Note I'm using a full high bit video path and display. I see the 'banding' (concentric circles) on the print under my GTI booth.
Next I printed the 16-bit image again as in step #1, the ONLY difference is, I turned OFF the check box in the 3880 driver. I see NO banding on the print, it looks just like print #1.
Conclusion: the check box doesn't do anything. Now I could be wrong, but print #1 and #3 look the same. The only difference is if the check box is on or off and the two prints are identical.
Next I printed the 16-bit document in ACPU. No profile of course. I see NO banding. Nothing like I saw in Photoshop printing the 8-bit per color doc. It's darker of course, no profile. But no concentric circles, smooth as a baby's behind.
Conclusion: It appears to me, ACPU does print 16-bit data.
Next I printed the image in 16-bit on my P800 again using my profile, RelCol etc. There is of course no check box in this driver.
I see NO banding.
Conclusion: Lack of check box doesn't affect the output of high bit data. Just as seen above with the 3880.
Dither was OFF in Photoshop for all testing.
Now the question is, does Windows do the same, can it pass the high bit data to the driver with or without a check box, that check box appearing on this end to do nothing at all.
Doug's test image appears to provide a good way to decide IF or IF NOT high bit data is passed to the driver or, the driver is doing something with that data that can be seen on output.
-
Very useful Andrew, at least answers the outcomes for OSX; but leaves open of course why they provide the option in the one printer but not the other, and what happens on Windows.
-
Very useful Andrew, at least answers the outcomes for OSX; but leaves open of course why they provide the option in the one printer but not the other, and what happens on Windows.
This indicates to me, the 16-bit check box is a marketing created option in the driver. Of course if anyone finds a difference in their testing, I'd love to know. I didn't try 8-bit per color with the check box on, seems pointless. And it makes sense that the driver wouldn’t need the check box as unseen on the P800. Not super happy Epson has some drivers with and some without the option or that the option even exists based on what I see. Which again is why I think the check box is almost certainly a marketing generated 'feature' and nothing more. :'(
-
Next I printed the 16-bit image again as in step #1, the ONLY difference is, I turned OFF the check box in the 3880 driver. I see NO banding on the print, it looks just like print #1.
I get banding in this scenario (with 16 bit unchecked, and 'Use Dither' in Photoshop's Color Settings unchecked). If 'Use Dither' is checked, there is no banding.
-
I get banding in this scenario (with 16 bit unchecked, and 'Use Dither' in Photoshop's Color Settings unchecked). If 'Use Dither' is checked, there is no banding.
NONE of my output testing as Doug indicated, had Dither on. Dither should play no role with high bit data.
-
So it's strange that we got different results.
-
In none of my tests did I convert the document to 8 bit. I just toggled the 16 bit checkboxess in the print driver, and the 'Use Dither' checkbox in Photoshop's Color Settings.
Printing from Photoshop I got banding when 16 bit was unchecked, but only if 'Use Dither' was also unchecked.
Printing from ACPU I got banding when 16 bit was unchecked.
-
So I guess we should use "Use Dither" in its default setting of on. This doesn't sound like rocket science.
-
And why uncheck 16-bit? I mean turn it off to do the test, but check the box when you are actually printing.
-
NONE of my output testing as Doug indicated, had Dither on. Dither should play no role with high bit data.
Right. Dither plays no role in 16 bits.
-
In none of my tests did I convert the document to 8 bit. I just toggled the 16 bit checkboxess in the print driver, and the 'Use Dither' checkbox in Photoshop's Color Settings.
Well I think you should. The check box is very suspicious and doesn't live in the P800 driver or other drivers so I'd suggest you convert.
I'd also suggest you utterly ignore the Dither options unless we hope to only discuss Photoshop. What other products provide such an option? Not Lightroom (which needs testing), among many others. Lastly, as Adobe clearly shows in the Color Settings, Dither should only affect 8-bit per color data. IF it affects 16-bit data, it's a bug.
-
And why uncheck 16-bit? I mean turn it off to do the test, but check the box when you are actually printing.
If you're asking me, I turned it off WITH 16-bit data to see if it did anything with actual 16-bit data. It did absolutely nothing. It's not an option on my other printer and appears to be unnecessary; 16-bit data printed as expected with no such option.
-
So checked or unchecked?
-
So checked or unchecked?
Checked or uncheck WHAT?
-
16-bit.
-
Well I think you should.
It didn't strike me as being relevant. I'm only interested in the effect of the print drivers' 16 bit checkboxes (there are two) on the printing of a 16 bit file.
The check box is very suspicious and doesn't live in the P800 driver or other drivers so I'd suggest you convert.
I don't think it's suspicious. It does what it says it does.
I'd also suggest you utterly ignore the Dither options unless we hope to only discuss Photoshop.
The 'Use Dither' setting is an integral part of the equation.
What other products provide such an option? Not Lightroom (which needs testing), among many others.
I'm only interested in Photoshop.
Lastly, as Adobe clearly shows in the Color Settings, Dither should only affect 8-bit per color data. IF it affects 16-bit data, it's a bug.
You're correct to the extent that if the entire pipeline is 16 bit, Dither won't be invoked. However, if you uncheck '16 bit' in the print driver, then the 16 bit file is converted to 8bit, and Dither is important in this conversion process.
-
It didn't strike me as being relevant. I'm only interested in the effect of the print drivers' 16 bit checkboxes (there are two) on the printing of a 16 bit file.
It didn't do a damn thing on this end. ON, or OFF, with 16-bit data, I get the SAME results. I also get the same results in the P800 which has NO such options.
You think that if you take 16-bit data and turn the check box off, something converts it to 8-bits per color? That's absolutely not what I see testing with a 3880 on this end. And why assume it does? Convert the data to 8 bits per color THEN make a print. There's zero question it's 8 bits per color now. I see the difference too, on screen which I reported for those who read what I reported.
I don't think it's suspicious. It does what it says it does.
What do you think it does? Why do I see zero difference if it's on or off?
The 'Use Dither' setting is an integral part of the equation.
What equation would that be? Considering there are many, many applications for printing that have no such options, why would it be at all pertinent? And you don't seem to believe either Doug or I or Adobe who clearly show that dither in Photoshop alone is for 8-bit per color data, NOT 16-bit data.
I'm only interested in Photoshop.
Terrific, you're not the only one here and the only one printing solely in Photoshop, that's WHY ACPU was discussed.
You're correct to the extent that if the entire pipeline is 16 bit, Dither won't be invoked.
I know. ::)
However, if you uncheck '16 bit' in the print driver, then the 16 bit file is converted to 8bit, and Dither is important in this conversion process.
ONLY if you assume turning it off produces 8-bits per color with just that setting which doesn't jive with what my prints show. Or that many applications have no such option for Dither. Or that if you're printing 16-bit, as the OP who left asked about, Dither does absolutely nothing.
-
16-bit.
See my last post.
-
I'm only interested in the effect of the print drivers' 16 bit checkboxes (there are two) on the printing of a 16 bit file.
Two, where? What print driver? I see simply one on my 3880n driver.
-
It very well could be that the 16 bit check box was an Easter Egg gone wrong.
-
Andrew, we've done the same test and got different results. I will redo my tests to double check. I don't think anything I am saying contradicts what Doug has already said.
-
Andrew, we've done the same test and got different results. I will redo my tests to double check. I don't think anything I am saying contradicts what Doug has already said.
Back up, you say you see TWO check boxes. I see ONE. I don't recall what printer you're using. So please indicate what printer and where you see two 16-bit check boxes. With the ONE I see for my 3880, toggling it on or off makes no difference in the print when the data is indeed 16-bit. We may be getting differing results from differing drivers but until I know what you're doing and where, I can't comment further.
-
Epson 3880. OSX (High Sierra). Photoshop CS6.
Two 16 bit checkboxes:
-
When I created Bills Black Ball, I first ran a dE00 on 1 bit changes from 0 to 255 in ProPhoto and selected the dark range that also had the largest dE00 for each bit increase. I used ProPhoto RGB because it has a 1.8 gamma which is a somewhat better match for the many different printer profiles I've examined.
However, I've been looking at the math and perceptual sensitivity v step size area and I should be able to produce an image that brings out the 8bit/16bit difference even better on prints. I'm also looking at doing an optimal version specifically for monitors to make it easier to test whether people's 30 bit system is really performing or has, without warning, reverted to 24 bits.
-
Epson 3880. OSX (High Sierra). Photoshop CS6.
Two 16 bit checkboxes:
One is the PS dialogue box and the other is the Epson driver box. Different boxes for different purposes.
-
One is the PS dialogue box and the other is the Epson driver box. Different boxes for different purposes.
Yes, you're right. I misunderstood the functions of those two dialog boxes.
Sorry, Andrew, your results now make sense to me.
However, it seems that there is one test you didn't do - printing the 16 bit file through ACPU with 16 bit unchecked. When I do this, I get banding in the print. This seems to contradict your conclusion that 'the check box doesn't do anything' (?)
-
Epson 3880. OSX (High Sierra). Photoshop CS6.
Two 16 bit checkboxes:
Ah, the very old' CS6; no wonder; I'm on CC2019.
Only one of those is in the print driver. The other is Photoshop itself. I didn't mess with the Photoshop area whatsoever.
-
However, it seems that there is one test you didn't do - printing the 16 bit file through ACPU with 16 bit unchecked.
I don't see the point. I was interested in seeing IF ACPU did pass the 16-bit data or not, seems it did.
-
Next I printed the 16-bit document in ACPU. No profile of course. I see NO banding.
Decided this wasn't as clean a test as possible. The other tests, Doug's image was converted to the output color space through PS. Now while we'd not do this with ACPU, figured I'd give that a shot.
Converted to my custom profile (RelCol) in Photoshop using Convert to Profile. Again, Dither is off but shouldn't make any difference.
Opened the converted copy above in ACPU. For fun, I actually kept the 16-bit check box OFF in my Epson 3880 driver. The print isn't as dark this time because it was converted like the others.
Smooth as a baby's back end again. Like the others printed through Photoshop.
Conclusion: ACPU accepts 16-bit data and uses it. Further, the check box for 16-bit in the Epson print dialog doesn't do squat.
-
I repeated my tests.
I am seeing banding, admittedly subtle, when the image is printed with 16 bit unchecked in the Epson print driver*. There is no banding when 16 bit is checked.
I see this when printing from Photoshop, and also when printing from ACPU.
----------------
* When printing from Photoshop, I have 'Send 16-bit Data' checkbox in the Photoshop print dialog checked. I am toggling the '16 Bit Output' checkbox in the Epson print driver.
-
I repeated my tests.
I am seeing banding, admittedly subtle, when the image is printed with 16 bit unchecked in the Epson print driver*. There is no banding when 16 bit is checked.
I see this when printing from Photoshop, and also when printing from ACPU.
----------------
* When printing from Photoshop, I have 'Send 16-bit Data' checkbox in the Photoshop print dialog checked. I am toggling the '16 Bit Output' checkbox in the Epson print driver.
I would trust my eyes. Let Andrew make whatever decision he wants for his own work.
-
The banding I'm seeing is very subtle. It is significantly less than the banding visible when the image is printed after being converted in Photoshop to 8 bit (with no dither). But it does indicate that the 16 bit checkbox in the Epson print dialog is not merely cosmetic - it does do something, and it should remain checked.
-
The banding I'm seeing is very subtle. It is significantly less than the banding visible when the image is printed after being converted in Photoshop to 8 bit (with no dither). But it does indicate that the 16 bit checkbox in the Epson print dialog is not merely cosmetic - it does do something, and it should remain checked.
Glad you reported this as something now is going on that is VERY odd.
I took a profile target with 918 patches hoping to make a print with check box on and off, nothing more, so I could measure and produce a colorimetric report. I printed the targets three times and I keep seeing this which is rather alarming.
Before I paste the report, again, this is 918 patches of differing colors I can measure on my iSis. I printed it 'untagged' (the assumption would then be ProPhoto RGB) but also assigned sRGB to the target. The original wasn't in 16-bit so I converted it as such. That alone shouldn’t be an issue. Again, everything is identical between the two prints going off to the Epson 3880 expect the check box for 16-bit is either ON or OFF in the driver. This is the difference which is huge:
Number of Samples: 918
Delta-E Formula dE2000
Overall - (918 colors)
--------------------------------------------------
Average dE: 11.16
Max dE: 42.30
Min dE: 0.21
StdDev dE: 7.14
95th %ile dE: 15.22
Best 90% - (825 colors)
--------------------------------------------------
Average dE: 9.33
Max dE: 20.13
Min dE: 0.21
StdDev dE: 4.47
Worst 10% - (93 colors)
--------------------------------------------------
Average dE: 27.40
Max dE: 42.30
Min dE: 20.13
StdDev dE: 5.73
--------------------------------------------------
Doug, I believe you have a printer from Epson with this option and I know you too can print and measure as I did. I need a major reality check here. The max dE (42) and the most egregious differences are in green. But even the average is alarming and I don't know if this might be a bug with Mojave, the driver, but it's very strange.
And now that I examine the two prints I made today, using Doug's construct, I do notice the gray balance is a bit different visually. With lots of colors, it's all over the map. The targets were 'wet', right out of the printer so the dE's would be a tad lower tomorrow but nothing is going to get the two close to where they should be.
I suppose I should also try the same test but use my Gamut Test File image which is natively 16bit and print one each with (check box off and on), the difference in colors should be visible. If anyone with a 3880 can test this, it would help. I suppose it could be the driver acting up with the new OS as I can't believe the check box would make such a huge difference. I can see the differences of the color patches, there was little need to measure them but none the less, we can see the huge colorimetric differences. So anyone with this printer on Mac running Mojave can test this without the need of a Spectrophotometer. Look at greens. The lowest dE is a middle gray (0.21). So the black ball is in an area of color space (neutrals so to speak) where the color differences are the least. The driver I'm using for the Mac is 9.33, I can't find anything newer.
Odd, very very odd!
-
Wow!
Those are the results I'd expect with some sort of differing color management or conversion taking place. I have no idea what's going on but that sort of thing will produce very visible difference on most any image.
What app are you using to print and how does it assume ProPhoto? Are you printing the chart in Photoshop?
In any case I can't duplicate it here - Epson's a 9800 and 8 bits only - and I've never seen anything like that on the Canon. But I'm also on Win 10 x64 which is a different beast.
Since you have an iSis, I've attached a 16 bit image file tagged in Adobe RGB formatted to be a CC and readable by iSis with the default 957 letter size. Also attached the CGATs file you can load as a patch set which makes the iSis measurement readings happy. The RGB values are also high bit Adobe RGB.
Print it in Photoshop using Absolute Colorimetric and try switching 8/16.
-
I'm curious what printer you are using. Is there an advantage to printing 8-bit?
I didn’t get through the whole thread yet, but in regards to this specific question the only thought I would have is if you are trying to print a very large print in 16 bit, I’ve seen circumstances where it has choked the printer pipeline. I can’t explain it because I always thought the data going to the printer was streamed so all I can think of is somehow the spool file or whatever is being created becomes unmanageable. I always print from LR on a Mac to an epson 44” wide printer (currently p9000) using the 16bit option, but on prints that are longer than about 80” and 30” wide I have had occasions where the printer appears to be printing but lays down no ink, where it just sits there and never prints and the spool file just disappears, and sometimes it starts printing a repeated pattern of a small part of the image continuously.
At this point I use 8 bit for images over about 70” long.
For some file size would also be an issue. I do not make intermediate files and print through photoshop, I print from the original master file and let LR handle the resizing and output sharpening. But those that make files to specific output sizes before printing, 8 bit files are smaller.
-
Here are my latest test results. These are photographs of prints (I tried using my flatbed scanner, but I discovered that there's lots of distracting gunk on the underside of the glass).
AFAIK, I am printing with the same settings as Andrew, but, unlike him, I am seeing (subtle) banding when 16 bit is not selected in the Epson driver.
First I will post 'straight' photographs. These are not very revealing, but they show what the prints actually look like.
Next I will post 'enhanced' photographs (Blacks -100, Whites +100, in ACR). These reveal the banding. This banding can be seen by the naked eye (I wouldn't have bothered photographing the prints if I had seen no banding). The banding is subtle.
Here are the straight photographs.
(1) Epson driver, 16 bit vs 8 bit, from Photoshop
(2) Epson driver, 16 bit vs 8 bit from ACPU
(3) Converting the 16 bit file to 8 bit in Photoshop, without Dither vs with Dither
-
And here are the same images, enhanced in ACR to reveal banding:
-
See my last post.
I read your post saying you can't see a difference. I am asking you whether you check the 16-bit box when you normally print or whether you leave it unchecked. You do one or the other.
-
I am not a colour geek, just a regular photographer who has fallen down the rabbit-hole opened up by the OP :)
I'm very happy for anyone to challenge my methodology.
Earlier in this thread I was confused by what I regarded as TWO 16 bit checkboxes in the print pipeline. I think I now have a better understanding of the different functions of these checkboxes. In my most recent tests (the ones I've just posted), the 'Send 16 bit Data' in the Photoshop print dialog is always checked (except for the third print, which is an 8 bit image, and hence the checkbox is greyed out). So in the first two prints, I am toggling the '16 Bit Output' checkbox in 'Print Setting' in the Epson print driver.
If you send a 16 bit file to print, and don't check 'Send 16 bit Data' in the Photoshop print dialog, then Photoshop will make an on-the-fly conversion of the 16 bit file to 8 bit. If you don't have Dither turned on in Photoshop's Color Settings, then banding will appear in your file.
-
Based on my tests, '16 Bit Output' in the Epson print driver should always be checked. Likewise, 'Use Dither' in Photoshop's Colour Settings.
-
Doug, I’m printing from Photoshop CC 2019 just released this week. I’ll try you target later thanks. Something is obviously very wrong and I need to nail down if this yet another Epson/Adobe print bug.
-
Doug, I’m printing from Photoshop CC 2019 just released this week. I’ll try you target later thanks. Something is obviously very wrong and I need to nail down if this yet another Epson/Adobe print bug.
For an experienced professional such as yourself to be getting those huge dE errors is indeed very troubling and a prominent indication that something else is amiss besides this 16-bit business. I'm staying tuned to see what you come up with, as this finding is more important than much else on this thread. If you have the time and software available there to do so without inordinate inconvenience, it may be useful to perform the identical tests using the previous and the current versions of Photoshop CC. That should nail the question about whether the update is problematic. I can't do this, because I'm still on El Capitan so I can't use the latest PS version, nor am I planning to upgrade my OS just yet.
-
For an experienced professional such as yourself to be getting those huge dE errors is indeed very troubling and a prominent indication that something else is amiss besides this 16-bit business. I'm staying tuned to see what you come up with, as this finding is more important than much else on this thread. If you have the time and software available there to do so without inordinate inconvenience, it may be useful to perform the identical tests using the previous and the current versions of Photoshop CC. That should nail the question about whether the update is problematic. I can't do this, because I'm still on El Capitan so I can't use the latest PS version, nor am I planning to upgrade my OS just yet.
Couldn't agree more. On the positive side, unlike some of the past bugs, this one should get addressed pretty fast. Nothing subtle about it. Unless it only shows up with some unusual combo of hardware/software/settings.
-
Couldn't agree more. On the positive side, unlike some of the past bugs, this one should get addressed pretty fast. Nothing subtle about it. Unless it only shows up with some unusual combo of hardware/software/settings.
I decided to print your target in ACPU to first eliminate Photoshop as a factor. No need to measure them, I can see very clearly there's a massive difference in color with the print driver 16-bit check box on or off. So it appears to be a bug in the 3880 Epson driver. However, I do need to measure them to provide data as to which is 'correct'. Going out on a limb, I'd say OFF is wrong. I suppose I need to see if an 8-bit per color doc does the same. But I think I need to ping my boys at Epson USA and see if this is something they are aware of and care.... Could be due to Mojave, that would be my next test but if someone here has a 3880 on Mac OS, but useful for a reality check for me if they can make a print of Doug's target or for that matter anything colorful with a 16-bit doc and just toggle the 16-bit check box in print driver on and off. If they match, it points to the new OS. If not, more work ahead.
-
Here's a photograph of two prints of Doug's ColorChecker. ACPU. 16 bit on the left, 8 bit on the right.
Epson 3880. Epson Driver 9.33. High Sierra.
I can't see any big differences.
-
I decided to print your target in ACPU to first eliminate Photoshop as a factor. No need to measure them, I can see very clearly there's a massive difference in color with the print driver 16-bit check box on or off. So it appears to be a bug in the 3880 Epson driver. However, I do need to measure them to provide data as to which is 'correct'. Going out on a limb, I'd say OFF is wrong. I suppose I need to see if an 8-bit per color doc does the same. But I think I need to ping my boys at Epson USA and see if this is something they are aware of and care.... Could be due to Mojave, that would be my next test but if someone here has a 3880 on Mac OS, but useful for a reality check for me if they can make a print of Doug's target or for that matter anything colorful with a 16-bit doc and just toggle the 16-bit check box in print driver on and off. If they match, it points to the new OS. If not, more work ahead.
Makes sense. Man, that's a serious bug!
Did you first convert in Photoshop to device space Abs before printing with ACPU? That way one will look exactly like a colorchecker and the other one won't which makes it easier to communicate, visually if necessary, the bug to Epson.
-
I decided to print your target in ACPU to first eliminate Photoshop as a factor. No need to measure them, I can see very clearly there's a massive difference in color with the print driver 16-bit check box on or off. So it appears to be a bug in the 3880 Epson driver. However, I do need to measure them to provide data as to which is 'correct'.
I am confused. I thought a couple of days ago you said there was no difference when checking the 16-bit box or not, and that the checkbox was purely a marketing ploy perpetrated by Epson. Are you saying with the new release, the checkbox is no longer a marketing ploy, but has been implemented and implemented wrong?
-
Here's a photograph of two prints of Doug's ColorChecker. ACPU. 16 bit on the left, 8 bit on the right.
Epson 3880. Epson Driver 9.33. High Sierra.
I can't see any big differences.
Thanks that’s really useful information. I’ve contacted Epson and have heard back, they suspect it’s a Majove bug and are checking on if there’s a newer version. Stay tuned.
-
Here are flatbed scans of those two prints. The colours are the same.
(I just took Doug's tiff and printed it in ACPU - no colorspace conversion, as per his last post.)
-
I am confused.
Understandable.
I thought a couple of days ago you said there was no difference when checking the 16-bit box or not, and that the checkbox was purely a marketing ploy perpetrated by Epson. Are you saying with the new release, the checkbox is no longer a marketing ploy, but has been implemented and implemented wrong?
Do you understand what a deltaE difference is before I explain further?
-
Do you understand what a deltaE difference is before I explain further?
Thesse were the quotes I was inquiring about:
This indicates to me, the 16-bit check box is a marketing created option in the driver. Of course if anyone finds a difference in their testing, I'd love to know. I didn't try 8-bit per color with the check box on, seems pointless. And it makes sense that the driver wouldn’t need the check box as unseen on the P800. Not super happy Epson has some drivers with and some without the option or that the option even exists based on what I see. Which again is why I think the check box is almost certainly a marketing generated 'feature' and nothing more. :'(
It didn't do a damn thing on this end. ON, or OFF, with 16-bit data, I get the SAME results. I also get the same results in the P800 which has NO such options.
You think that if you take 16-bit data and turn the check box off, something converts it to 8-bits per color? That's absolutely not what I see testing with a 3880 on this end. And why assume it does? Convert the data to 8 bits per color THEN make a print. There's zero question it's 8 bits per color now. I see the difference too, on screen which I reported for those who read what I reported.
If you're asking me, I turned it off WITH 16-bit data to see if it did anything with actual 16-bit data. It did absolutely nothing. It's not an option on my other printer and appears to be unnecessary; 16-bit data printed as expected with no such option.
-
Thesse were the quotes I was inquiring about:
Do you understand how Doug's target was created and what it doesn't show? Hence the question you didn't answer about deltaE.
So, in honor of Bill Atkinson, I have created an image I call Bills Black Ball. The reason that Bill's set of color gradient balls were created was because Bill felt that banding was easier to see in circles rather than linear gradients.
The attached tiff image, in ProPhoto RGB, has RGB values ranging from RGB(20,20,20) to RGB(35,35,35) at the outer edges. It is quite suitable for demonstrating 8 bit or higher paths for both monitors and printers.
It was a great target to examine banding, it's not at all good, nor designed to show visually or numerically anything about RGB values outside of 20/20/20 to 35/35/35/. The test I provided yesterday used colors all over color space. And thanks to 3-4 people here (Doug, Mark, Elliot), after viewing Doug's work, a bug in the driver for what appears to be only Mojave, released September 24, 2018 (not that I upgraded on that day, I did not) was found.
Nothing therefore tested solely with Doug's target over the last day on my end, on Mojave can now be accepted although in terms of banding, I still see no differences ON DOUGs Target in terms of banding!
RGB 23/23/23 THEN run through my output profile and measured show a dE 2000 of 2. Do you or do you not understand what that metric indicates in terms of the difference between the 16-bit check box being on or off for that one target? IF SO, you'll see that prior to the bug found, my statement that I see no difference, prior to 24 hour dry down was that there was NO visual difference with either on or off.
You asked repeatedly about should the check box be on or off. IF THER IS NO BUG, it would and should make no difference with 16-bit data hence. It's ALWAYS on for me and probably why, I didn't see any issues with the output from Mojave in the few weeks it's been installed on this Mac. Until this set of posts which if anything, shows that there's a nastily bug under Mojave for the 3880 yet NOT for my other printer that gets more use; my P800. No check box, no bug.
In terms of the results of my testing, WITH A DRIVER bug, I stand by everything I wrote. But now some of us know, the analysis is based on a buggy driver.
Now, once I finally get a driver that supports the check box toggling without a bug, I'll revisit Doug's target again.
-
For anyone wishing to use the image for other purposes, it is in Adobe RGB (1998). The CC's LAB values, were from measurements on a 3 y/o ColorChecker with an I1 Pro2 so there will be small differences from the CC images at places like BabelColor.
Also, there is a useful neutral gradient I attached to the side. It runs from white to black then back again. The steps are highly precise with the L* stepping from 1 to 99 then back to 1 in increments of 1. It's a good check on the ability of a printer to print good neutrals. For those with an iSis, if you save a measurement file in CGATs, the Lab readings of the last 198 entries (out of 957 total) will show the measured LAB values in sequence. Color vision is quite sensitive to small chroma and hue shifts on the neutrals so I often use this part of the image to check a printer profile.
-
Understandable.
Do you understand what a deltaE difference is before I explain further?
Yes, and that the deltaE differences you are seeing are clearly visible.
-
Yes, and that the deltaE differences you are seeing are large.
No, not with Doug's target.
-
The bug is invoked with the check box ON not off. Just printed my Printer Test File both ways. With it ON, it almost looks like the output profile wasn't used (dark, very ugly).
I converted this test file to 8-bit per color, but had the check box ON (which seems pointless and counter intuitive). Wanted to see if the bit depth was an issue or just the check box. Output was wrong. So it doesn't matter the document bit depth, it's the check box under Mojave that's the bug.
-
No, not with Doug's target.
I was referring to the differences you report in post 206.
-
I was referring to the differences you report in post 205.
And I was referring to your questions in post #224:
Thesse were the quotes I was inquiring about:
-
The bug is invoked with the check box ON not off. Just printed my Printer Test File both ways. With it ON, it almost looks like the output profile wasn't used (dark, very ugly).
I converted this test file to 8-bit per color, but had the check box ON (which seems pointless and counter intuitive). Wanted to see if the bit depth was an issue or just the check box. Output was wrong. So it doesn't matter the document bit depth, it's the check box under Mojave that's the bug.
I suppose this applies to the 3880 (by now a deprecated model) and not the P800, because you were saying said option doesn't exist in the P800 driver. Nonetheless I'm sure many people are still happily using their 3880s, so it should be fixed. Now who owns this problem: Adobe, Apple or Epson?
-
I suppose this applies to the 3880 (by now a deprecated model) and not the P800, because you were saying said option doesn't exist in the P800 driver. Nonetheless I'm sure many people are still happily using their 3880s, so it should be fixed. Now who owns this problem: Adobe, Apple or Epson?
P800 is fine. And there was a new driver for it that I installed after Mojave. Epson owns the problem IMHO thus far. I'm still waiting to hear back if there's a newer driver but their web site still shows this:
-
I suppose this applies to the 3880 (by now a deprecated model) and not the P800, because you were saying said option doesn't exist in the P800 driver. Nonetheless I'm sure many people are still happily using their 3880s, so it should be fixed. Now who owns this problem: Adobe, Apple or Epson?
I wonder whether Apple give hardware manufacturers enough lead time to test everything. Of course the 3880 is an old model but it's Epson's fault for making it such a rock steady printer that hardly ever (never in my experience) clogs. With all the installed Epson printers, it would be a tedious job to check every driver and setting. I've not looked at the manufacturing specifications for the P800 but in the absence of the checkbox, does it print 16 bit?
-
I wonder whether Apple give hardware manufacturers enough lead time to test everything.
Considering how they allow the public to test beta's of the OS, I'd have to believe the answer is they do.
Yes, it appears the P800 simply passes the bit depth in the document through the driver, based on the results I see on mine with Doug's test file. And that's HOW it should be. The check box is dumb and unnecessarily even when no bug exists. It's an extra and unnecessary item in the GUI and again, I think it's more for marketing than anything else (I'm sticking by my original opinion). You have 16-bit data, send to the printer and it should use it. Have 8-bit per color data, ditto. Have 16-bit but a HUGE file that's going to slow you down or make the driver (?) barf, convert to 8-bits per color.
What we have now is multiple Epson's with and without the check box. That's just confusing even without one driver producing a bug that affects the output.
-
I wonder whether Apple give hardware manufacturers enough lead time to test everything. Of course the 3880 is an old model but it's Epson's fault for making it such a rock steady printer that hardly ever (never in my experience) clogs. With all the installed Epson printers, it would be a tedious job to check every driver and setting. I've not looked at the manufacturing specifications for the P800 but in the absence of the checkbox, does it print 16 bit?
I second Andrew's comments. My understanding from talking with various developers is that Apple gives them at least six months advance notice to come into compliance with OS upgrades before they issue them.
As for 16-bit printing in a P800 - inconceivable that it wouldn't.
As for why that 16-bit checkbox even exists for some driver versions and not others, I think one would have to ask Epson and hope they would tell. I'm not convinced it's marketing. This is too obscure an item on which to hang one's marketing hat. It's of immediate appeal to a small crew of techno-literati, but hardly to the larger constituency forming the prosumer market for these 17" printer models. They are much better off touting brilliance of colour, fine detail reproduction, media handling features and that kind of stuff. I think the explanation is more innocent - somewhere in the minds of some engineers there is a rationale that impressed management enough to include this "feature". So those minds need to be tweaked to find out what's the charm! :-) I suspect I may have an idea of this answer. They may well say that 16-bit is the default which should remain checked for all 16-bit image files; however, just in case you need to send a smaller amount of data through the print pipeline, you have the option to revert to 8-bit by turning it off, and the driver dumbs down the file - just in passing for that one print - from 16 to 8. Other than that, I think Andrew's explanation of how it should work is the most generally sensible.
-
I second Andrew's comments. My understanding from talking with various developers is that Apple gives them at least six months advance notice to come into compliance with OS upgrades before they issue them.
That's appropriate but what if Apple makes a last minute change to some part of the new OS which breaks the work the developer has done. This is not unheard of and we are seeing the same thing now with Windows 10 which MSFT is treating just like IOS updates as they do not plan to issue a 'new' Windows product. I've avoided all that because I'm staying on Win 8.1 until support runs out or some needed app no longer runs.
As for 16-bit printing in a P800 - inconceivable that it wouldn't.
As for why that 16-bit checkbox even exists for some driver versions and not others, I think one would have to ask Epson and hope they would tell. I'm not convinced it's marketing. This is too obscure an item on which to hang one's marketing hat. It's of immediate appeal to a small crew of techno-literati, but hardly to the larger constituency forming the prosumer market for these 17" printer models. They are much better off touting brilliance of colour, fine detail reproduction, media handling features and that kind of stuff. I think the explanation is more innocent - somewhere in the minds of some engineers there is a rationale that impressed management enough to include this "feature". So those minds need to be tweaked to find out what's the charm! :-) I suspect I may have an idea of this answer. They may well say that 16-bit is the default which should remain checked for all 16-bit image files; however, just in case you need to send a smaller amount of data through the print pipeline, you have the option to revert to 8-bit by turning it off, and the driver dumbs down the file - just in passing for that one print - from 16 to 8. Other than that, I think Andrew's explanation of how it should work is the most generally sensible.
I agree with both you and Andrew. I've not had to deal with this as my 3880 runs under WinOS and hence the only option is for 8 bit printing. Epson engineers may have figured out how to have the driver detect 8 or 16 bit files and for the newer printers the checkbox is not needed. If you have MacOS do you still have to check the 16 bit output box in LR or is that a thing of the past (just asking for informational purposes).
-
That's appropriate but what if Apple makes a last minute change to some part of the new OS which breaks the work the developer has done. This is not unheard of and we are seeing the same thing now with Windows 10 which MSFT is treating just like IOS updates as they do not plan to issue a 'new' Windows product. I've avoided all that because I'm staying on Win 8.1 until support runs out or some needed app no longer runs.
I agree with both you and Andrew. I've not had to deal with this as my 3880 runs under WinOS and hence the only option is for 8 bit printing. Epson engineers may have figured out how to have the driver detect 8 or 16 bit files and for the newer printers the checkbox is not needed. If you have MacOS do you still have to check the 16 bit output box in LR or is that a thing of the past (just asking for informational purposes).
The P5000 is a newer, more expensive model than P800 and its driver does provide that checkbox. And yes, Lr for OSX does provide a 16-bit option checkbox in the Print module.
-
The P5000 is a newer, more expensive model than P800 and its driver does provide that checkbox. And yes, Lr for OSX does provide a 16-bit option checkbox in the Print module.
Thanks. I've done some research about WinOS printing and it looks as though MSFT provided 16 bit print capability back when Vista was developed well over ten years ago now. The specification is XPS and drivers need to be compliant with that. It looks like only Canon has done this but the problem as I've read is that Adobe has not put the feature in LR to do this with WinOS (and I assume PS as well). It's interesting that the ability to do 16 bit printing in WinOS has been around for so long and never implemented until recently and only by on manufacturer. Some RIPs can do 16 bit printing in WinOS. Curious situation.
-
Indeed, that is curious. One wonders why. Roughly half the graphic arts market these days uses Windows from what I've heard.
-
Indeed, that is curious. One wonders why. Roughly half the graphic arts market these days uses Windows from what I've heard.
Perhaps the driver emulation is complicated and printer manufacturers decided that 8 bits was enough for 'most' everyone. I'm surprised that Epson have not provided 16 bit drivers for their new line of printers but of course LR would have to allow 16 bit delivery to the printer under WinOS as well.
-
Fortunately, I am going to dodge the bullet. I am running High Sierra on my mid-2011 machine and so am not able to upgrade to Mojave, but I am able to upgrade to LR8/PS20.
-
Perhaps the driver emulation is complicated and printer manufacturers decided that 8 bits was enough for 'most' everyone. I'm surprised that Epson have not provided 16 bit drivers for their new line of printers but of course LR would have to allow 16 bit delivery to the printer under WinOS as well.
LR appears to do so on the Mac, according to the output I just tried using Doug's target. Smooth as it should be. This again begs the question why a check box for 16-bit isn't necessary for the P800 but appears on others.
Like Photoshop, there's a 16-bit check box in LR. Is there one under the Windows version?
-
Perhaps the driver emulation is complicated and printer manufacturers decided that 8 bits was enough for 'most' everyone. I'm surprised that Epson have not provided 16 bit drivers for their new line of printers but of course LR would have to allow 16 bit delivery to the printer under WinOS as well.
But Epson has provided the 16-bit option for the newest printer of the SureColorPro line, which is the SC-P5000, which I have and operate. It is accessible in the driver for OSX. Whether it is accessible for the Windows driver I can only surmise from checking the Manual. In the Manual for the P5000, in <Printing with Mac> they show a screen grab of the Printer Settings tab that includes the 16-bit checkbox, without explaining it in any text (great manual); in <Printing with Windows> none of the screen grabs show the existence of a 16-bit checkbox anywhere. So I have to conclude they do provide 16-bit drivers if the operating system accommodates 16-bit data in the print pipeline.
-
LR appears to do so on the Mac, according to the output I just tried using Doug's target. Smooth as it should be. This again begs the question why a check box for 16-bit isn't necessary for the P800 but appears on others.
Like Photoshop, there's a 16-bit check box in LR. Is there one under the Windows version?
I think I provided one plausible explanation why the SC-P5000 has it - it's an option provided so that if you want to send only 8-bit data you can uncheck it (for whatever reason). If that's true it begs the question why this option is offered on the SC-P5000 but not the P800. The only answer I can think of is that at twice the price, they have to pack in more bells and whistles to make it seem worthwhile, on top of the more obvious things - the G & O inks, twice the printhead nozzle density, larger tanks, more robust build quality, built-in automatic roll holder, etc.
-
I think I provided one plausible explanation why the SC-P5000 has it - it's an option provided so that if you want to send only 8-bit data you can uncheck it (for whatever reason).
But can you think of ANY reason?
-
Less data to handle?
As I said, one would need to get into the heads of the engineers designing this stuff to know for sure.
-
LR appears to do so on the Mac, according to the output I just tried using Doug's target. Smooth as it should be. This again begs the question why a check box for 16-bit isn't necessary for the P800 but appears on others.
Like Photoshop, there's a 16-bit check box in LR. Is there one under the Windows version?
Now on this again, never occurred to me to verify because I just leave the highest quality options selected and perpetually active everywhere they exist, but in Lr, there are TWO places for selecting 16 bit (see attached screen grab), the first being in the Lr Print interface, the second in the Epson driver accessed through Lr (OSX). Why both?
-
Less data to handle?
That might be useful if the 8 bit pipeline was quicker than the 16 bit pipeline. But it isn't.
-
Now on this again, never occurred to me to verify because I just leave the highest quality options selected and perpetually active everywhere they exist, but in Lr, there are TWO places for selecting 16 bit (see attached screen grab), the first being in the Lr Print interface, the second in the Epson driver accessed through Lr (OSX). Why both?
Why both in Photoshop?
-
That might be useful if the 8 bit pipeline was quicker than the 16 bit pipeline. But it isn't.
Maybe there was a time that certain systems weren't capable of managing 16-bit data, I don't really know. As I said, one would need to get the insight of the engineers who put it there as an option.
-
Why both in Photoshop?
Probably the same reason, but what is it? :-)
-
Now on this again, never occurred to me to verify because I just leave the highest quality options selected and perpetually active everywhere they exist, but in Lr, there are TWO places for selecting 16 bit (see attached screen grab), the first being in the Lr Print interface, the second in the Epson driver accessed through Lr (OSX). Why both?
1) In LR (or PS) you choose whether to deliver 16 bit data to the print driver
2) In the print driver you then choose whether to send that data down the 8 bit or 16 bit pipeline.
-
And neither setting makes much of a difference :)
-
Probably the same reason, but what is it? :-)
I don’t know but I appreciate the consistency among these Adobe software products. I can ping Dave P at Adobe.
-
I don’t know but I appreciate the consistency among these Adobe software products. I can ping Dave P at Adobe.
Good idea.
-
1) In LR (or PS) you choose whether to deliver 16 bit data to the print driver
2) In the print driver you then choose whether to send that data down the 8 bit or 16 bit pipeline.
Yes, but that still begs the question of why you need two commands to achieve the same ultimate objective, and then having the duplication, which prevails if they were set differently.
-
I'm not sure if the objective is exactly the same. It's puzzling.
Printing from Photoshop, the first box is called 'Send 16-bit Data' and the second (in the Epson driver) is called '16 Bit Output'.
If you uncheck the first box, then Photoshop makes the conversion from 16 bit to 8 bit (with or without dither, depending on your Color Settings).
If, instead, you uncheck the second box, then the Epson driver deals with the 16 bit data, presumably making its own conversion to 8 bit. From my tests this conversion is different from both of Photoshop's conversions (dither on, dither off).
-
This is useful?
https://helpx.adobe.com/lightroom/help/print-job-options-settings.html
-
Partially useful - there's no discussion about its relationship with the 16-bit option in the Epson driver for some printers and doesn't indicate anything about inconsistent settings between the application and driver. Another example of these guys needing to get their act together.
-
1) In LR (or PS) you choose whether to deliver 16 bit data to the print driver
2) In the print driver you then choose whether to send that data down the 8 bit or 16 bit pipeline.
Possibly. But are you sure LR and PS aren’t just putting these settings there so it can pass them on to the driver? I just can’t imagine anyone having a need to send 16bit data to the printer but then have the printer send it down the pipeline in 8 bit. If it’s nearly impossible to see the difference between a print using 8bit vs 16bit in both checkboxes, I just don’t see how there would be any visual difference? And it seems most would rather trust LR and PS to make the conversion because that’s what we do with profiles, so whatever we set in those programs should be what’s sent to and set in the driver by default.
to me its not necessarily puzzling it’s in both places, because one is in either LR or PS and should just be there so it can send that setting on the printer drier, much like it does with application managed or printer managed color. They also both show up in both places.
What is puzzling is why the setting doesn’t jive. If I turn it off in LR why is there a circumstance where it’s still on the printer driver. If I select a template with 16bit, toggle the checkbox to 8 bit in the Print Job section, if just hit the print button it’s going to the pinter as 16 bit, because that setting isn’t syncing. I have to also open the Printer ... dialog box and toggle it there.
I think they are intended to sync. Seems like a bug to me, unless an Epson engineer would like to explain why it’s working as intended and what use it provides.
-
Thanks. I've done some research about WinOS printing and it looks as though MSFT provided 16 bit print capability back when Vista was developed well over ten years ago now. The specification is XPS and drivers need to be compliant with that. It looks like only Canon has done this but the problem as I've read is that Adobe has not put the feature in LR to do this with WinOS (and I assume PS as well). It's interesting that the ability to do 16 bit printing in WinOS has been around for so long and never implemented until recently and only by on manufacturer. Some RIPs can do 16 bit printing in WinOS. Curious situation.
With my sc-p9000 it appears to be 16 bit as the spool file is twice the size in MB. Windows 10 plus Lightroom Classic cd . The printerresolution image of Bart van der wolf is printed all the way to the 720 ppi limit. Without artefacts as a result of down rezzing or so. However i now have a curious Problem, that is my sc-p7000 , using the same driver version, somewhere in the pipeline the image appears to be converted to 8 bit (or 360ppi) yet printed at 720ppl, with some kind of dithering for the part above 360ppi. And artefacts already well before the 360ppi limit. In the dithered part you can see the original structure but faintly with a 10x loupe going all the way to the 720ppl limit.
Would this printer resolution test image be a good test for the 8 or 16 bit quest?
-
Now on this again, never occurred to me to verify because I just leave the highest quality options selected and perpetually active everywhere they exist, but in Lr, there are TWO places for selecting 16 bit (see attached screen grab), the first being in the Lr Print interface, the second in the Epson driver accessed through Lr (OSX). Why both?
I commented on this in an earlier post. The LR checkbox is the instruction for LR to send 16 bit data to the print driver. To print at 16 bits you need to have both the LR and driver checked to accomplish this. LR for Windows does not have a 16 bit check box. I'm still on the old LR 6 as I have not bought into the subscription service yet. However, from what I've seen in some Internet research the current version of LR for WinOS does not have this feature yet. As noted also, only one Canon printer that I've found supports 16 bit printing under WinOS and you need to make sure that the Canon XPS driver is installed. Here is the most current comment on LR from the Queen herself: https://feedback.photoshop.com/photoshop_family/topics/16-bit-printing-in-windows-10
-
Would this printer resolution test image be a good test for the 8 or 16 bit quest?
Where can I find this image?
-
3. I'd submit that such testing at the very least should be done, on the Mac (for Epson) using a driver that specifically has this check box because newer drivers have no such option and despite my questions to Epson, I haven't received an answer if the newer drivers still pass all high bit to the driver or not. I kind of suspect not, here's why and yes, it's a massive assumption: the high bit check box wasn't available on Windows. This probably didn't make Windows user aware of this happy. It makes some sense to remove it on the Mac as they've done with my P800. That doesn't mean on either Mac or Windows, newer drivers don't 'detect' 16-bit and pass it along if found. But since no one here has provided much proof it makes a visual difference, it would make some sense to simply make it all disappear.
Is there any chance that the missing 16 bit checkbox has something to do with the current version of Photoshop? My Epson P5000 is on driver 10.18 which is the most recent one on Epson’s web site and the checkbox is available when I print. However, I’m still using CS6 and I don’t know if that has something to do with it or not. Also, High Sierra on my Mac if that matters.
-
LR does NOT send 16 data to the Canon Pixma Pro 1 - XPS driver run on Windows. ( I think this is conflict of interests of Adobe vs MSFT around xps format). I have seen banding in BW using this configuration.
The turn around to print 16 bits is to use the Canon print studio pro plug in. LR exports 16 bits files into it, so the xps driver gets all the 16 bits data. No banding if you do so.
I did not recheck lastly, but I think PS results were something intermediate, may be due to dithering.
I commented on this in an earlier post. The LR checkbox is the instruction for LR to send 16 bit data to the print driver. To print at 16 bits you need to have both the LR and driver checked to accomplish this. LR for Windows does not have a 16 bit check box. I'm still on the old LR 6 as I have not bought into the subscription service yet. However, from what I've seen in some Internet research the current version of LR for WinOS does not have this feature yet. As noted also, only one Canon printer that I've found supports 16 bit printing under WinOS and you need to make sure that the Canon XPS driver is installed. Here is the most current comment on LR from the Queen herself: https://feedback.photoshop.com/photoshop_family/topics/16-bit-printing-in-windows-10
Sent from my Nokia 6.1 using Tapatalk
-
Does it? Even if it does, one can still test this by:
1. Convert in high bit to the output color space to avoid dither, print the image in the output color space using ACPU, an older version of Photoshop that allows this or another utility similar to ACPU.
2. Keep everything in 16-bit, turn off the 16-bit check box in the printer dialog box.
3. I'd submit that such testing at the very least should be done, on the Mac (for Epson) using a driver that specifically has this check box because newer drivers have no such option and despite my questions to Epson, I haven't received an answer if the newer drivers still pass all high bit to the driver or not. I kind of suspect not, here's why and yes, it's a massive assumption: the high bit check box wasn't available on Windows. This probably didn't make Windows user aware of this happy. It makes some sense to remove it on the Mac as they've done with my P800. That doesn't mean on either Mac or Windows, newer drivers don't 'detect' 16-bit and pass it along if found. But since no one here has provided much proof it makes a visual difference, it would make some sense to simply make it all disappear.
YEARS ago when I was working on the Epson Print Academy I asked the product manager in the US for pro printers why the check box was there if I couldn’t see any difference. He said that 'someday' in the future, the printers might be able to use this additional data and it could be seen on output. I don't believe that day's arrived yet.
Can't speak to the Mac, but LR Classic automatically dithers high bit images when printing. I'm not aware of any option in LR. It just does it. It's effectively the same as printing with a 16 bit path, even on torture images like the "black ball."
Also, it does a fine job of properly using the 30 bit video driver on my system.
As an aside, I was looking at the yellow dot ink laydown (hooray for scanners) on my 9800 between RGB 255,255,255 and 255,255,254. For ducks I also looked at 255,255,254.5 and printed with dither selected from Photoshop w/o CM so the dither is applied directly to the printer. (The 9800 is an 8 bit only device)
Turns out that in a square of 50x50 "720 DPI pixel spaces" there are only about 50 yellow ink dots randomly scattered and half that for the fractional RGB that would be dithered by PS. So the print driver is already, on 8 bit image paths, broadly dithering where it drops ink. I'd bet the plugin Canon uses with XPS on Win. just dithers the fractional and sends the data to the Win. driver too. This is all just marketing IMO. It reminds me of audiophiles with "golden ears" but give them an A/B test.....
-
...So anyone with this printer on Mac running Mojave can test this without the need of a Spectrophotometer. Look at greens. The lowest dE is a middle gray (0.21). So the black ball is in an area of color space (neutrals so to speak) where the color differences are the least. The driver I'm using for the Mac is 9.33, I can't find anything newer.
Odd, very very odd!
Andrew,
It sounds like you've completed your investigation (although I found it a bit difficult to follow this thread). I don't have a 3880 but I do have a 7900, along with Mojave, LR/PS CC 2019 updated yesterday, eye one pro (not 2) / iprofiler, and ColorThink Pro. If there are any tests that would help I could do them over the weekend.
I also have ImagePrint, if an additional test through an independent driver would provide any insight.
Dave