Ad
Ad
Ad
Pages: « 1 2 [3]   Bottom of Page
Print
Author Topic: Epson x800 print softness  (Read 10501 times)
Wayne Fox
Sr. Member
****
Offline Offline

Posts: 2880



WWW
« Reply #40 on: December 11, 2007, 03:02:29 PM »
ReplyReply

Quote
It's not clear from your post if you're actually using the jpeg attached to your post for your tests?  Given that the attached jpeg is a roughly 4"x6" print at 360ppi, I would think that the results would be highly dependent on how it was up-sized if making a large print.
Thanks,
-jk
[a href=\"index.php?act=findpost&pid=159925\"][{POST_SNAPBACK}][/a]

The original full version of that image can be downloaded from Bill Atkinson's public folder, it's called lab test page.tif, and is a 5520x6960 image.

That's the file I used when printing tests.  There is enough small detail in several areas of the prints, including catchlights as well as text to clearly see when the problem is occurs.
Logged

ares
Newbie
*
Offline Offline

Posts: 23


« Reply #41 on: December 11, 2007, 03:04:56 PM »
ReplyReply

Quote
It's not clear from your post if you're actually using the jpeg attached to your post for your tests?  Given that the attached jpeg is a roughly 4"x6" print at 360ppi, I would think that the results would be highly dependent on how it was up-sized if making a large print.

I'm using a TIFF version of the image. I've uploaded a jpg conversion because I wasn't able to upload the original TIFF on this forum.

And I'm NOT resizing it. I'm printing it exactly as it is. It's a small image because there is no need to waste a big amount of paper and ink to do the testing. Just print it, choosing the right color profile for the paper you're using, twice: the first time on a default paper size (for example A4), the second time on a custom paper size created by yourself. There should be no difference, and indeed when printing under Windows there is no difference at all. Under OSX the results are the ones I've already reported.
Logged
Wayne Fox
Sr. Member
****
Offline Offline

Posts: 2880



WWW
« Reply #42 on: December 11, 2007, 03:05:28 PM »
ReplyReply

Quote
The one thing I have _NOT_ seen mentioned is what starting page size was selected before going into the custom page size...if one started on a standard page size that represented a borderless printing and made a custom page size from that, I could see where the driver would be doing on the fly resize because that's what borderless page sizes do.
[a href=\"index.php?act=findpost&pid=159900\"][{POST_SNAPBACK}][/a]

I suppose this is possible.  I"m not sure why, since it seems all a custom paper size should do is specify the size of the paper and the size of the printable area within the paper.  It seems this should be an OS function, yet the problem seems to only affect Epson's x800 series printers (excluding the 3800).
Logged

Mark D Segal
Contributor
Sr. Member
*
Offline Offline

Posts: 6968


WWW
« Reply #43 on: December 11, 2007, 03:10:31 PM »
ReplyReply

And only Mac - not Windows.
Logged

Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....." http://www.luminous-landscape.com/reviews/film/scanning_workflows_with_silverfast_8.shtml
Wayne Fox
Sr. Member
****
Offline Offline

Posts: 2880



WWW
« Reply #44 on: December 12, 2007, 04:45:05 PM »
ReplyReply

Final test (for me anyway)

Last night I used the Lab Test Page.tif and created a smaller version by cropping and also copied some of the images with more detail so they would be on the page multiple times.  I resized the image without interpolation to 360 dpi, and printed at native size 8 test prints on 16" Epson Prem. Glossy paper (roll).

Test 1 - Created a new custom page size of 16x12.5 inches with .5 inch manual borders on all 4 sides.

Test 2- Modified the previous custom page size, using the pop-up menu to select the printers default border size (which is 0 for the 9800).

Test 3 - Created a new custom page size of 16x13", with default border sizes (again which is 0).

Test 4 - Modified that custom page to have .5 inch borders all the way around.

All 4 of those tests required the image to be clipped, so to insure clipping had no impact, I cropped the image to fit within the page,  and repeated the exact same 4 tests.  All in all I created 4 custom pages, and modifed the borders of those 4 pages.

This is using Mac OS X Leopard and the new beta drivers available from Epson.

Although in a previous test I was able to see a difference similar to the OP, there is no visible difference in any of these 8 tests to the eye (even with my reading glasses on).  I also couldn't find a significant difference using a 10x loupe.  If I scanned the images at 1200dpi and compared them, I could see areas that appeared very slightly sharper when comparing a custom border to a 0" border - but this occurred on both prints as compared to each other, rather than one print being sharper in all areas, and even at this resolution those differences may actually have just been me looking too hard.

At this point, at least under Leopard with the new beta drivers, I cannot duplicate or cause a soft print due to a custom page setup. The original test I did which did have an obvious difference I believe was done with the prior version of the 9800 driver.

Curious if the OP has tried using Leopard and the new beta drivers, and what the results might be.
« Last Edit: December 12, 2007, 04:46:26 PM by Wayne Fox » Logged

gkroeger
Jr. Member
**
Offline Offline

Posts: 51


« Reply #45 on: December 13, 2007, 10:59:59 AM »
ReplyReply

I am running Leopard (10.5.1) with the old drivers and a 7800.  I will run some tests tonight and then install the new beta driver and run the test again.
Logged
ares
Newbie
*
Offline Offline

Posts: 23


« Reply #46 on: December 13, 2007, 04:36:05 PM »
ReplyReply

I've tested the beta drivers as soon as they were released, with the usual result. Just for fun, I've done a bit of code and data analysis (in my former life I was a software engineer) and now I can confirm that the data sent to the printer is different when printing on custom rather than default paper sizes. This does NOT happen under Windows. Note that I'm no longer talking about visually inspecting the prints, I'm talking about examining the raw data stream. Since I have no more time to spare and Epson support has been less than non-existent, I've set up a Windows XP machine, connected to my studio network, and I'm now printing from it. This also solves the issue of unwanted color shifts, wich was never officially acknowleged nor addressed (the usual workaround was to use ColorSync to change the printer default color profile to Generic RGB).

I was thinking about buying an 11880, but I will do so only after personally testing it by printing my usual image under OSX and then examining the prints. Hoping that at least the color shifts issue has really been solved.
Logged
Mark D Segal
Contributor
Sr. Member
*
Offline Offline

Posts: 6968


WWW
« Reply #47 on: December 13, 2007, 06:38:04 PM »
ReplyReply

Ares, this I believe is the first time you mention colour shifts. I have not heard complaints about that, and I know quite a few Mac OSX users operating Epson professional printers without such complaints (there are complaints about the unreliable stickiness of printer settings under OSX, and perhaps those kind of glitches are causing the colour shifts - as you most likely know, when printing with Mac OSX you are best advised to verify the integrity of all the settings at least twice before pressing the print button.

The aspect of it that is most troubling is your comments on support from Epson. I don't know which of their worldwide branches you are dealing with, but here in North America they're pretty good. They virtually closed down their Canadian operation and they provide Canada support from the USA. So far the track record on this side of the Atlantic it appears that on the whole their Pro-Graphics people are responsive and helpful. One gets the impression over here at least that with growing competition for the machines, they want their customers to know they are supported. If this state of mind is not being replicated elsewhere it is something that Epson America and Epson HQ in Japan should be told about.
Logged

Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....." http://www.luminous-landscape.com/reviews/film/scanning_workflows_with_silverfast_8.shtml
ares
Newbie
*
Offline Offline

Posts: 23


« Reply #48 on: December 14, 2007, 01:35:49 AM »
ReplyReply

Quote
Ares, this I believe is the first time you mention colour shifts. I have not heard complaints about that, and I know quite a few Mac OSX users operating Epson professional printers without such complaints

It has been mentioned even on this forum some time ago:

http://luminous-landscape.com/forum/index....hl=salmon+color

It's called "salmon color" because the most noticeable shift happens in yellow/orange region. The easiest way to discover if you are affected is to print the first A4 sheet of Bill Atkinson's 1728 target. Since the color patches are sequential, an unwanted shift is immediately recognizable. I've had this problem and solved it by the workaround I've already described. Never heard a word from Epson about it.

Now, the default color profile for Epson LFP has always been "Standard". In ColorSync this is the printer profile with the blue dot next to it.
But with Leopard drivers the default profile has changed to PLPP250. Why? Because this solves the issue? Or because this masks the issue, since PLPP250 is one of the profiles with the larger gamut? It is believed that the color shift is due to an unwanted profile conversion of the already prematched data, so converting to a profile with a larger gamut would have less impact on color appearance.

Quote
The aspect of it that is most troubling is your comments on support from Epson. I don't know which of their worldwide branches you are dealing with, but here in North America they're pretty good. They virtually closed down their Canadian operation and

Maybe I'll try to contact them to see if they are interested in my findings.


Just to clarify: I have NOTHING against Epson printers, or Epson itself. I've spent thousand of euros on Epson LFPs and I've been extremely satisfied. I've printed on almost every paper and every canvas on the market, never a problem, the straight paper path is wonderful, never had issues of banding or head strikes, output quality has been (and is) always impeccable.
It's only that Epson support for OSX is lacking, and, at least here in Europe, they are not interested at all in improving it. Just another example: the version of LFP Remote Panel utility available on Epson european web sites is still the original 1.0b wich doesn't work neither with Leopard drivers nor with the latest Tiger drivers. I've had to download the newer version available from Epson USA site. Unfortunately this version doesn't work with Leopard drivers, so for now I have to use the Windows version instead. Note that on european sites the Leopard driver is not a beta one, is presented as final (version 6.11), so we have the driver and not a working LFP Remote Utility. And again, no mention of the problem by Epson. One could waste hours trying to figure out why LFP Remote Utility doesn't communicate with the printer.
« Last Edit: December 14, 2007, 01:59:06 AM by ares » Logged
Wayne Fox
Sr. Member
****
Offline Offline

Posts: 2880



WWW
« Reply #49 on: December 14, 2007, 02:35:37 AM »
ReplyReply

Quote
I've tested the beta drivers as soon as they were released, with the usual result. Just for fun, I've done a bit of code and data analysis (in my former life I was a software engineer) and now I can confirm that the data sent to the printer is different when printing on custom rather than default paper sizes. This does NOT happen under Windows. Note that I'm no longer talking about visually inspecting the prints, I'm talking about examining the raw data stream.

[a href=\"index.php?act=findpost&pid=160482\"][{POST_SNAPBACK}][/a]

So you examined the raw data stream under both platforms?  It would seem the streams would be different to some point, to account for various border sizes etc. but that might not affect the actual printed data.  I am curious how you "intercepted" the data to examine it.

So your saying your work around of 0 borders doesn't work now?
Logged

Mark D Segal
Contributor
Sr. Member
*
Offline Offline

Posts: 6968


WWW
« Reply #50 on: December 14, 2007, 07:53:40 AM »
ReplyReply

Quote
It has been mentioned even on this forum some time ago:

http://luminous-landscape.com/forum/index....hl=salmon+color

It's called "salmon color" because the most noticeable shift happens in yellow/orange region. The easiest way to discover if you are affected is to print the first A4 sheet of Bill Atkinson's 1728 target. Since the color patches are sequential, an unwanted shift is immediately recognizable. I've had this problem and solved it by the workaround I've already described. Never heard a word from Epson about it.

Now, the default color profile for Epson LFP has always been "Standard". In ColorSync this is the printer profile with the blue dot next to it.
But with Leopard drivers the default profile has changed to PLPP250. Why? Because this solves the issue? Or because this masks the issue, since PLPP250 is one of the profiles with the larger gamut? It is believed that the color shift is due to an unwanted profile conversion of the already prematched data, so converting to a profile with a larger gamut would have less impact on color appearance.
Maybe I'll try to contact them to see if they are interested in my findings.
Just to clarify: I have NOTHING against Epson printers, or Epson itself. I've spent thousand of euros on Epson LFPs and I've been extremely satisfied. I've printed on almost every paper and every canvas on the market, never a problem, the straight paper path is wonderful, never had issues of banding or head strikes, output quality has been (and is) always impeccable.
It's only that Epson support for OSX is lacking, and, at least here in Europe, they are not interested at all in improving it. Just another example: the version of LFP Remote Panel utility available on Epson european web sites is still the original 1.0b wich doesn't work neither with Leopard drivers nor with the latest Tiger drivers. I've had to download the newer version available from Epson USA site. Unfortunately this version doesn't work with Leopard drivers, so for now I have to use the Windows version instead. Note that on european sites the Leopard driver is not a beta one, is presented as final (version 6.11), so we have the driver and not a working LFP Remote Utility. And again, no mention of the problem by Epson. One could waste hours trying to figure out why LFP Remote Utility doesn't communicate with the printer.
[a href=\"index.php?act=findpost&pid=160582\"][{POST_SNAPBACK}][/a]

Thanks for bringing that thread to my attention. I would have ignored because I use Windows XP and have never had a colour management problem on any Epson printer or using any version of the Epson driver since the launch of the 4000 printer.

I don't know how much of a mandate or freedom of action Epson in Europe has to actually fix problems related to operating systems. I suspect there is most likely more analytic infrastructure in EPson USA and certainly Epson Japan for dealing with this stuff. But the very least they should do is take note of the issues, forward them to where they would be evaluated, and give you appropriate feedback. It really shouldn't be necessary to run two computer systems to achieve a satisfactory print.
Logged

Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....." http://www.luminous-landscape.com/reviews/film/scanning_workflows_with_silverfast_8.shtml
Pages: « 1 2 [3]   Top of Page
Print
Jump to:  

Ad
Ad
Ad