Dan Margulis Applied Color Theory --Fate and the False Profile

From: wayne_ellis@putnam.com
Date: Tue, Aug 14, 2001, 1:59 PM
RE: [colortheory] Fate and the false profile

Dan, yet another wonderful article in the August issue of Electronic Publishing. I hope you will favor us with a PDF version soon.
I hope too that everyone realizes what a remarkably fine writer you are, how much a clear and likeable personality emerges in what you write, and how you have a gift for making us all feel as smart as you are (unlikely) and for taking tension and threat out of every complex subject. You bring light to every life you touch, and we are all in your debt.

From: "Michael Cervantes", mcdesign@tld.net
Date: Wed, Aug 15, 2001, 11:00 AM
RE: RE: [colortheory] Fate and the false profile

>>You bring light to every life you touch, and we are all in your debt.>>
I agree 100% with you. I am a different graphic designer after Margulis enter in my life. I highly appreciate Dan's friendship and teaching.

Regards

Michael Cervantes
MC Design Studio

From: "Ron Bean", rbean@execpc.com
Date: Fri, Aug 31, 2001, 12:28 PM
RE: [colortheory] False gamma vs curves

In "Fate and the False Profile", Dan wrote:
>The lightening caused by the lower gamma is much smoother than
>doing the same thing with Photoshop curves, which exaggerate
>changes at the highlight and shadow ends too much.

I don't understand why this should be the case-- I thought gamma was just a curve with a specific shape, and that Photoshop curves could be any arbitrary shape. What prevents you from making a curve that shape in Photoshop?

From: Dan Margulis, 76270.1033@compuserve.com
Date: Sat, Sep 1, 2001, 2:46 PM
RE: [colortheory] False gamma vs curves

Ron writes,
>>I don't understand why this should be the case-- I thought gamma was just a curve with a specific shape, and that Photoshop curves could be any arbitrary shape. What prevents you from making a curve that shape in Photoshop?>>

It's not that easy to make a curve with 5 or 6 accurate points in that tiny dialog box. For the same reason, it's hard to write a curve that exactly duplicates what changing the gamma settings in Levels does--there's a fudge factor there, too.

A better reason to do it with the false profile is that it doesn't do anything to the image data other than redefine it. If the image is so dark that we have to resort to a false profile, it's probably very noisy in the shadows, too. Applying an extreme curve to the shadows may exacerbate this problem.

Dan Margulis

From: Chris Murphy,
Date: Sun, Sep 2, 2001, 11:55 AM
RE: Re: [colortheory] False gamma vs curves

Dan Margulis writes:
>A better reason to do it with the false profile is that it doesn't do
>anything to the image data other than redefine it. If the image is so dark
>that we have to resort to a false profile, it's probably very noisy in the
>shadows, too. Applying an extreme curve to the shadows may exacerbate this
>problem.

What is a false profile?

Chris Murphy
Color Remedies (tm)
Boulder, CO
303-415-9932

From: Dan Margulis, 76270.1033@compuserve.com
Date: Sun, Sep 2, 2001, 5:21 PM
RE: [colortheory] False gamma vs curves

Chris Murphy writes,
>>What is a false profile?>>

A false profile is the use of the Image: Mode>Assign Profile command to assign color and gamma values that are known to be incorrect, in an effort to make further color correction easier. In my August column I suggested that users whip up half a dozen of these false profiles to have around in case they are needed.

One example showed an RGB image that was extremely dark and colorless. I assigned one of these stock false profiles to it, using Wide Gamut RGB primaries with a gamma of 1.0. It was still far from being an acceptable image but I was able to get a pretty decent result out of it after some further moves. I was not immediately able to get similarly good results without starting with the false-profile gambit.

Dan Margulis

From: Chris Murphy,
Date: Sun, Sep 2, 2001, 6:13 PM
RE: Re: [colortheory] False gamma vs curves

Dan Margulis (76270.1033@compuserve.com) writes:
>One example showed an RGB image that was extremely dark and colorless. I
>assigned one of these stock false profiles to it, using Wide Gamut RGB
>primaries with a gamma of 1.0. It was still far from being an acceptable
>image but I was able to get a pretty decent result out of it after some
>further moves. I was not immediately able to get similarly good results
>without starting with the false-profile gambit.

I'm not convinced "false profile" is exactly a good term, but I'm not sure what other term would suffice. I'll have to think about it.

When you open an image, with or without a profile embedded, some profile is affecting the preview of the image. In the case of an untagged image (Assign Profile is set to "Don't Color Manage This Document") then the working space profile applies.

If you get better results, even if they are perfect results, with a different profile, then it's just a better assigned profile. If the newly assigned profile is considered "false" then the previous profile is even more false. So this is actually the case of "assigning a better profile to the image." The original one was worse.

The true "false profile" is the one that was being used to begin with - most likely due to it being marked as "Don't Color Manage This Document."

Chris Murphy
Color Remedies (tm)
Boulder, CO
303-415-9932

From: varis@varis.com
Date: Sun, Sep 2, 2001, 8:50 PM
RE: Re: [colortheory] False gamma vs curves

Dan Margulis (76270.1033@compuserve.com) writes:

> A better reason to do it with the false profile is that it doesn't do
> anything to the image data other than redefine it. If the image is so dark
> that we have to resort to a false profile, it's probably very noisy in the
> shadows, too. Applying an extreme curve to the shadows may exacerbate this
> problem.
Chris Murphy writes:

> What is a false profile?

Perhaps we should call it a correction profile. The idea is to assign a specially designed profile (or choose an unusual one) to correct for some perceived defect in the original image. The way I understand it - assigning such a profile does not re-calculate/re-generate the numbers in the original image. It simply changes what they mean and it gives us a new starting point from which to make further "real" corrections (number changing corrections like curves) or a new "color set" to convert from. Extreme brightness/gamma and chroma changes can be made without suffering additional round-off errors that might exaggerate noise or posterize tones beyond what already exists in the original image. These special profiles are only false in that they don't represent the original state of the image - frankly, the moment one releases the shutter on a camera one has seriously departed from reality so I don't think there is any truth or falseness to any profile just an arbitrary definition of color in a particular image.

-- regards,

Lee Varis
varis@varis.com
888-964-0024
www.varis.com

From: Andrew Rodney,
Date: Sun, Sep 2, 2001, 10:49 PM
RE: Re: [colortheory] False gamma vs curves

on 9/2/01 7:07 PM, Lee Varis at varis@varis.com wrote:

> Chris Murphy writes:
> Perhaps we should call it a correction profile. The idea is to assign a
> specially designed profile (or choose an unusual one) to correct for
> some perceived defect in the original image.

I think both you and Dan misunderstand what is happening here. You are not correcting anything! You are not changing the pixels a lick. The preview appears 3wrong2 because you don1t have a profile assigned to the image or you have the incorrect profile assigned to the file. Dan isn1t fixing the image. He is simply describing the numbers in the file to Photoshop and with that information, Photoshop now produces a new updated preview. If you don1t change the data (only how it appears), how can you be correcting the image? You are correcting the preview (and I would HAVE TO ASSUME Dan is doing this with a -god forbid- calibrated display). It1s not a false profile. That1s something Dan made up that sounds good but isn1t at all accurate. As Chris points out, he is messing with numbers in a Working Space to produce what appears on screen to look better (naturally he must be doing this with some confidence in what he is seeing on screen). The profile isn1t false, it1s much more accurate to what he had prior to assigning this new tweaked Working Space profile.

For this to really work, the display has to be correctly profiled. That is, if you have some display that is wildly off kilter, messing with the numbers to change the preview is about as ineffective as messing with the controls on your display to change it1s behavior hoping to make the file better. The file didn1t change. You simply altered the display to make it look better. What is important here is that IF your display is properly profiled, AND you assign the correct profile (one that was created correctly or one altered as Dan has done), then the data has some integrity. Why? Because Photoshop can ONLY conduct colorspace conversions with ICC profiles. The source of the conversion (the assigned profile) plays as important a role as the destination profile!!! By assigning a profile that produces a good preview on a calibrated display, you are telling Photoshop 6 3I like what I see, now color manage it from here on.2 The quality of the output profile will naturally play a role in what happens from here on out. But the assignment of the profile (whether from an accurate profile someone created or one that was fudged by messing with the numbers) is critically important in how that file ultimately prints.

> The way I understand it -
> assigning such a profile does not re-calculate/re-generate the numbers
> in the original image. It simply changes what they mean and it gives us
> a new starting point from which to make further "real" corrections
> (number changing corrections like curves) or a new "color set" to
> convert from. Extreme brightness/gamma and chroma changes can be made
> without suffering additional round-off errors that might exaggerate
> noise or posterize tones beyond what already exists in the original
> image.

Right!

> These special profiles are only false in that they don't
> represent the original state of the image

No, they DO represent the true state of the image (or as close to the truth as one can fudge by playing with the limited numbers at your disposal). You could play around till the cows come home to improve the look of the image by assigning these profiles. Or you could simply get the correct profile in the first place! That means (god forbid for anyone that dislikes the idea of ICC profiling), actually making some measurements and producing a profile correctly from the beginning. Not screwing around, guessing at numbers until the preview looks better. What Dan is doing certainly is a valid way to work with untagged files. He is simply getting closer to the truth; what the numbers in the file really mean. If however he simply realized that creating good profiles for all files did a much better job with less guessing, or simply insuring everyone just tagged their files, this exercise wouldn1t be need to be used. If someone tags the wrong profile (VERY difficult to do in Photoshop 6), you could 3fix2 the mistake by tweaking numbers in what is being called a 3false profile.2 Calling it a false profile is the opposite of what is really happening here. What this is, is a best guess profile. We have to guess because someone didn1t tag the file in the first place.

Andrew Rodney

From: Bob Smith
Date: Sun, Sep 2, 2001, 11:28 PM
RE: Re: [colortheory] False gamma vs curves

Andrew Rodney wrote:
> You could play around till the cows come home to improve the look of the image
> by assigning these profiles. Or you could simply get the correct profile in
> the first place! That means (god forbid for anyone that dislikes the idea of
> ICC profiling), actually making some measurements and producing a profile
> correctly from the beginning. Not screwing around, guessing at numbers until
> the preview looks better. What Dan is doing certainly is a valid way to work
> with untagged files.

I agree that false profile might be a misnomer but I think you're missing the point about Dan's reason for using this. The idea is a helpful tool for correcting images that are way off to begin with... not for dealing with normal images in a normal workflow. In other words even if the image has an embedded profile, its so obviously far off to be meaningless. So make up a profile that redefines the image in a more appropriate way for that particular image and edit normally from there. The contention is that this works better and is easier than trying to pull an extreme curve to adjust the image so that it appears correctly in a less appropriate (if more standardized) RGB space. Basically he's conceding that the CMM and a couple of profiles can do a better job of altering an image than what you'd be able to create within the limitations of the curves dialog.

Bob Smith

From: "Ron Bean", rbean@execpc.com
Date: Mon, Sep 3, 2001, 2:25 AM
RE: Re: [colortheory] False gamma vs curves

Andrew Rodney writes:
>What this is, is a best guess profile. We
>have to guess because someone didn1t tag the file in the first place.

No, it would still look awful if they had tagged it, because it was badly underexposed. That kind of tag assumes you have a reasonably good image to start with, and this was an "unreasonably bad" image.

This has little to do with color management, it's about color *correction* (which implies that the color was wrong to begin with). In this case there is no good profile; even with Dan's "best guess" profile it required major corrections. After the color is corrected (or at least "improved"), then you can start to talk about managing it.

The "falseness" of the profile comes from the fact that it's different from what you'd get by profiling the device that created the image (in this case a digital camera). It's a better profile for that particular image, but you wouldn't want to blindly assign it to every image from that device (unless maybe they're all underexposed, in which case you might want to tag the photographer instead).

From: Andrew Rodney,
Date: Mon, Sep 3, 2001, 11:01 AM
RE: Re: [colortheory] False gamma vs curves

on 9/2/01 9:28 PM, Bob Smith at rmsmith@calpha.com wrote:
> I agree that false profile might be a misnomer but I think you're missing
> the point about Dan's reason for using this. The idea is a helpful tool for
> correcting images that are way off to begin with...

But you are NOT correcting, that1s my point. You are defining. How can you be correcting by not altering the data in the file, only how Photoshop interrupts the numbers but the alteration of a profile?

> The contention is that this
> works better and is easier than trying to pull an extreme curve to adjust
> the image so that it appears correctly in a less appropriate (if more
> standardized) RGB space.

I fully agree. Pulling a curve to adjust a file because it 3looks bad2 when the numbers are fine and the preview is inaccurate (due to the wrong profile) is a bad idea. Assigning the correct profile to make the numbers look right in the first place is a good idea. One is a correction (data altering). The other is proper description of data so it appears correctly. I see the two as vastly different approaches.

Andrew Rodney

From: Andrew Rodney,
Date: Mon, Sep 3, 2001, 11:06 AM
RE: Re: [colortheory] False gamma vs curves

on 9/3/01 12:24 AM, Ron Bean at rbean@execpc.com wrote:
> The "falseness" of the profile comes from the fact that it's
> different from what you'd get by profiling the device that created
> the image (in this case a digital camera)

No, not if you profiled the camera for underexposed! It's wrong because the file was exposed differently than how the original profile was created. If you decided for whatever reason you wanted to underexpose the file this way every time and you profiled the camera for this capture, your profile would produce much better results (and much worse if you used it on properly exposed images).

Profiles assume a certain behavior of the files they describe. If you profile a camera one way and capture another, the description is wrong, the preview is wrong.

Andrew Rodney

From: Chris Murphy,
Date: Mon, Sep 3, 2001, 11:49 AM
RE: Re: [colortheory] False gamma vs curves

Ron Bean writes:
>No, it would still look awful if they had tagged it, because it
>was badly underexposed. That kind of tag assumes you have a
>reasonably good image to start with, and this was an
>"unreasonably bad" image.

What's occurring is the creation of a profile for a specific device and condition - be it a digital camera, or shooting film then scanning it, in an underexposure situation. If this device and condition were predictable in advance, the profile certainly could have been embedded in the image, and then the preview on screen would be accurate from the get go.

Just because this profile is built on-the-fly for a specific use, while most profiles are made in advance for more general use, does not make this method color correction.

>This has little to do with color management, it's about color
>*correction* (which implies that the color was wrong to begin
>with).

That's not what this strategy says. The strategy is saying the numbers in the image are GOOD, the problem is with the assigned profile. Dan is creating a better assigned profile in order to end up with an interpretation of the same RGB numbers that is superior.

> In this case there is no good profile; even with Dan's
>"best guess" profile it required major corrections. After the
>color is corrected (or at least "improved"), then you can start
>to talk about managing it.

Profiles are inherently best guess no matter what. There is no such thing as perfect profiles anyway. So while the new profile isn't perfect, it is more appropriate than the previously assigned profile.

>The "falseness" of the profile comes from the fact that it's
>different from what you'd get by profiling the device that created
>the image (in this case a digital camera). It's a better profile
>for that particular image, but you wouldn't want to blindly assign
>it to every image from that device (unless maybe they're all
>underexposed, in which case you might want to tag the
>photographer instead).

I'm unconvinced that this distinction makes this method fall under color correction rather than color management. If someone makes their dinner by wrapping it in foil, sticking it in the engine compartment of their car, then driving 60 miles - it's still dinner. Even if it's produced differently than most dinners around the world. The purpose is the same.

Chris Murphy
Color Remedies (tm)
Boulder, CO
303-415-9932

From: "Ron Bean", rbean@execpc.com
Date: Mon, Sep 3, 2001, 12:31 PM
RE: Re: [colortheory] False gamma vs curves

Chris Murphy writes:

>That's not what this strategy says. The strategy is saying the numbers in
>the image are GOOD, the problem is with the assigned profile.
No, this strategy says "I am using a tool for a purpose it was not designed for". The new profile does not even come close to correcting the image by itself, it's just a starting point.

Have you looked at the original in Dan's article? ("M" on p36) Do you really think you could create a profile for that? It would make in interesting demonstration if you could (or a similar image with known lighting conditions).

From: Andrew Rodney,
Date: Mon, Sep 3, 2001, 12:35 PM
RE: Re: [colortheory] False gamma vs curves

on 9/3/01 9:48 AM, Chris Murphy at wrote:
> I'm unconvinced that this distinction makes this method fall under color
> correction rather than color management.

Amen! This isn1t color correction, it1s color description!

It1s interesting that Dan1s article and this series of messages appeared as it illustrates that people who were previously shying away from color management and profiles are now seeing the role of profile description and how Photoshop 6 produces a preview. It illustrates (finally) the fact that digital images are simply a set of numbers and how profiles allow the description of these numbers affects preview and conversions.

Previous to Photoshop 5 and 6, everyone simply looked at numbers and assumed (at least in RGB) there was some relation to their displays (there really wasn1t). You could adjust the display and make the file 3look better2 but that didn1t really help very much considering that anyone else who looked at the file would see a vastly different preview. So a room full of users could in theory 3correct2 (change the actual file) based on what they were seeing and that was at best a chaotic situation. When Adobe came up with the Photoshop 5 architecture which divorced the editing of files based on what the display was doing, most users heads exploded. It made perfect sense to place files in a common definition using a profile. Then simply expect users to profile their displays so that Display Using Monitor Compensation kicked in and everyone could have a common ground for viewing AND editing their files. So the display was defined but what about the file? Well we have to embed profiles to get this part of the equation to work.

That lead people who were afraid of ICC workflows to recommend not embedded profiles (as if embedding a profile somehow altered the data; it didn1t). Now we have a case where all kinds of people produce files with no descriptors. The display is hopefully defined for preview purposes but without files having their descriptors, the system doesn1t work yet. It1s just like one hand clapping.

Now we get someone that suggests we alter the tagged profile to make the appearance of the file look better. Well that1s what Adobe has been proposing for years now. Tag the file to describe to Photoshop what the data means. You still must profile the display! Display Using Monitor Compensation still plays a factor! You still need a descriptor to get from RGB to CMYK (or another flavor or RGB). How can we continue to debate the need of using ICC profiles in the world of Photoshop 5 and 6?

PS4 worked in basically the same fashion! Anyone who thinks otherwise doesn1t understand that from the day Photoshop started dealing with CMYK, it expected users to define what the numbers in an RGB file were. The bad news was that with PS4, that assumption was your individual display (the old monitor preference file). And the vast majority of users didn1t use any kind of accurate method of defining just what Joe1s or Dan1s display RGB was. No wonder Photoshop got a bum rap for doing RGB to CMYK conversions. What has changed today is that we don1t foolishly assume that all RGB files are in Joe1s or Dan1s (or any other individual users) monitor RGB. We expect the RGB to be from any number of scanners or cameras. What makes anyone on this list assume that all such capture device are in any way similar to, let alone identical to their individual displays? What if you have a Mac user that deals with a monitor gamma of 1.8 and a PC user who deals with 2.2 gamma? When each user gets the same file from a scanner, which one is seeing the data correctly (if they assume monitor RGB)? Neither!

I will say it once more and stop for the day: Digital files are simply 11s and zero1s. The meaning of a color isn1t defined without a profile. Even with CMYK, the numbers only assume a certain color IF the numbers are destined for a specific device. IF all output devices that dealt with CMYK produced identical results, we wouldn1t need output profiles. We all know this isn1t the case (that all CMYK devices behave identically). We also know all input RGB devices don1t behave identically. So we either guess what these numbers mean or we KNOW what these numbers mean. Either way, the only way you can do this is with a profile.

Andrew Rodney

From: "Maris V. Lidaka, Sr.", mlidaka@ameritech.net
Date: Mon, Sep 3, 2001, 12:57 PM
RE: Re: [colortheory] False gamma vs curves

I am unconvinced that whether this method is called color correction or color management matters.
Dan's original message indicated he was originally "assigning" a profile rather than converting. The result is different (improved) both on screen and in print, so the CRT pixels' numbers and the CMYK numbers changed even if the (imaginary?) original numbers didn't.

Maris Lidaka

From: William Alexander, walexander@leisurepublishing.com
Date: Mon, Sep 3, 2001, 1:10 PM
RE: Re: [colortheory] False gamma vs curves

Lurker just curious...
I am beginning to realize the need for proper profiling in my workflow, but I'm kicking myself due to the fact that something that, to some, is so simple to understand, totally baffles me. Can anyone on the list recommend the book that must be out there which describes simply and concisely (probably more of a pamphlet really) how to incorporate profiles correctly into my workflow? If one does not exist, surely the collective knowledge of this group could write one as an appendix to Professional Photoshop 7.

William Alexander
Art Director
Leisure Publishing Company
540-989-6138

From: gowens01GO@netscape.net
Date: Mon, Sep 3, 2001, 1:23 PM
RE: [colortheory] False Profile

Hi Group
The false profile could be called the "f/ correction." Basically what happens is that you are correcting under or over exposed images by adjusting the gamma lower or higher. I think this is a really good idea. Especially for the person who has his system carefully profiled from input to output. Should they get a outside image that is over or under exposed the false profile becomes a variable that should save you from changing a bunch of profiles.

Gary Owens

From: Terry Wyse, terry@allsystems.com
Date: Mon, Sep 3, 2001, 1:42 PM
RE: Re: [colortheory] False gamma vs curves

on 9/3/01 5:06 PM, William Alexander wrote:
> I am beginning to realize the need for proper profiling in my workflow, but
> I'm kicking myself due to the fact that something that, to some, is so
> simple to understand, totally baffles me. Can anyone on the list recommend
> the book that must be out there which describes simply and concisely
> (probably more of a pamphlet really) how to incorporate profiles correctly
> into my workflow? If one does not exist, surely the collective knowledge of
> this group could write one as an appendix to Professional Photoshop 7.

I'm not sure one really exists from a WORKFLOW standpoint (that means a front-to-back "system" approach to me). However, there's a few good books that speak to some of the specific areas (image capture, display, application, print/proof, etc.). Getting it all together as a workflow is something else.

Rather than plug *other's* books on Dan's list, email me off-list and I'll recommend a couple.

Regards,
Terry
_____________________________
Terence L. Wyse
Prepress Specialist
All Systems Integration, Inc.
http://www.allsystems.com
terry@allsystems.com
_____________________________

From: Bob Smith, rmsmith@calpha.com
Date: Mon, Sep 3, 2001, 2:17 PM
RE: Re: [colortheory] False gamma vs curves

Andrew Rodney wrote:
> But you are NOT correcting, that1s my point. You are defining. How can you
> be correcting by not altering the data in the file, only how Photoshop
> interrupts the numbers but the alteration of a profile?

Can't 'correcting' include changing an inappropriate description of the image data to a more appropriate one? Even though numbers in the file weren't changed, we now have a file that displays better and will print better when converted to an output space. We have a file that's easier to edit because we can see it now. You're tying the word correcting to altering numbers in the file. I'm saying that correcting is taking a file that looks or outputs poorly and changing something...anything... so it doesn't do that any more.

Bob Smith

From: Andrew Rodney,
Date: Mon, Sep 3, 2001, 3:24 PM
RE: Re: [colortheory] False gamma vs curves

on 9/3/01 10:54 AM, Maris V. Lidaka, Sr. at mlidaka@ameritech.net wrote:
> I am unconvinced that whether this method is called color correction or
> color management matters.

> Dan's original message indicated he was originally "assigning" a profile
> rather than converting. The result is different (improved) both on screen
> and in print, so the CRT pixels' numbers and the CMYK numbers changed even
> if the (imaginary?) original numbers didn't.

Not really. The resulting CMYK data would be different if one used two different source profiles but that is simply due to how ICC profiles work with conversions of any kind. One must define a source AND a destination profile to conduct a conversion. Both are equally important. When Photoshop doesn1t know the meaning of the numbers in a file, it just makes a guess (the guess being whatever you, the user set in your Color Settings). So if you have an untagged file and your color settings are set to sRGB, even if the file is in Adobe RGB, sRGB is used for the conversion and preview (prior to the conversion). Assigning only allows Photoshop to know what the files numbers mean. But this is very important and wouldn1t be much of an issue if people would tag files in the first place.

Andrew Rodney

From: Andrew Rodney,
Date: Mon, Sep 3, 2001, 3:18 PM
RE: Re: [colortheory] False gamma vs curves

on 9/3/01 11:06 AM, William Alexander at walexander@leisurepublishing.com
wrote:
> Can anyone on the list recommend
> the book that must be out there which describes simply and concisely
> (probably more of a pamphlet really) how to incorporate profiles correctly
> into my workflow?

I have a PDF tutorial at http://www.digitaldog.net that walks users through the processes of assigning and converting with profiles. It should give you better idea of what is happening in Photoshop 6 and how that application deals with profiles and previewing.

Andrew Rodney

From: Andrew Rodney, Date: Mon, Sep 3, 2001, 3:14 PM
RE: Re: [colortheory] False gamma vs curves

on 9/3/01 12:10 PM, Bob Smith at rmsmith@calpha.com wrote:
> Can't 'correcting' include changing an inappropriate description of the
> image data to a more appropriate one? Even though numbers in the file
> weren't changed, we now have a file that displays better and will print
> better when converted to an output space. We have a file that's easier to
> edit because we can see it now. You're tying the word correcting to altering
> numbers in the file. I'm saying that correcting is taking a file that looks
> or outputs poorly and changing something...anything... so it doesn't do that
> any more.

Would you consider changing the brightness and contrast settings on your monitor to make a file look better color correction? I wouldn1t but maybe you and others would. In essence, this is all you are doing when assigning the correct (better) profile. You are altering the display conditions. So I don1t consider this correcting the file as the file has undergone no change what so ever. One could do the same thing by loading different Knoll Gamma settings to alter the display. This is a kludge of a workflow Dean Collins suggested as his 3poor man1s calibration.2 The display changes on an image by image basis to make it match some kind of output device. In the Photoshop 6 world, I don1t buy it.

Andrew Rodney

From: varis@varis.com, varis@varis.com
Date: Mon, Sep 3, 2001, 3:42 PM
RE: Re: [colortheory] False gamma vs curves

Guys, please....
you say potato, I say pot-ah-to....

I think this thread has gone on long enough....

--
regards,

Lee Varis
varis@varis.com
888-964-0024
www.varis.com

From: Chris Murphy,
Date: Mon, Sep 3, 2001, 3:52 PM
RE: Re: [colortheory] False gamma vs curves

Maris V. Lidaka, Sr. writes:
>Dan' original message indicated he was originally "assigning" a profile
>rather than converting. The result is different (improved) both on screen
>and in print, so the CRT pixels' numbers and the CMYK numbers changed even
>if the (imaginary?) original numbers didn't.

I understand what's going on, I just don't consider this color correction. It's profile correction. The originally assigned profile was wrong. Dan's technique creates a better source profile, and assigns it instead of the truly false profile. Dan's "false profile" is actually a "better than the original, while still not perfect profile."

I've been training more advanced customers with a similar technique of assigning a variety of profiles to their images to see which one looks like a rendering they prefer. Once they settle on one that they like (even if it's not perfect) that becomes the source profile for that image. This is at least as much color management as color correction (for without color correction, one would be unsure of the effect of gamma on an image), but I dispute that it's mostly color correction or that the resulting profile is accurately referred to as "false."

Chris Murphy
Color Remedies (tm)
Boulder, CO
303-415-9932

From: Chris Murphy,
Date: Mon, Sep 3, 2001, 3:45 PM
RE: Re: [colortheory] False gamma vs curves

Ron Bean (rbean@execpc.com) writes:
>No, this strategy says "I am using a tool for a purpose it was
>not designed for".

What? What Dan is using it for is SPECIFICALLY what it's designed for. That's the reason why Adobe allows you to create your own RGB spaces by futzing with gamma (and primaries and whitepoint).

> The new profile does not even come close to
>correcting the image by itself, it's just a starting point.

You are arguing that it's not color management only because it doesn't do a perfect job? That if it did the perfect job, and completely corrected the image on its own, *then* it would be color management and not color correction? That's ludicrous.

The original starting point is what was wrong, the custom created profile is BETTER. There is no 1 or 0, black or white, yes or no with color management. There are ranges of how bad or how good something is. You are saying that because the profile doesn't do a perfect job, it's not color management. That is NOT a compelling argument at all.

One can have a profile that does 50% of the job, but isn't good enough to get the rest of the way there. That is *STILL* color management - the remaining 50% would be solved with color correction.

>Have you looked at the original in Dan's article? ("M" on p36)

No I haven't.

>Do you really think you could create a profile for that?

I probably could but would it be practical? Often it's much more practical to use a profile to get as much of the work done as possible in advance without even changing a single pixel by ensuring the assigned profile is as good as possible from the get go. That's precisely what Dan's technique is going. The remaining portion of the technique, which is equally important, is fine tuning it with color correction.

In order to create such a profile, I would need a suitable test image. Probably the only suitable test image would be the image that has this particular problem in the first place. I would use color correction techniques with a suitable profile editing application and make the necessary edits to the profile instead of directly to the image. Once I'm done, I would have the added step of actually applying the profile. The profile is probably not reusable for anything else so I fail to see the benefit of creating a profile for this one image, even if I can do so.

Chris Murphy
Color Remedies (tm)
Boulder, CO
303-415-9932

From: Bob Smith, rmsmith@calpha.com
Date: Mon, Sep 3, 2001, 3:58 PM
RE: Re: [colortheory] False gamma vs curves

Andrew Rodney wrote:
> One could do the same thing by loading different Knoll Gamma
> settings to alter the display.

That's not the same thing at all. Doing that would not alter the results of a move to another color space... same file numbers with same definition yields the same conversion. It just looks different on the monitor cause we whacked it with Knoll Gamma settings. The false profile yields a completely different file when moved to another space because even though the numbers are the same, their definition has been changed (or 'corrected') so it moves to another space very differently.

Bob Smith

From: Chris Murphy,
Date: Mon, Sep 3, 2001, 4:01 PM
RE: Re: [colortheory] False gamma vs curves

Bob Smith writes:
>Can't 'correcting' include changing an inappropriate description of the
>image data to a more appropriate one?

No - that is color management. RGB numbers by themselves are meaningless. By changing profiles, or creating a custom one that does a better job describing those RGB values is also color management.

> Even though numbers in the file
>weren't changed, we now have a file that displays better and will print
>better when converted to an output space.

That is why having an accurate source profile is so important. You can have the best press profile ever made, but if the source profile for an image is wrong, the separation will be wrong also. Fix the source profile, and you will have a better separation.

> We have a file that's easier to
>edit because we can see it now. You're tying the word correcting to altering
>numbers in the file.

It's easier to edit because now it's in the correct source space. Previously it was in the wrong source space. That's why it was more difficult to see originally; and why it's easier to work with after the fact.

>I'm saying that correcting is taking a file that looks
>or outputs poorly and changing something...anything... so it doesn't do that
>any more.

If we weren't involved in a discussion on semantics, I guess now we are. Yes you ARE correcting something - but what you are correcting is a color management setting. The previous setting, the assigned profile, was wrong. That's why the image looked wrong, that's why it would output wrong. By correcting the assigned profile (to something better than it was, even if it's not perfect), the image can be further refined with true color correction techniques. The result is superior image reproduction.

Chris Murphy
Color Remedies (tm)
Boulder, CO
303-415-9932

From: Terry Wyse, terry@allsystems.com
Date: Mon, Sep 3, 2001, 4:12 PM
RE: Re: [colortheory] False gamma vs curves

on 9/3/01 7:57 PM, Lee Varis wrote:
> Guys, please....
> you say potato, I say pot-ah-to....
> I think this thread has gone on long enough....

Actually, Dan would say/spell "potatoe". Dan QUAIL that is.

OK, what if we agree that applying the "false" profile *could* be called a "correction" but NOT image editing? To me, image editing implies a change in pixels where a "correction" doesn't imply anything, it's just a correction.

OK, never mind then.

TLW

From: Chris Murphy,
Date: Mon, Sep 3, 2001, 4:16 PM
RE: Re: [colortheory] False gamma vs curves

Bob Smith writes:
>That's not the same thing at all. Doing that would not alter the results of
>a move to another color space... same file numbers with same definition
>yields the same conversion.

Conversion is color management. Converting from a source to destination is color mangement. Selecting different profiles, creating different profiles, fixing or correcting previously incorrectly set profiles is color management.

> It just looks different on the monitor cause we
>whacked it with Knoll Gamma settings.

What happens to Dan's RGB image if he saves it but:

a.) does not convert it to CMYK first;
b.) does not embed his newly created ICC profile into the image?

The image is indistinguishable from the original. Color management must be used in order for his method to have an EFFECT on the image - and that's because his method using a color management tool.

>The false profile yields a completely
>different file when moved to another space because even though the numbers
>are the same, their definition has been changed (or 'corrected') so it moves
>to another space very differently.

Yes! And that is the definition of color management. That has always been the definition of color management. I can't remember how many times I've said on various lists that *both* source *and* destination profiles must be correct to get a good separation.

The technique Dan exposes to an otherwise anti-color management crowd I think is fantastic. What I don't like is inaccurate and misleading terminology. Now all of a sudden people are starting to use "false profile" like it's a real term, like it's an accurate term. It's wrong and it's bad for users and it's bad for the graphic arts as a whole.

It is not a "potatoe" vs. "potahto" issue. It's the difference between a potato and a giraffe.

Chris Murphy
Color Remedies (tm)
Boulder, CO
303-415-9932

From: Andrew Rodney,
Date: Mon, Sep 3, 2001, 4:19 PM
RE: Re: [colortheory] False gamma vs curves

on 9/3/01 1:58 PM, Bob Smith wrote:
> That's not the same thing at all. Doing that would not alter the results of
> a move to another color space... same file numbers with same definition
> yields the same conversion. It just looks different on the monitor cause we
> whacked it with Knoll Gamma settings. The false profile yields a completely
> different file when moved to another space because even though the numbers
> are the same, their definition has been changed (or 'corrected') so it moves
> to another space very differently.

All true but the point was that by altering the source profile, the net result is an alteration of the preview, just as changing the Knoll Gamma setting would do. My point is you haven't corrected the image, you've changed the way it is being previewed. This isn't color correction. In both cases, the pixel data wasn't altered.

The "false profile" doesn't produce a completely different file UNTIL you convert it. But at this point, pixel data is changed. My argument is that until you alter the data, you haven't corrected the file. You are just correcting the preview.

Andrew Rodney

From: William Alexander, walexander@leisurepublishing.com
Date: Tue, Sep 4, 2001, 8:31 AM
RE: Re: [colortheory] Beginner Profiles question

Wait... I have one more beginner question which I hope someone can answer. I understand that the profiles are only altering the way my monitor interprets the numeric data that creates the image, and doesn't alter that data. Occasionally, though, when I open an image for the first time in Photoshop, I get a dialog "Converting Colors" which appears to me to take a long enough time to complete that it must be changing the data of the image. Is this an entirely different sort of profile? One is for the interpretation of my monitor and one is used in conversions? I keep hearing references to profiles not changing the data just how it's interpreted. Which is the true statement?
William Alexander

From: N9VJG, n9vjg@abac.com
Date: Tue, Sep 4, 2001, 8:58 AM
RE: [colortheory] Color Profile Debate Part XXIII

Greetings Everyone:
I will not take sides or criticize anyone on the Color Management/Calibration issue. As Dan wrote, everyone wants consistency and uses various tools and techniques to achieve it.

However, I would like to share the fact that I have fallen into the habit of deleting every post regarding this issue because it has become a "my religion is better than yours" issue.

Let's get back to K plate blending, Lab correction and writing-good-curves discussions so we can save the world from the scourge of digitally-compromised images and johnny-come-lately Photoshop experts.

--
Eric Curtis Bond
Photo Grafix
http://www.abetterreality.net
(847) 673-7043

From: William Alexander, walexander@leisurepublishing.com
Date: Tue, Sep 4, 2001, 9:07 AM
RE: Re: [colortheory] Color Profile Debate Part XXII

I agree that the thread falls out of the range of good color correction in Dan's terms, but as a novice to profiles, and a Photoshop user with 7 years of experience, I am concerned that improper use of profiles will cause my carefully corrected images to reproduce incorrectly somewhere down the line. While I too would rather see the energy in this list spent on curves and lab corrections etc. I hope there is still a little room for helping me understand how to ensure that profiles don't screw up my color corrections.
William Alexander

From: Andrew Rodney,
Date: Tue, Sep 4, 2001, 9:13 AM
RE: Re: [colortheory] Beginner Profiles question

on 9/4/01 6:29 AM, William Alexander at walexander@leisurepublishing.com
wrote:
> Wait... I have one more beginner question which I hope someone can answer.
> I understand that the profiles are only altering the way my monitor
> interprets the numeric data that creates the image, and doesn't alter that
> data. Occasionally, though, when I open an image for the first time in
> Photoshop, I get a dialog "Converting Colors" which appears to me to take a
> long enough time to complete that it must be changing the data of the image.
> Is this an entirely different sort of profile? One is for the interpretation
> of my monitor and one is used in conversions? I keep hearing references to
> profiles not changing the data just how it's interpreted. Which is the true
> statement?

IF you have the Convert policy on in Photoshop 6 AND you have the warning check boxes off in color preferences, you are giving permission to Photoshop to convert any file not in the preferred color space into the preferred colorspace. The better approach is to use the Preserve policy or if you want to use the Covert policy, at least turn the warnings check boxes on so you can be informed about the process and decide on a case by case bases if you want to invoke a conversion or not. In many cases, you will not want to convert but rather preserve the profile.

Profiles DO change data when a specific conversion is asked for (which is what is happening in your case above). You may have your preferred RGB working space set to Adobe RGB and open a file in ColorMatch RGB. Since the Convert policy is on (this tells Photoshop you want a conversion to take place) AND you have the warning check boxes off, Photoshop is converting from Adobe RGB to ColorMatch RGB (changing the data). In such a scenario, you would be far better off preserving the original profile (Adobe RGB).

Andrew Rodney

From: Andrew Rodney,
Date: Tue, Sep 4, 2001, 9:22 AM
RE: Re: [colortheory] Color Profile Debate Part XXIII

on 9/4/01 7:05 AM, William Alexander wrote:

> I agree that the thread falls out of the range of good color correction in
> Dan's terms, but as a novice to profiles, and a Photoshop user with 7 years
> of experience, I am concerned that improper use of profiles will cause my
> carefully corrected images to reproduce incorrectly somewhere down the line.

That most certainly is the case!

> While I too would rather see the energy in this list spent on curves and lab
> corrections etc. I hope there is still a little room for helping me
> understand how to ensure that profiles don't screw up my color corrections.

If you want to live with LAB, you don1t have to worry about profiles... as long as you stay in LAB. LAB is self defining; you don1t need a profile to define LAB. RGB and CMYK are not (hence the reason we need to define them). Of course, there isn1t a device on the planet that output1s to LAB so guess what, we all have to worry about definitions of RGB and CMYK.

Cool color correction tricks using LAB is lots of fun and occasionally useful. Of course if the file you just corrected in LAB doesn1t output correctly (or as you expected), the work was an exercise in futility.

Andrew Rodney

From: Dan Margulis, 76270.1033@compuserve.com
Date: Tue, Sep 4, 2001, 9:46 AM
RE: Re: [colortheory] Beginner Profile Question

William writes,
>>I am beginning to realize the need for proper profiling in my workflow, but I'm kicking myself due to the fact that something that, to some, is so simple to understand, totally baffles me.>>

It's hardly shocking that you or anyone else should be baffled--as you've seen in the last day, any mention of them in a less than politically correct way results in clouds of jargon and ridicule, not to mention mailbombs to this group.

>>Can anyone on the list recommend the book that must be out there which describes simply and concisely (probably more of a pamphlet really) how to incorporate profiles correctly into my workflow?>>

You already have a profiled workflow, and at the moment, there's no reason to believe that there's anything incorrect about it. In your Edit: Color Settings>Working RGB, you have some definition--Apple RGB, ColorMatch RGB, or perhaps something else. That's a profile--it tells Photoshop what "RGB" means to you. This information is necessary if you take the file to LAB or CMYK.

Similarly, you have information in your Color Settings>CMYK that tells Photoshop what you want done when a file enters CMYK. This is a profile, too. Furthermore, I observed in a recent class that you have no compunction about editing that profile to make a false separation, as when you want a heavier black to preserve neutrality.

Creating an occasional false profile in CMYK has been standard practice for some time, although the term "false separation" is more common. Doing the same in RGB is logical but hasn't been convenient until Photoshop 6.

>>I understand that the profiles are only altering the way my monitor interprets the numeric data that creates the image, and doesn't alter that data. Occasionally, though, when I open an image for the first time in Photoshop, I get a dialog "Converting Colors" which appears to me to take a long enough time to complete that it must be changing the data of the image.>>

It is. This suggests that you are using Photoshop 5.x, with its color defaults unchanged.

>>Is this an entirely different sort of profile? One is for the interpretation of my monitor and one is used in conversions?>>

No, they're the same, but your default settings are causing a conversion on open, which is ordinarily a bad idea.

>>I keep hearing references to profiles not changing the data just how it's interpreted. Which is the true statement?>>

They are both true. The RGB profile defines what 135r150g170b, say, means. What that color will look like on your monitor will depend on your profile, because Photoshop uses it to interpret the number. Change your profile, and the monitor appearance will change. However, if you are just sending this RGB file to some kind of output device, then the profile *won't* matter--you're sending out 135r150g170b, the interpretation of that number doesn't matter, because the output device will have its own interpretation of what 135r150g170b means.

If instead of sending an RGB file to output, however, you're converting to CMYK, then the RGB profile does matter. To generate the proper CMYK values, Photoshop needs to interpret what 135r150g170b means, so that it can be matched as closely as reasonable. Two otherwise identical RGBs file with two different profiles print identically in RGB but produce two different CMYK files.

But again: you're already using profiles. And unless you are getting results with them that are not only bad but bad in a consistent way (the majority of files print too dark, too green in the shadows, too washed out, or whatever) you probably don't need to do anything more with them.

Dan Margulis

From: William Alexander, walexander@leisurepublishing.com
Date: Tue, Sep 4, 2001, 8:31 AM
RE: Re: [colortheory] Beginner Profiles question

Wait... I have one more beginner question which I hope someone can answer. I understand that the profiles are only altering the way my monitor interprets the numeric data that creates the image, and doesn't alter that data. Occasionally, though, when I open an image for the first time in Photoshop, I get a dialog "Converting Colors" which appears to me to take a long enough time to complete that it must be changing the data of the image. Is this an entirely different sort of profile? One is for the interpretation of my monitor and one is used in conversions? I keep hearing references to profiles not changing the data just how it's interpreted. Which is the true statement?
William Alexander

From: Chris Murphy,
Date: Tue, Sep 4, 2001, 10:07 AM
RE: Re: [colortheory] Beginner Profiles question

William Alexander writes:
>I understand that the profiles are only altering the way my monitor
>interprets the numeric data that creates the image, and doesn't alter that
>data.

Profiles can do two things. They can affect preview and they can affect pixels.

Assigning a profile to an image (also known as tagging, which profile embedding is related to) involves only ONE profile, and therefore does not change the pixel values of the image. It only changes the definition of what flavor of RGB applies to that image. You will see the on screen preview of that image change, but not the values.

Converting images from one space to another (a mode change such as RGB to CMYK, or Lab to RGB are examples; but RGB to RGB conversions are possible as well, same with CMYK to CMYK). Converting involves TWO profiles - a source and destination. The source comes from assigning a profile (or tagging it) per the above. The destination is the profile describing the space you want to convert to.

Example 1: If you have an RGB image and you want to convert it to CMYK. The source profile is the specific RGB space assigned to your RGB image. If you don't have one specifically assigned to the image, then in Photoshop 6, what you have set as the RGB Working Space is what will be used as source. What you have set as the CMYK working space will be the destination when you do a traditional mode change using Image:Mode:CMYK.

> Occasionally, though, when I open an image for the first time in
>Photoshop, I get a dialog "Converting Colors" which appears to me to take a
>long enough time to complete that it must be changing the data of the image.

It is. Converting color means exactly that. The pixel values themselves are changing. I could be mistaken, but I suspect you are using Photoshop 5? If you are using Photoshop 6, make sure your Color Management Policies are set to either "Preserve Embedded" or "Off" and not "Convert to Working RGB/CMYK." In Photoshop 6, these conversions are annoying and unnecessary but not dangerous. In Photoshop 5, they could be dangerous.

>I keep hearing references to
>profiles not changing the data just how it's interpreted. Which is the true
>statement?

Both. It depends on how they are used. They can be used just to defined color, or they can be used to convert color. One profile can only define color. One profile is insufficient for converting images. You need two profiles to convert an image - a source profile and a destination profile.

Chris Murphy
Color Remedies (tm)
Boulder, CO
303-415-9932

From: William Alexander, walexander@leisurepublishing.com
Date: Tue, Sep 4, 2001, 11:07 AM
RE: Re: [colortheory] Beginner Profiles question

Ok in the interest of help I have posted my Photoshop 6 color settings at http://www.idzyn.com/settings.jpg could someone anyone tell me if they seem to be correct? Much grateful thanks applies to anyone who comments.

William

From: Andrew Rodney,
Date: Tue, Sep 4, 2001, 11:53 AM
RE: Re: [colortheory] Beginner Profiles question

on 9/4/01 8:56 AM, William Alexander wrote:
> Ok in the interest of help I have posted my Photoshop 6 color settings at
> http://www.idzyn.com/settings.jpg could someone anyone tell me if they seem
> to be correct? Much grateful thanks applies to anyone who comments.

No, these settings are problematic. Let1s look at them one by one:

For RGB preferred working space, you have set your display profile. This is a VERY bad idea. What you are doing is defining your working space as a display profile and that flies in the face of the logic Adobe placed in Photoshop 5 and 6 in divorcing the display from how we edit our files. You are telling Photoshop to assume all files in RGB are somehow your display which they are not. RGB Working Spaces should be well behaved (R=G=B is neutral) and not based on any specific device. By using your display profile as a Working Space, you are insuring that neither of these are the case. IF you want a Working Space that is well behaved but is close to a calibrated display (but not based on any individual display), use ColorMatch RGB here.

Next you should consider NOT having your policies set to OFF. This insures that Photoshop will do it1s best to ignore profiles and save files without embedded profiles. I1d set the policy to 3Preserve2 which provides the most flexibility. What this will do is keep any file you open in the same colorspace as it came to you. With OFF, you are asking (actually insuring due to your Working Space being your monitor) that all files get their profiles stripped and saved as such. If a user sends you a file in say Adobe RGB, your current settings will insure that you will not see the file correctly and the file will be saved with no profile. Not good. OFF is Adobe1s way of allowing you to burry your head in the sand and not be bugged. But it insures that you1ll have the best chances of hosing your files! If you are sharing files with others (those that may be smart enough to tag their files), you1ll insure that when you return them, those nice tags are gone.

Put the warning check boxes on. Yes, it can be a hassle to be reminded every time you open a file that something isn1t in sync but until you get the feel for things, it1s the safest way to work. In fact, the only time I would ever recommend NOT having warnings is a workflow where you have so much control over the files you open that you are 100% sure that you know the colorspace of the file and you want to bring it into Photoshop 6 a certain way. Most users are getting files from all over and getting files in various flavors of RGB or CMYK. So being reminded at open (and the open dialog warning will actually show you what the space of the file is prior to opening it) provides a great deal of control. You can decide at this point to preserve the file (let it open in the colorspace it was tagged as) or convert. You can go either way on a case by case bases.

Lastly I1d set the Engine to Adobe ACE. It seems to be the best behaved CMM for conversions.

If you go to http://www.digitaldog.net you1ll find a PDF that explains EVERY item in this dialog and what they all do. Go to the tips and tricks page (it1s called Photoshop 6 Color Management).

Andrew Rodney

From: William Alexander, walexander@leisurepublishing.com
Date: Tue, Sep 4, 2001, 12:41 PM
RE: Re: [colortheory] Beginner Profiles question

Alright I've changed the settings. I open the first document I plan on working on, a Kodak PhotoCD image that is RGB. It has no profile embedded. What profile should I add? Or none at all? I plan to immediately convert to LAB, then to CMYK. Does it even need an RGB profile at all in this case? If so do I use Colormatch, which is my default RGB, or my monitor? Also, if I don't need the profile I created for my monitor, then what purpose does it serve?

From: Andrew Rodney,
Date: Tue, Sep 4, 2001, 1:10 PM
RE: Re: [colortheory] Beginner Profiles question

on 9/4/01 9:47 AM, William Alexander wrote:
> It has no profile embedded. What profile should I add Or none at all? I plan
> to immediately convert to LAB, then to CMYK. Does it even need an RGB profile
> at all in this case? If so do I use Colormatch, which is my default RGB, or my
> monitor? Also, if I don't need the profile I created for my monitor, then what
> purpose does it serve?

You need to assign the profile that describes the numbers in the file. It has no embedded profile (problem) so you have to guess. Since no one supplied a profile, you need to Assign something OR the preferred RGB Working Space you picked (ColorMatch RGB) is used. How does the image look?

You DO need to create a profile for your display! You just don1t load it in the color settings. It is used only for preview purposes and if you created the profile and placed it in the right place, PS will use it.

Andrew Rodney

From: Chris Murphy,
Date: Tue, Sep 4, 2001, 3:09 PM
RE: Re: [colortheory] Beginner Profiles question

on 9/4/01 9:47 AM, William Alexander wrote:
> Also, if I don't need the profile I created for my monitor, then what
> purpose does it serve?

Ooops - forgot to answer this. Make sure your profile is set in the Monitors control panel (click on the color button, you'll see a list of profiles). Photoshop 6 asks the operating system what the display profile is and the operating system tells it. So that setting is taken care of for you.

Chris Murphy
Color Remedies (tm)
Boulder, CO
303-415-9932

From: Chris Murphy,
Date: Tue, Sep 4, 2001, 3:04 PM
RE: Re: [colortheory] Beginner Profiles question

William Alexander writes:
>Alright I've changed the settings. I open the first document I plan on
>working on, a Kodak PhotoCD image that is RGB. It has no profile embedded.
>What profile should I add? Or none at all? I plan to immediately convert to
>LAB, then to CMYK. Does it even need an RGB profile at all in this case? If
>so do I use Colormatch, which is my default RGB, or my monitor? Also, if I
>don't need the profile I created for my monitor, then what purpose does it
>serve?

A technique I use, so long as the monitor is calibrated and profiled, is I go to the Image:Mode:Assign Profile menu. This is for all images that either do not have a profile embedded in them, or they have a questionable profile embedded in them (you'd know this based on who's giving you the image). Ensure the preview checkbox is checked. Now go through the profiles one by one and note how the preview changes. Find one that makes the image the most acceptable on-screen. What you're doing here is guessing at a suitable source space, while also evaluating the image for rendering. Note that what you LIKE is probably not the same thing as the original -- so you need to be clear on whether artistic license is acceptable for the image/project you are working on, or if you're supposed to match something the client provided.

Once you get something that you like better than the other profiles, click OK. That's the assigned profile. Now you can convert to Lab, CMYK --or a well behaved RGB space like ColorMatch RGB or Adobe RGB. I would highly recommend converting to RGB because you will find initial color correction easier in RGB; and this is practically a given because the image has a questionable origin and a questionable assigned profile, so it likely needs at least a gray balance job done on it - and that's easier done in RGB than any other space.

And why - you might ask - wouldn't you just gray balance the image with the assigned profile? Why convert to ColorMatch or Adobe RGB first? Because RGB device profiles are similar to CMYK device profiles in that they are NOT gray balanced. Equal numbers do not make gray in those spaces. Whereas in ColorMatch RGB, Adobe RGB (and other standardized RGB spaces) equal amounts of red, green and blue make a completely neutral gray.

Chris Murphy
Color Remedies (tm)
Boulder, CO
303-415-9932

From: Chris Murphy,
Date: Tue, Sep 4, 2001, 2:57 PM
RE: Re: [colortheory] Beginner Profiles question

William Alexander writes:
>Ok in the interest of help I have posted my Photoshop 6 color settings at
>http://www.idzyn.com/settings.jpg could someone anyone tell me if they seem
>to be correct?

1.
Working Space for RGB should be Colormatch RGB or Adobe RGB, or some reasonable standardized RGB space that is NOT based on an actual device. Your current setting here is your monitor profile which is not a good idea. (It may not be gray balance, it has a smaller gamut than either ColorMatch or Adobe RGB - and there are workflow reasons why as well.)

2.
Color Management Policies. There no right or wrong here, it just depends on what you're trying to do. Currently, the policy is set to rather drastic extremes, that of not color managing RGB images at all, and CONVERTING all CMYK images on open if they do not match the CMYK working space.

I could be convinced this is a good idea in certain situations, but I'm not convinced these settings are good in your particular case. I would change the color management policies for all three spaces to "Preserve embedded profile". You can leave the Ask When Opening and Ask When Pasting check boxes unchecked if you like; all they do is give you an opportunity to override the behavior of the pop-up menus above them. Preserve embedded profile is a very safe setting.

3.
I would change the Engine to "Adobe (ACE)" unless you have a really good reason why you want to use Colorsync. It's not a big deal, but the Adobe (ACE) engine will give you better conversions. Visibly better? Maybe not - but there are fewer bugs (as in none that I know of) with the Adobe engine. It's not a major sticking point, but that's what I would use unless I needed Photoshop output to look the same as something like QuarkXPress if you are using color management in QuarkXpress (which can use only ColorSync).

4.
Intent should be set to Relative Colorimetric for most images. If you often work with bright, vivid, saturated images with fine detail - then leave it set to perceptual. If you work with normal images, change it to relative colorimetric.

5.
Turn off the Use Dither (8-bt/channel images) option. There is currently a bug that occasionally causes white in RGB to convert with scum dots. That is 255,255,255 in RGB will convert to something OTHER THAN 255,255,255 in another RGB space, or 0,0,0,0 in CMYK. This is not good.

Chris Murphy
Color Remedies (tm)
Boulder, CO
303-415-9932

From: Dan Margulis, 76270.1033@compuserve.com
Date: Tue, Sep 4, 2001, 3:37 PM
RE: [colortheory] Color Profile Debate Part XXIII

Eric writes,
>>However, I would like to share the fact that I have fallen into the habit of deleting every post regarding this issue because it has become a "my religion is better than yours" issue.>>

I am sympathetic to this position and also to those North Americans who came back from our three-day holiday weekend to find more than 40 messages from this group in their in box.

I observe that the offending thread began in earnest Saturday night and in the following 24 hours six persons who are not vendors of color management services contributed a total of 10 messages between them. Meanwhile, Andrew Rodney alone favored us with eight posts on the same topic. I think we all respect Andrew's POV and would not want to prevent him from expressing it, but surely this could be done more economically. After the first three or four posts nobody could possibly have been in any doubt as to what his position was or why. Continuing to mailbomb the group after that isn't going to persuade anybody who isn't persuaded already.

This has been a recurrent problem in the group (see Eric's title to this post) and so I once again appeal publicly to Andrew to limit the sheer volume of what he posts when a topic like this rears its head.

>>Let's get back to K plate blending, Lab correction and writing-good-curves discussions so we can save the world from the scourge of digitally-compromised images and johnny-come-lately Photoshop experts.>>

It isn't that easy. The concepts are related. I would agree that a lot of the nostrums that our color management friends recommend either are useless or of very little value, but this seems to be an exception. I find that the curves, etc., work better with this technique, at least when the image is very bad to begin with. Furthermore, there's been a great deal of feedback from people who have found the same thing.

Dan Margulis

From: "Bruce J. Lindbloom", blind@picto.com
Date: Tue, Sep 4, 2001, 4:48 PM
RE: Re: [colortheory] Color Profile Debate Part XXIII

Dan writes:
> Meanwhile, Andrew Rodney alone favored us with eight posts on the same
> topic. I think we all respect Andrew's POV and would not want to prevent him
> from expressing it, but surely this could be done more economically. After
> the first three or four posts nobody could possibly have been in any doubt
> as to what his position was or why. Continuing to mailbomb the group after
> that isn't going to persuade anybody who isn't persuaded already.
It didn't appear to me as though Andrew's reasons for posting were to establish any "position" or to "persuade" anyone. He was taking the time to provide very informative answers to specific questions on a topic that he is an expert on. I think he was trying to be helpful, not promote any personal agenda. --
Bruce J. Lindbloom, Pictographics Intl. Corp.

From: "Tara Marlowe", taramarlowe@hotmail.com
Date: Tue, Sep 4, 2001, 11:00 PM
RE: Re: [colortheory] False gamma vs curves

Tara Marlowe
DIGITAL, Inc.
New York City
646-522-8539
In a perfect world we would always get a file with it's source profile tagged. But I often don't know the person who made the capture or whether they know anything about tagging files. If there is a profile in the image I don't know if they put it there on purpose or not. I'm sure I'm not the only one who deals with this. So I need a solution that takes these variables into acount and doesn't depend on everyone else. Something more realistic, please.

>wouldn1t be much of an issue if
>people would tag files in the first place.
>
>Andrew Rodney

From: Bob Smith, rmsmith@calpha.com
Date: Wed, Sep 5, 2001, 9:37 AM
RE: Re: [colortheory] False gamma vs curves

Tara Marlowe wrote:
> But I often don't know the person who made the capture or whether
> they know anything about tagging files. If there is a profile in the image I
> don't know if they put it there on purpose or not. I'm sure I'm not the only
> one who deals with this. So I need a solution that takes these variables
> into acount and doesn't depend on everyone else.

In that situation which unfortunately is very common, all you can do is guess. At least Photoshop 6 makes this very easy to do without altering the image data. It was a much more awkward process in Photoshop 5. Just use the apply profile command with preview turned on and keep trying different profiles you have until you find the one that looks the best. If you've also received a good print along with the file, then that takes a little bit of the guesswork out of it as you can be looking for a profile that yields a match to the print rather than just totally guessing as to what the intended look of the file should be. Of course all of this assumes you have a well calibrated display since you're relying on the look of the displayed image to judge the file. Dan's idea of making a few stock 'false profiles' can also help with this process considerably. Once you've applied that profile you can then either edit the file from there or convert to a space that's more appropriate and continue from there.

Bob Smith

From: Andrew Rodney,
Date: Wed, Sep 5, 2001, 10:44 AM
RE: Re: [colortheory] False gamma vs curves

on 9/5/01 7:30 AM, Bob Smith at wrote:
> In that situation which unfortunately is very common, all you can do is
> guess. At least Photoshop 6 makes this very easy to do without altering the
> image data.
Bob is correct. Photoshop 6 makes this whole issue of embedded profiles pretty moot. First, it1s pretty difficult to embed the wrong profile. 2nd, since Photoshop 6 supports documents specific color, all you the questionable user has to do is look at the image and decide if you like the preview. If you do, you can stick with the embedded profile and get on with your life. If you don1t, you can assign different profiles or you can try Dan1s technique and modify Working Spaces to produce a preview you like. Once you get what looks good, you are telling Photoshop 61s Color Management 3I like what I see, now match it from here on...2

You basically have 3 possibilities here with respect to profile embedding. I1ll just say that despite the suggestions of others that I1m making this all out to be some kind of religious crusade, let me point out that these are simple facts (not belief systems). Photoshop 6 operates in a fixed architecture with regard to color and previewing images. If you don1t like Adobes methods (or if you prefer religion) then move down to Photoshop 4. I will further say that in a Photoshop 6 world, you MUST deal with at least two ICC profiles: a profile of your display for previewing files and a profile within each file (to describe the numbers for that preview). Like it or not, this is how Photoshop 6 works. It isn1t up to interpretation, believe systems or religion, it1s pure fact.

OK, scenario #1 is we deal with untagged files. Perhaps there are those that have religious beliefs that embedded profiles in files is the road to damnation. Facts are that Photoshop 6 will use whatever preferred working space you set in your color preferences along with your display profile to preview that file. Since the actual data may not be close to this preferred working space, it is as likely as unlikely that you1ll like what you see. If you don1t, you have to either change your preferred working space or assign a profile. Why not simply assign a profile?

Scenario #2 is there is an embedded profile but for whatever reason, you suspect it isn1t correct. Well how does it look on screen? If it looks OK, stick with that profile. If it doesn1t, pick another. All you are doing is altering the meaning of the numbers to produce a good looking preview. This is EXACTLY what Dan proposes in his article (and yes I did read it and have the pictures). He is being quite clever and showing how a user can alter a Working Space to change the meaning to produce a better preview. What is key here is having a calibrated display!!! Yes, god forbid the 3Calibrationists2 convince you that you need to profile your display but the fact is, the preview you see on screen is based on this profile. So if your display profile is complete science fiction, then altering 3False Profiles2 will not work since you are being visually fooled.

I1ll add that having an accurate profile of your display aids in another critical way. If you and all others you deal with have good display profiles, then you all see the same color on your various workstations (even PC1s running a gamma 2.2 display and Mac1s running 1.8). So, if you make this 3False Profile2 with a sound display profile and send it to Dan (who also has a good display profile), you both see the file as the original user intended. Isn1t that nice.

Scenario #3 is the easy one. The correct profile is embedded. You pass this file onto another user and he/she too has a calibrated and profiled display. They open the file and say 3Gee, looks good2 and off they go.

So with any scenario, you can get the correct definition to produce a good looking file. With scenario #1 (where we assume a user is setting the policies to OFF), all you do is continue to keep the original intent of the file a mystery. Why would one do this? Certainly not because someone down the chain MIGHT embed the wrong profile! You can fix that easily. You can call them up and ask them why the file looks so awful with profile #1 assigned when you find that profile #2 (perhaps even a 3False Profile2) corrects the preview.

Frankly, if everyone on this lists decides that they never want to embed a profile, that1s fine with me. IF I get your file, I have to jump through more hoops to figure out what your intent was. I don1t see why anyone would want to do this if they share files with others but so be it. I don1t (despite the rumors to the contrary) get a penny from the ICC every time someone embeds a profile (however, every time you hear a bell ring, an angle does get it1s wings...). Facts are facts and have nothing to do with religion. Facts are, you simply will not get a correct preview on screen (or one that syncs with any other PS users) unless you have a display profile that is accurate and an embedded profile in your file (unless the untagged file matches the preferred working space and you are still dealing with two sets of profiles).

Andrew Rodney

From: hd@imagers.com, hd@imagers.com
Date: Wed, Sep 5, 2001, 11:06 AM
RE: Re: [colortheory] Beginner Profiles question

William Alexander wrote:
> Alright I've changed the settings. I open the first document I plan on
> working on, a Kodak PhotoCD image that is RGB. It has no profile embedded.
> What profile should I ad? Or none at all? I plan to immediately convert to
> LAB, then to CMYK. Does it even need an RGB profile at all in this case? If
> so do I use Colormatch, which is my default RGB, or my monitor? Also, if I
> don't need the profile I created for my monitor, then what purpose does it
> serve?

While there is no profile embedded in the .pcd file, the source of the image should be considered when translating the scan from the CD. Photoshop ships with profiles to be used when opening Kodak Photo CD scans, and they show up as options in the Kodak PCD Format dialogue box (v6) or the Kodak ICC Photo CD dialogue box (v5).

The source profile you choose depends upon the film type (color reversal or negative) of the film that was scanned as well as which Kodak scanner was employed to make the scan.

Your choice of Lab (8 bit, v6) as the initial destination is, according to the opinions of experienced pcd handlers, the best choice for beginning work.

Henry Davis
hd@imagers.com

From: Andrew Rodney,
Date: Wed, Sep 5, 2001, 11:39 AM
RE: Re: [colortheory] Beginner Profiles question

on 9/5/01 8:50 AM, HD at hd@imagers.com wrote:
> William Alexander wrote:

>> > Alright I've changed the settings. I open the first document I plan on
>> > working on, a Kodak PhotoCD image that is RGB. It has no profile embedded.
>> > What profile should I ad? Or none at all? I plan to immediately convert to
>> > LAB, then to CMYK. Does it even need an RGB profile at all in this case? If
>> > so do I use Colormatch, which is my default RGB, or my monitor? Also, if I
>> > don't need the profile I created for my monitor, then what purpose does it
>> > serve?

> The source profile you choose depends upon the film type (color reversal
> or negative) of the film that was scanned as well as which Kodak scanner
> was employed to make the scan.

Keep in mind that the PhotoCD scan must be captured with this method in mind. There are basically two ways a PIW scan operator can set the scanner. One is with ICC profiles in mind in which case he/she must use the Universal Film Terms, turn the SBA (screen balance algorithm) off and use Locked Beam Scanning (which tells the operator not to try and correct the scan). If you don1t ask for this, you might not get these settings and picking a profile may produce poor results.

If you use Photoshop 6, you1ll have the option to pick the input profiles supplied and then convert to 8 or 16 bit LAB or RGB. If you pick RGB, the conversion will go from the source profile into whatever preferred RGB Working Space you pick in color preferences. Since you want to work in LAB, just pick that.

Andrew Rodney

From: "Tara Marlowe", taramarlowe@hotmail.com
Date: Wed, Sep 5, 2001, 11:43 AM
RE: Re: [colortheory] False gamma vs curves

Tara Marlowe
DIGITAL, Inc.
New York City
646-522-8539
Andrew Rodney wrote:

>since Photoshop 6 supports documents specific color, all you the
>questionable user has to do is look at the image and decide if you like the
>preview. If you do, you can stick with the embedded profile and get on with
>your life. If you don1t, you can assign different profiles or you can try
>Dan1s technique and modify Working Spaces to produce a preview you like.

So let's say I change the working space until I get something I like. At what point is the file actually changed to hold that definition. Am I fooling myself by just changing the preview or have I changed the definition of the image? I am confused when peole say "you aren't changing the numbers, but what the numbers mean" what's the difference?

>Once you get what looks good, you are telling Photoshop 61s Color Management
>3I like what I see, now match it from here on...

I don't mean to sound difficult but it usually isn't a matter of what I like in terms of color, it's matter of what the client has in mind. So with no hard copy to compare it to I am stuck trying to read minds.

If we were going to be that loose on our definition of color then none of this would be necessary in the first place. I'm not comfortable with futzing around with profiles until the color "looks good" to me, since that isn't a very objective approach. I need a way to verify my decision was a good one according to the client.

>OK, scenario #1 is we deal with untagged files. Facts are that Photoshop 6
>will use whatever preferred working
>space you set in your color preferences along with your display profile to
>preview that file. Since the actual data may not be close to this preferred
>working space, it is as likely as unlikely that you1ll like what you see. If
>you don1t, you have to either change your preferred working space or
>assign
>a profile. Why not simply assign a profile?

So I don't know if I change my working space if this changes the actual file
or just the way it looks onscreen.
>
>Scenario #2 is there is an embedded profile but for whatever reason, you
>suspect it isn1t correct. Well how does it look on screen? If it looks OK,
>stick with that profile. If it doesn1t, pick another. All you are doing is
>altering the meaning of the numbers to produce a good looking preview. This
>is EXACTLY what Dan proposes in his article (and yes I did read it and have
>the pictures). He is being quite clever and showing how a user can alter a
>Working Space to change the meaning to produce a better preview.

So is this just improving the preview or actually improving the image? When is the image changes vs. just the preview?

>
>Scenario #3 is the easy one. The correct profile is embedded. You pass this
>file onto another user and he/she too has a calibrated and profiled
>display.
>They open the file and say 3Gee, looks good2 and off they go.
>
>So with any scenario, you can get the correct definition to produce a good
>looking file. With scenario #1 (where we assume a user is setting the
>policies to OFF), all you do is continue to keep the original intent of the
>file a mystery.

So I assume this means that if I open and untagged file and don't assign a profile that it will be in the working space only until I close the file. The next time that file is opened in will be moved (converted?) to whatever working space is on that machine and it'll just keep changing everytime it's opened?

Sorry if this is too basic for you guys but I have been reading and lurking for quite a while now and I'm still not completely with it. It seems to me that for something like this to work it has to be understandable to a person of average intelligence. I'm pretty sure I'm not the only one out there that feels like this.

Thanks for your time and patience. Tara

From: Andrew Rodney,
Date: Wed, Sep 5, 2001, 12:44 PM
RE: Re: [colortheory] False gamma vs curves

on 9/5/01 9:24 AM, Tara Marlowe wrote:
> So let's say I change the working space until I get something I like. At
> what point is the file actually changed to hold that definition. Am I
> fooling myself by just changing the preview or have I changed the definition
> of the image?

Both. The exact moment you Assign a profile you change the meaning of the numbers and the preview updates to reflect that. The file actually undergoes NO change. The number of every pixel remains identical to their values previous to the newer assignment.

> I am confused when peole say "you aren't changing the numbers,
> but what the numbers mean" what's the difference?

You aren't. Digital images are numbers. They really don't have color (the file is just a big set of 1's and zero's). What does 244/19/38 look like? What color is it exactly? Take that value and output it on 12 different devices and you'll get 12 different colors. They will all appear more red then anything else (look how high the R value is). But they will all output different hues and densities of red.

> I don't mean to sound difficult but it usually isn't a matter of what I like > in terms of color, it's matter of what the client has in mind. So with no > hard copy to compare it to I am stuck trying to read minds.

IF you and your client both have a profile of your respective displays (one that is accurate of course), then when you open the file that is tagged, you both see the same preview! That is a net gain that we got with Photoshop 5 when we separated the way we edit our files (the Working Space) from our displays. You are not reading minds. You have a consistent line in the sand in which to view the files. And the file has a meaning both users (or both copies of Photoshop 6) understand. Without a profile, that isn't the case at all.

> I'm not comfortable with futzing
> around with profiles until the color "looks good" to me, since that isn't a
> very objective approach. I need a way to verify my decision was a good one
> according to the client.

What you are doing is producing a file you and your client can both look at and rely on as previewing the same. That isn't to say that if BOTH users see the same preview, one isn't going to dislike what the other has done. But at least both previews are in sync and a discussion can now happen with a common thread. The alternative is to set up a system where both users see different previews. That's a recipe for disaster. What if BOTH previews are incorrect and not an accurate indication of what will end up on print?

> So I don't know if I change my working space if this changes the actual file
> or just the way it looks onscreen.

It changes how Photoshop interprets the numbers so the preview changes to reflect that. The net result is a change in what you see (and others if you tag the file as such). The numbers don1t' change.

> So is this just improving the preview or actually improving the image? When
> is the image changes vs. just the preview?

It is improving the preview first and foremost. But it is also defining what will result WHEN you eventually output the file. Lets say you have an untagged file and it looks awful. You assign Adobe RGB 1998 and it looks great. You would never send a file in Adobe RGB 1998 to an output device. Adobe RGB is a Working Space and it probably has no bearing on any RGB printer you would send the file to. So you decide to send it off to the lab for a LightJet print. They have an output profile for their Lightjet and either they (or better you) do a Convert to Profile command where you convert from Adobe RGB 1998 to LightJet RGB. NOW all the numbers in the file change. They are optimized for this Lightjet. In addition, the file gets tagged with the LightJet profile and your preview updates to show you how the file will output to that device. OR you decide you want to output to a CMYK device. Same story, you convert from Adobe RGB to SWOP Coated V2 and send the file off. The numbers change and the file previews correctly based on SWOP Coated V2.

Now suppose you didn't first assign Adobe RGB 1998. The file looked ugly. Reason was your preferred RGB Space was set to something other than Adobe RGB 1998 (let's say sRGB and for that reason, Photoshop 6 is previewing the ugly file because it assumes the untagged file is sRGB). Well if you convert to CMYK, sRGB is used as the source. So your ugly file looks ugly in CMYK!

> So I assume this means that if I open and untagged file and don't assign a > profile that it will be in the working space only until I close the file.

Correct. IF you set sRGB as the preferred RGB Working Space in the color settings, Photoshop 6 just assumes all untagged files are sRGB. It has to guess something to produce a preview and for conversions.

> The next time that file is opened in will be moved (converted?) to whatever > working space is on that machine and it'll just keep changing everytime it's > opened?

That's right. So your untagged file looked ugly as sRGB. You send it to the client who's preferred space is Adobe RGB and he says it looks great. You say it looks ugly. You fix the file to make it look good and he gets it and now it looks ugly. You go back and forth until he fires you and you both commit suicide. If only the file was tagged, would fine on both/either machine.

Andrew Rodney

From: "Tara Marlowe", taramarlowe@hotmail.com
Date: Wed, Sep 5, 2001, 12:56 PM
RE: [colortheory] Working file/Output file

Thank you Andrew and Bob for your response.
One more question before I fade back into obscurity: Does everyone keep a main file before converting to output space for archiving and further edits? Or do you just convert it back to your working space if you need to edit it further or output to another device?

In other words I would have a working copy in Adobe RGB and duplicate copies that are only used for output. Tara

From: Stephen Marsh, Stephen Marsh
Date: Wed, Sep 5, 2001, 1:16 PM
RE: [colortheory] Re: More on profile assignments

Andrew writes:
"All you are doing is altering the meaning of the numbers to produce a good looking preview. This is EXACTLY what Dan proposes in his article (and yes I did read it and have the pictures). He is being quite clever and showing how a user can alter a Working Space to change the meaning to produce a better preview. What is key here is having a calibrated display!!! Yes, god forbid the Calibrationists? convince you that you need to profile your display but the fact is, the preview you see on screen is based onthis profile. So if your display profile is complete science fiction, then altering False Profiles? will not work since you are being visually fooled."

Andrew, I have to agree in part, but disagree with your view on Dan's use of profiles or workspaces in this context.

As previously noted, users like myself are fairly comfortable making a 'false separation' but it has only been since version 5 that most users have been able to play with a 'workspace hack' or whatever term finally makes all parties happy.<g>

This list and Dan's suggestions are not about monitor previews, but about final image data. Has this list forgotten what by the numbers means? It would seem so from all the noise.

To illustrate my point, here is a link to an unprofiled image - which happens to be from a digicam (some flavour of Sony Cybershot):

http://members.ozemail.com.au/~samarsh/DSC00046.JPG

It is a sad fact that consumer digicams often jpeg and do not tag files - all to save space. The lack of tag would not be a problem if the profile was supplied. As a pre press service provider - I have yet to see this happen.

Opening/assigning any available profile or workspace hack does not help the skin tone - the endpoints and neutrals are fine, it's just the skin tone which is bad.

Using Adobe RGB or variants with wider gamut or higher gamma made the skin tone really bad:

8c 61m 27y 1k for example, when converting to SWOP TR001 UCR.

Using ColorMatch RGB or lesser gamuts such as sRGB variants with wider gamut or lower gamma made the skin tone better, but _far_ from what is needed:

13c 49m 24y 1k for example, when converting to SWOP TR001 UCR.

The ColorMatch variations show better cyan (luminosity), while the ridiculously high magenta value has been decreased - but not enough. Sadly the yellow dropped a bit, rather than gaining as one would want (yellow needs to be much higher).

You could perform evaluations and conversions...even edits if you like with your monitor set to greyscale - in this case the preview does not matter.

As Dan, yourself and others correctly assert, the numbers have not changed - but the description of the RGB data has and so does the conversion to CMYK.

It is the files numbers when converted after profile assignment and editing which matter - as well as the description of what those numbers mean.

Beneficial results to the image which help further correction is what Dan is proposing - not the need to have monitor calibration and profiling (although this can't hurt, if you still remember that Photoshop has an info palette).

Andrew has a before/after image at his DigitalDog site of a Nikon D1 without/with custom profile which also demonstrates this point nicely (the point of a good RGB input description, so that the transform to output RGB/CMYK can take place as intended).

Now let's see what Dan has to say - this is just my take on his proposed method.

Interesting note: Dan has suggested this 'false profile' a while ago in a MakeReady article and in PP6 - where a 1.00 gamma is used to rescue a digicam image. No storm was raised then, and it's been over nine months...Dans progeny perhaps?

P.S. Congratulations on your achievement Dan!

Sincerely,

Stephen Marsh.

From: Chris Murphy,
Date: Wed, Sep 5, 2001, 1:17 PM
RE: Re: [colortheory] False gamma vs curves

Tara Marlowe (taramarlowe@hotmail.com) writes:
>So let's say I change the working space until I get something I like. At
>what point is the file actually changed to hold that definition. Am I
>fooling myself by just changing the preview or have I changed the definition
>of the image?

When you change the assigned profile for an image in Photoshop 6, you are changing the definition of the image - THEREFORE the preview will change also.

> I am confused when people say "you aren't changing the numbers,
>but what the numbers mean" what's the difference?

RGB numbers, like CMYK numbers, are almost meaningless. If I say 100% cyan, you have a general idea of what I mean by cyan, but if you print 100% cyan to three different devices - an inkjet print, a press, and a dye sublimation printer - you will get three very different results even thought you told each device to print the same values.

Go into an electronics store and check out the different television sets all tuned to the same channel. Each set is getting the exact same RGB values yet each TV looks a little different. The reason is because each TV set has unique behavior.

By changing an assigned profile for an image, you are telling Photoshop what those device values LOOK like to a human. Therefore it updates the display (the preview of the image), yet the values of the image stay the same.

>I don't mean to sound difficult but it usually isn't a matter of what I like
>in terms of color, it's matter of what the client has in mind. So with no
>hard copy to compare it to I am stuck trying to read minds.

You are still stuck trying to read minds. Profiles and color management don't give you or the computer ESP. All that it attempts to do is mitigate the different color behavior among your devices - scanners, monitors and printers.

However, if the client has a calibrated and profiled monitor -- and you both have a copy of the same image with an embedded profile in it, both of you will see the same thing. Then you are at least seeing the same thing when the client is talking about how "this area on the right side is too dark" or whatever.

>If we were going to be that loose on our definition of color then none of
>this would be necessary in the first place. I'm not comfortable with futzing
>around with profiles until the color "looks good" to me, since that isn't a
>very objective approach. I need a way to verify my decision was a good one
>according to the client.

That's what proofs are for. Color management/profiles can assist in helping you get what you see on your monitor printed on a low cost output device, so you can send it to the customer. You use intermin low cost proofs until the client is reasonably satistfied, then move to contract quality proofs for final approval. That way you use low cost proofs for multiple iterations with the client instead of having to pay and wait for contract proofs from an outside vendor.

>So I don't know if I change my working space if this changes the actual file
>or just the way it looks onscreen.

Be careful with terminology in Photoshop 6. Changing the working space does in Color Settings does *NOT* affect documents that have assigned or embedded profiles in them. It only affects newly created documents and documents that are untagged (marked as Do Not Color Manage This Document). The working space in Photoshop 6 is effectively a default and nothing more.

Assigning a profile affects how Photoshop interprets the RGB/CMYK values in the file, that is, what COLOR do those values look like to a human. So by itself, the act of assigning profiles or working spaces does nothing to the file per se (if you choose to embed the profile into the image, then it will get a little bigger, perhaps 10k or so).

Since the profile affects how Photoshop interprets the RGB/CMYK values in that image, it means the profile affects how it's previewed on screen, and any conversions you make with that file (converting it to CMYK for example).

>So is this just improving the preview or actually improving the image? When
>is the image changes vs. just the preview?

Yeah that's a good point because for a person using color management it does both. It both changes the preview and it improves the image because that profile will be used throughout the production process. However, for the non-color managed, they would ignore the embedded profile and would unknowingly be using something else as a default that wouldn't do as good of a job.

When does it actually modify the pixels in the image? When you convert. So if you assign a profile that makes the image look good, I would immediately use Convert To Profile to convert the image into ColorMatch RGB or Adobe RGB.

I don't have any statistical data to indicate what the most common default profile is used by people who are choosing to ignore this aspect of color management (the effect of the source profile when making separations) - otherwise I'd be able to tell you whether to use ColorMatch RGB or Adobe RGB. Right now it's a coin toss unless you know something about the Photoshop settings of the person who will be using your file.

>So I assume this means that if I open and untagged file and don't assign a
>profile that it will be in the working space only until I close the file.
>The next time that file is opened in will be moved (converted?) to whatever
>working space is on that machine and it'll just keep changing everytime it's
>opened?

Mostly correct. If an image file does not have a profile embedded in it, the profile that applies to the image when it is opened depends on the working space profile selected in that user's copy of Photoshop 6. The next time the file is opened it will be previewed BASED on that user's settings (specifically their working space), which could be different from user to user. It's not actually converted (the numbers haven't changed), but each person will be seeing the image differently because the source profile for that image is different at each workstation.

That's the problem with ignoring this issue, which so many people do, and they end up with substandard separations because of it. And the traditional way of fixing it is to proof the image as is, and then fix it with a round or two or three of CMYK color correction after the fact.

>I'm pretty sure I'm not the only one out there that
>feels like this.

You are in the overwhelming majority.

Chris Murphy
Color Remedies (tm)
Boulder, CO
303-415-9932

From: Andrew Rodney,
Date: Wed, Sep 5, 2001, 1:17 PM
RE: [colortheory] Re: Working file/Output file

on 9/5/01 10:35 AM, Tara Marlowe wrote:
> Does everyone keep a
> main file before converting to output space for archiving and further edits?

Absolutely positively yes!!!! Archive a file in your Working Space (or if you are really conservative like me, I archive the raw input data from camera or scanner tagged with the profile from the capture device and in 16 bits).

Andrew Rodney

From: Andrew Rodney,
Date: Wed, Sep 5, 2001, 2:05 PM
RE: Re: [colortheory] Re: More on profile assignments

on 9/5/01 10:51 AM, Stephen Marsh wrote:

> This list and Dan's suggestions are not about monitor previews, but about
> final image data.
> Has this list forgotten what by the numbers means? It would seem so from all
> the noise.

How do you evaluate what you are doing with a false profile without judging it on a calibrated display? The numbers do not change when you assign a false profile so I have to assume Dan and others are altering the working space to produce a visual appearance they want. Are you saying this is done without a calibrated and profiled display? No matter what you do, Photoshop 6 is looking for some kind of profile that describes the display to produce a preview. There is no way to turn this behavior off. So seems to me that it is logical to tell Photoshop 6 the display is at least in a condition that it really is.

> Opening/assigning any available profile or workspace hack does not help the
> skin tone - the endpoints and neutrals are fine, it's just the skin tone which
> is bad...

You1ve illustrated the weakness of this 3False Profile2 workflow for difficult to define images. You need a custom profile. Go to http://www.digitaldog.net/files/Skintone%20Raw%20vs.%20profile.jpg and examine this file. What you see is exactly the issue you describe with skin tone issues (in this case a Nikon D1). The two images have IDENTICAL numbers but one has been tagged with the correct description of the input data. Amazing difference. Notice like your example that the image tagged in ColorMatch isn1t too bad in many areas but awful in others. A custom profile (not a tweaked, False profile) is the key here.

> Beneficial results to the image which help further correction is what Dan is
> proposing - not the need to have monitor calibration and profiling (although
> this can't hurt, if you still remember that Photoshop has an info palette).

Once again, the numbers do not change so obviously looking at the info palette is no help. So how do you evaluate what you are doing with the false profile other than looking at the preview? How can you do this kind of work without having Photoshop 6 provide an accurate preview? What possible advantage would there be to doing any kind of visual work with a display that isn1t displaying accurately?

Andrew Rodney

From: Chris Murphy,
Date: Wed, Sep 5, 2001, 2:47 PM
RE: Re: [colortheory] Working file/Output file

Tara Marlowe (taramarlowe@hotmail.com) writes:
>One more question before I fade back into obscurity: Does everyone keep a
>main file before converting to output space for archiving and further edits?
>Or do you just convert it back to your working space if you need to edit it
>further or output to another device?

I never convert an image back. I either go back to the original and make the edit there, then reseparate the image. Or if it's just a subtle fix that's needed, I'll make the fix in CMYK and be done with it. It depends on the situation, but I don't convert them back into RGB just to make some edits.

Chris Murphy
Color Remedies (tm)
Boulder, CO
303-415-9932

From: William Alexander, walexander@leisurepublishing.com
Date: Wed, Sep 5, 2001, 2:52 PM
RE: [colortheory] Continued Profile education

ARGH!

From: Chris Murphy,
Date: Wed, Sep 5, 2001, 3:16 PM
RE: Re: [colortheory] Re: More on profile assignments

Stephen Marsh writes:
>This list and Dan's suggestions are not about monitor previews, but about
>final image data.
>Has this list forgotten what by the numbers means? It would seem so from
>all the noise.

The source profile used affects both the preview and the separation. You don't get one without the other. If you are completely unconcerned with monitor previews, that's fine but the source profile used is still critical for getting a good separation. And the reason why people are saying the "image looks bad" is not because the data in the file is wrong, but because the source profile is wrong.

I think everyone knows what by the numbers means. When it's possible for the same RGB numbers to turn into completely different CMYK numbers due to a difference in the profile assigned to the RGB original, that tells me that by the numbers is partially a facade. It's wishful thinking to assume that a by the numbers approach will get you what you want regardless of the devices being used. A combination of both methods should be employed.

>It is a sad fact that consumer digicams often jpeg and do not tag files - >all to save space. The lack of tag would not be a problem if the profile >was supplied. As a pre press service provider - I have yet to see this >happen.

A consumer digital camera isn't considerd high end enough to be worth the fuss by the vendor. They think the target market buys the camera and is happy with the built in color management going on in the camera that the end user doesn't have to futz with at all. And if they print to an inkjet printer and get what they want, who cares about anything else because that's what most consumers do. They stick them on a web page and maybe print them to a printer and that's it.

>Higher end cameras come with profiles, and some of come with usable profiles
>Opening/assigning any available profile or workspace hack does not help
>the skin tone - the endpoints and neutrals are fine, it's just the skin
>tone which is bad.

These issues might be solved with a profile for the camera. What you're doing is trading one set of problems for another. You are trading the problem of having to correct every single image with a skin tone for producing a profile that will hopefully avoid the problem at least some of the time. If it solves the bulk of the problem for a few images but no others, is it still worth it?

Camera profiles are different from the RGB profiles you can make using Dan's method with Photoshop. The Photoshop made profiles are referred to as matrix-based profiles. They don't have much data in them at all in order to deal with selective color issues - for example in the case where everything looks great but skin tones are wrong. A camera profile (scanner profiles too) are table-based profiles. They contain quite a bit more information in them and can deal with selective color issues.

>It is the files numbers when converted after profile assignment and
>editing which matter - as well as the description of what those numbers mean.

Yes absolutely.

>Beneficial results to the image which help further correction is what Dan
>is proposing - not the need to have monitor calibration and profiling
>(although this can't hurt, if you still remember that Photoshop has an
>info palette).

I never said Dan was proposing either of things. All I'm trying to clarify are basically two apparent misconceptions:

a.) That Dan's technique is something new, and using color management for something it wasn't designed to do - color correction. That's false. Setting the source profile correctly in the first place is what color management has always been about and his technique allows users to do this when a device profile isn't availble.

b.) That "false profile" is a good term that should be used. It's a misplaced term because it's being used to describe a profile that is actually LESS-FALSE than the one that preceded it, making the image "look bad" to begin with.

>Interesting note: Dan has suggested this 'false profile' a while ago in a
>MakeReady article and in PP6 - where a 1.00 gamma is used to rescue a
>digicam image. No storm was raised then, and it's been over nine
>months...Dans progeny perhaps?

Speaking only for myself, if I'd heard the term "false profile" used in this manner, and people thinking that this is using color management for a purpose it wasn't originally designed, I would have had the same problem with it then as I do now.

Chris Murphy
Color Remedies (tm)
Boulder, CO
303-415-9932

From: "Michael Demyan", mdhealth@enter.net
Date: Thu, Sep 6, 2001, 1:40 AM
RE: [colortheory] More on profile assignments (a 'false profile')

Stephen Marsh writes:
"To illustrate my point, here is a link to an unprofiled image - which happens to be from a digicam (some flavour of Sony Cybershot):

http://members.ozemail.com.au/~samarsh/DSC00046.JPG

It is a sad fact that consumer digicams often jpeg and do not tag files - all to save space. The lack of tag would not be a problem if the profile was supplied. As a pre press service provider - I have yet to see this happen.

Opening/assigning any available profile or workspace hack does not help the skin tone - the endpoints and neutrals are fine, it's just the skin tone which is bad."

==========================================================================
I forgot Attachments are not forwarded to the group mail.

Here is a copy of the above image file with an attached 'false profile' I created called "Digital Flesh".
http://www.upbeat.com/pc-setup/Color/false_profile.html
It will only work on the flesh part of the image. It would wack the balance of the image 'orange'.

Mike Demyan
Digital Graphic Design
www.upbeat.com/pc-setup
mdemyan@ptd.net

From: "Michael Demyan", mdhealth@enter.net
Date: Thu, Sep 6, 2001, 1:24 AM
RE: [colortheory] More on profile assignments (a 'false profile')

Stephen Marsh writes:

"To illustrate my point, here is a link to an unprofiled image - which happens to be from a digicam (some flavour of Sony Cybershot):

http://members.ozemail.com.au/~samarsh/DSC00046.JPG

It is a sad fact that consumer digicams often jpeg and do not tag files - all to save space. The lack of tag would not be a problem if the profile was supplied. As a pre press service provider - I have yet to see this happen.

Opening/assigning any available profile or workspace hack does not help the skin tone - the endpoints and neutrals are fine, it's just the skin tone which is bad."

==========================================================================
Attached is a copy of the above image file with an attached 'false profile' I created called "Digital Flesh".

It will only work on the flesh part of the image. It would wack the balance of the image 'orange'.

Mike Demyan
Digital Graphic Design
www.upbeat.com/pc-setup
mdemyan@ptd.net

From: Stephen Marsh, Stephen Marsh
Date: Thu, Sep 6, 2001, 7:39 AM
RE: [colortheory] Re: More on profile assignments

--- In colortheory@y..., Andrew Rodney wrote:

> How do you evaluate what you are doing with a false profile without judging
> it on a calibrated display? The numbers do not change when you assign a
> false profile so I have to assume Dan and others are altering the working
> space to produce a visual appearance they want. Are you saying this is done
> without a calibrated and profiled display? No matter what you do, Photoshop
> 6 is looking for some kind of profile that describes the display to produce
> a preview. There is no way to turn this behaviour off. So seems to me that it
> is logical to tell Photoshop 6 the display is at least in a condition that
> it really is.
>

I agree that the RGB numbers in the file do not change (the list has established and agrees that only the description of these numbers change).

I like many on this list originally purchased Dan's book because of the deep CMYK editing and other colour mode editing techniques - among other things. Like many of Dan's intended audience - I am into print, with other colour modes being a lesser concern.

It is important to understand how RGB relates to the final CMYK conversion - but for me, the final CMYK file is the most important thing.

For RGB, I would gladly accept a correct tag or supplied separate profile - but this is rare in my work.

So in a pre press role - if I face a RGB image which can have any profile applied which makes the final conversion better, then I am all for it.

For the record, I am using this 'false RGB setup' in Photoshop 5 - which should not make a difference. In APS6 a untagged file will display in the RGB work space, just as in APS5.x. Andrew, I am sure you know that final CMYK values have traditionally concerned pre press and print.

This is how I use the false RGB workspace hack. An untagged file is opened and with no conversion and the workspace is changed until fixed samplers and live mouseovers report via the info palette that the selected RGB workspace will convert to CMYK with better values.

When a good RGB workspace is found - then RGB edits are made before CMYK conversion and final CMYK edits.

In my original post, choosing or assigning AdobeRGB to this image will make the too red skin tone very red in CMYK - if no further edits are taken. Magenta would be 61 which is too high for this particular skin tone. Even the ColorMatch value of 49 magenta
is high - but the cyan has increased from 8 to 13 which is a good thing. Sadly the yellow is far from ideal in either colour space.

Yes an Adobe Gamma or hardware/software generated profile would help. But I am concerned with how the image will convert to CMYK at the end of the day - and from the initial moment the RGB file is opened all moves take this final CMYK output into consideration.

My point is that with info palette settings set to display in CMYK - the monitor display is a secondary factor in using this workspace/profile hack technique.

> > Opening/assigning any available profile or workspace hack does not help the

> You?ve illustrated the weakness of this False Profile? workflow for
> difficult to define images. You need a custom profile. Go to
> http://www.digitaldog.net/files/Skintone%20Raw%20vs.%20profile.jpg and
> examine this file. What you see is exactly the issue you describe with skin
> tone issues (in this case a Nikon D1). The two images have IDENTICAL numbers
> but one has been tagged with the correct description of the input data.
> Amazing difference. Notice like your example that the image tagged in
> ColorMatch isn?t too bad in many areas but awful in others. A custom profile
> (not a tweaked, False profile) is the key here.
>

Yes, I agree. Without custom profile editing gear and knowledge - the profile hack can be limiting, depending on the image in question.

I am aware of the D1 image - after all I did refer to this in my original post.

In my pre press role my client supplies me an image. It may not have a tag or profile supplied - or any description in file/info or on paper.

It is not possible to create a custom profile for this particular hardware and capture condition.

All I have is the basic tools of APS5 and ver6 (installing tomorrow).

Although not perfect - the profile hack and by the numbers evaluation can work, at least so know more than 'the image looks a bit pink'...since the info palette set to CMYK display will show that the numbers are too pink.

> > Beneficial results to the image which help further correction is what Dan is
> > proposing - not the need to have monitor calibration and profiling (although
> > this can't hurt, if you still remember that Photoshop has an info palette).
>
> Once again, the numbers do not change so obviously looking at the info
> palette is no help. So how do you evaluate what you are doing with the false
> profile other than looking at the preview? How can you do this kind of work
> without having Photoshop 6 provide an accurate preview? What possible
> advantage would there be to doing any kind of visual work with a display
> that isn?t displaying accurately?
>

As outlined above - evaluations could be visual, but it is how the RGB numbers translate into CMYK that matters. The rest is icing on the cake.

Sincerely,

Stephen Marsh.

From: Stephen Marsh, Stephen Marsh
Date: Thu, Sep 6, 2001, 8:09 AM
RE: [colortheory] Re: More on profile assignments

--- In colortheory@y..., Chris Murphywrote:

> The source profile used affects both the preview and the separation. You
> don't get one without the other. If you are completely unconcerned with
> monitor previews, that's fine but the source profile used is still
> critical for getting a good separation. And the reason why people are
> saying the "image looks bad" is not because the data in the file is
> wrong, but because the source profile is wrong.
>
Chris, in broad terms I totally agree. You seem to understand my viewpoint on making informed decisions on RGB source images/profiles/workspaces via CMYK readouts - before conversion.

In the example originally posted - even my Adobe Gamma 'profiled' monitor shows the image as too pink. Having a better preview would be nice, but to me knowing that the skintone has values of 8c 61m 27y 1k in Adobe RGB variants and 13c 49m 24y 1k in ColorMatch RGB variants is more important.

> These issues might be solved with a profile for the camera. What you're
> doing is trading one set of problems for another. You are trading the
> problem of having to correct every single image with a skin tone for
> producing a profile that will hopefully avoid the problem at least some
> of the time. If it solves the bulk of the problem for a few images but no
> others, is it still worth it?

> Camera profiles are different from the RGB profiles you can make using
> Dan's method with Photoshop. The Photoshop made profiles are referred to
> as matrix-based profiles. They don't have much data in them at all in
> order to deal with selective color issues - for example in the case where
> everything looks great but skin tones are wrong. A camera profile
> (scanner profiles too) are table-based profiles. They contain quite a bit
> more information in them and can deal with selective color issues.

I agree - but in my role as a pre press operator for a printer, each job is one pitfall after another. You have no real control over the data presented to you. This is really an issue for the originator of the image - not the person at the end of the line. But this is not how the real world works. In a service role - you just have to deal with it.

> >Beneficial results to the image which help further correction is what Dan
> >is proposing - not the need to have monitor calibration and profiling
> >(although this can't hurt, if you still remember that Photoshop has an
> >info palette).

> I never said Dan was proposing either of things. All I'm trying to
> clarify are basically two apparent misconceptions:

> a.) That Dan's technique is something new, and using color management for
> something it wasn't designed to do - color correction. That's false.
> Setting the source profile correctly in the first place is what color
> management has always been about and his technique allows users to do
> this when a device profile isn't availble.

> b.) That "false profile" is a good term that should be used. It's a
> misplaced term because it's being used to describe a profile that is
> actually LESS-FALSE than the one that preceded it, making the image "look
> bad" to begin with.

I agree with these comments.

The point I was attempting to make (and failed poorly) - is that you do not _need_ a hardware profiled monitor for this to work. Yes it helps, and if I had the option I would take it (and remember it's limitations). The info palette in Photoshop can help a user who intends to take an image from RGB to CMYK - with or without a hardware/software monitor profile.

Since I have the choice of using by the numbers methods and Adobe Gamma - or only Adobe Gamma, knowing the final CMYK values wins every time, with the preview an important subject - but secondary to the conversion.

I hope this clarifies my post.

Regards,

Stephen Marsh.

From: Dan Margulis, 76270.1033@compuserve.com
Date: Thu, Sep 6, 2001, 9:20 AM
RE: [colortheory] Re: More on profile assignments

Stephen writes,
>>As previously noted, users like myself are fairly comfortable making a 'false separation' but it has only been since version 5 that most users have been able to play with a 'workspace hack' or whatever term finally makes all parties happy.>>

No, it's always been possible to go into Monitor Setup and do this from at least PS 3.0 on. However, in versions 3.x-5.x it involved making a change to the RGB setup (or whatever the equivalent term was in the specific version) that was good until cancelled. That was highly dangerous. The first time you applied a false profile and forgot to change the RGB setup afterwards would likely be the last time you ever tried such a workflow. The beauty of Photoshop 6 is this Assign Profile command, which is a one-shot deal that won't affect other pictures.

>>Beneficial results to the image which help further correction is what Dan is proposing - not the need to have monitor calibration and profiling (although this can't hurt, if you still remember that Photoshop has an info palette).>>

Correct. Of all the steps in the process, this is the one where a calibrated monitor is least helpful. Use of a false profile implies something grossly wrong with the original.

>>Interesting note: Dan has suggested this 'false profile' a while ago in a MakeReady article and in PP6 - where a 1.00 gamma is used to rescue a digicam image. No storm was raised then, and it's been over nine months...Dans progeny perhaps?>>

Well, this was a long gestation. The first mention of it was in my August 2000 column, as you say, and I used the same image in Professional Photoshop 6. However, I did say in that same book that I realized shortly before printing that I had screwed it up, and there was a better way to do things that I would reveal in PP7. This was a reference to my inability to grasp that in addition to making a new profile with a 1.00 gamma, I should also have changed the primaries to make the image more colorful.

Since that time, I've realized that this trick is not just a desperation measure to save otherwise impossible images. Images from my camera open best in Apple RGB or perhaps ColorMatch RGB. If the image is so disastrously dark that I have to use 1.0 gamma to save it, I don't at present know any alternate way of doing this. OTOH, if the image is a bit washed out and colorless, I can certainly get what I want with curves. But assigning an Adobe RGB profile seems to make the process less painful, and only takes a second.

I assume that further ideas will suggest themselves as the child grows up.

Dan Margulis

From: Terry Wyse, terry@allsystems.com
Date: Thu, Sep 6, 2001, 6:50 PM
RE: Re: [colortheory] Working file/Output file

on 9/5/01 4:35 PM, Tara Marlowe wrote:
> One more question before I fade back into obscurity: Does everyone keep a
> main file before converting to output space for archiving and further edits?
> Or do you just convert it back to your working space if you need to edit it
> further or output to another device?

Converting back from CMYK to RGB is generally a bad thing since, well, you really can't get there (RGB) from here (CMYK)! If you have the ability to see a color gamut chart of AdobeRGB compared to your CMYK working space you'll see why. The CMYK area that overlaps your RGB WS is all you'll get, the rest outside the CMYK profile is gone.

Terry

From: "mact", mact@adcomgraphics.net
Date: Thu, Sep 6, 2001, 10:52 AM
RE: [colortheory] bad pi

xa few issues ago, Dan described what he went through to revive a poorly exposed shot of a friend at _Electronic Publishing_ who had passed on.
I am wondering if the "false profile" approach might have made this easier to accomplish.

Mac Townsend,
Adcom Graphics, Fairfield, CA:
Electronic Prepress
www.adcomgraphics.net

From: Dan Margulis, 76270.1033@compuserve.com
Date: Thu, Sep 6, 2001, 7:53 PM
RE: [colortheory] bad pi

xMac writes,
>>a few issues ago, Dan described what he went through to revive a poorly exposed shot of a friend at _Electronic Publishing_ who had passed on. I am wondering if the "false profile" approach might have made this easier to accomplish.>>

That image was the father of all false profiles. I indeed used the approach in that article, but limited myself to changing the gamma setting. (This was done in Photoshop 5, so the Assign Profile command wasn't available.) I should have also changed the RGB primaries so that the picture would have gotten more colorful as well, but I wasn't that smart then.

That image (called "Presentation") is part of the exercises in my advanced course. I've therefore seen over 50 takes at it by some very good people. Without the initial false profile, nobody has yet gotten close.

Dan Margulis

From: "Brad Perkinson", BDP2@mousegraphics.com
Date: Thu, Sep 6, 2001, 9:10 PM
RE: Re: [colortheory] Working file/Output file

>Converting back from CMYK to RGB is generally a bad thing since, well, you
>really can't get there (RGB) from here (CMYK)! If you have the ability to
>see a color gamut chart of AdobeRGB compared to your CMYK working space
>you'll see why. The CMYK area that overlaps your RGB WS is all you'll get,
>the rest outside the CMYK profile is gone.
I agree with the conclusion but I disagree slightly with the explanation or maybe just with the grammar. The bad thing is actually the original RGB to CMYK conversion, so it is more like you can't get back here (RGB) once you have been there (CMYK). The distinction is important (at least to me) because we regularly have clients who have CMYK files but don't think they can use them for RGB output, not realizing that going from a smaller to a (mostly) larger color gamut works just fine.

Brad
--
Brad Perkinson
Mousegraphics
1414 W 14th St
Tempe, AZ 85281
480-894-1992
brad@mousegraphics.com

From: Andrew Rodney,
Date: Thu, Sep 6, 2001, 9:29 PM
RE: Re: [colortheory] Working file/Output file

on 9/6/01 7:05 PM, Brad Perkinson wrote:
> The distinction is important (at least to me)
> because we regularly have clients who have CMYK files but don't think they
> can use them for RGB ouput, not realizing that going from a smaller to a
> (mostly) larger color gamut works just fine.

There certainly is nothing that stops someone from taking a CMYK file, converting to RGB and making some kind of RGB output. And it probably does look pretty good. But I1d bet dollars to donuts that IF that user had the original RGB file and output both the RGB original and the RGB converted from CMYK file, they would far prefer the output from the original RGB IF (not that big an if) the file in question had some fairly saturated colors. A shot of a black cat on coal isn1t going to suffer (unless the black itself gets hosed in the conversion process). For fun, take a spectral gradient (admittedly on the other end of the saturated scale) and output an RGB file and an RGB from CMYK file and see just how much saturation gets lost in the process. If no RGB original exists (a shame since the file originally was RGB), then doing a CMYK to RGB conversion is really the only option.

Andrew Rodney

From: "Tara Marlowe", taramarlowe@hotmail.com
Date: Thu, Sep 6, 2001, 9:36 PM
RE: Re: [colortheory] Re: More on profile assignments

Andrew Rodney wrote:
Go to
> http://www.digitaldog.net/files/Skintone%20Raw%20vs.%20profile.jpg and
> examine this file. What you see is exactly the issue you describe with
skin

While I would agree that the skin tones look more normal in the profiled image, I think other parts of the image have suffered. The profiled image has posterization under the eyes and on the shadows of the hair. And it has lost a lot of the detail and highlights in the hair. Any idea why this is so? Tara

From: Andrew Rodney,
Date: Thu, Sep 6, 2001, 10:04 PM
RE: Re: [colortheory] Re: More on profile assignments

on 9/6/01 7:35 PM, Tara Marlowe at wrote:
> While I would a gree that the skin tones look more normal in the profiled
> image, I think other parts of the image have suffered. The profiled image
> has posterization under the eyes and on the shadows of the hair. And it has
> lost a lot of the detail and highlights in the hair. Any idea why this is
> so? Tara

Well I1m not seeing that on my browser. The file is also pretty heavily JPEGed. The image should have an embedded profile so if you are running Microsoft1s IE 5.0 on the Mac and you have your preferences set for ColorSync, you1ll get a Display Using Monitor Compensation type of behavior in your browser (doesn1t work at all on the PC version of IE). That might help.

Andrew Rodney

From: Dave Badger, dbadge@worldnet.att.net
Date: Fri, Sep 7, 2001, 8:02 AM
RE: Re: [colortheory] False gamma vs curves

on 9/5/01 12:23 PM, Andrew Rodney wrote:
> IF you and your client both have a profile of your respective displays (one
> that is accurate of course), then when you open the file that is tagged, you
> both see the same preview! That is a net gain that we got with Photoshop 5
> when we separated the way we edit our files (the Working Space) from our
> displays. You are not reading minds. You have a consistent line in the sand
> in which to view the files. And the file has a meaning both users (or both
> copies of Photoshop 6) understand. Without a profile, that isn't the case at
> all.

What about in an all CMYK workflow. I get a lot of files tagged with SWOP Coated v2. So this means in PS6 I'm seeing the same preview as the client who sent it in. But if I output it to my IRIS or Matchprint, it looks different then the screen preview. If I preserve this embedded profile and do corrections, they are unpredictable when output to my IRIS. Should I convert to "MyCMYKProfile" or just assign "MYCMYKProfile" to get the preview and output to match?

Dave Badger

From: Chris Murphy,
Date: Fri, Sep 7, 2001, 8:25 AM
RE: Re: [colortheory] False gamma vs curves

Dave Badger writes:
>What about in an all CMYK workflow. I get a lot of files tagged with SWOP
>Coated v2. So this means in PS6 I'm seeing the same preview as the client
>who sent it in.

IF the monitors on both ends are calibrated and profiled - and the profile isn't being ignored (in favor of the CMYK working space), then YES. In order to get the ignored (and favor of the CMYK working space), your color management policies would need to be set to OFF. So OFF, in this case, could prevent preview similarity between the two locations.

> But if I output it to my IRIS or Matchprint, it looks
>different then the screen preview.

That means the separation isn't ideal for the particular IRIS or Matchprint. If the separation is correct for your particular IRIS or Matchprint process, then you will get a good screen to proof match. It won't be perfect, but neither is the "match" between contract proof and press sheet - you learn how to read them.

NOTE that there is more than one kind of Matchprint. There are something like four or five bases and at least four laminates (ink sets and dot gain simulation). Last I checked there around 30 different combinations of these, but all were called Matchprint.

> If I preserve this embedded profile and
>do corrections, they are unpredictable when output to my IRIS. Should I
>convert to "MyCMYKProfile" or just assign "MYCMYKProfile" to get the preview
>and output to match?

Option A:
1. Set your working space to "MyCMYKProfile".

2. Set Photoshop to Preserve Embedded Profile, and check the "Profile Mismatches, Ask When Opening" checkbox.

Each time you open an image with a profile other than yours embedded in it, you can select the middle option in the dialog that will appear: "Convert document's colors to the working space."

This will effectively reseparate the image for YOUR specific output method. It will preserve color appearance by changing the document's CMYK values based on your device's output behavior.

Option B:
Set everything per above, and you'll get the mismatch warning telling you the profiles aren't the same. Click either the first or third options (preserve embedded, or discard embedded) it won't matter because you are going to reassign the profile anyway.

Once you assign "MyCMYKProfile" the color of the image will visibly change on screen while leaving the values intact. It will preserve document CMYK values, therefore color appearance will change to show you how those values will output on YOUR devices.

You can now either output and be happy with a screen to print match, even though it's not what the customer was expecting, or you can manually color correct the image, or you could just go with option A above.

Chris Murphy
Color Remedies (tm)
Boulder, CO
303-415-9932

From: Terry Wyse, terry@allsystems.com
Date: Fri, Sep 7, 2001, 9:11 AM
RE: Re: [colortheory] Working file/Output file

on 9/7/01 1:05 AM, Brad Perkinson (and others) wrote:
>>> One more question before I fade back into obscurity: Does everyone keep a
>>> main file before converting to output space for archiving and further edits?
>>> Or do you just convert it back to your working space if you need to edit it
>>> further or output to another device?
>

My response was based primarily on the original statement "if you need to edit it further...". This is where it would be a bad thing. You should instead go back to the original RGB, make your edits and re-separate.

Having said that, sure, if you need an RGB version for output then "un-separating" the image back to RGB would be perfectly acceptable. In fact, it's likely to be a better match to the CMYK output since most, if not all, the colors will fall within the gamut of the RGB device. A straight RelCol conversion from CMYK back to "output device RGB" would do the trick.

TerryFrom: William Alexander, walexander@leisurepublishing.com
Date: Fri, Sep 7, 2001, 9:33 AM
RE: [colortheory] Easy profile question

1 quick easy no need for a long thread profile question: If I get an RGB image with no profile embedded and am outputting in CMYK, should I assign my working profile, leave it without a profile, or does it not matter either way?
William in Roanoke

From: William Alexander, walexander@leisurepublishing.com
Date: Fri, Sep 7, 2001, 10:23 AM
RE: Re: [colortheory] Easy profile question

AND also I get a CMYK drumscanned image with no profile. Do I simply apply
my CMYK profile to it? Or leave it with no profile and convert it to my
profile before checking out the color?

From: Bob Smith, rmsmith@calpha.com
Date: Fri, Sep 7, 2001, 10:29 AM
RE: Re: [colortheory] Easy profile question

William Alexander wrote:
> If I get an RGB image with no profile embedded and am outputting in CMYK,
> should I assign my working profile, leave it without a profile, or does it
> not matter either way?

the short answer: Assign whatever RGB tag makes it look the best and/or gives CMYK info palette numbers that you like. Yes it does make a difference. The description that the file is tagged with affects how it transforms to CMYK.

Bob Smith

From: Andrew Rodney,
Date: Fri, Sep 7, 2001, 10:32 AM
RE: Re: [colortheory] False gamma vs curves

on 9/7/01 6:02 AM, Dave Badger wrote:

> I get a lot of files tagged with SWOP
> Coated v2. So this means in PS6 I'm seeing the same preview as the client
> who sent it in. But if I output it to my IRIS or Matchprint, it looks
> different then the screen preview.

Because the IRIS isn't behaving the same as the SWOP process the file was originally converted to (what makes you think it would). You need a profile for the Iris so you can get it to cross simulate the SWOP process (you do a CMYK to CMYK conversion).

> Should I
> convert to "MyCMYKProfile" or just assign "MYCMYKProfile" to get the preview
> and output to match?

Convert.

Andrew Rodney

From: Chris Murphy,
Date: Fri, Sep 7, 2001, 10:35 AM
RE: Re: [colortheory] Easy profile question

William Alexander writes:
>If I get a an RGB image with no profile embedded and am outputting in CMYK,
>should I assign my working profile, leave it without a profile, or does it
>not matter either way?

Oh it matters - in the sense that it affects the resulting CMYK values you get.

a.) Use Assign Profile to cycle through various profiles and find one that gives you the predicted CMYK values in the info palette you want with a conversion; then convert to CMYK.

b.) Calibrate and profile the monitor, and use assign profile to cycle through the various profiles until you see a preview that looks like what you want (be it something you just like better, or what the customer wants, or closest to the original); then convert to CMYK.

Chris Murphy
Color Remedies (tm)
Boulder, CO
303-415-9932

From: Andrew Rodney,
Date: Fri, Sep 7, 2001, 10:36 AM
RE: Re: [colortheory] Easy profile question
on 9/7/01 7:33 AM, William Alexander at wrote:

> 1 quick easy no need for a long thread profile question:
> If I get an RGB image with no profile embedded and am outputting in CMYK,
> should I assign my working profile, leave it without a profile, or does it
> not matter either way?

Assign a profile that produces the best preview on your calibrated display, then convert to CMYK.
Andrew Rodney

From: Andrew Rodney,
Date: Fri, Sep 7, 2001, 10:38 AM
RE: Re: [colortheory] Easy profile question

on 9/7/01 8:16 AM, William Alexander wrote:

> AND also I get a CMYK drumscanned image with no profile. Do I simply apply
> my CMYK profile to it? Or leave it with no profile and convert it to my
> profile before checking out the color?

Yes, you should assign your output profile to this untagged file which will update the preview and show you how this CMYK file will look to your output device. Another beauty of a profiled system. The untagged CMYK file will use whatever CMYK setting you have in your color preferences for a preview (you can load your output profile there). So now you can see what the numbers created from this drum scanner (optimized for god knows what CMYK process) will look like on YOUR CMYK process.

You shouldn1t have to do a conversion. If the image looks really bad with your output profile assigned, I1d ask why on earth you are getting these CMYK numbers in the first place that would produce such poor output. If your back were up to a wall, you still can1t convert to your space because you don1t know where the file came from (it1s untagged). So you have to play the guessing game and assign all kinds of CMYK profiles to update the preview and then run through your CMYK output profile. Not a pretty picture.

Andrew Rodney

From: Chris Murphy,
Date: Fri, Sep 7, 2001, 10:42 AM
RE: Re: [colortheory] Easy profile question

William Alexander (walexander@leisurepublishing.com) writes:

>AND also I get a CMYK drumscanned image with no profile.

Ask the scanner operating to what device the CMYK drumscan is meant for. Then use a profile for that. If they are separating for commecial coated, use that profile. If it's for SWOP use that profile. Assign it, then use Convert To Profile to effectively reseparate the image.

> Or leave it with no profile and convert it to my
>profile before checking out the color?

Keep in mind there is no such thing as no profile. Even with "no profile" the working space profile is what applies to such an image.

Chris Murphy
Color Remedies (tm)
Boulder, CO
303-415-9932

From: Chris Murphy,
Date: Fri, Sep 7, 2001, 10:47 AM
RE: Re: [colortheory] Re: More on profile assignments

Tara Marlowe (taramarlowe@hotmail.com) writes:
>While I would agree that the skin tones look more normal in the profiled
>image, I think other parts of the image have suffered. The profiled image
>has posterization under the eyes and on the shadows of the hair. And it has
>lost a lot of the detail and highlights in the hair. Any idea why this is
>so?

I personally don't expect an input profile to do a perfect job. I expect it to help me avoid having to correct for device specific peculiarities like hue casts - or a situation where everything looks pretty good except for skin tones.

Once the profile solves the bulk of these issues, I still expect to set a whitepoint and blackpoint for the image. I don't expect a profile to do this for me. I prefer an input profile that results in a flat converted image (low contrast). That way I'm sure the profile itself has not clipped highlights and shadows. I want to set those myself.

I assign the input profile, convert to working space RGB (Adobe RGB in my case), and go to levels to set white, black, and the midtone. From there I generally only need to make minor tweaks in RGB before converting to CMYK.

So I spend 10 seconds to assign and convert instead of a few minutes (sometimes more depending on the whackiness of the input device) per image solving what aren't real color problems, but rather device peculiarities. I still have to color correct the image - profiles don't do that part.

Chris Murphy
Color Remedies (tm)
Boulder, CO
303-415-9932

From: Terry Wyse, terry@allsystems.com
Date: Fri, Sep 7, 2001, 11:24 AM
RE: Re: [colortheory] Easy profile question

on 9/7/01 1:33 PM, William Alexander wrote:

> 1 quick easy no need for a long thread profile question:

OK, I'll bite! Seems we just went through this on another list and it opened a huge, steaming can of worms!

> If I get a an RGB image with no profile embedded and am outputting in CMYK,
> should I assign my working profile, leave it without a profile, or does it
> not matter either way?

It *absolutely* matters since the RGB profile you assign will directly
affect the resulting CMYK separation.

First off, what I'm about to suggest ASSUMES you're using a calibrated and profiled display. If this is not the case, then all bets are off.

The answer is "yes" you should assign a profile but not necessarily you're RGB working space profile, you need to find out what the customer was using to get the results they were/are expecting.

Quite simply, I would start by *assigning* different RGB working spaces and simply pick the one that looks correct (Mode: Assign Profile w/ preview on). I would say in probably 80%-90% of the cases, it's going to be one of these three:
* sRGB
* ColorMatchRGB
* AdobeRGB
so I would probably start with these three before moving on to less common RGB working space profiles.

Some of the things to look for when trying these different profiles would be:
* Overall lightness/darkness. For example, ColorMatchRGB with it's 1.8 GAMMA will look significiantly lighter than either sRGB or AdobeRGB (GAMMA 2.2). Try to ignore colors for the most part when evaluating GAMMA. Looking for gradated neutrals will give you a better idea. Switching between sRGB and ColormatchRGB should nail down the correct GAMMA.
* Saturation. If you think you've got the correct GAMMA setting,start looking at saturated colors in the image that contain some detail and compare the profiles. Example, AdobeRGB will appear much more saturated than the other two which at first *may* look better but take a close look at the detail. If you get absolutely *screaming* greens and reds which lack detail, then AdobeRGB is probably incorrect.

If none of these 3 profiles I mentioned give you the look you're after, then start checking out some of the other RB working space profiles.

Hope this helps,

Terry Wyse

From: Terry Wyse, terry@allsystems.com
Date: Fri, Sep 7, 2001, 12:09 PM
RE: Re: [colortheory] Easy profile question

on 9/7/01 11:09 AM, Terry Wyse wrote:
> OK, I'll bite! Seems we just went through this on another list and it opened
> a huge, steaming can of worms!

Oops. This WAS the list where the can was opened! I thought I was replying to a different list. No offence intended...

Terry

From: Terry Wyse, terry@allsystems.com
Date: Fri, Sep 7, 2001, 11:27 AM
RE: Re: [colortheory] Easy profile question

on 9/7/01 2:16 PM, William Alexander wrote:
> AND also I get a CMYK drumscanned image with no profile. Do I simply apply
> my CMYK profile to it?

Yes, assign your CMYK working space and you will get a correct preview of what it will proof/print like at your shop.

> Or leave it with no profile and convert it to my
> profile before checking out the color?

Well, if you leave it with NO profile, you're CMYK working space will be *assumed* as far as the preview goes. If you could care less about your display preview, then do nothing. HOWEVER if you are going to perform some kind of profile CONVERSION (as opposed to simply ASSIGnING a profile) then you MUST determine/assign a correct source profile.

Terry

From: Chris Murphy,
Date: Fri, Sep 7, 2001, 5:04 PM
RE: RE: [colortheory] Easy profile question

Ray Landis (ray.landis@techbooks.com) writes:
>Without the profile being embedded it doesn't remain with the file.
> Doesn't this only apply to the viewed image?

In Photoshop, some profile ALWAYS applies to a document. Either it's explicitly assigned, or one is assumed based on Color Settings. This profile will affect how the image is viewed AND it will affect how the image is converted.

If you don't convert an image in Photoshop, then a profile (assigned or not) affects the preview of the image (and info palette numbers if they are not of the same mode as the image; that is both RGB and CMYK profiles affect the CMYK info palette numbers for an RGB image.)

> If we print the file from
>say Quark we would not have the profile with the file.

Working space is a concept that applies to Photoshop. QuarkXPress has it's own rules of madness and it depends on the version, but for the most part if you print an image with or without a profile in it, QuarkXpress will print the image the same if the following are true:

1.) If color management is all turned off (if it's on, it still might not convert images, it depends on the settings)

2.) If the images are CMYK and the intended output device is CMYK (implies PostScript; non-PostScript is almost always considered RGB).

3.) If the images are RGB and the version of QuarkXPress is not between 4.0 and 4.04; if you have a version between 4.0 and 4.04, you must have PrintRGB XT or QuarkXPress will convert RGB images to CMYK whether you like it or not and they aren't particularly good conversions.

Chris Murphy
Color Remedies (tm)
Boulder, CO
303-415-9932

From: Dan Margulis, 76270.1033@compuserve.com
Date: Sat, Sep 8, 2001, 8:26 AM
RE: Re: [colortheory] Easy profile question

William writes,
>>AND also I get a CMYK drumscanned image with no profile. Do I simply apply my CMYK profile to it? Or leave it with no profile and convert it to my profile before checking out the color?>>

I have been trying to stay out of this thread but it is just getting too theatre-of-the-absurd.

If you get a CMYK image that has no profile (which will be most of the time), the correct procedure is,

1. Open the image,
2. Correct as seems necessary,
3. Save the image.

IOW, do exactly what you would have done in that part of your life which was happier because you had never heard of profiles and the color management thought police.

If you get an RGB file that has no profile (which will be a large percentage of the time) then you do exactly the same thing, unless you open it and decide that it looks considerably too dark/too light/not colorful enough. In that case

The reason one might assign an arbitrary profile in RGB and not in CMYK is that there is no extra conversion involved. If your normal RGB is Monitor RGB, but you decide to assign Adobe RGB to it for this one image, you still have to convert it to CMYK one time, same as if you hadn't. If you assign a CMYK profile and convert it to some new kind of CMYK, that's an unnecessary conversion. Fixing it with curves is better.

I assume from all that you have posted here that you are by this time completely confused and frustrated by all this politically correct stuff and are probably longing for the day that you had never heard of any of it. To which I would remind you of what I said at the outset: what is it about your current workflow that is so bad that you think it warrants changing?

Presumably you can imagine how utterly baffled users who aren't as sophisticated as you are feel about all this. If it's any consolation, a lot of what you have been told here by others is technically correct and a lot is berserk. Don't be intimidated.

One last point. According to what I have read, although I didn't look at the image itself, your current settings were set to ignore incoming RGB profiles. If so, this is such an extreme anti-profile position that even I wouldn't endorse it. And yet, your CMYK settings were not just to notice incoming profiles, but to CONVERT WITHOUT WARNING!!! This is such an insanely pro-profile position that I doubt even Andrew Rodney would endorse it.

In short, these setups were created by someone who had *some* clue what he was doing (because he had to change several defaults to get there) but left you with something most unsatisfactory. This is why, in my view, practical users don't pass on either tagged or untagged RGB files to strangers, because jokers like the one who set up your settings will wreck them either way. They convert to LAB first. This is also why practical users don't tag their CMYK files, as a means of baffling such jokers who would wreck them with an automatic conversion, among other reasons.

I apologize for the barrage of counterinformation from color management vendors which will now be forthcoming. I again withdraw, leaving as my final advice: the simple way is the best way. If you have something that's broken, fix it. Otherwise, leave it alone.

Dan Margulis

From: Chris Murphy,
Date: Sat, Sep 8, 2001, 12:14 PM
RE: Re: [colortheory] Easy profile question

Dan Margulis (76270.1033@compuserve.com) writes:
>I have been trying to stay out of this thread but it is just getting too
>theatre-of-the-absurd.
>
>If you get a CMYK image that has no profile (which will be most of the
>time), the correct procedure is,
>
>1. Open the image,
>2. Correct as seems necessary,
>3. Save the image.

That I agree with. In the context of the original discussion, I was assuming William wanted to know what to do if he were using profiles to get an accurate preview on his monitor. But if this is not a concern, then absolutely it's safe to just open the image, correct by the numbers, and save the image.

>If you assign a
>CMYK profile and convert it to some new kind of CMYK, that's an unnecessary
>conversion. Fixing it with curves is better.

I disagree. For some people with your skill set it will be better. But for plenty of people, they won't know what needs to be done to get an image meant for magazine printing, to look good for a large format size poster they are making on an inkjet. That kind of output process is VERY different from traditional CMYK press behavior.

So whether fixing it with curves is better, or repurposing it with two good profiles to resseparate the image is better - it depends on the skill set of the individual as well as what the repurposing entails (coated to uncoated is not a big deal, use curves; coated to newsprint, I might try both and see which is better; SWOP to inkjet, I would defer to two good profiles.)

>This is also why practical users don't tag
>their CMYK files, as a means of baffling such jokers who would wreck them
>with an automatic conversion, among other reasons.

This is a little off topic, but I don't see how the existance of an embedded CMYK profile is going to et you some automatic conversion that you otherwise wouldn't get had a profile not been embedded. For this to happen, there needs to be sabotage involved, and I don't exactly consider sabotage an automatic event, but a manual and intentional event. If you have an example of how this would happen with reasonable or even default color settings in any package on earth, I'd like to hear about it - under a separate subject.

>I apologize for the barrage of counterinformation from color management
>vendors which will now be forthcoming. I again withdraw, leaving as my
>final advice: the simple way is the best way. If you have something that's
>broken, fix it. Otherwise, leave it alone.

I think that's completely fair.

Chris Murphy
Color Remedies (tm)
Boulder, CO
303-415-9932

From: Chris Murphy,
Date: Sat, Sep 8, 2001, 11:59 AM
RE: RE: [colortheory] Easy profile question

Ray Landis (ray.landis@techbooks.com) writes:

>To be more specific, if we
> -are supplied a cmyk image with no profile and open it in Photoshop 6 and
>we say no to color management the image will still be viewed with the cmyk
>working space profile we have setup in color settings - this seems
>reasonable since without a profile dictating otherwise, we would want to
>view it in a known state

Yes. (Plus the side benefit is that you are able to see the CMYK file at all, on an RGB monitor. In order for this to be possible, some kind of conversion from CMYK to RGB is necessary, and it might as well be an ICC based conversion.)

> -but when we place this image in a Quark 4.x page with color management
>turned off and then print it to a cmyk printer the output still appears to
>have the working space profile included - for it matches the output of this
>same image with the working space profile embedded (having been embedded
>upon opening in Photoshop)

1.)
Embedding does not occur when opening an image in Photoshop. Embedding occurs when saving an image (there is a checkbox in the save as dialog specifically for embedding or not embedding). Profile embedding means "take the profile that is assigned to this image, and save it WITH the image."

2.)
An image with a profile embedded in it, and a duplicate image without a profile embedded in it, with QuarkXPress color management turned off WILL output the same. The profile in the one image is being ignored, and that's the only thing that's different between the two images. The data inside of them is the same.

> -it appears that unless an image already has a profile embedded, Photoshop
>6 applies it's working space profile to the file and it remains there for
>viewing and unless intentially converted to another profile will attach
>itself to the file for printing

Sort of yes, with one exception. For image's marked "Don't Color Manage This Document", also referred to as untagged sometimes, Photoshop uses the working space WHATEVER it's set to. So the concept of "working space" is what applies to these images, not the specific profile. What this means is if you have such an image open, and you go to Color Settings and change the working space profile so something else, you will see your untagged document change color (preview changes).

Photoshop does not ASSIGN the working space profile. ASSIGN means "this profile applies to this image, make it stick no matter what, until the image is converted." Since an untagged image doesn't have an ASSIGNED profile, what applies to it is the working space profile at a given moment.

> -this begs the question when opening a untagged file in PS 6, what is
>meant by turning off color management?

Seriously it's just a way to placate those who think it's a bad thing. Color management is still happening, just like color management was happening in Photoshop 2.5. Some level of color management is mandatory, or none of use could do a simple thing like doing mode changes between RGB, CMYK and grayscale.

The color management policy known as "OFF" basically means the default behavior of Photoshop is to:

a.) Ignore embedded profiles in images, right or wrong. So if you get an image with the correct profile in it, Photoshop will dump it - of course that means the working space profile is what will affect this images preview, and basis for any conversion.

b.) Do not embed profiles when saving images.

There is an exception to this: If you open an image with am embedded profile in it, it will be ignored per a.) above; but when you save it, the original profile is, by default, re-embedded in the image. Of course, there is an option in the Save As dialog that allows you to save such an image without an embedded profile.

c.) Pasting always preserves VALUES, not color appearance. This can be a gotcha if you paste color between RGB documents that truly have different profiles that should apply, but color management has been turned off. This can be mitigated by checking the "Profile Mismatches, Ask When Pasting" checkbox in Color Settings. Then you will get a dialog box everytime you paste colors asking you which behavior you want - preserve values, or preserve color appearance. They each have their merits.

>Sorry to be so thick on this concept however, what we've seen seems >contradictory to what is expressed in PS 6.

That's because it tries to please everyone as much as possible. That means there's a lot it can do that you don't need it to do, but if you want to understand all of the options then you end up having to wrap your head around Color Settings and other, foreign workflows.

Chris Murphy
Color Remedies (tm)
Boulder, CO
303-415-9932

From: Andrew Rodney,
Date: Sat, Sep 8, 2001, 12:44 PM
RE: Re: [colortheory] Easy profile question

on 9/8/01 6:22 AM, Dan Margulis wrote:
> I have been trying to stay out of this thread but it is just getting too
> theatre-of-the-absurd.

How?

> IOW, do exactly what you would have done in that part of your life which
> was happier because you had never heard of profiles and the color
> management thought police.

You certainly CAN do this. If you work completely by the numbers and don1t care what the display looks like, I agree 100%. You don1t need to define the space so leave it untagged. But I have to ask you and the people on the list if they know what the numbers from some outside source really is? I1m sure there are cases where you do. But lets say for sake of argument you do have an output profile for the device you intent to go to. IF you assign the profile, you1ll see (on a calibrated display) what the numbers in the file will produce. If there is anyone on this list the really believes that ALL CMYK files represent one recipe for all output devices, I have some beach front properly in New Mexico I1d like to let go cheap.

Let1s say you get a file from someone in CMYK that isn1t tagged. Do you know for a fact that those numbers represent the behavior of your output device? If so, forget this profile issue. If you are not sure, if you really do have a good output profile, you see what the data will produce. And if you really do have a good output profile, why are you getting files in CMYK that may (or more importantly may not) be using that recipe for RGB to CMYK conversions?

If you really want to know what the CMYK numbers for a device really are, profile it. The numbers you see in the info palette are very reliable because you used empirical data to get to those numbers for that exact output device. Anything else is a guess (the level of such a guess can range wildly).

If you get a CMYK file that will go to multiple output devices, at least you can see what the numbers will do to each device if you have an output profile. Or course, having an RGB file would be preferred as you could produce multiple CMYK conversions using each profile.

> And yet, your CMYK settings were not just to notice
> incoming profiles, but to CONVERT WITHOUT WARNING!!! This is such an
> insanely pro-profile position that I doubt even Andrew Rodney would endorse
> it.

Correct, I don1t recommend it but I will say that Adobe put a LOT of flexibility into the color settings because there are cases where someone in some workflow might need this behavior. I have strong recommendations for settings for most users but there are always some workflows that go against the norm. For example, suppose you work in a shop that simply proofs incoming CMYK files to some kind of proofer. That1s all you do. So if you get a CMYK file (tagged is better), you could save a huge amount of time automatically converting to the newer CMYK output profile. It1s a dangerous setting but with care, it will work for some users.

The bottom line here is that with added flexibility in ANY software there is added complexity and potential pitfalls. Rather than take on a communistic attitude that ONE set of settings is best for people on email list A or B, I think the key is having users understand their options and point them in the right direction hoping that with some degree of intelligence by the user (from educational sources like this list), they can make decisions that fit within their workflows.

> I apologize for the barrage of counterinformation from color management
> vendors which will now be forthcoming.

I1m not sure how to take such a comment. It isn1t in the spirit of a list that proposes to share education to it1s members. I1m not sure what you mean by 3Color Management Vendors2 so perhaps you1ll clarify this. I can speak only for myself by saying I don1t consider myself a vendor. I don1t sell any hardware or software be it a CMS product or a Wacom tablet. Like you Dan, I teach, write and lecture and I do consulting for those people that do need help not only with color management but with scanning, digital capture, workflow automation, Photoshop, etc. One could easily call you a CMYK Color Vendor as you spend a good deal of your time conducting classes which I believe are fee based. I have no problems with that and in fact would love to attend such a class someday. But I think you insult some of your readers and contributors by suggesting that by posting pertinent answers to users on this list that deal with color management, we are somehow vendors who have a hidden agenda. IF I am taking this comment out of context or incorrectly I apologize. The key to this and many other lists people like myself and Chris respond to is educational in purposes. I1ve learned a great deal from your books and this list and I don1t think it does any good to suggest you do this for purposes of evil and corruption.

This list has seen a huge amount of back and forth posts about color management with only one in recent memory who said all such posts go into the trash. It appears that those that post are generally interested in discussing some of these issues. Yes, you can suggest they go to the ColorSync list but I truly find this list a better place for real world users who don1t want to discuss how many ICC profiles will fit on the head of a pin. The CS list can get far too color geeky for me and I expect others. Of course IF the reason for this list is ONLY to discuss your classes, then I would consider this to be a very vendor specific agenda. So lets call a spade a spade.

Rather than suggest that these issues with profiles be ignored, it seems far more appropriate to educate. The behaviors we are discussing in Photoshop 6 are not going away any time soon so we either have to ignore it and in some cases suffer from those decisions or educate users so they can make intelligent decisions. I have to wonder how many of your students would be willing to spend an extra day in your class to really get the profile ICC light bulb to go off and fully understand the options they have at their disposals.

Respectfully

Andrew Rodney

From: pixel_gnome@yahoo.com, pixel_gnome@yahoo.com
Date: Sat, Sep 8, 2001, 9:24 PM
RE: [colortheory] Re: Easy profile question

Thanks Chris for your reply -
Chris said:
1.)
Embedding does not occur when opening an image in Photoshop. Embedding occurs when saving an image (there is a checkbox in the save as dialog specifically for embedding or not embedding). Profile embedding means "take the profile that is assigned to this image, and save it WITH the image."

2.)
An image with a profile embedded in it, and a duplicate image without a profile embedded in it, with QuarkXPress color management turned off WILL output the same. The profile in the one image is being ignored, and that's the only thing that's different between the two images. The data inside of them is the same.

I had thought that one difference between Photoshop 5 & 6 was that in 6 the profile was applied when the file was opened in Photoshop 6 and would stay with the file unless converted.

Are you thus saying that a CMYK file (with or without a profile) output through Photoshop 6 will exhibit the working space profile characteristics. And, this same file (with or without a profile) output through Quark with CM turned off will proof without a profile unless the file was saved in Photoshop 6 with embedding checked?

If this is the case, then all files introduced into our work environment would need to be saved in Photoshop 6 (with embedding checked) in order to ensure that what we output closely matches what we see on screen. We often receive supplied images from outside sources and our outputs are through a non-CM'd Quark workflow, not Photoshop.

Taking this a step further, wouldn't it then also be wise to convert embedded profiles in supplied files to our workspace profile for the same reasons?

thanks,
Ray Landis

From: Chris Murphy,
Date: Sat, Sep 8, 2001, 11:55 PM
Re: [colortheory] Re: Easy profile question

Ray Landis writes:
>I had thought that one difference between Photoshop 5 & 6 was that in
>6 the profile was applied when the file was opened in Photoshop 6 and
>would stay with the file unless converted.

It depends on your color management policies settings. If they are set to off the answer is no. It will have almost the same behavior as Photoshop 5.

If the policy is set to "preserve embedded" then any image with an embedded profile that you open will have that profile ASSIGNED to it, and it will stay with that image until convert (and will affect conversion). An image with NO profile embedded will have no profile assigned to it and by default will save without a profile too - the profile that affects its preview and conversion is a currently set working space profile.

If the policy is set to "off" then any image with an embedded profile will have that profile ignored for color behavior (preview and conversion), a working space profile applies instead; however the original profile, by default, is re-embedded when you save this image.

>Are you thus saying that a CMYK file (with or without a profile)
>output through Photoshop 6 will exhibit the working space profile
>characteristics.

Not sure what you mean by "output through Photoshop 6." To me, this means you are printing from Photoshop 6. If you print a document from Photoshop 6, how it prints depends on the settings in the Photoshop 6 portion of the print dialog box (Source Space and Print Space pop-ups). The defaults for this are Souce Space: Document, and Print Space: Separations. This means "send the CMYK values to the device." So with or without a profile assigned, the CMYK values will be sent to the device. If you have two identical images, one with profile and one without - they would print exactly the same.

> And, this same file (with or without a profile)
>output through Quark with CM turned off will proof without a profile
>unless the file was saved in Photoshop 6 with embedding checked?

This is a confusing question. In parenthesis you say with or without a profile, then you say "will proof without a profile" then you say "unless..embedding [is] checked." If embedding is checked that is an image WITH a profile.

What I'm saying is that if you have two identical images (in Photoshop save the same image twice, with embed profile checked, and one without embed profile checked), and you place both of them in QuarkXPress, with no color management turned on in QuarkXpress, and you print them, they will both print exactly the same. Embedded profiles don't do anything to an image except save a copy of the profile along with the image - it doesn't change CMYK values.

If this doesn't clarify, please rephrase the question and I'll take another shot.

>If this is the case, then all files introduced into our work
>environment would need to be saved in Photoshop 6 (with embedding
>checked) in order to ensure that what we output closely matches what
>we see on screen.

There are a couple of ways to handle this, and while it may annoy some that there are so many frickin color managment options, and ways to skin the cat, it allows people to pick which way they prefer doing things:

1.
Set the color management policies to "Preserve Embedded Profiles" - this means the preview will be accurate only when the image is printed to the device the embedded profile describes - which is likely NOT your device. BUT, you can go to Image:Mode:Assign Profile and you can choose your output device profile instead. Without changing a single pixel, this will show you how that image will print on your device if you do nothing to the image - just send it as is. If it's acceptable, stick the sucker in a page layout application and print it. It won't matter, in this instance, what profile is in the image because all QuarkXpress cares about (when color management is turned off) are the CMYK values in the image.

If you don't like what you see with your profile assigned, and you prefer what you saw before (the customer's profile), then click the cancel button for the Assign Profile dialog box, leaving the original profile intact. Go to Image:Mode:Convert to Profile, select your device profile as the Destination Space, and click convert. The pixels in the image will be changed in order to preserve the color appearance you see on screen, so they reproduce on your output device.

This would be my preferred method because it's safe. It allows you to ensure you really want to convert the image before you do it.

2.
Set the color management policies to "Off" - and set your device profile as the CMYK working space. No matter what, all CMYK images you open will preview on screen how they will appear on the selected output device - regardless of the profile embedded in them.

This method would be used by those who, for whatever reason, don't like the idea of Convert to Profile converting their image data; but instead would rather convert the image data using curves - or whatever. Either way the preview on-screen will show you what you're going to get.

>Taking this a step further, wouldn't it then also be wise to convert
>embedded profiles in supplied files to our workspace profile for the
>same reasons?

Option 3.
Set the color management policies to "Convert to Working CMYK" - this converts the image values by default. I would only use this if you assume all embedded profiles in images you receive are reasonably valid or this will just create a mess. I think you'd be better off with one of the above two methods, especially in the short term. See how things go with #1, and if you find you're having to convert practically all of your incoming images, then consider this option #3.

#1 is safe and allows a wait and see attitude. #2 is actually safe too, but it doesn't allow you to take advantage of embedded profiles that are correct, because they are ignored. #3 is the most convenient, but almost makes the biggest assumption (that embedded profiles are always right) - if the assumption is wrong you'll end up with a bad conversion.

BUT, the nice thing is that with Photoshop 6, an accurate device profile set as the working space, and a calibrated/profiled monitor - you will see on screen very closely what you will get on that output device. And it won't matter which option you select.

Chris Murphy
Color Remedies (tm)
Boulder, CO
303-415-9932

From: Chris Murphy,
Date: Sat, Sep 8, 2001, 10:53 PM
RE: Re: [colortheory] Easy profile question

Rafe B. (rafeb@channel1.com) writes:
>Heheh. This is amusing. So, Chris, you're saying
>that profiles are for folks without the "skill set"
>that Dan posesses? (Which would be, more or less
>the entire planet, I'd guess.)

Dan has a skill set that allows him to quickly surmise device behavior and make mental adjustments for it. In many cases (although I'm sure he'd agree not all) he's able to use his brain and skill set to color manage devices in his head. If a color laser printer is the end goal output device, he can look at a couple of prints and know what the current behavior of the device is, build a mental profile, and compensate for its current psychotic behavior. I personally don't find it amusing, I find it absolutely incredible.

It's not accurate to say profiles are only for folks without Dan's skill set. Dan uses them too. No one mentally converts RGB numbers to CMYK numbers. ICC profiles are the only way this is done in Photoshop 6; and before that it was some other kind of profile (ink settings files, or separation tables). Everyone needs them and uses them, the question is to what degree are they needed - and I'm saying "it depends."

>From my limited experience, Dan's tricks and gyrations
>are still easier to follow, and far more intuitive, than
>the ICC dogma, as implemented in Photoshop and similar,
>related applications.

We are most comfortable with what we know and understand, and we aren't as comfortable with what we don't know or understand.

>I know of at least three or four different listservs
>where the ins & outs of ICC color management are discussed,
>over and over and over again. Why would that be, I wonder,
>if it were so simple.

The basic concept is simple. The implementation is not simple because it involves so many devices, so many workflows, applications each with their own settings, many 3rd party products, measurement devices, software packages, XTensions, RIPs, device settings, paper types, inks, illuminants, vendors, customers, and PEOPLE.

Color management is this big huge gigantic thing that some people try to say is only about profiles. In comparison, color correction is simplier than color management.

Yet at the same time, if color correction were so simple, why are there so many discussions, books, and classes devoted to it? In every Photoshop class I've heard of or been to, color correction is a subject of discussion. So I don't think just because something is continuously discussed and has resources devoted to it doesn't mean it's too complicated. It just means information on that subject is in demand - otherwise there would be NO lists, books, classes, or discussions.

Chris Murphy
Color Remedies (tm)
Boulder, CO
303-415-9932

From: Dan Margulis, 76270.1033@compuserve.com
Date: Sun, Sep 9, 2001, 7:26 AM
RE: [colortheory] Danger of Embedded CMYK Profile

Chris Murphy writes,
>>This is a little off topic, but I don't see how the existance of an embedded CMYK profile is going to et you some automatic conversion that you otherwise wouldn't get had a profile not been embedded. For this to happen, there needs to be sabotage involved, and I don't exactly consider sabotage an automatic event, but a manual and intentional event. If you have an example of how this would happen with reasonable or even default color settings in any package on earth, I'd like to hear about it - under a separate subject.>>

I have to produce a picture of a screen grab of a Photoshop dialog box. When I separate it, I separate with Maximum GCR, because I want the fine lines to print 100% black (plus whatever is needed for trap). I separate this with my own setting for Electronic Publishing magazine, but later decide that it will appear in one of William's magazines, and send him the electronic file.

1. Scenario 1. I have profile embedding turned on. William's system, as we know, is set up to convert automatically. It therefore reseparates from my Electronic Publishing settings into William's house settings. These are presumably not very different colorwise, but in doing so, the lines that I had so painstakingly made 0c0m0y100k become 80c70m70y70k. The job prints marginally out of register and the lines get all fuzzy, and I complain to William's boss and tell him that William should be fired, little knowing that William had nothing to do with these stupid settings.

2. Scenario 2. I have profile embedding turned off. William's system would like to convert this, but can't because there's nothing to convert it *from.* Therefore it has no choice but to let it alone, and we both live happily ever after.

Dan Margulis

From: Andrew Rodney,
Date: Sun, Sep 9, 2001, 8:01 AM
RE: Re: [colortheory] Danger of Embedded CMYK Profile

on 9/9/01 5:21 AM, Dan Margulis wrote:
> 1. Scenario 1. I have profile embedding turned on. William's system, as we
> know, is set up to convert automatically.

We1ve been down this garden path and agreed that an automatic conversion is a bad setting for most all workflows. William should know better than to set his policies this way if he is getting files from people that are supposed to retain the original numbers.

> I complain to
> William's boss and tell him that William should be fired, little knowing
> that William had nothing to do with these stupid settings.

Can you get the guy fired who set William1s policies? Is William innocent of all actions he takes due to ignorance when dealing with any kind of file in Photoshop? For example, William doesn1t convert your file (his policies are correct) but no one taught him how to sharpen a file so he does a very heavy dose of USM while viewing the file at 25% and hoses your output. In which scenario is ignorance bliss? Neither.

> 2. Scenario 2. I have profile embedding turned off. William's system would
> like to convert this, but can't because there's nothing to convert it
> *from.* Therefore it has no choice but to let it alone, and we both live
> happily ever after.

Sure, he can still convert. Only Photoshop will guess that the untagged file happens to be whatever CMYK profile William has set as his preferred space in his color settings. Is it the correct assumption? Who knows, you never embedded a profile. Photoshop can ALWAYS convert spaces with or without embedded profiles. The problem is that without an embedded profile, Photoshop takes a guess that you place in the color settings as the preferred profile to use. So again, ignorant users get a far worse conversion than savvy users.

We can spends days talking about scenarios where users who haven1t a clue what they are doing toast files and the discussion doesn1t have to center only around profiles. So far, we haven1t outlawed baseball bats and yet people occasionally use them as murder weapons. Profiles don1t kill files, people kill files.

Andrew Rodney

From: Chris Murphy,
Date: Sun, Sep 9, 2001, 12:48 PM
RE: Re: [colortheory] Danger of Embedded CMYK Profile

Andrew Rodney writes:
>William should know better than to set
>his policies this way if he is getting files from people that are supposed
>to retain the original numbers.

If you really aren't absolutely sure about a setting, it's better to use the default (which for U.S. Pre-press is "Preserve Embedded Profiles.") The catch is that maybe he got advice from someone normally very credible, so he thought he did know better.

>Sure, he can still convert. Only Photoshop will guess that the untagged file
>happens to be whatever CMYK profile William has set as his preferred space
>in his color settings.

Yes - but that's not a conversion. If the policy is set to "Convert to Working CMYK" and the image does not have a profile embedded in it, the image is not converted when opened, it's just opened. That's the default behavior of this policy with images without profiles embedded. If the Missing Profile, Ask When Opening checkbox is selected, then you do have an option to override this behavior, including selecting a source profile for the image, and THEN converting the image from that into the CMYK working space.

Photoshop 5 could be set to assume a source profile, and if you set it to to convert CMYK images on open - even WITHOUT embedded profiles it would convert images. Photoshop 6 doesn't have such a thing in an automatic way - you need the Missing Profiles, Ask When Opening dialog (which does have sticky settings I think) checked.

Chris Murphy
Color Remedies (tm)
Boulder, CO
303-415-9932

From: Chris Murphy,
Date: Sun, Sep 9, 2001, 12:34 PM
RE: Re: [colortheory] Danger of Embedded CMYK Profile

Dan Margulis writes:

>1. Scenario 1. I have profile embedding turned on. William's system, as we
>know, is set up to convert automatically.

I specifically asked how this would happen with "reasonable or even default color settings". Setting Photoshop to "Convert to Working CMYK" isn't a good idea because it requires the assumption that a.) embedded profiles are always correct and b.) that images always need to be reseparated.

Nevertheless I must acquiesce that by embedding a profile, you do increase the chances that the image will be automatically converted, even by a small percentage. I personally would continue to embed them so I know how those images were separated, and if a problem arises, I would take that as an opportunity to instruct the individuals who automatically converted my image with a better method - but that's just me.

While I disagree with Dan's implication this is a wide spread enough of a problem to totally AVOID embedding profiles in CMYK images, I still don't like that this is possible. Effectively, by embedding a profile, whether you like it or not, you are effectively saying "I might not have correctly separated this image." Most of the time this is true - the job could change to another device, needing repurposing. But sometimes, like Dan's example, you know for a FACT that the separation is totally valid and you do not want it changed - therefore the logical thing to do is to not embed a profile.

It would be nice if there was a way we could both embed a profile (there are benefits to doing so), and set some kind of flag in the image that would inhibit automatic conversions. For example, at least raising a dialog with such an image that uses plain English saying "the originator of this image has marked it for no automatic conversion, are you sure you want to convert?" and then the default would be Don't Convert. Good luck getting this implemented...

Honestly - it's probably simpler to just not embed a profile in the copy of the image you send out when you are REALLY sure the separation is correct and you don't want it changed. Most of the time, the benefits of embedding outweigh the risks.

Chris Murphy
Color Remedies (tm)
Boulder, CO
303-415-9932

From: Andrew Rodney,
Date: Sun, Sep 9, 2001, 2:52 PM
RE: Re: [colortheory] Danger of Embedded CMYK Profile

It would be nice if there was a way we could both embed a profile (there
> are benefits to doing so), and set some kind of flag in the image that
> would inhibit automatic conversions. For example, at least raising a
> dialog with such an image that uses plain English saying "the originator
> of this image has marked it for no automatic conversion, are you sure you
> want to convert?" and then the default would be Don't Convert. Good luck
> getting this implemented...

Several was you could do this:
1. Lock the file. Of course the user can1t edit the file in any fashion but it1s a start
2. Put a text layer saying just what you wrote. The user sees it and after reading it (we have to assume the user can read), they trash the text layer. Even if the converted the file by mistake, they can close it and reopen it without a conversion.
3. Use an Annotation on the file. Photoshop 6 provides them. You put a BIG Annotation in the file that says what you said above. It doesn1t have to be trashed and it will never print so it can remain in the file forever.
4. Put a SimpleText document with the file explaining what your intentions are.

I suppose Adobe could tweak the TIFF format (they own it) where a user could somehow mark the file in such a way that a message as you suggest opens when an automatic conversion is set to take place. The could do this in the Photoshop format too. I seriously doubt they would even consider this approach. Their rational would be for users to simply understand how the application works...

Andrew Rodney

From: Chris Murphy,
Date: Sun, Sep 9, 2001, 5:11 PM
RE: Re: [colortheory] Danger of Embedded CMYK Profile

Andrew Rodney () writes:

>Several ways you could do this:
>
>1. Lock the file. Of course the user can1t edit the file in any fashion but
>it1s a start

The image is still converted; presumably someone who has "Convert to Working CMYK" set knows images are converted and save them as a different name to indicate the conversion has been done - and it's the converted image that's sent through production. The original is left intact regardless.

>2. Put a text layer saying just what you wrote. The user sees it and after
>reading it (we have to assume the user can read), they trash the text layer.
>Even if the converted the file by mistake, they can close it and reopen it
>without a conversion.

Yeah and when I give the neighbor kids a razor blade I can tell them to be careful and not cut each other but it's easier to just not give them a razor blade.

Having to think about adding a text layer to warn someone to not convert the file, when it's easier to just not embed a profile with which they could convert the file, is too much to think about for most people. And the thing is, people who do it correctly now have to remove the text layer - and plenty of workflows place the image without bringing it into Photoshop to begin with, so this requires them to open the image in Photoshop and delete the layer. We know how nicely certain other applications play with layered TIFFs.

>3. Use an Annotation on the file. Photoshop 6 provides them. You put a BIG
>Annotation in the file that says what you said above. It doesn1t have to be
>trashed and it will never print so it can remain in the file forever.

That's not a bad idea as a workflow tool anyway. But I will still have to agree with Dan that just not embedding the profile to begin with for many people will be an easier way to ensure that even if someone does have bad Photoshop settings, no matter how bizarre or rare, the image won't get automatically converted.

That embedding a profile allows for an increase incident rate that someone could override your desired conversion. It may have been better to ask Adobe not to include the possiblity for automatic conversions - most people and workflows don't need to do this, and if they do, there are products specifically designed for batch conversion of images, and that's a better place to do it anyway. If someone is using Photoshop (except for the automation functions) to open a file, they really shouldn't be allowed to convert images automatically without any kind of warning whatsoever.

>Their rational would be for users to simply understand how the
>application works...

Yes, well I'd like to have a million dollars too. It doesn't mean it's going to happen.

Chris Murphy
Color Remedies (tm)
Boulder, CO
303-415-9932

From: Stephen Marsh, Stephen Marsh
Date: Sun, Sep 9, 2001, 8:27 PM
RE: [colortheory] Re: Danger of Embedded CMYK Profile

>> In colortheory@y..., Andrew Rodney wrote:
> Sure, he can still convert. Only Photoshop will guess that the untagged file
> happens to be whatever CMYK profile William has set as his preferred space
> in his color settings. Is it the correct assumption? Who knows, you never
> embedded a profile. Photoshop can ALWAYS convert spaces with or without
> embedded profiles. The problem is that without an embedded profile,
> Photoshop takes a guess that you place in the color settings as the
> preferred profile to use. So again, ignorant users get a far worse
> conversion than savvy users.

Hello Dan and Andrew.

I have been following this thread with interest - as the CMYK side of the this missing profile/assign profile issue which started in previous posts about untagged RGB source files is just as important.

As all the talk around the 'false RGB workspace or profile' has demonstrated - it can be very hard taking a guess at an unknown RGB file and assigning or creating the 'correct' profile which produces a by the numbers or visual effect which is 'better' than the original (which has a poor workspace default used).

This is one reason that I do not like AdobeRGB as a default workspace - most untagged files I deal with demonstrate behaviour that is closer to traditional monitor spaces.

For the issue at hand, which is CMYK - I personally find a CMYK image a lot easier to evaluate if it is 'unknown'.

As in evaluating an unkown RGB file, by using the CMYK info palette readings and inspecting visual or printed separations (greyscale images) some idea of black generation can be gained, as well as black limits.

I have recently been playing with 'reverse engineering' an unknown CMYK file to get a better idea of the dot gain needed for a more accurate conversion out of the existing CMYK. I see dot gain and inkset as the two biggest problems (which profiles address).

Rather than blindly converting from the default CMYK workspace profile - the built-in CMYK settings can at least be tweaked to make a better conversion from the unknown source to the new mode.

Maximum black limits can be approximated.

Total ink limits can be approximated.

Black generation can be harder to judge - but it can still be approximated.

Of course dot gain is the biggest variable in the conversion next to the inkset. You can usually guess the inkset and there are some ways to ballpark the original dot gain settings.

This of course all takes time and effort and may not be that accurate - but at least things are better than defaults!

If you are going to convert, you can make a better decision about it. I understand that the current topic was an automatic CMYK conversion, without the benefit of human evaluation - but I think the discussion of a human making an informed evaluation and altering settings is a much more valuable debate and use of this lists energy.

In Dan's example, I would have spotted that he used a max black generation and 100% black ink values, as well as the total ink limits in use. Dot gain would have been harder, but if given enough time I could have come close. As for inkset - thats anyones guess (not to mention ICC options like which colour engine or render intent).

I agree Andrew's point that if the tag was in the file, then this hand evaluation and setting hacks would not be needed - and for file transfer and archival I totally agree with Andrew's position. But file info and read me files would probably still be used to explain the original intent anyway. A profile is still not the whole story - the intent behind it's use is just as important. A profile does not have to be tagged, it can be supplied.

Andrew wrote:

> So again, ignorant users get a far worse conversion than savvy users.

Andrew, do you mean users who are _ignorant_ of the profile because it is not tagged or supplied or noted in other ways such as in file info or read me files, or do you mean users _ignorant_ of the info palette who therefore can't make informed decisions on the CMYK data in the untagged file?

For files ready for final output as in the case above - I would not tag the file, as to indicate that I was not open to conversions.

However - the file info would be used in a CMYK file, indicating the CMYK separation method variables. Also a profile for the various images would be supplied with the files - just not tagged to them. A read me file explaining the process would also be added.

When working in an art studio - I had actions that converted from RGB to CMYK (different conditions for common work) - as part of the process, the file info section was automatically entered with the exact built in or third party profile settings/conversion options.

This would allow even non ICC based users to match their CMYK workspace exactly - for conversion (rare) or preview (common).

Now I am in pre press for a printer - and would gladly accept any information about a file, whether it is a separate profile or a read me file and file info notes.

I like to know what I am facing.

I am sure that I am not the only one who has to make 'semi-informed' decisions about an unknown CMYK file. How do others on this list evaluate a untagged file for a more informed conversion (if needed) or preview (if needed)?

I presume that similar info palette and channel palette inspections would be used, as well as assigning profiles.

P.S. I recently read that tags from APS6 in PageMaker 7 cause CMYK files to print the black separation on all process plates - if colour management is used. Apparently there is a bugfix.

From the recent example from Chris Murphy on Quark - this should not happen if colour management in layout software is disabled or not used for that image.

Sincerely,

Stephen Marsh.

From: Andrew Rodney,
Date: Sun, Sep 9, 2001, 9:03 PM
RE: Re: [colortheory] Re: Danger of Embedded CMYK Profile

on 9/9/01 6:27 PM, Stephen Marsh wrote:
> This is one reason that I do not like AdobeRGB as a default
> workspace - most untagged files I deal with demonstrate
> behaviour that is closer to traditional monitor spaces.

I agree and find that Colormatch RGB, at least for Mac users (or legacy files made on calibrated displays) works much better. So I usually recommend either ColorMatch RGB or Adobe RGB and tell people that if they have to deal with lots of files that will go to un-colormanaged applications, ColorMatch will work better. Of course if all applications treated color files like Photoshop (producing previews based on tagged data), Adobe RGB would be fine.

> As in evaluating an unknown RGB file, by using the CMYK info
> palette readings and inspecting visual or printed separations
> (greyscale images) some idea of black generation can be
> gained, as well as black limits.

You could say the same thing about an RGB file. That is, if you are going to the troubles to output a file to see what you get from the numbers, then doing so with RGB is about as cost and time effective as CMYK. The idea is to get a decent idea what the file will do WITHOUT having to output it. Naturally if you output either the untagged RGB or CMYK file, you gain a lot of information about what the file is capable of doing. With either untagged CMYK or RGB, you can get an idea of what the file can produce on a calibrated display by examining what it looks like after assigning different profiles. This is just a step closer than doing an actual output. You might still have to run a test. But we are hoping to avoid this in some if not all cases by simply getting an idea of what the numbers in a file can really do to a particular output device.

When you look at an untagged RGB file and examine the CMYK numbers, those numbers are based on both the assumed RGB profile (since it1s untagged that is your preferred RGB space in the color settings) AND the CMYK output profile you have loaded. Change either one and the numbers change. Photoshop is predicting the future here. What CMYK numbers will you get if you convert using both sets of profiles.

With CMYK files, the numbers are of course true CMYK numbers. But are those the numbers that are correct for the output device you hope to send the file to? If it is tagged, you get an accurate preview. If it is untagged, you don1t (unless you are lucky).

> Rather than blindly converting from the default CMYK workspace
> profile - the built-in CMYK settings can at least be tweaked to
> make a better conversion from the unknown source to the new
> mode.

Indeed! But having the original RGB file would be even better (and a good profile for a CMYK conversion using the settings you desire). Re-purposing CMYK from CMYK files isn1t something you want to do if you can get your hands on the original RGB file. This is why so many of us ask ourselves why users refuse to archive the original RGB data or insist on CMYK scans.

> Andrew, do you mean users who are _ignorant_ of the profile
> because it is not tagged or supplied or noted in other ways such
> as in file info or read me files, or do you mean users _ignorant_
> of the info palette who therefore can't make informed decisions
> on the CMYK data in the untagged file?

Well it could be both<g>. But originally I was referring to users who simply do not understand how Photoshop 6 works.

I1m all for CMYK numbers IF (this is a pretty big IF IMHO) you know what those numbers will produce. An identical tagged and untagged CMYK file will produce the same numbers. The tagged file tells Photoshop 6 how to preview the file and should tell the user the output device the file is destined for (in the kind of world Dan likes to use as an example, someone could name a profile 3Iris-archival-matt.icm2 when the profile was really built for a Kodak Approval but I don1t see why anyone would be stupid enough to do this. But it isn1t impossible). With the untagged file, you get the same numbers but do you know if the CMYK is for this Iris running matt paper, a Kodak Approval, an Epson 10000 or Joe blows press? Profiles are only descriptors. The should describe to Photoshop 6 how to preview the files and it should inform the user how the file was converted for a specific output device.

> For files ready for final output as in the case above - I would not
> tag the file, as to indicate that I was not open to conversions.

There are a lot of workflow situations where not tagging the file does no harm (but potentially no good). Lets say you have a dozen CMYK files all in the CORRECT output space linked to a Quark doc. The profile is meaningless and not necessary. The numbers are set for the intended output device. So we don1t need a profile. We are not at all concerned how the files look on screen. Now if you take those files and hand them to another user who hopes to output again to a different device, by not having a profile, you could make that persons life a lot more difficult because they don1t know the source of the original CMYK files. You could tell them, you could embed the profile or better, just give them the original RGB files (tagged) and let them convert to CMYK for the newer output device. So having a tagged file in a workflow where it is in output space and will never be used again, I don1t see the need to tag the file. I also see no reason NOT to tag the file. Again, do you need or care about describing what the numbers in that CMYK file really mean? If not, don1t tag. If you do, tag.

> When working in an art studio - I had actions that converted from
> RGB to CMYK (different conditions for common work) - as part of
> the process, the file info section was automatically entered with
> the exact built in or third party profile settings/conversion options.

An excellent idea! Users don1t take advantage of the metadata in the files enough. Plus there are ways of putting this kind of data directly into the profile and ways users can see this data. For example, there are private tags in ICC profiles specifically put in place for the software that generates them to use for such information. If you look into the private tag of a profile made by GretagMabeth1s products, you1ll find all the spectral measurement data. Handy if you need that. Not enough people (or companies) are pushing this capability. Can you really supply too much information about a file, especially if it doesn1t really add too much to the file size?

Andrew Rodney

From: Chris Murphy,
Date: Mon, Sep 10, 2001, 12:30 AM
RE: Re: [colortheory] Re: Danger of Embedded CMYK Profile

Stephen Marsh writes:
>This is one reason that I do not like AdobeRGB as a default
>workspace - most untagged files I deal with demonstrate
>behaviour that is closer to traditional monitor spaces.

This is one reason some people may prefer ColorMatch RGB for a working space in lieu of Adobe RGB. It's better for the default to work, than for it to have a bigger gamut (Adobe RGB has a slightly larger gamut than ColorMatch RGB).

>In Dan's example, I would have spotted that he used a max black >generation and 100% black ink values, as well as the total ink >limits in use.

When? In the example, the settings are set to Convert to Working CMYK, you don't have an opportunity to see the original CMYK values with this color management policy set in Photoshop. The image gets converted as the image is opened. That's the problem with this policy.

>P.S. I recently read that tags from APS6 in PageMaker 7 cause >CMYK files to print the black separation on all process plates - if >colour management is used. Apparently there is a bugfix.

That's real cute if it's true. I wonder if this stuff is actually tested by anyone but a band of anteaters before it's released to the public.

Chris Murphy
Color Remedies (tm)
Boulder, CO
303-415-9932

From: Stephen Marsh
Date: Mon, Sep 10, 2001, 7:55 AM
RE: [colortheory] Re: Danger of Embedded CMYK Profile

I originally wrote:
> >In Dan's example, I would have spotted that he used a max black
> >generation and 100% black ink values, as well as the total ink
> >limits in use.

Chris Murphy replies:

> When? In the example, the settings are set to Convert to Working CMYK,
> you don't have an opportunity to see the original CMYK values with this
> color management policy set in Photoshop. The image gets converted as the
> image is opened. That's the problem with this policy.

Thanks Chris, I am aware of all this - which is why I originally wrote this statement above the one you quote, in my original post:

> > "If you are going to convert, you can make a better decision about it. I understand that the current topic was an automatic CMYK conversion, without the benefit of human evaluation - but I think the discussion of a human making an informed evaluation and altering settings is a much more valuable debate and use of this lists energy."

I was attempting to 'spark' some talk on how various users evaluate an unknown CMYK file - to see if it suits their conditions.

It has been made clear that an auto conversion is not good, and for CMYK it is a even dicier situation than for RGB. Before this subject dragged on another twenty something threads - I was hoping to move the discussion into braoder areas, instead of chewing over auto conversions for a few more days.

This CMYK evaluation could be via the numbers or visually. I prefer to know what black ink values, TAC/TIC/TIL etc are being used. Then after the numbers check out - how does it 'look' on my eyeball profiled system. Of course this applies to RGB, but it is harder since there is no black plate or ink limits etc to verify.

I understand I am 'hijacking' William's thread a bit here...so to contribute to the original question:

No one has commented on the 8 bpc DITHER setting being active in these settings mentioned by William.

Apart from potential image quality issues, this can also add to a files size more than one might expect (just like some ICC profiles or long file info comments).

I have only had APS6 installed at work for a few days - so I have not had time to explore this 8 bpc mode conversion dither much yet, which I presume applies to all colour modes if this is active, as in Williams situation.

This dithered noise is separate to the high bit noise feature. So as in the case of a banded gradient, I presume that the noise can be applied in 8 bpc RGB > CMYK, as well as in 8 bpc CMYK
> 16 bpc CMYK > 8 bpc CMYK (as well as dither in the grad tool).

So it would be possible to get two applications of this dithered noise, in some mode conversion workflows (if intended). Correct? I presume most people would not take a regular bit file into high bit mode without a special reason as in 'band aid'.

My take on the 8 bpc dither is to disable it unless your outputs suffer from banding, contouring or posterization. As a default, it seems safest to leave it off.

Sincerely,

Stephen Marsh.

From: Kim Lathan
Date: Mon, Sep 10, 2001, 1:30 PM
RE: [colortheory] Re: Danger of Embedded CMYK Profile

We recently had a file supplied by a client that we ran directly out for proof. Color was marked up by the client saying the flesh tones looked pasty and red. It was requested that we correct the color.
I have my workstation set to recognize embedded rgb or cmyk profiles, but not automatically convert, in case I need to know that, and have proofing devices,scanners and monitors calibrated and color managed.

Upon opening the file in PS5.5, the file came up with the embedded SWOP coated profile ( I forget the exact name of the profile at the moment). When I told it to convert, the file looked like what I suspected the client was expecting. This saved me the time of retouching the file, as all I needed to do was resave the file without embedding the profile (preserving the original file of course in another location if needed).

The proof came out fine.

So I would say, I am glad the client had an embedded profile in this case and glad that I am set up to recognize profiles (I did not used to be set up this way), because then I knew pretty much what they were expecting. Will this work in all cases? That I am unsure of, although with more and more digital files being provided by clients, it could/will be an issue.

--
Kim Lathan

From: Steve Upton, upton@chromix.com
Date: Thu, Sep 13, 2001, 3:34 AM
RE: [colortheory] Re: Danger of Embedded CMYK Profile

At 12:27 AM +0000 9/10/01, Stephen Marsh wrote:
>I have recently been playing with 'reverse engineering' an
>unknown CMYK file to get a better idea of the dot gain needed for
>a more accurate conversion out of the existing CMYK. I see dot
>gain and inkset as the two biggest problems (which profiles
>address).
>
>Maximum black limits can be approximated.
>
>Total ink limits can be approximated.
>
>Black generation can be harder to judge - but it can still be
>approximated.
>
>Of course dot gain is the biggest variable in the conversion next
>to the inkset. You can usually guess the inkset and there are
>some ways to ballpark the original dot gain settings.
I think it is important to note that the dot gain and ink settings in a synthesized CMYK space will affect the conversions FROM that space but the Max black, TAC and black gen have no effect on the "proofing" transform from CMYK to a known CMYK separation. Of course the Max black, TAC and black gen settings do have an effect on the outgoing CMYK setup or profile (CMYK setup and profile being synonymous in PS 6)

If that is obvious to all then feel free to ignore this post.

Regards,

Steve Upton

+--------------------------------------------------+
CHROMiX / Profile Central
www.chromix.com www.profilecentral.com
+--------------------------------------------------+

From: Stephen Marsh
Date: Thu, Sep 13, 2001, 4:53 AM
RE: [colortheory] Re: CMYK > Other modes (was: Danger of...)

In colortheory@y..., Steve Upton wrote:
> > If that is obvious to all then feel free to ignore this post.

Steve - thanks for the reply.

This is far from obvious, testing has been the only way for me to verify this - and I came to the same conclusion. But it's nice to have someone else say it is so.

I for one thank you for making sure this point was clear to all.

So whats the reason for only limited data being needed to repurpose a CMYK file?

Why do the separation settings get ignored by Photoshop? (ucr/gcr, max black and total ink limits etc).

And yes, I agree with Andrew Rodney's previous response - starting with a RGB file is better, but if you only have the CMYK version to begin with (say an old drum scanner)...

BTW, from memory APS4 worked this way too, only dot gain and inkset were applicable in the conversion from CMYK to other modes.

Sincerely,

Stephen Marsh.

From: Terry Wyse, terry@allsystems.com
Date: Mon, Sep 17, 2001, 7:30 PM
RE: Re: [colortheory] Easy profile question

on 9/8/01 12:22 PM, Dan Margulis wrote:
> If you get a CMYK image that has no profile (which will be most of the
> time), the correct procedure is,

> 1. Open the image,
> 2. Correct as seems necessary,
> 3. Save the image.

> IOW, do exactly what you would have done in that part of your life which
> was happier because you had never heard of profiles and the color
> management thought police.

I won't comment on the "color management thought police" comment as that would waste precious bandwidth ;-)

I would add a step "1b" that would be to assign a CMYK profile that either 1) is close to the target "press" that the image was scanned/separated for or 2) assign a CMYK condition that matches your intended destination. Either will give you a more-or-less accurate preview of the current state of the image better than NOT having any profile assigned to it. Of course, if you purposely assign nothing, your CMYK working space still gets "assigned" by default for preview purposes.

> The reason one might assign an arbitrary profile in RGB and not in CMYK is
> that there is no extra conversion involved. If your normal RGB is Monitor
> RGB, but you decide to assign Adobe RGB to it for this one image, you still
> have to convert it to CMYK one time, same as if you hadn't. If you assign a
> CMYK profile and convert it to some new kind of CMYK, that's an unnecessary
> conversion. Fixing it with curves is better.

Who says you have to assign and convert to a "new kind" of CMYK? The reasons for assigning a profile in *either* RGB or CMYK are basically the same, RGB being a bit more important because of the assumed additional conversion step.

> Fixing it with curves is better.

Just curves? I would argue that converting from a known/source CMYK profile to a correct target CMYK profile does MUCH MORE than you could ever do with a simple curves adjustment.

Let's consider someone (I'll say a printer/prepress department because I know of a case where this actually happened) receiving an image that either had a CMYK profile embedded or it was known what the CMYK image was originally targeted for (let's say USWebCoatedSWOP for sake of argument). Let's also assume this prepress/printer has profiled either their presses or contract proofing system.

Do you really think simply using curves to attempt to correct this image is BETTER (it's certainly not easier) than simply performing a profile-to-profile conversion?

I know the answer to this one since I saw the operator spend much time and several rounds of proofs trying to correct this image. When I found out what was going on, we simply did the profile conversion and a single proof and, walla!, the image was corrected.

Terry

_____________________________
Terence L. Wyse
Color Management Thought Police
All Systems Integration, Inc.
http://www.allsystems.com
terry@allsystems.com
_____________________________

Adobe Photoshop training classes are taught in the US by Sterling Ledet & Associates, Inc.

Contact request form

Receive Schedule
and Pricing updates.

If you let us know how to contact you, we will enter you into our monthly drawing for a free 2-day class (A $895 value).

Get free video training
Get free tips, tricks and shortcuts
Get special sale pricing and free seminar invitations

Logo_small

Teach for us

Sterling Ledet & Associates, Inc. 4100 Perimeter Park South Atlanta, GA 30341

work sales@ledet.com work administration@ledet.com work webmaster@ledet.com

P work 770.414.5007 P work 877.819.2665 F fax 312.896.9094

Authorized Training Provider

Dan Margulis Applied Color Theory --Fate and the False Profile

Receive Schedule and Pricing updates.

Receive Schedule
and Pricing updates.