Color Settings Help Needed

ncjohn wrote in post #11707640
I'm glad you said this, Tony, because it reminded me of something that I guess is a bug in Elements 6 & 7.

Not a bug.

ncjohn wrote in post #11707640
Just now, I pulled up a photo in DPP and used the Adjustment menu to change the color space; the photo changed, as I thought it should.

It shouldn't IMO. The fact that DPP renders an image (slightly) different, when sRGB is the output colorspace chosen (and shows this in the preview as well) makes absolutely no sense (to me). But it does to Canon apparently.

ncjohn wrote in post #11707640
when using PSE, I would change the color space of the image (just to see what the difference would be) and it didn't change appearance at all. I thought that was strange but didn't know what it meant.

Assuming you meant you used "convert to profile" then you shouldn't see a change (provided no clipping occurs)

ncjohn wrote in post #11707640
So just now, having seen the image change in DPP, I went back to PSE, loaded up the same image as in DPP and tried it again. When changing from aRGB to sRGB and back, there's no change. When you tell it to remove the profile, it apparently does because the photo goes flat.

Not entirely sure about PSE, but PS assumes the set Default Working space if an image without profile is opened without assigning a profile.

ncjohn wrote in post #11707640
Then when you try to restore the profile, nothing happens. So it's like PSE can remove a profile but can't change it or add one if there isn't one. And it acts the same whether it's a RAW or jpeg.

I wouldn't know how (or why) to remove a color profile in PS, except to not include it while saving.

IMO, if an image has no embedded profile, it's either sRGB for web, (and/) or somebody screwed up.

I agree.
Very brief and oversimplified description of what color management does: Lets say that we have a red that is 250/0/0 in the sRGB space. That is close to being the brightest red sRGB can contain (255/0/0 is the limit). But in Adobe RGB it is 225/0/0 in order to leave room for even brighter reds. And for my monitor to display that same red it would have to be 246/0/0 because my monitor has a slightly larger gamut than sRGB but it's smaller than Adobe RGB. As you can see, in order for a number to mean a color you have to know the space also. A c.m. program looks at the three elements - image profile, monitor profile and digital number and says, "Aha, 250/0/0 in sRGB, I'd better make that 246/0/0 in the data I send to this monitor," or, "225/0/0 in Adobe so I'll send 246/0/0."
The color on the monitor should be the same, although the histogram changes.

Well... René and Elie, it sounds like you guys are confused by what DPP and PSE are doing, and if you two don't know what's going on, I sure as heck don't!

1) René and Elie, it sounds like you're saying an image should look the same on-screen whether the work space is sRGB or aRGB.
2) I've read more than once the idea of "When I process my RAW files, I save as sRGB for web or aRGB for printing."
3) And when we print, we try to get our prints to match our monitor.

BUT if the monitor image is the same whether the image is sRGB or aRGB, then the matching print should be the same regardless whether the image is aRGB or sRGB.

So, you guys can check this out -- the image will slightly shift only if the bright/saturated colors are there -- in other words if there are colors that are pushing the color space edges. As to how much they change that would depend on the image and your monitor and so it's undefined as to what you'll see. In fact, I was just looking at some flower shots and I see a bit of a shift at the very brightest levels but not enough that I would say makes things look "off" either way. It should be noted, though, that I'm using my little leptop -- I don't know what things would look like with a wider gamut monitor, and I'm not sure about printing.

ncjohn wrote in post #11711708
1) René and Elie, it sounds like you're saying an image should look the same on-screen whether the work space is sRGB or aRGB.

Yes. Provided the image doesn't contain colors that should be outside sRGB gamut, since there would be a difference then: The sRGB image would be clipped

ncjohn wrote in post #11711708
2) I've read more than once the idea of "When I process my RAW files, I save as sRGB for web or aRGB for printing."

Yeah, because web images are "supposed to be" sRGB: Most monitors are (still) "regular" (=about sRGB) gamut.
And most people still browse non-colormanaged. (POTN might be an exception)

ncjohn wrote in post #11711708
3) And when we print, we try to get our prints to match our monitor.

Yes-ish.
But we also try to limit the colors as little as possible: If I (say) edit on a laptop screen, I do not want to limit my image to that (smaller then sRGB) gamut!
There migt be colors in the image (even if it's sRGB) that are not display-able, yet will print A-okay.
For the same reason I might edit an image intended for my R2880 in AdobeRGB, even if my screen is incapable of displaying all colors. I will have to take a bit of extra care though.

ncjohn wrote in post #11711708
BUT if the monitor image is the same whether the image is sRGB or aRGB, then the matching print should be the same regardless whether the image is aRGB or sRGB.

Unless there are colors in the AdobeRGB image that fall outside sRGB (yet inside the printers gamut): They can be printed, but would have been clipped when using sRGB.

Think "Fall colors".

René Damkot wrote in post #11712527
Yes. Provided the image doesn't contain colors that should be outside sRGB gamut, since there would be a difference then: The sRGB image would be clipped

There migt be colors in the image (even if it's sRGB) that are not display-able, yet will print A-okay.
For the same reason I might edit an image intended for my R2880 in AdobeRGB, even if my screen is incapable of displaying all colors. I will have to take a bit of extra care though.

Unless there are colors in the AdobeRGB image that fall outside sRGB (yet inside the printers gamut): They can be printed, but would have been clipped when using sRGB.

To all these statements that are in bold, I have to ask: But how do you know whether there are colors that fall outside the sRGB gamut, if the monitor can't show them???
And in response to the blue bold: If they do print, seems like it would be case of, "Well, it doesn't match my screen, but I like it." True?

My favorite answer of all time!

ncjohn wrote in post #11712755
To all these statements that are in bold, I have to ask: But how do you know whether there are colors that fall outside the sRGB gamut, if the monitor can't show them???

This is where you need to work with the RGB histogram -- DPP does a pretty good job of showing how the colors fall in the two color spaces. Your monitor likely won't be as accurate (unless it is wide gamut).

To see this in action, you need to open an image with bright saturated colors, switch between the two color spaces and observe the RGB histogram, and for colors that push against the edge of the sRGB histogram you should see them fall within the aRGB histogram. To convert to an sRGB image for the Web, you could consider using the RGB tools along with the saturation and maybe brightness tools to "tame" those colors.

Pretty much -- it's a judgement call you make when dealing with that range of colors, and would take some trial and error to really nail what you want to do.

In practice, we deal with colors that are manageable in sRGB most of the time, but there are fields where you want your options open -- flowers, product photography, and fabrics (fashion, etc) are three that come to mind where you would want a print that is the closest to what you actually see even if the monitor doesn't quite fall in line.

I don't accept the word "match". Aside from all the considerations of a reflected light medium vs. a back-lit medium and the print viewing conditions, there is also the difference in contrast - a print will be 200:1 to 300:1 depending on the paper and a monitor, despite manufacturers' inflated claims, will be in the range 800:1 to 1000:1. And of course there is the difference in gamut. That is why Photoshop and other good printing programs have soft proofing and why thousands are begging for Lightroom to have it also. Soft proofing alters the normal display to be more like the print and can mark the out of gamut colors. Obviously if the normal display "matched" the print there would be no need for soft proofing. But even soft proofing is just a step closer, not a match, because it addresses primarily the contrast aspect and the differences in rendering intent but cannot force the monitor to display colors that are beyond its gamut. Using soft proofing you can adjust the image to bring the OOG colors into the printers gamut, but you still won't see them unless you are using a wide gamut monitor. So instead of "match" I'd say resemble".

So, this brings up an interesting question that the other color management thread that just came up got me thinking about, and that's how we would approach this printing management with software like DPP and Elements which don't have softproofing? Anyone have a "best practice" for use with those?

tonylong wrote in post #11713646
So, this brings up an interesting question that the other color management thread that just came up got me thinking about, and that's how we would approach this printing management with software like DPP and Elements which don't have softproofing? Anyone have a "best practice" for use with those?

Elements+ for PSE has softproofing.

tzalman wrote in post #11713329
Soft proofing alters the normal display to be more like the print and can mark the out of gamut colors.

How does it mark them? What does that look like?

Yes, that is better.

ncjohn wrote in post #11714463
Elements+ for PSE has softproofing.

Ah, that's good info!

So then, best practice for DPP?

tonylong wrote in post #11714980
So then, best practice for DPP?

Save to PSE.:p