PSD with embedded color profile cross OS issues

[gromit]

That more complex and more customizable curves can be produced in Photoshop and applied as an adjustment layer seems to have escaped you. Do you even understand what a gamma curve is? In the case of sRGB, its not a true gamma curve because of that tiny extra point in the curve in the shadows, a curve a beginning Photoshop user could produce. Again, you need to investigate this far more before posting. ICC profile curves in an RGB working space are very simple and very easy to produce with virtually no options (you can only specify a value); have you ever even done this?

This is my last reply on this topic, since it's of no help to the OP and of little real import anyway. Firstly, your original comment that it doesn't work is wrong. A colour is defined by its coordinates (RGB values) and the definition of the space. Change either and you change the colour. Though unorthodox, there's nothing inherently inferior to changing the space to effect the change. And, in the context of 8-bit files, there are advantages in changing the space. As to which is "better", this is a value judgement each will make individually based on their workflow. Regarding your comment that gamma curves are "very simple", a quick perusal of the ICC specs shows that TRC definitions can be surprisingly complex, not just gamma values but points and even parametric. But all this is besides the point and I'm unlikely to stop using an approach that works for me, even if you say it doesn't or there are better ways (for you).

The point of this parting reply though is to highlight your approach when confronted with ideas you just don't grasp. We're all to familiar now with your scattergun and bile-laden replies that are intended to show how superior you are. I've been reading your comments on colour management issues over the years and some of these are somewhat curious if not outright wrong. Personally I think you've been faking it for years and just don't have a good enough understanding of the topic to think things through for yourself, a book on the subject notwithstanding. Witness your continual referral to other experts (those brilliant Adobe engineers etc). It's this lack of fundamental understanding that puts you immediately into attack mode. Looking for something simple, like a name or some parameter out of context, that you can turn back on the originator. Few here are unlikely to stand up to such treatment. Your game is up, with me anyway.

[Mark D Segal]

Gromit, (we don't know who you really are) - this Forum is for technical and artistic discussion about photography and digital imaging in general. It is not for personal attacks. I am not a moderator of course, but as a long-standing senior member of this Forum and as a contributor in the current thread I find this kind assault on an individual's character to be totally out of place and I am reporting your post as such.

[digitaldog]

This is my last reply on this topic, since it's of no help to the OP and of little real import anyway.

We (I) were hoping to help you, you really need it! But I really do agree (for once) that the best thing you can do is go away and keep your head in the sand. You seem to enjoy the view there.

A colour is defined by its coordinates (RGB values) and the definition of the space. Change either and you change the colour.

Maybe you can explain that when you assign the values, the numbers don’t change a lick. Maybe you can re-read, and comprehend what I explained about how the values only change when a conversion is made using the source color space. Try real hard and maybe you’ll get it.

Though unorthodox, there's nothing inherently inferior to changing the space to effect the change. And, in the context of 8-bit files, there are advantages in changing the space.

As I said in my first post, there is nothing happening here until a conversion and compared to an adjustment layer and proper use of the right tool (curves), you have more control that’s non destructive. And you continue to dismiss or ignore the fact you keep ending up with blocked shadows and can’t seem to figure out, other than using this lame false profile technique how to stop this from happening in the first place.

Regarding your comment that gamma curves are "very simple", a quick perusal of the ICC specs shows that TRC definitions can be surprisingly complex, not just gamma values but points and even parametric. But all this is besides the point and I'm unlikely to stop using an approach that works for me, even if you say it doesn't or there are better ways (for you).

OK so I asked if you knew what a gamma curve is and its now clear you have no idea. Nor do you understand the differences between a gamma curve in a working space and the curves in an output profile. I simply can’t take the time to explain the huge differences here because you’ve illustrated that just talking about simple ideas here, that of a curve based on the gamma formula and a complex curve are well beyond your understanding. In fact, I should have dismissed your level of understanding of basic image processing early on or when you made the simply idiotic statement “We're talking about a micro adjustment here and Curves just don't do the same job.“ This is blatantly untrue and shows to any lurkers that you haven’t a clue about what you’re talking about!

We're all to familiar now with your scattergun and bile-laden replies that are intended to show how superior you are.

I’m sure everyone is pleased you’ve spoken for them. Superior has nothing to do with it, I’m simply trying to explain simple image processing that you either don’t wish to comprehend or simply can’t.

I've been reading your comments on colour management issues over the years and some of these are somewhat curious if not outright wrong.

Well so far, in terms of peer review (which has been brought up here), it seems you are the one who falls into this camp. Can you find anyone else here that subscribes to your flat earth theories?

Personally I think you've been faking it for years and just don't have a good enough understanding of the topic to think things through for yourself, a book on the subject notwithstanding. Witness your continual referral to other experts (those brilliant Adobe engineers etc).

You mean the people who have designed the tools discussed who agree with me and would easily disagree with you?

This is my last reply on this topic

That is generally the reply of someone who has discovered that they have run out of ideas, replies and knows that they’ve been shown the errors of their ways. My recommendation is to do just what you’ve proposed, leave, continue to believe the earth is flat, created in 6 days (while dismissing the science of carbon dating) and continue to use a silly technique that does not change the fact that you started with and ended up with blocked up highlights. In your case, the term “Ignorance is bliss” is so appropriate.

I’ll leave you with a quote of my dear friend and mentor, Bruce Fraser who beautifully describes your False Profile technique (and to some respect, your inability to understand the process):

"You can do all sorts of things that are fiendishly clever, then fall
in love with them because they're fiendishly clever, while
overlooking the fact that they take a great deal more work to obtain
results that stupid people get in half the time. As someone who has
created a lot of fiendishly clever but ultimately useless techniques
in his day, I'd say this sounds like an example."

[Mark D Segal]

Hello
I'm new here. I hope this is the right place to ask this.
I have a psd file, from a client, with an embedded color profile in it, that I don't have.
More, the psd was produced on a mac (hence the color profile, Cinema Display Calibrated).
I've tried converting, discarding, etc, but I still can't get the colors right 100% when I export images for web (24b png's).
Does anybody know if it is possible to get 100% the same colors both on win and mac from a psd file with an embedded custom color profile?
Also, the colors should be like the one the client sees in Photoshop on his mac. Is that possible?

Right now I can get them to look 100% like the psd looks in Photoshop on windows but the client sais the colors are washed out on his mac (actually NOT the one the design was produced on).
If i discard the color profile I get the design to look the same across all browsers and OS's but the colors are shifted to a mauve hue (the main colors are tones of blue).

Thank you.

Maybe we should bring this discussion back to the specific problem for which the OP was hoping to get some guidance. That is what makes this Forum useful to people. I'm not sure I know the answer, because this is a territory with mines planted everywhere. Could the OP ask the client to send another image - and if any profile is to be embedded in it, make it either the Adobe RGB or ProPhoto RGB colour working space. Once you have this, you can implement the standard steps provided in PS or LR for making a web-friendly image. One of the steps - near the end of the process when you've finished making the image look as you want it on your colour-managed display, will be to convert it to sRGB - very important - with Black Point Compensation (BPC) selected. This way, the colour space embedded in the image will more or less match the color gamut of most monitors out there, and with BPC having been selected, the tonal mapping from your file numbers to the display version should be much closer than if it were not. All that said and done, as Wayne Fox mentioned much earlier on in this thread, there is an element of a crap-shoot involved because most peoples' monitors are not colour-managed and some browsers are colour-managed, others are not, either by design or by choice or by non-choice. So there is a limit to what assurance you can give your client. One thing for sure, however, is that this has nothing to do with whether the image is made or seen on a Mac or a PC. It all depends on what colour-management is being deployed in the creative end and the viewing end regardless of the OS.

[digitaldog]

I agree with Mark, lets try to help the OP...

I have a psd file, from a client, with an embedded color profile in it, that I don't have.

The beauty of the CMS architecture here is you don’t have to have the profile installed on your machine, its embedded and being used. FWIW, you could extract it but that’s moot at this point.

More, the psd was produced on a mac (hence the color profile, Cinema Display Calibrated).

Doesn’t matter what OS the image was built on per say. Now if you have a document with an embedded display profile, we can surmise right off the bat that whoever gave you the image is a bit confused about color management. One should never embed a display profile as a working space into a document. The display profile is only used for preview purposes on each individuals machine. Its not to be embedded into a document.

I've tried converting, discarding, etc, but I still can't get the colors right 100% when I export images for web (24b png's).

That the image creator provided you an image in their display color space, something they should not, why do you feel its not right in terms of color appearance, that you should discard the embedded profile or that it isn’t “100% correct”? I suspect the image just looks really awful and if so, what is your clue that its off here?

Does anybody know if it is possible to get 100% the same colors both on win and mac from a psd file with an embedded custom color profile?

While I’d like to move away from the “100%” value here, in a color managed workflow, where both parties have a calibrated and profiled display, where the embedded profile does reflect the actual scale of the RGB values, both parties should pretty much see the same color appearance.

What I suspect is happening here is the originator of the image was working in some non color managed app. When they saw the image in a color managed app, they saw it didn’t match what they saw in that non color managed app which is maybe where they created that image or worked on it. To make the smart color management app match the dumb color managed app, they embedded their display profile. That WILL produce a match between the two app but the problem is, both are incorrect. This idea of embedding a display profile to produce a match is a bit like the false profile concept whereby the “solution” appears to have fixed the issue when in fact it made it worse. That is, having your color managed app work incorrectly using a display profile to produce a preview didn’t fix the issue, it just produced a match so now both app’s are matching in their incorrect preview of the data. The original user felt they fixed the issue but they didn’t (the got the smart ICC app to match the dumb non ICC app, that’s not at all useful).

Right now I can get them to look 100% like the psd looks in Photoshop on windows but the client sais the colors are washed out on his mac (actually NOT the one the design was produced on).

Which kind of makes sense if indeed, the originator did as I suspected above. You tried to fix the issue. You embedded something other than their display profile. On their side, the image doesn’t look like they expect because again, the definition of the values, correct as they may be, don’t jive with the display profile they used to “fix” the problem on their end.

What might work is having them use the Assign Profile command, in Photoshop proper, and embed one working space profile that produces a color appearance they like but NOT by using their display profile. Have them try sRGB, Adobe RGB (1998) etc. Which comes closest on their hopefully calibrated display to their idea of the proper color appearance? Have that then sent to you to view on your hopefully calibrated and profiled display.

What I suspect we have here is initially RGB mystery meat. A true RGB working space profile that the creator feels produces the desired color appearance, not a highly device dependent profile (their display profile) is the first place to begin to investigate what the RGB values actually represent. What happens if you convert from their embedded display profile to say sRGB and ask them to view that sRGB image only in Photoshop (or some similar ICC savvy product)? Can we surmise that they don’t really have a calibrated display, that the sRGB image from their display profile looks wrong to them in an ICC aware app like Photoshop?

Lastly, you say you can’t get the image to look “right 100% when I export images for web (24b png's).“ What if you save off as a JPEG which supports embedding sRGB into the doc and then view that on a browser that is ICC aware (Safari, Firefox)?  

[digitaldog]

We're talking about a micro adjustment here and Curves just don't do the same job.

Ain’t that the truth (expect your idea is hardly a macro adjustment).

"false profiles" (or whatever you want, or don't want, to call them) are a powerful tool. I use them all the time, mainly for unblocking shadows in gamma 2.2 files (Adobe RGB etc).

Lets look at making a "false profiles". In Photoshop’s Custom RGB dialog (Color Settings), you have the “precision” of making a “false profile“ from say 1.80 to 1.79 or 1.81 or for sRGB, 2.19 etc. Maybe that is what gives Gromit the idea he has some precision here. The tiny numeric values make tiny, insignificant differences in our testing. Lets do that. Make a “false profile” for Gromit‘s workflow. Build a profile at gamma 2.1 and save it to disk after naming it “False sRGB tweak“.

Make a new document in Photoshop: sRGB, 100x100 pixels. Fill with Lstar 50 and place an eyedropper sampling point in the center. Set the info to read Lab, you’ll see of course its Lstar 50.
Go into the Assign Profile command. Make sure its set for sRGB then toggle to Adobe RGB (1998). Same Lstar 50. For fun, toggle to Apple RGB, or ColorMatch RGB and notice the predicted values using this assignment are L57. The so called micro adjustment of moving from a 2.2 TRC in sRGB to a 1.8 gamma curve. Lighter yes, but was that too much? Try assigning the 2.1 profile. Lstar 50 is now Lstar 52, Now try making such a micro adjustment in curves. If you are careful as anyone who uses curves can be, you can set a single point dead center in the curve and using your keyboard, move that point one movement up or down to produce (Input 50/output 51), and examine the Lab values. Before and after Lstar now reads 50/49 (or depending on the direction of said curve, 50/51 with input 50/output 49). A pretty precise macro adjustment in terms of the results on this 8-bit file. More precise than the assignment using a gamma curve in a profile. But wait, you’ll see that viewing this at Lstar 50 only tells us one part of the story (that we can produce a finer adjustment on this solid color using curves, dismissing part of Gromit’s theory that a “false profile” is a marco adjustment and curves are not).

Now lets try using this idea of a macro “false profile“ as defined by Gromit on more tones. We’ll start with an image with dark tones, an Lstar 2 to Lstar 50 gradient, (keep the a&B star zero). Its in sRGB as Gromit stated that he uses a "false profiles" in so called gamma 2.2 files to unblock shadows. This will represent some tonal areas of our blocked up shadow area extending into midtones. Again, with the info palette set, use Assign Profile, pick a “false profile“ of say 2.0. You can try using the tiny tweaks when building a “false profile“, like 2.19, 2.15 etc but the results are totally insignificant in the lower area of the images that we are supposed to be "fixing." Try 2.0 and here you see the big issue with Gromit's idea. Yes, as you assign the 2.0 profile, you see the image lighten up, but where? Around Lstar 20. Everything below isn't touched. And since this IS a curve, as you move up in Lstar, the effect is greater! Like a Photoshop curve, this curve is one where the point defining the curve has more of an effect and it gradually decreases from that point in either direction (duh, that’s why its called a curve). If you wanted to open up the blocked up shadows, seems you'd want to do this far lower in the tonal areas (say Lstar 4-6). But this is a gamma curve! Gromit is actually altering and affecting the data far more in the midtowns than the shadows! By the time we get to Lstar 50, the “false profile“ curve has moved those tones to Lstar 55. Any savvy Photoshop users could lock down curves where they don't want the curve to affect an area of the tone curve. They could decide with absolute precision where they want a curve to be in its max position. A “false profile“ has no such control. Its like using a axe when you really need a scalpel. And as Mark pointed out, you can adjust these dark tones using a myriad of other Photoshop techniques where you could control exactly where you start, stop and how far, you adjust the values, in an increment as little as 1 or two values.

Are using curves to open up blocked shadows the best method? Well the best method is not to block up shadows in the first place, something Gromit has never answered my query about. Its pretty clear that using curves has more control, percision, allows the use of adjustment layers, layer masks, blend-if control etc that far, far exceeds anything anyone can accomplish with a "False Profile" and for good reason. Profiles were never intended to solve this particular problem. Unfortunately, dear Gromit doesn't see that.

Another fun tidbit that illustrates how the sRGB TRC isn't the same as a 2.0 gamma "false profiles" and how this could be an issue. Take the gradient in sRGB and place a sample point in the center. Now duplicate it and Assign Adobe RGB (the numbers don't change, the Lab values do indicate the new translation). Since you duplicated the image, the sample point in the dupes stay exactly in the same position. In my case, I see that the sRGB profile has an Lstar of 23, the Adobe RGB doc has an Lstar of 21. Now make a "false profiles" using 2.0, in fact just open sRGB as supplied by Photoshop and select Save RGB... to build a new "false profiles". Duplicate the Adobe RGB doc, Assign this "false profiles", you get the same Lstar as the Adobe RGB doc (Lstar 21 in this case) but not the sRGB doc due to the fact that sRGB is defined using a more complex curve (and it was specified for a reason). It is not a simple gamma curve like all these "false profiles". Gromit could actually be reducing the so called blocked up shadows in his sRGB document, certainly any area where sRGB calls for its shadow curve, with a "false profiles", not the other way. And not until the Lstar gets far above the value anyone I believe would consider a dark area of an image would the Lstar values now get lighter. Talk about counter productive!

Interesting update, playing around with a much higher rez file, Lstar 2 to 50 gradient, then posterized into 10 steps. With the 2.0 “false profile” look what happens in the deeper shadow tones (the opposite of what Gromit expects):

0/0 (0 change we did map Lstar 2 to zero with the Posterize command which may explain the next to results but I doubt it), 3/2 (-1), 9/7 (-2!), 15/15 (0), 21/22 (1), 27/28 (1), 32/34 (2).

With a “false profile” using 1.8.1, a much larger “curve”:
0/0 (0), 3/4 (1), 9/13 (4), 15/21 (6), 21/28 (7), 27/34 (7), 32/40 (8, curve is maxing out here, far from our shadows), 38/46 (, 43/51 (, 48/55 (7).

Clearly this idea of a “false profile” affecting shadows is bogus when its producing far larger numeric changes in late quarter/midtones. In the case of the 2.2 to 2.0 “false profile”, I’m actually seeing more deep shadow tones blocking up, not the opposite but this could be from the Posterize command, used to make it easier to see the effect of the profile although I suspect that’s what happened to the Lstar 0, it doesn’t explain why the “false profile” makes a negative value here. What a complete mess of a tonal correction.