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.

[Was DYP]

Mike Ornellas wrote:

We need 64 bit processing for many different kinds of work that Photoshop does.  The problem is that Adobe is not a hardware manufacture and has to deal with an outside entity all the time to support their product.  That in itself is insane...

What I fail to understand is how you can go (the whole application and plugins) to 64 bit processing by just rewriting the UI code.

[Mike_Ornellas]

That is a question for Chris.  I'm not an engineer.  - but something does not sound right.

[Chris Cox]

What I fail to understand is how you can go (the whole application and plugins) to 64 bit processing by just rewriting the UI code.

You can't. But Apple made rewriting the UI code a requirement to get to 64 bit at all.

[Was DYP]

Mike Ornellas wrote:

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....

Mike

In relating to your comments, take a look at this thread (if you haven't already), especially the part about "All we've said we're doing is rewriting the UI code, because we have to in order to deal with the impedence mismatch between Cocoa and modern UI frameworks". To make PS 64-bit compatible?

http://forums.adobe.com/message/1544926#1544926  Post #32 contains quite an interesting comment.

I would like your thoughts on this relating to PSCS5 and performance.

[Printer_Rick]

Thanks for all the comments, as well as the Configurator app I was not aware of that.

Rick McCleary wrote:

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.

Hope this next question is not too far off track. 3 (CMYK gamut) seems to be the breakdown point.

This is where things get muddy for me. The gamut has a defined size, from a file standpoint. The black point has a given percentage. The separation can be GCR or UCR. The black plate can be full, or skeletal. And of course CMYK is usually smaller than the source RGB.

Take for example a ProPhoto RGB, with fringe colors. This is converted to US Sheetfed Coated v2. On-screen, all kinds of colors stand to drop out.

But how is the display of CMYK ever going to be reconciled with the printing? What I mean is, one file can produce drastically different colors on press, even if plate and press calibration are both perfect. The 3 things I believe create this color shift - the screening, the substrate, and the coating.

150 LPI Round is in no way the same color as FM 2 micron. But the Photoshop file was the same. The display was the same.

60# Matte Text is not the same color as 100# Gloss Cover. But the Photoshop file was the same. The display was the same.

Dull Aqueous Coating is not the same color as Gloss Aqueous Coating. But the Photoshop file was the same. The display was the same.

Maybe there is a way to embed some of these variables in a file, to get a better soft proof. I don't know. Sometimes the display may lead a designer into thinking the royal blue is getting hammered, when in fact the final press gamut may be much larger than what he sees on his monitor.

I can't tell you how many jobs I've seen on press, where one result is "Hey, what's wrong with the file?" and a few minutes later "Wow, that looks even better than I thought it would!" But there's not even a plate change, just a different stock going through the press.

[PeterK__]

Printer_Rick wrote:

Take for example a ProPhoto RGB, with fringe colors. This is converted to US Sheetfed Coated v2. On-screen, all kinds of colors stand to drop out.

But how is the display of CMYK ever going to be reconciled with the printing? What I mean is, one file can produce drastically different colors on press, even if plate and press calibration are both perfect. The 3 things I believe create this color shift - the screening, the substrate, and the coating.

150 LPI Round is in no way the same color as FM 2 micron. But the Photoshop file was the same. The display was the same.

60# Matte Text is not the same color as 100# Gloss Cover. But the Photoshop file was the same. The display was the same.

Dull Aqueous Coating is not the same color as Gloss Aqueous Coating. But the Photoshop file was the same. The display was the same.

Maybe there is a way to embed some of these variables in a file, to get a better soft proof. I don't know. Sometimes the display may lead a designer into thinking the royal blue is getting hammered, when in fact the final press gamut may be much larger than what he sees on his monitor.

Of course there is! That's what ICC profiles are for! The entirety of the above post makes it very clear that you haven't even begun to scratch the surface with colour profiles. Yes, some colours are not reproducible on press and they will get dulled down, and all of that is dependent on the printing variables, which stock, line screen, rendering intent you chose, etc. but then your display will show that to you in the soft proof! You are the same person who thinks it's alright to be haphazardly assigning profiles to "colour correct" images, right? I guess you could do that, but the reasons why you would do that over using the tools in Photoshop meant for the purpose are beyond me. Read more on colour management, particularly on creating profiles and soft-proofing them. You'll save yourself a lot of headaches. (this is of course, after suffering a few while learning the subject)

[Lundberg02]

The OP has probably committed suicide by now, BUT

Gamma is not black point or ink density or anything like it. For ---------sake.

"Gamma" as loosely used here is actually   "gamma correction"  the inverse of the transfer function of (originally) a CRT, used to make images look approximately correct to he human eye. The actual function used is linearized in the 1/4 tones and 3/4 tones to avoid problems.

Various color management schemes use different compensation linearities, particularly  at the black end accounts for some of the weirdness of ColorSync.

"Gamma" only matters for mid tones. Use what ever you feel like.   High end printing  1.8

There are not enough wide gamut monitors out there yet  to establish a preference but I'm going to set mine to 1.8 when it shows up.

2.2 is usually used by web images  builders because it alleviates idiot viewer difficulties.

[Ramón_G_Castañeda]

Lundberg02 wrote:

The OP has probably committed suicide by now,

Lundy, I have him plonked so he may have uttered enough additional ignorant statements that I have not read to justify your assumption, but I doubt he has.

People who have no idea as to their cluelessness go through life quite content with themselves.

[Printer_Rick]

Lundberg,

I realize now my initial assumption about gamma was incorrect, and thanks for the information. I find it interesting that your preference for 1.8 is different from Ramón's suggestion of 2.2. On another note...

It seems there is a lot of misunderstanding going on. In the original post I shouldn't have even mentioned gamma. But I made it clear I wasn't sure about it.

Just trying to learn. Everyone can agree to disagree without going into attack mode.

It's no wonder color management is such a mess. Most people I encounter have zero understanding of it. Insulting them would be about the furthest thing from a solution that I can imagine.

[Guest]

Printer_Rick wrote:

It's no wonder color management is such a mess. Most people I encounter have zero understanding of it. Insulting them would be about the furthest thing from a solution that I can imagine.

Rick,

Your thoughts are a breath of fresh air in the convoluted world of photographers/designers/printers. Please contact me privately. (I know there's a way to do that on the forum, I just don't know how.)

Rick

[Ramón_G_Castañeda]

In the context of the original post in this thread, I would urge interested parties to read this recent post by MO in a anothere thread:

http://forums.adobe.com/message/2070772#2070772