Digital BW, The Print

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

From: "jimhayes361" <jimhayes@...>
To: <DigitalBlackandWhiteThePrint@yahoogroups.com>
Sent: Thursday, June 27, 2002 12:50 PM
Subject: [Digital BW] Re: ps 6/7 bug:print change confirmed


(snip)
>
> 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.

Jim,

With PS7 I start the print process by clicking on "Print with Preview..."
and then click the "More Options" box. I then select "Color Management"
instead of the default "Output" which let's you see and set the source and
destination spaces, just like PS6. If you have perhaps missed this as, I did
initially, in PS7 that might be a possible source of your problem.

Martin

(snip)

Jim,

Just to check on missing pieces I went back and did the file conversion and
curve application in both PS6 and PS7 but to sRGB space this time. I used
the same dark dominant image that gave a median of 44 in both versions of
PS.

When I converted to sRGB I got the following:

PS6: Mean = 80.12, Std. Dev. = 81.25, Median = 37
PS7: Mean = 79.85, Std. Dev. = 81.50, Median = 37

The PS6 to PS7 difference is similar to my earlier trial.

I did notice that when I took each of these converted files through the
"Print Preview.." dialog in PS7 that the Source Space of the PS7 converted
file showed up as "Untagged RGB" even though it had been converted to sRGB
and a check with the "Convert to Profile..." dialog confirmed that it was
indeed in sRGB space.

I don't know if any of this is helps but I wanted to get the data point.

At least the problem is not with your printer if you can still duplicate
your earlier PS results.

I remember doing some comparison prints with Paul's curves from both sRGB
and Adobe RGB awhile back and the differences in the prints was negligible
at the time.

Martin


----- Original Message -----
From: "jimhayes361" <jimhayes@...>
To: <DigitalBlackandWhiteThePrint@yahoogroups.com>
Sent: Thursday, June 27, 2002 5:32 PM
Subject: [Digital BW] Re: ps 6/7 bug:print change confirmed


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

Maybe you guys should use the same image for your tests, like a step wedge
from this lists files?

Are you all using the same operating systems? Do they all implement color
management similarly? in PS are you all using the same color engine for your
conversions, do you all have black point compensation checked (or not) and
dither checked (or not) and are they all set up the same for both PS 6 & 7?

Todd

> Jim,
> 
> Just to check on missing pieces I went back and did the file conversion and
> curve application in both PS6 and PS7 but to sRGB space this time. I used
> the same dark dominant image that gave a median of 44 in both versions of
> PS.
> 
> When I converted to sRGB I got the following:
> 
> PS6: Mean = 80.12, Std. Dev. = 81.25, Median = 37
> PS7: Mean = 79.85, Std. Dev. = 81.50, Median = 37
> 
> The PS6 to PS7 difference is similar to my earlier trial.
> 
> I did notice that when I took each of these converted files through the
> "Print Preview.." dialog in PS7 that the Source Space of the PS7 converted
> file showed up as "Untagged RGB" even though it had been converted to sRGB
> and a check with the "Convert to Profile..." dialog confirmed that it was
> indeed in sRGB space.
> 
> I don't know if any of this is helps but I wanted to get the data point.
> 
> At least the problem is not with your printer if you can still duplicate
> your earlier PS results.
> 
> I remember doing some comparison prints with Paul's curves from both sRGB
> and Adobe RGB awhile back and the differences in the prints was negligible
> at the time.
> 
> Martin
> 
> 
> ----- Original Message -----
> From: "jimhayes361" <jimhayes@...>
> To: <DigitalBlackandWhiteThePrint@yahoogroups.com>
> Sent: Thursday, June 27, 2002 5:32 PM
> Subject: [Digital BW] Re: ps 6/7 bug:print change confirmed
> 
> 
>> 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.

> Maybe you guys should use the same image for your tests, like a step wedge
> from this lists files?
I'd rather use an image.

> 
> Are you all using the same operating systems?
nope
>Do they all implement color
> management similarly?
they are supposed to.

>in PS are you all using the same color engine for your
> conversions, do you all have black point compensation checked (or not) and
> dither checked (or not) and are they all set up the same for both PS 6 & 7?
all set up the same for PS6 and 7 in my tests Todd.  each different thing,
intent, BPC, engine (already tested)...  (kept the same between the
versions) yeilds variance in the histo's luminousity.

as for keeping things constant between the tests others are doing,  you'd
have to include the inks and workflow, which I don't use.

But to see this difference in converion between PS versions is interesting.
Just don't think it relates to Jim's printing problem or at least isn't the
major cause.

Carolyn

--- In DigitalBlackandWhiteThePrint@y..., Todd Flashner <tflash@e...> 
wrote:
> Maybe you guys should use the same image for your tests, like a step 
wedge
> from this lists files?

This sounds like a good idea, standardize. Where I'm coming from is 
panic mode,this "test image" I've been using is a real print I was 
trying to get ready for a show. So naturally, I wanted to get the 
thing right so I could go on to frame it, etc as well as some other 
images. Last night in PS 6 I reprinted everything except for one or 
two images, and I can do those today.

Anyway, not having done any step wedges for this problem yet, I don't 
know how visible it would be. I suspect I would see an increased  
density change value somewhere along 70-80%k for PS 7, and maybe the 
50%k patch would look a tiny bit lighter in PS 7- but this last would 
be barely perceptable. Since I can see a definite change in my "test 
print" I know something is going on. If I can get to test wedges I 
will, at the moment I need to catch up on some other stuff.

> 
> Are you all using the same operating systems?

Win98SE for me.

 Do they all implement 
color
> management similarly?

That's what I've been trying to nail down. I've been using Adobe ACE, 
relative colometric for one example. And I think I have everything 
else the same now. Folks have been checking me out on this latter 
point.

 in PS are you all using the same color engine 
for your
> conversions, do you all have black point compensation checked

yes, checked.

 (or 
not) and
> dither checked

yes, checked.

 (or not) and are they all set up the same for both PS 
6 & 7?


Unfortunately, there are no discrepancies here that I can see. In the 
color management dialouge for BOTH 6 and 7 I chose "Photoshop 5 
defaults". I examined the advanced dialouge box for both 6 and 7 and 
rechecked over and over 5 or 6 times now that every choice was 
duplicated in each version.

One possible thing I did not check fully is that my image had three 
layers to it, and I converted to sRGB in one step. That is, I did not 
manually invoke the flatten image commend. When I seleted change mode 
to sRGB, a dialogue pops up asking if I want to merge image first, and 
I always chose "yes". I did this in both 6 and ver 7. It still creates 
a discrepancy since I did the step the same way in both versions, but 
does not remove it as a possible cause (ie if I flattened image first, 
would the change from 6 to 7 go away).
Jim H.

> 
> Todd
>

--- In DigitalBlackandWhiteThePrint@y..., Carolyn Frayn 
<carolynfrayn@s...> wrote:

> But to see this difference in converion between PS versions is 
interesting.
> Just don't think it relates to Jim's printing problem or at least 
isn't the
> major cause.
> 
> Carolyn

Who knows really? I used to work in R&D for HP (past lifetime). Got to 
 doing a LOT of electrical connector tests, esp gold plating 
environmental. I'm not a statistician, but I had a class or two, and 
was assigned one for much of my endless testing.

One thing I learned was that numbers can be operated on so that you 
just can't believe them. They can be made to say anything, just about.

If we see a tiny difference in the histo numbers it could mean a big 
OR insignifigant change in the data sent to printer. If we see a huge 
change in the histo, depending on how it is calculated, and how many 
points it is based on, and how it was origianlly skewed (dark or 
light?) it may mean a small or large change as well. Then there is the 
question as to how sensitive is Paul's workflow to changes in critical 
parts of the data (ie 3/4 tones maybe), and it's time to take a couple 
of asprin<g>. About the only thing I'm prepared to say right now is 
that there IS a change. I can also say I'm puzzled by my test prints 
here. That's safe to say<g>.

I want to believe I have something not set right in PS7- after all 
that would mean I could start using it again. Maybe that radio button 
or drop down box will turn up soon. Right now, time is a problem and 
I'm low on ink, so I can't run many more tests myself. I do want to 
thank everyone who has helped me so far in trying to resolve this.
Jim H.

Hi Carolyn,

We were just taking hacks from different angles of the issue. I was looking
at why the variance in the histograms might be greater for Jim than for
Martin or you, while you are looking at why his prints may differ more than
the difference in histo numbers would suggest. For what I'm looking at it's
important that you all are consistent to each other, for what you are
looking at it's only important that each person be consistent between each
version of PS.

But it looks like you've established the posterization is more a component
of how the print is made than the variance between the histos, so, good
work!

Todd

> 
>> Maybe you guys should use the same image for your tests, like a step wedge
>> from this lists files?
> I'd rather use an image.
> 
>> 
>> Are you all using the same operating systems?
> nope
>> Do they all implement color
>> management similarly?
> they are supposed to.
> 
>> in PS are you all using the same color engine for your
>> conversions, do you all have black point compensation checked (or not) and
>> dither checked (or not) and are they all set up the same for both PS 6 & 7?
> all set up the same for PS6 and 7 in my tests Todd.  each different thing,
> intent, BPC, engine (already tested)...  (kept the same between the
> versions) yeilds variance in the histo's luminousity.
> 
> as for keeping things constant between the tests others are doing,  you'd
> have to include the inks and workflow, which I don't use.
> 
> But to see this difference in converion between PS versions is interesting.
> Just don't think it relates to Jim's printing problem or at least isn't the
> major cause.
> 
> Carolyn

Hi back Todd... 

> We were just taking hacks from different angles of the issue. I was looking
> at why the variance in the histograms might be greater for Jim than for
> Martin or you, 

I get the same greater variance as Jim when converting to sRGB, same smaller
variance as Martin when conveting to Adobe RGB and my own CMYK versions also
get a small variance. small small...

>while you are looking at why his prints may differ more than
> the difference in histo numbers would suggest. For what I'm looking at it's
> important that you all are consistent to each other, for what you are
> looking at it's only important that each person be consistent between each
> version of PS.
yes... exactly.

> 
> But it looks like you've established the posterization is more a component
> of how the print is made than the variance between the histos, so, good
> work!

not so sure yet.  I'm posting something soon... I think the sRGB profile
used in Paul's workflow may be part of the problem.

Carolyn

> Some very quick thoughts. If you are comparing histos make sure the image
> cache prefs are identical for both PS versions.
hi Tyler... yes, I don't use cache for histos.

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

Cool... great thought.  I trashed all but one of each profile, there were
many, many versions... I kept the most current, and kept them in the
sys/app/adobe/color/profile/...recommended folder, that has the alias in the
colorsync folder.

so... I'll try to make my point without boring you.



FROM original multi profile burdened hard drive:

-----all conversions done using RelCol BPC and dither.



PS7: 
Gamma 2.2 file 

--mean 127.33
-- Std Dev 87.87
-- median 139

converted to Adobe 1998 file

-- mean 127.32
-- Std Dev 87.88
-- Median 139

converted to sRGB file

-- mean 126.91
-- Std Dev 89.42
-- median 140



PS6:  
Gamma 2.2 file 

-- mean 127.33
-- Std Dev 87.87
-- Median 139

converted to Adobe 1998 file

-- mean 127.33
-- Std Dev 87.87
-- median 139

converted to sRGB file

-- mean 127.19
-- Std Dev 89.06
-- median 140

***** this shows that with all these profiles on board the hard drive,
different PS versions may be picking different profile to do conversion..

*** it also shows sRGB is just not the profile to be using in a printing
workflow of any kind.


NOW>>>>>>  with all profiles except one trashed, so that both PS's are
forced to use the same profiles:

PS7: 
Gamma 2.2 file 

--mean 127.33
-- Std Dev 87.87
-- median 139

converted to Adobe 1998 file

-- mean 127.32
-- Std Dev 87.87
-- Median 139

converted to sRGB file

-- mean 126.91
-- Std Dev 89.42
-- median 140



PS6:  
Gamma 2.2 file 

-- mean 127.33
-- Std Dev 87.87
-- Median 139

converted to Adobe 1998 file

-- mean 127.33
-- Std Dev 87.87
-- median 139

converted to sRGB file

-- mean 127.19
-- Std Dev 89.06
-- median 140



There is only one difference in this set using one profile compared to the
first set with the many profiles installed... PS7 has converted to Adobe
1998 exactly the same as in PS6 this time.

and this shows again that sRGB is doing strange conversions in my mind, why
not stick with Adobe 1998 for less data change or loss.


It's not the different versions in my mind, (and now as this shows, using
the same Adobe1998 profiles makes those conversions identical) it's the sRGB
conversions that are strange.  this workflow Jim is using is a gamma2.2 to
sRGB workflow. 



>Make sure both destination spaces are the identical profile before
> assuming the conversion is at fault.

Using the wrong RBG workspace in this workflow is at fault in my mind.

still awake?
Carolyn

Hey Tyler,  just how many times can one say "in my mind" in one post and
still be taken seriously?  Have to quit writing so late...
damn.
Carolyn

Carolyn,

In my mind Tyler seems to have spotted Jim's problem and you have confirmed
it.

I took my files all the way to a print. These were the 2.2 grayscale to sRGB
in PS6 and then in PS7 which showed some slight variation in Mean and Std.
Dev. which in my mind is probably too small to be important. I then printed
out both converted files in PS7 and the PS6 converted file in PS6 giving me
three prints. After letting them season overnight and I took them outside in
open shade to view. They are all identical as far as I can tell.

The remaining question is where are all these various profiles are stored in
Win98SE. In Win2000 the ICC profiles seem to mainly be stored in the
C:\WINNT\System32\spool\drivers\color folder. I installed PS7 without
removing PS6 but I only have single copies of the Adobe RGB and sRGB ICC
files. A files search on *.ic* should turn them up for Jim.

I had a similar problem with versions of Silverfast where key files from the
older version had been left in odd places in the OS directory.

As to why we are in sRGB in the first place, this is a carry over from
Paul's start on the RGB separation curves when he was using PS5 I believe. I
have switched to Adobe RGB and while there is a slight difference, the
curves seem to work just fine. In my mind that is. Same for Tyler's 1280
curves. These were also designed for sRGB but a change to Adobe RGB doesn't
seem to make a great deal of difference. This assumes you start working the
image from scratch in one space or the other. If you work it up to print
from one and then try and print it from the other I would expect to see some
differences.

Thanks,
Martin


----- Original Message -----
From: "Carolyn Frayn" <carolynfrayn@...>
To: <DigitalBlackandWhiteThePrint@yahoogroups.com>
Sent: Friday, June 28, 2002 11:17 PM
Subject: Re: [Digital BW] Re: ps 6/7 bug:print change confirmed


> Hey Tyler,  just how many times can one say "in my mind" in one post and
> still be taken seriously?  Have to quit writing so late...
> damn.
> Carolyn
>
>
>
>
> 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/
>
>
>

Martin,

One other point to bear in mind is that the Registry entries may determine
which profile is being used. You can delete or change the actual profile in
the color folder, but unless these are unregistered or the new one
registered, you may not be getting the effects you want!

In XP (and probably 2000) the relevant entries seem to be under
Hkey_local_machine/software/microsoft/windowsNT/Current version/ICM. A
search for ICM in the 98 Registry will show their location.

Bob Frost

----- Original Message -----
From: "Martin Wesley" <mwesley250@...>


>
> The remaining question is where are all these various profiles are stored
in
> Win98SE. In Win2000 the ICC profiles seem to mainly be stored in the
> C:\WINNT\System32\spool\drivers\color folder. I installed PS7 without
> removing PS6 but I only have single copies of the Adobe RGB and sRGB ICC
> files. A files search on *.ic* should turn them up for Jim.
>
> I had a similar problem with versions of Silverfast where key files from
the
> older version had been left in odd places in the OS directory.

Hi Martin,

> 
> In my mind Tyler seems to have spotted Jim's problem and you have confirmed
> it.

My tests showed that even with the exact profiles being used the  sRGB is
playing with the numbers far more than Adobe RGB between the two versions...
that there were the same variances with the sRGB conversion.  The only
difference making sure only one copy of a profile was on board was to the
Adobe1998 conversions, making them identical between versions.

So I don't think it's the multi profile problem, I think it's the 'way' the
two versions of PS are converting to the sRGB file, making them different in
each version.

I was hoping that Jim would convert his same gamma2.2 file to AdobeRGB
instead of the sRGB in both versions, run the prints and see if that made a
difference to his output, kept them similair.

> I took my files all the way to a print. These were the 2.2 grayscale to sRGB
> in PS6 and then in PS7 which showed some slight variation in Mean and Std.
> Dev. which in my mind is probably too small to be important. I then printed
> out both converted files in PS7 and the PS6 converted file in PS6 giving me
> three prints. After letting them season overnight and I took them outside in
> open shade to view. They are all identical as far as I can tell.

Yes, that's what I found with my print tests, althought I did not go thru
the quad partitioned workflow. Identical, even with the smaller variance in
histos. so in my mind if Jim were to do the above, convert his Gamma2.2 to
Adobe1998 after converting/printing from both versions this should tell him
if it's the sRGB conversion messing up his file too much.

Best,
Carolyn

--- In DigitalBlackandWhiteThePrint@y..., "Martin Wesley" 
<mwesley250@e...> wrote:
<snip>
 I then 
printed
> out both converted files in PS7 and the PS6 converted file in PS6 
giving me
> three prints. After letting them season overnight and I took them 
outside in
> open shade to view. They are all identical as far as I can tell.

Strange that I'm the only one that can print a difference.

 A files search on *.ic* should turn them up for Jim.

Win98SE....

After doing this I came up with only one instance of "srgb Color Space 
Profile.icc" dated 4/23/99, in the c:\windows\system\color folder.

There was another interesting profile, something like "photoshop 5 
defaultscmyk.icc" (also a PS4 defaults) in I think the common 
files\Adobe subfolder (didn't jot it down). I figured this didn't 
apply, but I mention it for completeness. Could it select this when 
PS5 defaults are selected in the color settings in PS7 or 6 and lump 
the profiles for all the modes together in this one icc file? Could 
then the srgb component of the "default icc" file differ from the srgb 
file under the system\color folder?

I searched in the registry, I remember the path to the ICM, but just 
saw numbers, no directory paths or file names. Perhaps I'm not skilled 
enough to find stuff here, but since I only turned up one srgb icc 
file, it may be moot.


> 
> As to why we are in sRGB in the first place, this is a carry over 
from
> Paul's start on the RGB separation curves when he was using PS5 I 
believe. I
> have switched to Adobe RGB and while there is a slight difference, 
the
> curves seem to work just fine.




  This assumes you start 
working the
> image from scratch in one space or the other. If you work it up to 
print
> from one and then try and print it from the other I would expect to 
see some
> differences.

Does this mean for already finished images I am pretty much stuck with 
srgb or will something like a transform curve work? Or just squint a 
little if the diff is negilible. The only real problem I have with my 
one image is posterization, I don't mind too much that PS7 makes it 
darker. Or should Paul redo the curves? I thought the specs on MIS 
site for PC still said to use srgb.

If I'm stuck with srgb, the next time I upgrade my OS or something 
similar, but keep PS 6, will I have a different srgb file converting 
my images so all the old ones are no longer valid?

If so, it would be wise to convert ALL my images (that show a 
difference, if I can tell that without printing every one over) now in 
PS6, and store them up on a bunch of CD's, so that the magic 
conversion is already done when opened again, so I can use Paul's 
curves to print in PS7, PS8, etc.
Jim H.

 
 
> 
> Thanks,
> Martin
> 
> 
> ----- Original Message -----
> From: "Carolyn Frayn" <carolynfrayn@s...>
> To: <DigitalBlackandWhiteThePrint@y...>
> Sent: Friday, June 28, 2002 11:17 PM
> Subject: Re: [Digital BW] Re: ps 6/7 bug:print change confirmed
> 
> 
> > Hey Tyler,  just how many times can one say "in my mind" in one 
post and
> > still be taken seriously?  Have to quit writing so late...
> > damn.
> > Carolyn
> >
> >
> >
> >
> > 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/

> >
> >
> >

--- In DigitalBlackandWhiteThePrint@y..., Carolyn Frayn 
<carolynfrayn@s...> wrote:
<snip>
  The 
only
> difference making sure only one copy of a profile was on board was 
to the
> Adobe1998 conversions, making them identical between versions.
> 
> So I don't think it's the multi profile problem, I think it's the 
'way' the
> two versions of PS are converting to the sRGB file, making them 
different in
> each version.
> 
> I was hoping that Jim would convert his same gamma2.2 file to 
AdobeRGB
> instead of the sRGB in both versions, run the prints and see if that 
made a
> difference to his output, kept them similair.


I guess I should do this, since I seem to have been doing pictures on 
a flawed workflow. On at least the one print. Wonder how many it would 
show up on? 

 They are all identical as far as I can tell.
> 
> Yes, that's what I found with my print tests, althought I did not go 
thru
> the quad partitioned workflow. Identical, even with the smaller 
variance in
> histos. so in my mind if Jim were to do the above, convert his 
Gamma2.2 to
> Adobe1998 after converting/printing from both versions this should 
tell him
> if it's the sRGB conversion messing up his file too much.

I will se what I can do.
Jim H.

> 
> Best,
> Carolyn

--- In DigitalBlackandWhiteThePrint@y..., Carolyn Frayn <carolynfrayn@s...> wrote:
> Hey Tyler,  just how many times can one say "in my mind" in one post and
> still be taken seriously?  Have to quit writing so late...
> damn.
> Carolyn

Well, untill we all stop screwing around and start putting something worth looking at on paper, it's all in our minds anyway. 
Let me further confuse the collective mind here. I have a file I use frequently that is a grid of solid patches, 1 to 100% gray 
scale, each patch a solid tone. 2.2 gamma grayscale.
When I convert that to sRGB with dither checked, uh, why are some of the patches no longer solid tone? One of the worst 
here is 39%. Made a new file and filled it with solid 39% gray, check histo to make sure that's correct, converted as above, 
histo shows some slight variation now, clustered around that tone, and I can see the bumpiness on my monitor.
The same conversion but to AdobeRGB also shows some variation, but much less. Conversion to either space without dither 
does not show the problem.
So converting to sRGB from gray with dither is turning individual tones into "some tones". Now what happens when yanking 
all that around with severe sep curves? Does it matter?
Further tests reveal that sRGB and gray 2.2 gamma do not precisely map to each other without moving some tones, and 
AdobeRGB and 2.2 gray do. So they are not directly interchangeable for quad work as I first assumed from their 2.2 spec.
Even though sRGB is useless for anything other than it's intended web use, and now it's being shoved down our throats as 
digital camera spaces, I'm not positive it's useless for quad work since gamut mapping is not an issue.
However since gray 2.2 does not map precisely to it without moving some tones, I would use Adobe instead if it doesn't 
screw up your current results, and I'd certainly turn that stinkin dither off.
Better yet, stick to 16 bit, sorry Todd.
C. D. Tobie could certainly tell you more about the foisting of sRGB upon us, and why Adobe ever made it a "default". They 
backed away from that quickly, and those unfamilier with events and the complexities of working spaces wound up still 
assuming it was advised.
Tyler, stuck in his mind

or as some would say, stuck with my head up my...

Bob,

Thanks for pointing that out. I tend not to think of the registry because I
hate the thought of mucking around in there.

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



----- Original Message -----
From: "Bob Frost" <bobfrost@...>
To: <DigitalBlackandWhiteThePrint@yahoogroups.com>
Sent: Saturday, June 29, 2002 2:12 AM
Subject: Re: [Digital BW] Re: ps 6/7 bug:print change confirmed


> Martin,
>
> One other point to bear in mind is that the Registry entries may determine
> which profile is being used. You can delete or change the actual profile
in
> the color folder, but unless these are unregistered or the new one
> registered, you may not be getting the effects you want!
>
> In XP (and probably 2000) the relevant entries seem to be under
> Hkey_local_machine/software/microsoft/windowsNT/Current version/ICM. A
> search for ICM in the 98 Registry will show their location.
>
> Bob Frost
>
> ----- Original Message -----
> From: "Martin Wesley" <mwesley250@...>
>
>
> >
> > The remaining question is where are all these various profiles are
stored
> in
> > Win98SE. In Win2000 the ICC profiles seem to mainly be stored in the
> > C:\WINNT\System32\spool\drivers\color folder. I installed PS7 without
> > removing PS6 but I only have single copies of the Adobe RGB and sRGB ICC
> > files. A files search on *.ic* should turn them up for Jim.
> >
> > I had a similar problem with versions of Silverfast where key files from
> the
> > older version had been left in odd places in the OS directory.
>
>
>
>
> 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/
>
>
>

--- In DigitalBlackandWhiteThePrint@y..., "jimhayes361" 
<jimhayes@j...> wrote:
> --- In DigitalBlackandWhiteThePrint@y..., Carolyn Frayn 
> <carolynfrayn@s...> wrote:
> <snip>

> > I was hoping that Jim would convert his same gamma2.2 file to 
> AdobeRGB
> > instead of the sRGB in both versions, run the prints and see if 
that 
> made a
> > difference to his output, kept them similair.
> 

The two prints done in Adobe 98 are only two hours dry but here is 
what it looks like it may be:

first, here are the values for the histos, with the same Paul's curve 
applied after conversion...


PS6/Adobe98: mean=47.87 SD=70.61 median=12
PS7/Adobe98: mean=47.83 SD=70.63 median=12
PS6/srgb:    mean=46.83 SD=71.55 median=10
PS7/srgb:    mean=45.57 SD=72.27 median=8

Puzzling that there is a difference using Adobe98, and I think there 
is only one version of the space on the computer.

Before I tell you what happened, I'm going to fill you all in on more 
of the history behind the image. It is a triple seamless montage of 
three hands, all shot with a Canon G2 during the same session. The 
background is dark, as is most of the image. I like it that way, but 
it started out as a misfiring of a flash that I didn't erase from the 
CF card. The background has been boosted up a little. The camera works 
in 10 bit mode, so I have a little headroom in pshop 16 bit to tune 
it. I also used Genuine Fractals to enlarge image to correct size from 
the native 4 mp CCD.

However, the camera like the Canon D30, has a habit of introducing 
banding in low key areas, and it gets worse with multiple shots , as 
camera warms. I was lucky to realize when I first printed this in 
Febuary with PS6/srgb, that the banding was barely visible, and 
certainly acceptable.

Okay, end of lecture. When I examine the four prints,

PS6/srgb: best print, no or little posterization. Good tones. Some 
banding can be seen if you know what to look for- my wife as impartial 
judge searched long and couldn't see any banding or cordury.

PS7/srgb: posterization, ugly. Shadow background a little darker than 
above. Wife can't see any cordury or banding. She sees the 
posterization- no problem, like an um, a sore thumb.

Ps6/Adobe98: Not bad really. The tones are off from the PS6/srgb 
print, but nothing that isn't within artistic interpretation or 
whatever you want to call it (darkroom fudge factor?). I rather like 
it except for two small areas where the transition is not as smooth as 
the PS6/srgb print and a tiny bit of posterization occurs- this takes 
a critical eye to spot. Wife sees no banding. I don't think she would 
have seen the posterization either.

PS7/Adobe98: Something odd. The print looks identical to the 
PS6/Adobe98 print except that in one area especially, microbanding 
shows up in a 3/4 tone area. I don't know if this is due to the camera 
noise or not, but it looks sharper and finer- more like microbanding 
than cordury. Lest you think I'm overly picky, I took all four print 
samples and layed them on a mat board, handed it to my wife who stood 
under a sunlit skylight with a sunny sky. After about 20 seconds  
without hinting she easily "labeled" the microbanding in ONLY the 
PS7/Adobe98 print in one area. Then I prodded her to find the 
cordury/banding in the other three images and in the noisiest areas of 
the all four, even pointing them out, but she couldn't see them.

I checked the images myself under my good old Vison saver Ott-lite and 
 I had to agree, although I could see all the banding- it was more 
prominent on the PS7/Adobe98 print in one 3/4 tone area. I don't know 
if the camera noise is masking the microbanding in other areas of the 
PS7/Adobe98 print or if the microbanding just occurs in one roughly 3 
x 3 inch area. 

In fact I saw it right out of the printer, and thinking something 
amiss with the inkflow, did an immediate nozzle check which came out 
perfect. So if it was due to a misfiring nozzle, it cleared up before 
print was done (could be I guess <shrug>).

I don't know if that helps, I think I am rather adding to the 
confusion. My computer seems to, in it's mind, want me to use PS6, 
whatever the profile.<g>
Jim H.

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

From: "jimhayes361" <jimhayes@...>
To: <DigitalBlackandWhiteThePrint@yahoogroups.com>
Sent: Saturday, June 29, 2002 8:20 AM
Subject: [Digital BW] Re: ps 6/7 bug:print change confirmed


> --- In DigitalBlackandWhiteThePrint@y..., "Martin Wesley"
> <mwesley250@e...> wrote:
> <snip>
>  I then
> printed
> > out both converted files in PS7 and the PS6 converted file in PS6
> giving me
> > three prints. After letting them season overnight and I took them
> outside in
> > open shade to view. They are all identical as far as I can tell.
>
> Strange that I'm the only one that can print a difference.
>
Something is going on in your system. It is just a matter of isolating it.
Are you running the most recent version of the 1280 driver? Since W2k and
W98 use different versions of the driver I wonder if that could be a factor.

>  A files search on *.ic* should turn them up for Jim.
>
> Win98SE....
>
> After doing this I came up with only one instance of "srgb Color Space
> Profile.icc" dated 4/23/99, in the c:\windows\system\color folder.
>
> There was another interesting profile, something like "photoshop 5
> defaultscmyk.icc" (also a PS4 defaults) in I think the common
> files\Adobe subfolder (didn't jot it down). I figured this didn't
> apply, but I mention it for completeness. Could it select this when
> PS5 defaults are selected in the color settings in PS7 or 6 and lump
> the profiles for all the modes together in this one icc file? Could
> then the srgb component of the "default icc" file differ from the srgb
> file under the system\color folder?
>
> I searched in the registry, I remember the path to the ICM, but just
> saw numbers, no directory paths or file names. Perhaps I'm not skilled
> enough to find stuff here, but since I only turned up one srgb icc
> file, it may be moot.

I would agree. Even if there is a registry entry point to a different
version if it is not on your hard drive it should not be an issue. I really
don't like to mess with the registry directly in any case.
>
>
> >
> > As to why we are in sRGB in the first place, this is a carry over
> from
> > Paul's start on the RGB separation curves when he was using PS5 I
> believe. I
> > have switched to Adobe RGB and while there is a slight difference,
> the
> > curves seem to work just fine.
>
>
>
>
>   This assumes you start
> working the
> > image from scratch in one space or the other. If you work it up to
> print
> > from one and then try and print it from the other I would expect to
> see some
> > differences.
>
> Does this mean for already finished images I am pretty much stuck with
> srgb or will something like a transform curve work? Or just squint a
> little if the diff is negilible. The only real problem I have with my
> one image is posterization, I don't mind too much that PS7 makes it
> darker. Or should Paul redo the curves? I thought the specs on MIS
> site for PC still said to use srgb.

I think you have to give it a try. I would expect some differences but they
may be image dependent. Perhaps do your print from sRGB and then a print
from Adobe RGB and then tweak the Adobe RGB to match. This might lead you to
a single curve or levels action you could just apply to all your images that
you have adjusted to work from sRGB.
>
> If I'm stuck with srgb, the next time I upgrade my OS or something
> similar, but keep PS 6, will I have a different srgb file converting
> my images so all the old ones are no longer valid?

You might just want to abandon sRGB at this point. As you need to do
reprints, do them from Adobe RGB and assess the results. I usually find in
cases like this I want to change something. Even in this digital world I
always seem to have a slightly different take on a image when I haven't
printed it in awhile. Remember that in the darkroom the odds of coming back
several months later to make another print from a negative always results in
something slightly different than the time before. There is just too much
variation in the materials. Just go for the most pleasing result with the
new workflow.
>
> If so, it would be wise to convert ALL my images (that show a
> difference, if I can tell that without printing every one over) now in
> PS6, and store them up on a bunch of CD's, so that the magic
> conversion is already done when opened again, so I can use Paul's
> curves to print in PS7, PS8, etc.

I would just address them one by one as they come up. If you are reprinting
the image a year from now the odds are very high that you will have a
different batch of paper, possibly a different ink set or certainly a
different batch and even maybe a new printer model. Given all of that you
are going to need to make adjustments to your image file and the added
adjustments you need to make for the switch to Adobe RGB from sRGB will be a
small part of that process. Just keep moving forward. There is too much to
do to go back and compensate for a color space change in all you files until
you need to do it.

Martin

(snip)

--- In DigitalBlackandWhiteThePrint@y..., "Martin Wesley" 
<mwesley250@e...> wrote:
> 
> ----- Original Message -----
> From: "jimhayes361" <jimhayes@j...>

> > Strange that I'm the only one that can print a difference.
> >
> Something is going on in your system. It is just a matter of 
isolating it.
> Are you running the most recent version of the 1280 driver? Since 
W2k and
> W98 use different versions of the driver I wonder if that could be a 
factor.


I think it's version 6.0be. I downloaded file "sph12809598me60be.exe" 
on Jan 3, 2002.

> 
> >  A files search on *.ic* should turn them up for Jim.
> >
> > Win98SE....
> >
> > After doing this I came up with only one instance of "srgb Color 
Space
> > Profile.icc" dated 4/23/99, in the c:\windows\system\color folder.

> >
> > I searched in the registry, I remember the path to the ICM, but 
just
> > saw numbers, no directory paths or file names. Perhaps I'm not 
skilled
> > enough to find stuff here, but since I only turned up one srgb icc
> > file, it may be moot.
> 
> I would agree. Even if there is a registry entry point to a 
different
> version if it is not on your hard drive it should not be an issue. I 
really
> don't like to mess with the registry directly in any case.


Well there is one other piece of dirty laundry I'll air, since we're 
Sherlocking my computer. I started using Photocal along with a new 
monitor a couple of months ago. Except I have a photocal bug- it goes 
through the pushups, then dumps out and won't save my profile after 
the first time. In fact it tries to hide the original Photocal 
profile. The photocal upper tech told me that it was not a problem 
with their software but that my color subfolder didn't match my 
registry. I didn't want to face fixing that so the work around is to 
backup registry, then delete one key that references the photocal 
profile, then run photocal, and manually associate the profile with 
the monitor when done. I really don't mind the workaround.

This probably has no bearing on anything whatsoever, but I add it for 
completeness sake, since we are talking matching up profiles to 
registry entries.
 
<snip>
 or will something like a transform curve work? Or just squint 
a
> > little if the diff is negilible. The only real problem I have with 
my
> > one image is posterization, I don't mind too much that PS7 makes 
it
> > darker. Or should Paul redo the curves? I thought the specs on MIS
> > site for PC still said to use srgb.
> 
> I think you have to give it a try. I would expect some differences 
but they
> may be image dependent. Perhaps do your print from sRGB and then a 
print
> from Adobe RGB and then tweak the Adobe RGB to match. This might 
lead you to
> a single curve or levels action you could just apply to all your 
images that
> you have adjusted to work from sRGB.

See my last post. I am mystefied by the microbanding...


> 
> You might just want to abandon sRGB at this point. As you need to do
> reprints, do them from Adobe RGB and assess the results.

See my last post where oddly I get microbanding using PS7/Adobe98 on 
my test print. PS6/Adobe98 is not too bad.

 I usually 
find in
> cases like this I want to change something.

Wise words. Yes, I know the drill from my darkroom days, couldn't even 
count on the paper to be consistant from lot to lot.


 Even in this digital 
world I
> always seem to have a slightly different take on a image when I 
haven't
> printed it in awhile. Remember that in the darkroom the odds of 
coming back
> several months later to make another print from a negative always 
results in
> something slightly different than the time before.

Yeah I know, it's all true, sage one.<g> I've changed digital images 
from the mid-late 90's a lot. After almost two years with Piezo and 
then MIS, it just seems like there's so many bandaids all over the 
workflow/inksets/printers. Amazing we can even get inconsistant prints 
out of those heads.

In a way, I look hopefully toward the 2200 if it truely gives a one 
stop one vendor solution. The cynic in me is whispering that something 
will go wrong...orange prints, $$$$prints, metamerism, dull blacks, I 
don't want to think of all the things maybe promised, maybe delivered, 
maybe not. 


 There is just too 
much
> variation in the materials. Just go for the most pleasing result 
with the
> new workflow.

Yes wise. What was that about the booze? Here in Colorado with all the 
fires you know we need some cooling down. Margueritas? Salt?

> >
> > If so, it would be wise to convert ALL my images (that show a
> > difference, if I can tell that without printing every one over) 
now in
> > PS6, and store them up on a bunch of CD's, so that the magic
> > conversion is already done when opened again, so I can use Paul's
> > curves to print in PS7, PS8, etc.
> 
> I would just address them one by one as they come up. If you are 
reprinting
> the image a year from now the odds are very high that you will have 
a
> different batch of paper, possibly a different ink set or certainly 
a
> different batch and even maybe a new printer model. Given all of 
that you
> are going to need to make adjustments to your image file and the 
added
> adjustments you need to make for the switch to Adobe RGB from sRGB 
will be a
> small part of that process. Just keep moving forward. There is too 
much to
> do to go back and compensate for a color space change in all you 
files until
> you need to do it.


Yeah, I got a little frustrated. It's no different then the darkroom, 
just a little less wet. I'm just going to print this image out in 
PS6/srgb cause it looks best that way now. I'll switch over to 
PS7/Adobe98 NEXT time I do a real print and see if the microbanding 
shows up, I'm rationing my ink now, can't waste anymore til after 
vacation.

Cheers Amigo,
Jim H.

> 
> Martin
> 
> (snip)

on 6/29/02 1:54 PM, tboleyyh wrote:

> However since gray 2.2 does not map precisely
> to it without moving some tones, I would use Adobe instead if it doesn't
> screw up your current results, and I'd certainly turn that stinkin dither
> off. Better yet, stick to 16 bit, sorry Todd.


Ouch. Double ouch!

Good post, as always, Tyler, though I'm not sure I agree with the bit depth
conclusion. (Surprise, surprise <g>)

Two things are missing from your experiment, A) that doing the conversion in
16-bit mode improves the situation, B) that the improvement shows in print.

First off, let me restate my position on 16-bit editing. I just think 8-bit
editing is too often looked at as the primary cause of posterized prints and
I think that's more attention than it deserves. I still believe that.
However, I don't walk a tightrope without a net, so I scan in 16-bits, work
my images globally in 16-bits leaving local edits with masks to 8-bit mode,
and always have a 16-bit backup close at hand.

Anyway, post encouraged me to see if it's time for me to rethink things, but
based on my tests (surely NOT exhaustive), I'm not compelled to.
Furthermore, and consistent with my recommended approach to making bit depth
assessments, I'd put a portion of what little money I have to bet that if
Jim does everything he's doing now in the same way--except for maintaining a
16-bit workflow--he will still get the same result in print. My bottom line
has always been the print, not the histogram.

Now, back to the 16 bit for conversions...Since I don't have your test
pattern I just opened a 16-bit image with a predominance of dark tones (as
though a broody guy like me has any other type of images ;-)


The image was 16-bit grayscale, gamma 2.2, which I then downsampled to
8-bit.

           

            Mean     St. Dev.    Median

Grayscale
g 2.2       

16-bit:     86.40    68.42       84
8-bit:      86.40    68.43       84

16-bit
to sRGB:    85.82    69.81       83

8-bit
to sRGB
dither:     85.83    69.80       83

8-bit
to sRGB
no dither   85.78    69.74       83

The conversion to sRGB is no better in 16-bit mode than 8-bit with dither.

16-bit
to Adobe:   86.40    68.43       84

8-bit
to Adobe
dither:     86.40    68.42       84

8-bit
to sRGB
no dither:  86.40    68.42       84

The conversion to AdobeRGB is no better in 16-bit mode than 8-bit with or
without dither.

I also tried all of the above with different rendering intents and color
engines, neither of which changed any of the above numbers.

So, what do I take from this? A) it matters more what spaces we convert
between than what bit mode we do it from. B) for my type of image the dither
seemed only to help. C) I don't think Jim's problem is due to his
conversion, I think it's in his print-driver/driver-settings.

Todd

on 6/29/02 8:10 PM, Todd Flashner wrote:

> B) for my type of image the dither
> seemed only to help.


BTW, I didn't mean for this to refute what you (Tyler) found about the
dither. On the contrary, I found your results very interesting. I guess it
just points to how image dependent so much of this stuff can be, and by what
numbers or characteristics we judge these things by.

Todd

--- In DigitalBlackandWhiteThePrint@y..., Todd Flashner <tflash@e...> wrote:
...
> > off. Better yet, stick to 16 bit, sorry Todd.
> 
> 
> Ouch. Double ouch!
I failed to make my point, or mislead. The only reference I intended to 16 bit was that it doesn't allow you to select dither 
during conversions so that "problem" is avoided. Mentioning you was just a little ribbing.

> Two things are missing from your experiment, A) that doing the conversion in
> 16-bit mode improves the situation,
see above

> B) that the improvement shows in print.
Different issue. The weirdness I found in the dithering conversion was a side observation. I don't think it's related to Jim's 
problem, which frankly I had forgotten all about. Whether or not this mottling within a single tone shows up in a print, I 
don't know, which is why I asked if it mattered. It doesn't to me, because I don't work in 8 bit. For those who do, it might be 
worth looking at if you have no life, but it's unrelated to Jim's problem.

> First off, let me restate my position on 16-bit editing.
Oh goody

> I just think 8-bit
> editing is too often looked at as the primary cause of posterized prints and
> I think that's more attention than it deserves.
I agree, and frankly have never entered those discussions. I think most of the problems are in the scans and the sep 
methods.
Regarding the rest of your test and post, I'm sure it's correct. Again, I wasn't speaking to that, really only two things. One, 
sRGB doesn't seem to be an exact match to gray 2.2, some tones will move. AdobeRGB does seem to be the same, at least on 
my system. Two, when converting with dither, there seems to be some sprinkling of just off tone values in what should have 
been solid values. For normal PS color work, this may be as intended, it's dithering after all. For quad work it seems 
undesirable to me, but I'm not positive if it would show up in a print and am not about to blow time figuring it out. It may be 
worth someone's time if they feel that option needs to be left on.
Again, all of this is tangential to Jim's original problem, which Carolyn addressed far more thoroughly than I.
And now, let me state my position on 16-bit editing (a rousing "oh goodie" please). I just don't see the big deal, it's no skin 
off my nose to stay in 16 bit for everything, and I saw improvement in some early tests on paper, done deal. So rather than 
investigate it to the nth degree, and commit precious time and materials to doing battle with internet gurus, I'd rather just 
use it and make prints the best possible way I know how. Was using Amidol instead of Dektol a provable advantage? Was it 
in the users mind? Don't care any more, we all have to follow our little obsessions.
If you ever have to output to an LVT though, you will care about that histo.

> So, what do I take from this? A) it matters more what spaces we convert
> between than what bit mode we do it from.
Right, however, if they are not identical tonally, some tones will move. Whether or not that is destructive, and needs to be 
done in high bit puts us back to your 16/8 issue.

>B) for my type of image the dither
> seemed only to help. 
Just for curiosity's sake, you might fill a file with 39% gray, covert it to sRGB with dither, and take a look at it. Pull it apart 
with levels and you'll see what I mean. Again, it's unrelated to Jim or tonal conversion comparisons like you were making.

C) I don't think Jim's problem is due to his
> conversion, I think it's in his print-driver/driver-settings.
My apologies to Jim, I lost his problem somewhere along the way. I just observed some odd things and was yakking. 
Overall Jim's problem is of interest because most of us will wind up on PS7 at some point, it'd be nice to avoid problems. If 
everything about the conversion is identical, source and destinations spaces, engine, intent, etc., it seems to me PS and 
what version it is is out of the picture, could be wrong.
Tyler

on 6/29/02 9:56 PM, tboleyyh wrote:

>> B) for my type of image the dither
>> seemed only to help.
> Just for curiosity's sake, you might fill a file with 39% gray, covert it to
> sRGB with dither, and take a look at it. Pull it apart
> with levels and you'll see what I mean. Again, it's unrelated to Jim or tonal
> conversion comparisons like you were making.


Okay, I tried it. You're right, I don't like it. But one really shouldn't do
such drastic Levels moves in 8-bit mode you know. <he he, I'm ducking>

As for the rest of your post, I agree. Unfortunately that includes the fact
I continually find myself in the activity room for people with no life. :-(

Todd

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

From: "jimhayes361" <jimhayes@...>
To: <DigitalBlackandWhiteThePrint@yahoogroups.com>
Sent: Saturday, June 29, 2002 4:25 PM
Subject: [Digital BW] Re: ps 6/7 bug:print change confirmed


> --- In DigitalBlackandWhiteThePrint@y..., "Martin Wesley"
> <mwesley250@e...> wrote:
> >
> > ----- Original Message -----
> > From: "jimhayes361" <jimhayes@j...>
>
> > > Strange that I'm the only one that can print a difference.
> > >
> > Something is going on in your system. It is just a matter of
> isolating it.
> > Are you running the most recent version of the 1280 driver? Since
> W2k and
> > W98 use different versions of the driver I wonder if that could be a
> factor.
>
>
> I think it's version 6.0be. I downloaded file "sph12809598me60be.exe"
> on Jan 3, 2002.

That's the latest one, so I guess that factor is eliminated.
>

(snip)
> >
> > I would agree. Even if there is a registry entry point to a
> different
> > version if it is not on your hard drive it should not be an issue. I
> really
> > don't like to mess with the registry directly in any case.
>
>
> Well there is one other piece of dirty laundry I'll air, since we're
> Sherlocking my computer. I started using Photocal along with a new
> monitor a couple of months ago. Except I have a photocal bug- it goes
> through the pushups, then dumps out and won't save my profile after
> the first time. In fact it tries to hide the original Photocal
> profile. The photocal upper tech told me that it was not a problem
> with their software but that my color subfolder didn't match my
> registry. I didn't want to face fixing that so the work around is to
> backup registry, then delete one key that references the photocal
> profile, then run photocal, and manually associate the profile with
> the monitor when done. I really don't mind the workaround.
>
> This probably has no bearing on anything whatsoever, but I add it for
> completeness sake, since we are talking matching up profiles to
> registry entries.

For cleaning up something like this I have had good luck with Norton
WinDoctor part of Norton's System Works. Seems to do a good job of tracking
down problem entries in the registry and fixing them safely.
>
> <snip>
>  or will something like a transform curve work? Or just squint
> a
> > > little if the diff is negilible. The only real problem I have with
> my
> > > one image is posterization, I don't mind too much that PS7 makes
> it
> > > darker. Or should Paul redo the curves? I thought the specs on MIS
> > > site for PC still said to use srgb.
> >
> > I think you have to give it a try. I would expect some differences
> but they
> > may be image dependent. Perhaps do your print from sRGB and then a
> print
> > from Adobe RGB and then tweak the Adobe RGB to match. This might
> lead you to
> > a single curve or levels action you could just apply to all your
> images that
> > you have adjusted to work from sRGB.
>
> See my last post. I am mystefied by the microbanding...

That is weird. I guess all you can do is try a file that is derived from a
neg and scan rather than a digital camera and see what you get.
(snip)
>
> In a way, I look hopefully toward the 2200 if it truely gives a one
> stop one vendor solution. The cynic in me is whispering that something
> will go wrong...orange prints, $$$$prints, metamerism, dull blacks, I
> don't want to think of all the things maybe promised, maybe delivered,
> maybe not.

Ditto. I suspect that metamerism will be the killer and the advertised life
of the prints is not going to compete in a silver dominated world.
>
>
(snip)
>
> Yes wise. What was that about the booze? Here in Colorado with all the
> fires you know we need some cooling down. Margueritas? Salt?

Just grab some of your favorite poison, go side out in the sun for awhile
and don't think about any of this for awhile. Sovereign remedy for inkjet
printing.
>
> > >
> > > If so, it would be wise to convert ALL my images (that show a
> > > difference, if I can tell that without printing every one over)
> now in
> > > PS6, and store them up on a bunch of CD's, so that the magic
> > > conversion is already done when opened again, so I can use Paul's
> > > curves to print in PS7, PS8, etc.
> >
> > I would just address them one by one as they come up. If you are
> reprinting
> > the image a year from now the odds are very high that you will have
> a
> > different batch of paper, possibly a different ink set or certainly
> a
> > different batch and even maybe a new printer model. Given all of
> that you
> > are going to need to make adjustments to your image file and the
> added
> > adjustments you need to make for the switch to Adobe RGB from sRGB
> will be a
> > small part of that process. Just keep moving forward. There is too
> much to
> > do to go back and compensate for a color space change in all you
> files until
> > you need to do it.
>
>
> Yeah, I got a little frustrated. It's no different then the darkroom,
> just a little less wet. I'm just going to print this image out in
> PS6/srgb cause it looks best that way now. I'll switch over to
> PS7/Adobe98 NEXT time I do a real print and see if the microbanding
> shows up, I'm rationing my ink now, can't waste anymore til after
> vacation.

Good luck and have a great vacation!

Martin

>> Hey Tyler,  just how many times can one say "in my mind" in one post and
>> still be taken seriously?  Have to quit writing so late...
> Well, until we all stop screwing around and start putting something worth
> looking at on paper, it's all in our minds anyway.

do you have a pill for that?

> Let me further confuse the collective mind here. I have a file I use
> frequently that is a grid of solid patches, 1 to 100% gray
> scale, each patch a solid tone. 2.2 gamma grayscale.
> When I convert that to sRGB with dither checked, uh, why are some of the
> patches no longer solid tone? One of the worst
> here is 39%. Made a new file and filled it with solid 39% gray, check histo to
> make sure that's correct, converted as above,
> histo shows some slight variation now, clustered around that tone, and I can
> see the bumpiness on my monitor.

never thought of unchecking dither... I rely on it for my color stuff, so
just left it be for gray conversions. thank you. makes a lot of sense.

> However since gray 2.2 does not map precisely to it without moving some tones,
> I would use Adobe instead if it doesn't
> screw up your current results,
yup

>and I'd certainly turn that stinkin dither off.
... good point.


> assuming it was advised.
> Tyler, stuck in his mind
not a bad place to be stuck in..

> or as some would say, stuck with my head up my...
hard drive?

Carolyn

> PS7/Adobe98: Something odd. The print looks identical to the
> PS6/Adobe98 print except that in one area especially, microbanding
> shows up in a 3/4 tone area.

Did you try this particular conversion/version print again?  could your
printer need a little alignment?

But, what it seems to tell you is that the conversion to sRGB in PS7 is
screwing up your workflow, because  converting to Adobe1998 is not doing the
same (corduroy ignored for the moment).

>I don't know if this is due to the camera
> noise or not, but it looks sharper and finer- more like microbanding
> than cordury. Lest you think I'm overly picky,

nothing wrong with that anyway.

> 
> In fact I saw it right out of the printer, and thinking something
> amiss with the inkflow, did an immediate nozzle check which came out
> perfect. So if it was due to a misfiring nozzle, it cleared up before
> print was done (could be I guess <shrug>).

as above, I think I would also run an alignment check.

> 
> I don't know if that helps, I think I am rather adding to the
> confusion. My computer seems to, in it's mind, want me to use PS6,
> whatever the profile.<g>

when the computer speaks we shall listen.  I agree, I'd just print those
images prepped in PS6 thru PS6 while using that particular workflow...
that's why I keep old version on board... other issues crop up as well.

Carolyn

>> and I'd certainly turn that stinkin dither off.
> ... good point.

One last thing about the dither. Tyler's test was of a single tone, which
got converted then tortured with a tonal adjustment. Doing the same thing on
a gradient I think you'll find you prefer the dithered conversion as it
makes for smooth transitions, while the non dithered one shows banding.


Of course if you stay in 16-bit mode it's moot.

Todd

--- In DigitalBlackandWhiteThePrint@y..., Carolyn Frayn 
<carolynfrayn@s...> wrote:
> 
> > PS7/Adobe98: Something odd. The print looks identical to the
> > PS6/Adobe98 print except that in one area especially, microbanding
> > shows up in a 3/4 tone area.
> 
> Did you try this particular conversion/version print again?

Not until I  fill another inkcart set and put it in there. The 
bottle/vacuum filled carts were supposed to last through July and part 
of August, with a CFS being installed then, but with all the stuff 
going on a lot got wasted already.

  could 
your
> printer need a little alignment?

Possibly, but I should also tell you that the PS7/Adobe98 print was 
run right before (first a nozzle check and then) the PS6/Adobe98 
print. Any misalignment would have shown up in the PS6 print as well, 
coming later.

> 
> But, what it seems to tell you is that the conversion to sRGB in PS7 
is
> screwing up your workflow, because  converting to Adobe1998 is not 
doing the
> same (corduroy ignored for the moment).


Well it looks just a bit finer and sharper then the cordury that is 
slightly visible in all the prints. And it is above the threshold of 
"the wife test".

But, beyond that yes, the PS6/Adobe98 and PS7/Adobe98 are about 
identical, which is not the case for when srgb is used. Ignoring the 
microbanding fluke, the PS6/srgb print is still ever so slightly 
superior as the PS6 or PS7 with Adobe98 has a very very small spot of 
posterization. It is not enough to make me in the future NOT use 
Adobe98 for conversions. But the microbanding is now a puzzling issue.

What I'm really trying to say is I have the least problem when I use 
PS6, whatever the space. Also that the Adobe98 space does cause no 
discernable difference in PS6 vs PS7, microbanding ignored.
  
> 
> >I don't know if this is due to the camera
> > noise or not, but it looks sharper and finer- more like 
microbanding
> > than cordury. Lest you think I'm overly picky,
> 
> nothing wrong with that anyway.
> 
> > 
> > In fact I saw it right out of the printer, and thinking something
> > amiss with the inkflow, did an immediate nozzle check which came 
out
> > perfect. So if it was due to a misfiring nozzle, it cleared up 
before
> > print was done (could be I guess <shrug>).
> 
> as above, I think I would also run an alignment check.

As mentioned, why didn't it show up on the PS6/Adobe98 print done 
after the PS7/Adobe98 print?

Alignment checks on the 1280 are in two parts: one for black ink that 
most people would recognise similar to say that on an 1160, and a 
second one for color which is pretty hard to do unless one loads Epson 
carts back in. However, I am told this second part doesn't make as big 
a diff. I haven't done one in awhile, but still question why it then 
wouldn't have shown up in the later PS6/Adobe98 print.

If I don't use up too much ink otherwise in the next week I will try 
to run an alignment and another print.
Jim H.

> 
> > 
> > I don't know if that helps, I think I am rather adding to the
> > confusion. My computer seems to, in it's mind, want me to use PS6,
> > whatever the profile.<g>
> 
> when the computer speaks we shall listen.  I agree, I'd just print 
those
> images prepped in PS6 thru PS6 while using that particular 
workflow...
> that's why I keep old version on board... other issues crop up as 
well.
> 
> Carolyn

> One last thing about the dither. Tyler's test was of a single tone, which
> got converted then tortured with a tonal adjustment. Doing the same thing on
> a gradient I think you'll find you prefer the dithered conversion as it
> makes for smooth transitions, while the non dithered one shows banding.
> 

but that showed that in that one tone enough torture may have been applied
thru a dithered conversion to change the print in that tone when going thru
sRGB as aversed to a conversion to AdobeRGB where it hardly changed.


> Of course if you stay in 16-bit mode it's moot.

so many tests, so little time... <e::g>

Carolyn

> But, beyond that yes, the PS6/Adobe98 and PS7/Adobe98 are about
> identical, which is not the case for when srgb is used. Ignoring the
> microbanding fluke, the PS6/srgb print is still ever so slightly
> superior as the PS6 or PS7 with Adobe98 has a very very small spot of
> posterization. It is not enough to make me in the future NOT use
> Adobe98 for conversions. But the microbanding is now a puzzling issue.
yes... there's always something.
>
> What I'm really trying to say is I have the least problem when I use
> PS6, whatever the space. Also that the Adobe98 space does cause no
> discernable difference in PS6 vs PS7, microbanding ignored.
as those conversions seemed to show.

 
> As mentioned, why didn't it show up on the PS6/Adobe98 print done
> after the PS7/Adobe98 print?
wish I knew.

> Alignment checks on the 1280 are in two parts: one for black ink that
> most people would recognise similar to say that on an 1160, and a
> second one for color which is pretty hard to do unless one loads Epson
> carts back in. However, I am told this second part doesn't make as big
> a diff. I haven't done one in awhile, but still question why it then
> wouldn't have shown up in the later PS6/Adobe98 print.
thank you, I'm not familiar with the 1280.

> If I don't use up too much ink otherwise in the next week I will try
> to run an alignment and another print.
Good luck Jim,

Carolyn

on 6/30/02 1:14 PM, Carolyn Frayn wrote:

>> One last thing about the dither. Tyler's test was of a single tone, which
>> got converted then tortured with a tonal adjustment. Doing the same thing on
>> a gradient I think you'll find you prefer the dithered conversion as it
>> makes for smooth transitions, while the non dithered one shows banding.
>> 
> 
> but that showed that in that one tone enough torture may have been applied
> thru a dithered conversion to change the print in that tone when going thru
> sRGB as aversed to a conversion to AdobeRGB where it hardly changed.

True. I thought we all were in agreement by then g2.2 does not map as well
to sRGB as AdobeRGB, I was interested in exploring the bit depth/dither
thing.

Another point is if you do your conversion last, so that you will not be
applying a tortuous tonal adjustment after conversion, dither, or not, will
likely make no difference.

And with that, I'm outta here. ;-)

> so many tests, so little time... <e::g>

So right...

--- In DigitalBlackandWhiteThePrint@y..., Todd Flashner <tflash@e...> wrote:
> on 6/30/02 1:14 PM, Carolyn Frayn wrote:
> 
> >> One last thing about the dither. Tyler's test was of a single tone, which
> >> got converted then tortured with a tonal adjustment.

It was also visible in several tones, and the tonal adjustment was just so you could see it better. It was visible before the 
adjustment too. I was only trying to show it to you clearly.

> Another point is if you do your conversion last, so that you will not be
> applying a tortuous tonal adjustment after conversion, dither, or not, will
> likely make no difference.

On the contrary, the most severe tonal adjustment you will make, your sep curves, must be done after conversion.
It was just an observation, if you like the results with dither I'm not countering that.
As I said, I have no idea if this is a problem.
Tyler

on 6/30/02 3:30 PM, tboleyyh wrote:

>> Another point is if you do your conversion last, so that you will not be
>> applying a tortuous tonal adjustment after conversion, dither, or not, will
>> likely make no difference.
> 
> On the contrary, the most severe tonal adjustment you will make, your sep
> curves, must be done after conversion.

Uncle!

>>>> One last thing about the dither. Tyler's test was of a single tone, which
>>>> got converted then tortured with a tonal adjustment.
> 
> It was also visible in several tones, and the tonal adjustment was just so you
> could see it better. It was visible before the
> adjustment too. I was only trying to show it to you clearly.

You've got some good eyes my man, you take a lot of vitamin A or something?

Todd

on 6/30/02 3:30 PM, tboleyyh wrote:
 
>>>> One last thing about the dither. Tyler's test was of a single tone, which
>>>> got converted then tortured with a tonal adjustment.
> 
> It was also visible in several tones, and the tonal adjustment was just so you
> could see it better. It was visible before the
> adjustment too. I was only trying to show it to you clearly.

Can I borrow your glasses? On my gradients (4x6" @ 300dpi) I could see no
difference without applying pretty strong tonal moves.

 >> Another point is if you do your conversion last, so that you will not be
>> applying a tortuous tonal adjustment after conversion, dither, or not, will
>> likely make no difference.
> 
> On the contrary, the most severe tonal adjustment you will make, your sep
> curves, must be done after conversion.

That's an excellent point, which I hadn't considered. Interestingly though I
just did a gradient and converted to AdobeRGB with and without dither, then
applied a separation curve (selected somewhat arbitrarily, but trying to
pick one that is middle of the road: Roark's 1160 NC curve) and I could see
no difference. But I ain't got your eyes.

> It was just an observation, if you like the results with dither I'm not
> countering that.
> As I said, I have no idea if this is a problem.

Likewise. Just because a topic interests me (and I seem to enjoy the
minutia) enough to make some tests and share the results doesn't mean I'm
attached to any particular outcome. I'd much rather be wrong and learn
something than be right and learn nothing. I'm really glad you raised the
issue, I learned from it.

Todd

Todd

--- In DigitalBlackandWhiteThePrint@y..., Todd Flashner <tflash@e...> wrote:
> Can I borrow your glasses? On my gradients (4x6" @ 300dpi) I could see no
> difference without applying pretty strong tonal moves.
I didn't try it on grads

> just did a gradient and converted to AdobeRGB with and without dither, then
> applied a separation curve (selected somewhat arbitrarily, but trying to
> pick one that is middle of the road: Roark's 1160 NC curve) and I could see
> no difference. But I ain't got your eyes.
I doubt I could either, I was converting to sRGB which had much more of it than AdobeRGB, and it was on patches not grads. 
My eyes aren't that good. If anything I would think dithering might make grads artificially smoother, like adding noise to 
color banding problems. However all that ever did for me was leave me with color bands with noise. I was just not thrilled 
with seeing PS inject non image tones into my file, I felt somehow violated, shamed, no longer pure. Would I have to rescan 
for a virgin file?
This all started with the potential problems with converting to sRGB from 2.2 gray, among other things. Actually I don't even 
remember.
Well, I have laundry to do.
Make a print.
Tyler