Yahoo Groups archive

Digital BW, The Print

Index last updated: 2026-04-28 22:56 UTC

Message

Re: [Digital BW] Re: pshop 6->7 VM (converts file differently?)

2002-06-26 by Todd Flashner

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

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.