Date   

Re: Hong Kong Printing Job

Remaley, Dan <dremaley@...>
 

Hi Rob, it sounds like they are printing CTP linear which = about 14%
midtone gain. Or they are printing with positive film, which "chokes" on
platemaking, making smaller dots therefore, less dot gain.
Be carefull of the Toyo inks they have a 'strong' colorant, especially Mag.,
making Magentas tough to match.
I would suggest proofing one page for color ok, measuring solids M-C-Y of
the proof against solid draw downs of the Toyo inks. Measure in Lab or
Hue/Gray.
Questions please call:

Dan Remaley
Process Control Tech.
p:412.741.6860 x450
f:412.741.2311
E:dremaley@...

----------
From: Rob Winner
Sent: Wednesday, February 6, 2002 1:53 PM
To: Color Theory
Subject: [colortheory] Hong Kong Printing Job

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



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: Sharpening with high pass filter

Andrew Rodney <andrew@...>
 

on 2/6/02 12:21 PM, John McKercher at john@... wrote:

Does anyone else have any comments on this method or are there reasons for
using/not using this method as oppsoed to using USM?

A variation is to duplicate the file, convert to grayscale and run the ³Find
Edges² filter. Invert, soften with G-blur and run levels to control the
contrast. Then load that into the main image as a selection and sharpen.
Works great. Protects all the shadows, severe highlights and smooth areas
and only sharpens the edges.

Andrew Rodney


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


Sharpening with high pass filter

John McKercher <john@...>
 

I recently read about a method of sharpening using the high pass filter.
Basically you take your layer, duplicate it, run the high pass filter with a
radius of 10, set this duplicated layer to hard light and adjust the layer's
opacity to get the level of sharpening required (usually between 20% and
70%.

The nice thing is that you can go back and undo or change the amount of
sharpening you applied. The bad thing is that you can't sharpen the colour
channels.

Does anyone else have any comments on this method or are there reasons for
using/not using this method as oppsoed to using USM?

John McKercher
typesetter/production
Hartley and Marks Publishers
john@...


Hong Kong Printing Job

Rob Winner <rwinner@...>
 

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


Re: consequences of workflow change

Andrew Rodney <andrew@...>
 

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]


Re: consequences of workflow change

Dan Margulis <76270.1033@...>
 

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


Re: Monitor Warm Up

Maris V. Lidaka, Sr. <mlidaka@...>
 

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

Maris

----- Original Message -----
From: "Brad McMullin" <mcmullin@...>
To: "ColorTheory" <colortheory@...>
Sent: Wednesday, February 06, 2002 7:58 AM
Subject: [colortheory] Monitor Warm Up


| 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
|
|
| [Non-text portions of this message have been removed]
|
|
|
| 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: Monitor Warm Up

Andrew Rodney <andrew@...>
 

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]


Re: Color Correction by the Numbers for Ink Jets

Stephen Marsh <samarsh@...>
 

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.


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