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]

Assign profile is there for you to assign IF the image comes with no embedded profile.Period.

EDIT:Thats the closest thing you'll find to cheats on Photoshop.Why would you want to brake something that works well?

Give a look on those articles...they are very well writen and clear.

Either that or youre writing an article about Color Management and want to demonstrate something on screen.

[Printer_Rick]

"And what if a moron unwittingly embedded the wrong profile in output? Then assigning a different one would restore the original color."

I stated this in post 18, I'd like to clarify what I meant.

Let's assume a photographer gives a designer an RGB image, with Adobe RGB embedded. But the designers RGB policy is "Off". He opens the image (effectively discarding the profile), adds a logo or type, saves and closes.

Now the image is handed off to another designer. This designer places the image in InDesign CS3. The document space is sRGB. He outputs using PDF/X-4, no color conversion.

The image in the PDF has been re-assigned to sRGB, not converted. sRGB becomes the new source for conversion to CMYK.

The job is proofed. The photographer says, "What happened? The color's all wrong"

In this instance, reassigning Adobe RGB to the PDF image would in fact restore original color.

You may think this scenario is not likely to happen. But these hand-offs might happen more than you think. 1st mistake is the Designer 1 throwing out the profile. 2nd mistake is designer 2 unwittingly re-assigning.

But re-assigning again is the sure way to correct the image.

[Miguel_Curto]

1st Designer only messes up if he pastes logo from diferent color profile.Or he chooses to "save as" and unticks the "embed color profile".

But youre right...that would restore the "correct" profile but on the other hand instead of the photographer you would have the client screming upon  the phone:" WHAT THE HELL YOU DID TO MY LOGO COLORS?"

And Mike is wright..it shouldnt but happens all the time.

"Get used to understanding disclamers" Best piece of advice I've read here so far...

[Mike_Ornellas]

Most people have their head shoved up their butt- so anything that you do with their permission and understanding to make the image better is a valid workflow...

[Mike_Ornellas]

Rick -

These issues happen ALL DAY LONG.  Some people notice and some dont. Most printers eat thousands of dollars because of Adobe Software.  Get used to understanding disclamers, keep your nose clean and dont care much.

[Chris Cox]

Hey Mike - where you been hiding?

[Ramón_G_Castañeda]

Great to see you posting in these new forums, Mike.

[Miguel_Curto]

Ive slepts over this,and to be honest Im not so sure this (assigning) wouldnt be a valid option on enhancing images in that cenario (original "bad" image in sRGB and finished image to be in AdobeRGB).At least as valid as Levels or Curves.

sRGB mimics AdobeRGB only its not as saturated on Cyans and Greens.From my perspective what is happening is sRGB values are being showned using a larger gamut ence the satured values are pushed even further to the edges.This COULD (in my limited view) introduce some banding or posterisation in the color gradients (mainly cyans and greens) but then again so could levels and curves if the image clearly needs correction witch is the reason leading to re-assigning profile in the first place.

It will probably alter color relationships for the same reason, but since your purpose it to "correct"/"enhance" the image this could be a valid "exploit".

Maybe someone who understands better the mechanic behind this can shed some light on this.

[Ramón_G_Castañeda]

Miguel,

If you start with a crappy image and you just want to make it look different, that's one thing.  But you're getting into an area where any artistic liberty is allowed, as in toning or colorizing of photographs, and that has very little to do with the accurate representation and rendering of color.

Sure, you can use that "technique" in the same manner you use any plug-in to transform the image, except that it will be a pretty crude if expedient way of "correcting" color.  It's crude because you have very little selective control over the process.

There's is a fundamental difference in the perspective of the original poster and mine:  he doesn't deal with photographs, and I dont deal with CMYK illustrations to enhance cereal boxes.

EDIT: added "illustrations to enhance cereal boxes".

Message was edited by: Ramón G Castañeda

[Printer_Rick]

Miguel Curto wrote:

Ive slepts over this,and to be honest Im not so sure this (assigning) wouldnt be a valid option on enhancing images in that cenario (original "bad" image in sRGB and finished image to be in AdobeRGB).At least as valid as Levels or Curves.

Thanks, I think now you see my point of view. It's just a quick fix for a bad image where color isn't critical, and the goal is pleasing color.

I wasn't suggesting re-assigning Adobe RGB should be a prepress workflow. It's a design option.

When clients ask me what source space to use for print design, I tell them Adobe RGB. But still most tagged images I get are sRGB, for whatever reason...

[Mike_Ornellas]

You are funny Chris -

I needed a time out from the forum madness because it was not doing me or anyone else any good. I see some things have changed but most characters remain the same.

;o)

[Mike_Ornellas]

Rick -

It's a very mixed up world where we both work. What we need is the ability to have a road - an option for the masses to follow in regards to color management. Users can then choose to follow it or not to increase the reliability of image preservation, but not to guarantee the process. Adobe needs for the most part enough flexibility to grow and expand their product, but by the same token, needs to understand and address multiple users for many working conditions.  The only way it shall get any better is when the powers that be make a commitment to faithfully study the markets that they serve and develop an optional workflow that streamlines chaos. Until then, embrace the free for all idiotology and try not to get caught up in the finger pointing game.

I feel that you have a pretty good understanding of color management - more so then most prepress people.  Just keep studying the subject and figure out what works best for you as well as reducing your liability. After all, the customer is always right even though they are not that bright.  Pretty much sums up a lot of perspectives from many points of view.

[Printer_Rick]

Thanks for your comments Mike. I think we're on the same page.

I still hear a lot about printers demanding CMYK, and even charging for conversions. Consequently a lot of designers convert images to CMYK in Photoshop, when it's really unnecessary and time consuming. It's easier to convert on placed images on output (or even leave them RGB for PDF output)

The question is how does the mindset get changed? For years and years designers were told "supply CMYK". Old habits die hard.

The only obstacle for prepress (correct me if I'm wrong) with Photoshop RGB are Pantone 4C builds. RGB - CMYK conversion won't hold book values. But this only matters if design elements are purposefully added in Photoshop after image capture.

[Was DYP]

I still hear a lot about printers demanding CMYK, and even charging for conversions. Consequently a lot of designers convert images to CMYK in Photoshop, when it's really unnecessary and time consuming. It's easier to convert on placed images on output (or even leave them RGB for PDF output)

The question is how does the mindset get changed? For years and years designers were told "supply CMYK". Old habits die hard.

If I had a printer not demanding CMYK for conventional offset print I would thoroughly be investigating them and every aspect of their color management. I would want to know just how they made there proof. Was it done after CMYK conversation etc. And they better come up with some good answers.

In fact the more I think about it would probably just avoid them as I would not want to give that kind of control to a printer. I have done thousands of offset print jobs and never once have I ever given a printer RGB files.

[Printer_Rick]

Was DYP wrote:

If I had a printer not demanding CMYK for conventional offset print I would thoroughly be investigating them and every aspect of their color management. I would want to know just how they made there proof. Was it done after CMYK conversation etc. And they better come up with some good answers.

In fact the more I think about it would probably just avoid them as I would not want to give that kind of control to a printer. I have done thousands of offset print jobs and never once have I ever given a printer RGB files.

I understand this argument. Supplied CMYK is safer, no doubt about it. And you avoid the Device N issues mentioned earlier.

But any printer worth his salt proofs CMYK page output, the RIPped file gets sent to the proofing device. It has to match what goes to plate (apart from plate device calibration)

I was just saying it's possible for a designer to supply RGB images in output, or even RGB images with native files (extra emphasis on images). As long as images and documents are tagged properly with source and destination, the conversions would be the same

And you might avoid the printer having to do an extra CMYK-CMYK conversion.

There are definitely two good sides in this argument and I understand both sides. If I were supplying a file for print, I would probably leave all my native RGB, find out what CMYK profile the printer preferred, and supply a CMYK PDF (no native files).

[Miguel_Curto]

Was DYP wrote:

If I had a printer not demanding CMYK for conventional offset print I would thoroughly be investigating them and every aspect of their color management. I would want to know just how they made there proof. Was it done after CMYK conversation etc. And they better come up with some good answers.

In fact the more I think about it would probably just avoid them as I would not want to give that kind of control to a printer. I have done thousands of offset print jobs and never once have I ever given a printer RGB files.

When asked to deliver (for the client that then has his own printer witch I dont know) files in CMYK im always under the impression that most of the time they dont reealize what their talking/asking.

This is getting very off-topic but how should I know what is the proper CMYK to send the file if most of the time I dont even have a clue how is it gonna be printed.Every single CMYK file incorporates ink limits,black rendition and among other things atends deviations of color due to paper color so how can I know? The problem is if I try to say this to client most of the time they see me as a dificult person and next time (if theres a next) they'll propably take their work elsewhere.

Also,Im pretty sure that in previous version of Photoshop came with BruceRGB profile wich adresses some limitations of clipping color in convertions from AdobeRGB to CMYK but it seems there isnt anymore so most of the time tend to stick with AdobeRGB wich I think Adobe contributed to press people to use it as standart while it has clear problems with convertions for hard copy.But once again,if Im alone here whenever theres a problem with my work people (even if its not induced by me) would point at me saying: hes not working properly.

[Mike_Ornellas]

Charging for a conversion is a billable item because the person doing the conversion is taking the liability of said action. I do a lot of high end retouching, illustration, image compositing and the like and when you are dealing with very fussy clients that love job justification edits, you are rightfully inclined to bill what you can get. Yes, a lot of designers are doing their own CMYK conversions because of old bad habits, but there are many facets to how and why people do what they do. I can go into a lengthly disruption, but I would only be repeating myself to no end. Some of the blame should be placed upon the printers for starting this conundrum of supplying CMYK files to them.  It's usually due to ignorance, fear, liability or lack of care on their part. The lines are very blurred in print.

The mind set will only get changed by the people who have the ability to make change. Education only works for so long and so far. The software needs to offer that change Rick in order for harmony to have any chance. And yes, old habits die hard, but hope is not dead, just unrealized.

There are many reasons why people still work in an output space. It's mostly done because its extremely difficult to edit a 3 channel color space destined for a 4 channel color space. I'm not talking about pleasing color. I'm talking about the faced paced insane nature of art directors that demand the impossible from an RGB file. Things like preserving black only objects for drop shadows as one example. An RGB to CMYK conversion does not account for this. A CMYK to CMYK conversion could address this with device link profiles and CS4, but its still a situation of putting the tooth paste back in the tube. The other solution is to create color fill layers with object masks but again, RGB to CMYK conversions are an issue when trying to preserve device N color spaces. I really wish the Photoshop team would address this issue and create a feature as I have requested. It would solve a ton of illustration and color separation issues for the masses.

So - it's not just spot color support that is the issue, but Im sure spot color change would require a complete architecture rewrite of Photoshop. Unfortunately marketing does not see the benefits of this because it's seen as a print issue only - but it goes far beyond print.

[Jeffrey_Smith]

Mike Ornellas wrote:

Some of the blame should be placed upon the printers for starting this conundrum of supplying CMYK files.

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

[Mike_Ornellas]

Jeffery -

The software is not mature enough to address multiple users in multiple environments. Part of the blame resides in the development of the software because it has to cater to a wide range of industries.

Not an excuse. Not a blame.  Just the fact of not having enough focus on Adobe's part.

[Jeffrey_Smith]

Mike, your messages always seem to carry a common theme, that Adobe should have a greater role in the direction of color management implementation. But the fact of the matter is the CM directive comes from a broad group serving the common purpose and encouraging an open vendor, open platform, open minded environment (and if that doesn't sound like a load of [garbage: edited by host], then I don't know what does). But really, Adobe's part is no greater than any other group. How can Adobe, as an individual company, improve color management? (rhetorical question)

[Mike_Ornellas]

The basis for color management comes from a group of companies. The standards. The requirements. etc....

The implementation or workflow is a different story.

[Printer_Rick]

I think Adobe's solution to the color management problem is PDF. Their part of the solution, anyway.

As Mike mentioned Device N in Photoshop is probably just a dream. It's not cost effective for them to pursue developing that. So we have to deal with that, and rely on PDF output as the solution for color management on the software side of things.

That leaves the all input and output devices, which of course is bigger than Adobe.

[Mike_Ornellas]

Rick -

All you need to do is put a [edited by host] check box in the color fill dialog box.  It's not brain surgery.

[Printer_Rick]

All you need to do is put a [edited by host] check box in the color fill dialog box.  It's not brain surgery.

Not understanding Mike. I was agreeing with your statements. What's this all about?

[Mike_Ornellas]

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.

It could be intigrated into Smart Objects to follow the rest of the logic of SO's.