Digital BW, The Print

Has anyone noticed when using Paul's inks on a PC (Win98 in my case) 
with standard VM ink, and Paul's workflow curves, on an 1280 if you 
now get posterization in 3/4 tones when printed in pshop 7? That 
wasn't there using pshop 6?

Just investigating something at the moment, and I need to eliminate 
variables so I'm just asking questions right now, not suggesting 
possibilities<g>
Jim H.

--- In DigitalBlackandWhiteThePrint@y..., "jimhayes361" 
<jimhayes@j...> wrote:
> Has anyone noticed when using Paul's inks on a PC (Win98 in my case) 
> with standard VM ink, and Paul's workflow curves, on an 1280 if you 
> now get posterization in 3/4 tones when printed in pshop 7? That 
> wasn't there using pshop 6?
> 
> Just investigating something at the moment, and I need to eliminate 
> variables so I'm just asking questions right now, not suggesting 
> possibilities<g>
> Jim H.

I need to add something:

I just took the same file of a very dark subject and ran it through 
Paul's workflow with all color settings/ color spaces/options, and 
with the same order of steps converting to rgb and using the same mw 
curve for 2880 dpi.

So with everything else being exactly the same, I call up the 
histogram after preparing image for print in both photoshop 6 and 7 
(on same machine):




Pshp 6| mean=46.83 SD=71.55 median=10

pshop 7| mean=45.57 SD=72.27  median=8

It's repeatable. Although the differences are small, it means what is 
sent to printer is different data whether ver 6 or 7 is used. I would 
guess this is due to either a change in the way layers are merged when 
converting to RGB, a change in the way the data is converted from 
gamma 2.2 to sRGB, or a change in the way Paul's curve is applied as 
an adjustment layer.

I should be sending a real print (ver 6 vs 7) to the printer as a 
final step to test this, and will do so in a few days. At the moment I 
have OEM ink in my 1280.

Any comments on this? I really don't know what to make of it yet, 
maybe it's not signifigant.
Jim H.

on 6/25/02 1:37 PM, jimhayes361 wrote:

> I would 
> guess this is due to either a change in the way layers are merged when
> converting to RGB, a change in the way the data is converted from
> gamma 2.2 to sRGB, or a change in the way Paul's curve is applied as
> an adjustment layer.

I don't have PS 7 so I don't know if the Color Settings dialog is the same,
but... 

in the Advanced section, are you using the same Conversion Engine (Adobe Ace
is probably your best choice, though perhaps that is what got tweaked and
upgraded between versions. Try Apple CMM with both versions and compare),
Intent, Black Point Compensation, and Dither, settings? If any of these
settings are different between versions you will get different conversions
between modes.

Todd

--- In DigitalBlackandWhiteThePrint@y..., Todd Flashner <tflash@e...> 
wrote:
> on 6/25/02 1:37 PM, jimhayes361 wrote:
> 
> > I would 
> > guess this is due to either a change in the way layers are merged 
when
> > converting to RGB, a change in the way the data is converted from
> > gamma 2.2 to sRGB, or a change in the way Paul's curve is applied 
as
> > an adjustment layer.
> 
> I don't have PS 7 so I don't know if the Color Settings dialog is 
the same,
> but... 
> 
> in the Advanced section, are you using the same Conversion Engine 
(Adobe Ace
> is probably your best choice, though perhaps that is what got 
tweaked and
> upgraded between versions. Try Apple CMM with both versions and 
compare),
> Intent, Black Point Compensation, and Dither, settings? If any of 
these
> settings are different between versions you will get different 
conversions
> between modes.
> 
> Todd


Todd,

The complete color settings advanced  dialouge is IDENtical for both 
ver 6 and ver 7 when I did the histogram test. I used Adobe ace 
relative colometric, with black point and dither boxes checked. I 
can't try Apple CMM, I don't seem to have it as an option on Windows, 
all I could try is Microsoft ICM- I figured it would just buy me more 
trouble knowing how great ms is at color matching<g>.

The workflow, selections in all dialog boxes, presets, order of 
workflow, file, curve loaded, etc etc...was done identically for both 
ver 6 and 7 AFAIK. And the same done mutiple times through the 
workflow. But please, I welcome anyone checking me out on this so that 
I can resolve my posterization problem.

The steps I did after making sure that color settings ("pshop 5 
defaults" settings), etc were identical:
1) Open file up, disgarding mismatched profile. Image is labelled 
"untagged grey". I could assign profile of gamma 2.2 to it, but it 
just gives me the same  histogram results.

2) convert to rgb mode. Dialog asks if I wantt to merge layers. I 
choose "yes". sRGB appears as the new color space for file.

3) Add adjust curves layer- in curves dialog I load Paul's mw 2880 
curve for PC. I also checked the normal 1440 (mw for PC 1280) curve 
that most people use  and also get a change from 6 to 7.

4) select background layer and view histogram. Note down mean, SD and 
median.

5) close down pshop and open up the other version and repeat steps. 
There is a slight discrepancy in all three values, but most notable in 
the median.
Jim H.

Jim

It's certainly over my head. I'd say take it to the CM gurus at:

http://lists.apple.com/mailman/listinfo/colorsync-users

(to join the Colorsync list)

Don't be put off by it being an Apple list, it's for all color management,
which conversions certainly fall under.

Todd

> Todd,
> 
> The complete color settings advanced  dialouge is IDENtical for both
> ver 6 and ver 7 when I did the histogram test. I used Adobe ace
> relative colometric, with black point and dither boxes checked. I
> can't try Apple CMM, I don't seem to have it as an option on Windows,
> all I could try is Microsoft ICM- I figured it would just buy me more
> trouble knowing how great ms is at color matching<g>.
> 
> The workflow, selections in all dialog boxes, presets, order of
> workflow, file, curve loaded, etc etc...was done identically for both
> ver 6 and 7 AFAIK. And the same done mutiple times through the
> workflow. But please, I welcome anyone checking me out on this so that
> I can resolve my posterization problem.
> 
> The steps I did after making sure that color settings ("pshop 5
> defaults" settings), etc were identical:
> 1) Open file up, disgarding mismatched profile. Image is labelled
> "untagged grey". I could assign profile of gamma 2.2 to it, but it
> just gives me the same  histogram results.
> 
> 2) convert to rgb mode. Dialog asks if I wantt to merge layers. I
> choose "yes". sRGB appears as the new color space for file.
> 
> 3) Add adjust curves layer- in curves dialog I load Paul's mw 2880
> curve for PC. I also checked the normal 1440 (mw for PC 1280) curve
> that most people use  and also get a change from 6 to 7.
> 
> 4) select background layer and view histogram. Note down mean, SD and
> median.
> 
> 5) close down pshop and open up the other version and repeat steps.
> There is a slight discrepancy in all three values, but most notable in
> the median.
> Jim H.  
> 
> 
> 
> 
> 
> Please visit the Group Homepage to check the Files, Bookmarks, Polls and other
> resources as they are often being updated. The page is at:
> 
> http://groups.yahoo.com/group/DigitalBlackandWhiteThePrint
> 
> Please follow these basic guidelines:
> - Include your full name with your message.
> - Include the address of your website, if you have one.
> - As threads develop, trim off excess portions of earlier messages to keep
> them short.
> - As the topic of a thread changes remember to change the subject header.
> - Good manners are required at all time. No personal attacks or
> "flames."
> - Complete your Yahoo profile.
> - Before posting a question, search the message archives and the various
> resources on the homepage.
> 
> 
> 
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> 
>

----- Original Message -----

From: "jimhayes361" <jimhayes@...>
To: <DigitalBlackandWhiteThePrint@yahoogroups.com>
Sent: Tuesday, June 25, 2002 12:58 PM
Subject: [Digital BW] Re: pshop 6->7 VM (converts file differently?)



(snip earlier)

> The steps I did after making sure that color settings ("pshop 5
> defaults" settings), etc were identical:
> 1) Open file up, disgarding mismatched profile. Image is labelled
> "untagged grey". I could assign profile of gamma 2.2 to it, but it
> just gives me the same  histogram results.
>
> 2) convert to rgb mode. Dialog asks if I wantt to merge layers. I
> choose "yes". sRGB appears as the new color space for file.
>
> 3) Add adjust curves layer- in curves dialog I load Paul's mw 2880
> curve for PC. I also checked the normal 1440 (mw for PC 1280) curve
> that most people use  and also get a change from 6 to 7.
>
> 4) select background layer and view histogram. Note down mean, SD and
> median.
>
> 5) close down pshop and open up the other version and repeat steps.
> There is a slight discrepancy in all three values, but most notable in
> the median.
> Jim H.
>
Jim,

I went through the steps above (except that I am working in Adobe RGB) and I
am not seeing any significant difference between 6 and 7

For the PS7 version of my file I got Mean = 124.58, Std. Dev. = 95.52,
Median = 143
For the PS6 version of my file I got Mean = 124.41, Std. Dev. = 95.48,
Median = 143

So there is some difference but much smaller than you are getting. I am
running Windows 2000. I wonder if it is image dependent.

The only thing I can suggest was a recommendation from Dan Culbertson way
back on converting from grayscale to RGB. The workflow would go: flatten
image, mode change to Channels, delete any remaining alpha channels,
duplicate the black channel twice so that there are three black channels,
convert to RGB. The theory is that this will reduce the chance of any gamma
mismatch between the grayscale space and RGB space. Something to try.

Martin

--- In DigitalBlackandWhiteThePrint@y..., "Martin Wesley" 
<mwesley250@e...> wrote:
> 

> Jim,
> 
> I went through the steps above (except that I am working in Adobe 
RGB) and I
> am not seeing any significant difference between 6 and 7
> 
> For the PS7 version of my file I got Mean = 124.58, Std. Dev. = 
95.52,
> Median = 143
> For the PS6 version of my file I got Mean = 124.41, Std. Dev. = 
95.48,
> Median = 143
> 
> So there is some difference but much smaller than you are getting. I 
am
> running Windows 2000. I wonder if it is image dependent.

Martin I think this is the case exactly. I did a few images since I 
switched to PS7 and most were normal range prints- that is a more or 
less full tonal spectrum. It's really hard to see and I didn't think I 
had a problem at all, except the  small areas of shadow values looked 
a little posterized which I figured was just bad file manipulation on 
my part.

But I just went back and reprinted a print which is just about all 
shadows. For example your mean is about 124, about midrange, or, a 
fully balanced tonal image. My mean is 46.83 (ps6) or 45.57 (ps7). I 
also find it interesting that your histogram discrepancy is less than 
mine- is it due to darkness of print or do I have a setting wrong?

Now this dark print I originally printed in Febuary. More than about 
80% of it's surface is shadow detail, and it is one of my best prints 
as far as smooth shadow values/ transistions go. There is absolutely 
no posterization in the 3/4 tones which take up a lot of the print 
surface.

When I compare it to the print I just reprinted yesterday in PS7- the 
new print is really bad. I have a close up of a hand with skin texture 
but it is very dark skin (varies Zone  III-IV) . in this new print 
instead of a textured hand I get something that is so posterized it 
almost looks like a cartoon.

In addition I have a silklike drape that covers much of the 
background. Smooth in tonal transistion in the Febuary print,  in the 
print yesterday the tone breaks lighter suddenly on a fold of the 
cloth where it looks like it's broken out with measles.

Anyway, my supposition (not even a theory yet) is that if you don't 
get exactly the same numbers in PS7 vs 6, even if they are off less 
than 1%, the file is still different than the one you fed to the 
printer under PS6. Perhaps the higher values around 70%k say are not 
as sensitive to small changes in the file data. But how can anyone say 
how much of a difference in the histogram values will affect what 
Paul's curves do to image?

The only way to solve this is to first, make sure I am not overlooking 
something in my settings/workflow, and then when I get the VM ink back 
in, simply print out my dark "problem" print in both PS 6 and in PS 7 
and see if it does print shadows differently. This is the only final 
way to rule it out or in.

However, I am gratefull for your giving me Culbertsons workflow 
notion, and I think I will go back to the puter and try it out.

Sorry for the length. If you get a chance and have some time, try 
printing out one of your lowest key images and check for posterization 
in 3/4 tones. I don't know if it would show up in a step wedge, I 
suspect if one compared it side by side, 6 vs 7 it might.
Thanks for the help,
Jim H.   


> 
> The only thing I can suggest was a recommendation from Dan 
Culbertson way
> back on converting from grayscale to RGB. The workflow would go: 
flatten
> image, mode change to Channels, delete any remaining alpha channels,
> duplicate the black channel twice so that there are three black 
channels,
> convert to RGB. The theory is that this will reduce the chance of 
any gamma
> mismatch between the grayscale space and RGB space. Something to 
try.
> 
> Martin

Martin Wesley
http://www.borderless-photos.de/guests.html

----- Original Message -----
From: "jimhayes361" <jimhayes@...>
To: <DigitalBlackandWhiteThePrint@yahoogroups.com>
Sent: Tuesday, June 25, 2002 4:39 PM
Subject: [Digital BW] Re: pshop 6->7 VM (converts file differently?)


> --- In DigitalBlackandWhiteThePrint@y..., "Martin Wesley"
> <mwesley250@e...> wrote:
> >
>
> > Jim,
> >
> > I went through the steps above (except that I am working in Adobe
> RGB) and I
> > am not seeing any significant difference between 6 and 7
> >
> > For the PS7 version of my file I got Mean = 124.58, Std. Dev. =
> 95.52,
> > Median = 143
> > For the PS6 version of my file I got Mean = 124.41, Std. Dev. =
> 95.48,
> > Median = 143
> >
> > So there is some difference but much smaller than you are getting. I
> am
> > running Windows 2000. I wonder if it is image dependent.
>
> Martin I think this is the case exactly. I did a few images since I
> switched to PS7 and most were normal range prints- that is a more or
> less full tonal spectrum. It's really hard to see and I didn't think I
> had a problem at all, except the  small areas of shadow values looked
> a little posterized which I figured was just bad file manipulation on
> my part.

Jim,

I went back an dug out a grayscale that was shadow predominate and went
through the same workflow and got similar results:

For the PS7 version of my shadow file I got Mean = 82.30, Std. Dev. = 80.02,
Median = 44
For the PS6 version of my file I got Mean = 82.32, Std. Dev. = 80.07, Median
= 44

So it seems to be pretty consistent on my system at least.

>
> But I just went back and reprinted a print which is just about all
> shadows. For example your mean is about 124, about midrange, or, a
> fully balanced tonal image. My mean is 46.83 (ps6) or 45.57 (ps7). I
> also find it interesting that your histogram discrepancy is less than
> mine- is it due to darkness of print or do I have a setting wrong?
>
> Now this dark print I originally printed in Febuary. More than about
> 80% of it's surface is shadow detail, and it is one of my best prints
> as far as smooth shadow values/ transistions go. There is absolutely
> no posterization in the 3/4 tones which take up a lot of the print
> surface.
>
> When I compare it to the print I just reprinted yesterday in PS7- the
> new print is really bad. I have a close up of a hand with skin texture
> but it is very dark skin (varies Zone  III-IV) . in this new print
> instead of a textured hand I get something that is so posterized it
> almost looks like a cartoon.

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?
>
> In addition I have a silklike drape that covers much of the
> background. Smooth in tonal transistion in the Febuary print,  in the
> print yesterday the tone breaks lighter suddenly on a fold of the
> cloth where it looks like it's broken out with measles.
>
> Anyway, my supposition (not even a theory yet) is that if you don't
> get exactly the same numbers in PS7 vs 6, even if they are off less
> than 1%, the file is still different than the one you fed to the
> printer under PS6. Perhaps the higher values around 70%k say are not
> as sensitive to small changes in the file data. But how can anyone say
> how much of a difference in the histogram values will affect what
> Paul's curves do to image?
>
> The only way to solve this is to first, make sure I am not overlooking
> something in my settings/workflow, and then when I get the VM ink back
> in, simply print out my dark "problem" print in both PS 6 and in PS 7
> and see if it does print shadows differently. This is the only final
> way to rule it out or in.
>
> However, I am gratefull for your giving me Culbertsons workflow
> notion, and I think I will go back to the puter and try it out.
>
> Sorry for the length. If you get a chance and have some time, try
> printing out one of your lowest key images and check for posterization
> in 3/4 tones. I don't know if it would show up in a step wedge, I
> suspect if one compared it side by side, 6 vs 7 it might.

I would think that anything like this would show up in a step wedge. So you
might want to start there.

As I recall you are on a 1280 and I wanted to point out that Adobe
PressReady works with the 1280 (it thinks it is a 1270) giving you full CMYK
control. Peter Lindman sent me some really great prints he did with the
MIS-VM set and I have seen Tyler's work with Piezo inks and Press Ready on a
3000. Of course you are then off on your own doing curves but you have more
control than trying to trick the Epson driver with the RGB curves.

I'm wandering. If you resolve the issue, which my trials would suggest you
can, please let us know what you find.

Martin

(snip)

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

Todd,

You wrote, in part:

>...
> 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. ...

>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.

>...

As you suspected, I have found that all the workflows have imperfections.
There are "lines" in the ramps of all of them -- Piezo included.  If you
hold a print of a smooth Photoshop ramp up close to a light so you can see
everything, you'll be very depressed.  We are far from perfection in this
process.  Whether a workflow works for a particular print probably relates
to whether there is a "line" or flat spot at a critical point in the ramp
for that particular shot.

See, for example my "Ramp-smoothness.jpg" in the "Image Processing" folder
of the Files section of this forum. Go to
http://groups.yahoo.com/group/DigitalBlackandWhiteThePrint/files/
Then follow the link to Image Processing.

What I did is run a Photoshop gradient at 50% in the opposite direction of
the ramp in the printed test file.  The two should cancel each other out
entirely -- except for the imperfections.  I then raised the contrast of the
images to accentuate the imperfections.  The bottom halves of the images did
not have the 50% ramp run across it.  So, you can see how much I raised the
contrast.

At any rate, you can see the "lines" I mentioned clearly. (There are two
that are scanner defects -- one at 100% and one at 90%.)  My point in the
exercise is not to say one driver is better than the other, but to show that
both are far from perfect.

So, I subscribe to your solution entirely -- multiple workflows.  With the
quads -- 1160 and 3000 -- Piezo and Epson workflows are easy with the same
FS/Piezo compatible inksets.  With the vm inksets multiple curves can be
helpful.

Paul
http://www.PaulRoark.com

Todd,

We have discussed all of your points at one time or another and I believe we
are pretty much in complete agreement. Posterization can have many sources.
The most common is probably over manipulating 8-bit files and I think the
second maybe scanning.

(By the way for those new to the subject, we use the word posterization to
mean the loss of smooth transition from one tone to the next in the print.
Areas that print out very flat or smooth areas that abruptly change tone.
Posterization actually means a reversal of tone where instead of getting
lighter or darker the tone actually goes in the opposite direction. You can
get this extreme but it is rare.)

My remarks about the RGB separation curve method and posterization come
simply from looking at the histogram of a file before you apply the
separation curve and after you apply it. From what I have seen regardless of
the original condition of the image data there is less of it after the
curves are applied. You can easily see this in the histograms or even better
since you have a Mac there is a utility in the Files section of the Hi-End
Scanner Group that gives you a count of the number of colors in an image
file. Tyler check some counts before and after curve application and the
count does go down after the curves are used.

As we have noted before, when you do something to an 8-bit file that removes
some of the 256 shades of gray it may or may not be noticeable in the print
or on the screen. So most of the time we are okay. I think that we get into
problems when the lost data falls in an image critical area or there is so
much loss any sense of continuous tone is gone. So if you are walking the
fence with an image and then apply an RGB separation curve you are more
likely to fall into posterization.

For those not familiar with the RGB separation curve and Epson driver
method, a grayscale file is converted to RGB and a set of curves are applied
to partition the ink so that the dark ink is used for the dark tones and the
light inks are used for the highlights. With the MIS-VM inks this also
controls the hue of the print. In order to fool the Epson driver into
partitioning the inks correctly the RGB curves are often very severe and
cause data loss. We would seem to be really torturing the whole system here
since we take a grayscale file and send it to the driver as modified RGB
data and the driver converts this into CMYK info to control the printer.

I can see what is happening to the image data with this workflow. I have no
idea what is happening to the data with the Piezo driver or a RIP. However,
I assume that the Piezo driver is a CMYK driver but I don't know. The RIP
drivers are CMYK drivers and theoretically it would seem likely that the
data would have to be manipulated less than in an RGB/Epson driver workflow.
This is purely assumption on my part since I have not experience yet. (I did
pick up a copy of PressReady but have not had time to play with it.)

My own system has been to use MIS-VM in a 1280 primarily with medium warm
and warm curves. I scan in 16-bit and make initial adjustments there and
then drop to 8-bit for final editing. I work in RGB using a soft proof
profile. If I get posterization I try different curves, either earlier
versions or different hues or switch between Paul's and Tyler's curves, to
either eliminate the problem or shift it to a less objectionable tonal
range. If that fails I will go back and apply the adjustments I have used on
the 8-bit file to a 16-bit version of the file. If that doesn't work then I
try a re-scan.

I think bottom line some images don't work. They don't work in silver
either. Sometimes a neg is just too flat in some areas to be useable.
Sometime a digital approach will pull it out but not always. The key may be
to have a variety of drivers and ink sets available just as you had a
variety of papers, developers and toners in the darkroom. I have a second
1280 that I have been using to try different ink sets. I would like to leave
that set up with PiezoTone and keep VM in the other (I am considering
switching to the Sepia-VM though). I need to set up a third 1280 then for on
going trials but I am out of room. Adding a RIP for the VM and PiezoTones
would further increase options.

I think the multi-printer, ink set, driver approach is the way to go rather
than trying to find the one perfect system. Different images are going to do
better on one than the other. I generally like the Epson driver for sky and
clouds, and the Piezo driver for images with lots of fine detail for
instance. I think your remarks on the different ink sets have different
transition points is valid and supports this idea.

I can't match prints from MIS-VM and Piezo. It is just like trying to match
silver prints on different brands of paper. You can get close but.... I
certainly can't get a file that prints well with the Piezo driver and then
print it out using the RGB/Epson driver without adjusting levels, etc. They
just aren't that close. Since I have managed lots of posterization in prints
using Piezo I can't recommend it as a posterization cure. The RIP's may be
another story but I suspect you can mess up there too.

Regarding the "pure" 8-bit print, I can only say that if it printed out with
posterization without any manipulation being done I would suspect that
either the scan was not good enough or the image itself was pretty flat,
perhaps too flat. Also keep in mind that a posterized image can have a
perfect histogram. If I scanned a posterized print for example, I would
expect that the histogram would look okay.

As you have pointed out before and I confirm, you can have files with
terrible looking histograms that print out just fine. I think the reverse is
also true. You can have files with really great looking histograms that may
still print out with flat or dead areas due to a lack of info in the scan or
the image.

Well that ramble should have put most of you to sleep!

Martin


----- Original Message -----
From: "Todd Flashner" <tflash@...>
To: <DigitalBlackandWhiteThePrint@yahoogroups.com>
Sent: Tuesday, June 25, 2002 10:09 PM
Subject: Re: [Digital BW] Re: pshop 6->7 VM (converts file differently?)


> 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
>
>
>
>
> Please visit the Group Homepage to check the Files, Bookmarks, Polls and
other resources as they are often being updated. The page is at:
>
> http://groups.yahoo.com/group/DigitalBlackandWhiteThePrint
>
> Please follow these basic guidelines:
> - Include your full name with your message.
> - Include the address of your website, if you have one.
> - As threads develop, trim off excess portions of earlier messages to keep
them short.
> - As the topic of a thread changes remember to change the subject header.
> - Good manners are required at all time. No personal attacks or
"flames."
> - Complete your Yahoo profile.
> - Before posting a question, search the message archives and the various
resources on the homepage.

>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>

on 6/26/02 2:30 AM, Martin Wesley wrote:

> I can see what is happening to the image data with this workflow. I have no
> idea what is happening to the data with the Piezo driver or a RIP.


Martin,

Your post nicely summarizes the landscape here, and I should probably just
let it stand, but I have work I'm trying to avoid. ;-)

I think the above gets to the heart of what my quibble was. There seems to
be an assumption (by many, including myself at one point) that the RGB
workflow is harsher on a file than sending a grayscale file through the
Piezo driver/profile, and I'm just not sure that is the case.

Yes, in the RGB workflow we know the image is tortured by radical separation
curves, but do we know that the Piezo alternative is any less dramatic?
Unfortunately we don't. *Something* is still partitioning those same ink
densities. I'd say the proof is in the output, and we know that both can
fail.

> Posterization can have many sources.
> The most common is probably over manipulating 8-bit files and I think the
> second maybe scanning.

I'll spite myself and go out on a limb and suggest that the inkjet process
itself is the primary cause of the posterization most on this list
experience.

My sense is that since all workflows are working with similar ink densities
and similarly applying those densities across the image, tones that fall
into those density (and sometimes hue) cracks and transitions may fail
similarly with all systems. That all are capable of posterization with
pristine files seems to bear that out.

Now if this were a group of LTV outputters I'd agree fully with what you say
above.

Todd

Martin, Todd, Paul, everyone,

You all bring up extremely good points. I am going to limit myself to 
two observations and one experiment. I'm doing this because something 
CHANGED on my system and I need to isolate it. This change in workflow 
or settings turned a great print done in Febuary, which I have in a 
light tight box as reference, to a trashy posterized print done two 
days ago. However imperfect or perfect my workflow/ print file/combing 
was in Febuauary, it got worse from the same exact file and same 
settings in June.

I use an 1280 with standard VM inkset, which I (perhaps 
uneconomically) use virgin vacuum filled carts with. I bought my first 
six bottles of ink in January, my second arrived April 9th. So one 
change that happened was I started filling from a new set of bottles. 
I swab tested them to be sure they were not mislabeled and I double 
checked labels as I filled carts.

The second change was that I loaded Photoshop 7 on my system (Win98SE) 
on April 22.

The things that changed are: time, inkset bottles (same batch?), and 
pshop 6---->7.

If the ink gooped up my printer over "time", I may see it get better 
in both ps6 and 7 after running Epson carts in it for a couple of 
days. I suspect this is not the case. Since no CIS is involved we can 
rule out all the little problems it can cause.

If the two sets of inksets differ, MIS would have long heard of it by 
now from many other folks. I think this can be ruled out, escpecially 
since they were bought only 3 months apart.

If when I put a new set of carts in after the OEM ink run, I can, from 
the same file, duplicate the good print using PS 6 and duplicate the 
bad print using PS7, then the variable that messed up the print is the 
conversion algorithim in PS6 vs 7. If the result from this experiment 
is positive, it locks out the other two variables and a lot of other 
things as the culprit. And someone then has to discover what changed 
in PS7.

Oh well. All speculation until I run those two prints- maybe Thursday, 
Friday.
 
The second note is that I tried Culbertson's technique, suggested by 
Martin, to convert from greyscale to RGB and then apply one of Paul's 
curves in both PS6 and PS7. What's very interesting is that using 
Culbertson's method, PS6 and PS7 give identical mean, SD, and median 
values for my test print using the VM workflow, down to applying 
Paul's curve. BUT, the values in the histogram differ from both PS 6 
and PS7 when the regular greyscale gamma 2.2 convert to sRGB is used 
(Paul's workflow). And of course as already stated way back in a 
previous post, the values differ between PS6 and PS7 using the gamma 
2.2 greyscale--->sRGB.

 So one gets three slightly different files going to the printer 
depending on whether you use grey gamma 2.2 to sRGB PS 6, grey gamma 
2.2 to sRGB PS7, or Culbertson's channel conversion to RGB method 
(PS6/PS7 independent).

What is puzzling to me is Martin not getting quite as large a 
difference as I did when he tried the gamma conversion in both ver 6 
and ver 7. It could still be that I'm overlooking some setting, but I 
really can't think of what it is. Maybe it just depends on which file 
one uses(?), not just how dark or light it is?
Jim H. 






--- In DigitalBlackandWhiteThePrint@y..., "Martin Wesley" 
<mwesley250@e...> wrote:
> Todd,
> 
> We have discussed all of your points at one time or another and I 
believe we
> are pretty much in complete agreement. Posterization can have many 
sources.
> The most common is probably over manipulating 8-bit files and I 
think the
> second maybe scanning.
> 
<snip>
> 
> I can see what is happening to the image data with this workflow. I 
have no
> idea what is happening to the data with the Piezo driver or a RIP. 
<snip>

> 
> I think bottom line some images don't work. They don't work in 
silver
> either. Sometimes a neg is just too flat in some areas to be 
useable.
> Sometime a digital approach will pull it out but not always. The key 
may be
> to have a variety of drivers and ink sets available just as you had 
a
> variety of papers, developers and toners in the darkroom. I have a 
second
> 1280 that I have been using to try different ink sets. I would like 
to leave
> that set up with PiezoTone and keep VM in the other (I am 
considering
> switching to the Sepia-VM though). I need to set up a third 1280 
then for on
> going trials but I am out of room. Adding a RIP for the VM and 
PiezoTones
> would further increase options.
> 
> I think the multi-printer, ink set, driver approach is the way to go 
rather
> than trying to find the one perfect system. Different images are 
going to do
> better on one than the other. I generally like the Epson driver for 
sky and
> clouds, and the Piezo driver for images with lots of fine detail for
> instance. I think your remarks on the different ink sets have 
different
> transition points is valid and supports this idea.
> 
<snip>

on 6/26/02 12:13 PM, jimhayes361 wrote:

> If when I put a new set of carts in after the OEM ink run, I can, from
> the same file, duplicate the good print using PS 6 and duplicate the
> bad print using PS7, then the variable that messed up the print is the
> conversion algorithim in PS6 vs 7. If the result from this experiment
> is positive, it locks out the other two variables and a lot of other
> things as the culprit. And someone then has to discover what changed
> in PS7.


Jim

there is a thread titled "PS7 Grayscale bug?" running on the

colortheory@yahoogroups.com

list that seems related to your issue.

Todd

Martin,

Thanks for an outstanding discourse on the posterization issue. You  had attempted to give me some insight into this area when I queried the group about it some weeks ago. I tried the solutions you suggested without a good outcome, and had reached the conclusion myself that, just as in the wet darkroom, there are certain images that you are just not going to be able to "make". I must say, though, at this point in my experience I derive much more satisfaction from images printed in the chemical darkroom. I know that this is largely a function of 25 years vs 10 weeks digital experience.

I am a physician and rarely get the opportunity to spend 4-6 hours in my darkroom. I love the fact that I can derive satisfaction and pleasure from even the few minutes a day I am able to spend "digitally".

Thanks for your expertise and willingness to share.

Stuart Spigel

  ----- Original Message ----- 
  From: Martin Wesley 
  To: DigitalBlackandWhiteThePrint@yahoogroups.com 
  Sent: Wednesday, June 26, 2002 1:30 AM
  Subject: Re: [Digital BW] Re: pshop 6->7 VM (converts file differently?)


  Todd,

  We have discussed all of your points at one time or another and I believe we
  are pretty much in complete agreement. Posterization can have many sources.
  The most common is probably over manipulating 8-bit files and I think the
  second maybe scanning.

  (By the way for those new to the subject, we use the word posterization to
  mean the loss of smooth transition from one tone to the next in the print.
  Areas that print out very flat or smooth areas that abruptly change tone.
  Posterization actually means a reversal of tone where instead of getting
  lighter or darker the tone actually goes in the opposite direction. You can
  get this extreme but it is rare.)

  My remarks about the RGB separation curve method and posterization come
  simply from looking at the histogram of a file before you apply the
  separation curve and after you apply it. From what I have seen regardless of
  the original condition of the image data there is less of it after the
  curves are applied. You can easily see this in the histograms or even better
  since you have a Mac there is a utility in the Files section of the Hi-End
  Scanner Group that gives you a count of the number of colors in an image
  file. Tyler check some counts before and after curve application and the
  count does go down after the curves are used.

  As we have noted before, when you do something to an 8-bit file that removes
  some of the 256 shades of gray it may or may not be noticeable in the print
  or on the screen. So most of the time we are okay. I think that we get into
  problems when the lost data falls in an image critical area or there is so
  much loss any sense of continuous tone is gone. So if you are walking the
  fence with an image and then apply an RGB separation curve you are more
  likely to fall into posterization.

  For those not familiar with the RGB separation curve and Epson driver
  method, a grayscale file is converted to RGB and a set of curves are applied
  to partition the ink so that the dark ink is used for the dark tones and the
  light inks are used for the highlights. With the MIS-VM inks this also
  controls the hue of the print. In order to fool the Epson driver into
  partitioning the inks correctly the RGB curves are often very severe and
  cause data loss. We would seem to be really torturing the whole system here
  since we take a grayscale file and send it to the driver as modified RGB
  data and the driver converts this into CMYK info to control the printer.

  I can see what is happening to the image data with this workflow. I have no
  idea what is happening to the data with the Piezo driver or a RIP. However,
  I assume that the Piezo driver is a CMYK driver but I don't know. The RIP
  drivers are CMYK drivers and theoretically it would seem likely that the
  data would have to be manipulated less than in an RGB/Epson driver workflow.
  This is purely assumption on my part since I have not experience yet. (I did
  pick up a copy of PressReady but have not had time to play with it.)

  My own system has been to use MIS-VM in a 1280 primarily with medium warm
  and warm curves. I scan in 16-bit and make initial adjustments there and
  then drop to 8-bit for final editing. I work in RGB using a soft proof
  profile. If I get posterization I try different curves, either earlier
  versions or different hues or switch between Paul's and Tyler's curves, to
  either eliminate the problem or shift it to a less objectionable tonal
  range. If that fails I will go back and apply the adjustments I have used on
  the 8-bit file to a 16-bit version of the file. If that doesn't work then I
  try a re-scan.

  I think bottom line some images don't work. They don't work in silver
  either. Sometimes a neg is just too flat in some areas to be useable.
  Sometime a digital approach will pull it out but not always. The key may be
  to have a variety of drivers and ink sets available just as you had a
  variety of papers, developers and toners in the darkroom. I have a second
  1280 that I have been using to try different ink sets. I would like to leave
  that set up with PiezoTone and keep VM in the other (I am considering
  switching to the Sepia-VM though). I need to set up a third 1280 then for on
  going trials but I am out of room. Adding a RIP for the VM and PiezoTones
  would further increase options.

  I think the multi-printer, ink set, driver approach is the way to go rather
  than trying to find the one perfect system. Different images are going to do
  better on one than the other. I generally like the Epson driver for sky and
  clouds, and the Piezo driver for images with lots of fine detail for
  instance. I think your remarks on the different ink sets have different
  transition points is valid and supports this idea.

  I can't match prints from MIS-VM and Piezo. It is just like trying to match
  silver prints on different brands of paper. You can get close but.... I
  certainly can't get a file that prints well with the Piezo driver and then
  print it out using the RGB/Epson driver without adjusting levels, etc. They
  just aren't that close. Since I have managed lots of posterization in prints
  using Piezo I can't recommend it as a posterization cure. The RIP's may be
  another story but I suspect you can mess up there too.

  Regarding the "pure" 8-bit print, I can only say that if it printed out with
  posterization without any manipulation being done I would suspect that
  either the scan was not good enough or the image itself was pretty flat,
  perhaps too flat. Also keep in mind that a posterized image can have a
  perfect histogram. If I scanned a posterized print for example, I would
  expect that the histogram would look okay.

  As you have pointed out before and I confirm, you can have files with
  terrible looking histograms that print out just fine. I think the reverse is
  also true. You can have files with really great looking histograms that may
  still print out with flat or dead areas due to a lack of info in the scan or
  the image.

  Well that ramble should have put most of you to sleep!

  Martin


  ----- Original Message -----
  From: "Todd Flashner" <tflash@...>
  To: <DigitalBlackandWhiteThePrint@yahoogroups.com>
  Sent: Tuesday, June 25, 2002 10:09 PM
  Subject: Re: [Digital BW] Re: pshop 6->7 VM (converts file differently?)


  > 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
  >
  >
  >
  >
  > Please visit the Group Homepage to check the Files, Bookmarks, Polls and
  other resources as they are often being updated. The page is at:
  >
  > http://groups.yahoo.com/group/DigitalBlackandWhiteThePrint
  >
  > Please follow these basic guidelines:
  > - Include your full name with your message.
  > - Include the address of your website, if you have one.
  > - As threads develop, trim off excess portions of earlier messages to keep
  them short.
  > - As the topic of a thread changes remember to change the subject header.
  > - Good manners are required at all time. No personal attacks or
  "flames."
  > - Complete your Yahoo profile.
  > - Before posting a question, search the message archives and the various
  resources on the homepage.
  >
  >
  >
  >
  > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
  >
  >
  >



        Yahoo! Groups Sponsor 
              ADVERTISEMENT
             
       
       

  Please visit the Group Homepage to check the Files, Bookmarks, Polls and other resources as they are often being updated. The page is at:

  http://groups.yahoo.com/group/DigitalBlackandWhiteThePrint

  Please follow these basic guidelines:
  - Include your full name with your message.
  - Include the address of your website, if you have one.
  - As threads develop, trim off excess portions of earlier messages to keep them short.
  - As the topic of a thread changes remember to change the subject header.
  - Good manners are required at all time. No personal attacks or "flames."
  - Complete your Yahoo profile.
  - Before posting a question, search the message archives and the various resources on the homepage. 




  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. 



[Non-text portions of this message have been removed]

----- Original Message -----

From: "Todd Flashner" <tflash@...>
To: <DigitalBlackandWhiteThePrint@yahoogroups.com>
Sent: Wednesday, June 26, 2002 9:12 AM
Subject: Re: [Digital BW] Re: pshop 6->7 VM (converts file differently?)


> on 6/26/02 2:30 AM, Martin Wesley wrote:
>
> > I can see what is happening to the image data with this workflow. I have
no
> > idea what is happening to the data with the Piezo driver or a RIP.
>
>
> Martin,
>
> Your post nicely summarizes the landscape here, and I should probably just
> let it stand, but I have work I'm trying to avoid. ;-)
>
> I think the above gets to the heart of what my quibble was. There seems to
> be an assumption (by many, including myself at one point) that the RGB
> workflow is harsher on a file than sending a grayscale file through the
> Piezo driver/profile, and I'm just not sure that is the case.

Todd,

Can't argue with you on that since I don't have anyway to accurately test
it. Perhaps someone who uses a RIP workflow where you apply CMYK separation
curves prior to printing can comment on what the histogram looks like before
and after. Of course we don't know if the Piezo driver functions in CMYK or
not. Odds are it does partition the inks in some fashion.
>
> Yes, in the RGB workflow we know the image is tortured by radical
separation
> curves, but do we know that the Piezo alternative is any less dramatic?
> Unfortunately we don't. *Something* is still partitioning those same ink
> densities. I'd say the proof is in the output, and we know that both can
> fail.

Yep.
>
> > Posterization can have many sources.
> > The most common is probably over manipulating 8-bit files and I think
the
> > second maybe scanning.
>
> I'll spite myself and go out on a limb and suggest that the inkjet process
> itself is the primary cause of the posterization most on this list
> experience.

Could very well be true. The one caution I have in that regard is that many
people report problems with workflows, materials and equipment identical to
what others report success with. I have seen people get very poor results
with the MIS-VM on a 1280 with Windows identical to my set up. My wedges
look pretty good and theirs looked pretty hopeless for use with real prints.
This is very technical stuff and there would appear to be many variables
that may not always be under control. In the end though I have seen so many
excellent ink jet B&W prints and heard so many stories of failure I have to
conclude that it is a workable medium but not an easy one. I don't consider
silver printing easy either.
>
> My sense is that since all workflows are working with similar ink
densities
> and similarly applying those densities across the image, tones that fall
> into those density (and sometimes hue) cracks and transitions may fail
> similarly with all systems.

I am not sure that the ink densities are that close. From what Paul has said
there is quite a bit of density variation between a Y position Piezo ink and
a Y position MIS-VM ink.

>That all are capable of posterization with
> pristine files seems to bear that out.

Only if the original scans and/or source negs are free of posterization.
From my own experience I have encountered posterization either as a result
of too much image manipulation or a neg that was flat to begin with. A good
test would be to take your pure 8-bit file that posterized and print it as a
mono ink print to see if the posterization is a result of the partitioning
or not.
>
> Now if this were a group of LTV outputters I'd agree fully with what you
say
> above.

Since photo laser printers are RGB devices printing on color material I
guess no partitioning is involved so data loss or damage should not be an
issue. I wish I had one. <G>

Martin

Martin,

This is why I like you. Very sane, well informed, good ideas, good host. I
bet you keep good booze on hand too.

Got any sisters?

Todd

>> Martin,
>> 
>> Your post nicely summarizes the landscape here, and I should probably just
>> let it stand, but I have work I'm trying to avoid. ;-)
>> 
>> I think the above gets to the heart of what my quibble was. There seems to
>> be an assumption (by many, including myself at one point) that the RGB
>> workflow is harsher on a file than sending a grayscale file through the
>> Piezo driver/profile, and I'm just not sure that is the case.
> 
> Todd,
> 
> Can't argue with you on that since I don't have anyway to accurately test
> it. Perhaps someone who uses a RIP workflow where you apply CMYK separation
> curves prior to printing can comment on what the histogram looks like before
> and after. Of course we don't know if the Piezo driver functions in CMYK or
> not. Odds are it does partition the inks in some fashion.
>> 
>> Yes, in the RGB workflow we know the image is tortured by radical
> separation
>> curves, but do we know that the Piezo alternative is any less dramatic?
>> Unfortunately we don't. *Something* is still partitioning those same ink
>> densities. I'd say the proof is in the output, and we know that both can
>> fail.
> 
> Yep.
>> 
>>> Posterization can have many sources.
>>> The most common is probably over manipulating 8-bit files and I think
> the
>>> second maybe scanning.
>> 
>> I'll spite myself and go out on a limb and suggest that the inkjet process
>> itself is the primary cause of the posterization most on this list
>> experience.
> 
> Could very well be true. The one caution I have in that regard is that many
> people report problems with workflows, materials and equipment identical to
> what others report success with. I have seen people get very poor results
> with the MIS-VM on a 1280 with Windows identical to my set up. My wedges
> look pretty good and theirs looked pretty hopeless for use with real prints.
> This is very technical stuff and there would appear to be many variables
> that may not always be under control. In the end though I have seen so many
> excellent ink jet B&W prints and heard so many stories of failure I have to
> conclude that it is a workable medium but not an easy one. I don't consider
> silver printing easy either.
>> 
>> My sense is that since all workflows are working with similar ink
> densities
>> and similarly applying those densities across the image, tones that fall
>> into those density (and sometimes hue) cracks and transitions may fail
>> similarly with all systems.
> 
> I am not sure that the ink densities are that close. From what Paul has said
> there is quite a bit of density variation between a Y position Piezo ink and
> a Y position MIS-VM ink.
> 
>> That all are capable of posterization with
>> pristine files seems to bear that out.
> 
> Only if the original scans and/or source negs are free of posterization.
> From my own experience I have encountered posterization either as a result
> of too much image manipulation or a neg that was flat to begin with. A good
> test would be to take your pure 8-bit file that posterized and print it as a
> mono ink print to see if the posterization is a result of the partitioning
> or not.
>> 
>> Now if this were a group of LTV outputters I'd agree fully with what you
> say
>> above.
> 
> Since photo laser printers are RGB devices printing on color material I
> guess no partitioning is involved so data loss or damage should not be an
> issue. I wish I had one. <G>
> 
> Martin
> 
> 
> 
> 
> 
> Please visit the Group Homepage to check the Files, Bookmarks, Polls and other
> resources as they are often being updated. The page is at:
> 
> http://groups.yahoo.com/group/DigitalBlackandWhiteThePrint
> 
> Please follow these basic guidelines:
> - Include your full name with your message.
> - Include the address of your website, if you have one.
> - As threads develop, trim off excess portions of earlier messages to keep
> them short.
> - As the topic of a thread changes remember to change the subject header.
> - Good manners are required at all time. No personal attacks or
> "flames."
> - Complete your Yahoo profile.
> - Before posting a question, search the message archives and the various
> resources on the homepage.
> 
> 
> 
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> 
>

Jim,

I just wanted to point out one difference in our file conversion process.
You converted to sRGB in both PS6 and PS7 while I converted to Adobe RGB in
both. I don't know if this is significant but a variable to keep in mind.

I hope it is just a workflow adjustment issue and not something mechanical.

Martin Wesley
http://www.borderless-photos.de/guests.html

----- Original Message -----
From: "jimhayes361" <jimhayes@...>
To: <DigitalBlackandWhiteThePrint@yahoogroups.com>
Sent: Wednesday, June 26, 2002 9:13 AM
Subject: [Digital BW] Re: pshop 6->7 VM (isolating just 6 to 7 discrepancy)


> Martin, Todd, Paul, everyone,
>
> You all bring up extremely good points. I am going to limit myself to
> two observations and one experiment. I'm doing this because something
> CHANGED on my system and I need to isolate it. This change in workflow
> or settings turned a great print done in Febuary, which I have in a
> light tight box as reference, to a trashy posterized print done two
> days ago. However imperfect or perfect my workflow/ print file/combing
> was in Febuauary, it got worse from the same exact file and same
> settings in June.
>
> I use an 1280 with standard VM inkset, which I (perhaps
> uneconomically) use virgin vacuum filled carts with. I bought my first
> six bottles of ink in January, my second arrived April 9th. So one
> change that happened was I started filling from a new set of bottles.
> I swab tested them to be sure they were not mislabeled and I double
> checked labels as I filled carts.
>
> The second change was that I loaded Photoshop 7 on my system (Win98SE)
> on April 22.
>
> The things that changed are: time, inkset bottles (same batch?), and
> pshop 6---->7.
>
> If the ink gooped up my printer over "time", I may see it get better
> in both ps6 and 7 after running Epson carts in it for a couple of
> days. I suspect this is not the case. Since no CIS is involved we can
> rule out all the little problems it can cause.
>
> If the two sets of inksets differ, MIS would have long heard of it by
> now from many other folks. I think this can be ruled out, escpecially
> since they were bought only 3 months apart.
>
> If when I put a new set of carts in after the OEM ink run, I can, from
> the same file, duplicate the good print using PS 6 and duplicate the
> bad print using PS7, then the variable that messed up the print is the
> conversion algorithim in PS6 vs 7. If the result from this experiment
> is positive, it locks out the other two variables and a lot of other
> things as the culprit. And someone then has to discover what changed
> in PS7.
>
> Oh well. All speculation until I run those two prints- maybe Thursday,
> Friday.
>
> The second note is that I tried Culbertson's technique, suggested by
> Martin, to convert from greyscale to RGB and then apply one of Paul's
> curves in both PS6 and PS7. What's very interesting is that using
> Culbertson's method, PS6 and PS7 give identical mean, SD, and median
> values for my test print using the VM workflow, down to applying
> Paul's curve. BUT, the values in the histogram differ from both PS 6
> and PS7 when the regular greyscale gamma 2.2 convert to sRGB is used
> (Paul's workflow). And of course as already stated way back in a
> previous post, the values differ between PS6 and PS7 using the gamma
> 2.2 greyscale--->sRGB.
>
>  So one gets three slightly different files going to the printer
> depending on whether you use grey gamma 2.2 to sRGB PS 6, grey gamma
> 2.2 to sRGB PS7, or Culbertson's channel conversion to RGB method
> (PS6/PS7 independent).
>
> What is puzzling to me is Martin not getting quite as large a
> difference as I did when he tried the gamma conversion in both ver 6
> and ver 7. It could still be that I'm overlooking some setting, but I
> really can't think of what it is. Maybe it just depends on which file
> one uses(?), not just how dark or light it is?
> Jim H.
>
(snip earlier)

I tried both (gamma2.2>sRGB) and (gamma2.2>Adobe1998) out of curiousity.

then tried my CMYK conversion, yes, the same, the median and std dev are
different (but so very slightly).

in my cmyk convert, the mean value differences from PS6 to PS7  I'm getting
are 133.36 vs 133.27  and standard deviation value differences are 95.15 vs
95.03

You are getting more histo variance from PS6 to PS7 converting to sRGB than
to Adobe1998.

I can't find any info on this in the photoshop forum at adobe, curious
thing... should pose a question there perhaps.  Perhaps the same is true of
the PS5.5 to PS6 change, that the conversions are mapped better with each
upgrade.

Two other points, this variance occurs using any intent, and it occurs when
doing an RGB to RGB conversion as well.

I don't see how this is causing such a drastic change in your print though,
I believe it is a different issue.

Carolyn

> Jim,
> 
> I just wanted to point out one difference in our file conversion process.
> You converted to sRGB in both PS6 and PS7 while I converted to Adobe RGB in
> both. I don't know if this is significant but a variable to keep in mind.
> 
> I hope it is just a workflow adjustment issue and not something mechanical.
> 
> Martin Wesley

Yes it's there, and it can be seen in a dark print especially. The two 
prints have been sitting drying for an hour now- and they are 
different. You have to compare them side by side in a reasonable 
light- then the posterization shows up. I printed one in PS6 first, 
then switched to PS7 and redid right away. 

I ran my test print as an 8x 10 in both PS 6 and PS7, using Paul's 
workflow for 1280 PC, standard VM inkset- new carts just put in. I did 
use sRGB instead of Adobe 98 because Paul had done these curves for 
sRGB.

The only difference in the workflows is that PS6 shows me a source 
space and print space addendum to the Epson printer dialogue, and PS7 
has- nothing below the epson printer dialogue box (Win98SE). This is 
the only thing that is apparently different as one goes through the 
workflow in both PS6 and 7.

It shows up more in the larger print size, but I still make out 
posterization in the PS7 image (8x10). The PS6 image is clean.

In addition, when I examine a midtone Zone VI area side by side, the 
PS7 print is oh so slightly lighter and maybe more contrasty. But to 
see this you have to stand on your head and stare into an Ott-Lite<g>.


I really encourage people to run the test for yourself. I think a lot 
of prints will be under the threshold of detectibility if you don't do 
a side by side under a REAL good light...but my  oddish dark image 
shows up the problem with good but not fancy lighting in more than one 
3/4 tone area on the print. No question.

If you convert to Adobe RGB 98 maybe it won't show up as much as if 
you use sRGB. Who knows? What makes me nervous, is that there is any 
discrepancy at all in the histogram numbers. Something is being 
converted diferently from before in PS6.

If I have time (haha) I will try to scan a section of the two prints 
at the same pass. But please remember that my flatbed is 7 years old+ 
and leans toward magenta. And I may have to boost the brightness in 
these shadow areas for you to see the difference, etc etc. I'll let 
the prints dry for a day or two first I think, be official about it.
Jim H.

assuming that you need to set your source and print space for these
workflows, this would certainly change your entire print.  It's in the print
with preview dialogue box in PS7.

Carolyn

> The only difference in the workflows is that PS6 shows me a source
> space and print space addendum to the Epson printer dialogue, and PS7
> has- nothing below the epson printer dialogue box (Win98SE). This is
> the only thing that is apparently different as one goes through the
> workflow in both PS6 and 7.

Carolyn and Martin, all,

You both make the same very good point, and I'm glad I now know where 
that feature got hidden. Thanks to both of you. But...

I just ran a third print through using PS7 going through print with 
preview. I did have to set to "color management"; when I did this the 
source came up as sRGB and destination came up as same as source. I 
went to print button from that dialouge and compared the fresh print 
to the other two, already three hours drying.

I will look at it again after some drying time has passed, but 
unfortunately, the two PS7 prints match (that is the one done by going 
through "Print with Preview"--->"color management"---->yada vs the one 
done earlier just through the "print" dialouge). And both differ from 
the PS6 print done with srgb as "source" and "same as source" for 
destination (but in "print" dialouge).

IOW, I get posterization in PS7 using either method, but PS6 gives me 
my healthy print looking like my Febuary reference print (but done 
smaller in 8 x 10).

I would also like to update/ change my observations on the differences 
between the two prints: At a second look, I discover that you DO need 
to view these two prints under good quality lights, and you would be 
best to use a very dark print full of 3/4 tones. It shows up slightly 
above about a Zone V, but moreso Zone IV and below. The posterization 
 is maybe the most visible symptom, but I'll add now that the PS7 
print dark values also get slightly darker- vaugely 75% now looks like 
maybe 80%k just to hazard a number. As a second symptom it is 
detectable.

Can the color space specification have changed for sRGB in PS7 so that 
 it's really being converted to a "different"  sRGB space then Paul 
had origianally tuned his curve to?
Jim H. 





--- In DigitalBlackandWhiteThePrint@y..., Carolyn Frayn 
<carolynfrayn@s...> wrote:
> 
> assuming that you need to set your source and print space for these
> workflows, this would certainly change your entire print.  It's in 
the print
> with preview dialogue box in PS7.
> 
> Carolyn
> 
> > The only difference in the workflows is that PS6 shows me a source
> > space and print space addendum to the Epson printer dialogue, and 
PS7
> > has- nothing below the epson printer dialogue box (Win98SE). This 
is
> > the only thing that is apparently different as one goes through 
the
> > workflow in both PS6 and 7.

> I just ran a third print through using PS7 going through print with
> preview. I did have to set to "color management"; when I did this the
> source came up as sRGB and destination came up as same as source. I
> went to print button from that dialouge and compared the fresh print
> to the other two, already three hours drying.

Sorry Jim, I'm not familiar with Pauls workflows, do you set color
management to (no color adjustment) in PS6?

In PS7 when you choose color management > source/print spaces and intent,
then go back to the print driver dialogue it doesn't allow you to choose "no
color adjustment"  like in PS6..  So is PS7 assuming "no color adjustment"
when a source/print space is selected?

I'm going to have to actually read the manual. Something is strange to me.

When printing from PS7, using a source and print space, the print dialogue
is set in stone at automatic. This is not the same as PS6.  I have not
noticed this before today as I print thru pressready.

That would certainly change your file, if one were actually using auto and
the other "no color adjustment"... again though, I use NCA in my work flows
with profiles etc but don't know how your workflow is effected.



> Can the color space specification have changed for sRGB in PS7 so that
> it's really being converted to a "different"  sRGB space then Paul
> had origianally tuned his curve to?
> Jim H. 


I thought perhaps it was converting / mapping differently, but not that the
spaces are different. Also checked the older engines... but same variances.
That subtle difference should not be leading to such a difference in your
print in my opinion. So I wonder if it is the above.  I'll check the manual,
and perhaps a post to adobe forums... or search for further info there.

Or if this has been discussed I missed it...

Carolyn

--- In DigitalBlackandWhiteThePrint@y..., Carolyn Frayn 
<carolynfrayn@s...> wrote:
> 
> > I just ran a third print through using PS7 going through print 
with
> > preview. I did have to set to "color management"; when I did this 
the
> > source came up as sRGB and destination came up as same as source. 
I
> > went to print button from that dialouge and compared the fresh 
print
> > to the other two, already three hours drying.
> 
> Sorry Jim, I'm not familiar with Pauls workflows, do you set color
> management to (no color adjustment) in PS6?


In the dialogue box for Epson printer, under "advanced", color 
management--->"color controls" is selected- not no color management. 
Then in the last dialogue box before print starts, the source is 
selected as sRGB and printer space is selected as "same as source". 
Does that answer your question? I'm a little blurry as to what other 
color management you might be asking about.

> 
> In PS7 when you choose color management > source/print spaces and 
intent,
> then go back to the print driver dialogue it doesn't allow you to 
choose "no
> color adjustment"  like in PS6..  So is PS7 assuming "no color 
adjustment"
> when a source/print space is selected?

If I understand your question, as in PS6 I have the "advanced" 
dialouge box color management set to the "color controls" radio 
button. In fact to avoid mistakes I just saved all of Paul's settings 
so I can choose them from a pull down menu on the "details" 
tab--->custom radio button. The saved settings come up in both PS6 and 
PS7.

> 
> I'm going to have to actually read the manual. Something is strange 
to me.


I'm quite wandering around in a fog myself. I can't explain why the 
prints are different in PS6 and PS7, but the possible causes for it 
(wrong settings selected etc) seem to be disapearing.

> 
> When printing from PS7, using a source and print space, the print 
dialogue
> is set in stone at automatic. This is not the same as PS6.  I have 
not
> noticed this before today as I print thru pressready.


Well, if you're talking about the choice above the sliders in the 
advanced dialogue box(?), it's set at "automatic" PS6 or PS7 for me. I 
also have a "vivid" and "photo-realistic" mode in both PS6 And PS7. If 
you're talking about selecting source space and print space, both you 
and Martin pointed out to me how I could do that through print with 
preview, and the print is still posterized as I said<shrug>.

> 
> That would certainly change your file, if one were actually using 
auto and
> the other "no color adjustment"... again though, I use NCA in my 
work flows
> with profiles etc but don't know how your workflow is effected.

But since I don't have "no color adjustment" radio button selected 
in either 6 or 7...
 
> 
> 
> 
> > Can the color space specification have changed for sRGB in PS7 so 
that
> > it's really being converted to a "different"  sRGB space then Paul
> > had origianally tuned his curve to?
> > Jim H. 
> 
> 
> I thought perhaps it was converting / mapping differently, but not 
that the
> spaces are different.

Yeah, I realized after I typed that that it was not the case, since 
Martin gets diferences in the final histogram using Adobe 98 space 
instead of sRGB (although smaller deviations then I get).


 Also checked the older engines... but same 
variances.
> That subtle difference should not be leading to such a difference in 
your
> print in my opinion. So I wonder if it is the above.  I'll check the 
manual,
> and perhaps a post to adobe forums... or search for further info 
there.


Please, thank you. My workaround is simply to print in PS6, but I 
really don't understand what is happening and it is time for wiser 
folks than me to look at this. I see it but I don't believe that I'm 
really the first to have stumbled on this. We should have heard of it 
before now. But I'm running out of ideas of how I could have messed 
some setting up.
Jim H.

> 
> Or if this has been discussed I missed it...
> 
> Carolyn

>> Sorry Jim, I'm not familiar with Pauls workflows, do you set color
>> management to (no color adjustment) in PS6?
> 
> 
> In the dialogue box for Epson printer, under "advanced", color
> management--->"color controls" is selected- not no color management.
> Then in the last dialogue box before print starts, the source is
> selected as sRGB and printer space is selected as "same as source".
> Does that answer your question? I'm a little blurry as to what other
> color management you might be asking about.

Little different on the Mac, in advanced, there is "color management" that
is where "no color management" or "automatic" are choosen.

If you are using a workflow that is epson driver setting dependant and sRGB
as your source space and "same as source" as your printer space, then it's
probably set to automatic.


> 
>> 
>> In PS7 when you choose color management > source/print spaces and
>> intent,
>> then go back to the print driver dialogue it doesn't allow you to
> >choose "no
>> color adjustment"  like in PS6..  So is PS7 assuming "no color
> >adjustment"
>> when a source/print space is selected?
> 
> If I understand your question, as in PS6 I have the "advanced"
> dialouge box color management set to the "color controls" radio
> button. In fact to avoid mistakes I just saved all of Paul's settings
> so I can choose them from a pull down menu on the "details"
> tab--->custom radio button. The saved settings come up in both PS6 and
> PS7.

I'd have to go see his settings then. I assume this workflow was created
before switching to the "no color adjustment" one.


>> I'm going to have to actually read the manual. Something is strange
> to me.
> 
> 
> I'm quite wandering around in a fog myself. I can't explain why the
> prints are different in PS6 and PS7, but the possible causes for it
> (wrong settings selected etc) seem to be disapearing.
> 
>> 
>> When printing from PS7, using a source and print space, the print
>> dialogue
>> is set in stone at automatic. This is not the same as PS6.  I have
> >not
>> noticed this before today as I print thru pressready.
> 
> 
> Well, if you're talking about the choice above the sliders in the
> advanced dialogue box(?), it's set at "automatic" PS6 or PS7 for me. I
> also have a "vivid" and "photo-realistic" mode in both PS6 And PS7. If
> you're talking about selecting source space and print space, both you
> and Martin pointed out to me how I could do that through print with
> preview, and the print is still posterized as I said<shrug>.

There it is. Thank you... set at "automatic"

the PS7 manual indicates that when you choose your printer space (in this
case you are using sRGB ) and your source space (again you are using sRGB =
same as source) then "NO additional conversions will be performed on the
colors of the document when it is printed."  ----that from the manual.

So for a moment I thought it was perhaps ignoring the color management
dialogue settings in the print dialogue and using "no color management" no
matter if the input was set to "automatic"

a small test like that set to "no color management" from PS6 would show you
if this were the case in PS7... the PS6 print should look like the PS7 you
are getting if the PS7 printer were indeed ignoring the "auto" input.

I tried this, but with my color press proof I'm running right now thru my
1200, same print, from PS6 and PS7, using both set at print space AdobeRGB,
source space same as source... both on NCA (which is the better print) and
then both on auto (which produce a lighter non-representational print as is
the case when in printing same as source without printer profile
involvement)

No, I didn't convert anything for those, just wanted to test that thought,
that PS7 was somehow treating the file differently thru the color managment
dialogue. apparently not.  Those set to auto were identical, those set to
NCA were identical.

Then I converted both crops to sRGB, one in PS6 and one in PS7, the histos
again showed the same variance, but the prints, printed the same as above
only with the sRGB space chooses, printed indentically.  Although there is
that slight difference in the way the two versions handle the conversion I
don't see it in these prints.

Did the same thru pressready, to cmyk profile, identical prints.

I can't print with quads tonight, one printer is down, another set up for
press at the moment... and others just are what they are... but was curious
about the conversion differences with relation to the prints.  any prints.

> Please, thank you. My workaround is simply to print in PS6, but I
> really don't understand what is happening and it is time for wiser
> folks than me to look at this. I see it but I don't believe that I'm
> really the first to have stumbled on this. We should have heard of it
> before now. But I'm running out of ideas of how I could have messed
> some setting up.

When you try printing with the epson inks I'll be curious to hear of your
results. 

Carolyn

--- In DigitalBlackandWhiteThePrint@y..., Carolyn Frayn 
<carolynfrayn@s...> wrote:
>  
> >> Sorry Jim, I'm not familiar with Pauls workflows, do you set 
color
> >> management to (no color adjustment) in PS6?
> > 
> > 
> > In the dialogue box for Epson printer, under "advanced", color
> > management--->"color controls" is selected- not no color 
management.
> > Then in the last dialogue box before print starts, the source is
> > selected as sRGB and printer space is selected as "same as 
source".
> > Does that answer your question? I'm a little blurry as to what 
other
> > color management you might be asking about.
> 
> Little different on the Mac, in advanced, there is "color 
management" that
> is where "no color management" or "automatic" are choosen.


Yes, that option exist in a Windows form too in "advanced". I was 
trying to say that perhaps not too clearly. There are a series of 
radio buttons which essentially let you choose "no color management" 
or "color controls". Then there is a pull down menu under the radio 
buttons. At least when "color controls" is active, "automatic is a 
selection here.

> 
> If you are using a workflow that is epson driver setting dependant 
and sRGB
> as your source space and "same as source" as your printer space, 
then it's
> probably set to automatic.

Yes it is.

> 
> 
> > 
> >> 
> >> In PS7 when you choose color management > source/print spaces and
> >> intent,
> >> then go back to the print driver dialogue it doesn't allow you to
> > >choose "no
> >> color adjustment"  like in PS6..  So is PS7 assuming "no color
> > >adjustment"
> >> when a source/print space is selected?

This may be a moot point, since "no color adjustment" is never used as 
an option in Paul's workflow for PC. I think Tyler's workflow may. So 
in both PS7 and 6, "color controls" is selected.

> > 
> > If I understand your question, as in PS6 I have the "advanced"
> > dialouge box color management set to the "color controls" radio
> > button. In fact to avoid mistakes I just saved all of Paul's 
settings
> > so I can choose them from a pull down menu on the "details"
> > tab--->custom radio button. The saved settings come up in both PS6 
and
> > PS7.
> 
> I'd have to go see his settings then. I assume this workflow was 
created
> before switching to the "no color adjustment" one.

Yes. Did Paul change it? As I just said, I think Tylers workflow is 
"no adjustment".

> 
<snip>
> 
> Then I converted both crops to sRGB, one in PS6 and one in PS7, the 
histos
> again showed the same variance, but the prints, printed the same as 
above
> only with the sRGB space chooses, printed indentically.  Although 
there is
> that slight difference in the way the two versions handle the 
conversion I
> don't see it in these prints.

Puzzling. It seems like no-one can reproduce the print change with a 
real print. Maybe I have something set wrong, but I honestly don't 
know what it would be. And the PS7 print is darker in shadows, more 
contrasty by a tad, and posterized. Could my eyes lie like that? 
Perhaps the only way to check this out is for someone to run a step 
wedge in both PS6 and PS7 and measure it with a spectrophotometer.

One other difference to note (I mentioned it in other posts but should 
have highlighted it)is that Paul has a number of curves, some not 
published as official curves on the MIS site. Paul was good enough to 
send me a set of curves for the 1280 at 2880 dpi. He hadn't quite 
finished these before he realized most people didn't need to go above 
1440. But they work very well on Eclipse Satine paper I found, and on 
many prints I discovered the details came out sharper. All the curves 
are based on the same idea however, they just lay down a little more 
or less ink for a given %k. Of course, instead of choosing 1440 dpi, I 
chose 2880 in the advanced dialouge.
Could that be it?

> 
> Did the same thru pressready, to cmyk profile, identical prints.
> 
> I can't print with quads tonight, one printer is down, another set 
up for
> press at the moment... and others just are what they are... but was 
curious
> about the conversion differences with relation to the prints.  any 
prints.

Maybe the step wedge thing is the way to go if you have something to 
measure it with.

> 
> > Please, thank you. My workaround is simply to print in PS6, but I
> > really don't understand what is happening and it is time for wiser
> > folks than me to look at this. I see it but I don't believe that 
I'm
> > really the first to have stumbled on this. We should have heard of 
it
> > before now. But I'm running out of ideas of how I could have 
messed
> > some setting up.
> 
> When you try printing with the epson inks I'll be curious to hear of 
your
> results.

No, I was just running them to try to clear what I thought was a 
gummed up printer causing the discrepancy. An old trick I learned to 
partially clear the problems with the old Piezo inkset. But it didn't 
improve the PS7 print obviously. Nice to know it's not the printer 
though.
Jim H. 
> 
> Carolyn

> Yes, that option exist in a Windows form too in "advanced". I was
> trying to say that perhaps not too clearly. There are a series of
> radio buttons which essentially let you choose "no color management"
> or "color controls". Then there is a pull down menu under the radio
> buttons. At least when "color controls" is active, "automatic is a
> selection here.

Yes, thank you, that's the same then.

>>>> In PS7 when you choose color management > source/print spaces and
>>>> intent,
>>>> then go back to the print driver dialogue it doesn't allow you to
>>>> choose "no
>>>> color adjustment"  like in PS6..  So is PS7 assuming "no color
>>>> adjustment"
>>>> when a source/print space is selected?
> 
> This may be a moot point, since "no color adjustment" is never used as
> an option in Paul's workflow for PC. I think Tyler's workflow may. So
> in both PS7 and 6, "color controls" is selected.

It wasn't moot when I thought PS7 was "ignoring" the "auto" selection while
using a print/source space input. But that wasn't right.

Yes, all of Tyler's and my workflows use "no color adjustment". Otherwise
your image is dependant rather than cross platform/cross application among
other things.  We use profiles for source and output rather than allowing
the printer driver to change the data.




>> 
>> I'd have to go see his settings then. I assume this workflow was
> created
>> before switching to the "no color adjustment" one.
> 
> Yes. Did Paul change it? As I just said, I think Tylers workflow is
> "no adjustment".

I read that he changed his technique lately yes, not that he changed the
existing ones.



> Puzzling. It seems like no-one can reproduce the print change with a
> real print. Maybe I have something set wrong, but I honestly don't
> know what it would be. And the PS7 print is darker in shadows, more
> contrasty by a tad, and posterized. Could my eyes lie like that?
> Perhaps the only way to check this out is for someone to run a step
> wedge in both PS6 and PS7 and measure it with a spectrophotometer.

someone doing that with the workflow you are using
and without it.  That should tell you simply enough if it is your quad
workflow manipulations causing this, due to the small change in conversion
data between versions, adding on to that the curves that the quad
partitioning is doing to said data.. or not.

> One other difference to note (I mentioned it in other posts but should
> have highlighted it)is that Paul has a number of curves, some not
> published as official curves on the MIS site. Paul was good enough to
> send me a set of curves for the 1280 at 2880 dpi. He hadn't quite
> finished these before he realized most people didn't need to go above
> 1440. But they work very well on Eclipse Satine paper I found, and on
> many prints I discovered the details came out sharper. All the curves
> are based on the same idea however, they just lay down a little more
> or less ink for a given %k. Of course, instead of choosing 1440 dpi, I
> chose 2880 in the advanced dialouge.
> Could that be it?
> 

I don't know. I've never seen any real posterization issues arrise in my
workflows other than those that are file related. Some profiles can cause a
step to be missing, the transition between tones to be less smooth which I
tweak out... but posterization, not really.


>> Did the same thru pressready, to cmyk profile, identical prints.
>> 
>> I can't print with quads tonight, one printer is down, another set
>> up for
>> press at the moment... and others just are what they are... but was
> >curious
>> about the conversion differences with relation to the prints.  any
> >prints.
> 
> Maybe the step wedge thing is the way to go if you have something to
> measure it with.

I don't. I send my stuff to a friend for that. Someone else using the
workflow you are using would be the way to go.

>> When you try printing with the epson inks I'll be curious to hear of
> your
>> results.
> 
> No, I was just running them to try to clear what I thought was a
> gummed up printer causing the discrepancy. An old trick I learned to
> partially clear the problems with the old Piezo inkset. But it didn't
> improve the PS7 print obviously. Nice to know it's not the printer
> though.

ah, thanks... reading and printing late into the morning, missed that. Yes,
I know that routine.  Yes, nice to know it's not the printer.  As I say, I
get the same variation upon conversion but don't see it with my prints, so
the only thing left in my mind is the curves/workflow you are using.  I'm
still going to find out about that difference in conversion though, I'm
curious.

Good luck,
Carolyn

Some very quick thoughts. If you are comparing histos make sure the image cache prefs are identical for both PS versions.
Are there multiple versions of your destination space on your computer? Not only in your colorsync profiles folder, but Sys/
App support/Adobe/color/profiles/recomended.
Is PS6 using one and PS7 another? It's possible they could have been altered a touch over time. Get info in multiple versions 
to see. Make sure both destination spaces are the identical profile before assuming the conversion is at fault.
Tyler