Assign Profile vs Converting to Profile

[Printer_Rick]

This relates to a very lengthy thread in the InDesign forum, "RGB vs CMYK images and resolution"

I have a lot of questions (perhaps confusing) relating to RGB color gamuts. To simplify let's start with 2 gamuts, ProPhoto and Adobe RGB

I have a profile editor that can view both of these within potato-shaped Lab gamut. They are of course both triangles, I believe all RGB gamuts are. I can see ProPhoto is considerably larger than Adobe RGB, containing more fringe colors

I also see that the gamma of Adobe RGB is 2.2. The white point is 6500K

The gamma of ProPhoto is 1.8. The white point is 5000K

I understand gamma to be "black point". Or better yet "black density". On a press sheet, ink density can be measured with a densitometer. In my experience a density reading of 2.2 on a press sheet would be very dark. Is my understanding correct - that gamma (RGB) is comparable to ink density (CMYK)? Perhaps better to state as an analogy: Gamma: RGB as Density: CMYK

My monitor RGB profile has a gamma of 1.8 (mac standard). This tells me that the Adobe RGB gamma of 2.2 has to be re-interpreted on my display. Is that correct?

As for white point, that would be the RGB equivalent of CMYK paper white.

The InDesign forum has a lot of discussion about assigning profiles, vs converting to profiles. My understanding is that assigning a different RGB is actually a "pure" conversion. The pixels are left completely intact. There is no move to Lab, and back to RGB. It's taking the image and effectively dropping it into a brand new gamut, The price for this, of course, is that the appearances of the colors are completely redefined, and this appearance shift can at times be radical.

For example, if I have an ProPhoto image open, then assign Adobe RGB, I can see very clearly that the image becomes darker on-screen, and the color "shrinks"

As a prepress person, I have often used re-assigning in RGB mode as a very effective color correction tool. Usually it's turd polishing, to be quite honest, when critical color match is not an issue. The scenario is usually a crappy sRGB image. I assign Adobe RGB, which as the Adobe description states is ideal for conversion to CMYK. I must add that I always use proof preview, I am well aware that Adobe RGB has colors far beyond a standard CMYK gamut. But when I convert to CMYK, using Adobe RGB as the source, the image color is expanded, and the result on press is often vastly improved.

I will also add that as a prepress person, I don't go re-assigning in this fashion without the customer's consent.

In the InDesign forum, this "re-assigning" has been referred to as "random color". There is a lot of emphasis on color appearance, and maintaining color appearance. The consensus therefore is that if you had an sRGB image, you should convert to Adobe RGB. But then it is my understanding that you miss out on the often huge benefit of gamut expansion. If you wanted to expand color after converting, you have to do color corrections, which alters the pixel data and in the strictest sense is destructive (unless you use adjustment layers).

All this leaves me wondering - if assigning is such a no-no, why is it available? Probably the main reason for the assign capability is to assign profiles to images that don't have an embedded profile. Sometimes users unknowingly discard profiles, if the color settings policy is set to off. When another user open the image, he quickly sees the image does not have a profile.

Normally he would assign his working space, since that is affecting his visual on-screen appearance. But he can't know for sure if that's true to the original capture.

Which brings up another point. Any device doing the capture (camera or scanner) has a gamut. This gamut is an input profile.  When the image is translated from device capture into digital file, should this input profile be embedded in the image?

At this point I'm not sure about this. I have a 7.1 MP camera, and the downloads always have sRGB embedded. Not a profile specific to the Kodak model. My guess is that sRGB is a universal standard, representing the gamuts of monitors and desktop scanners. It is the working space of the world wide web. So it's more or less the default RGB, and is also the default working space in all Adobe applications (North America general purpose).

But the description of sRGB is very clear. It is not ideal for prepress, this is stated in Adobe's description. It is small. This may make it comparable to CMYK, but it is still not ideal for conversion to CMYK. And in fact there are CMYK colors that fall outside of sRGB. Especially if you are dealing with the larger CMYK gamuts corresponding to new offset screening technologies (FM screening and concentric screening)

So why in the world would someone convert from sRGB, to Adobe RGB? There's no benefit at all. May as well leave it sRGB, instead of converting. And the even bigger question - how do you know that sRGB is "true" color? To me, the true color is the original subject. In the case of a photo, that might be just a memory. In the case of a scan. it's the original, but the user might not even have that, if someone else did the scan and all he has is the digital file. So who's to say that the embedded profile - sRGB - is a fair representation of the original?

Re-assigning RGB profiles may be an odd way of adjusting color. But it can be effective. Why would the assign option be readily available, if not to translate colors to a different gamut, without altering pixel data? Seems to me it is the primary reason Adobe developed the assign option in the first place.

I know this is a lot of questions. Any input on any of these matters would be greatly appreciated.

[Miguel_Curto]

Mike, (again getting off-topic) couldnt you do that with smart-objects?joining diferent color spaces in same document?IF if the parent document gets changed or altered it would take significant efort to mess with the file embeded in smart object.Maybe there should be an option to password-protect the color space in a smart-object or its maybe im just getting confused...gonna check "device N color".Thats new to me...

[Mike_Ornellas]

Well, I guess I'm the king of off topic because I don't stay between the lines in life.

What you are referring to is a parent child association. What I'm talking about is a layer based form of color management within a single master document.  One of the big problems with SO's is that it's a nested object and you can only do so much with a nested object.  Things like blending modes don't transfer when multiple objects are places in a parent document. It's the nature of the beast.  It's the same situation that happens when you create a drop shadow on a Photoshop document, then place it in In Design over a color fill for example. You get a knockout and not an overprint of the object.  High end work stations such as Dalim make Adobe products look like child's play when it comes to object based editing and control...

But I digress-

Color management needs to come around at some point because the implementation is greatly flawed in many ways. It's far better then what we had many moons ago, but it's time for an upgrade.

[Printer_Rick]

Mike Ornellas wrote:

In order so support device N color  -  Adobe needs to supply a check box in the layer color fill dialog box that deems said layer object as color space neutral so when you convert the file from one color space to the next, you preserve the numbers of that layer object. The rest of the file gets converted to the destination space.

Sorry, thought you meant I needed to put a check box, I misunderstood.

That would be a good feature, hope they add it some day. It would definitely solve the drop shadow problem and color build problem. But if I understand correctly, as you said integrating spot color support in a color space would require a total overhaul.

Maybe that's best. I think a color space that included spot colors would be a nightmare, more trouble than it's worth...

[Mike_Ornellas]

Maybe that's best. I think a color space that included spot colors would be a nightmare, more trouble than it's worth...

not really -

All you need to do is link a color fill layer object to a channel .  I'm sure it easier said then done, but that's the concept.

[Printer_Rick]

Mike Ornellas wrote:

not really -

All you need to do is link a layer to a channel that has a color fill object.  I'm sure it easier said then done, but that's the concept.

Mike, that's a good concept. That's not what I was picturing though. I was thinking of a whole new color space. I user would pick however many spot colors he wanted to include in his space. Then convert to it. That would be bizarre, and a real mess.

Nothing wrong with getting off subject, Mike. Relating to the subject and color management workflows:

Re-assigning is not part of valid workflow. A good color management workflow would be good photography – good design – good output. All conversions, of course. I just think re-assigning is an effective way of resetting color, in the event of bad photography, where a good design is the goal, and maintaining color appearance is not the goal.

I have to stress all these points, in case a novice reads this thread and thinks "hey let's re-assign everything". That truly is wrecking color management, and in most cases would be very counter-productive.

As I stated earlier I believe PDF output is Adobe's solution to the color management problem. This is not usually PDF output from Photoshop, it is PDF output of placed images. The solutions aren't completely ironed out yet. I believe Adobe needs to continue efforts to make color management in relation to PDF output simpler, so that color conversions stay true to intended color.

But there is progress and I believe color management workflows will be much easier to build one day. Maybe if the apps included a way to package profiles, output settings, and color settings for a single workflow file transfer, that would be a good start.

There is a related thread in the color management forum (wow that place is an empty room, isn't it) I started called Source profiles, I got some support there along with a good explanation.

[Mike_Ornellas]

I just think re-assigning is an effective way of resetting color, in the event of bad photography, where a good design is the goal, and maintaining color appearance is not the goal.

I agree.  You need to have the flexibility to re-assign a color space to images as needed. But to allow it to happen as open as we have it now is a real bad idea in my opinion. The reasons are many and you have pointed out a few. We need to find a happy medium between flexibility and control for the masses.  I think I got it, but it falls on deaf ears often...

oh well...

As far as PDF being the be all end all solution for color management, I dont think that's going to happen because that architecture is a well - way to opened and Adobe likes it that way even though it just wreaks havoc all over the place.  I feel color management needs to start as far up stream as possible and that is at the capture stage. What happens in the PDF, we really can't control much considering the way Acrobat deals with images. But - there are a lot of thoughts about how to reintegrate mystery meat files as well as known color space files back into management.  It's just less managed then the original files due to generation loss.  We can't do much about that, but we can try and retain what's left of the files color history.

[Printer_Rick]

As far as PDF being the be all end all solution for color management, I dont think that's going to happen because that architecture is a well - way to opened and Adobe likes it that way even though it just wreaks havoc all over the place.  I feel color management needs to start as far up stream as possible and that is at the capture stage. What happens in the PDF, we really can't control much considering the way Acrobat deals with images. But - there are a lot of thoughts about how to reintegrate mystery meat files as well as known color space files back into management.  It's just less managed then the original files due to generation loss.  We can't do much about that, but we can try and retain what's left of the files color history.

Well said Mike. Yes, a lot of mystery meat in PDFs and that is a problem...

On another note, anyone's help on this. Good Pro-Photo capture. This is going to US Web Coated (SWOP)v2. My thought is ProPhoto - CMYK, one conversion. Is there ever a benefit to Pro-Photo - Adobe RGB - CMYK? I can't image there is, you lose colors either way. But maybe color corrections in the smaller middleman aRGB would somehow be more effective...

[Guest]

Printer_Rick wrote:

On another note, anyone's help on this. Good Pro-Photo capture. This is going to US Web Coated (SWOP)v2. My thought is ProPhoto - CMYK, one conversion. Is there ever a benefit to Pro-Photo - Adobe RGB - CMYK? I can't image there is, you lose colors either way. But maybe color corrections in the smaller middleman aRGB would somehow be more effective...

No benefit to ProPhoto > aRGB > CMYK.

Likewise, there's no benefit to sRGB > aRGB > CMYK (as has been debated on the Indesign thread.) Well, that's not exactly true. There is be a benefit if you're going to introduce colors into the aRGB file that are not in the sRGB gamut during editing - like blues and cyans. sRGB hacks out a good chunk of the blue/cyan spectrum contained in most CMYK spaces.

[Printer_Rick]

Thanks Rick, and thanks to everyone else for the good information. Color managing images is always a good discussion.

[Mike_Ornellas]

Color management is more of an oxymoron.  It should be coined "color manglement"

It's more descriptive...

[Guest]

The Color Manglers. A proto-punk band in a dissonant groove.

[Was DYP]

No benefit to ProPhoto > aRGB > CMYK.

Assign No. Convert Yes, in certain situations, you will be able to keep detail in highly saturated colors. ProPhoto > Colormatch RGB > CMYK might be a better choice. But again it is the final output you're after so keep all options on the table.

[Miguel_Curto]

Was DYP wrote:

No benefit to ProPhoto > aRGB > CMYK.

Assign No. Convert Yes, in certain situations, you will be able to keep detail in highly saturated colors. ProPhoto > Colormatch RGB > CMYK might be a better choice. But again it is the final output you're after so keep all options on the table.

Sry to disagree (but since this is a discussion forum guess its ok)

If youre using such a wide gamut profile as Kodak ProPhoto (wider isnt the same as better thought) I fail to see why on earth you would convert it fisrt to a profile that cilps cyans,blues and greens as well as a lot of yellow (AdobeRGB clips a lot of yellow too) from your final CMYK.

Both were designed as screen profiles,good ones but never the less screen ones.

[Guest · Accepted solution]

Printer_Rick wrote:

Re-assigning is not part of valid workflow. A good color management workflow would be good photography – good design – good output. All conversions, of course. I just think re-assigning is an effective way of resetting color, in the event of bad photography, where a good design is the goal, and maintaining color appearance is not the goal.

I have to stress all these points, in case a novice reads this thread and thinks "hey let's re-assign everything". That truly is wrecking color management, and in most cases would be very counter-productive.

Rick -

Well said. I was just about to weigh in with the point you just made above.

A solid, well-patrolled color managed workflow is essential to being profitable at every step along the way. As soon as the color-managed chain is broken, dollars start flying out the window.

When resurrecting a basket-case file (whether it's untagged or just plain crappy), you can definitely use every trick in the book, including assigning wack-o profiles to the image. Nothing wrong with that. The problem, of course, is that everyone is so touchy about the entire subject of color management that the mere suggestion of such a solution ignites all sorts of heartburn. The distinction you make between following best practices in a solid workflow versus stepping out-of-bounds to solve an isolated problem is very good.

[Printer_Rick]

Sure hope I didn't kill this discussion. Ramón's suggestion to review the other thread is good advice, I hope everyone gets a chance to do it.

Lots of things said here so far go well beyond Assign vs Convert. That's OK. If I could rename this thread "Color Management discussion" I would gladly do it.

Jeffrey_Smith wrote:

I am not in disagreement at all with this statement, but I would ask the question to any commercial printer, what scenario produces the more reliable and predictable outcome more often?

1. Ignorant and bliss people (including everyone in the process: photographer, designer, prepress, pressman, etc.) who subscribe to the CMYK conundrum.

or

2. Skilled and knowledgable people subscribing to sound CM practices, but with one hiccup, can be headed down total color mismanagement

Jeffrey, before I attempt to answer your question, can you answer this: in option 2 you refer to a hiccup. In your opinion where is this hiccup most likely to occur?

Now another general question for everyone, regarding custom RGB gamuts:

Like any other RGB gamuts, custom RGB gamuts can be assigned to images. Consider this example

1. Adobe RGB tiff image. Convert to profile - Custom RGB. Change name to aRGB 1.8, change gamma to 1.8. White point is 6500K, primaries Adobe RGB.

2. Save as tiff with different name

3. Run Applescript "extract profile" on this new image. Put the new profile in Colorsync profiles folder

4. You can throw away the new image, you don't need it now that you have the new profile

5. Open the first image and assign the new profile

In everyone's opinion, in step 5 what is really happening to the image? I have follow-up questions but I won't ask them yet.

[Jeffrey_Smith]

Printer_Rick wrote: In your opinion where is this hiccup most likely to occur?

Let's use the same participants in the color management stream: Photographer, Designer, Prepress and Pressman.

The color management stream is like a chain, and it is only as strong as the weakest link. With that said, I think all contributors in the process can introduce something that can break. But the area that has the highest potential for something to go horribly wrong is prepress, at this point any color mismanagement has little or no chance for recovery.

[Mike_Ornellas]

And guess who is doing prepress now....

Designers and art directors.

Do the math.

The software sucks.

[Printer_Rick]

Jeffrey_Smith wrote:

Let's use the same participants in the color management stream: Photographer, Designer, Prepress and Pressman.

The color management stream is like a chain, and it is only as strong as the weakest link. With that said, I think all contributors in the process can introduce something that can break. But the area that has the highest potential for something to go horribly wrong is prepress, at this point any color mismanagement has little or no chance for recovery.

Jeffrey,

To narrow it down, what part of prepress do you think is the most common mistake

1. Source RGB discarded

2. Layered RGB converted in PS without merge

3. Destination CMYK not the ideal choice

4. Proofer calibration out of tolerance

5. Plate calibration out of tolerance

I would think it would be one of these, if I left something out please let me know

[Mike_Ornellas]

3

[Guest]

To narrow it down, what part of prepress do you think is the most common mistake

1. Source RGB discarded

2. Layered RGB converted in PS without merge

3. Destination CMYK not the ideal choice

4. Proofer calibration out of tolerance

5. Plate calibration out of tolerance

I vote for #3. Because of an entire system of communicative dysfunction in the workflow, we have arrived at a point where the standard is for printers to require CMYK, but too often, they give no indication as to what that means, resulting in a big cloud of nothingness, a classic Catch-22. As a result, color goes pear-shaped. Of course, the fault is not entirely with the printer. Just as often, a printer will make available a profile to use but the suppliers upstream (photog, designer) don't know what to do with it.

It's crazy-making, really. Implementing color management is not that difficult, but the basic set of best practices has become so enshrouded in a web of confusion and misinformation, it seems way more complicated than it really is. I have worked with clients who have been confused and frustrated for years by this stuff. An afternoon of calm instruction rocks their world. One client in particular spends $1.5M per year with Quebecor - no small operation.

Education works. CMYK is exclusively a business medium. Making the connection between process control and profit usually does the trick. The key is to not punish ignorance. A few posts back, Printer_Rick made the point that hollering at someone for not understanding something is completely the wrong approach.

[Mike_Ornellas]

I vote for #3. Because of an entire system of communicative dysfunction in the workflow,

And that my friend leads to the software developer who ultimately has the power of absolute change while its users fumble through an ever compounding pile of marketing features with no clear direction.

Like they say - it's brilliant~!

[Guest]

And that my friend leads to the software developer who ultimately has the power of absolute change while its users fumble through an ever compounding pile of marketing features with no clear direction...

... which leads us straight into the circular dog-chasing-tail conversation we've collectively been having for the last 10 years.

But I digress. Here's a step in the right direction (offered by the software developer!!):

The maze of buttons and levers and features in Photoshop right now is enough to make the novice lose his lunch. So, it's no wonder that the relatively simple set of basic color management best practices is hard to keep track of. Configurator is a new way of collecting together functions, buttons, etc into one panel so that a user can find exactly what he needs to do a specific job. It curently works only in Ps, but hopefully the other app teams will see the wisdom in incorporating it into InDesign and Illustrator.

It's an evolutionary process - messy and lurching, but forward-moving.

[Mike_Ornellas]

Of course it evolutionary Rick.  I did not say we are going backwards, but that again depends upon who you speak to.  The real issue at hand is that once a user passes files off to someone else, all hell rains down. Some may argue this is not the software developers fault as well, but one thing for sure, people will get sick and tired of the same old crap and sales will taper off for Adobe because people are not gaining any more reliability then what they had in the last version of software. Marketing thinks that endless compilations of crap is key to sales.  Sorry, but its not. The bottom line is becoming very tight and hand to mouth transactions are becoming the norm - not this endless waste of bull crap with job justification edits with features we could live with or without.

Adobe is running out time to capture the world in the real sense.  People are wising up to the software game of need or want to upgrade.  You have to remember that I deal with files that come and go from all places in the world.  I see many things that most dont including what country has what version of software the most.

Adobe needs to address this issue or lose present and future customer base is the bottom line.

People are tired of musical chairs - both with file fiascos and version upgrades...

Go look a General Motors.  Too big, so it shall start cutting limbs off....

[Guest]

mo -

I can't disagree at all with anything you've said. But the fact is that the tools we have are the tools we have. Anything we (as users - influential ones, at that) can do to help others use those tools is a good thing.

[Mike_Ornellas]

I know Rick.  Its a mess. But Adobe fears workflows like the plague.  They fear solutions because they do want to commit to doing real beneficial homework for their own success.  The just focus of technology upgrades and work in features driven by numb nuts as far as I see it.

Lets just drop the politics for a bit and help the other Rick.

Rick the printer -

Every stock has a different reflective characteristic. Some are matt, dull or gloss. Some have optical brighteners that cast color, either visually or color metrically or both. The critical nature of print and stock selection - color management has difficulty nailing down due to rounding of numbers, errors in densitometer retains and general software bugs or fuzzy math such as BPC.  Black Point compensation as well as color engines and rendering intents all play a critical role in trying to preserve the color appearance between what you see and what you get. Also, some extreme colors in CMYK such has really saturated blues and yellows -  a normal run of the mill monitor cant show the actual color because  its outside of RGB space. Also, the viewing light conditions at which you look at the press sheet is a consideration.

So, to answer your question. The nature of critical color in CMYK  - even with all the technology perfect in a perfect world, will still not be precise enough, but close enough to sell most of the time.