Date   

Monitor Warm Up

Brad McMullin <mcmullin@...>
 

Hello,
Need some suggestions. I came into work this morning I found that an image
which I was working on last night is much darker than I remember. How long
do I have to wait before the monitor is warmed up to the standard which I am
use to working. I do most of my color correction by the numbers. But, the
subjective stuff will be thrown off by this. I am using a Hitachi Super
Scan 814 if it matters.
Note: My guess is 30min. to an Hour.

Thanks,
Brad


Re: Color Correction by the Numbers for Ink Jets

Lee Varis
 

hfdomke wrote:

Dan Margulis's writes ...the Highlight should be
5C2M2Y and the Shadow should probably be something like
80C70M70Y70K.
If I go into Photoshop's color picker and enter those numbers
and convert them to RGB I get these numbers:
Highlight: R248 G250 B255
Shadow: R0 G1 B12

If I can pick my black point and white point dropper values to use
with curves ... would these be reasonable number to enter if my
output device will be a 6-ink Epson Inkjet printer
You can not extrapolate accurate RGB numbers from CMYK aim points. The
numbers you cite are highly dependent on what RGB & CMYK workspace
profiles you are using. I'm guessing that Dan's numbers are based on a
different kind of CMYK setup than what you've got set in your PS Color
Settings (you don't mention what you are using there- when I do this in
my set up I get 251R 249G 248B for white). Also the CMYK gamut is
smaller in most areas of color and several RGB colors may have the same
CMYK equivalents (dependent on rendering intent settings that affect
gamut compression) - the numbers you end up with won't necessarily match
the ideal RGB starting numbers for these CMYK aim points. I would prefer
to find neutral black and white points for RGB images, something like:
R240 G240 B240 for white (sometimes as high as 250 ea.) and R5 G5 B5 for
black (sometimes I like values as high as 10 for black) These numbers
are for highlight and shadow where you want to hold some sense of detail
or texture - a specular highlight should still top out at 255 ea. with 0
ea. for deep black shadows. Most of the time you want something neutral
in these areas and neutral in any of the standard PS workspace profiles
will be equal values in RGB. In CMYK if your numbers in these extreme
areas are off a few points it won't be that noticeable but your RGB
numbers seem to be definitely on the cool side and may force a cool bias
in other areas of the image if you use them to auto correct.

I also question the accuracy of the color picker to do conversion
calculations anyway - try creating patches of color in RGB and then
actually convert to CMYK to test this out. I find that the resulting
numbers are sometimes off a little bit from the color pickers
"prediction" (though not so much with these "end point" numbers). I'd be
interested to hear from someone at Adobe how Photoshop arrives at the
color equivalent numbers in the color picker.

--
Regards,

Lee Varis
varis@...
http://www.varis.com
888-964-0024


Color Correction by the Numbers for Ink Jets

hfdomke <missouri@...>
 

Dan Margulis's writes on p. 23 and 24 in "Professional
Photoshop 6" that for writing curves, the Highlight should be
5C2M2Y and the Shadow should probably be something like
80C70M70Y70K. This is geared for prepress and many of us
also print on high quaility ink jet printers that want RGB
numbers.

If I go into Photoshop's color picker and enter those numbers
and convert them to RGB I get these numbers:
Highlight: R248 G250 B255
Shadow: R0 G1 B12

If I can pick my black point and white point dropper values to use
with curves (such as in a program like Nikon Capture 2) would
these be reasonable number to enter if my output device will be
a 6-ink Epson Inkjet printer like the SP-890, 2000P or 75000? (I
use all three). What about if I was outputting to an Iris printer?

Thanks for the help!
Henry


Re: consequences of workflow change

Andrew Rodney <andrew@...>
 

on 2/5/02 9:33 AM, Bob Smith at bob@... wrote:

After editing a file without regard to the preview (correcting by the
numbers) the embedded profile is still correct in that accurately shows how
the file will look on the device the profile describes, so I guess that
technically you could say that the profile is accurate.
Yes plus should someone need to do a CMYK to CMYK conversion (for proofing),
the original profile is still needed and will allow the new edits to be
honored.

However it is not faithful to what the editors intentions were (printing on a
device different from what the profile describes) and that is where the
confusion arises.
No image editing after the fact is. That really has nothing to do with the
profile. If you un-tag the profile or assign a different profile, the
preview changes and so does any subsequent conversions. So the profile
really didn't hurt and (unless you do a conversion) doesn't do anything
anyway.

I get a file in with an embedded profile indicating
that the image was prepped for SWOP. I look at the numbers and decide that
its not going to print correctly on my press so I edit the CMYK to values
that will work on my press with no regard to the profile or the monitor
display. In essence I'm manually doing what would be accomplished in a
profile to profile conversion.
Well maybe. It's semantics at this point. Yes, doing a Convert to Profile
would alter every pixel and update the tag. Doing a global edit alters all
the pixels too and leaves the tag set as it was originally. Again, I don't
see this being more than a decision to alter the numbers using edits within
Photoshop or using a profile to do a conversion. One is fine control and the
other is a very brutal, heavy handed edit (using a conversion). I guess if
stuck in such a position, if I found that some slight editing was in order,
I'd use many of Dan's techniques like channel editing to get to my aim
point. If I needed to convert say SWOP coated to newsprint, doing a CMYK to
CMYK conversion (with perhaps additional edits in PS after) might be faster,
easier and ultimately better. The new condition would be updated in the new
tagged profile, no problem.

The SWOP profile is still in the file and will be saved with it if I have
PS6 prefs set to US Prepress Defaults
The original profile will be saved regardless of what you set in Color
Preferences (unless you turned your policy to OFF).

That's all fine and dandy
until that file gets handed off to someone else. Maybe someone pulls the
file out of an archive a few months later to print in a totally different
type of job. Now when opened, the file still has the SWOP profile so its
displayed like it would print in SWOP, not like it printed when used on my
press.
If the original profile remained (as I think it should), then it will look
ugly and someone should take notice. Or if they read by the numbers, as so
many here support, they will SEE the file isn't set correctly based on the
numbers.

I'd suggest that when you did the work above, you do it on a copy! That way
the original file numbers/tag is intact. Anytime you take a file in output
space (be it CMYK or RGB) and edit it, it's no longer optimized for the
original output device. So tag or not, you would be advised to keep a new
copy of the edited file IF you think someone would go back months latter and
hope to take the file to a different device (or better, just archive the
file in an RGB Working Space and re-convert for any device you have a
profile for). Repurposing a file in output space is a recipe for disaster
and just a lot of counter productive work! That's why we have color
management. IF all you need to do is produce one set of numbers for one
device, you don't need tags, profiles, calibrated displays or RGB archives.
If you do need to repurpose files, you need the above.

If someone other than the person who did the editing is opening the
file, what they see on screen is confusing and difficult to sort out.
Not if they work by the numbers. And if they work visually (and by the
numbers), the original tag with the new pixel editing shows them what they
would get. But how many rounds of edits does one put up with? Go back to the
original SWOP file with tag and send it out to your SWOP device.

Andrew Rodney


Re: consequences of workflow change

Bob Smith <yahoo@...>
 

Andrew Rodney wrote:

The description of the numbers is still honored by the edit AND the tag is
used if any further colorspace conversion takes place. Plus as you say, the
preview remains faithful to the edit. I don¹t see any issues with the tag
after editing a file. Files (with and without tags) are meant to be edited.
After editing a file without regard to the preview (correcting by the
numbers) the embedded profile is still correct in that accurately shows how
the file will look on the device the profile describes, so I guess that
technically you could say that the profile is accurate. However it is not
faithful to what the editors intentions were (printing on a device different
from what the profile describes) and that is where the confusion arises.

Take this scenario. I get a file in with an embedded profile indicating
that the image was prepped for SWOP. I look at the numbers and decide that
its not going to print correctly on my press so I edit the CMYK to values
that will work on my press with no regard to the profile or the monitor
display. In essence I'm manually doing what would be accomplished in a
profile to profile conversion. From past posts and from what Dan teaches,
its clear that many on this list and in the industry at large work that way.
The SWOP profile is still in the file and will be saved with it if I have
PS6 prefs set to US Prepress Defaults (A common and sensible choice which
turns on preserve embedded profile). After editing, the numbers in the file
are correct to make the file print on my device, but the display probably
doesn't look like what the original creator of the file saw while editing
and viewing the file with his SWOP profile. I don't care... I know its
going to print like what he wants on my press. That's all fine and dandy
until that file gets handed off to someone else. Maybe someone pulls the
file out of an archive a few months later to print in a totally different
type of job. Now when opened, the file still has the SWOP profile so its
displayed like it would print in SWOP, not like it printed when used on my
press. If someone other than the person who did the editing is opening the
file, what they see on screen is confusing and difficult to sort out.

To me, the above is a good argument for keeping an accurate profile... one
that accurately describes how the file will print on the intended device...
attached to the file at almost all times. Edit all you want by the numbers,
but have a profile that accurately describes what your numbers mean and keep
that attached to the file so others can tell what you did an why. I point
out the above just to illustrate how some on this list will hit snags from
time to time with profiles. Unfortunately the response is too often to try
to avoid anything remotely resembling a profile. If you're passing those
files around, that only adds to the confusion. It doesn't reduce it.

Bob Smith


Re: consequences of workflow change

Andrew Rodney <andrew@...>
 

on 2/5/02 3:56 AM, Dave Badger at dbadge@... wrote:

True, but I was thinking in terms of we *have* to open RGB files in PS and
convert to our shop output space. If it's untagged, and the operator so
inclined, you'd have a fair change of subjectively using one of Photoshop
predefined RGB working spaces as the assumed profile and while you have the
image open, tweak the CMYK if necessary.
The same can be said of CMYK. Picking a predefined CMYK space might work,
might not. Without a tag, it¹s simply a guessing game.

In any case the client who sends us
untagged RGB's can only expect our "best effort" to convert.
The same could be said of clients sending CMYK. But I understand that IF you
sell input and/or you want total control over conversions, one could hardly
blame you for simply taking any set of CMYK numbers you get and sending that
to your output device. The client gets what he gets.

With supplied CMYK's how can we have any clue as to how close or how far
their separation is from our output CMYK?
If it¹s tagged, yes.

We could open the image and if deemed to have an accurate tag do a CMYK>CMYK
Convert to Profile to our
output profile, but if untagged, you can't even begin to guess at an assumed
profile.
Right. Untagged CMYK is very problematic.

If I look at the file through a soft proof of the shop's output
profile, am I looking at a lousy sep make through the correct profile (let's
say SWOP, which is close to the shop's profile), or am I'm looking at a good
sep make through the wrong profile?
You are viewing their numbers through your output device. If it looks lousy,
it¹s likely a bad conversion for YOUR device. Might look great to the
originally intended device (if it¹s tagged, how does it preview?).

In any case, as soon as we open that
CMYK image, we've taken liability for that color and with 75% of the images
supplied in CMYK, we can't take the time or chance altering the supplied
file.
Understood. Then customers should know any CMYK they supply will output as
is to your device and if they have your shop profile, they can view that
prior to even sending you the file. It would be one less area where they
could say ³we didn¹t know it would output so ugly.²

In the case I first cited, it turned out the "ColorPass-55" profile was from
a Canon Color laser rip, so the difference between that and our SWOP based
output was obvious. Most cases, we would never know if the supplied sep was
our of sync with our output space.
Well you can now see that a Canon Laser CMYK numbers are vastly different
than your numbers so that¹s why the output (could have been the preview)
looked so bad. Tagged or untagged, some numbers are so far from their aim
point (this being a good example), that you just have to wonder if anyone
had a clue on the customer end in providing this file. But with the tag, you
were able to see the issue and fix it.

I agree this would be ideal, but one, I'm still tweaking our profiles as
different problems show up, and two, if the customer is their not happy with
the color, all they have to say is "but I used your profile". Then we're
into a big blame game.
Just let them use the profile for soft proofing then. Yes, ideally you¹d
want the golden version of a profile in case they do decide to use it to
convert from RGB. But if you tell them you need to control conversions and
the profile is only for preview purposes, at least they can get an idea how
awful a Canon Laser CMYK file would look to your printer.

Andrew Rodney



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


Re: consequences of workflow change

Tracy Williams <t_williams@...>
 

Hi all.
I have been following this thread and after reading today's postings would
like to comment. I am still *old school*. I haven't made the switch to
Photoshop 6 (and what I read on this list makes me even more hesitant to
upgrade), I correct by *numbers* (I still don't trust monitors. My final
product will not be an image on a monitor, it will be ink on paper.), and I
try to give the shop that will print my critical jobs a sample disk of
images that I have done cmyk conversions on to evaluate before I turn over
the entire job. Some printers have even offered to make proofs from the
sample files so that we can both be comfortable with how my files will
translate in their system. Then, if their pre-press department sees anything
grossly out of whack, I can adjust my files before I put the a job full of
images thay they would need to tweak in their laps.

This workflow has been successful for me. The pre-press department won't get
as many unpleasant surprises and neither will I.

Tracy Williams

From: Dave Badger <dbadge@...>
Date: Tue, 05 Feb 2002 05:56:20 -0500
To: Andrew Rodney <andrew@...>, Stephen Marsh
<samarsh@...>, <colortheory@...>
Subject: Re: [colortheory] Re: consequences of workflow change

on 2/4/02 9:20 AM, Andrew Rodney wrote:

Receiving RGB files with or without a proper tag almost seem more
straight forward
now.

You think? How come? You still don¹t have a description of the RGB numbers
and you have to end up with CMYK so you have to assume something about the
numbers which is just as dangerous as assuming something about CMYK numbers.
True, but I was thinking in terms of we *have* to open RGB files in PS and
convert to our shop output space. If it's untagged, and the operator so
inclined, you'd have a fair change of subjectively using one of Photoshop
predefined RGB working spaces as the assumed profile and while you have the
image open, tweak the CMYK if necessary. In any case the client who sends us
untagged RGB's can only expect our "best effort" to convert.

With supplied CMYK's how can we have any clue as to how close or how far
their separation is from our output CMYK? We could open the image and if
deemed to have an accurate tag do a CMYK>CMYK Convert to Profile to our
output profile, but if untagged, you can't even begin to guess at an assumed
profile. If I look at the file through a soft proof of the shop's output
profile, am I looking at a lousy sep make through the correct profile (let's
say SWOP, which is close to the shop's profile), or am I'm looking at a good
sep make through the wrong profile? In any case, as soon as we open that
CMYK image, we've taken liability for that color and with 75% of the images
supplied in CMYK, we can't take the time or chance altering the supplied
file.

In the case I first cited, it turned out the "ColorPass-55" profile was from
a Canon Color laser rip, so the difference between that and our SWOP based
output was obvious. Most cases, we would never know if the supplied sep was
our of sync with our output space.

Then you need to supply the ICC profile for your Iris (or press or whatever
you have that describes the condition of your print process). They can then
see on their (hopefully) calibrated display what the color will look like to
your device with THEIR numbers. OR better, they can convert RGB to CMYK
using that profile which is ideal.
I agree this would be ideal, but one, I'm still tweaking our profiles as
different problems show up, and two, if the customer is their not happy with
the color, all they have to say is "but I used your profile". Then we're
into a big blame game.



Dave Badger



To unsubscribe from this group, send an email to:
colortheory-unsubscribe@...



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


Re: consequences of workflow change

Andrew Rodney <andrew@...>
 

on 2/4/02 8:11 AM, Bob Smith at yahoo@... wrote:

Andrew Rodney wrote:

Editing an existing CMYK in now way invalidates the tag unless that edit >>
was
a colorspace conversion.
It does if someone does the editing by trying to achieve certain numbers
rather than by relying on making the image look good on the monitor. I'm
guessing that there are a lot of people on this list that have routinely
worked that way for ages.
The description of the numbers is still honored by the edit AND the tag is
used if any further colorspace conversion takes place. Plus as you say, the
preview remains faithful to the edit. I don¹t see any issues with the tag
after editing a file. Files (with and without tags) are meant to be edited.

Andrew Rodney




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


Re: consequences of workflow change

Dave Badger <dbadge@...>
 

on 2/4/02 9:20 AM, Andrew Rodney wrote:

Receiving RGB files with or without a proper tag almost seem more
straight forward
now.

You think? How come? You still don¹t have a description of the RGB numbers
and you have to end up with CMYK so you have to assume something about the
numbers which is just as dangerous as assuming something about CMYK numbers.
True, but I was thinking in terms of we *have* to open RGB files in PS and
convert to our shop output space. If it's untagged, and the operator so
inclined, you'd have a fair change of subjectively using one of Photoshop
predefined RGB working spaces as the assumed profile and while you have the
image open, tweak the CMYK if necessary. In any case the client who sends us
untagged RGB's can only expect our "best effort" to convert.

With supplied CMYK's how can we have any clue as to how close or how far
their separation is from our output CMYK? We could open the image and if
deemed to have an accurate tag do a CMYK>CMYK Convert to Profile to our
output profile, but if untagged, you can't even begin to guess at an assumed
profile. If I look at the file through a soft proof of the shop's output
profile, am I looking at a lousy sep make through the correct profile (let's
say SWOP, which is close to the shop's profile), or am I'm looking at a good
sep make through the wrong profile? In any case, as soon as we open that
CMYK image, we've taken liability for that color and with 75% of the images
supplied in CMYK, we can't take the time or chance altering the supplied
file.

In the case I first cited, it turned out the "ColorPass-55" profile was from
a Canon Color laser rip, so the difference between that and our SWOP based
output was obvious. Most cases, we would never know if the supplied sep was
our of sync with our output space.

Then you need to supply the ICC profile for your Iris (or press or whatever
you have that describes the condition of your print process). They can then
see on their (hopefully) calibrated display what the color will look like to
your device with THEIR numbers. OR better, they can convert RGB to CMYK
using that profile which is ideal.
I agree this would be ideal, but one, I'm still tweaking our profiles as
different problems show up, and two, if the customer is their not happy with
the color, all they have to say is "but I used your profile". Then we're
into a big blame game.



Dave Badger


Re: consequences of workflow change

Jerry L. P'Simer <jpsimer@...>
 

Andrew Rodney wrote:

Editing an existing CMYK in now way invalidates the tag unless that edit was
a colorspace conversion. You are viewing the data through the original
profile and making edits. The preview accurately reflects the edits. The tag
still describes the numbers for the preview and resulting (if necessary)
conversion (where a new tag would be inserted).
Are you saying that it is impossible to change color spaces through ps edits
which would invalidate the profile used for conversion?


Jerry P'Simer


Re: consequences of workflow change

Bob Smith <yahoo@...>
 

Andrew Rodney wrote:

Editing an existing CMYK in now way invalidates the tag unless that edit was
a colorspace conversion.
It does if someone does the editing by trying to achieve certain numbers
rather than by relying on making the image look good on the monitor. I'm
guessing that there are a lot of people on this list that have routinely
worked that way for ages. That's probably at least partially because of the
fact that former versions of Photoshop were not nearly as elegant at
delivering a reliable monitor proof. People got used to editing CMYK
strictly by trying to achieve highlight or gray balance numbers that they
knew their conditions required while paying relatively little attention to
the monitor display. Do that in an embedded profile workflow and you
confuse anyone who gets the image downstream and assumes that the profile
embedded is accurate.

Bob Smith


Re: consequences of workflow change

Andrew Rodney <andrew@...>
 

on 2/3/02 2:41 PM, Dave Badger at dbadge@... wrote:
Receiving RGB files with or without a proper tag almost seem more
straight forward
now.

You think? How come? You still don¹t have a description of the RGB numbers
and you have to end up with CMYK so you have to assume something about the
numbers which is just as dangerous as assuming something about CMYK numbers.
In fact, untagged RGB isn¹t any better or worse than untagged CMYK as far as
tags. At least an RGB file can be separated into CMYK with a lot less damage
and hassles once you know the meaning of the RGB numbers (with a tag).

I think assuming all CMYK files are print ready is the safe way to go
and then charging for corrections if the customer is unhappy with the
proofs.
RGB is print ready too. It¹s just not the colorspace you use to print. But
lots of people have devices that you send RGB to and an untagged RGB file is
just as close OR far away from the optimal numbers for that printer as
untagged CMYK.

On a related note, you've talked several times about how if edits are make
to a CMYK image then the tag is no good anymore. Is this because the edits
have created a "new" color space that the profile no longer describes? And
is this an issue only when you to do a CMYK>CMYK conversion, or do you
consider the original profile no good for previewing also?
Editing an existing CMYK in now way invalidates the tag unless that edit was
a colorspace conversion. You are viewing the data through the original
profile and making edits. The preview accurately reflects the edits. The tag
still describes the numbers for the preview and resulting (if necessary)
conversion (where a new tag would be inserted).

About half our work is printed in house on our short run presses. In the end
the customer only care if the images came off the press how he/she
envisioned it.
Then you need to supply the ICC profile for your Iris (or press or whatever
you have that describes the condition of your print process). They can then
see on their (hopefully) calibrated display what the color will look like to
your device with THEIR numbers. OR better, they can convert RGB to CMYK
using that profile which is ideal. Or they can view RGB data with your
profile and let you convert to CMYK with that profile latter in the chain.
But they saw what they will get because you allowed them to soft proof their
RGB with your profile. Of course they have to have their RGB tagged or all
bets are off.

Andrew Rodney


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


Re: Holding neutrals & Proofing (Thank you)

Stephen Marsh <samarsh@...>
 

John writes:

I just got match prints from a job that I am very
proud of, and looks like it will come out great.

It was a lot of products, silhouetted, and I held the
natural shadows.
Congratulations John - this is the fun part of the process, it's the final
prints which often do not live up to the proof. I am not talking of
separation or press error, just that laminate proofs often look more 'pure'
than the final job.

I shot digitally, selected out the products from the
white(light grey) background, tweaked the product,
pumped the background up to white holding the shadows,
converted the product with light black generation, and
then converted the background with a maximum black
generation, and combined it all back together.
You obviously have concerns with the neutral background - but do not want
more K in the products.

I personally would have gone with medium to heavy GCR depending on the
density of the neutral background and
not black only (maximum). Now I can see how you held the natural shadows
with ease. <g> I don't have a full mental picture of your job - so I don't
know how the use of the max. GCR will affect things, I hope you have some
trap between the background and the products or where the two different
separation methods meet (there may be registration issues depending on
content and use). The dot structure in the neutral background might be more
obvious - since this will be a 45 degree stipple of one ink and not a
rosette of CMYK inks, but depending on intended viewing distance this may
not be noticeable.

It sounds like you have tried to cover things as best you can, I guess the
only real concerns will be neutrals in the products (which are probably
minimal by the sounds of things) and any extra gain in the K in the products
brought on by the use of the heavy GCR background - but with your separation
approach for the products this seems safe. There will probably not be any
issues, I have used this approach for rich black jobs in some cases, but
with medium or heavy black generation - and these are pulling a lot more ink
onto the sheet than your particular job.

I am sure your post will spark comment from other members - things have been
slow and this seems like a bread and butter topic for the list.

P.S. - I would suggest a press check if possible and sign off on that.

Let me know off list how the print run goes.

Sincerely,

Stephen Marsh.


Re: consequences of workflow change

Stephen Marsh <samarsh@...>
 

On a related note, you've talked several times about how if edits are make
to a CMYK image then the tag is no good anymore. Is this because the edits
have created a "new" color space that the profile no longer describes? And
is this an issue only when you to do a CMYK>CMYK conversion, or do you
consider the original profile no good for previewing also?
Not really - it is just gray balance which concerns me, if other conversions
are taking place off the CMYK file if it has a tag (the tag is trusted).

In a basic RGB > CMYK the gray balance is fine, it matches the separation
profile. If you make no edits and convert back to another mode from this
tagged file which has not been edited in CMYK - then the results should be
close to the original file (apart from contrast issues from TAC and black
ink limits). Since the numbers in the file match the profile in gray
balance - all the conversions work as intended.

If you do not care about the profile after separation and only consider it a
'start point', fine - this means more knowledge and skill is required in
CMYK. Make all edits to the separated data and use whatever gray balance and
other specifications that your local conditions aim for. There are probably
neutral gray aimpoints which are followed or something.

Or convert RGB > CMYK and make edits in CMYK - but follow the gray balance
indicated in the profile. Now if the tag is kept and a conversion is made
off the tag - neutrals are not hosed.

Do you have any links? I'd like to follow through with this type of
testing.

The ColorSync AppleScripts are probably in your ColorSync or AppleScrit
scripts folder on your hard drive (if you did not clean up all of the
install) or on the Mac OS CD - I have never used them.

I have sent you the Mac only freeware utility off list - please virus check
before
use.

About half our work is printed in house on our short run presses. In the
end
the customer only care if the images came off the press how he/she
envisioned it. They don't care about all the calibration/color management
garblelygook that took place inbetween. Their monitor > your press. Better
educated clients would be nice, but doesn't seem to be our market. One
faction argues we should do whatever it takes to produce good images off
the
press and corrections/conversions are part of that cost. Another faction
argues that we give 'em what they gave us and move on. In a highly
competetive market, I vote for the former.
I agree Dave, you cant afford to make clients unhappy - and the service
provider role is not always fun <g>.

Sincerely,

Stephen Marsh.


Re: More dangers of embedded CMYK Profiles

Dave Badger <dbadge@...>
 

on 2/3/02 1:05 PM, Andrew Rodney wrote:

Tags don¹t change the data in your file until you make some kind of
conversion. The number are either going to produce good output or they will
not.
Thank you for an extraordinary helpful response. Your "meaning of the
numbers" approach is the only way I can mentally visualize what's happening
in Photoshop.

Thanks again,

Dave Badger


Re: consequences of workflow change

Dave Badger <dbadge@...>
 

on 2/2/02 11:59 PM, Stephen Marsh wrote:

Now things get confusing. There should be no reason that you converted a
CMYK file, with or without a tag - so is it correct that the ColorPass
profile and file are RGB? If this is so your comments below make things
sound like this is a CMYK file/profile.
I apologize for not being more precise on that point and it caused a lot of
confusion. The images with the "ColorPass-55.icc" profile were CMYK when we
received them.

I meant this to be a discussion of CMYK profiles in the workflow. Receiving
RGB files with or without a proper tag almost seem more straight forward
now. I think assuming all CMYK files are print ready is the safe way to go
and then charging for corrections if the customer is unhappy with the
proofs. In this case the customer had marked "check all color" on the 1st
round proofs so they knew something wasn't right but didn't know what. When
I saw what the "ColorPass-55.icc" profile did for the images, it was hard to
ignore.

In the failed conversion, the file went from Client CMYK > Output CMYK -
were any conversion settings different between these two conversions? As
mentioned in theory this should have been better, but your results indicate
otherwise.
No, same settings. I wouldn't call it a "failed" conversion, just not as
good as the Client CMYK > WS RGB > Output CMYK approach. This surprised me.
Maybe a Client CMYK has a vasly different black generation which doesn't
translate accurately into LAB, so the Output CMYK isn't optimal. This is why
Scitex creates DeviceLink profiles-so that each of the four channels is
passed directly to the Output space bypassing a reconversion from LAB.

So the question was the same
as yours - what to tag the CMYK scan with? The scanner was ICC capable but
the proprietary tables gave better results - so no profile was available
from that quarter. We could have tagged with the separation profile used for
supplied RGB data (SWOP v2 or custom CMYK table profile) - but since the
workflow and users did not care about the active use of CM or profiles -
none got tagged!
On a related note, you've talked several times about how if edits are make
to a CMYK image then the tag is no good anymore. Is this because the edits
have created a "new" color space that the profile no longer describes? And
is this an issue only when you to do a CMYK>CMYK conversion, or do you
consider the original profile no good for previewing also?

Try these suggestions when inspecting unknown or suspect CMYK
files/profiles:

* If on a Mac, use the supplied ColorSync AppleScript or free third party
tools like ProfileDestillator to pull the profile out of the image so that
you can install and use the suspect profile for some deeper testing.
Do you have any links? I'd like to follow through with this type of testing.


Most printers do not touch a clients data for exactly the reasons you
mention. Most have a 'all care but no responsibility' approach - where at
best they will inspect things and ask questions if they spot potential
issues with incoming data, or they will simply output the files as supplied
and proofing shows any issues.
About half our work is printed in house on our short run presses. In the end
the customer only care if the images came off the press how he/she
envisioned it. They don't care about all the calibration/color management
garblelygook that took place inbetween. Their monitor > your press. Better
educated clients would be nice, but doesn't seem to be our market. One
faction argues we should do whatever it takes to produce good images off the
press and corrections/conversions are part of that cost. Another faction
argues that we give 'em what they gave us and move on. In a highly
competetive market, I vote for the former.


Regards,

Dave Badger


Re: More dangers of embedded CMYK Profiles

Andrew Rodney <andrew@...>
 

on 2/3/02 10:23 AM, Dave Badger at dbadge@... wrote:

Ok, let me try to clarify; all the images that came in with the "ColorPass-V55
1100 Color Server" tag were already CMYK, the conversion having been done in
an unknown program. I suspect some kind of a color server based on the full
name of the tag. The rest were RGB files tagged with "sRGB" which we manually
converted in our Photoshop. Then the whole job was sent from InDesign to our
Iris for proofs.
There are not that many programs that would tag the image with a profile.
But none the less, you have two options:

1. Believe that ICC profiles are the cause of evil in the world and assume
(as Dan does) that most tags are incorrect.
2. Open the file and view it on a calibrated display with the tag and see if
it looks funny or not. If it looks really odd, you can now suspect that
someone tagged the file incorrectly (or the file is just plan ugly).

Since there are few applications around that do tag files (the most common
being Adobe Photoshop and with that application, a least version 6, it¹s
difficult to tag the file incorrectly), simply looking at the numbers WITH
the profile can provide you some information. You can also use the soft
proof features in Photoshop and pick your house profile (or use the Assign
profile command) and you will see what the existing numbers would look like
IF you simply sent them to your output device. This is VERY powerful. You
don¹t alter the data one lick but you view the data going to your device.

At this point you have to decide a few things. If the file looks OK with the
tag, do you want to do a conversion from the EXISTING numbers to your output
device (Convert to Profile) or simply send the numbers to your device.

Since the file has a tag (correct or not), we are able to see the numbers as
the customer saw them. The numbers are the numbers you got. The tag doesn¹t
alter this one bit! If the customer gave you goofy numbers that would
produce ugly output, the blame is on their heads. BUT!!!!.. By tagging the
file, they have at least provided some idea of what they wanted. They may
have provided CMYK optimized for newsprint and expect you to print on coated
paper (ugly output) but their intentions where provided with the tag.

Lets look at the other side of the equation. We like to believe (like Dan)
that anyone that provides a file that is tagged is kind of stupid and didn¹t
tag the file correctly. I guess the tag showed up on it¹s way from the
customer in the currier¹s van. Anyway, let¹s assume it¹s of no use. Fine,
you open the file in Photoshop to inspect it and remove the tag. Now you are
viewing the file in whatever CMYK space you have set in color pref¹s. That
could be your house profile. Again, you haven¹t changed anything here. You
get to see how the numbers in the file will appear if you send them to your
printer (but you need a profile, god forbid, for your printer).

But if you must convert, you¹ve lost the tag (be it accurate or not) so you
get to guess what the SOURCE is for conversion. Let¹s say you decide that in
the past, a conversion back to RGB fixed the issue. OK, you¹ve hosed the
original tag so what source is being used to go from CMYK to RGB? Again, a
guessing game.

Tags don¹t change the data in your file until you make some kind of
conversion. The number are either going to produce good output or they will
not. If you decide that your policy is to take any CMYK file you get and
send those numbers to the output device (and the customer is responsible for
the numbers they provide), having or not having a tag is moot. But if you
decide that when a custom provides you with CMYK numbers, you need to decide
if the output will be good or not, only the Tag will assist you. It¹s a
starting point in understanding what the INTENT of the customer was. We all
know some (a lot?) of customers don¹t have a bloody clue what CMYK numbers
to provide. They had the scans made elsewhere or someone in the chain did
the CMYK conversions. If you, yourself didn¹t do the conversions, then you
have to make some guesses (and simply sending all files to the printer and
then seeing the results is very counter productive).

So, you can decide that any tag is simply the result of some stupid user or
you can view the file as such and make decisions from there. You can decide
that proper education to users about the benefits of embedding a profile
will make your life easier or you can continue to believe that communicating
color (which is what tags do) is for idiots. Tagging a file incorrectly
isn¹t impossible. But it isn¹t as easy as some would lead you to believe.
And if the tag is wrong, no worries as long as you know how to investigate
the issues. Proposing that tagging files is a bad idea only keeps numbers
ambiguous. Tags are only a method of communication.

Are you saying as long as the CMYK preview and tag are correct, then they
should output just as seen directly to the Iris?
No, I¹m saying the numbers in the file are sound based on the tag and that
you should be able to:

1. View the numbers unaltered and see what they would produce on the Iris if
you just sent them out to that device (no conversion).
2. View the numbers altered if you did a conversion using this original tag
as a source for a conversion and Iris as the destination.
3. See what the user saw (what was his intent) and what the numbers would
look like to his device (tagged profile).

With no profile, you get nada (well you can see what those numbers would
look like to your Iris with an Iris profile assigned or soft proofed but
you¹ll need a profile for your Iris).

I understand in an RGB workflow, the proper conversions should take place so
that color A in the original matches color A on the output. But in a CMYK
workflow, we send the images (regardless of where they came from) directly to
the Iris (no conversions in PS). So the only thing I could think of is that
the CMYK values that produced correct color through the "ColorPass-55"
profile, produced incorrect color when sent through the Iris's "DIPress
Profile".
EXACTLY!!! You¹ve got it. With the tag, you can see all this before you
output the file (on a profiled display). As I said above, if your policy is
to take any CMYK file and output without conversion, then the tag is useful.
You can provide your Iris profile to the customer and tell them ³assign our
Iris profile to your file that is now in ColorPass-55 and see how ugly it
will look.² Now they can re-separate from the original RGB data OR decide
they need to convert from ColorPass-55 to Iris (or DIPress) profile. You can
put the responsibility to get the correct CMYK numbers for your device back
into their hands. They can see how dumb it is to send you a file in
ColorPass-55.

In order to fix it, we first tried a "Convert to Profile" of the CMYK images
tagged with "ColorPass-55.icc" to "DIPress.icc". The preview showed some
undesirable color shifts.
Exactly! The CMYK numbers for ColorPass-55 isn¹t the correct set of numbers
for Iris or DIPress.

So we next tried a "Convert to Profile" of the CMYK images tagged with
"ColorPass-55.icc" to "ColorMatchRGB.icc". This, of course converted to images
to RGB, but the color preview remained the same. Then we converted from
"ColorMatchRGB.icc" to "DIPress.icc" with acceptable results and sent those
files to the Iris. (Which came out much better).
Well it¹s strange that this didn¹t happen in the above step (ColorPass-55 to
DIPress). But, if going to RGB solved the problem, fine. You could not have
produced the same conversion to RGB had you not had the original
ColorPass-55 tag. Any colorspace conversion requires a source and
destination. In this case the original tag was used. The bottom line was
that you were able to fix the problem (although going back to the original
RGB scan would have been better).

But does this mean you recommend taking all incoming CMYK files and converting
them through Photoshop or iQueue to our in house profiles?
Yes if you want the best possible output and want to take on this extra
work. You have a device that requires a specific set of CMYK values and your
customers are providing you a set of CMYK numbers for other devices. To get
to the aim point you need to convert. IF the numbers you are provided are
close to your eventual aim point, the output will be pretty good. If the
numbers you are provided are a mile off, the output will be a mile off
(which may be something you want if the policy is to take any CMYK number
provided and simply output). But if the idea is to get YOUR CMYK device to
produce the closest intent of the customer, AND the customer provides a
tagged file, you can use both profiles to get to the desired CMYK numbers.
With no tagged profile from the customer, you can¹t do this.

One other thought; this is the first time we've noticed such a drastic
difference between Photoshop preview and output, and we also rarely use Adobe
InDesign. Could it have some color management options that would mess with a
CMYK file?
Trust Photoshop. But InDesign 2.0 (which I just got the other day) seems to
have color settings that are virtually identical to Photoshop 6. I can¹t
comment on the two being a match but I can say that Photoshop (with a
profiled display) will preview correctly. I assume InDesign 2.0 will too.

Andrew Rodney


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


Re: More dangers of embedded CMYK Profiles

Dave Badger <dbadge@...>
 

on 2/1/02 10:58 PM, Andrew Rodney wrote:

You have to get to the bottom of why the images got so ugly. It makes no
sense that viewing the tagged files looked good and then something happened
to make them ugly after a conversion.


Ok, let me try to clarify; all the images that came in with the
"ColorPass-V55 1100 Color Server" tag were already CMYK, the conversion
having been done in an unknown program. I suspect some kind of a color
server based on the full name of the tag. The rest were RGB files tagged
with "sRGB" which we manually converted in our Photoshop. Then the whole job
was sent from InDesign to our Iris for proofs.

The ones we converted from sRGB to "DIPress.icc" came out fine. The CMYK
"ColorPass-55" images sent untouched to the Iris came out ugly. When I
checked out these images on my monitor, they looked great and were tagged
with the "ColorPass-55" profile. I then went to 'Assign Profile" and
temporarily changed it to the "DIPress.icc" profile upon which the preview
changed to reflect the ugly Iris's. This is when I came to the conclusion:
I'm assuming they looked brownish and muddy because the embedded
"ColorPass-55" profile is not an accurate description of our SWOP based
calibrated Iris. (Which is supposed to emulate our press). Is this correct?

I¹m not clear what you mean. You opened the files (which are tagged) and they
looked OK. So there shouldn¹t be a problem here. That is, if the tag were
wrong, the image should preview incorrectly.
Are you saying as long as the CMYK preview and tag are correct, then they
should output just as seen directly to the Iris?(or other output device). I
understand in an RGB workflow, the proper conversions should take place so
that color A in the original matches color A on the output. But in a CMYK
workflow, we send the images (regardless of where they came from) directly
to the Iris (no conversions in PS). So the only thing I could think of is
that the CMYK values that produced correct color through the "ColorPass-55"
profile, produced incorrect color when sent through the Iris's "DIPress
Profile". (As the Iris rip ignores CMYK embedded tags??).

So at what point did the files end up ugly and brown?
You have to get to the bottom of why the images got so ugly. It makes no sense
that viewing the tagged files looked good and then something happened to make
them ugly after a conversion.
When sent directly from InDesign to the Iris, we did no conversions.

If the embedded profile was originally wrong to begin with, the preview should
have shown this UNLESS the profile was somehow highly screwed up! I guess
that¹s not impossible but then how did the conversion to ColorMatch Fix this
issue?
In order to fix it, we first tried a "Convert to Profile" of the CMYK
images tagged with "ColorPass-55.icc" to "DIPress.icc". The preview showed
some undesirable color shifts. I've always heard a CMYK to CMYK conversion
like this should be avoided, but need to understand why.

So we next tried a "Convert to Profile" of the CMYK images tagged with
"ColorPass-55.icc" to "ColorMatchRGB.icc". This, of course converted to
images to RGB, but the color preview remained the same. Then we converted
from "ColorMatchRGB.icc" to "DIPress.icc" with acceptable results and sent
those files to the Iris. (Which came out much better).

Why do you say CMYK to CMYK? Was the file (ColorPass-55) CMYK?(Yes) If so, the
tag
isn¹t the issue. Getting an untagged CMYK file would be just as problematic
since you¹d have to do a CMYK to CMYK conversion but you would have no idea
what recipe of CMYK you got to begin with.
Understood. But does this mean you recommend taking all incoming CMYK files
and converting them through Photoshop or iQueue to our in house profiles?
(Assigning untagged files with a best guess assumed profile)? Again, I
thought it was best to leave CMYK files alone, and then if the customer is
unhappy with the proof, make corrections in Photoshop.

One other thought; this is the first time we've noticed such a drastic
difference between Photoshop preview and output, and we also rarely use
Adobe InDesign. Could it have some color management options that would mess
with a CMYK file?


Thanks again,

Dave Badger




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


Thank you.

John Gulotta <hophogro@...>
 

I just want to thank everyone on this list, although I
have never posted, I read it well.

I just got match prints from a job that I am very
proud of, and looks like it will come out great.

It was a lot of products, silhouetted, and I held the
natural shadows.

I shot digitally, selected out the products from the
white(light grey) background, tweaked the product,
pumped the background up to white holding the shadows,
converted the product with light black generation, and
then converted the background with a maximum black
generation, and combined it all back together.

I didn't do the Quark production work, but the match
prints tell the tale. I am very happy about the sheer
size of the job and how I steered it through my
studio. Digital is great, but it is nearly impossible
to survive if the photographer attempts to do the
digital processing him(her)self. This was a real
breakthrough for me and my co-workers, if I can latch
onto another regular client, I'll be doing my part in
keeping the unemployment rate down.

I really feel that the people on this site have
enabled me to perceive and accomplish this job. You
all educate and inspire me. Even when we don't agree.

Anyway, just me talking, if anyone has a comment, feel
free, and thanks again!

John Gulotta
Horizon Photo Group

__________________________________________________
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions!
http://auctions.yahoo.com


Re: Are proofs proofs update.....

Darren Bernaerdt <bernaerdt@...>
 

Dawn,

The company I work for produces a bi-weekly flyer that is printed on
newsprint. I don't have the density values handy, but we're talking about a
typical dark, yellowish stock that is used on those types of jobs. If I seem
to remember correctly, this is the type of paper we're discussing here.

Our printer has been using a Polaroid DryJet proofer for some time and has
introduced a cast on the proof to simulate what we see on press. I think it
has been beneficial for me (the photographer), our "Photoshop guy" (all
in-house production) and for the people on the floor actually printing this
stuff. Sure, we could make the "mental bridge" and proof on a clean, white
stock. Why bother when we can have something that closely emulates our press
conditions.

When we produce a catalogue on a higher quality stock, the cast is adjusted
appropriately to simulate the better quality paper (still nowhere near
white). FWIW, the proofer they've been using for these other projects is a
Fuji Pictro (the version targeted to the printing market, not the model
typically used by photographers).

I find it odd that your printer has a table from Fuji to simulate the cast,
but doesn't seem interested in using it. Wouldn't it make their lives
easier? And, it sounds like they would have a happier client. Not a bad idea
if you intend to stay in business for the long term.

Quebecor is hardly a small outfit. Perhaps the people at your plant could
contact another location for some assistance? As a company, I'm sure they've
solved this issue before. No sense re-inventing the wheel.

Good luck.

Darren Bernaerdt

-----Original Message-----
From: Dawn Campbell [mailto:dawn@...]
Sent: Friday, February 01, 2002 11:44 AM
To: Color theory
Subject: [colortheory] Are proofs proofs update.....


Again, thanks to all that provided me with info on this issue.

What we found out or were told was that 1) the irises are the
most accurate proofs produced by the Quebecor plant here--they do
not produce matchprints or wet proofs, and their iris printer is
incapable of printing on other substrates 2) that they have NEVER
before been asked to match the proof to the stock, hence, no
attempt was made by them to alter the iris proofs provided to us
(huh??) and 3) they obtained a table from Fuji for casting the
proofs to match different stocks, and they have reprinted the
proof for the front cover on irises with 3 different samples, but
for only the front page.

They have told us they have never been asked to do this before
and they have implied that we are a little daft for asking (or
don't know what we are doing). They have said that everyone else
seems to manage and indicated that in reproducing the front page
of the previous flyer, we should use that (single iris proof of
the cover) as a guide for all images in future flyers??

I find it amazing that "no one" has ever before asked them for
casted proofs. I also don't really know how they think they've
solved anything by giving us a reprint of a previously used page,
with no intent to follow up for future flyers. Their intent is to
continue giving us the untinted irises, as they did before. I
fail to see how giving me a iris of that one page is going to
help me with the hundreds of pictures we might use in the future,
and I told them that, but their response seems to be that they
are just humoring us, and there was and is no need to put them
through all this hassle.

We have gotten quotes from other web printers in the area and are
looking at those.

Regards to all,
Dawn