Untitled Document

As a custom lab owner for 30 years, I'm grateful that we're finally getting to the point where most people do embed profiles no matter what they are so that we CAN convert from them to our output profiles. The major exceptions are still the printers and agencies who somehow mysteriously work in a vacuum and never embed profiles. I get the clear impression that they think we're incompetent if I ask for a profile, or maybe my question could reveal their lack of knowledge in the area, so I've learned not to ask them. For them we have to use our best judgment. Ironically, their work is the most demanding but they're used to the method of charging customers for proofs and corrections. Who am I to rock the boat?

There are also a great and increasing number of people who come to the lab with profiled images who want their images "improved". For them, it doesn't matter if we match their monitors (or even their files) or not. I have no problem with that, but it illustrates the problem that the lab needs to know up front IF the embedded profile is to be honored. This is now the most difficult part of the workflow. Even Dan's blind test of photo labs earlier this year was faulted because it came without instructions, so it was no surprise that results varied. Some labs opted to honor, some opted to improve and the rest just ran them and let the machine de jour do whatever it wanted to do. All of them are correct on different levels.

John Castronovo

___________________________________________________________________________

John Castronovo writes,

This list carries extensive archives so that we can see who was saying what when, and how right or wrong they proved to be.

The above comment echos one John made a few months ago when discussing my photo lab test, in which his lab participated ("unofficially", because he knew it was a test) and did an excellent job. At that time, he indicated to the list, as he does here, that if a stranger hands him a job,without specifying that it the embedded profile is to be honored, John declines to offer guarantees as to what he will do.

Longtime list members will understand that, since John has been a long-time defender of a profiled workflow, this statement brings closure to a discussion that has plagued this list almost since its inception--whether there would ever come a time when one could safely hand off a tagged file to a stranger and assume that the stranger would handle it properly.

When Photoshop 5 implemented the idea of embedded profiles as "a universal language of color" in 1998, substantially the same folk who are peddling ProPhoto now hailed it as "brilliant", "a work of genius", "possibly the greatest software release in history." Users who doubted the new order were bashed mercilessly online. Service providers were advised that they had six months to a year to adopt, or die, and that resistance was futile.

Alone at the time, I said that the ability to embed profiles was useful to "a small minority of disciplined users", such as members of this list, but that "These color changes singlehandedly make what would otherwise be a superb upgrade into one that will foment chaos. Despite its undoubted merits, on the whole Photoshop 5 is a major disservice to the industry."

http://www.ledet.com/margulis/PS5Review.pdf

Before the end of the next year, it was plain that the desired goal--to eliminate the occasions when strangers had to communicate in order to transfer files, because the embedded profile would speak for itself--could never be achieved. I wrote an article entitled "How Color Management Failed" (at that time, "color management" was a term limited to the embedding and honoring of profiles; the expansion into areas of process control was a later phenomenon.)

http://www.ledet.com/margulis/How_CM_Failed.pdf

This article's suggestion that there would *never* come a time when strangers could freely pass profiled files back and forth basically shut down the ColorSync list for several weeks while its members attempted to find suitably damning words for it and its author. On *this* list, the years wore on, the failure became more and more apparent, and yet we had thread after thread warning us that resistance was still futile, and that it if we embedded profiles and a stranger ignored them, we shouldn't be upset if our jobs were ruined, because if would be that stranger's fault.

It was not as easy to explain wrecked jobs to clients as one might think, so the victims of the misinterprations often started threads on this list. Threads suggested that a service provider who ruined a job by ignoring a profile should pay to redo it--but the same people arguing this also argued that a service provider who ruined a job by *honoring* a profile that turned out to have been there by client error should pay to redo the work.

http: //www.ledet.com/margulis/ACT_postings/ProfilingandProofing/Profiling.htm

As late as 2003, the longest threads in list history continued to see zealots insisting that any service provider who wouldn't honor embedded profiles automatically deserved the blame for the failure of a job--and the ruined jobs continued.

http: //www.ledet.com/margulis/ACT_postings/DailyLife/Daily.htm

Since then, things have died down somewhat in light of what everybody now knows--that handing out tagged files to strangers on the assumption they'll automatically be honored is a form of masochism. If the success of the job depends on the profile being honored, we *have* to make sure that the next person knows.

John's policy is realistic in light of the real-world images that get handed to him. He is committed to looking for the best-quality way of doing things and that he usually supports standards initiatives. He has been vocal in support of a profiled workflow. When *he* will not commit to honoring embedded profiles from a stranger, the game is over.

So, the eight-plus year experience can now be regarded as producing the following final results. In the name of making communication between client and service provider on a *few* jobs unnecessary, we now have to have formal communication on *every* job. In the name of offering options that improve quality marginally in a small fraction of images we get to watch a parade of completely ruined jobs. John is right when he says, "This is now the most difficult part of the workflow."

It used to be the *easiest*--before the theoreticians who now push ProPhoto got their way.

Dan Margulis

___________________________________________________________________________

With such absolute nonsense once again starting, it©ˆs hard to gather the energy to reply to this kind of negative mindset that prefers to condemn a process than explain how to use it. Anyway:

Digital images are big piles of numbers.

Numbers alone, don©ˆt tell us what a color should look like (there©ˆs the all powerful, worshiped Lab color space which is self defining but you have to convert to lab from something so that©ˆs that).

The only way we have to define color appearance from numbers is defining the color space (the scale of the numbers).

The only way we have to define a color space today is by embedding profiles in documents.

If you care about communicating what the numbers mean, you embed a profile.

You could I guess label the file ©¯Dan©ˆs Flowers in sRGB.TIFF©˜ but then, would you believe the file is in sRGB anymore or less given a so called stranger than just embedding the profile?

We label lots of items from medicine bottles to the type of gas we want to pump into our cars. People continue to pump the wrong gas and take the wrong drug dosage. No one of sound mind could possibly be criticizing the process of labeling an item that without such a label becomes ambiguous, unknown and suspect to far more damage. An embedded profile is just a label and it can be wrong just as some idiot could overdose on baby aspirin.

When Dan invents Dan RGB and a better way to define numbers and color spaces, the world will be a better place no question. Until then, we have a solution that while imperfect works well when used by somewhat intelligent people. Until then, we all await the perfect, foolproof solution from the minds of the color theory list.

Andrew Rodney

___________________________________________________________________________

Dan,

Surely the formal communication IS the embedded profile. All teachers of digital imaging have to do is to make their pupils realise this. There will always be those who cannot read, whether it is english, spanish, chinese, or 'color management-speak'! Surely our job as teachers is to teach them the language, so they can understand the changes that are taking place in the world around them.

Trying to imitate 'King Canute' is not very helpful, IMO.

'Adapt or die' is the rule that the world operates by (with or without humans).

If people ruin (where did that strange word 'hose' come from?) the images you send them, don't send them any more. To save time I sent 100 images (in sRGB) to a commercial processor recently, and they came back all sorts of colors; I shan't send them any more - I've just printed them (in the original Adobe98) on my Epson inkjet (using a custom profile) and they are perfect. I shall look for another printer who knows what they are doing.

Bob Frost.

___________________________________________________________________________

There is more than one way that an end user may define a color space for an image: there are also guessing and assuming.

If there were actually only one way, this thread would not exist. If there were actually only one way to define the color space of an image, and it were enforced in such a way as to not allow for any other option, who would deny that this would be the easiest, most efficient scenario?

However, the de facto situation imposes so many options that there really aren't any rules. Oh yeah, there is the Communication Rule that has developed to resolve the issue for each and every file an end user touches. How convenient.

Ordinarily, a de facto standard imposes A rule by practice.

Ordinarily, a de jure standard imposes A rule by law.

We currently have neither. We have color anarchy, and it continues to by my impression that there was more of a "standard" 15 years ago. What we have now sounds more like very sophisticated, yet spoiled children arguing over who gets their way.

It is almost undeniable that if A Rule or A Standard is imposed, it will involve some sort of compromise. If this process of argument is some sort of search for such an ultimate, uncompromising standard, then I believe we may be disappointed. Sure, the search will probably continue, but there really needs to be an interim agreement so that at least there is some temporary clarity. If tons of unknowns are going to be slinging files about at each other, a standard should have been the first item on the agenda.

I recall sRGB as the color space for which no agreement could be found in even making it even an interim standard. The same goes for ColorMatch, Adobe98, etc. The color community would rather have chaos and anarchy, which is sooo much fun, and keeps everyone with their own horse in the race. While it is definitely a technical issue, just how look at how political sounding it has become.

Maybe every service provider should name their own RGB, thus implying some sort of competitive advantage.

Henry Davis

___________________________________________________________________________

On Nov 30, 2006, at 10:39 AM, Andrew Rodney wrote:

This is the kind of clear and reasonable claim that should have been made in the first place-- and wasn't. I think it is how profiles were implemented and not that profiles were implemented that riles Dan and many others. IMO, it is a fact that damage has been *and* continues to be done by "experts" making extravagant claims.

Ric Cohn

___________________________________________________________________________

Henry

Did you read Rich's post of a few days ago? It included this paragraph

So there are standards, and it seems ProPhoto is one of them!

___________________________________________________________________________

My Lord! Be honest here Dan.

I said that for the 43 cents I charge for a 4x6 print I wouldn't guarantee that I'd be able to second guess the customer's wishes if I wasn't told to honor the profile or not, or for that matter if there was no profile, multiple channels, a lab or cmyk image thrown into the mix for good measure. Many kinds of files require further work and we like to be warned when the customer needs additional attention.

To be sure, if we're talking about a job of any size we'd be on the phone to discuss it with the customer which is what I've always said should be done. My position hasn't changed one bit over the years. If there's no profile we call and if there is one, we honor it . . . unless we're talking about work that's literally worth pennies, and that's what your test was really about.

Because your test files had no instructions, I made you two sets to illustrate my point: one where I honored the profiles and one where I let the technician adjust the images according to his liking. In the real world, there's no way to truly sort this out on the fly when you're making hundreds of prints for peanuts. However, this group isn't about such imaging. This is a group of professionals who work at the high end of the imaging food chain, so I don't think this example proves anything to them.

john castronovo

___________________________________________________________________________

On Nov 30, 2006, at 6:19 AM, Dan Margulis wrote:

A parade of completely ruined jobs?

Are you joking? The "theoreticians" laid the groundwork and established standards for workflows that have become widely adopted and have eliminated much of the chaos in the field - chaos that exists largely because of people who refuse to endorse widely accepted and recommended standards.

Lee Varis recently wrote to tell us how 90% of the work coming into his lab is tagged with AdobeRGB, and how HAPPY he and his customers are. The 10% that refuse to embed profiles are the problem - and it seems that they KNOWINGLY strip out their profiles because of an UNFOUNDED FEAR that someone they DON'T KNOW will mis-convert their image. So what do they get? Someone in the lab trying to guess what profile they used so they can convert it properly. Brilliant! Do you think Lee wants everyone to strip profiles and hand the lab "mystery meat?" I'll bet not!

Let's see.

On Nov 18, 2006, at 1:56 PM, Dan Margulis wrote:

Of course, there is NO recommendation on what to use if you are NOT sure that someone may "convert (or fail to convert) it improperly later" and you have made it clear that you have NEVER endorsed sRGB - for anything. And after multiple requests, you have never recommended anything as far as color spaces go, other than what NOT to use, and now you long for the days when profiles were not embedded. Talk about creating chaos!!! Most of the world has settled on embedded profiles as a standard, and AdobeRGB as a pre-press / photo lab / inkjet standard. Even Web browsers are becoming color- managed and reading/respecting embedded profiles. Having recognized that color management works, people are now asking for more, not less. Standards committees, libraries, national archives, and photographers are looking for direction for the future, and it is definitely in wide-gamut color spaces that can preserve as much information in an image as possible. You'd like to go back to the days when there was no "working space" and no History palette, and every image was mystery meat. It's almost unbelievable - but I believe it.

An embedded profile does not guarantee a perfectly edited image - it only indicates what color space the numerical image data should be output/processed in. John's problem with clients is not with the embedded profile - it's with poor editing. Do they want exactly what's defined in the image to be converted to output, or do they want the image improved? The same is true of Lee's customers.

As a "leader" and educator, you should be making sound POSITIVE recommendations, rather than longing for the days when standards didn't exist and users did whatever they wanted to. (You never did provide the specific recommendations to common APPLIED photoshop scenarios that I requested.) The photographic community is fortunate that Adobe engineers made the decisions that they did in PS 5 - the implementation of color management in a desktop image editing application was a landmark achievement by forward-thinking engineers. Their adoption of RIMM/ROMM as the processing space in Adobe Camera RAW was no less forward-thinking. They have used cutting-edge research to design and build their products, and I have no doubt that they will continue to do so.

Personally, I'm thankful for the "theoreticians" at Adobe, Kodak, and elsewhere who have pushed the field forward and have established standards for other developers to follow. As developers and users catch on, everyone's life becomes easier, image editing becomes more accurate, and there are fewer surprises when images are output on any given device. If you want to revert to Photoshop 4, go for it... the rest of the world will keep moving forward.

--Rich Wagner

___________________________________________________________________________

Fifteen years ago, hardly anybody was sending desktop-generated images to any kind of pro-level output. It was mostly for-position-only graphics, leaving the the service bureaus and printers to manage final output in whatever closed-loop manner they chose -- at big bucks.

Where's the basis for comparison?

Rick Gordon

------------------

On 11/30/06 at 2:41 PM -0500, Henry wrote in a message entitled

"Re: [colortheory] Honoring embedded profiles (was ProPhoto)":

___________________________________________________

RICK GORDON

EMERALD VALLEY GRAPHICS AND CONSULTING

___________________________________________________

WWW: http://www.shelterpub.com

___________________________________________________________________________

Hello Andrew,

Dan wrote (quoting John Castronovo): "he indicated to the list (...) that if a stranger hands him a job,without specifying that it the embedded profile is to be honored, John declines to offer guarantees as to what he will do."

John has considered all the factors and has come up with that policy, strictly speaking he is doing what is best for himself and ,perhaps, for (the majority ?) his customers. His, is strictly a merchant's consideration of the problem and *his* way to resolve it, it does not negate the concept that an image file and its profile are (should be) indissociable.

Dan's pragmatism is probably the correct attitude if you want your 100 images of that wedding correctly done first thing to-morrow morning.

André Dumas

___________________________________________________________________________

It wasn't a comparison - it was an observation that draws a distinction. I will, though, offer another observation.

Pro and non-pro photographers alike can shoot film, pos or neg, send it to a pro lab, and get it processed. Except for certain labs that use a proprietary process and film, the processing is accomplished according to A Standard. Unless the film is of a proprietary brand, it can be processed using the standardized method, and yield fairly predictable results.

The digital corollary has many standards, as if every order to be processed is proprietary. I regard "many standards" as another way of saying "no standard". Others will see it differently. It is only an observation, but it seems to me to be the gist of this thread. In reading, I also sense just a wee bit of denial that a real standard might be necessary. It is almost as thought the thread is screaming for a standard while at the same time it desires the freedom and autonomy of many standards. I say this with regard to commercial workflows, and not to any one user's particular working methods.

Just how many of us would like a more complicated situation? There are solutions, but they will involve compromise.

Henry Davis

___________________________________________________________________________

Rich (and list), I don't have much interest in this particular thread and will mostly stay silent - it is more than enough that I have to keep up with each post as part of my moderation duties. That being said, I would like to comment on your recent post - more in general to the list than directly to you Rich.

The biggest problem for these debates is that they cross over many issues that may or may not be connected and are true for some users in some settings but not so for others.

Most come to the conclusion that for Photoshop images and RGB work, it is a no brainer and that the embedded ICC profile is a good thing. As has been stated many times by many people on both sides of the fence - it is the implementation of colour management that often leaves a lot to be desired, not the basic concept of managing colour (which used to be closed loop, it has always been there where it really counted, in some shape or form).

Photographers and photo labs provide a fairly simple workflow - and that proves to be rather complex! Perhaps it is a "grass is always greener" thing, but I envy the problems faced by a photo lab.

For those in the CMYK world, the workflow and complexity is greatly increased over a simple photo lab workflow. One may have raster images in various flavours of various colour modes and the same for vector images. These are all combined into a page layout that may also be using various colour modes on the native layout elements. Some of these can produce "oil and water" results that never happen in RGB only workflows. One can colour manage manually or use ICC methods. Embedded ICC profiles and ICC workflows in such settings can be of great help and they can also cause major problems at other stages of the workflow - usually closer to output than in earlier production (often outside fo the files creators at a service provider).

Often where problems come up is with poor software design or choice of settings at the service provider that fail to overcome the poorly written software. The problem is most common as either a workflow design issue or a bug/glitch that leads to undesired results. This has been an ongoing issue in the prepress industry and is still common today.

Even the Adobe InDesign & Illustrator CS2 software team had to *finally* accept that a "SAFE" CMYK workflow was needed where CMYK values were not altered based on the embedded ICC tag. Despite the Photoshop 5 colour management workflow lessons! Thus InDesign CS2 had a great new marketing angle (a solution to a problem of their own creation). Idealogy overcomming common sense until InDesign CS2, after how many ruined jobs in the hands of customers? The majority of CMYK users in the majority of circumstances do not wish to have their files values altered (unlike RGB users who depend on this and thus the profile is needed). So now InDesign is workable in CS2, as one can colour manage RGB based off the tag to convert the values in the file, while at the same time ignoring profiles in CMYK objects and not converting their values.

Dan has and continues to do so. The positive advice is to play things safe and attempt to second guess upstream issues so that one is not burnt.

In past threads on this issue, I believe Dan made the following broad generalisations (there have been TOO many of these threads, check the edited list archives at Dan's Ledet site):

Generally RGB embedded tags are a good thing (there will be exceptions such as 40,000 images all having the same known profile, so why tag it - just assume it in the workflow upstream). This is not controversial. Where Dan is controversial is that he understands that the world is not a perfect place and that things can and do happen that are beyond our immediate control. His recommendations are to consider the various pros/cons and to be conservative and or to attempt to second guess upstream actions. This often goes against the idealistic textbook appraoch where software and people all interact with no error.

So rather than rant against his jobs being ruined by upstream users or software that do not understand colour management or worflows correctly and ruin his files, Dan avoids the issue by second guessing them. It is a very pragmatic approach. I am sure that Dan would like things to work as intended, but he is also a realist before being an idealist.

I see Dan's position similar to this:

Yes, once the pedestrian crossing light is green, in theory it is safe to walk. But it is also wise to check the traffic too.

Even if the service provider admits fault and reprints, one may miss a deadline and an important client. Where an embedded profile has no use and can cause problems, the lucky expert will avoid the tagging of profiles. Even if this flies against the conventional wisdom. As has been shown with safe CMYK workflows and automatic colour conversion - conventional wisdom changes.

I think the idea of an embedded tag is good in some cases, but not in others. If the software and human element was not a factor, then there would be even less cases where it was not a good thing. So for me, it is once again the implementation of colour management and how software may behave and human actions, more so than the ICC tag.

It would have been nice if they had been forward-thinking enough to have looked straight to version 6 Rich!

But it is easy for me to be critical, not being a software engineer. Photoshop 5 colour handling was far from fortunate (mis?). But good ideas can evolve from bad ones, so Photoshop 6 colour handling was a good thing. If Adobe had to learn from version 5, then it would have been nice if it was done in beta testing rather than in the hands of users, but we finally got a useable colour tool in version 6 that went far beyond the old model.

I think we can all see where things are headed with Lightroom, at least for RGB and camera raw data. Seamless, simple colour management that is mostly hidden from the user all made possible with well designed colour management software workflows (as the problem is not the ICC tag, but how software and users decide to variably act based on the profile). Profiles are honoured and untagged are assumed, profiles are always embedded.

Very different to Photoshop, that has a rather complex colour management interface (that could be made even more complex to give more control to users and seen as a positive thing by some). Will Photoshop and the industry head in the same direction? It is what we have all been asking for after all. Simpler colour management that is bullet proof for both the creator and subsequent handlers of the data.

We have options in Photoshop and with options come complexity. Can things be simplified but still remain workable while still providing flexibility? I am not sure, as that is where the problems come in!

That is more than enough on the topic from me.

Sincerely,

Stephen Marsh.

___________________________________________________________________________

Hi Dan,

As John has already responded negatively to the above statement I would guess that we're far from 'closure.'

Dan, I read your post very carefully and followed and read through most of the links. I have perused through these articles in the past also and I think I understand your position on this subject very well. My first inclination when I read your views on this subject, however, is disagreement. I am a positive thinker when it comes to the ability of science (along with market forces) to bring positive change to the world.

With that in mind...

I understand, based on my own experience, why, at the moment, this is true. In my own workflow I work with a profiled monitor and profiles for both my printers and scanner. Moving to a profiled workflow was the best thing I've done.

Unfortunately, the reason I went to all the trouble and expense of incorporating this workflow was because my experience with local labs was a disaster! And I can't say if things have improved in the past two years because I've eliminated outside labs from my 'loop.' I don't think that was ever the intent of colormanagement.

To be fair I should actually go pay my local lab a visit and see how much they've learned since I was last in; I know I've learned a lot!

Nevertheless, I'm still an optimist! I do honestly believe that the concept of color management and the embedding of profiles is a good one. It just may take awhile for it to become mainstream. It's still in it's infancy. As old printers/photographers die off and new printer/photographers enter the field they probably won't even realize what "all the fuss was about!"

And best of all, a professional's work will still be easily distinguishable from an amateur's because as you have said many times, Dan, "Machines and humans don't see things the same way!" A pro will always be able to make his prints look better!

Murray DeJager

___________________________________________________________________________

From: "Stephen Marsh"

Don't be so sure about that grass is greener bit. Not all RGB workflows are simple. We often need to convert those same page layout files for RGB printing, so for example we're often dealing with duotones and tints of PMS colors that have no correlation to RGB at all. The same issues apply in that there are many incongruous elements on the page, plus we have to deal with the issue of interpreting mystery CMYK conversions when we have no clue about the press conditions they were intended for. I'll accept that there may be cases where CMYK profiles may need to be ignored because I'm not in that end of the business, but it would sure be nice to have them when we're not printing on a press.

Ideally, printers should be able to ignore CMYK profiles if they get in their way, but leave them embedded if they can be a help for someone else, IMHO.

john castronovo

___________________________________________________________________________

John Castronovo wrote:

I am not making slight of your type of work here John, I have to do similar as well at times for clients wishing to use stuff in MS Office or whatever RGB useage. For work originating from my studio, there is not too much problem as prepress is considered and built into every design/concept job. It is work presented from outside designers that is the problem. Even the "print ready" jobs are not ready for imposing or output straight off the disk as "print ready" would imply.

The complexity I was referring to that does not exist in RGB settings is using overprints/combinations of spot colour and process colours for separated output, or gradations between spot colours and process colours for separated output, or transparency features/blending modes in illustration/photos/layouts and spot colours and or CMYK combinations etc. All the things that relate to separations, that are not an issue in composite CMYK or composite RGB settings (although transparency flattener issues can affect composite RGB or CMYK users too).

No argument there for your type of repurposing work John, but that is the issue for me - I am not repurposing/reseparating, I want those values!

Recent case in point. The unlucky expert rides again, this time with the lead role being played by yours truly. <g>

* I am asked to send a CMYK job out to get film made in a rush, I did not have time to do my usual workflow (mistake #1). After nearly twenty years in the game, I should know that it is not worth rushing something out when a problem can create even more time wasted than the delay it takes to double check things.

* I usually create a pre-separated CMYK PDF and then recombine the seps and run a rough proof before sending off the file for film output at the local service provider. In this case there is only time to send a *composite* PDF (mistake #2). If you prefer not to trust that the next person will make the seps as expected, do it yourself - which is my standard workflow when I have the time.

- But in "theory" there should be no problem with sending a composite CMYK PDF to a service provider to make a set of negs and an inkjet press simulation 'proof' of the data on the negs. The CMYK numbers go in and the same CMYK numbers come out, don't they?

* I receive a call from the SP that due to an ICC profile being present in my composite PDF (mistake #3) that their RIP had automatically reseparated the input CMYK values based on the ICC profile and had created new seps. Thus all the black only elements such as hairline rules and text was now in four colours and 90%K rather than 100K only and the pastel blue background had turned mauve with higher magenta values. The film was output. I was asked to resupply the PDF with the profile stripped and that we would be charged for new film a proof. If they remove the ICC profile, strange things may happen to the PDF such as text failing to output or other output glitches.

Simply having no ICC profile in the composite PDF stops their RIP from automatically reseparating the job.

* Usually I do not tag output ready files, but obviously not this time. They are useful in-house, but less so when sending a final job out that will never need any future reseparation.

We have had this similar story repeated many times in the past by many different people. Yes, we know that service providers can be less than helpful and appear to sabotage jobs and if only they would educate themselves and use the right settings then there would be no problem. The problem is not the ICC profile but the implemented CM workflow, software and people using it. If one does encounter these problems, simply vote with your wallet and shop elsewhere etc.

Meanwhile Dan, myself and other practical minded people have no problems accepting that theory does not always work as expected when applied in the real world and that it is best to avoid problems in the first place.

Agreed, but the world is not ideal. It pays to observe and think rather than just parrot conventional wisdom that may have little application to your particular environment.

This is the message that Dan tries to impart to his students. It starts with simple curves and image evaluation by the numbers and spreads into many other areas of our professions.

Rich has recently been asking Dan for specific recommendations on various workflow aspects (that for the most part are a side issue to the main focus of Dan's CMYK output experience/commentary). For me, that is not what Dan has ever been about. The reason for his popularity as an author is that he teaches his readers to *think for themselves*, rather than just presenting a cook book or canned reply. Dan can do that too, but I believe that the greatest contribution that Dan makes as an author and educator is encapsulated in this old (Chinese?) proverb:

"Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime."

Sincerely,

Stephen Marsh.

___________________________________________________________________________

On Dec 1, 2006, at 12:53 AM, Richard Wagner wrote:

Just to be clear... there is some confusion on this point and you have to read the whole post carefully to understand it. The biggest problem for the lab is NOT with customers who knowingly strip profiles but with customers who use profiles improperly. If there is no profile – in almost every case I've seen the worst case scenario is that the customer is working in monitor RGB - if we assume sRGB we are generally 85-90% OK. Sometimes ARGB is a better assumption and we don't pickup on that just by looking but the point is we generally don't guess TOO wrong!

However, if the customer ASSIGNS a wrong profile or "converts" to Epson RGB and then "assigns" Adobe RGB (don't laugh - this has happened!) things get REALLY screwy! The complexity of color management is just too much for many people and a service bureau now has to really be on guard against stupid mistakes in profile management/application for a wide range of situations that never existed before color management. Our customers can have very "creative" ideas about color so we cannot automatically make assumptions about wacky color that we see if there is a normal profile tag – but from personal experience it takes the misapplication of a profile to really screw up the color! If there is a profile tag, we just never know if the color is going to be right or not. If there is NO tag we can generally guess right ENOUGH almost 100% of the time! This is, of course, not ideal but simply a fact of life. I'd much rather have all customers CORRECTLY tag their files – however, there is nothing in color management nowadays that can guarantee this.

This DOES NOT MEAN that color management doesn't work!!! Color management doesn't kill color - people kill color. BUT... color management, in and of itself, does not make life easier for the service bureau dealing with the unwashed masses. I think we HAVE to make a distinction between pragmatic workflow policies and ideal workflow policies. I ALWAYS try to educate customers on the proper use of color management but sometimes there's nothing you can do – for some people its actually safer to have them do as little as possible with color management just so they won't really screw up.

I'm hopeful that eventually color management will get more bullet proof with regards to the majority of imaging workflows and still allow for creative controls that advanced users can take advantage of. Progress is being made – it just seems slow to people frustrated by the mismanagement of color management.

regards,

Lee Varis

President, LADIG

___________________________________________________________________________

Is this really possible? How can color management ever be bulletproof and easy? We have a "standard" of sorts, basically set by the web community and followed by a lot of camera vendors, that sRGB is the default workspace we should all use. All of the Fuji and Noritsu machines assume sRGB, often choke if you send them something different (apparently varies from machine to machine). If the goal is to make it "easy" for everybody, we all need to just live in an sRGB world and be done with it.

Making Prophoto the "standard" doesn't fix anything. Depending on your workflow, it could make things worse, in that you can edit a photo and get a certain result on your monitor, then send your properly tagged ProPhoto image out to be printed and discover that it looks NOTHING like what you created on your machine. So, it looks like color management failed.

But there's the rub. Most people, unless they REALLY REALLY want to know this stuff, want to look at a monitor, edit, and get what they see. They don't to look at numbers, or juggle profiles or any of this "computer" stuff. Let's face it, most photographers like to use their camera. they don't like using the computer. And they probably passed up Trig in high school and took extra art classes. They hate numbers. There are not a lot of left-brain/right-brain people. Most people tend toward one or the other.

So you still need someone around who likes numbers, who likes screwing around with the computer, to deal with all your color management issues. But here's the other problem: all the color management companies have pushed all this stuff through by saying it makes things easier. No need to hire somebody to deal with this, we put it in all the software. Now no one wants to budget for a guy to sit around and just monkey with profiles. We were sold cheaper production and ease of use. I'm not bringing somebody in to deal with that.

So you get people who aren't suited for this sort of work who are FORCED to deal with it, often with disastrous results.

The good thing/bad thing about standards, is they are usually a sort of lowest-common denominator. Yes, it puts limits, but it also means nothing goes disastrously wrong, we've all reached a certain plateau. ProPhoto doesn't seem like a good standard at this point, if not because of issues trying to edit in the space, but for the fact that if you work and tag everything with ProPhoto, you have to hope and pray and slaughter chickens to make sure somebody down the line knows how color management works. And you still won't get what you see if they're not using an Epson printer. So the onus is still on you, the originator of the file, to make sure you edit and tag so that it won't get ruined down the line.

Or just tell your clients "I do what the standards body tells me, I can't help it if somebody else down the line screwed up."

But the real question is, what have the standards bodies really done? There are myriad examples of manufacturers either outright ignoring or throwing out parts of the standards to get a machine out the door in a hurry, or because they want to make you adapt to their workflow so you can never just pick up and go to another provider. Web designers have been putting up with this for years. There are standards, but no one can blindly follow them because, dun, dun, dun, they don't work on IE. So you throw the standards out the window and you design in a way so that websites look right on IE, where your clients are looking. And it's because standards bodies HAVE NO POWER. Simple. Nobody has to do what they say and being the early adopter, in the hopes of leading the way, is a recipe for being unemployed because you don't work the way everybody else does.

In fact, there's a lot of web designers now who are just saying "Forget the standards bodies, they're not doing any good." And in a free-market capitalist system, the company that sells the most machines wins, not the one that follows standards. It's the problem with enforcing standards from outside rather than just looking around and figure out which system the market has chosen and shoot for that.

Which obviously doesn't make for pat answers.

Matthew Rigdon

___________________________________________________________________________

From: "Stephen Marsh"

I wish I could charge for my problems like that. I just had a PDF last week that didn't output correctly due to a transparency issue that the RIP didn't like, but I fixed it and did the job over at my cost rather than blame the customer who prepared it. It was a low bid job too - one that was supposed to just drop on the RIP and print. Is it common practice for service providers to make customers pay for remakes due to their RIP workflow errors? If so, that's the problem in a nutshell because it will never get fixed. Meanwhile, I suppose I must agree with your more pragmatic defensive driving approach.

john castronovo

___________________________________________________________________________

I need to clarify my position further.

I always ask that my customers provide images with embedded profiles so that we can provide profiled results, if that's what they want - some don't because they don't trust their own workflow.

The difficulty is when we get orders without instructions. The lack of communication from the customer is the issue and this is mostly a problem with amateurs, many of whom are also in business and commercial settings. Without their instructions, the options at the lab are:

1-educate them at our cost (not always possible and sometimes it makes us look worse because "we're so much trouble")

2-attempt to make the best looking image for the price (most people have always wanted this in photo printing)

3-guess to match what the customer probably saw on an unknown display (dangerous)

4-just run it through the machine and let the customer adjust his files for the next time (what most labs do)

5-convert from an embedded profile to our printer profile (best for everyone, if we have an understanding with the customer that the image has been corrected already, see #1 above)

Clearly, the choice depends upon our communication with and evaluation of the customer. That's what I mean when I say that this is the most difficult part of the job, not that all bets are off when we print an order.

john castronovo

___________________________________________________________________________

On Dec 2, 2006, at 6:45 PM, Stephen Marsh wrote:

Fine, but the "conventional wisdom" may apply to the vast majority of cases, and when it does, ignoring it causes unnecessary problems. There are those who think zebras every time they hear hoofbeats, even though they may be standing in (and getting trampled by) a herd of horses.

Dan is without a doubt an excellent practitioner and teacher of image correction, particularly for pre-press, and particularly when starting with bad images. However, those are not the only skills needed by people who use Photoshop as one of the tools of their profession. There is a huge population of professional Photoshop users who are not working in pre-press departments, who need to know how to use Photoshop for output to devices other than just 4-color offset. The advice that is applicable for CMYK presses is not necessarily applicable to other devices, and these differences are often ignored or downplayed. For those working in pre-press, even the printing world is moving aggressively towards color management and better standardization, such as that described by GRACol 7. There is an excellent 3-day workshop on color management for those in the printing industry that starts tomorrow, sponsored by PIA/GATF (www.colormanagementconference.com). Remote proofing and approval are now a reality for many publishers. None of this would be possible without ICC-based color management.

To "think for oneself" one must be aware of the options. In many ways, this List reminds me of Plato's Allegory of the Cave. People are content with their workflow and what works for them, and they fail to realize that what they are seeing are only shadows of what exists outside the cave. They are afraid of what they have been told exists outside the cave, and therefore they are unwilling to leave the cave and explore. Anyone who leaves the cave and returns with wonderful stories of what they have seen outside is considered to be crazy or a liar and is attacked relentlessly to protect the status quo.

Dan appears to be strongly anti-ICC workflow (witness most recently his method of "calibrating" the monitor of his new computer), yet that is the direction that the majority of the imaging community is going. If Dan's students are to "make choices," there should be discussion of the advantages of different color spaces, and recommendations on the advantages and disadvantages of each, so that the student would have resources on which to base decisions. Instead, none of that discussion exists, and useful information is replaced by anecdotes and fear, and the only recommendations are of what *not* to do. As I mentioned previously, a reader of Dan's Lab book would have no idea how to rationally choose a color space, as the discussion of the differences between color spaces simply does not exist in the book. Is it a book about Lab? Sure, but images seldom start out in Lab, and Lab is seldom the ultimate destination. I haven't seen the new PS book, but again, if this is a book for the professional who uses Photoshop as a tool, a discussion of workspaces and the Photoshop preferences should form the foundation of the book, as these are the first (and often most important) decisions that users must make, and users in the workforce will often have to deal with images that are not in sRGB or SWOP.

Lastly, there are real expectations in the global workplace about how image data is communicated. Millions of images are moved between buyers and sellers though agencies like Corbis, Getty, Alamy, and other stock agencies. There is the expectation by photographers, the agencies, and the purchasers of the images that these images will comply with an ICC workflow. There is a reason that ASMP and UPDIG have developed image distribution standards, and it is primarily to facilitate commerce. **Not** advising students to generally follow the standards, and instead advising that "If you are certain that your workflow won't let anyone convert (or fail to convert) it improperly later, use Adobe RGB" goes against the grain of *all* current recommendations and invites trouble. It is this kind of advice that encourages users to strip profiles from images before passing them on, creating chaos down the road where there would otherwise be little. If you want to teach someone how to deal with the exceptions and difficult cases, you must teach the general rules first, or the student goes away thinking that every case is an exception or is unusually difficult.

Teach him how to sail and navigate, and he can feed himself and the masses, and create a viable fishing industry.

With regards,

--Rich Wagner

___________________________________________________________________________

On Dec 2, 2006, at 8:26 PM, Matthew Rigdon wrote:

Matthew,

sRGB is a standard for WEB use, but it makes a lousy standard for other image uses. Making it "easy" for everyone by resigning every image to sRGB would limit image quality for everyone to the lowest common denominator. sRGB is a terrible color space for many uses, and most professionals and certainly archivists would find that unacceptable. Even Kodak imaging kiosks that allow consumers to insert digital camera memory cards and "edit" and print images on the spot take advantage of extended gamut JPEG 2000 format images from cameras. That format can contain data in ERIMM/ROMM (= ProPhoto), giving the advantages of editing/printing in a much wider color space than sRGB. Software that can read JPEG2000 can also use the embedded profile to convert the image to a video RGB color space like sRGB when it's needed. There are ways to make life "easy" without resorting to the lowest common denominator. In addition, most cameras now allow users to shoot in AdobeRGB or RAW, so the likelihood of everyone regressing to sRGB is essentially nil. The masses want better quality, AND an easier workflow. The two are not incompatible.

Well, Microsoft's biggest change with the newly released IE7 was to conform to W3C standards. Microsoft has discovered that they're not the only game in town, and that by not conforming with standards, they're losing market share. They're tired of being the brunt of jokes and books on Microsoft IE "hacks and filters." For the developers who have been writing to standards and including Microsoft- specific "patches" to their code, it will be trivial to update their sites for IE7 - just disable the patches. For those who have written IE-specific code and blown off the standards (and the other browsers), well, they're going to have a lot of work to do.

"Internet Explorer 7 contains a number of improvements to cascading style sheet (CSS) parsing and rendering over IE6. These improvements are aimed at improving the consistency of how Internet Explorer interprets cascading style sheets as recommended by the W3C in order that developers have a reliable set of functionality on which to rely. In some cases a few of these changes may have the effect of making existing content render in ways that are not compatible with IE6 [or any previous version of I.E.]."

http://msdn.microsoft.com/ library/default.asp?url= /library/en-us/IETechCol/cols/dnexpie/ie7_css_compat.asp

http://tinyurl.com/b245h

"When development of Internet Explorer 7 began, one of the key efforts was to address the comments and concerns of web developers. Among the most persistent requests was for better compatibility with the W3C Cascading Style Sheet (CSS) working draft. As a result, Internet Explorer 7 has improved support for CSS 2.1."

http://msdn.microsoft.com/library/default.asp?url= /library/en-us/IETechCol/cols/dnexpie/ie7_css_ZenTek.asp

http://tinyurl.com/y8bgwk

Standards exist to make life easier and more fool-proof. That's why we have standard electrical voltages, nut and bolt sizes, internet protocols like TCP/IP, JPEG, and so on.

--Rich Wagner

___________________________________________________________________________

Bob Frost writes,

But then adds,

Now I'm confused. If the files are in Adobe RGB, then why is the lab getting sRGB? Is this your standard workspace?

If, OTOH, you are *converting* them to sRGB because you don't trust the lab to honor an embedded profile and don't wish to have your job destroyed in consequence, then it is hard to comprehend the purpose of your post. You seem to be attacking what I said, but what I said was that few are masochistic enough to trust a STRANGER to handle an EMBEDDED profile. If you are converting to sRGB because you are afraid of what this stranger might do with a tagged Adobe RGB file, you're acknowledging the truth of that statement.

If you feel that this is *not* the way the world should operate (or if you're a masochist), your course is clear. Stand up for principle. Give the files to the strangers in tagged Adobe RGB. Absolutely do *not* tell them the tag is there. This would simply encourage laziness on their part! After all, as you say, surely the formal communication *is* the embedded profile. It is their responsibility to get it right without being told--that's the whole point of the embedded profile, no?

If they do mess your job up, it's not *your* fault--it just proves that they're stupid or lazy or both. You can tell them what fools they are and how they are stuck in the past and how resistance is futile. That'll teach 'em! And maybe it will make you feel better, too, as you think of how to explain what happened to your client.

Dan Margulis

___________________________________________________________________________

On 2-Dec-06, at 8:26 PM, Matthew Rigdon wrote:

The reason it's not easy is that even though the theory of a calibrated workflow is relatively straightforward, the implementation is anything but.

I'm talking about the chaos caused by a large group of uncalibrated/random "users", not the difficulties in diverging from "common" practice for creative purposes.

It would be a much different situation if color management were dead simple to install and use. Everyone out there could be running a color managed workflow, and then the debate could properly be focused on the best workflow/ colorspace for a given purpose.

I suspect much of the difficulty lies in the large group of users who are struggling to maintain/achieve a color managed workflow, or who have tried to do so and given up.

To begin and maintain a profiled workflow means wading through too much complexity in dialogue boxes, Photoshop settings, and choices in the print drivers for many people.

Inevitably, things go astray and so the hunt is on: where *is* that profile stored? Why do there have to be so many places to store them? If I have special software/hardware on my printer that makes a custom profile, why can't I access it? Is it hidden? How will I know it by name if I do see it? Etc., etc.

Spend even more time in your life on the help line, looking through install disks, manuals . . .

Who can say that they haven't been frustrated in this way? I can imagine a few replies to this from the usual suspects. "It's not that hard", "Just get this package" and "This is nothing compared to channel blending,"etc. To them I would say: your job is working with these tools 40 hours a week so it's hard for you to relate to the average photographer/Photoshopper who spends as little time as possible being a computer weenie.

A whole bunch of people and organizations are in charge of this situation which is another way of saying that no one is.

A standards committee of Adobe, Epson, HP, Canon, Nikon, Microsoft, Apple, etc. could solve it, don't you think?

Ron Kelly

___________________________________________________________________________

On Dec 2, 2006, at 10:41 PM, Richard Wagner wrote:

Which works fine in a world of press releases. Unfortunately, out in the real world, here's what web developers have found (http:// www.idealog.us/2006/08/microsoft_drops.html http: //www.gtalbot.org/BrowserBugsSection/MSIE7Bugs/CWilsonMSIE7AndCSSCompliance.html). Which isn't to turn this into a Microsoft web discussion, but to point out that it's easy to follow standards in the marketing department.

But it gets back to the issue that many are running into, that standards bodies really can't do anything. So what's the point? You have to work with what you're given. You seem to keep harping on Dan to create a new "standard", for whatever reason. I read the LAB book , too, and i noticed that it never talks about profiles or color management. And you what? it didn't bother me because it was a book about LAB. I didn't expect a discussion of those other things. Just like I never expected a discussion of concrete in my statics classes in college, or a discussion of material science in my boolean logic classes.

In most cases, they became standards because the competitors just went away. TCP/IP just happened to be the protocol for Arpanet. Once upon a time, people used AOL and Compuserve and Prodigy, which were just dial-up systems. I doubt they were built on TCP/IP. I know that early Novell networks weren't and even Microsoft's early networking wasn't built on TCP/IP. TCP/IP became a standard because the market chose it, not because anybody decreed it.

I know too many photographers myself who just want to take pictures. They don't care about profiles or soft-proofing. They get pissed off because they want to see what they shoot on their monitor. Otherwise, why go digital? If you don't want to see it on your monitor, and then have everybody else see the same thing on their monitor, and it come out the printer the same way, why go digital? You can shoot film and just guess at your results. And I would have to say to a lot of people, whether I use or like sRGB, just go with an sRGB workflow. Forget what the standards bodies say, it's the one that's winning out there in the marketplace. Most labs that use the Fujis and Noritsus say "send us sRGB". It is the profile ligua franca of the internet. Every dSRL I'm aware of has sRGB embedded as the default color space. And if you edit in sRGB, what you see on your monitor is what you'll get out of your Epson printer. Why swim upstream?

I know you keep putting Dan on the spot, but tell me, for the people I work with, who want to see on screen what prints out, who don't want to hear about how it "looks different on my friend's PC than it does on my Mac", how switching them to ProPhoto RGB is going to make those things go away?

On Dec 3, 2006, at 11:52 AM, Ron Kelly wrote:

Name one thing that these companies have gotten together and fixed, lol.

Matthew Rigdon

___________________________________________________________________________

Matthew:

I didn't use the smiley guy.

Next time I'll make it reeeeeel clear when I'm being sarcastic.

Ron Kelly

___________________________________________________________________________

"john castronovo" wrote:

When the film shop called, I commented that it was not right to have their RIP automatically converting my colours to something else - even more so with no warning from them that this will happen (if an ICC profile is in the PDF). And then to want to charge for that on top of everthing else?

To be fair to the SP, they did not charge for the new film or proof and I stressed that I would try to ensure that none slip into future files.

There are not many choices around today in our area if you want film within 24hrs. It is hard to vote with your feet. Eventually we will be forced into some small run direct to plate setup to replace film and camera ready plates, but that day is still not here for this small shop!

So, the job was *only* a day late to press after all that. Like I said, I prefer to send pre-separated data than composite where possible.

Yes, agreed John, there is no easy answer as the service provider (I am one too) has to do a lot of non billable work to make jobs fly.

Sincerely,