The printer driver - the last mile

[tvalleau]

I have what I thought was a simple question, but it turns out to be more than a little difficult to get answered: what _exactly_ does the Epson photo printer driver -do-?

I have searched the fount of all wisdom, including LuLu, and even called Epson and their first two tiers of support couldn't answer the question.

I always thought that the driver took in binary data from the image, and spit out a printer command language (PCL) set of instructions. But I cannot confirm that.

Here's where the question comes from: there are major players in the printing business saying that "you do not need to send a 16-bit image to the printer because it will be converted to 8-bit anyway" and  "Apple only uses 8-bits internally."

Ummm.... First, Apple has had a 16-path since 2007, AFAIK. And second, the Epson driver has a checkbox for 16-bit data, so it gets at least that far as 16-bit.

I make my own 16-bit printer profiles, which are sent to a 16-bit Profile Connection Space for conversion to send to the 16-bit driver.

So what happens inside the driver black box? That's what the first few tiers of Epson support could not answer.

It obvious that (for serious fine art printing) a 16-bit image renders gradations and luminosity (especially in the blacks) better than an 8-bit image. So it seems to me that it's equally obvious that the image is NOT "converted to 8-bit" as they claim. (Just compare an 8-bit Piezography print to a 16-bit one...)

Now it wouldn't surprise me if my conjecture about the PCL (or Epson's own version of a command language) is correct, that it does not need more than 8-bits to describe how to work the 8 (or 10 or 12 whatever) inks that need to be sized, positioned, and timed. Most CMYK printers don't need more than 8-bits for the language, as I understand it.

Is that the point of confusion: where the 8-bit "advice" came from? A misunderstanding?

Or is it just me that isn't getting it?

I continue to insist on 16-bit images from my clients, so that I have the headroom to adjust them for critical printing. But I've recently had two customers argue with me, and refuse to supply a 16-bit, saying that Gigantic Printing Inc told them it wasn't needed, and therefore I don't know what I'm talking about.

I've been printing since 2003, and like many of you, my prints are in museums and galleries and have sold in the 4-figures. And I do know that a -final- 8-bit print is very close to the same print sent as 16-bit... and may well be 'good enough'.

it's just that "good enough" isn't.

So, after all that: can anyone tell me what happens in the last mile?

Thanks.

[deanwork]

High bit data can improve rendition of areas where high frequency detail is involved, subtle highlight information especially.

“Frequency is used to describe the amount of detail packed into a given area of an image. This is measured by the amount of tonal variation between rows or columns of pixels.”

I have what I thought was a simple question, but it turns out to be more than a little difficult to get answered: what _exactly_ does the Epson photo printer driver -do-?

I have searched the fount of all wisdom, including LuLu, and even called Epson and their first two tiers of support couldn't answer the question.

I always thought that the driver took in binary data from the image, and spit out a printer command language (PCL) set of instructions. But I cannot confirm that.

Here's where the question comes from: there are major players in the printing business saying that "you do not need to send a 16-bit image to the printer because it will be converted to 8-bit anyway" and  "Apple only uses 8-bits internally."

Ummm.... First, Apple has had a 16-path since 2007, AFAIK. And second, the Epson driver has a checkbox for 16-bit data, so it gets at least that far as 16-bit.

I make my own 16-bit printer profiles, which are sent to a 16-bit Profile Connection Space for conversion to send to the 16-bit driver.

So what happens inside the driver black box? That's what the first few tiers of Epson support could not answer.

It obvious that (for serious fine art printing) a 16-bit image renders gradations and luminosity (especially in the blacks) better than an 8-bit image. So it seems to me that it's equally obvious that the image is NOT "converted to 8-bit" as they claim. (Just compare an 8-bit Piezography print to a 16-bit one...)

Now it wouldn't surprise me if my conjecture about the PCL (or Epson's own version of a command language) is correct, that it does not need more than 8-bits to describe how to work the 8 (or 10 or 12 whatever) inks that need to be sized, positioned, and timed. Most CMYK printers don't need more than 8-bits for the language, as I understand it.

Is that the point of confusion: where the 8-bit "advice" came from? A misunderstanding?

Or is it just me that isn't getting it?

I continue to insist on 16-bit images from my clients, so that I have the headroom to adjust them for critical printing. But I've recently had two customers argue with me, and refuse to supply a 16-bit, saying that Gigantic Printing Inc told them it wasn't needed, and therefore I don't know what I'm talking about.

I've been printing since 2003, and like many of you, my prints are in museums and galleries and have sold in the 4-figures. And I do know that a -final- 8-bit print is very close to the same print sent as 16-bit... and may well be 'good enough'.

it's just that "good enough" isn't.

So, after all that: can anyone tell me what happens in the last mile?

Thanks.

[tvalleau]

Indeed it can, Dean and thanks for replying. However, that doesn't get at what the printer driver is doing. I'll keep seaching, and if I find out, I'll come back and post the answer.

[Nora_nor]

I remember someone answered here several years ago and it involved cups

[PeterAit]

Indeed it can, Dean and thanks for replying. However, that doesn't get at what the printer driver is doing. I'll keep seaching, and if I find out, I'll come back and post the answer.

I don't understand why this matters. Isn't it the final print that matters?

[jrsforums]

A response in Qimage forum.  ‘amdin’ would be the creator, Mike Chaney.

https://ddisoftware.com/tech/qimage-ultimate/16-bit-printing/?wap2

[tvalleau]

On Oct 25, 2022, at 1:01 AM, Tracy Valleau <tracy@dlsi.biz> wrote:

Here, lightly edited for clarity, and posted with his permission, is Walker Blackwell's reply:

(snip)

Me: I have what I thought was a simple question, but it turns out to be more than a little difficult to get answered: what exactly does the Epson photo printer DRIVER -do-?  I always thought that the driver took in binary RGB data from the image, and spit out a printer command language (PCL) set of instructions. But I cannot confirm that.

W: That is essentially what it does with a little extra Epson-only language sprinkled in.

Me: Here's where my question comes from: there are major players in the printing business saying that "you do not need to send a 16-bit image to the printer because it will be converted to 8-bit anyway" and "Apple only uses 8-bits internally."

W: Only partially true. Apple has 16bit pipeline (has had for many years). But unless you are doing grayscale printing you don’t need it at all. In fact there is a longstanding bug when printing 16 bit with Epson drivers on pro printers that skews the colors wonky. So nobody uses 16bit for color printing. ...the 16bit bug doubles the color saturation. Turning 16bit off [fixes it.]

Me: Ummm.... First, Apple has had a 16-bit path since 2007, AFAIK. And second, the Epson driver has a checkbox for 16-bit data, so it gets at least that far as 16-bit.

W: Exactly. But don’t click 16bit it’s messes up everything.

(snip)

W: RGB is 256*256*256 gradients really. So overkill unless only grayscale image is printed.

W: It’s just that 8bit is already good enough to produce literally some of the best and smoothest images. Think about it. You start in 16 bit and work your image. Once you have a perfect image in photoshop when you convert to 8bit from there you don’t actually lose any image quality. You would if you continued to edit it but that is not what you are doing in printing really. So 16bit -> 8bit pipeline is fine. Less work and file size ,no change in color print quality.


Me: I continue to insist on 16-bit images from my clients, so that I have the headroom to adjust them for critical printing. But I've recently had two customers argue with me, and refuse to supply a 16-bit, saying that Gigantic Printing Inc told them it wasn't needed, and therefore I don't know what I'm talking about.

W: Keep insisting. Working space is different than output space. Working space needs the flexibility to stretch. Output is just a final conversion to ink, 16bit not needed.

Me: I do know that a -final- 8-bit print is very close to the same print sent as 16-bit... and may well be 'good enough'.  It's just that "good enough" isn't.

W: But in RGB world it actually is. (snip)

Me: Where did that "common wisdom" that "...it will be converted to 8-bit anyway" come from?

W: It’s mostly bullshit (it does not convert to 8 anyway) but it’s not invalid. There is no need to be at 16 unless you have grayscale gradients.

regards

-Walker

(Thanks Walker. I learned things I didn't know.)

[tvalleau]

I don't understand why this matters. Isn't it the final print that matters?

Yes, that is exactly the point - getting the best possible print. 8-bit images cannot be edited as well as 16-bit images. Further, the 16-bit image is NOT being converted to 8-bit automatically. So the editing and print quality, as well as correcting mis-information, is the point.

[jrsforums]

Yes, that is exactly the point - getting the best possible print. 8-bit images cannot be edited as well as 16-bit images. Further, the 16-bit image is NOT being converted to 8-bit automatically. So the editing and print quality, as well as correcting mis-information, is the point.

For editing, there are good examples showing the benefits of 16-bit data.  For printing….not so much…if any at all.  I fear you are ‘slicing the baloney too thin’ 😀

[Lessbones]

Looping back to the original question--  you should check out the documentation for gutenprint.  Basically you were on track in that Epson does have it's own language, with a few variations for different printers containing different numbers of inks.

Basically as far as I have ever been able to tell, a printer "driver" is a simplified version of a RIP-- it essentially just takes the RGB (or CMYK) data from the computer, and funnels it through the chosen preset for paper type, which determines mainly head height, which main black to use, and total ink limit.  All these actual transforms on the data actually occur in the printer itself however.  Inside the printer is an SOC that performs the ink splitting duties out to dilute inks and how and when to use extended gamut colors like orange and green.  I would love to know how this system works, because I'm pretty sure it's not operating on standard ICC principles.  This goes for the main 3 manufacturers of large format aqueous inkjet printers, namely Canon, Epson, and HP.  For other printer manufacturers it is up to the end user to figure out how to best handle these parameters, and it can be a daunting task.

I recently made a profile for an Epson 9900 with a bad yellow channel-- I had replaced the green ink with yellow, and in order to profile it in this state I had to determine my own crossovers from LC to C, LM to M, and for the 3 black inks.  A huge amount of trial and error can be involved, and usually the screening patterns built into most RIPS are not as refined as the ones Epson and other OEMs purpose build for their proprietary drivers.

at this point the RIP is sending to the printer a 1 or 2 bit file that has a channel reserved for each individual ink present at the selected resolution--

say if you choose 720x1440dpi, there is now a raster grid for every single channel containing either a 0,1,2 or 3 (for 2-bit VSD) or a 0 or 1 for 1 bit.  These files are generally massive, and you don't usually see them appear on your hard drive.  I learned a ton about this with my chinese made UV printer, which makes no attempt to hide it's inner workings.  a 10kb jpeg sized to 30"x40" on a 6 channel printer all of a sudden can bloom to 3-4gb when translated into the language of the print head.

I'm extremely interested in gutenprint, but there is a relatively lacking community around it--  having printer drivers that enable you to ditch a channel when one goes bad (say, switch your bad black channel into light cyan, losing some smoothness, but regaining the ability to print images) is invaluable, and it seems like it could be turned into an incredibly capable open source RIP if given the proper GUI treatment...

[PeterAit]

Yes, that is exactly the point - getting the best possible print. 8-bit images cannot be edited as well as 16-bit images. Further, the 16-bit image is NOT being converted to 8-bit automatically. So the editing and print quality, as well as correcting mis-information, is the point.

I agree--I always work in 16 bit (if possible)--but what does this have to do with the printer driver?

[Lessbones]

The point is that once your image is "finalized" to the point where you're ready to print, it won't be advantageous to have in 16 bit vs. 8 bit, the output will be indistinguishable

[BobShaw]

A couple of things I have discovered:
1. Many printers, even expensive ones, are only 8 bit. The Epson P800 for example is 8 bit.
2. If you print on rolls then the print comes out whatever size you say as long as it is less than the roll printable area.
If you print on sheets especially and send an A4 print to A4 paper then it has to change the size, because it either has to allow for the border or the unprintable area or overprint if it is borderless. So the print size will be changed and there I expect a 16 bit file would be an advantage.

I always use a 16 bit file regardless so whatever happens does not matter, and one day I may have a 16 bit printer.

[PeterAit]

The point is that once your image is "finalized" to the point where you're ready to print, it won't be advantageous to have in 16 bit vs. 8 bit, the output will be indistinguishable

You are really not understanding me. The print is the thing, right? And if you get a gorgeous print that you love who cares whether the driver is 8 or 12 or 16 bits? And if the print is crummy, same question.

As an analogy, when you eat at a fancy restaurant do you judge the food? Or do you fret about whether the chef uses copper or iron pans, gas or electric stove, etc?

And by the way, 16 bit images are better for editing regardless of the printer bit depth.

[TheNinth]

The point is that once your image is "finalized" to the point where you're ready to print, it won't be advantageous to have in 16 bit vs. 8 bit, the output will be indistinguishable

But why does that matter? If we agree a 16 Bit workflow has advantages, why not send the file as 16 Bit to the printer, just out of convenience?

[jrsforums]

But why does that matter? If we agree a 16 Bit workflow has advantages, why not send the file as 16 Bit to the printer, just out of convenience?

Yes, but , in most cases, it will be converted to 8-bit for driver.

16-bit workflow has potential advantages particularly when doing a lot of manipulation.  I’m not sure you need that for final printing….unless creator did a poor job on original image, which I am not sure it is your job to correct.

[Lessbones]

the only point would be quicker workflows with flattened files and lower storage usage.  If you're not sending files all over the internet and you have plenty of space and computing power, then by all means, keep them in 16 bit.  by no means is it "better" to downconvert before printing.  Personally I never work in 16 bit unless it's a very special case, because of how much slower things are to process, but i'm doing this commercially, and time is a critical asset.

[neil snape]

I didn't read all the posts, I am sure there is good information in there.
16 bit print workflow is going to call up different masking processes in the driver making the spool file. This is where the extra bit depth can create a smoother transition (in theory) and or better definition if using the finest droplet size. Remember that colour gamut is largely dependant on overlapping droplets this the more information sent to the driver, the better the spool file potential.
Generally it is not made for what you would think photographers would wish for.
It is depending on the driver (I worked with HP engineers) made for creating masking for contrasty lines vertical/horizontal and diagonal lines typically text, as a priority, graduations after...
It may help in the case of some graduations but that is not the intended purpose or so they told me.
I have not found any real tests that proved better graduations in graduations with 16 bit files sent to the driver. So you have to try as each printer brand will have different masking.
One thing is sure, the spool times are much longer with 16 bit, so be ready for that.