Pages: 1 2 [3] 4 5   Go Down

Author Topic: Epson Native Resolution (360)  (Read 22669 times)

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20630
  • Andrew Rodney
    • http://www.digitaldog.net/
Re: Epson Native Resolution (360)
« Reply #40 on: June 02, 2014, 10:24:53 am »

As a user of Perfect Resize all the way back to the genuine Fractals days, I personally don't see much difference between LR uprez to 360 and taking a image to 360 with Perfect resize and then printing from LR at 360.  I have done enough tests over the years.
LR for the price, really does a great job, let it do the work. 
That's been my experience as well. With proper capture sharpening with LR, it does a better job than PR with it's default's.
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

Jim Kasson

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2370
    • The Last Word
Re: Epson Native Resolution (360)
« Reply #41 on: June 02, 2014, 11:33:50 am »

...when we process a photo in Develop and open it in Print, then in the Print dialogue specify a resolution of say 360, can we take it that there is an LR algorithm that does the resampling?

Yes.

.And if so would you put it on par with any other resampling algorithms you've had experience with?.

Some comparison images scanned from real printer (Epson 4900) output here and here.

Jim

Schewe

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 6229
    • http:www.schewephoto.com
Re: Epson Native Resolution (360)
« Reply #42 on: June 02, 2014, 06:33:31 pm »

...can we take it that there is an LR algorithm that does the resampling?

Yes, it's a hybrid Bicubic going from normal Bicubic with little resampling to Bicubic Smoother when getting upwards of 200% (not sure what the cutoff point is but I kinda recall 200% was pure Bicubic Smoother–Eric can correct me). The advantage is that there is a smooth interpolation between the types of upsampling...

Quote
And if so would you put it on par with any other resampling algorithms you've had experience with?

Well, considering the resampling and sharpening work together, it's certainly a really good solution. The LR resampling might be beaten by some resizing algorithms...including the new Image Size Preserve Details in Photoshop CC, but I'm personally satisfied keeping all in LR for my work :~)
Logged

Schewe

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 6229
    • http:www.schewephoto.com
Re: Epson Native Resolution (360)
« Reply #43 on: June 02, 2014, 07:43:38 pm »

For what reason a printing route part utters the request for a certain input resolution (300 etc PPI>HP, Canon, 360 etc PPI Epson) I do not know for sure but Qimage Ultimate in default mode will auto-magically resample to that requested PPI any image loaded on the print page.

Which is what the OS level print pipeline seems to be doing as well. The main difference is in the case of the OS pipeline, it's a poor algorithm compared to Qimage.

We have no dispute that controlling the resampling outside of the print pipeline is a superior workflow...the app engineers (on Photoshop & Lightroom) and in the case of Epson an upper level tech say it's the OS print pipeline that's doing the resampling in a speed based (not quality based) method.

I also think we can agree that allowing the OS level pipeline to resample can actually introduce potential aliasing issues that interfere with optimal image quality.

The main take-a-way is DON'T let the print pipeline do the resampling...

At one point Bruce Fraser had advocated that users keep their images at "native resolution" and let the print pipeline send the sharpened image data to the printer. This was based on a lot of testing Bruce Fraser and I did when developing PhotoKit Sharpener. Bruce thought that native rez between 180-480 simply be left at it's own resolution (he didn't advocate downsampling ever but said upsampling was of less benefit back then).

When I worked with the Lightroom engineers to incorporate PhotoKit Sharpening into Lightroom, we determined there was a potential benefit to upsampling prior to sharpening (this was after Bruce passed away). So, the original thinking was updated to resampling to 360/300 PPI.

Later, due to debate here on LuLa, and after much testing, I determined that upsampling native resolution to 360/720 for Epson and 300/600 for Canon before output sharpening was superior. Sadly, I never had the chance to play with or test any HP printers so I can't talk about any benefits to upsampling to 1200 PPI...

Now, for the pixel peepers out there, let me reiterate; if the native resolution of your image is below 360/300, you should upsample (with you fav algorithm) and then do output sharpening before printing. If the image is above 360/300 then you should upsample to 720/600 and then sharpen.

This is noticeable in high frequency image data and areas of high contrast diagonals and circles when printed on glossy media. It's less noticeable on matte media but still noticeable on certain smooth matte media and not really noticeable on watercolor and pretty much NOT noticeable on canvas...

YMMV and you should always test these "theories" with you own images and you own printers/papers to make up your own minds.
Logged

Mark D Segal

  • Contributor
  • Sr. Member
  • *
  • Offline Offline
  • Posts: 12512
    • http://www.markdsegal.com
Re: Epson Native Resolution (360)
« Reply #44 on: June 02, 2014, 09:53:22 pm »

but I'm personally satisfied keeping all in LR for my work :~)

Me too, and anything else would have to beat it by a VISIBLE margin at normal viewing magnification on paper before I would change, but always interesting to try different stuff and see how it compares.
Logged
Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....."

Bart_van_der_Wolf

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 8913
Re: Epson Native Resolution (360)
« Reply #45 on: June 03, 2014, 07:41:27 am »

Yeah, ya know...based on the discussions I've had with the "experts" (meaning the guys from Epson and Adobe who write the code) I keep coming back to the question, if the OS level print pipeline doesn't do the resampling, why does the print driver need to report the print resolution to the OS?

Hi Jeff,

It doesn't need to, although it can be asked for by an application (e.g. Qimage by default reports that driver settings specific PPI feedback because the application sends a request), and the response can also be ignored. Depending on the choice of paper/quality set in the printer driver, one can ask the printer driver for the maximum PPI it will accept based on those settings, and avoid sending too much data.

One can send more PPIs, but then the printer driver will override it and resample again. Some printer drivers have settings for the type of resampling and other postprocessing (e.g. smoothing out jaggies) to use. So it allows to prevent needless overhead by the sending application, but it can still be sent too much data. There may be some interaction between the printer driver and the printer firmware, but the OS has little to do with it.

Quote
Epson "reports" either 360 or 720 DPI in the system...Canon/HP either 300/600 DPI. We know this and can prove that the driver reports to the OS what the desired resolution the driver wants...We know that the apps send the image data to the print pipeline without changes (unless the user does something proactive). I have been told by Epson that the driver itself doesn't do any resampling. So, what happens between the app & the driver? On Mac, potentially a lot. On Windows much less.

But, in either case, I don't think it's the application nor the print driver doing any resolution changes...I think it's the OS that takes the app data and hands it off to the driver-and makes the changes required for both resolution and color handling
.

Resampling is not the task of the OS, that's what applications and drivers are for. The OS will control the various physical input and output interfaces and the data transfer/timing/handshaking between them. The OS wouldn't know how to reduce jaggies for a specific printer hardware and features, but some printer drivers allow to select that option.

What might happen is that the printer driver can let part of the resampling be handled by the printer firmware, e.g. the 720 to 360 PPI resampling when the finest detail option is unchecked in the printer driver but 720 PPI data amounts are sent. That (averaging 2 bytes before dithering) would be a trivial operation, always the same, and can be optimized together with the dithering in a firmware operation. Firmware is usually faster than software, because it's not flexible. Other tasks, like borderless printing, requires variable amounts (a percentage) of resampling, and color management for the additional pixels, a typical task for an application or a driver (if printer manages color).

Quote
Can alternative resampling do a better job? You bet! I think we've proven that...upsampling to the reported driver resolution has show better results than letting the resolution changes happen outside of the print pipeline. Right? We agree that taking an active role in sending the correct sharpened resolution to the driver is better than not doing the post processing?

I really don't think the app nor the driver does the resampling...I think it's a crude resampling done by the print pipeline–and I think we agree that it's less than optimal, right?

Specific targeted post-processing of the pixels that get delivered to the pipeline definitely allows better output quality. No discussion about that.

Cheers,
Bart
Logged
== If you do what you did, you'll get what you got. ==

Bart_van_der_Wolf

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 8913
Re: Epson Native Resolution (360)
« Reply #46 on: June 03, 2014, 07:50:58 am »

As a user of Perfect Resize all the way back to the genuine Fractals days, I personally don't see much difference between LR uprez to 360 and taking a image to 360 with Perfect resize and then printing from LR at 360.  I have done enough tests over the years.

Hi Paul,

But have you tested upsampling to 720PPI, with GF / Perfect Resize doing the edge preserving upsampling, and post upsampling sharpening or Detail enhancement with a suitable plugin?  And have you tried with the Finest Detail option checked? Otherwise the printer driver will force the resolution up/down to 360 PPI exactly, with a poor algorithm, without output sharpening after the resampling.

In my experience, people tend to sell themselves short on quality because they do not use proper sharpening + detail booting at the output resolution, and one can do that to a higher degree at 720 PPI on Epsons (or 600 PPI for Canon/HP).

Cheers,
Bart
Logged
== If you do what you did, you'll get what you got. ==

Bart_van_der_Wolf

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 8913
Re: Epson Native Resolution (360)
« Reply #47 on: June 03, 2014, 07:59:02 am »

Yes, it's a hybrid Bicubic going from normal Bicubic with little resampling to Bicubic Smoother when getting upwards of 200% (not sure what the cutoff point is but I kinda recall 200% was pure Bicubic Smoother–Eric can correct me). The advantage is that there is a smooth interpolation between the types of upsampling...

Hi Jeff,

It would be nice if Eric could explain a bit more about that, because as far as I can see, LR uses something quite different from Bi-Cubic / Smoother. But I understand that he is not entirely free to give away too much info about the inner workings. It's just that I see something different going on, without the halo/blocking creation that would be a tell-tale sign of a simple non-adaptive filter like a variant of bicubic.

Cheers,
Bart
Logged
== If you do what you did, you'll get what you got. ==

Paul2660

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 4066
    • Photos of Arkansas
Re: Epson Native Resolution (360)
« Reply #48 on: June 03, 2014, 08:17:08 am »

Hi Bart:

To me the most important part is understanding what is going on with a driver driven print, or LR and understanding that 360 is the correct number for larger prints, 720 smaller.   

To be honest, if you take an average 60MP 3 part stitch or a 3 part D800 Stitch to 720, your file will be so huge in 16 bit mode, that to me it just becomes pointless to work with it.  But yes I have tried pretty much every angle of Perfect resize I can think of, but for my work, I never to to 720, always at 360.  I have plenty of ram, and processor, but these files just get huge.  Not to mention, Perfect resize will take 10 minutes to process it out.  I never have figured out what it's doing in all that time (besides making a person think "wow, it's sure taking a long time so the results should look great").

Most times, now my work is at 300 dpi, output from C1 or LR, and I will leave the image in that dpi throughout the work process, I then do the final output size in the LR print module to 360 ppi and let it do the final sharpening.  I still will often use Focus Magic as an in between step or it with a combination of one of the photokit creative sharpening levels. 

For me it's all about get to the final results with the least amount of steps, and after reading Jeff's book, and spending time with my printers, I feel you can see a difference in the LR prints.  That plus I can still tweak an image with the LR develop toolset, which I often do.  I have used LR for years, but only really started to print from it about 6 months ago, but only recently started outputting everything to 360.  Plus the fact that LR has incorporated the Photokit sharpening routines, in both the Develop and print module is to a great asset, as I have always been a big fan of the Photokit plugin.

As to the print from the driver with finest detail checked, even Epson is a bit vague on this, as they imply you should only use it for images with text or wording.  I have tried it and agree it makes a bit of difference to the positive but it can also add some strange artifacts.  The other big issue can be with printing solid areas, skies, water etc, where when this option is checked the driver seems to want to add more detail, when tends to look like noise or something worse. 

I am 100% windows, so the Mac print flow may be totally different with Epson and the print driver, I know they allow 16bit with Mac, not Win. 

There is no "right" answer, but as Jeff stated, you have to find a method that works for you and learn it the best you can.  On my larger prints, 40 x 60 and 36 x 72, this method is giving me some excellent results. 

Paul

Logged
Paul Caldwell
Little Rock, Arkansas U.S.
www.photosofarkansas.com

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20630
  • Andrew Rodney
    • http://www.digitaldog.net/
Re: Epson Native Resolution (360)
« Reply #49 on: June 03, 2014, 10:44:41 am »

Me too, and anything else would have to beat it by a VISIBLE margin at normal viewing magnification on paper before I would change, but always interesting to try different stuff and see how it compares.
My problem is with the tests I've done, I see no visual difference at Photographers Viewing Distance (defined by Bruce Fraser as based on the size of one's nose just about to touch the print itself). Even with a loupe, it's a struggle hence, I'm not convinced the differences are worth shooting for. Now maybe it's the printer (3880) and paper (luster or glossy) or the image (Roman 16's) or their 'native' resolution (about 200 and change to an 8x11).
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

Bart_van_der_Wolf

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 8913
Re: Epson Native Resolution (360)
« Reply #50 on: June 03, 2014, 11:12:38 am »

My problem is with the tests I've done, I see no visual difference at Photographers Viewing Distance (defined by Bruce Fraser as based on the size of one's nose just about to touch the print itself). Even with a loupe, it's a struggle hence, I'm not convinced the differences are worth shooting for. Now maybe it's the printer (3880) and paper (luster or glossy) or the image (Roman 16's) or their 'native' resolution (about 200 and change to an 8x11).

Hi Andrew,

Could it be due the output sharpening? At Photographers Viewing Distance it should be easy to see, from a larger distance only if the output sharpening was (additionally) tuned for that.

Cheers,
Bart
Logged
== If you do what you did, you'll get what you got. ==

JRSmit

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 922
    • Jan R. Smit Fine Art Printing Specialist
Re: Epson Native Resolution (360)
« Reply #51 on: June 03, 2014, 01:38:23 pm »

When the image at print size has more then 360 pixel per inch going to 720ppi AND finedetails =on it is visible, definitely at "nose" distance, also at normal viewing distance there is something different.
It is as if the image has more clarity, more depth, more spatial effect. This is true even on smooth fine art papers.
I did a test with the same image printed on different fine art papers of A4 with different settings and corresponding printer profiles. As an additional outcome the 360 vs 720 ppi& fd=on was visible to those asked to look at the prints and describe the differences they observed.
I am on Windows 7, use an Epson4900, use LR for development and print and i am extremely happy with this set up. Tried a 3880 a while ago and found it to be less smooth compared to the 4900.
Logged
Fine art photography: janrsmit.com
Fine Art Printing Specialist: www.fineartprintingspecialist.nl


Jan R. Smit

Mark D Segal

  • Contributor
  • Sr. Member
  • *
  • Offline Offline
  • Posts: 12512
    • http://www.markdsegal.com
Re: Epson Native Resolution (360)
« Reply #52 on: June 04, 2014, 01:53:31 am »

In my effort to further pursue the question of where re-sampling occurs to meet the "native resolution" of the printer and where best to do the re-sampling - at least for Epson professional printers, I have received the following information from a totally reliable source, who will have to remain unidentified. It is this:

<Basically, the answer is “it depends”.  It depends on whether you’re using Windows or OS X.
On OS X, the image is rendered using Quartz Compositor which has a unique interpolation algorithm similar to Bi-Cubic or Bi-Linear, so the printer driver doesn’t need to worry about the image resolution.
For Windows, the image is rendered by an Epson-proprietary renderer and it is based on the Nearest-Neighbour algorithm.
So OS X will do a nicer job than Windows, but in all cases you are better off getting it right before you send it – i.e. with LightRoom or PS or Qimage etc., as has already been mentioned. This is also why you have different options such as Coarse Rendering and Edge Smoothing in Windows, but not in OS X.>

Logged
Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....."

Schewe

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 6229
    • http:www.schewephoto.com
Re: Epson Native Resolution (360)
« Reply #53 on: June 04, 2014, 03:30:13 am »

That pretty much follows the thinking I was informed of...it "depends" and "it's complicated".

:~)
Logged

Bart_van_der_Wolf

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 8913
Re: Epson Native Resolution (360)
« Reply #54 on: June 04, 2014, 04:01:22 am »

In my effort to further pursue the question of where re-sampling occurs to meet the "native resolution" of the printer and where best to do the re-sampling - at least for Epson professional printers, I have received the following information from a totally reliable source, who will have to remain unidentified. It is this:

<Basically, the answer is “it depends”.  It depends on whether you’re using Windows or OS X.
On OS X, the image is rendered using Quartz Compositor which has a unique interpolation algorithm similar to Bi-Cubic or Bi-Linear, so the printer driver doesn’t need to worry about the image resolution.

Hi Mark,

Thanks for the info.

However, from what I can find, the Quartz Compositor takes its rasterized input(s) from various applications, composites all image data sources kept in Backing Stores, and outputs a single composited image to the Graphics card. "Quartz is the umbrella term for the Mac OS X display layer through which all drawing and screen display is done."

So it seems that possibly the printer driver sends a raster image to the QC which then sends a composited image to the display card.

How does the print pipeline fit into that scheme?

Quote
For Windows, the image is rendered by an Epson-proprietary renderer and it is based on the Nearest-Neighbour algorithm.

Which then still leaves it an open question for other printer drivers ...

Quote
So OS X will do a nicer job than Windows, ...

QED

Quote
... but in all cases you are better off getting it right before you send it – i.e. with LightRoom or PS or Qimage etc., as has already been mentioned. This is also why you have different options such as Coarse Rendering and Edge Smoothing in Windows, but not in OS X.>

Yes, preprocessing (re-sampling and subsequent detail enhancement and output sharpening) at the required native printer driver resolution will obviously allow more control and potentially better quality output.

Cheers,
Bart
Logged
== If you do what you did, you'll get what you got. ==

Mark D Segal

  • Contributor
  • Sr. Member
  • *
  • Offline Offline
  • Posts: 12512
    • http://www.markdsegal.com
Re: Epson Native Resolution (360)
« Reply #55 on: June 04, 2014, 05:07:20 am »

The info you re linking to is nine years old. Some things may have changed since then. No info on other printers; my source knows Epson printers - thoroughly.
Logged
Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....."

Bart_van_der_Wolf

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 8913
Re: Epson Native Resolution (360)
« Reply #56 on: June 04, 2014, 09:06:05 am »

The info you re linking to is nine years old. Some things may have changed since then. No info on other printers; my source knows Epson printers - thoroughly.

Hi Mark,

I have to assume your source doesn't know the Apple OS as well as Epson printers. No problem, one cannot know everything.

Doing some more research myself, it seems possible that a Printer driver for OS X uses some API functionality that's available outside the OS kernel, in particular Quartz 2D (not Compositor, which is display oriented).

That means that a part of a graphics library may be utilized for some calculations, but it will be called by the printer driver which also instructs to direct the output to the printer. It's not a functionality of the OS, but a software component that is borrowed by an application or driver for executing a task. I have not found any details about available algorithms yet.

Cheers,
Bart
Logged
== If you do what you did, you'll get what you got. ==

Mark D Segal

  • Contributor
  • Sr. Member
  • *
  • Offline Offline
  • Posts: 12512
    • http://www.markdsegal.com
Re: Epson Native Resolution (360)
« Reply #57 on: June 04, 2014, 10:33:15 am »

Hi Mark,

I have to assume your source doesn't know the Apple OS as well as Epson printers. No problem, one cannot know everything.


Risky assumption :-)
Logged
Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....."

Bart_van_der_Wolf

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 8913
Re: Epson Native Resolution (360)
« Reply #58 on: June 04, 2014, 10:51:41 am »

Risky assumption :-)

Best I can do, based on the limited information at hand ...

Cheers,
Bart
Logged
== If you do what you did, you'll get what you got. ==

Mark D Segal

  • Contributor
  • Sr. Member
  • *
  • Offline Offline
  • Posts: 12512
    • http://www.markdsegal.com
Re: Epson Native Resolution (360)
« Reply #59 on: June 05, 2014, 12:10:59 am »

Best I can do, based on the limited information at hand ...

Cheers,
Bart

Understood Bart, but you made a good point and a useful contribution, because on the basis of your intellectual curiosity I went back to "source" and got the following response:

<It is not Quartz “Composer” but Quartz “2D” - rasterizes drawing objects from the application and provides to printer driver. http://en.wikipedia.org/wiki/Quartz_2D>

Hope that helps clear-up the matter.

Cheers,

Mark

 
Logged
Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....."
Pages: 1 2 [3] 4 5   Go Up