Up-Rezing or Down-Rezing an image

[Bart_van_der_Wolf]

On the other side of the fence, you would choose to upsample to 360 or 720 not because you think you are "gaining data", but because those resolutions align nicely with the dot patterns used by an Epson printer and, being multiples, align well with those dot patterns and produce fewer artifacts.  As an added benefit, you are using the data you have and not throwing anything away when you upsample.

Hi Mike,

Thanks for commenting here. An additional benefit of upsampling rather than throwing away data, is that one can output sharpen at the larger size, i.e. more precise and probably use a bit higher amount as well. With Qimage Ultimate and your DFS algorithm used for Smart output sharpening, it can be pushed further because DFS doesn't produce halos.

You mention the alignment with the dot patterns used, and all evidence points in the direction of the dither pattern expecting either 360 or 720 PPI input, or it will first resample to that. Yet there are also some who question whether resampling actually takes place, even though the aliasing patterns of test prints point towards resampling (given the periodic aliasing artifacts that are perfectly consistent with resampling). Also the printer driver reports back what PPI it wants to receive.

Because you've studied the printer driver API in more detail, and may have spoken with insiders at Epson/Canon, do you have any additional 'proof' you are allowed to share that resampling is what the printer driver will do, instead of some sort of dithering that happens to produces 'resampling artifacts' (which would be strange for a stochastic dither pattern, unless very poorly designed).

When talking about upsampling to 360 versus 720, I've found that most printers/papers can render detail at a maximum of somewhere between that range.  In other words, some detail can be rendered higher than 360 but probably not as high as 720.  It's not straightforward because it depends on the printer you are using, the paper you are printing on, the driver settings, and even the color you are testing.  Generally speaking, if you are printing a high res image and that image already has higher than 360 PPI at the intended print size, printing at 720 versus 360 will yield a little better minute detail.

Yes, that's the overall consensus nowadays. In my experience, even some very nice matte surfaces (like Canson Infinity Baryta Photographique, with a satin surface) can retain these high resolutions. Of course, a good profile will help the printer to send the right amount of ink to avoid too much ink diffusion. Maybe it would even be a nice addition for Qimage to offer some sort of control to allow tweaking of sub-optimal paper profiles for the best ink load that offers the largest gamut with high densities but minimum ink useage.

But you'll probably have to put your nose almost to the paper to see it.

Ha, you can leave it up to us pixel peeping photographers to do just that!

That's why I often say that printing at 360 PPI is fine for large prints and 720 more appropriate for smaller ones because those smaller ones might undergo closer scrutiny.  Nothing wrong with printing at 720 PPI for everything, but you may never see the benefit on a 40x30 hanging on a wall.

And viewing distance will quickly kill our ability to see the detail anyway. However, don't underestimate the benefits of being able to do better output sharpening(!), which translates to more than just the detail between 360 and 720 PPI. The Modulation Transfer Function (MTF) curve of the entire image will be lifted when the finest details are sharpened. The entire image will 'pop' more, even at larger viewing distances.

Cheers,
Bart

[dwswager]

As I've said, I send 360ppi to my Epson and have done so all the way back to the 1994 Epson Stylus Color printer.  For smaller prints for which I have more data than 360ppi, I sometimes upsample to 720ppi.

I don't know the Mac OS, but on Windows, the Graphics Device Interface (GDI) is basically concerned with screen draws.  There is obviously the printer function calls necessary to facilitate printing, but the actual data handling and conversion is done by the driver (more a full featured program in Epson's Case).  The Windows GDI printer calls are here.  The only thing that comes into play is the DeviceCapabilities function call the application makes to populate the INTERNAL printing dialog boxes.  One value it can request is DC_ENUMRESOLUTIONS in which it passes back the resolutions capable by the printer.  However, I've never seen an application actually use this function and instead requires you to go into the into the Epson printer properties box, not part of GDI,...something like this:



As we are all aware, Epson does not present an option to change 'resolution' directly, but based on combination of settings like Media Type, Print Quality and Finest Detail checkbox affect a change in printer quality indirectly to 720x720, 1440x720, 2880x1440, etc.

Question:  You are saying if I write a program that issues a DeviceCapabilities function call to the Epson printer, it will report back 360 and 720, 1440 or whatever depending on the printer model?

DWORD DeviceCapabilities(
  _In_   LPCTSTR pDevice,
  _In_   LPCTSTR pPort,
  _In_   WORD DC_ENUMRESOLUTIONS,
  _Out_  LPTSTR pOutput,
  _In_   const DEVMODE *pDevMode
);

Jeff, unfortunately, on the the Windows platform I don't see how one could save the image to PDF without specifically giving the application a resolution setting or printing to PDF which also entails setting the output parameters.  There does not seem to be a method on Windows to use printing settings for the Epson and then save as PDF instead except maybe printing to a FILE port and looking at the printer output.

Finally, someone mentioned a 359pp, 360ppi, 361ppi test resulting in some aliasing artifacts.  Has this test been done at 239,240,241 or 479,480,481 to see if the same occurs?

[Bart_van_der_Wolf]

I don't know the Mac OS, but on Windows, the Graphics Device Interface (GDI) is basically concerned with screen draws.  There is obviously the printer function calls necessary to facilitate printing, but the actual data handling and conversion is done by the driver (more a full featured program in Epson's Case).  The Windows GDI printer calls are here.  The only thing that comes into play is the DeviceCapabilities function call the application makes to populate the INTERNAL printing dialog boxes.  One value it can request is DC_ENUMRESOLUTIONS in which it passes back the resolutions capable by the printer.

As we are all aware, Epson does not present an option to change 'resolution' directly, but based on combination of settings like Media Type, Print Quality and Finest Detail checkbox affect a change in printer quality indirectly to 720x720, 1440x720, 2880x1440, etc.

Question:  You are saying if I write a program that issues a DeviceCapabilities function call to the Epson printer, it will report back 360 and 720, 1440 or whatever depending on the printer model?

Hi,

I'm not 100% sure if that's the function that, amongst others, Qimage uses, but it could well be the one. There could be other mechanisms besides the Windows GDI that may be involved, and the printer driver itself might also have some directly accessible functions.

Finally, someone mentioned a 359pp, 360ppi, 361ppi test resulting in some aliasing artifacts.  Has this test been done at 239,240,241 or 479,480,481 to see if the same occurs?

I don't have an Epson printer, so I cannot test that specifically for you. If you use the test file I attached to my earlier response (post #26), tag (no resampling, only tagging) a copy with the PPI you want to test, and send it to the printer, it would give you the answer.

The file is 720 pixels wide, so it should print as 720/239=3.013 inches, 720/240=3.0 inches, 720/241=2.988 inches, when not resampled. Now try and force it to print as 3.0 inches exactly (you might want to try both with and without the 'Finest detail' option on), and watch what happens. Compare that to printing it to exactly 1 inch, at 720 PPI with 'finest detail' switched on. Same for the 479/480/481 scenario.

I would also be interested to see the actual results that the Epson driver produces, with the relevant driver settings used (so others can repeat and compare the experiment, to rule out specific printer issues like head alignment). Few people post images of their findings, which makes it difficult to discuss and compare. Jim Kasson's scanned output in his blog is a fine exception to that.

Using a paper with relatively low ink diffusion characteristic is of course helpful.

Cheers,
Bart

[dwswager]

I'm not 100% sure if that's the function that, amongst others, Qimage uses, but it could well be the one. There could be other mechanisms besides the Windows GDI that may be involved, and the printer driver itself might also have some directly accessible functions.

I'm surprised Qimage actually interacts with the printers.  Even Photoshop doesn't.  I haven't seen an application that actually worked that way since Windows 3.1!!  Most applications require you to utilize the printer driver/application to make settings changes beyond maybe setting the number of copies.  Though Photoshop does take the current paper size setting from the printer, but not much else that I can tell.

I'm also surprised that Epson's driver/application is smart enough not to override the Qimage settings with it's own stored defaults/last used settings in the driver.

I don't have an Epson printer, so I cannot test that specifically for you. If you use the test file I attached to my earlier response (post #26), tag (no resampling, only tagging) a copy with the PPI you want to test, and send it to the printer, it would give you the answer.

The file is 720 pixels wide, so it should print as 720/239=3.013 inches, 720/240=3.0 inches, 720/241=2.988 inches, when not resampled. Now try and force it to print as 3.0 inches exactly (you might want to try both with and without the 'Finest detail' option on), and watch what happens. Compare that to printing it to exactly 1 inch, at 720 PPI with 'finest detail' switched on. Same for the 479/480/481 scenario.

I would also be interested to see the actual results that the Epson driver produces, with the relevant driver settings used (so others can repeat and compare the experiment, to rule out specific printer issues like head alignment). Few people post images of their findings, which makes it difficult to discuss and compare. Jim Kasson's scanned output in his blog is a fine exception to that.

Using a paper with relatively low ink diffusion characteristic is of course helpful.

Once I get my installation of Photoshop back printing from my Jeff inspired experiment trying to get the Epson output to file via printing to the Epson 3880 on FILE: printer port hosed it up, I will give this a try.  Most likely I will use some EEF scraps so that is about as good as it gets for sharpness.

[hugowolf]

I'm surprised Qimage actually interacts with the printers.  Even Photoshop doesn't.  I haven't seen an application that actually worked that way since Windows 3.1!!  Most applications require you to utilize the printer driver/application to make settings changes beyond maybe setting the number of copies.  Though Photoshop does take the current paper size setting from the printer, but not much else that I can tell.

The minimum borders/margins are also reported and used.

I'm also surprised that Epson's driver/application is smart enough not to override the Qimage settings with it's own stored defaults/last used settings in the driver.

What is to override? This is the requested input resolution (in ppi), it is not like you are trying to set the output resolution (dpi). But, if you do  not check Finest Detail, 720 ppi is overridden.

There is a similar method (function) in Java, if I remember correctly.

Brian A

[dwswager]

What is to override? This is the requested input resolution (in ppi), it is not like you are trying to set the output resolution (dpi). But, if you do  not check Finest Detail, 720 ppi is overridden.

There is a similar method (function) in Java, if I remember correctly.

Brian A

Quite frankly, everything, If Qimage does not bypass the front end to the driver/app.

With respect to your second sentence, that is the question that is being investigated and has never been definitively confirmed.  If the Epson driver was requesting data in a specific resolution, I would have expected that this would have been documented long ago.  There has been speculation about this issue since 1994 and a definitive answer this simple seems unlikely to have gone undocumented, especially as it would have eliminated a lot of consternation and crap loads of wasted paper and ink used for testing.

Since I haven't programmed anything in about 6 years, I have to load the C++ development environment back on my system to see what the Epson returns to a resolution request.  I suspect a null string, as I expect the driver front end is going to want complete control, but will gladly jump for joy if it returns 360 and 720 as there would at least be some hint that a resample is being requested.  I will also be disappointed if the 3880 returns:

360x360
720x720
1440x720
1440x1440 and
2880 x 1440.

This will be useless in this investigation as it will just represent printer output 'resolutions' that would populate a selection dialog and not be indicative of any re-sampling.

And it makes zero sense that if the driver requires the data in a specific resolution that A) Epson would not want to do the resampling to ensure the best quality possible, or B) The application would not do it as the best vehicle and that it would be left to the OS to resample the data.

[Added Clarification]

The return values of the DeviceCapabilities API call are not requirements for anything for the application or GDI to do. If the  DC_ENUMRESOLUTIONS request comes back 150, 300 and 600 dpi, that does not mean the data sent to the printer must be a raster image in that resolution.  It is information intended for the application to present to the user as a option if its using it's own printer dialog.  Photoshop does not use this resolution data and requires the user to set these properties in the printer driver settings application.  Both Photoshop and the OS is completely agnostic as to what resolution and Epson printer is going to print at.   This is a throwback to the old days when printers had their own RIP and special processors.  Now, all the data is processed on the PC side and transferred to the printer.

Bottom line:  If you print from Photoshop a 4x5 image at 360ppi, no matter how you set the printer driver, what get's sent to the driver is identical.   Only the data output by the driver and sent via the port to the printer will be different.  The only thing that changes is how the data is handled by the driver and the mechanical machinations of the printer itself.  The point of an outboard RIP is to give the user control on over how the data is handled.  But then, you are bypassing the driver and sending the data via the output port directly to the printer.  Again, the Application and OS are ignorant of those handling options.

Hence, either the data is resampled by Epson in the driver or it's not resampled at all!  There is no mystery component in every OS mucking with your data.

[disneytoy]

This has been excellent info. I needed to print 34x25ish" from 16mpx 4500x3200 files.

Taking the advice here, I uprezed my files to 360 dpi for printing out of LR5.

I tried Perfect resize 9, because they have the "fractal" algorithm.

Also PS CC 2014.

What I found is, with some noise reduction first, Perfect Resize gave a rather dabbled pattern. irregular dabs. A bit smoother than PS. I think PS is more accurate to the original file.

Perfect Resize is a bit more arty, watercolor like. Not a bad thing.

So, hopefully I'm getting the absolute best large print from these steps.

I don't think you would be missing anything using the latest PS uprezing.

I'm going to try some 34x48" prints next.

Even though my initial file size is not optimal, (waiting for my 50mpx Sony a7rII) I think the added viewing distance at 34x48" will balance out the lack of resolution. We will see!

This is the fun part of having a 9890!

[Bart_van_der_Wolf]

I'm surprised Qimage actually interacts with the printers.

Qimage does not bypass the printer driver (if that's what you mean), it interrogates it and sends it various settings. It can store different settings e.g. for different papers, and then populates the necessary fields of the driver, before sending it the resampled data.  For the resampling it first asks which resolution the printer expects to receive, and then resamples the image to match those expectations. That also involves things like asking for print margins, the real ones based on printable area, because it needs to know the actual output size and then uses the PPI info to resample pixel perfect results, and sharpens that (based on the amount of resampling, thus respecting the original resolution that's available) before setting the printer driver settings and outputting the data stream to the driver.

Qimage is not a RIP in the traditional sense, but a image resampling and print queue manager that interacts with the printer driver (receiving and sending of parameters, and outputting image data).

Cheers,
Bart

[Ernst Dinkla]

I thought Mike could shed a light on how Qimage interacts with the Windows drivers but he kept that part disguised so far. Might be on purpose, Lightroom does not have that level of interaction. The relation with the settings is also kept in the saved Qimage log files but with for example changes in driver versions the choices can get corrupted. With the HP Z drivers there were more issues in the past as they were less Windows compatible according Mike. I think this thread had its answers for the OP and did not change my perspective on the driver requested input resolutions. The thread may not satisfy the curiosity of programmers but the described tests and reported printer's practice give enough indications it isn't BS.

Met vriendelijke groet, Ernst

http://www.pigment-print.com/spectralplots/spectrumviz_1.htm
December 2014 update, 700+ inkjet media white spectral plots

[hugowolf]

.. I uprezed my files to 360 dpi for printing out of LR5.

Why would you do that? Why not let Lr handle it?

Brian A

[Mark D Segal]

Go back to reply #19

[hugowolf]

Go back to reply #19

I am not questioning the 360 ppi, I am questioning uprezing in Ps to print from Lightroom, which, unless I am misreading it, appears to be what was done.  When all that needs to be done is to check the Resolution box in Lightroom and set it to 360 ppi.

Brian A

[Mark D Segal]

OK, there's so much cross-talk and so many applications at play in this thread it's hard to keep track of the conversation. But yes, I agree with what you say about doing it in LR. And it works very well.

[Tony Jay]

OK, there's so much cross-talk and so many applications at play in this thread it's hard to keep track of the conversation. But yes, I agree with what you say about doing it in LR. And it works very well.

Ditto!
I read your post Brian but Mark answered the question - your reply clarified what you really meant and it is absolutely correct.
There is no need to to uprez in Ps if one can do it in Lightroom (easier too).

Tony Jay

[disneytoy]

Because I was uprezing from around 4500x3200 to 12,200x XXX. I experimented with the different options and found uprezing in the current PS CC 2014.2 using Preserve detail setting to produce the most acceptable file to print. In fact I just printed a 34" x 48" this way and it looks great.

The original fine was very sharp and clean to start with. I do a bit of noise reduction first with NIK Define. Then Image Resize.

I like Perfect Resize but it is not as detailed as PS. I found that Lightroom 5.7 does not use as good an algarythm as the latest PS. LR does seem to lag a bit with matching PS features, i.e. Contentaware, etc.

Maybe in LR6 the upresing will be equal.

Understand, I'm doing a pretty big jump. Maybe for going from 8x10 to 11x14 or 16x20 LR5 is fine.

I did 100% print outs using LR5, PS CC Preserve Detail, and Perfect Resize. All to 360dpi. They are close, but to my eye, PS looked less "altered." Perfect resize has a watercolor like dappled "grain."

LR5 had more jaggies, that is why I think it is using an older re-sampling algorithm. Remember a couple releases ago PS updated their image Resize algorithm.

It is subtle but at a 34x48" print you can see some difference around the edges.

Also, my workflow, I can examine the uprez on screen prior to wasting a 4 foot print.

But I may try the Perfect resize 9 again for certain images that do not have fine grain.

As soon as I get a roll of 44" Glossy, I'll try a 42"x64" print.

[dwswager]

Qimage does not bypass the printer driver (if that's what you mean), it interrogates it and sends it various settings. It can store different settings e.g. for different papers, and then populates the necessary fields of the driver, before sending it the resampled data.  For the resampling it first asks which resolution the printer expects to receive, and then resamples the image to match those expectations. That also involves things like asking for print margins, the real ones based on printable area, because it needs to know the actual output size and then uses the PPI info to resample pixel perfect results, and sharpens that (based on the amount of resampling, thus respecting the original resolution that's available) before setting the printer driver settings and outputting the data stream to the driver.

Qimage is not a RIP in the traditional sense, but a image resampling and print queue manager that interacts with the printer driver (receiving and sending of parameters, and outputting image data).

Cheers,
Bart

Yeah, I got that.  To bypass the driver you would have to convert the data to the 'machine's native language.  I was not speaking to Qimage specifically, but applications of all types in general.

My main points were:

1. Resolutions returned by a printer in response to a query are not input requirements, but options for output.

2. There is no secret component within all the OSes that mysteriously re-samples raster data as it passes from application to printer driver.  Therefore, any re-sampling occurs in the application (not likely) or in the driver (denied by Epson).

3. The Epson driver allows only certain options to be set by the application directly.  Output resolution is generally not one of them (mainly because it interacts with the media type selection).  Neither is color handling.  It expects the user to set these in the printer settings front end to the driver or will pull them from the default settings (at least on Windows).

4. If it was something as simple and obvious as the Epson driver requiring specific input resolutions, that would have been discovered about 30 minutes after the original dither algorithm appeared in 1994 in the original Stylus Color printer.

[Schewe]

4. If it was something as simple and obvious as the Epson driver requiring specific input resolutions, that would have been discovered about 30 minutes after the original dither algorithm appeared in 1994 in the original Stylus Color printer.

So, you are still doubting that the print driver reports to the OS it's "desired" resolution? While not specifically "documented" it's been well known that both Mac and Windows print drivers report their "desired" resolution to the OS. With Epson pro printers that resolution is 360PPI unless finest detail is selected. With Canon/HP it's either 300PPI or 600PPI depending on the the driver setting. In both Epson's case, depending on the media setting the reported rez can be 1440 and for Canon/HP it can be 1200PPI.

It seems you want to chase this issue down a rabbit hole...sorry, not really interested. I did my research and wrote my article and I'm pretty much done with it. Bottom line is if the input rez if under 360/300 (Epson.Canon-HP) then upsample to 360PPI. If above 360/300, upsample to 720 (Epson with finest detail) or 600PPI (for typical Canon or HP settings).

Not sure why this is so hard to test and understand.

[Bart_van_der_Wolf]

My main points were:

1. Resolutions returned by a printer in response to a query are not input requirements, but options for output.

If a specific resolution is not supported, then that limits what one can send it.
Also have a look at the following Windows GDI (if that's what's being used) parameter:

DC_ENUMRESOLUTIONS
Retrieves a list of the resolutions supported by the printer. The pOutput buffer receives an array of LONG values. For each supported resolution, the array contains a pair of LONG values that specify the x and y dimensions of the resolution, in dots per inch. The return value indicates the number of supported resolutions. If pOutput is NULL, the return value indicates the number of supported resolutions.

2. There is no secret component within all the OSes that mysteriously re-samples raster data as it passes from application to printer driver.  Therefore, any re-sampling occurs in the application (not likely) or in the driver (denied by Epson)

In the Mac OS there is functionality that is used to do the resampling and the printer driver does the dithering and weaving, in Windows OS it is probably handled by the printer driver, which may call specific DLLs we don't know. What we do know, e.g. from watching the aliasing artifacts, is that (low quality) resampling takes place.

3. The Epson driver allows only certain options to be set by the application directly.  Output resolution is generally not one of them (mainly because it interacts with the media type selection).  Neither is color handling.  It expects the user to set these in the printer settings front end to the driver or will pull them from the default settings (at least on Windows).

The various settings can be sent to the driver by applications. Qimage has been doing that for more than a decade, and if that requires indirectly modifying the media type (because there is no direct input possible) to trigger a certain functionality, then that's how it is done. Not really rocket science.

4. If it was something as simple and obvious as the Epson driver requiring specific input resolutions, that would have been discovered about 30 minutes after the original dither algorithm appeared in 1994 in the original Stylus Color printer.

And it has, and print resolution has been used since. If some applications do not utilize direct influence, but rather rely on default printer behavior (e.g. letting the driver resample to a few fixed, native, resolutions, based on other settings in the printer driver), then that's their choice. More advanced applications use their own (high quality) resampling, plus optionally output sharpening, and send that to the driver that doesn't need to resample anymore.

Cheers,
Bart

[dwswager]

I do not doubt that the Epson printer responds to the Enumerate Resolutions function.  I no longer have development environments, nor the driver development kit installed on my machines so I can't verify for myself or report here what response the printer gives.  What I do know is that the response is to provide the application with the available resolutions as choices to the user. (I might have to reload some of this stuff to actually monitor/capture the data just to see what is going on.  If I do, I will post findings).

I loaded Qimage to see how it uses this data and what it gets.  Attached are images with the Epson 3880 and 2400.  For the 3880 Qimaged offered resolution choices of 90, 180, 240 and 360.  For the 2400 it offered resolutions of 180, 240, 360 and 720.  I assume based on what I see in the print dialog that Qimage itself will re-sample to this resolution, though re sampling is not necessary.  The surprises here to me are on the 3880 with inclusion of 90 and the max of 360.

And Jeff, yes, I generally send size at 360ppi and sometimes 720ppi if I have that type of density at the size I'm printing.  Both Photoshop and ACR are set to a default of 360ppi.

[Bart_van_der_Wolf]

I loaded Qimage to see how it uses this data and what it gets.  Attached are images with the Epson 3880 and 2400.  For the 3880 Qimaged offered resolution choices of 90, 180, 240 and 360.  For the 2400 it offered resolutions of 180, 240, 360 and 720.  I assume based on what I see in the print dialog that Qimage itself will re-sample to this resolution, though re sampling is not necessary.  The surprises here to me are on the 3880 with inclusion of 90 and the max of 360.

Those are possible settings for faster output, because less resampling will have to be done by Qimage. That can be useful for poorly written printer drivers that choke on the number of mega/giga pixels it gets sent after interpolation, and huge billboard output doesn't need such high resolution at all, so one might as well speed up the preprocessing.

The (for this discussion) relevant number is the feedback as reported at the top right-hand side of the Qimage window (see attachment for one of the printers I have currently attached). The values will vary with the settings of the printer driver, e.g. output medium.

Cheers,
Bart