on 6/25/02 10:31 PM, Martin Wesley wrote: > This has always been a tricky area and is the weakness of the RGB separation > and Epson driver workflow. The application of the curves themselves in 8-bit > mode can totally trash your data. How do the PS6 and PS7 histograms compare > prior to applying a separation curve? Is the problem occurring when the mode > change is made or when the curves are applied? Hi Martin, Well, I'd like to see this explored a bit. As I don't have the Piezo driver I can't compare, but you may remember a few weeks ago I posted regarding a print I received from a friend which had the same problem (right down to dark skin - or at least light skin in shadow) but, A) the print was from a file that had no manipulation done in 8-bit mode, i.e., had a "pure" histogram, and B) was printed through the Piezo driver. Still, posterization (or something close enough to it to be called that) was present. Now, please don't misinterpret my interest. I don't know that I'm trying to prove anything per se - if the Piezo driver/workflow were to consistently prove itself better I'd just go and buy it, and I may just do that in time, (but that's not what I've seen so far). Anyway, I am interested in understanding this. Sooo, when you say it's a weakness of the RGB workflow, do you in fact mean: as opposed to the Piezo workflow; or do you mean it's the weakness of any partitioned workflow. Have you (anyone) tried the same image side by side through the two different workflows and compared? What I'd consider a side by side test would be to work the file fully in grayscale, then dupe it. Send the original to the Piezo driver to print on say EAM with that profile, convert the dupe to RGB and apply a good EAM curve to it and print through the Epson driver. Similarly, I take your point, which was that the posterization may be caused by working a file in 8-bit mode such that it wont appear to be damaged UNTIL you apply the separation curves. This too needs be side by side tested by also working the same file in the same way in 16-bit mode and printing from that, and comparing. Consider also that the Epson driver includes Microweave and/or Error Diffusion, which may (throw salt over my shoulder) help with broken files. Anyway, sorry to be so intense, but this topic has bedeviled me. While struggling with my own occasional posterization I believed all the conventional wisdoms about the sources: bad curves, overworked files, misapplied driver settings...all very properly the first things to rule out. But then what? When we've ruled out the first suspects, when a person uses a good scanner, does no 8-bit editing, uses the Piezo driver with the right profile, etc, and they still get posterization, what does it tell us? And it always seems to be in the 3/4 tones, no? I just wonder what it is in this process. I'd love for someone who has the piezo driver to make the comparison sometime. Take a file that posterizes through one workflow - any workflow - and then do the same file through the alternative workflow and see if it helps. If it does I'd say stick with the workflow that helps, until you get posterization with it. Then try the alternate workflow and see if it helps. My suspicion is that no one workflow will out work the other in all cases. I'd bet it's good to have two workflows available precisely in case you hit the wall with one, you'll have somewhere else to go. Someone mentioned it's probably the way tones in some images fall relative to the transition between ink densities. That sounds very plausible to me, and it would explain why it is common to Piezo and Epson prints, and 8-bit and 16-bit files, and some of our prints get it while others don't. The irony is (while it's certainly a blessing in other ways), all the carbon pigment inksets seem to be increasingly built around the Piezo densities, which means switching inks/workflows becomes less likely to change anything. Todd
Message
Re: [Digital BW] Re: pshop 6->7 VM (converts file differently?)
2002-06-26 by Todd Flashner
Attachments
- No local attachments were found for this message.