Hello All,

I am working on a book project which will be printed in Hong Kong by Toppan.
I am working with a US Rep and delivering to them CMYK files. The specs for
Photoshop given me to make the RGB to CMYK seps were as follows:

Press Specs:
Avg Ink Limit: 334%
UCR: Recommended
Dot Gain: Average 10-12%
10-12% ( < Photoshop 4)
-1% ( > Photoshop 5)

Ink Standard: Toyo coated
Shadow Density Breakdown:
Cyan: 85%
Magenta: 77%
Yellow: 77%
Black: 95%


I am confused by a dot gain setting of -1 if I am using PS6. Any input?

Rob Winner
rwinner@...

on 2/6/02 10:33 AM, Dan Margulis at 76270.1033@... wrote:

And, if the sophisticated user has to discuss with
the next person that a conversion is necessary, then there isn't any need
for an embedded profile in the first place.

IF the user is working in Photoshop 5 or 6.... a profile will be used to do
that subsequent conversion. There isn¹t a way to do a colorspace conversion
WITHOUT a profile in these applications. If you want to simply remove the
tag, a conversion with a profile in these applications will take place none
the less. The difference is the Working Space CMYK profile will be used for
the source and that¹s very likely not the correct profile to be using.

1) Unlike RGB profiles, where I'm not aware of any reported conversion
problems, conversions from CMYK do not appear to be stable enough for most
professionals.

So you convert from CMYK back to RGB? A profile needs to be used. You simply
send the same numbers provided to the device? You get ugly output (as we
heard from Dave). If any kind of conversion is going to take place, a
profile will be used at least in any modern version of Photoshop. Or are you
suggesting you can fix all this using standard tools? That¹s fine. Laborious
but fine. It isn¹t the only way to fix the issue.

Situations like the one reported by Dave aren't uncommon,
where in principle the conversion should work and in practice it doesn't.

The conversion did work. He fixed the problem using profiles and
conversions. He had a profile for his house device. He used a profile to get
back to RGB.

2) As we have previously seen here, there exist firms such as Dave's that
apparently see an embedded profile as a license to convert. In many cases
that leads to a ruined job.

Dave has two options and it has NOTHING to do with profiles! He can send the
numbers he is supplied (by an admittedly bone headed customer who gave him
CMYK optimized for a laser printer) or he can convert. Which route he takes
is a business/service decision, not a color management decision (unless his
business decision is to fix the numbers by converting from Laser Printer
CMYK ultimately to his house printer CMYK). The issue wasn¹t that he had an
embedded profile, the issue was he got bad CMYK numbers. All the profile did
was allow him to see what his customers intent was (to the Laser), what his
output would look like if he simply sent those numbers to his printer (Ugly
output) and a way to get from the supplied CMYK to a new set of CMYK values.
In the future, any tagged CMYK file will be a nice indicator of what might
possibly happen if he sends the numbers to his printer. Can you possibly
explain why that would be a bad thing Dan?

Bad numbers are bad numbers. Profiles don¹t affect that issue, they only
allow users to see and if necessary convert/correct. Profiles don¹t kill
jobs, people kill jobs.

In my book, I advocated
embedding CMYK profiles only when the CMYK is substantially different from
SWOP.

This is exactly what happed to Dave (unless you feel that Laser Printer CMYK
is remotely similar to SWOP). Oh, please define SWOP (not as SWOP in their
spec does but as every printer who has a different printer behavior that is
supposed to be SWOP).

Andrew Rodney


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

Bob writes,

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

Many do, and there are a largish number of other ways for incorrect
profiles to creep in. Embedding profiles in CMYK is a very different animal
from doing so in RGB.

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

It's definitely a PITA to do this, so one must ask whether the benefits (if
any) outweigh the risks.

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

Considering that at least 99% of CMYK work does not involve conversion
based on CMYK profiles, and that 100% of all CMYK work prior to 1998 did,
it is very difficult to understand what confusion is being referred to.
Nobody other than color management vendors appears to perceive any.

The benefits of sinking tags into CMYK files are as I see it, as follows.

1) If the user dies or is otherwise utterly unavailable for consultation,
conceivably the profile may help somebody down the line understand what was
going on, probably not. If the user is not dead, he is either
sophisticated, in which case he will not want anybody to act on that
profile without previous discussion, or unsophisticated, in which case the
profile is meaningless. And, if the sophisticated user has to discuss with
the next person that a conversion is necessary, then there isn't any need
for an embedded profile in the first place.

2) It keeps the few color management vendors who have not realized that
this particular application is a lost cause, happy.

The disadvantages are:

1) Unlike RGB profiles, where I'm not aware of any reported conversion
problems, conversions from CMYK do not appear to be stable enough for most
professionals. Situations like the one reported by Dave aren't uncommon,
where in principle the conversion should work and in practice it doesn't.
When it happens, the normal result is the one Dave now enjoys, viz., a) he
eats the cost of the job; b) he cheeses off the client; c) he gets to
practice his troubleshooting skills, for which he can charge nobody.

2) As we have previously seen here, there exist firms such as Dave's that
apparently see an embedded profile as a license to convert. In many cases
that leads to a ruined job.

Considering the exceedingly limited upside of embedding, and the very real
threat of ruined jobs, the choice seems very easy. In my book, I advocated
embedding CMYK profiles only when the CMYK is substantially different from
SWOP. That's the way I felt at the time, but so many of these snags have
popped up since then that I now would not embed even in that case.

Dan Margulis

Monitor calibration programs generally recommend 1 hour warm up before calibrating, but that may well not be practical in your workflow.

Maris

on 2/6/02 6:58 AM, Brad McMullin at mcmullin@... wrote:

Note: My guess is 30min. to an Hour.

Unless you have a Barco, that¹s correct. The Barco compensates for warm up
on the fly so you can start editing a second after it¹s on.

Andrew Rodney


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

Henry writes:

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.

Then as has been suggested in a recent post by Andrew Rodney - you convert
from your CMYK tag or assumed workspace profile set-up in colour settings -
to the profile for your inkjet, on a copy of the original file. This RGB
file is then output to the Epson profile which simulates your press or acts
as your contract proof, or pre-proof guide or whatever.

If the CMYK numbers in the file match the assigned/assumed profile - then
you will get true neutrals.

This will not happen with standard aimpoints - you have to follow the LAB
values in the profile when making your curve moves in CMYK. This does not
really matter for most people, but if you are expecting a neutral conversion
out of CMYK then the right numbers and profile have to be used. What most
people seem to do is hit standard aimpoints such as 5/3/3 or whatever, even
if this is not providing neutral values via LAB readings for the profile.
This colour may proof or print on press as neutral - but to the profile and
any mode conversions, it is not neutral (since the CMYK numbers are not
synced to the file).

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

This demonstrates my point that if you alter CMYK numbers so that they are
out of sync for the profile - and the profile is expected to deliver neutral
colours in LAB or RGB - then you may have another thing coming.

This may or may not be an issue - not many convert CMYK to other modes as a
workflow rule (apart from channel blend tricks etc), and when they do they
do not care that the 'closed loop non icc numbers' do not match the profile
for neutrals, since they may care about the actual final CMYK values in the
final film or plate more than having them match the profile.

Some users do like to keep the neutral values in the file matching the
profile - so that conversions out of CMYK are accurate to the profile,
probably more so for neutrals throughout the tonal range but not so much in
the highlights/shadows (where more generic aimpoints might be used, even if
they disregard the profile).

This is not easy to comment on, there are a lot of ways that people edit
when in CMYK.

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?

You would ideally need to profile each device using the print settings,
ink/stock/resolution etc - and I do not mean ICC profile, although this
would be ideal.

This is just like finding total ink limits on a press. Head on over to this
page and download this file. Stuffit expander required for decompression:

http://www.thelawlers.com/essays.html

http://www.thelawlers.com/FTP/Gray%20step%20chart.sit

This is a 100 step grayscale chart in vector EPS format, each patch varies
by 2-3 RGB levels when converted to RGB. This image can also act as a gray
balance test image when converted to RGB or CMYK, but would also ideally
include a grayscale gradient as well to see if 'crossover' is an issue on
inkjets. I am not suggesting gray balance at this point (that's ICC profiles
and CM) - I am just trying to help you find suitable RGB aimpoints for your
common devices, if you wish to optimise your RGB before print.

Rasterize into Photoshop as RGB at say 120 or 240 ppi, assign your WS RGB
(workspace, i.e. Adobe RGB etc) and save as PSD.

Now convert or print/convert from workspace to Epson RGB or however you
normally print for the Epson or IRIS - just convert to the appropriate
profile for the intended output.

Visually evaluate the step chart so that you can find the patch where the
min and max tonal values start/end.

Use these as guides and adjust after running these aimpoints on test images
with real image content, the shadow detail will probably vary more on
natural images than the step chart - but you should have a max limit to
shoot for.

I think there are two different workflows here...

a) Using an inkjet to simulate a press or proof

b) Alternate workflow for optimising images in RGB for an RGB output

Method (a) is trying to exactly reproduce the CMYK file within the limits of
the profiles/device etc on an inkjet.

Method (b) does not care about matching the CMYK file, it is about making
the inkjet perform to its best.

Regards,

Stephen Marsh.

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

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

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

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

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

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]

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

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]

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

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

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

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]

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.

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.