Let's see what your page setup and print options look like.
US C 17x22 in (Manual - Rear)
Pages to Pring: All Pages
Page Order: Automatic
Scale to fit paper size CHECKED
Destination Paper Size: Suggested Paper: US C 17x22 in (Manual - Rear)
Page Setup Manual - Rear
MediaType: Exhibition Fiber Paper [ouch! $3.40 per sheet]
16 Bit Output CHECKED
Output Resolution: Superfine - 1440 dpi
Nothing else checked. e.g. not High Speed.
I just tried a different photo, and it worked OK. This was with the Camera Raw Cache at 50G.
My Mac mini has 8G of memory. When I first started using LR it had 2G, but one of the LR updates needed at least 4G, so I upgraded the memory.
Hope you have some ideas about this!
You probably don't need to be using 16 bit output, that could be some of the issue. The Camera Raw Cache won't make much difference here. 8GB should be fine
I'm using 16 bit output because that is recommended for highest quality by Julieanne Kost and others. I've used 16 bit output for the same image with 8.5"x11" prints with no problems.
And Lightroom should be able to handle this image!
With a 3880, compromise shouldn't be necessary. The workarounds get results, perhaps only with loss of time and not loss of quality.
I tried a few more things.
A different image printed out normally through LR on the C paper.
I double-checked on the first image that I tried. This has trees with plenty of leaves in the top half (high "information content")
But that had the same problem as before with the normal process, and settings as above, with the cache at 50G.
So you're right that the larger cache didn't solve the problem.
I tried two things:
Saved as TIFF instead of Jpeg. The TIFF file was 84.9M vs. 11.3 for the Jpeg, so I wanted to see if it posed memory problems.
Worked OK for the TIFF printed from Preview, as it had for the Jpeg. With LR closed. I suppose that conserved system memory, but I'm not sure exactly how printing is implemented in LR.
Then I tried another experiment. From the LR Print module, with settings as above, I saved a PDF. This is a branch. Earlier I had the corrupted print problem when I displayed a PDF and then printed from that, with LR still open. That didn't work. In the new experiment, I closed LR and everything else, and restarted the computer.
The saved PDF file is rather large - 3.52GB. Nevertheless, I opened it with Adobe Reader, used the OS Page and Printer setups as above, and was able to make a good print.
If it could be done this way, it should be possilbe for LR to do the same thing while open. Right?
To evaluate your suggestion, Sean, I would need to do something like printing the other image with 8 bit output, in order to determine whether I can see a difference in quality from the version that printed normally with 16 bit output.
I've been a persistent engineer/mathematician, and don't rest until I've solved a problem!
It would be nice if Adobe had a customer service line for dealing with this kind of problem. I'm a computer/image processing scientist, but not an Adobe programmer!
Thanks for your suggestion
This appears to be a bug in the LR 4.4 software, and I guess it is something like this, based on my experience as a C/C++ programmer:
The problem occurs when a complex image is behing handled by the print module. Here I'm assuming that some kind of lossless compression is being used.
It appears that a fixed space is allocated for the image, based on the print size and bit depth. (thus a different bit depth might not work much better, anyway, even if one didn't care about the compromised quality). This space would work for most images, but those beyond a certain threshold of information content would require too much space. In this case, the saved print image would be smaller than the printed size. When the data is sent to the printer, and the end of the saved image is reached, the first 0.5" of the image is sent repeatedly.
An expert on the internet pointed out that the Epson 3880 stores one line at a time.
Another clue: cables of length greater than 10' might cause troubles. Mine is 8', but the longer cable would have a slightly longer transmission time, as well as more chances for picking up interference.
If my first scenario were correct, it would explain why an image with lower information content, thus smaller after lossless compression, would print correctly, but an image that is larger under lossless compression would not.
I'm not sure whether or not this is a good explanation. If it were, the solution would be to perform a check of the validity of the lossless compression. If it were invalid, a message could be provided that the image could not be printed, thus saving expensive paper. Alternatively, a better dynamic allocation of the print image could be used. There might also be issues with timing the output to the printer, but a pause could be made if it were necessary for the computer to catch up with the data flow.
I believe I could solve this problem if I had access to the source code. But that should be Adobe's job.
It does not appear that LR 4.4 software is capable of doing this correctly, or even of delivering an error message when it can't do the job that it is supposed to be able to do.
Adobe, are you listening?!
This being a user forum, Adobe only happen by from time to time.
If what you're saying is true, then you'll get the problem with any paper size with your image; have you tried other smaller (cheaper) paper to test in both 8 and 16 bit?