Adobe Photoshop Training with Dan Margulis

Dan Margulis Applied Color Theory

RGB Numbers and Workspaces

Date: Tue, 14 Oct 2003 19:41:11 -0000

From: Holly Thorne

Subject: RGB Numbers

Been reading along here...charming stuff.

I want to just clarify something so my head is screwed on right. No matter what color space I use (sRGB, Adobe RGB, etc.), my colors are represented by the same numbers 256x3 channels (unless I am working in 16 bit). SO...I am wondering: when someone refers to Adobe RGB as a 'broader color space' just how is that? I mean if it is using the same numbers and represents different colors, it really has the same number of colors -- it just represents them differently?

Not to throw a glass beaker over a rock driveway, but doesn't that deflate the importance of the working color space a bit? If my monitor doesn't display Adobe RGB, I can choose to safely view in sRGB and don't have to futz with profiles, because sRGB will probably be assumed by most devices. No? So here I am with my sRGB image going to an sRGB device (another monitor) and voila...sRGB. Difference would be calibration -- which would be a variable anyhow.

If I take that same sRGB image and tell PS about my monitor in a profile (not so as to embed it), and then choose to proof on screen, I can see some previews for generic web and sheetfed without $$ spent on custom profiles. Blimey if these don't end up pretty close. I convert to CMYK, and then I have CMYK, and it looks like CMYK, smells like CMYK...separated for my target. At this point, with CMYK, I don't bother embedding a profile because it shouldn't matter. If I have prepped my CMYK file for CMYK output to a specific CMYK device, then I am not changing anything by telling the printer "hey, printer, I am sending you a CMYK file separated just for you." I don't re- profile a target I have already profiled for. Snurks to custom profiling...I get that you want to customize to specific printers and inks.

So, just thinking aloud, mind you, if I just stick with sRGB and don't try to get fancy-schmancy and use standard printing stock etc., I get color I can be happy with without all the profile-potential- hang-me-ups and complications.

Is all that about right? If not, please don't start a war on my account but just tell me what's wrong in the second paragraph? I'll suffer the rest.

Holly Thorne

___________________________________________________________________________

Date: Tue, 14 Oct 2003 16:54:01 -0600

From: Andrew Rodney

Subject: Re: RGB Numbers

on 10/14/03 1:41 PM, rgbvitality wrote:

I want to just clarify something so my head is screwed on right. No

matter what color space I use (sRGB, Adobe RGB, etc.), my colors are

represented by the same numbers 256x3 channels (unless I am working

in 16 bit).

No. The same color appearance can be produced with different sets of numbers in different RGB Colorspaces. The same numbers produce different appearance too.

Not to throw a glass beaker over a rock driveway, but doesn't that

deflate the importance of the working color space a bit? If my

monitor doesn't display Adobe RGB, I can choose to safely view in

sRGB and don't have to futz with profiles, because sRGB will probably

be assumed by most devices. No?

Nope. You think your monitor IS producing sRGB and for that reason you don¬πt need to profile it? Not the case.

So here I am with my sRGB image going

to an sRGB device (another monitor) and voila...sRGB.

That¬πs in a perfect world. Output devices and capture devices can¬πt really be natively be in sRGB as sRGB isn¬πt even based on a real device and if it were, it be a very simple monitor like device since Working Spaces only need three sets of values to be defined (a Gamma, whitepoint and chromaticity values).

If I take that same sRGB image and tell PS about my monitor in a

profile (not so as to embed it), and then choose to proof on screen,

I can see some previews for generic web and sheetfed without $$ spent

on custom profiles.

IF indeed those devices behaved as you¬πre predicted.

I convert to CMYK...

Using a profile!

At this point, with CMYK, I

don't bother embedding a profile because it shouldn't matter.

Correct. Unless you want someone to open the file and see how it appeared to you.

So, just thinking aloud, mind you, if I just stick with sRGB and

don't try to get fancy-schmancy and use standard printing stock etc.,

I get color I can be happy with without all the profile-potential-

hang-me-ups and complications.

IF indeed those devices behaved as you¬πre predicted. Another emphases on ¬≥IF¬≤.

Andrew Rodney

http://www.imagingrevue.com/

___________________________________________________________________________

Date: Thu, 16 Oct 2003 04:47:46 -0000

From:Randy Wright

Subject: Re: RGB numbers

Adobe98 is to sRGB as inches are to centimeters. 10 inches is not the same as 10 cm. You can measure any length(color) in inches or centimeters, but the numbers defining that length(color) will be different. Also, 256 inches is a greater length(range of colors)than 256 cm, but you can make finer distinctions between the steps(colors) in the metric scale.

Randy Wright

Color Services

___________________________________________________________________________

From: "Mike Russell"

Date: Fri Oct 17, 2003 2:24 am

Subject: Re: [colortheory] RGB Numbers

Holly,

I'm in agreement with you. There's nothing wrong with your second paragraph, except that it's probably redundant to tell the emperor he has no tie, when in fact he is not yet ready to accept the notion that he has no clothes at all.

There is less need for profiles than is often touted, particularly for a small set-up of one or two systems. For me, the main challenge of color correction is the adjustment of color to achieve a significant effect in the final image, and this is not facilitated by over-accurate calibration and profiling, and may in fact be hindered by it.

Good quality digital pictures were happily being made before profiles existed, with very relatively little effort put into the issues that profiling is designed to solve. The tangible progress in color correction has been, I submit, not accuracy and reproduceability but improvements in equipment speed, capacity, and cost.

I'll go one further and say that we are acting out, through our controversies over whether and how much to calibrate, an ancient psychological battle. Mankind has ever been split into the Dionysians, who follow a devil may care attitude about everything, and the Apollonians, who are forever striving to bring order the world.

Balance is key, and in fact each of us embodies aspects from both personality types. Too much Dionysius, and everything is a mess. Too much Apollo, and we're spending too much time staring at patches and sticking suction cups on our monitors.

Mike Russell

http://www.curvemeister.com

http://www.zocalo.net/~mgr

http://geigy.2y.net

___________________________________________________________________________

Date: Fri, 17 Oct 2003 08:00:17 -0600

From: Andrew Rodney

Subject: Re: RGB Numbers

on 10/17/03 12:24 AM, Mike Russell wrote:

I'm in agreement with you. There's nothing wrong with the second paragraph,

except that it's probably redundant to tell the emperor he has no tie, when

in fact he is not yet ready to accept the notion that he has no clothes at

all.

More Dan speak?

Good quality digital pictures were happily being made before profiles

existed, with very relatively little effort put into the issues that

profiling is designed to solve.

Great color WAS made before profiles. The question was, how many rounds of proofs were needed, did anyone looking at the image have any idea of what they were looking at was remotely close to what they1d get off the printer. Control over gamut mapping was virtually non existent and taking the same RGB data (if you could even get it) and producing multiple files for multiple devices was near impossible (unless you wanted to burn more time and money at the print stage).

Profiles don1t do anything but describe stuff. When you describe what the display is going and what the numbers in the file really mean (they are after all just numbers), it makes it a lot easier, faster, cheaper and more consistent to get the good color. Profiles don1t magically produce numbers that are correct to produce great color. Profiles allow the user to see and then get the color they want. If you1re happy making prints then corrections until you get to your aimpoint, you don1t need a profile. But I prefer NOT to use a kitchen knife as a screw driver when I have a power drill!

Andrew Rodney

http://www.imagingrevue.com/

___________________________________________________________________________

Date: Sat, 18 Oct 2003 10:20:47 -0400

From:John Castronovo

Subject: Re: Re: RGB numbers

Randy,

In your analogy, one can measure the same distance with either inches or centimeters, i.e. the numbers are different, but the thing being measured is the same.

However, the difference between sRGB and Adobe98 (or larger color spaces) is that the size actually increases and not just the numbers measuring it. The reddest red is redder in one than the other, so given that there are only 256 numbers to represent red, a one unit change in sRGB means less than it does in a larger space.

Maybe you were trying to say the same thing, but I thought that the analogy could be misleading to some.

john castronovo

___________________________________________________________________________

Date: Sat, 08 Nov 2003 13:43:38 -0000

From: "rgbvitality"

Subject: Re: RGB Numbers (round 2)

I'm back after a little leave...I just wanted to clarify, and thank those that responded. I still have a quandry, and really want to understand...

I'm in agreement with you. There's nothing wrong with the second paragraph,

except that it's probably redundant to tell the emperor he has no tie, when

in fact he is not yet ready to accept the notion that he has no clothes at

all.

So...I have 256x3 colors in sRGB or AdobeRGB. These colors map something different. Using the measure analogy, say the following represents broadness of a color space:

sRGB:

| | | | | | | | | | | | | | | |

Adobe RGB:

| | | | | | | | | | | | | | | |

The color range for Adobe RGB is somewhat broader. OK...Size is said to be impressive, but what does it really mean? As a girl size hasn't always been a motivation, regardless of what you hear.

So, I view this on a screen that is neither sRGB or Adobe RGB...it is Monitor RGB.

say Monitor is somewhere between sRGB and Adobe RGB:

| | | | | | | | | | | | | | | |

The representation of either of these is skewed, unless it falls within the range of my monitor...If I can't see the 'big end' of the Adobe RGB, and it represents a color outside my monitor gammut, that will pretty much be re-assigned to something else, and I won't see it correctly. yes? Like a flat conversion from RGB to CMYK, I get trunctated results just from viewing on screen! If I use sRGB, the color will pretty much be guaranteed to fit my monitor, and I see all of it...no skewing. This is if I don't

calibrate. yes?

Monitor RGB:

| | | | | | | | | | | | | | | |

sRGB:

| | | | | | | | | | | | | | | |

Adobe RGB:

| | | | | | | | | | | | | | *|* *|*

*color in trouble*

Now, I've viewed on screen. If using Adobe RGB for correction and having been a good girl and calibrated my monitor and generated the ICC profile, the numbers get corrected for the space of the monitor. That is sRGB and Adobe RGB remap for the screen based on the profile...

Monitor RGB:

| | | | | | | | | | | | | | | |

sRGB:

| | | | | | | | | | | | | | | |

Adobe RGB:

| | | | | | | | | | | | | | | |

As far as i understand the profile is supposed to translate so as to optimize color to the device. If i have 256x3 colors, then that is all I have. A good profile works with those limitations to display what I actually have optimally. NO? If that isn't the way this works, then I am not sure what the point is if the mapping isn't going to show me a changed representation of all the colors and adjust according to the device profile? In the end, broad or short, whichever the color space, I see the same thing if i choose a working space and have a monitor profile.

If this works as i have stated, then corrections should lead to the same display if there is an optimal appearance. If this does not work the way i have stated, then the Adobe RGB will represent all sorts of colors I can't see -- and can't judge the meaning of reliably in preview. However, if it DOES remap, the same representation of sRGB and Adobe RGB on screen will mean different things as mappings -- if the numbers can be interpreted differently -- that is IF the printer knows the profiles the result is based on.

so...i go along with the assumption it has to re-map for the preview...not change the numbers of the file, but to show me Monitor RGB representations of each file.

I take my identically corrected sRGB and Adobe RGB images, and decide I want to print.

If i work in RGB having built the Monitor profile, I see the colors mapped to the Monitor RGB on screen. if I send sRGB to press with no profile, I should get a CMYK conversion of these colors...unpreviewed, the results would probably diminish RGB>CMYK. However, converted to CMYK before sending (to a printer that respects my CMYK) I will get what i send, and preview my CMYK via my Monitor RGB. This is the only time this happens: No profile embedded, no real surprises. If I send sRGB with a profile for the working space, that space should adjust to the CMYK--IF the profile is respected. If not, profiling does nothing. If it adjusts, I SHOULD get somewhat better results by filling the CMYK gammut, depending on the quality of the mapping. HOWEVER, if these are drastically different, there might be compression in various ranges...who knows what you really get. I could get equally surprised by a profile than not having one. It depends on how that conversion is made. But comparing the workflows, it seems a smarter move to do one of the following:

sRGB>CMYK

sRGB>embed sRGB profile to send RGB to CMYK device

Well, so I keep following the string...If I work in Adobe RGB and send Adobe RGB to press with no profile, the numbers will probably be seen as sRGB. The response -- because there is no translation -- will be seen as sRGB, and the result will probably be FLATTER than working in sRGB with no profile because the sRGB representation will be compressed. No? I wouldn't optimally correct the image in a different way just because the numbers tell a different story. On the other hand, I stick the Adobe RGB profile in there and send RGB, the device should read the profile, understand the representation of Adobe RGB, and the result might seem to bloom on press. The colors I can't see get translated to the CMYK space and just the opposite of what happens without a profile happens with. That might be a blooming surprise of over-saturated color...Again, depending on how the color is translated. rreally, if all is working perfectly, sRGB correction should MATCH the AdobeRGB --that is IF EACH IMAGE HAS BEEN OPTIMALLY CORRECTED. Regardless of the working space.

If any of this is correct, i need a profile embedded to benefit from Adobe RGB...HOWEVER, why do I need Adobe RGB at all? if the goal of profiling is to match screen to print, then profiles will work with either sRGB or Adobe RGB to give me the same match from my screen to printer...regardless of the working space. Looking back at the non-profile results, adobe RGB only ends up in flatter images when profiles are not respected, so what benefit is there to Adobe RGB in imperfect situations?!

It seems the best choice is to work in sRGB, in either case.

if i have someething fundimentally wrong, I'd be glad to know so I can rethink what i

do.

Holly Thorne

___________________________________________________________________________

Date: Mon, 10 Nov 2003 11:23:03 -0800

From: Alison Walker

Subject: Re: Re: RGB Numbers (round 2)

Holly,

I am very impressed with how you have been able to demonstrate the

issues of out of gamut colors visually in an e-mail. You are on the

right track. There are two more graphs you need add, CMYK and Lab.

CMYK SWOP Coated 320 dmax

| | | | | | | | | | |

sRGB

| | | | | | | | | | | |

6 color Epson

| | | | | | | | | | | | |

Monitor RGB

| | | | | | | | | | | | | |

Adobe RGB

| | | | | | | | | | | | | *|* *|*

*|*

Lab

| | | | | | | | | | | | | | |

| | | | |

* out of gamut colors relative to smaller color spaces

Profiling is a way of providing a definition of the "flavor" of color that is represented by the numbers found in a color space. A red might visually look the same in two different files but numerically they may be different if they are from two different color spaces. Or they my have the same RGB values but display differently relative to there color space. The job of the profile is to move colors between color spaces. If a smaller space does not have a particular flavor of color as in a larger space, the conversion process will figure out how to move that color into the smaller space.

Every profile has a table of RGB measurements taken when the profile was made. It also has a Lab table representing those RGB values. Because Lab has a larger color space than any device, it is used as a translator between profiles. Additionally, the rendering intent (like relative or perceptual) used to perform all this math will determine how in gamut and out of gamut colors are transfered between the two profiles / color spaces. The idea being that with profiles we can make "choices" about how colors are converted from one space to another. Managing the conversions to get more predictable results.

The idea of starting with a larger color space is to try to capture as many of the original colors found in an image. This way no matter what your final out put, you will have retained all those colors to send to an output device assuming its gamut is big enough to accommodate them. By starting with the larger space you are not limiting your self if you change output devices sometime in the future. Your master RGB file might still have colors in it that a larger gamut device could handle. Note the difference between the CMYK and Epson output spaces above.

No matter what, as you convert between spaces you will loose colors if they are out of gamut. The profile tries to keep colors that are the same flavor (Lab) but with different RGB values looking the same as they are converted as long as the flavor is contained in each space. And converting from a smaller space back to a larger will not bring them back. Once they are lost in a conversion, they are gone for good. But trying to decide what color space to start with is the big question. My feeling is if you can find a repeatable and predictable way to handle out of gamut colors with one space better than another, that is the space you should work with. Other wise you may be fighting with colors your output device could never handle.

I find it best to send out files that are converted to the final output device. That way I know how the conversion was handled and if I have to make any changes I can redo the conversion the exact same way as before. But if you are sending out RGB, they must have a profile attached. Attaching profiles to CMYK is a little less critical but can be helpful. Sadly, you can't always count on the person down stream knowing what to do with some of these images. Find a vendor you trust. Talk to them a head of time. Ask questions. If you don't think they understand, either bring them up to speed or go somewhere else. But don't assume they know more then you.

Good luck. Hope this helps.

Alison Walker

Seattle, WA

___________________________________________________________________________

Date: Tue, 11 Nov 2003 12:37:56 EST

From: Dan Margulis

Subject: Re: Re: RGB Numbers (round 2)

Holly writes,

Looking back at the non-profile results, adobe RGB only ends up in flatter

images when profiles are not respected, so what benefit is there to Adobe RGB in imperfect situations?!

Certainly one has to look out for such situations. We recently had the longest thread in the history of the group, in which there was a lot of heat but all the rational parties agreed that people need to be extremely careful about who they hand their Adobe RGB files off to.

Since that time, there has been a major development in Photoshop CS. The new default behavior is that embedded CMYK and grayscale profiles are ignored, period. No warning, no nothing. This should, hopefully, terminate the endless threads here in which we are advised that embedded profiles are the wave of the future in CMYK and that it's all a matter of educating users and that resistance is futile.

The RGB situation is similar. The new Photoshop CS default is sRGB. Embedded profiles are honored by default, so if we receive a tagged Adobe RGB file from someone else it will open into Adobe RGB automatically, without any warning. Of course, many users will continue to have settings that ignore the profile with disastrous results.

These changes concede the correctness of what I have been saying for many years, since in effect what they are doing is attempting to restore the pre-1998 status quo. IOW, what we've learned the hard way since 1998 is that the world at large doesn't have a taste for the "flavor-of-the-week" RGB and CMYK described elsewhere today. Instead, we have in CMYK an explicit return to a vague standard. In RGB the move isn't quite complete but it's been evident for some time that sRGB will be the winner, and now it's a sure thing.

Also, in my classes there have been a surprising number of recent cases where students brought in problem images caused by a misuse of Adobe RGB. This past week there was a particularly egregious example. The student's company produces food catalogs, the food being shot digitally in a studio. Many of the items are brilliantly colored, such as corn or various green vegetables.

Their workflow apparently calls for the photographer to convert to CMYK before the color correction, which isn't a great idea IMHO. But whatever, all the student had was uncorrected CMYK files. The color basically looked good but wherever there was something brilliant all the detail was almost completely gone. It was a real PITA to get it back.

While we don't know what went on in the studio, I'd bet a large amount of money that the photographer was using Adobe RGB or something even wider-gamut. Thus, he had a lot of out-of-CMYK-gamut colors while in RGB, and when he converted, no matter what setting he chose, he was booked to wipe out detail in bright colors.

The setup was apparently well calibrated, so all the photographer had to do was assign a false profile of sRGB to these particular images and all would have been well. Instead, there was a mess that took a long time to fix.

In summary, Adobe RGB is perfectly viable but those who want to use it need to 1) understand that the rest of the world isn't necessarily on the same page and that precautions will be necessary before passing the files on to strangers; 2) understand how to assign a narrower-gamut profile if necessary for certain images.

Dan Margulis

___________________________________________________________________________

Date: Fri, 14 Nov 2003 09:44:16 -0600

From: Lori Sabo

Subject: Re: Re: RGB Numbers (round 2)

Dan,

Does that mean you can't convert correctly from a cmyk file to other

cmyk spaces or to rgb spaces (as in, convert to profile)?

Lori

___________________________________________________________________________

Date: Fri, 14 Nov 2003 16:30:31 EST

From: Dan Margulis

Subject: Re: Re: Re: RGB Numbers (round 2)

Lori writes,

Dan,

Does that mean you can't convert correctly from a cmyk file to other

cmyk spaces or to rgb spaces (as in, convert to profile)?

No. All color settings behave exactly as before, as do the Assign Profile and Convert to Profile commands. The change is that the new *default* is for CMYK embedded profiles to be ignored altogether, although we are free to change it to something else if we like. Thus, we finally have an end to the interminable debate on this list as to whether CMYK embedded profiles will ever become so entrenched that we would be able to trust strangers to honor them. But, if you have something that works for you in Photoshop 7, just load it into CS and continue to do what you're doing.

Dan Margulis

___________________________________________________________________________

Date: Fri, 14 Nov 2003 16:25:08 EST

From: Dan Margulis

Subject: Re: Re: CMYK on RGB only devices

Hal Silverman writes,

Command-Option-~ (tilde)

What is the selection that is made based on?

A grayscale version of the document, created internally and loaded as a selection without ever becoming visible to the user.

Dan Margulis

___________________________________________________________________________

Date: Sun, 16 Nov 2003 13:36:09 -0700

From: Chris Murphy

Subject: Photoshop CS defaults, was: RGB Numbers (round 2)

On Nov 11, 2003, at 10:37 AM, Dan Margulis wrote:

Since that time, there has been a major development in Photoshop CS. The new

default behavior is that embedded CMYK and grayscale profiles are ignored,

period.

That's always been the default behavior. In Photoshop 6 and 7, the default Color Settings was set to Web Graphics defaults, which causes all of the color management policies to be Off by default.

The RGB situation is similar. The new Photoshop CS default is sRGB.

That's the same as it's been since Photoshop 5.

Embedded profiles are honored by default, so if we receive a tagged Adobe RGB file from

someone else it will open into Adobe RGB automatically, without any warning.

Of course, many users will continue to have settings that ignore the profile

with disastrous results.

Yes, this is what's new. The "General Purpose Defaults" for North America, Europe, and Japan. The color management policy for RGB is now Preserve Embedded thus RGB editing spaces will be embedded into files when saved, and embedded profiles will override the working space automatically when opening files.

The other change is that the rendering intent has been changed to Perceptual which I think is a bad idea. If it's used in conjunction with the default CMYK profile from Adobe it will result in nearly identical conversions as RelCol in particular in the case of SWOP. This is not how most profiles behave. Most of them have a bit of a contrast and midtone boost in the perceptual intent as compared to RelCol. If this were the case with the U.S. Web Coated (SWOP) v2 profile, I wouldn't object as much because as previously discussed on this list the Adobe SWOP v2 profile produces darker separations than it should.

These changes concede the correctness of what I have been saying for many

years, since in effect what they are doing is attempting to restore the pre-1998

status quo.

Dan, two things have changed, let's not get carried away. U.S. Prepress Default was never the default behavior in Photoshop, and if you decide to select it, it has the same behavior as it has in Photoshop 6 and 7.

Their workflow apparently calls for the photographer to convert to CMYK before the

color correction, which isn't a great idea IMHO. But whatever, all the student

had was uncorrected CMYK files. The color basically looked good but wherever

there was something brilliant all the detail was almost completely gone. It was

a real PITA to get it back.

I've seen this quite a bit in cases where Adobe RGB (1998) was assumed to be the source profile for digital camera shots. I think this is a bad idea. ColorMatch RGB, or Apple RGB in lieu of a more appropriate profile for that camera, are a far better starting point than Adobe RGB. Digital cameras don't have Adobe RGB behavior, so using it as a source profile is probably not a good assumption. But as this has already been discussed I'll leave it at that.

Chris Murphy

Color Remedies (TM)

www.colorremedies.com/realworldcolor

___________________________________________________________________________

Date: Fri, 21 Nov 2003 07:19:18 EST

From: Dan Margulis

Subject: Re: Photoshop CS defaults, was: RGB Numbers (round 2)

Chris Murphy writes,

That's always been the default behavior. In Photoshop 6 and 7, the

default Color Settings was set to Web Graphics defaults, which causes

all of the color management policies to be Off by default.

"Web Graphics" was only the default if the print-oriented user ignored several prompts to load something else. But in any event, there's an enormous difference. Web Graphics would alert whenever it encountered an embedded profile. Consequently, when there was a screwup, those in denial about whether embedded profiles would ever catch on had a convenient way to do what they do best, blame the user.

With Photoshop CS, there's no such excuse. The default that most people will use ignores CMYK profiles altogether, no warning, no muss, no fuss. It's a pure and simple acknowledgment of what I said in 1999 about where the failure of this concept in the CMYK community.

Yes, this is what's new. The "General Purpose Defaults" for North

America, Europe, and Japan. The color management policy for RGB is now

Preserve Embedded thus RGB editing spaces will be embedded into files

when saved, and embedded profiles will override the working space

automatically when opening files.

Again, what I recommended in 1998. It is gratifying that Adobe finally sees the light.

The other change is that the rendering intent has been changed to

Perceptual which I think is a bad idea.

Right. I was surprised at this, since earlier this year, a couple of the more prominent Adobe bootlickers announced (in a very gracious way, it must be admitted) that they had been mistaken all these years and that Relative Colorimetric was probably best for most images, thus joining me in a position I have taken since 1998.

I've seen this quite a bit in cases where Adobe RGB (1998) was assumed

to be the source profile for digital camera shots. I think this is a

bad idea. ColorMatch RGB, or Apple RGB in lieu of a more appropriate

profile for that camera, are a far better starting point than Adobe

RGB. Digital cameras don't have Adobe RGB behavior, so using it as a

source profile is probably not a good assumption.

Shhh! Don't tell your color-management friends! Many of them haven't realized the drawbacks of wide-gamut RGBs just yet. What would happen if they have to surrender on this point too, after so many other defeats?

I notice on the ColorSync list that there has been a reversal of position regarding the practicality of profiling cameras, something I was excoriated for being dubious about here only two years ago. Now, it appears that everyone concedes the point. And not only have they reversed their view of Photoshop 5, but most of them have gone beyond mine, which they initially said was reactionary, prehistoric, etc. Not to mention the relatively new acceptance of photographers doing their own CMYK, of profiling proofs rather than presses, of digital cameras as professional-quality instruments, of nonimpact printers as contract proofers, and of emphasizing process control, in all of which areas they are now chasing positions that I've held for a very long time.

Now, granted this cave-in on the embedded profile issue, how would it be if they also started doubting Adobe RGB? In such a disastrous scenario, the entire color management community would actually have morphed completely, and not have a single position that can be distinguished from I stood in 1998. What's next? Will they all grow gray hair and become Margulis clones?

Dan Margulis

___________________________________________________________________________

Date: Fri, 21 Nov 2003 11:53:22 -0700

From: Chris Murphy

Subject: Re: Photoshop CS defaults, was: RGB Numbers (round 2)

On Nov 21, 2003, at 5:19 AM, Dan Margulis wrote:

With Photoshop CS, there's no such excuse. The default that most people will

use ignores CMYK profiles altogether, no warning, no muss, no fuss. It's a

pure and simple acknowledgment of what I said in 1999 about where the failure of

this concept in the CMYK community.

Well, you weren't the only one saying it, but you were in an elite club of people being ignored by Adobe on this front.

And really, the cave-in here is more an admission that the user interface and intelligence in the application is insufficient. Because what we really need, especially in a page layout application, is not wholesale dropping of embedded profiles in CMYK images. What we need is for the application to have a better understanding of what kind of device the CMYK images is going to be printed on. Because if it's a press, or anything that has less than perfect registration, yes we most likely want to discard embedded profiles to avoid automatic repurposing. But in the case where the output device has perfect registration, that isn't the case. It's more often BETTER to repurpose those kinds of images and illustrations. The reasons why we care about channel integrity in CMYK have to do with the mechanical realities of the printing process.

Again, what I recommended in 1998. It is gratifying that Adobe finally

sees the light.

Imagine how much less painful life would have been if we'd just been able to get over this hurdle the easy way instead of the hard way. And how we'd have three versions of Photoshop that behaved sensibly by default instead of just one that's a month old.

And what's kind of perverse is that U.S. Prepress Defaults, where we really need these sane behavior the most instead of something vague like "General Purpose Defaults", *still* has the Preserve policy for CMYK.

Right. I was surprised at this, since earlier this year, a couple of the more

prominent Adobe bootlickers announced (in a very gracious way, it must be

admitted) that they had been mistaken all these years and that Relative

Colorimetric was probably best for most images, thus joining me in a

position I havetaken since 1998.

I don't get it either. If Adobe had come out with an improved SWOP profile, containing a perceptual intent to compensate for the ICC spec's assumption of paper white being L*=100 (resulting in increasingly excessively dark separations the darker the paper white is), then I'd be OK with perceptual as a default while that SWOP profile was also the default. If you want something better, change it. But in actuality, the current SWOP profile produces 1-3% *darker* separations using perceptual. So I think it's just a bad idea.

Shhh! Don't tell your color-management friends! Many of them haven't realized

the drawbacks of wide-gamut RGBs just yet. What would happen if they have to

surrender on this point too, after so many other defeats?

There isn't a problem with wide-gamut RGB. The problem is using them as an assumed source profile when the image came from a digital camera.

Now, granted this cave-in on the embedded profile issue, how would it be if

they also started doubting Adobe RGB? In such a disastrous scenario, the entire

color management community would actually have morphed completely, and not

have a single position that can be distinguished from I stood in 1998. What's

next? Will they all grow gray hair and become Margulis clones?

Oh stop it! You're going to start scaring people! There's no need to be mean, Dan.

Chris Murphy

Color Remedies (TM)

www.colorremedies.com/realworldcolor

________________________________________________________________________

Date: Sat, 22 Nov 2003 03:45:53 -0000

From: "David Kern"

Subject: CMYK Conversion Question

Sorry for this "behind the learning curve" question:

I rarely need to provide CMYK files to clients so I haven't noticed this before but when I do a conversion to U.S. Web Coated Swop V.2 in Photoshop 7.0, it gives me a much different result than in 5.5. In 7.0 the CMYK remains fairly close to the RGB ( except for absolute colorimetric--which is drastic). Whenever I did a conversion in 5.5 I had to do a lot of tweaking to the image because the conversion ( to the same CMYK settings) always made it much darker, contrastier and with a color shift.

David Kern

___________________________________________________________________________

Date: Sat, 22 Nov 2003 12:52:45 -0500

From: Lee Clawson

Subject: Re: Photoshop CS defaults, was: RGB Numbers (round 2)

Chris,

.... Because if it's a press, or anything that has less than perfect

registration, yes we most likely want to discard embedded profiles to avoid

automatic repurposing.

What is "automatic repurposing" ???

Lee

___________________________________________________________________________

Date: Sat, 22 Nov 2003 11:07:56 -0800

From: Doug Walker

Subject: Re: Photoshop CS defaults, was: RGB Numbers (round 2)

On Friday, November 21, 2003, at 04:19 AM, Dan Margulis wrote:

Shhh! Don't tell your color-management friends! Many of them haven't realized

the drawbacks of wide-gamut RGBs just yet. What would happen if they have to

surrender on this point too, after so many other defeats?

Dan

Is this where a digital camera shots had no profile associated with it, and so it was assumed?

Is there any connection to those of us using D1x who CHOOSE Nikon Adobe RGB?

Thanks for clarification.

Doug Walker, FP

"Specializing in People on Location in a Clean, Bold Classic Style!"

website: http://www.walkerphoto.com

Member, PPW, ASMP, APA SF

___________________________________________________________________________

Date: Sun, 23 Nov 2003 15:34:41 EST

From: Dan Margulis

Subject: Re: Photoshop CS defaults, was: RGB Numbers (round 2)

Doug writes,

Is this where a digital camera shots had no profile associated with it,

and so it was assumed? Is there any connection to those of us using D1x who

CHOOSE Nikon Adobe RGB?

As I noted in the initial post, all I know is that the images were shot digitally in a studio, and that we were presented with CMYK files. Having seen the effect many times before, however, (and Chris Murphy says the same thing) I surmised that the RGB files had been in Adobe RGB and, whether in the initial exposure or in some subsequent RGB correction, many objects wound up outside of the CMYK gamut.

If you're asking whether they just randomly assigned Adobe RGB to images, I don't think so. If that were the case, everything would have looked garish and dark. These images were basically OK except when there were brilliantly colored objects.

There's definitely a connection to your work. In Adobe RGB workflows for a CMYK destination, you have to be very watchful for images that have critical objects that are out of the CMYK gamut. It's much easier to have this problem in Adobe RGB than in the three other "official" RGB definitions. If you send a file into CMYK that's not colorful enough, it's easy to fix it in CMYK. If the file is so colorful that all detail is wiped out during the transition, it'll take an expert to make it look right afterward.

The solution when you identify such files is to apply a false sRGB profile to them before converting into CMYK. That may make the file look worse on your screen, but it will look *better* than the Adobe RGB version even immediately after conversion. And if the client isn't happy with the printed product he won't be interested in what the file used to look like when it was in RGB.

Dan Margulis

___________________________________________________________________________

Date: Mon, 24 Nov 2003 10:11:57 -0700

From: Chris Murphy

Subject: Re: Photoshop CS defaults, was: RGB Numbers (round 2)

On Nov 22, 2003, at 10:52 AM, Lee Clawson wrote:

What is "automatic repurposing" ???

A conversion intended to preserve the color appearance of a file, by changing the numeric values in the file, that occurs without prompting the user. It's effectively an automatic reseparation, or automatic conversion.

I use the term automatic repurposing, because the color is correct after such a conversion. From a theoretical point of view, automatically repurposed files are exact what we need and want. But from a practical view, printing presses have behavior that must be dealt with in ways that conventional color management cannot handle (DeviceLinks can, to a great degree do this, but they're rare and do not depend on embedded profiles).

Chris Murphy

Color Remedies (TM)

www.colorremedies.com/realworldcolor

___________________________________________________________________________

Date: Mon, 24 Nov 2003 10:21:23 -0700

From: Chris Murphy

Subject: Re: Photoshop CS defaults, was: RGB Numbers (round 2)

On Nov 23, 2003, at 1:34 PM, Dan Margulis wrote:

There's definitely a connection to your work. In Adobe RGB workflows for a

CMYK destination, you have to be very watchful for images that have critical

objects that are out of the CMYK gamut. It's much easier to have this problem in

Adobe RGB than in the three other "official" RGB definitions. If you send a

file into CMYK that's not colorful enough, it's easy to fix it in CMYK. If the

file is so colorful that all detail is wiped out during the transition, it'll

take an expert to make it look right afterward.

If important detail hasn't been obliterated in the process.

Perceptual rendering, in a case like this can be helpful, as this is exactly what it is suited for. But because of the lack of intelligent gamut mapping (it's a one size fits all thing), and especially the profiles supplied by Adobe which have very similar rendering intent behavior, this work around is only partial, and depends on the how the profile was built.

Chris Murphy

Color Remedies (TM)

www.colorremedies.com/realworldcolor

___________________________________________________________________________

Date: Tue, 25 Nov 2003 08:28:45 -0000

From: Stephen Marsh

Subject: Re: Photoshop CS defaults, was: RGB Numbers (round 2)

Chris Murphy writes:

Perceptual rendering, in a case like this can be helpful, as this is

exactly what it is suited for. But because of the lack of intelligent

gamut mapping (it's a one size fits all thing), and especially the

profiles supplied by Adobe which have very similar rendering intent

behavior, this work around is only partial, and depends on the how the

profile was built.

For those using SWOP TR001, Chromix also freely offer to members a series of different GCR/UCR and ink weight at their ProfileCentral site - but it has been down of late.

This has the same colorimetric data as the Adobe SWOP profiles (when measuring AbsCol CMYK to LAB values) - but they do have more 'unique' behaviour than the more tame Adobe SWOP v2 profile.

Stephen Marsh.

___________________________________________________________________________

Date: Wed, 26 Nov 2003 11:24:21 EST

From: Dan Margulis

Subject: Re: Photoshop CS defaults, was: RGB Numbers (round 2)

Chris Murphy writes,

Perceptual rendering, in a case like this can be helpful, as this is

exactly what it is suited for. But because of the lack of intelligent

gamut mapping (it's a one size fits all thing), and especially the

profiles supplied by Adobe which have very similar rendering intent

behavior, this work around is only partial, and depends on the how the

profile was built.

Right. Separation algorithms have to compress the amount of space allowed to colors that were out of gamut in RGB, otherwise 99.9 percent of all resulting pictures would look gray and rancid. The only question is, how much. The relative colorimetric method that's now recommended for most images basically answers, as much as possible. So, if you have important OOG colors, this method is likely to hose them, but other colors will be reproduced more accurately.

This "perceptual" idea is not to suppress OOG contrast so much, at the price of somewhat flatter colors elsewhere. The problem, as Chris indicates, is that there's no agreement on how much "somewhat" means. In the Photoshop profiles, there's very little difference, hence I don't even discuss it in classes because it wouldn't be a problem to adjust a "RelCol" sep to match a "Perceptual" one.

Profiles from other vendors might conceivably be a different story, but even so, for this set of images we'd need something really drastic, because these would be in the .1 percent of images where no compression at all of the OOG colors might work. IOW, we'd have been better off if the photographer had just opened up a blank CMYK document and pasted the R,G,B into the C,M,Y, rather than try to convert from Adobe RGB through any known CMYK profile. I guess we'd need something called "Super-Perceptual" but there's not much chance of that.

The key here is to understand that it isn't a CMYK problem or a separation algorithm problem. It's an RGB problem, where too many critical areas of the image were, in Adobe RGB, way outside the CMYK gamut. Adobe RGB users need to learn to recognize this narrow class of images, and know how to bail out of Adobe RGB on them before making the switchover.

Dan Margulis

___________________________________________________________________________

Date: Wed, 26 Nov 2003 12:11:46 -0700

From: Chris Murphy

Subject: Re: Photoshop CS defaults, was: RGB Numbers (round 2)

On Nov 26, 2003, at 9:24 AM, Dan Margulis wrote:

This "perceptual" idea is not to suppress OOG contrast so much, at the price

of somewhat flatter colors elsewhere. The problem, as Chris indicates, is that

there's no agreement on how much "somewhat" means.

And "somewhat" chances depending on the colors in question, depending on the image itself, depending on the source space, and the destination space, and what in the image is important and what you're willing to sacrifice. This is so far beyond current color management to handle that it would be like driving the space shuttle with the steering column of a tricycle. It's just insufficient to the task (not that it claims to be able to do it, but that's beside the point.)

Profiles from other vendors might conceivably be a different story, but even

so, for this set of images we'd need something really drastic, because these

would be in the .1 percent of images where no compression at all of the OOG

colors might work. IOW, we'd have been better off if the photographer had just

opened up a blank CMYK document and pasted the R,G,B into the C,M,Y, rather than

try to convert from Adobe RGB through any known CMYK profile. I guess we'd

need something called "Super-Perceptual" but there's not much chance

of that.

My memory has failed me on the name of the product acquired by Pictographics that had a kind of workaround for this. It was a profile building application that allowed the user to select a source space, and build an output profile's gamut compression contingent on that source space. So you could build a profile that was geared to handle Adobe RGB (1998) images - of course sacrificing somewhat its ability to render from other sources.

Again this is still a one size fits all, in that the same amount of gamut compression would apply to all Adobe RGB images (or whatever the source space was when building the output profile) equally. Current technology doesn't do image analysis to dynamically compress the gamut. But this kind of workaround is certainly better than what we have now, in my opinion, which involves a much broader assumption. And we know what can happen when assumptions are made.

Chris Murphy

Color Remedies (TM)

www.colorremedies.com/realworldcolor

___________________________________________________________________________

Date: Sat, 29 Nov 2003 15:40:05 -0800

From: Doug Walker

Subject: Re: Photoshop CS defaults, was: RGB Numbers (round 2)

On Friday, November 21, 2003, at 04:19 AM, Dan Margulis wrote:

Shhh! Don't tell your color-management friends! Many of them haven't realized

the drawbacks of wide-gamut RGBs just yet. What would happen if they have to

surrender on this point too, after so many other defeats?

Dan,

Would you mind expounding upon this just a bit more?

Is this what you refer to as an 'out of gamut' problem for images where most of the critical image is out of gamut?

Doug Walker, FP

___________________________________________________________________________

Date: Tue, 2 Dec 2003 12:24:29 EST

From: Dan Margulis

Subject: Re: Photoshop CS defaults, was: RGB Numbers (round 2)

Doug Walker writes,

Dan,

Would you mind expounding upon this just a bit more?

Is this what you refer to as an 'out of gamut' problem for images where

most of the critical image is out of gamut?

While wider-gamut RGB definitions have certain advantages, we have had a number of discussions of some of their drawbacks in the last year or so. Without rehashing these totally, the basic problems are, as you mentioned, devotion of too much space to colors that can't be printed or in some cases even displayed correctly on the monitor; channels that are excessively volatile in their effect on the image, making accurate color correction difficult; and the necessity of monitoring what happens to the file if it ever leaves your hands because a misinterpretation of a wider-gamut RGB file by someone else is likely to be disastrous.

For these reasons, I personally feel that for a skilled user, if the final destination of the file is CMYK, Adobe RGB is the poorest choice of the four major RGBs. Beginners may get better results with Adobe RGB, however, because it tends to create a more colorful result.

The remark that you quoted merely called attention to the fact that most color management advocates, being sRGB-phobic, haven't yet adopted this view, although in almost all other respects the conventional color management wisdom has come around to occupying positions I held more than five years ago.

Dan Margulis

___________________________________________________________________________

Date: Tue, 02 Dec 2003 15:00:15 -0500

From: Terry Wyse

Subject: Re: Photoshop CS defaults, was: RGB Numbers (round 2)

on 12/2/03 12:24 PM, Dan Margulis wrote:

The remark that you quoted merely called attention to the fact that most

color management advocates, being sRGB-phobic, haven't yet adopted this view,

although in almost all other respects the conventional color management wisdom has

come around to occupying positions I held more than five years ago.

I think it's a matter of context. In the last 5-6 years that I've been reading anything I can get my hands on about color management and as a "practicing" color management idiot/consultant for the last 3-4 years, I can't recall anybody advocating wide-gamut RGB spaces to the exclusion of all others. It's ALWAYS been a matter of choosing your RGB working space based on a "capture-centric" viewpoint (keep ALL the original color data because you NEVER KNOW when you might need it) versus an "output-centric" view that sez "why keep all the extra 'color' if I'm never going to use it?". Both are right and have merit in my view. The first knows that, going in, they won't get all that color on output and furthermore don't have the ability to even SEE all the color given the current state-of-the-art with displays. The second knows that, while they have the "comfort" of working in a space that better fits what they can print and display, they're losing a lot of flexibility should different output options present themselves. Any "good" color management consultant or savvy end-user should know this and either understand their workflow or explain to their client what sorts of compromises they will be making with EITHER approach. It's rarely a one size-fits-all proposition when you're dealing with clients that range anywhere from offset print production to digital photo studios to museums capturing art. Personally, I think a case can be made for a 16-bit Lab "digital master" (think of it as the transparency) that gets archived and a production/working file that gets brought into something like ColorMatchRGB (and, yes, even sRGB!) as an editing space in preparation for CMYK output.

One example would be my current digital camera "workflow" with my Sigma SD-9. When I started with this camera, I would convert from RAW (X3F file) to Adobe RGB and had lot's of problems with fleshtones. I'm now using ColorMatchRGB has my space of choice because I feel I get better results. It could very well have to do with the fact that ColorMatchRGB is a very good fit to my monitor's color space as opposed to any notion of AdobeRGB being inferior in some way. The point is, for my work with this camera (inkjet photo printing), ColorMatch gives me what I'm looking for and is easy to work with. On the other hand, I'd like to think monitors will get better and we'll have wider-gamut output choices in the future, which is why, in my case, I ALWAYS save/archive the raw file in case that happens. So I work in an "output-centric" mode but I still keep one eye on the "capture-centric" view because, well, you NEVER KNOW.... :-)

Cheers,

Terry

__________________________________

WyseConsul

Color Management Consulting

v 704.843.0858

__________________________________

___________________________________________________________________________

Date: Tue, 02 Dec 2003 22:29:41 +0000

From: Martin Orpen

Subject: Re: Photoshop CS defaults, was: RGB Numbers (round 2)

on 2/12/03 8:08 pm, Dan Margulis wrote:

The remark that you quoted merely called attention to the fact that most

color management advocates, being sRGB-phobic, haven't yet adopted this view,

although in almost all other respects the conventional color management wisdom

has come around to occupying positions I held more than five years ago.

I think you have to distinguish between different types of colour management advocates Dan :-)

Those of us that have to work with CMYK - films and Cromalins and everything - are well aware of the problems of getting good separations from *wider gamut* RGBs.

The maligned sRGB colour space might be small, but if you want detail in red clothing and your model is looking a bit flushed it's a hell of a lot better than AdobeRGB1998.

For anybody interested in reading more about this stuff, we've been transferring (and updating) some examples from our old web site to a new php-based site. One of the pages that was copied over today is called "Why I hate 98" and can be reached via this link:

http: //prometheus.idea-digital.com/phpbb2/viewtopic.php?t=61

You have to register to read it but there's plenty of stuff there to make it worthwhile and we are copying more information over on a daily basis :-)

Martin Orpen

Idea Digital Imaging Ltd -- The Image Specialists

http://www.idea-digital.com

___________________________________________________________________________

Date: Tue, 02 Dec 2003 16:25:05 -0700

From: Andrew Rodney

Subject: Re: Re: Photoshop CS defaults, was: RGB Numbers (round 2)

Cromalins ... Ugh.

I1ve produced more images using Adobe RGB (as have my clients) to print then I can shake a stick at. There1s nothing inherently dangerous about this space than any other space IF (big if) you know what you1re doing and you use proper color management. Yes, the space is larger than CMYK gamut but then sRGB (and even ColorMatch RGB) can1t fully contain the CMYK gamut. IF getting full saturation cyan's and greens is important, you1re going to have to find something larger than sRGB! In fact, most capture devices are far wider than all the spaces so far discussed. Do you really think the high end drum scanners of past where really unable to capture wide(er) gamut than what they pushed out the back end? With the on the fly conversions into CMYK, done correctly, no worries. Same with taking Adobe RGB (or even a wider gamut RGB file) and converting. Upside is that IF you ever need to go out to a wider gamut printer, you1ve got the original data. That1s nice to have.

There1s no question that sRGB has gotten a bum rap. Some make it sound as if you1re going to get pure junk if a file ends up in this space. That1s simply as inaccurate as suggesting that a wide gamut RGB space will produce junk in the right hands. Taking a file that isn1t Adobe RGB and calling it that (or take a file that is Adobe RGB and tag it differently) WILL produce really bad color. But a mistake is a mistake and it1s not the cause of the colorspace.

Yes, there are some colors that fall outside Adobe RGB that your display can1t show you (although NEC Mitsubishi Japan has announced a 22" CRT monitor which is said can be calibrated to Adobe RGB color space/gamut). Give the choice between funneling a file into a space that insures I can't fully reproduce it on any number of devices verses not seeing some areas on screen, I'll take the larger space. I like to keep my options open.

There is absolutely no reason, given good conversions from either space why one should produce better detail than the other. If you're seeing flushed skintones, it's due to an incorrect assignment of the numbers in the first place. Assign Adobe RGB to a file that's really sRGB and you'll get butt ugly skin tones. But then that's a totally incorrect way to handle the file so I don't see how Adobe RGB is at fault.

FYI, Adobe didn't invent Adobe RGB (at least not on purpose). Those who recall a space called SMPTE-240m in the original 5.0 version of Photoshop should know that it soon after got renamed to Adobe RGB when SMPTE informed Adobe that two of the chromaticity values they themselves placed on their website specifying this space were incorrect! Fortunately much testing proved (and continues today to prove) that the mix up produced a well behaved editing space none the less. In the following dot release, Adobe had no choice but to rename the space since it wasn't really SMPTE-240m.

It might be politically popular to call either Adobe RGB (or elsewhere sRGB) bad spaces but the facts are, there are no perfect Working Spaces. All the working spaces will produce really ugly final output if handled incorrectly. What we want is a space that can at the very least contain all the colors we hope to eventually reproduce.

Andrew Rodney

http://www.imagingrevue.com/

___________________________________________________________________________

Date: Wed, 03 Dec 2003 00:30:03 +0000

From: Martin Orpen

Subject: Re: Photoshop CS defaults, was: RGB Numbers (round 2)

on 2/12/03 11:25 pm, Andrew Rodney wrote:

I1ve produced more images using Adobe RGB (as have my clients) to print then

I can shake a stick at. There1s nothing inherently dangerous about this

space than any other space IF (big if) you know what you1re doing and you

use proper color management. Yes, the space is larger than CMYK gamut but

then sRGB (and even ColorMatch RGB) can1t fully contain the CMYK gamut. IF

getting full saturation cyan's and greens is important, you1re going to have

to find something larger than sRGB!

You'll note that my beef with AdobeRGB1998 is with reds - not cyan and green. And because we deal with images the sometimes have people in them, this is a rather important bit of the colour spectrum for us.

Nobody's that bothered if the grass is a bit of an odd colour - a supermodel with sunburn is a different matter.

In fact, most capture devices are far

wider than all the spaces so far discussed. Do you really think the high end

drum scanners of past where really unable to capture wide(er) gamut than

what they pushed out the back end? With the on the fly conversions into

CMYK, done correctly, no worries. Same with taking Adobe RGB (or even a

wider gamut RGB file) and converting. Upside is that IF you ever need to go

out to a wider gamut printer, you1ve got the original data. That1s nice to

have.

We've got the benefit of still having high-end drum scanners right here in the studio. And like the true *calibrationists* that we are, we make our own profiles with *monster-sized* gamuts.

But my problems with AdobeRGB1998 arise from images that are supplied to us - not those that we create (with the exception of negatives which are another good reason to avoid wide gamut RGB spaces - but that's another story).

There1s no question that sRGB has gotten a bum rap. Some make it sound as if

you1re going to get pure junk if a file ends up in this space. That1s simply

as inaccurate as suggesting that a wide gamut RGB space will produce junk in

the right hands. Taking a file that isn1t Adobe RGB and calling it that (or

take a file that is Adobe RGB and tag it differently) WILL produce really

bad color. But a mistake is a mistake and it1s not the cause of the

colorspace.

This may be true.

But for the sake of argument I'd be willing to state that you are more likely to get a better result from sRGB to CMYK than from AdobeRGB1998 to CMYK from a bunch of randomly selected untagged RGB originals.

It's far easier to saturate and add contrast than it is to try and rescue detail from solid areas.

There is absolutely no reason, given good conversions from either space why

one should produce better detail than the other. If you're seeing flushed

skintones, it's due to an incorrect assignment of the numbers in the first

place. Assign Adobe RGB to a file that's really sRGB and you'll get butt

ugly skin tones. But then that's a totally incorrect way to handle the file

so I don't see how Adobe RGB is at fault.

It's at fault because it's so difficult to make the judgement from the screen rendition that you've pushed the reds too far. Few of my clients are watching the numbers and more often than not the skin tones and detail in reds suffer.

What you say is true - but you're having to make too many provisos: "given good conversions"; "if you know what you're doing"; "using proper colour management" etc.

This stuff goes out the window on a Friday afternoon when the ad deadlines are looming and we've got no control over the images that are supplied to us.

It might be politically popular to call either Adobe RGB (or elsewhere sRGB)

bad spaces but the facts are, there are no perfect Working Spaces. All the

working spaces will produce really ugly final output if handled incorrectly.

What we want is a space that can at the very least contain all the colors we

hope to eventually reproduce.

So what RGB space would you suggest for people who are producing images that will be primarily reproduced in European magazines? (and what CMYK space for that matter? - Photoshop seems to be sadly lacking in both areas.)

Martin Orpen

Idea Digital Imaging Ltd -- The Image Specialists

http://www.idea-digital.com

___________________________________________________________________________

Date: Tue, 2 Dec 2003 17:59:53 -0700

From: Chris Murphy

Subject: Re: Photoshop CS defaults, was: RGB Numbers (round 2)

Considering that the problem has only been talked about in earnest for the past year, and that vastly more people have a fine and dandy experience with Adobe RGB (1998) than they have problems with it, I still think it is a good editing space to use. That one needs to be vigilant with respect to high saturation areas with fine detail is really not anything new, just that we have a more recent reminder that this problem becomes increasingly greater the larger the editing space gamut is.

But I do agree that wide gamut RGB spaces are recommended more often by those using color management. This makes sense. These people can take advantage of such wider gamut spaces, despite the possibility of getting bitten every now and then. That there was also a big rush to negatively judge sRGB I don't think is in dispute either. From a traditional print perspective, it's unlikely that sRGB is really going to negatively impact your work and by design Photoshop still has the ability to show you what you're going to get (or not get) if sRGB is your editing space.

There is clear value in wide gamut RGB spaces. NEC has a monitor available in the Japanese market that has Adobe RGB (1998) primaries. It stands to reason that as output devices increasingly have wider gamuts, that our displays will need to have them also. The problem, as I see it, is that the industry is finding color management as it exists today to be unsophisticated enough. It's conversions are good, but they're not at all intelligent. The conversions allow the potential for serious damage to occur in the course of conversion, by way of important detail being dropped. There are both short term and long term work arounds for this problem, but I don't really see the industry moving toward either at this point.

Anyone worked with e-sRGB yet? There's a whacky fun color space.

Chris Murphy

Color Remedies (TM)

www.colorremedies.com/realworldcolor

___________________________________________________________________________