Dan Margulis Applied Color Theory - Ancient Custom Color

Date: Wed, 15 May 2002 22:15:40 -0400
From: Jonathan Clymer
Subject: Ancient custom color dialogs

In a recent post in the Adobe Photoshop forum, an Adobe employee said:

"you really shouldn't be using the custom color dialogs. They're ancient,
and not nearly as accurate as current ICC based profiling tools."

This doesn't sound very practical for one thing, but apart from that, how
ancient can it be?

Jonathan Clymer


Date: Thu, 16 May 2002 08:53:18 -0000
From: "marshyswamp71"
Subject: Re: Ancient custom color dialogs

--- In colortheory@y..., Jonathan Clymer wrote:
> In a recent post in the Adobe Photoshop forum, an Adobe employee said:
>
> "you really shouldn't be using the custom color dialogs. They're ancient,
> and not nearly as accurate as current ICC based profiling tools."
>
> This doesn't sound very practical for one thing, but apart from that, how
> ancient can it be?

This is true in some respects - but far from the best advice for all users.

This question very much depends on your skill level, workflows and other variables which change from person to person.

From Photoshop 2.5 to 4 I don't think the settings changed...Photoshop 5 reinvented dot gain, with 20% from v4 being around 12% in version 5 when the 'same', 'new' 20% figure was chosen. Not sure of any other changes...Photoshop 6 and 7 did not change anything else with custom CMYK built in tables, if I recall correctly (apart from on the fly generation of them as ICC profiles when you make changes to them, since v6 or 7 uses ICC for all tasks).

I do not surf the Adobe forums much, I can't be bothered joining and I get frustrated when I read many of the posts that go on there.

Many people tell you that the built in settings are crap - but I would bet that these same people have little or no practical expereience in the real print world, or have not experienced the many things which may be required of a serious prepress production user.

Both built in settings and proper profiles both have pros and cons, the more you use and learn about both formats - the more you see that each have their place, depending on the workflow and task at hand.

For the sake of argument...even though I currently use a proper ICC profile for producing targeted seps for our common conditions -if the next version of Photoshop did not include custom CMYK then I would _not_ upgrade...this feature is that critical for advanced users or users who need flexibility and far from useless or legacy.

Long live the built in custom CMYK settings.

If anyone doubts how useful the old built in settings are, try this...make a vector EPS using solid black or 400% CMYK in Illus, FreeHand, Quark etc...or even just some tint patches of 10, 20, 30% etc. Make sure that an 'accurate', 'better' proper ICC profile is set as your workspace. Now rasterize the EPS to grayscale mode or CMYK depending on the source test...and see if you can get a proper ICC profile to rasterize your vector elements with correct colour values...go on, I dare you.<g> Granted not everyone rasterizes vector files, but for those that do this is a big issue.

What is better, using a 'proper' profile that has incorrect dot gain, or using a 'poor' custom CMYK built in setting which has correct dot gain but may not offer softproofing or perceptual renders? To me having control of the dot gain and other settings matters more than whether the separation is produced by a proper ICC profile.

This has come up in the past, perhaps try searching for keywords such as built-in CMYK etc.

Regards,
Stephen Marsh.


Date: Thu, 16 May 2002 06:40:23 -0500
From: Bob Smith
Subject: Re: Re: Ancient custom color dialogs

marshyswamp71 wrote:

> To me
> having control of the dot gain and other settings matters more than
> whether the separation is produced by a proper ICC profile.

Which to me sort of begs the question... Why doesn't Adobe go the rest of the way and turn the color settings into a more full fledged profile generating/editing system? By that I mean one that saves out a proper profile with rendering intent options; and possibly allows importing some third party profile for tweaking using the the existing color settings interface. At the very least this gives a person whose knows Photoshop color settings a familiar way of seeing what's under the hood of some unknown profile generated by third party software. Doing so would add tremendous capability to an already versatile system; and it would probably lower the level of some of the profile wars that erupt here from time. It doesn't seem like Adobe is that far away from being able to do this (easy for a non-programmer to say!)

Bob Smith


Date: Thu, 16 May 2002 09:27:30 EDT
From: Dan Margulis
Subject: Re: ancient custom color

Jonathan writes,

>>In a recent post in the Adobe Photoshop forum, an Adobe employee said:
"you really shouldn't be using the custom color dialogs. They're ancient, and not nearly as accurate as current ICC based profiling tools.>>

Nobody is a particular fan of the inflexible and inaccurate built-in Photoshop engine. However, a viable alternative is needed before it can be abandoned. At the moment, virtually all high-end CMYK users employ it, in spite of its disadvantages.

The reason is that the ability to edit profiles easily is an absolute prerequisite. Confronted with the choice between an elderly method that allows us to change dot gain and black generation easily, and method with more potential that requires us to hire a consultant and/or buy additional software to modify the profile, it's not hard to figure out what knowledgeable users will do.

Adding a generalized profile editor to Photoshop would not be all that hard. It's something I've been advocating since Photoshop 5. Unfortunately, the development team was too busy figuring out ways to make life hard for users of digital cameras to implement it this time. Perhaps in Photoshop 8.

Dan Margulis


Date: Thu, 16 May 2002 07:45:27 -0600
From: Andrew Rodney
Subject: Re: Re: ancient custom color

on 5/16/02 7:27 AM, Dan Margulis wrote:

> Adding a generalized profile editor to Photoshop would not be all that hard.
> It's something I've been advocating since Photoshop 5. Unfortunately, the
> development team was too busy figuring out ways to make life hard for users
> of digital cameras to implement it this time. Perhaps in Photoshop 8.

Here Dan and I are in TOTAL agreement. I want to have total control over profile editing in Photoshop (I can do it in Linocolor). I1ve been begging the Adobe team for this option for years. In fact I had a long conversation (most of which I couldn1t totally follow) with Photoshop1s dad, Thomas Knoll. There is no question that Adobe can allow us the ability to edit profiles. But Thomas had reservations about allowing users to edit pre-existing profiles since there would be cases where the results would not be up to Thomas1s standards of quality and he is at the mercy of the pre-existing quality of the profile. At least that was how I took his take on the reasons Adobe wasn1t rushing to allow profile editing.

I think this needs to be a feature of Photoshop 8! I don1t know how many features the team has come up with in their heads to convince people to upgrade when the next version comes out but I1d bet that more users who deal with color would want a way to edit profiles and have more control over the older 3built in2 CMYK settings (which by the way ARE ICC profiles since Photoshop 5).

While some may want to put down the built in controls in Photoshop, keep in mind that these tools do provide a level of control you can1t find in some high end proprietary packages like the ability to set dot gain (that1s usually done when measuring targets and the user has no actual control over this). I think that if Adobe wants to be at the forefront of desktop color (with ICC profiles), we need the ability to use Photoshop1s superb toolset to edit more than just images. We need that toolset to edit profiles.

Oh, as far as the comment about digital cameras, let1s put the blame not on the host application that reads file data but the original product that places the incorrect data in the file!

Andrew Rodney


Date: Thu, 16 May 2002 11:48:07 -0400
From: Scott Olswold
Subject: RE: Re: ancient custom color

Andrew and others who are currently salivating at the thought,

Aside from not having to spend some pocket change, I don't see how a profile editor "fits" within the Photoshop objective: preparing/creating images for print/web. Don't get me wrong, I'm a tried and true color geek and I can spend an inordinate amount of time futzing with a profile, trying to maximize its efficacy for a wide range of input colors, gray balance, etc. Since profile editors exist in the mainstream, I'm not quite sure how Mr. Knoll's comment works (if I shove a poor profile in Photoshop or open it in an editor, it'll still be garbage, Thomas' standards or not--with all due respect to Mr. Knoll), except that Photoshop remains inviolate and rather "hold harmless" in the whole process.

Frankly, it just serves to muddy Photoshop's position: is it an image editor, a profile editor, or both? Would we create a splinter group who wish to exploit the profile editor and then complain that the "image editing features" make the program a resource hog (or vice versa)? My opinion (as unesteemed as it may be to some of you) is that you leave the profile editing software developement up to the folks at Gretag et al., and just let Photoshop keep using these edited profiles in a fashion consistent with their intended design and purpose.

Requisite Color Theory content: In Photoshop 5.x, once you make the changes in the Built-in setup you have to move over to Tables (it retains your changes in Built-in) in order to make an ICC-compliant profile.

Scott Olswold


Date: Sat, 18 May 2002 17:24:41 -0600
From: Chris Murphy
Subject: Re: Re: ancient custom color

Jonathan Clymer, jeclymer@bellatlantic.net writes:

>"you really shouldn't be using the custom color dialogs. They're ancient,
>and not nearly as accurate as current ICC based profiling tools."
>
>This doesn't sound very practical for one thing, but apart from that, how
>ancient can it be?

It's pretty ancient, and it has a number of limitations and bugs that can cause some pretty serious problems, but for the most common kinds of output processes it's geared for - press output - if you give it the correct data, it will make good relative colorimetric (with black point compensation) conversions and on-screen previews. I would even argue that for well behaved press conditions, with accurate data sampled and input into Photoshop's custom CMYK setup, is capable of outperforming come current ICC based profiling tools.

Andrew Rodney writes:
>Oh, as far as the comment about digital cameras, let1s put the blame not on
>the host application that reads file data but the original product that
>places the incorrect data in the file!

There's a lot of blame to go around. What Adobe has done with Photoshop 7 is make it quite a bit more hostile to color management, and has done so by default. What's clear to me as a result of this change in behavior is that the OFF policy is the wrong default policy by virtual of Web Graphics Defaults being the default settings used in Photoshop 7.

Applications are getting more complex due to features being added to make them a jack of all trades, catering to as wide an audience as possible. This results in the apps having dangerous or useless options for certain industries. I feel Adobe needs to have a dialog pop-up the first time an application is used and asks you what you're using it for, and it then disables all the naughty stuff you shouldn't be using (like insane transparency and animation effects in Illustrator for example, if you are in print-centric graphics).

For the print centric graphic arts, a much more reasonable default settings would be ColorMatch RGB for the working space, Preserve Embedded Profiles for all policies, and uncheck all of the ask when opening/ask when pasting dialogs. This set of settings, while not ideal for everyone is less inconvenient, and less dangerous, than Web Graphics being the default. U.S. Prepress Defaults is asking too much of end users who really don't want to be involved in color management issues. And the OFF policy is simply ineffective except for web graphics.

The digital camera vendors have been suckered into using sRGB in order to get little MicroSoft 2000 and XP product stickers on their boxes. These vendors basically need to decide if they are going to be in the service of their customers or that of MicroSoft. Or at the very least come up with a creative way to do both - as right now they are totally dropping the ball.

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


Date: Sun, 19 May 2002 13:28:07 EDT
From: Dan Margulis
Subject: Re: ancient custom color

Chris Murphy writes,

>>There's a lot of blame to go around. What Adobe has done with Photoshop 7 is make it quite a bit more hostile to color management, and has done so by default.>>

I for one am tired of hearing other companies blamed whenever Adobe's careless programming breaks their product.

With respect to the problem with camera profiles, if I am interpreting a recent statement by Chris Cox correctly, Adobe now recognizes that *all* EXIF profiles are currently wrong. If we know that they're always wrong, what on earth is Adobe doing making it mandatory that we honor them? This is an obvious failure to research before implementing.

Plus, there's huge variation between individual cameras even of the same model. If we force the camera vendors to put some arbitrary tag on their files, it may be better than sRGB but it's still going to be wrong for many of their cameras and it will still be a PITA for users of Photoshop 7 until Adobe gets a fix out.

If an Adobe manager were driving at 120 mph and smashed into a parked car, a lot of Adobe programmers and affiliated bootlickers would say, it's obviously the fault of the parked car, because its owner didn't put a nickel in the parking meter.

The blame game, however, is irrelevant. What we need is a fix for this from Adobe as quickly as possible.

Dan Margulis


Date: Sun, 19 May 2002 17:46:20 -0600
From: Andrew Rodney
Subject: Re: Re: ancient custom color

on 5/19/02 11:28 AM, Dan Margulis wrote:

> With respect to the problem with camera profiles, if I am interpreting a
> recent statement by Chris Cox correctly, Adobe now recognizes that *all* EXIF
> profiles are currently wrong.

Chris will have to set his record straight here. But from my perspective, NO camera actually shoots into sRGB but many camera manufacturers are doing their best to funnel color to something close to sRGB. That being the case, the EXIF 3profile2 is wrong simply because sRGB and what comes off a digital camera are different. But they are close enough for a lot of users who need SOME kind of definition of the RGB data.

We have only a few options here. The data is accurately described by a profile. That means a custom profile because as Dan points out, all cameras, even those made from the same company on the same day are different from each other. So that means a user can only get a truly accurate definition by spending some money and a good deal of time building a profile. For a lot of users, that1s simply not a viable solution. So what1s the next best thing? Funnel the color into something close to a defined RGB Working Space and sRGB seems to be the choice definition these manufacturers are shooting for (we can debate that this isn1t a good idea but that1s what1s happening).

The last option isn1t a good one. Simply supply untagged RGB data in a space that isn1t anything known and let users guess and thus complain about the color when they bring the file into Photoshop as Photoshop can1t produce an accurate preview. This is exactly what happened with some of the first generation digital cameras after Photoshop 5 arrived. The Nikon D1 provided the users with RGB data (untagged) that basically looked awful with any RGB Working Space. Produce a custom profile for D1 data and the files look and output just fine.

> If we know that they're always wrong, what on
> earth is Adobe doing making it mandatory that we honor them? This is an
> obvious failure to research before implementing.

Many camera manufacturers decided to funnel the data into something reasonable (?) close to sRGB and place that tag in the EXIF data. Photoshop didn1t put that there, it only reports what is being provided in the EXIF data. That the data isn1t really sRGB and that the camera manufacturers place a tag in their files should be the issue.

> Plus, there's huge variation between individual cameras even of the same
> model. If we force the camera vendors to put some arbitrary tag on their
> files, it may be better than sRGB but it's still going to be wrong for many
> of their cameras and it will still be a PITA for users of Photoshop 7 until
> Adobe gets a fix out.

The problem is that to get the best possible color, we need an accurate descriptor of the RGB values. So the options are a 3canned profile2 (which the EXIF data is using; sRGB), a custom profile (costly and time consuming) or no profile (chaos).

Users of Photoshop 7 can honor the EXIF tag and decide if what they now get is good or not. If it1s not good, then they have to decide if they want to build a custom profile, edit sRGB using Dan1s 3False Profile2 technique (which I think is the first step since it1s free) or simply ignore the EXIF data and play around until they find some profile that produces reasonable color. SOME profile has to be tagged (or assumed which is what happens when you ignore and strip out a profile). Photoshop can1t work without using some description of the RGB or CMYK data in a file. That descriptor is either right or its wrong. Photoshop only reports what is in the file
>
> If an Adobe manager were driving at 120 mph and smashed into a parked car, a
> lot of Adobe programmers and affiliated bootlickers would say, it's obviously
> the fault of the parked car, because its owner didn't put a nickel in the
> parking meter.
>
Dan, it1s possible the breaks on the car simply stopped working. Do we still blame the Adobe manager?
>
> The blame game, however, is irrelevant. What we need is a fix for this from
> Adobe as quickly as possible.
>
The fix is to produce custom profiles or simply deal with the color we are handed and do our best to get an accurate preview and final conversion to the print process.

A camera manufacturer can call their data sRGB or DanRGB or AndrewRGB. When Photoshop reports what it1s told, we have to decide if the data and the tag are correct, a mile off, reasonably close, dead nuts on or anywhere in-between. The alternative is to have no tag which isn1t helpful at all unless we find that all tags are 100% wrong. In some of the consumer/prosumer cameras I1ve played with, sRGB or Apple RGB usually gets one in a half way decent preview on a calibrated display inside of Photoshop.

This issue isn1t only happening with digital cameras. When you bring in an untagged file from a scanner, the issues are still present. What1s different here is that instead of a scanner software driver simply sticking sRGB as a a tag in the file, we have digital cameras doing this and what1s new in PS7 is that the EXIF data is being examined and reported. Had the camera manufacturers placed an actual sRGB ICC profile in the file, the issues would be the same.

Andrew Rodney


Date: Sun, 19 May 2002 22:28:12 -0600
From: Chris Murphy
Subject: Re: Re: ancient custom color

Dan Margulis writes:

>I for one am tired of hearing other companies blamed whenever Adobe's
>careless programming breaks their product.

I said there's a lot of blame to go around. That includes Adobe. It also includes camera manufacturers who are reporting, via EXIF, incorrect camera behavior. One can't exclusively blame Adobe or camera vendors. Any application choosing to honor EXIF data is affected. Thus this isn't an inherent problem with honoring the data, the problem is that the data is wrong.

>With respect to the problem with camera profiles, if I am interpreting a
>recent statement by Chris Cox correctly, Adobe now recognizes that *all* EXIF
>profiles are currently wrong. If we know that they're always wrong, what on
>earth is Adobe doing making it mandatory that we honor them? This is an
>obvious failure to research before implementing.

Really...that's quite disconcerting. Do you have a copy of this statement by Chris Cox?

If it's the case EXIF data is always wrong, and application developers know it, and despite such knowledge ship applications that recognize EXIF data as being valid, they are accomplices in screwing workflows. There is mutual blame. I also agree that this would be a failure to properly research before proceeding with implementation.

>Plus, there's huge variation between individual cameras even of the same
>model. If we force the camera vendors to put some arbitrary tag on their
>files, it may be better than sRGB but it's still going to be wrong for many
>of their cameras and it will still be a PITA for users of Photoshop 7 until
>Adobe gets a fix out.

I agree on both counts. I think the entire concept of digital camera profiling has shown to be largely a waste of time except in very specific closed loop workflows, and therefore the attempt to tag every digital camera image with some profile is very premature. It *IS* better for the image to be untagged so that it is announced as having arbitrary color. Until the technology of profiling digital cameras improves, profile information in EXIF data should be ignored by applications.

The situation is suspicious to me. Why would vendors support EXIF data not proven to be helpful? There cannot be any evidence anywhere that shows tagging digital camera images as behaving per sRGB in EXIF data is the right thing to do. And yet the manufacturers have somehow been conned into doing this. By whom?

>If an Adobe manager were driving at 120 mph and smashed into a parked car, a
>lot of Adobe programmers and affiliated bootlickers would say, it's obviously
>the fault of the parked car, because its owner didn't put a nickel in the
>parking meter.

>The blame game, however, is irrelevant. What we need is a fix for this from
>Adobe as quickly as possible.

If what you're saying is true, that *all* cameras using EXIF data that tag images as behaving per sRGB is doing so incorrectly (I have no means of verifying it), then Adobe needs to remove honoring profile information in EXIF data immediately. They're welcome to support anything else they want to in EXIF.

This leads to a most fascinating situation. Upon opening such an image with EXIF data denoting the file as behaving per sRGB, this theoretical version of Photoshop 7 would be discarding the profile on open. When it saves out the file again, I presume everyone who has been in favor of Photoshop's OFF policy will be consistent and say that the file is changed immediately upon open for *all* policies (which would discard the profile on open); that way if the user tries to close the image, they will be spammed into saving the file WITHOUT the sRGB tag in EXIF data?

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


Date: Sun, 19 May 2002 22:48:16 -0600
From: Chris Murphy
Subject: Re: Re: ancient custom color

Andrew Rodney writes:

>Chris will have to set his record straight here. But from my perspective, NO
>camera actually shoots into sRGB but many camera manufacturers are doing
>their best to funnel color to something close to sRGB.

That doesn't explain the current situation. a.) Why are they even attempting to target sRGB when the average CCD and CMOS chip captures way more color than this? b.) Why does EXIF only denote either sRGB, or "unknown"? Why is sRGB the only option in EXIF? c.) At least in Dan's case, he's noting with at least a couple of digital cameras (perhaps more), either Apple RGB or ColorMatch RGB describe digital camera behavior better than sRGB. His situation is about as random as selecting anybody else - there is no reason to believe that his cameras are more inclined to have behavior more similar to a 1.8 gamma space compared to sRGB than anyone else's cameras. This tells me that the vendors aren't doing a good job of targeting sRGB when some other profile does a better job, and that profile is NOT a custom camera profile.

>Funnel the color into something close to a defined RGB Working Space and
>sRGB seems to be the choice definition these manufacturers are shooting for
>(we can debate that this isn1t a good idea but that1s what1s happening).

I definitely do not want to debate the merits (or lack thereof) of sRGB. However, I would like to know how camera manufacturers came to choose sRGB as the target of choice. That is a valid question. It is also a valid question why EXIF only has two place holders: sRGB and everything else. That's so totally absurd I cannot even begin to describe how absurd it is; although it's less absurd than Adobe deciding to HONOR this data when apparently ZERO research was done to qualify the validity of the data in mainstream use in the first place. It's sounding pretty damn irresponsible and I'm hoping it turns out that's not the case.

>The last option isn1t a good one. Simply supply untagged RGB data in a space
>that isn1t anything known and let users guess and thus complain about the
>color when they bring the file into Photoshop as Photoshop can1t produce an
>accurate preview.

We have had this debate before, with Photoshop 5. Everyone now agrees that embedded the wrong profile is worse than embedding no profile. In a color managed workflow this is even more the case - any image coming in without a profile is known to be ambiguous. These files are better off being dealt with as ambiguous than with the wrong profile.

>Many camera manufacturers decided to funnel the data into something
>reasonable (?) close to sRGB and place that tag in the EXIF data. Photoshop
>didn1t put that there, it only reports what is being provided in the EXIF
>data. That the data isn1t really sRGB and that the camera manufacturers
>place a tag in their files should be the issue.

There are two issues. If Adobe knows an overwhelming majority of EXIF data is wrong, honoring it is just plain stupid. In this case, they need to end honoring these tags until the technology matures.

Furthermore, no one I know as yet makes a script of any kind that removes the unwanted EXIF data - which would be valuable for workflows using any of the three policies.

>SOME profile has to be tagged (or assumed which is what happens when
>you ignore and strip out a profile).

Actually it's better for color managed workflows to see an untagged image, and get a warning that the image isn't tagged so people know it's ambiguous. For non-color managed workflows, they're going to ignore the EXIF profile anyway.

>Dan, it1s possible the breaks on the car simply stopped working. Do we still
>blame the Adobe manager?

If they have a whole bunch of additional cars on the way that all have busted brakes - yes we do. They need to stop launching additional cars with busted brakes until the brakes get fixed. Otherwise it's called negligence. Which is precisely what vendors tagging digital camera images incorrect with sRGB are guilty of right now.

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


Date: Mon, 20 May 2002 06:59:49 -0600
From: Andrew Rodney
Subject: Re: Re: ancient custom color

on 5/19/02 10:48 PM, Chris Murphy at lists@colorremedies.com wrote:

> That doesn't explain the current situation. a.) Why are they even
> attempting to target sRGB when the average CCD and CMOS chip captures way
> more color than this?
>
At least two reasons. One, Microsoft. Two, if we agree that in lieu of custom profiles for these cameras, the manufacturers have to provide some color that looks half way decent to the majority of users. With consumer cameras, the manufacturers are doing what they do with printers and other such color issues, forcing sRGB.

The fact is that most of these manufacturers are doing it wrong with regard to sRGB (try sending a file in sRGB, Apple RGB and Adobe RGB through the automatic settings in an Epson driver; you1ll find sRGB isn1t the best option).
>
> b.) Why does EXIF only denote either sRGB, or
> "unknown"?
>
That I don1t know but again, I suspect Microsoft or whoever is in charge of setting up spec1s for EXIF meta data. OR the manufacturers again decided that there would only be two tags they would honor when writing the file. We1d need Chris Cox or someone else to explain what the limitations of tagging with EXIF data is.
>
> At least in Dan's
> case, he's noting with at least a couple of digital cameras (perhaps
> more), either Apple RGB or ColorMatch RGB describe digital camera
> behavior better than sRGB.
>
I would agree with that as well. That1s what I1m finding too. But let us not forget how clueless the camera manufacturers are about color and color management! When the Nikon D1 first came out and people complained about 3magenta2 skin tones, Nikon told the world that the camera shoots into NTSB-RGB. It wasn1t close to that but it sounded good to Nikon at the time.

We can blame Adobe but I put a lot more blame on the camera manufacturers. We seem to agree that they like to tell us the data is sRGB when it1s Apple RGB or ColorMatch. AT least Adobe knows the difference!
>
> I definitely do not want to debate the merits (or lack thereof) of sRGB.
> However, I would like to know how camera manufacturers came to choose
> sRGB as the target of choice.
>
I think they did more or less.

> We have had this debate before, with Photoshop 5. Everyone now agrees
> that embedded the wrong profile is worse than embedding no profile.

Not everybody, I don1t. At least if I get an sRGB tag, I1m smart enough to look at it and try something reasonably close (Apple RGB or ColorMatch). I1m not going to the opposite end of the scale and look at Wide Gamut RGB or ProPhoto. Yes, I1d like the tag to be correct. But close is better than nothing.

> > There are two issues. If Adobe knows an overwhelming majority of EXIF
> data is wrong, honoring it is just plain stupid.
>
I don1t think anybody knows. Who for example has tested the hundereds of digital cameras and come up with a ratio of files that say they are sRGB (and are close) to those that are not? Certainly not Adobe and I1ll bet not a single person on this list. A sampling of a few cameras doesn1t provide enough science to say all (or even most) cameras are wrong.

> Furthermore, no one I know as yet makes a script of any kind that removes
> the unwanted EXIF data - which would be valuable for workflows using any
> of the three policies.
>
That wouldn1t be that hard to do! The question is, would we strip out any additional needed data?
>
> If they have a whole bunch of additional cars on the way that all have
> busted brakes - yes we do.
>
That hasn1t been investigated to the point I personally am willing to say
all the breaks are duds.
>
Andrew Rodney


Date: Mon, 20 May 2002 08:33:59 -0600
From: Ron Kelly
Subject: Re: Re: ancient custom color

Chris Murphy wrote:
>I said there's a lot of blame to go around. That includes Adobe. It also
>includes camera manufacturers who are reporting, via EXIF, incorrect
>camera behavior.

> Dan Margulis writes:
>
> One can't exclusively blame Adobe or camera vendors. Any
> application choosing to honor EXIF data is affected. Thus this isn't an
> inherent problem with honoring the data, the problem is that the data
> is wrong.

I'm just trying to clarify something here, make sure I understand the issues at stake. I'd like to "go digital" in the near future so this is very relevant to me. WHY is the EXIF data wrong? If it's another new standard, it's really getting off to a great start!

Ron Kelly


Date: Mon, 20 May 2002 09:31:00 EDT
From: Dan Margulis
Subject: Re: Re: ancient custom color

Chris Murphy writes

>Really...that's quite disconcerting. Do you have a copy of this statement
>by Chris Cox?
>
>If it's the case EXIF data is always wrong, and application developers
>know it, and despite such knowledge ship applications that recognize EXIF
>data as being valid, they are accomplices in screwing workflows. There is
>mutual blame. I also agree that this would be a failure to properly
>research before proceeding with implementation.

Chris Cox of Adobe, the world's leading practitioner of blaming everyone else for his own team's foulups, wrote as follows two weeks ago. While it is not the model of clarity that Chris's writings usually are, I interpret it to mean that 1) all or almost all cameras that use the EXIF tag set it to sRGB; 2) in all cases currently known the sRGB tag is wrong.

Dan Margulis

****************************************
"If you don't think your camera is really sRGB (and none of them are), then please complain to the camera manufacturer.

"Again, this does not harm your data -- it just mislabels it because the camera manufacturer mislabeled it. If you assign the correct profile for your camera, all is fine. The only possibility for damage is if you automatically convert to your working space -- and the possibility for damage ALWAYS exists that way. Set it to "ask".

"As for not having an embedded profile -- that is true. But there are several other places in the image file that can specify the name of a profile that should be associated with the image. The most common of these is the EXIF data embedded by all consumer digital cameras. And almost all EXIF compliant digital cameras say that the image is sRGB (when it really isn't). Again, this is the fault of the camera manufacturer."


Date: Mon, 20 May 2002 12:53:25 -0600
From: Chris Murphy
Subject: Re: Re: ancient custom color

Andrew Rodney (andrew@digitaldog.net) writes:

>At least two reasons. One, Microsoft. Two, if we agree that in lieu of
>custom profiles for these cameras, the manufacturers have to provide some
>color that looks half way decent to the majority of users. With consumer
>cameras, the manufacturers are doing what they do with printers and other
>such color issues, forcing sRGB.

I suspect Microsoft as well. As for the second reason, I don't buy it. EXIF could be extended to imply Apple RGB, ColorMatch RGB and/or Adobe RGB (1998). Basically there is a "ColorSpace" tag and when it =1 then sRGB is implicit, and if it's =FFFF.H then "uncalibrated" is implicit.

In reading the EXIF specification, it actually says the camera behavior conforms to ITU-R BT.709, not sRGB. However ITU-R BT.709 doesn't clearly specify a standard monitor condition. So they use ITU-R BT.709 as the picture taking algorithm and presuppose a display with sRGB behavior. I'm not even convinced that digital cameras actually do have behavior that conforms to ITU-R BT.709 in a device characterization sense, which has to do with HDTV standards for production.

So they aren't actually tagging the image with sRGB to say the camera conforms to sRGB. They are doing this for non-color managed workflows, by building images that already have sRGB behavior so they look OK on the average PC monitor. This is not color management. This is Tonka Toys. That Adobe is actually honoring sRGB as an implicit profile, I think, is a bad idea considering where the EXIF specification is currently at.

>That I don1t know but again, I suspect Microsoft or whoever is in charge of
>setting up spec1s for EXIF meta data.

At least through version 2.0 it was the Japan Electronic Industry Development Association. How it relates to Microsoft I don't know.

>We1d need Chris Cox or someone else to explain what the limitations of
>tagging with EXIF data is.

EXIF is extensible.

>I would agree with that as well. That1s what I1m finding too. But let us not
>forget how clueless the camera manufacturers are about color and color
>management!

So if we know this, one would assume Adobe either does or should know this. And if Adobe knows this or should know this, why would they accept extremely questionable data from a questionably competent digital camera industry as valid?

>> We have had this debate before, with Photoshop 5. Everyone now agrees
>> that embedded the wrong profile is worse than embedding no profile.
>
>Not everybody, I don1t. At least if I get an sRGB tag, I1m smart enough to
>look at it and try something reasonably close (Apple RGB or ColorMatch).

Andrew, most people are not in a position to second guess an implied profile. And that you translate embedded sRGB profiles as being "questionable" enough to start trying something else is NOT what we are supposed to use embedded profiles for. We're supposed to use the LACK of an embedded profile as being "ambiguous, I need to look at this sucker more carefully and choose an appropriate profile for it." Having to second guess embedded profiles makes them a pain in the ass to use.

What you are proposing is that embedding *any* profile that is better than what might be assumed is acceptable practice for profile embedding. I think that's a very bad workflow scenario. People will be convinced to use color management if it actually helps them do their job in a more seamless manner. If they have to second guess color management (which arguably people have been doing for years, and continue to do), they aren't going to trust it and aren't going to use it. It will never be widely adopted outside of those workflows that put in a lot of effort to get it to work.

You are proposing the dilution of the value of embedded profiles. I cannot agree with this. If a profile does not do an acceptably good job outside of having to tag it with a custom profile, then it should not be used. That is, if sRGB does the best job of any standard RGB profile, but still isn't perfect, that's fine. But sRGB i s not doing the best job - more often than not I'm hearing Apple RGB or ColorMatch RGB are doing a better job. The original embedded (literal or implicit) of sRGB was FLAT OUT WRONG in that case. The market is better served by untagged images in this case.

>That wouldn1t be that hard to do! The question is, would we strip out any
>additional needed data?

Simply have it parse the file, looking for "ColorSpace" and change the value from 1 to FFFF.H. Now it's marked as untagged and Photoshop will honor that it's untagged.

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


Date: Mon, 20 May 2002 13:04:43 -0600
From: Chris Murphy
Subject: Re: Re: ancient custom color

Ron Kelly (abcolor@telusplanet.net) writes:

> WHY is the EXIF data wrong? If it's another new standard, it's
>really getting off to a great start!

EXIF is the Exchangeable Image File Format for digital cameras. Basically digital cameras supporting EXIF speak EXIF. They don't speak exclusively JPEG or TIFF or whatever. The data stream is EXIF and within that data stream they can include a variety of metadata - or data about the image such as date, time, ambient conditions, and the implicit color space.

The part we are complaining about is the implicit color space. While the image doesn't actually contain an embedded ICC profile (although I think the spec supports doing this), it can specify one implicitly. And by one, I mean literally one - sRGB. So an sRGB profile isn't actually there, but the image announces itself as being an sRGB image. Any application that chooses to recognize this, would treat the image as though it has an sRGB profile embedded in it.

Apparently a majority of the cameras that use EXIF also set the ColorSpace tag to 1, which is sRGB. And further, apparently a majority of the cameras doing this don't actually produce images with sRGB behavior. Why? Well I think the spec is making some assumptions that just aren't true.

Although I don't have data yet, what I suspect is going on is that the camera vendors don't have their color science figured out yet (as Andrew says, they are basically clueless), and Microsoft is "encouraging" the manufacturers to announce their wares as conforming to sRGB. So what we have are clueless people being bullied by bullies and the consumers lose. But that always seems to be the case, so it's not like anything's new really.

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


Date: Mon, 20 May 2002 14:22:08 -0600
From: Andrew Rodney
Subject: Re: Re: ancient custom color

on 5/20/02 12:53 PM, Chris Murphy at lists@colorremedies.com wrote:

> I suspect Microsoft as well. As for the second reason, I don't buy it.
> EXIF could be extended to imply Apple RGB, ColorMatch RGB and/or Adobe
> RGB (1998). Basically there is a "ColorSpace" tag and when it =1 then
> sRGB is implicit, and if it's =FFFF.H then "uncalibrated" is implicit.
>
Sure, that1s possible (and useful) but what makes you think the camera data is any of the above? If it1s telling you it1s sRGB and it1s not, it1s likely you could be told the data is Apple RGB and it1s not. I don1t think these guys really know. Can a camera really produce RGB data like a display (of which our lovely RGB Working Spaces are based)? I1ve never seen a custom camera profile that had that perfectly triangular gamut shape. These manufacturers are attempting to place a round peg in a square hole. Or in some cases, a round peg in a somewhat rounded square hole.
>
> In reading the EXIF specification, it actually says the camera behavior
> conforms to ITU-R BT.709, not sRGB. However ITU-R BT.709 doesn't clearly
> specify a standard monitor condition. So they use ITU-R BT.709 as the
> picture taking algorithm and presuppose a display with sRGB behavior. I'm
> not even convinced that digital cameras actually do have behavior that
> conforms to ITU-R BT.709 in a device characterization sense, which has to
> do with HDTV standards for production.
>
I1ll buy that.
>
> So they aren't actually tagging the image with sRGB to say the camera
> conforms to sRGB. They are doing this for non-color managed workflows, by
> building images that already have sRGB behavior so they look OK on the
> average PC monitor. This is not color management. This is Tonka Toys.
>
Most of these are toy cameras too. When you start looking at truly pro cameras (the Kodak DCS line, Canon1D/D60, Nikon D1X, LightPhase, Imacon etc), you don1t get this nonsense. They allow you to shoot into all kinds of spaces and the actually embed an ICC profile in the file.

> At least through version 2.0 it was the Japan Electronic Industry
> Development Association. How it relates to Microsoft I don't know.
>
They are both bad guys to have to deal with when it comes to color!
>
> So if we know this, one would assume Adobe either does or should know
> this. And if Adobe knows this or should know this, why would they accept
> extremely questionable data from a questionably competent digital camera
> industry as valid?
>
As yet, we don1t know the ratio of cameras that are way off compared to those that are pretty close...
>
> Andrew, most people are not in a position to second guess an implied
> profile.
>
Why not? If it doesn1t look good on your calibrated display, why not try assigning a different profile before you alter the pixel data?
>
>
> And that you translate embedded sRGB profiles as being
> "questionable" enough to start trying something else is NOT what we are
> supposed to use embedded profiles for.

I agree but so many on this list like to talk about how common to get files with the incorrect embedded profile, why not try a different assignment.

In a prefect world, all files would have the correct profile embedded and we1d bet our live on that being correct. Since that1s not the case, and if you see an image that doesn1t appear Kosher, why not try a different embedded profile as your first route to fixing the issue? It1s a lot easier and faster and does less damage to the file than trying to pull curves and fix all the pixels. We don1t know what the right numbers are in many cases so we fly by the seat of our pants and look at the preview. Or we know what the numbers should be so the profile isn1t an issue at this point.
>
> We're supposed to use the LACK of
> an embedded profile as being "ambiguous, I need to look at this sucker
> more carefully and choose an appropriate profile for it." Having to
> second guess embedded profiles makes them a pain in the ass to use.
>
Indeed it does. So if everyone would simply embed the correct profiles....
>
> What you are proposing is that embedding *any* profile that is better
> than what might be assumed is acceptable practice for profile embedding.

No, I1m saying that if the preview looks really awful on my calibrated screen AND I1m getting data from a person I think might be a tad clueless, I1m going to try assigning different profiles before I throw in the towel and try to fix the image by altering all the pixels.

> I think that's a very bad workflow scenario. People will be convinced to
> use color management if it actually helps them do their job in a more
> seamless manner. If they have to second guess color management (which
> arguably people have been doing for years, and continue to do), they
> aren't going to trust it and aren't going to use it. It will never be
> widely adopted outside of those workflows that put in a lot of effort to
> get it to work.

No profile isn1t any better in my view. In fact, no profile leads me to believe the person hasn1t any idea of what they saw on screen or what the file meant. I1m not proposing people embed the wrong profile. I1m simply saying that my guessing the meaning of the numbers (if even necessary) is a bit easier with an embedded profile even if it1s wrong. But I1d prefer there always be the right tag in the file.
>
> That is, if sRGB does the best job of any standard RGB profile, but
> still isn't perfect, that's fine.
>
I think with these digital cameras, that1s usually going to be the case. For the kinds of users who will be shooting with these consumer cameras, sRGB, Apple RGB or ColorMatch RGB will all be fine. Now if the file is close to sRGB and somehow Adobe RGB (or god forbid) ProPhoto RGB gets embedded, the file will look awful and output just as bad.
>
> But sRGB i s not doing the best job -
> more often than not I'm hearing Apple RGB or ColorMatch RGB are doing a
> better job.
>
Better is relative with the group of people using these consumer cameras. If this color mismatch were such a huge issue, we1d have heard about it several years ago. Most people (non pro1s) using $500 digital cameras are simply happy color comes out on their Epson ink jets. If you asked them to pick sRGB from ColorMatch RGB, half would likely pick one set over the other. For someone like Dan or you, sRGB may not be acceptable compared to Apple RGB. I1m not trying to defend the boneheaded-ness of these manufacturers but for a lot of their customers, no one cares.
>
Andrew Rodney


Date: Mon, 20 May 2002 14:39:16 -0700
From: David Cardinal
Subject: Re: Re: ancient custom color

> Most of these are toy cameras too. When you start looking at
> truly pro cameras (the Kodak DCS line, Canon1D/D60, Nikon
> D1X, LightPhase, Imacon etc), you don1t get this nonsense.
> They allow you to shoot into all kinds of spaces and the
> actually embed an ICC profile in the file.

Actually, The Canon 1D, D30, Nikon D1, D1H and D1X do not embed profiles into their images. You need to assign them yourself or have a package (like the one we publish, DigitalPro for Windows) that does it for you. In fact, if you don't do that the D1X and D1H have precisely the problem folks have discussed here as Nikon does set the "Calibrated/sRGB" tag, whether you are shooting in Mode 1 ("sRGB") or Mode 2 ("Adobe RGB")

FWIW, in the case of the 1D, D1H, and D1X the camera does an okay job of producing images in the specified space. Not as good as a custom profile, but way better than older models like the D1 which produced images that were sort of but not quite in NTSC.

I can also confirm that with consumer cameras results seem to be all over the map.

--David Cardinal
Pro Shooters LLC
http://www.proshooters.com


Date: Mon, 20 May 2002 15:09:45 -0600
From: Chris Murphy
Subject: Re: Re: ancient custom color

Andrew Rodney writes:

>Sure, that1s possible (and useful) but what makes you think the camera data
>is any of the above? If it1s telling you it1s sRGB and it1s not, it1s likely
>you could be told the data is Apple RGB and it1s not. I don1t think these
>guys really know.

All the more reason they shouldn't be using this system until they have reasonable assurance of the behavior of the camera and resulting images before embedding profiles (implicit or literal).

>Can a camera really produce RGB data like a display (of
>which our lovely RGB Working Spaces are based)? I1ve never seen a custom
>camera profile that had that perfectly triangular gamut shape. These
>manufacturers are attempting to place a round peg in a square hole. Or in
>some cases, a round peg in a somewhat rounded square hole.

If Apple RGB or ColorMatch RGB is working better a significantly larger percentage of the time than sRGB, then they should cease and desist implicitly specifying sRGB as the behavior for these cameras. At worst they should implicitly specify Apple RGB or Colormatch RGB. At best the industry should be doing a better job researching what it's going to take to really profile digital cameras, including acknowledging the limitations of the ICC spec on this issue.

>Most of these are toy cameras too. When you start looking at truly pro
>cameras (the Kodak DCS line, Canon1D/D60, Nikon D1X, LightPhase, Imacon
>etc), you don1t get this nonsense. They allow you to shoot into all kinds of
>spaces and the actually embed an ICC profile in the file.

That's fine, but I have a problem with Adobe recognizing Tonka Toy data as being useful and valid when it's not. More data collection was needed before making the decision they arrived at. And while the devices may be toy cameras, they are increasingly taking stunning pictures in terms of detail and sharpness and are absolutely being used in production work, like it or not.

While there are toy film cameras, we don't dork film typing or the development process for them do we? No, it's treated just like professional film typing and development. Essentially what this situation has doneis it make the "film" typing of toy cameras questionable. That is just plain bad for the industry.

>> At least through version 2.0 it was the Japan Electronic Industry
>> Development Association. How it relates to Microsoft I don't know.
>>
>They are both bad guys to have to deal with when it comes to color!

Oh that's great. If you know this, Adobe should know it too, and therefore I think it's rather irresponsible for them to have presumed this data is even useful let alone correct, considering the source. It's sounding more and more like they totally jumped the gun on supporting the EXIF ColorSpace tag.

>In a prefect world, all files would have the correct profile embedded and
>we1d bet our live on that being correct. Since that1s not the case, and if
>you see an image that doesn1t appear Kosher, why not try a different
>embedded profile as your first route to fixing the issue?

I'm not arguing with the strategy of dealing with a non-ideal situation. I'm complaining about how we have arrived at the non-ideal situation, which is an increasing potential for embedded profiles to be wrong, and then to be RESPECTED as valid as well. Bad bad bad combination.

>> We're supposed to use the LACK of
>> an embedded profile as being "ambiguous, I need to look at this sucker
>> more carefully and choose an appropriate profile for it." Having to
>> second guess embedded profiles makes them a pain in the ass to use.
>>
>Indeed it does. So if everyone would simply embed the correct profiles...

...and if Adobe would ignore what appears to be known false data (or at least with high probability to be wrong). Considering what Chris Cox is reported as saying about cameras that report themselves as sRGB, but none of them do, and what you have said about the Japan Electronic Industry Development Association, I feel like Adobe has acted very presumptuiously in supporting the EXIF ColorSpace tag.

>No profile isn1t any better in my view. In fact, no profile leads me to
>believe the person hasn1t any idea of what they saw on screen or what the
>file meant. I1m not proposing people embed the wrong profile. I1m simply
>saying that my guessing the meaning of the numbers (if even necessary) is a
>bit easier with an embedded profile even if it1s wrong. But I1d prefer there
>always be the right tag in the file.

This is not a workflow scenario compatible with an attempt to trust the embedded profile. Second guessing profiles is inherently a way to regard them as less useful than they could be. Untagged means a file is ambiguous, and in an ambiguous situation, you go to Assign profile and find something reasonable visually because there is no other option. One incorrectly marked as sRGB will produce questionable results in your mind, but do you really know that the scene is too dark or does it just look too dark? Instead of going with what was shot, you are immediately placed in an interpretive standpoint. Color management by itself inherently does not work alone, and has no chance to work alone; it requires human intervention to VALIDATE the profile. Humans having to validate or invalidate embedded profiles is more work with little benefit. Why mislead them with the wrong profile? If we do not hold vendors and Adobe to a higher standard, we will never get to a point in time where we can say:

a.) If a file has an embedded profile, it's ready for image analysis and color correction without further attention to color management issues.

b.) If a file does not have an embedded profile, one must first find a suitable profile to assign to the image; and then proceed with image analysis and color correction.

You are saying that while it's not ideal, it's *acceptable* to always be in condition B, to never be in a situation where an embedded profile can simply be trusted. I don't find this acceptable. We can't get there until we hold the industry accountable - either stick in the right profile for the job, or do not embed a profile at all.

>> That is, if sRGB does the best job of any standard RGB profile, but
>> still isn't perfect, that's fine.
>>
>I think with these digital cameras, that1s usually going to be the case.

That's the problem, it's not usually the case if Dan's quote from Chris Cox sounds like what it sounds like (cameras that say they conform to sRGB don't actually have sRGB behavior - and he even stated none of them do.)

>Better is relative with the group of people using these consumer cameras. If
>this color mismatch were such a huge issue, we1d have heard about it several
>years ago.

Several years ago these cameras were not in widespread use, especially by the professional community. And even within the consumer to lab community there are *massive* problems with color mismatches if my session at PMA was any indication. There is a major gap in how to get consumer digital shots accurately rendered in physical output upon request. It's only recently that there is some movement on a standard means of transporting digital files to a lab for output if you want them. Epson has gone to great lengths with their PIM technology to effectively do an end run around the convoluted settings in their drivers to get digital camera images to output within reason on an inkjet printer. It is a huge issue, and we have been hearing about it, and it's an even bigger problem now that Adobe has joined the party of those honoring wrong or useless data as being valid.

> Most people (non pro1s) using $500 digital cameras are simply
>happy color comes out on their Epson ink jets. If you asked them to pick
>sRGB from ColorMatch RGB, half would likely pick one set over the other. For
>someone like Dan or you, sRGB may not be acceptable compared to Apple RGB.

Gamut wise they are about the same. I'm not complaining about sRGB per se (although I question how it was selected in the first place), but rather than if an image is announced as having sRGB behavior, then it should have sRGB behavior - not be closer in behavior to Apple RGB which is what is increasingly appearing to be the case.

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


Date: Mon, 20 May 2002 18:27:47 EDT
From: Dan Margulis
Subject: Re: Ancient Custom Color

Ron Kelly writes,

> I'm just trying to clarify something here, make sure I understand the
> issues at stake. I'd like to "go digital" in the near future so this is
> very relevant to me. WHY is the EXIF data wrong?

As I understand it, because the spec was set up in such a way as to make it hard for camera manufacturers to choose anything other than sRGB; because there were contractual requirements with Microsoft that may have required it; because these cameras were designed in the age of Photoshop 4 and the engineers would have had no clue as to what sRGB even meant, let alone that it might become an issue in the year 2002.

So, we have thousands upon thousands of files that show up with the wrong profile. That's not the issue--there's no shortage of such files now. While Adobe should clearly have researched this a whole lot better than they did before deciding to honor profiles that are always wrong, that's not the major issue either.

The issue is that Photoshop 7 is broken with respect to incoming files that have the wrong profile. No matter how your color settings are set up, the moment you open such a file in any sensible way, you are deemed to have changed it.

Photoshop 6 doesn't recognize these incorrect profiles, but even if it did, it would be a minor inconvenience, nothing more. In Photoshop 7, it effectively makes the cameras unusable for many of us.

Dan Margulis


Date: Mon, 20 May 2002 21:50:41 -0400
From: Jerry Lodriguss
Subject: Re: Ancient Custom Color

>The issue is that Photoshop 7 is broken with respect to incoming files that
>have the wrong profile. No matter how your color settings are set up, the
>moment you open such a file in any sensible way, you are deemed to have
>changed it.
>
>Photoshop 6 doesn't recognize these incorrect profiles, but even if it did,
>it would be a minor inconvenience, nothing more. In Photoshop 7, it
>effectively makes the cameras unusable for many of us.

Hi Dan,

Since I'm getting ready to switch to PS7, I want to be sure I completely understand this... I thought I did, but you say for PS7: "No matter how your color settings are set up, the moment you open such a file in any sensible way, you are deemed to have changed it." and that "effectively makes the cameras unusable..."

I shoot with a Nikon D1H camera, set to Adobe (1998) RGB color space in the camera.

For Photoshop 6 and 7 here are the settings, behavior, and methodology I have been using:

PS 6.01 - Color Space set to Adobe, Color Management Policy set to preserve embedded profiles, Profile Mismatch and Missing Profile set to ask when opening:

PS Behavior: Open file and get "Missing Profile" dialog.

Solution: Assign Adobe (1998) RGB profile.

PS 7.0 - Color Space set to Adobe, Color Management Policy set to preserve, profile mismatch and missing profile set to ask when opening (exactly the same as PS 6.01):

PS Behavior: Open file and get "Embedded Profile Mismatch" dialog which says the file is in sRGB color space.

Solution: Discard the profile when opening the file, and then assign the Adobe (1998) RGB profile.

Are you saying that what I am doing is wrong?

Thanks,

Jerry

Astronomical photography: http://www.astropix.com

Sports Photography: http://www.astropix.com/SPORTSPIX/INDEX.HTM


Date: Mon, 20 May 2002 22:05:10 -0600
From: Chris Murphy
Subject: Re: Re: Ancient Custom Color

Dan Margulis (Dan Margulis) writes:

>The issue is that Photoshop 7 is broken with respect to incoming files that
>have the wrong profile. No matter how your color settings are set up, the
>moment you open such a file in any sensible way, you are deemed to have
>changed it.

Well no, you can open it with the PRESERVE policy and Photoshop will not
consider it changed.

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


Date: Tue, 21 May 2002 07:19:44 EDT
From: Dan Margulis
Subject: Re: Re: Ancient Custom Color

Chris Murphy writes:

>>Well no, you can open it with the PRESERVE policy and Photoshop will not
>consider it changed.

I said when you open the file "in any sensible way." Intentionally opening
the file into the wrong RGB, so that the preview will be wrong and any subsequent conversion will be wrong, is hardly sensible.

Dan Margulis


Date: Mon, 20 May 2002 22:06:22 -0600
From: Chris Murphy
Subject: Re: Re: Ancient Custom Color

Jerry Lodriguss (jml@astropix.com) writes:

>PS 7.0 - Color Space set to Adobe, Color Management Policy set to preserve,
>profile mismatch and missing profile set to ask when opening (exactly the
>same as PS 6.01):
>
>PS Behavior: Open file and get "Embedded Profile Mismatch" dialog which
>says the file is in sRGB color space.
>
>Solution: Discard the profile when opening the file, and then assign the
>Adobe (1998) RGB profile.
>
>Are you saying that what I am doing is wrong?

That's exactly what you'd do. An alternative would be to use some kind of script to automate the process for an entire folder of files.

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


Date: Tue, 21 May 2002 07:33:23 -0500
From: Bob Smith
Subject: Re: Re: Ancient Custom Color

Dan Margulis wrote:
> I said when you open the file "in any sensible way." Intentionally opening
> the file into the wrong RGB, so that the preview will be wrong and any
> subsequent conversion will be wrong, is hardly sensible.

I understand and agree with your complaints about the new OFF policy but even assuming it worked as it did in PS6, you still don't get accurate previews or subsequent conversions unless you either assign the correct profile; or have your working space set to the appropriate profile for the camera. I don't see those inconveniences as much different from using Preserve when you know the profile is wrong and assign the correct one later. To me, using Preserve, and keeping the status box at the bottom of the image window set to show the color space, is the most logical way to work. If the image looks good and the color space fits into the rest of your workflow you're home free. If the image looks good, but is honoring some odd profile, convert to you're preferred one. If the image looks bad, ignore the profile and assign whatever you want. With large batches of images that come from cameras that you know are incorrect, just dump em on a script that assigns a reasonable one before you ever look at them. Its not rocket science and hardly seems worth all the angst it causes here. Yes, Adobe should fix the OFF policy, and possibly allow the honoring of EXIF color space data to be switched off and on separately from profiles; but I'm not going to get any more gray hairs waiting for it to happen.

Along the lines of the OFF policy...has anyone else notice that in PS7 you can't simply open an image and print it without being asked to save it on close? These are images opened with Preserve where nothing...no page setup, printer change or conversion takes place...just print.

Bob Smith


Date: Tue, 21 May 2002 09:21:16 EDT
From: Dan Margulis
Subject: Re: Ancient Custom Color

Jerry writes,

>>PS 6.01 - Color Space set to Adobe, Color Management Policy set to preserve embedded profiles, Profile Mismatch and Missing Profile set to ask when opening:PS Behavior: Open file and get "Missing Profile" dialog.
Solution: Assign Adobe (1998) RGB profile.>>

Correct all the way, and no problem if you open a lot of files for inspection purposes and close them unchanged.

>>PS 7.0 - Color Space set to Adobe, Color Management Policy set to preserve, profile mismatch and missing profile set to ask when opening (exactly the same as PS 6.01):
PS Behavior: Open file and get "Embedded Profile Mismatch" dialog which says the file is in sRGB color space. Solution: Discard the profile when opening the file, and then assign the Adobe (1998) RGB profile.>>

Essentially the same thing as before, with one huge exception. If you now attempt to close the file, you get a "Do You Wish to Save Changes" dialog. If you're opening a large number of files just to inspect them, you'll have to respond to this bogus warning for each one. If you often have lots of images open on the screen and have actually changed some of them and are relying on the warning to identify which ones, you're out of luck, because *all* the images will have changed, in the perverted view of PS7.

>>Are you saying that what I am doing is wrong?>>

No, quite the contrary, you're doing the right thing, but Photoshop 7 is not.

Dan Margulis


Date: Tue, 21 May 2002 10:06:24 EDT
From: Dan Margulis
Subject: Re: Ancient Custom Color

Bob Smith writes,

>>I understand and agree with your complaints about the new OFF policy but even assuming it worked as it did in PS6, you still don't get accurate previews or subsequent conversions unless you either assign the correct profile; or have your working space set to the appropriate profile for the camera. I don't see those inconveniences as much different from using Preserve when you know the profile is wrong and assign the correct one later.>>

It depends on the workflow. Many of us choose RGB working space specifically because it matches a camera. In PS 6, this works perfectly. No warning on open, no warning on close. Even if PS 6 recognized the incorrect profile, it would be inconvenient but not a disaster--one could set profile management to ignore incoming profiles. With PS 7 this is impossible.

Similarly, many of us open lots and lots of images all at once, to determine which pictures are usable, and perhaps to correct a few of them. This is obviously unworkable in PS7.

It's a killer for my own workflow. But if *you* don't set workspace to match the camera, and if *you* don't often have more than one image open on the screen, then it's not nearly as big a problem for you as it is for me. Similarly, if a person doesn't own a digicam at all or accept files from strangers, the fact that Photoshop recognizes an incorrect profile doesn't affect anything.

Dan Margulis


Date: Tue, 21 May 2002 11:22:15 -0600
From: Chris Murphy
Subject: Re: Re: Ancient Custom Color

Dan Margulis writes:

>I said when you open the file "in any sensible way." Intentionally opening
>the file into the wrong RGB, so that the preview will be wrong and any
>subsequent conversion will be wrong, is hardly sensible.

Yeah OK, but it would have been easier to wrote "with the OFF policy" instead of "in any sensible way" because there is only one way (built-into Photoshop) to prevent the use of the wrong profile that happens to be embedded in the image, and that's the OFF policy.

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


Date: Tue, 21 May 2002 16:34:04 -0700
From: Jan Steinman
Subject: Re: ancient custom color

> From: Andrew Rodney>
>NO
>camera actually shoots into sRGB but many camera manufacturers are doing
>their best to funnel color to something close to sRGB. That being the case,
>the EXIF "profile" is wrong simply because sRGB and what comes off a digital
>camera are different...

It seems there is lots of blame to spread around.

Is it not true that the EXIF spec only allows for two profiles: "sRGB" and "undefined?"

If that is the case, EXIF is a major villain here. I don't expect camera makers to "dumb down" their gamuts to accurately fit "stupid RGB," nor do I expect them to make cameras that, to the typical consumer, "don't work right" because they have an undefined profile!

--
: Jan Steinman
: Bytesmiths
: 19280 Rydman Court, West Linn, OR 97068, 503.635.3229


Date: Tue, 21 May 2002 16:44:52 -0700
From: Jan Steinman
Subject: Re: ancient custom color

> From: Andrew Rodney >
>on 5/19/02 10:48 PM, Chris Murphy at lists@colorremedies.com wrote:
>
> > Why are they even
> > attempting to target sRGB when the average CCD and CMOS chip captures way
>> more color than this?
>>
>At least two reasons. One, Microsoft...

I think it's more complicated than this.

With anti-trust remedy action in the offing, Micro$oft has to do anything it can to keep Apple afloat. And since relatively few graphics pros contemplate using anything but Mac, it was safe to toss this bone to Apple: "we'll pollute the computing world with broken graphics standards, so you can support proper standards, and keep your customer base among people who know the difference."

I would expect no less from the company who's official policy toward standards -- as ruled by competent jurisdiction -- was "embrace, embellish, extinguish."

(With tongue planted firmly in cheek... duck -- here come the flames! :-)

--
: Jan Steinman
: Bytesmiths
: 19280 Rydman Court, West Linn, OR 97068, 503.635.3229


Date: Tue, 21 May 2002 16:27:03 -0700
From: Jan Steinman
Subject: Re: ancient custom color

>I for one am tired of hearing other companies blamed whenever Adobe's
>careless programming breaks their product.
>
>With respect to the problem with camera profiles, if I am interpreting a
>recent statement by Chris Cox correctly, Adobe now recognizes that *all* EXIF
>profiles are currently wrong...

I would not trust Chris to speak for Adobe -- or to even speak the truth.

He picks a fight with me on some other list whenever I complain about Adobe's non-support of MacOS X UFS users. He claims over and over than UFS is "unsupported by Apple." After careful reading of Apple documents, I can only assume that Chris is either a blustering idiot, or that he simply does not comprehend the difference between the concepts "supported" and "recommended." (Apple "supports" UFS, but "recommends" HFS+, which Adobe -- or at least Chris -- has interpreted to mean "UFS is useless garbage, and no one should ever use it" -- this is paraphrasing from memory, but pretty much what he has said.)

On the other hand, there is my experience. I use UFS quite successfully with everything but Adobe apps. The types of problems I have with Adobe apps (capitalization problems, for example) lead me to believe they never even installed their software using UFS, let alone tested it.

Sorry for the digression. I just wanted put some weight behind my assertion that, in my experience, Chris Cox states *his opinion* as though it were Adobe official policy, so I'd beware of claiming any official Adobe malfeasance based on what Chris Cox writes.

--
: Jan Steinman
: Bytesmiths
: 19280 Rydman Court, West Linn, OR 97068, 503.635.3229


Date: Wed, 22 May 2002 11:56:14 -0600
From: Chris Murphy
Subject: Re: Re: ancient custom color

Jan Steinman writes:

>I would not trust Chris to speak for Adobe -- or to even speak the truth.

He can be abrasive but he's not a liar.

>He picks a fight with me on some other list whenever I complain about
>Adobe's non-support of MacOS X UFS users. He claims over and over than UFS
>is "unsupported by Apple." After careful reading of Apple documents, I can
>only assume that Chris is either a blustering idiot, or that he simply
>does not comprehend the difference between the concepts "supported" and
>"recommended." (Apple "supports" UFS, but "recommends" HFS+, which Adobe
>-- or at least Chris -- has interpreted to mean "UFS is useless garbage,
>and no one should ever use it" -- this is paraphrasing from memory, but
>pretty much what he has said.)

While the issue of UFS vs HFS+ is quite off topic and out of scope for this list, Apple is essentially deprecating UFS in reality, regardless of what their documentation says. The UFS implementation on Mac OS X has serious and fundamental problems that I don't foresee ever getting fixed. We'll have a totally different volume format to replace both UFS and HFS+ before that happens.

I happen to know that Chris's feelings on UFS are shared by quite a few programmers at Adobe, and even quiet a few developers other than Adobe. So his opinion is by far not unique.

>On the other hand, there is my experience. I use UFS quite successfully >with everything but Adobe apps. The types of problems I have with Adobe >apps (capitalization problems, for example) lead me to believe they never >even installed their software using UFS, let alone tested it.

At least with Photoshop they did, I was one of them, and one of the biggest problems with UFS when it comes to Photoshop on OS X is that it overcommits disk space - i.e. it lies about how much space is available, then all of a sudden the volume is full in the middle of a write operation. Apple's implementation is also extremely slow when it comes to write operations, compared to HFS+. Some write operations can be 5x longer. As a scratch disk volume format I would consider it totally unusable. I don't blame Adobe for not supporting it any more than I don't blame them for not supporting installations on FAT while on OS X. The issue of case sensitivity is not unique to Adobe applications, it's a problem with a variety of other applications. This has been discussed in much greater detail on Omni Group's Mac OS X Admin list.

>Sorry for the digression. I just wanted put some weight behind my
>assertion that, in my experience, Chris Cox states *his opinion* as though
>it were Adobe official policy, so I'd beware of claiming any official
>Adobe malfeasance based on what Chris Cox writes.

Perhaps, but in the case of UFS, his opinions reflect that of all the other Adobe programmers and product managers I've talked to about the subject (and a variety of other non-Adobe developers); and in the case of EXIF, if he's saying none of the cameras using EXIF behave per sRGB then it's probably true. It's not conclusively true - but it's a pretty darn good bet.

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


Date: Wed, 22 May 2002 12:02:15 -0600
From: Chris Murphy
Subject: Re: Re: ancient custom color

Jan Steinman writes:

>With anti-trust remedy action in the offing, Micro$oft has to do anything
>it can to keep Apple afloat. And since relatively few graphics pros
>contemplate using anything but Mac, it was safe to toss this bone to
>Apple: "we'll pollute the computing world with broken graphics standards,
>so you can support proper standards, and keep your customer base among
>people who know the difference."

Microsoft is like any other software company in that other than marketing their largest cost is technical support. They are inclined to do whatever they can, within reason, to automate "reasonable" color from screen to print. Considering sRGB does do a reasonable job of describing a compute display, it's not unreasonable to expect consumer devices to default to that behavior. This is not the problem.

The problem is:

1. When devices claim to conform to sRGB, but don't.

2. When devices only allow their behavior to be defined in relation to sRGB.

My understanding is that Microsoft does push for conformance of device behavior to sRGB *OR* ICC - not both. What they need to do is push for conformance to both. For consumer devices, default to sRGB (and solve problem #1), but allow means to change the device to reference itself to some other space (solve problem #2).

Actually I would be satisfied with a non-ICC option (technically EXIF is *NOT* supplying ICC info - it just implies sRGB which Photoshop then goes and grabs an sRGB ICC profile on the local machine) so long as there is more than just an sRGB choice. I'd like to see at least a ColorMatch RGB choice, but would prefer to see Adobe RGB (1998).

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

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