Luminous Landscape Forum

Raw & Post Processing, Printing => Digital Image Processing => Topic started by: cripkd on August 31, 2010, 03:38:39 am

Title: PSD with embedded color profile cross OS issues
Post by: cripkd on August 31, 2010, 03:38:39 am
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.
Title: Re: PSD with embedded color profile cross OS issues
Post by: gromit on August 31, 2010, 04:39:57 am
I have a psd file, from a client, with an embedded color profile in it, that I don't have.

If the profile is embedded, then you have the profile. It's, er, embedded.

Look at your Color Settings and set:

RGB: Preserve Embedded Profiles
Profile Mismatches: Ask When Opening - OFF
Missing Profiles: Ask When Opening - ON
Title: Re: PSD with embedded color profile cross OS issues
Post by: cripkd on August 31, 2010, 06:29:43 am
I know what embedded profiles are, I don;t know why I explained that i don;t have it, i should have said that it's not the one I use when working in photoshop.
My question is if i will ever be able to get the design, starting with a custom color profile, to look the same on all os's and browsers (and look how the psd looks on the machine that produced it), and if yes, what are the usual steps to handle that.
Title: Re: PSD with embedded color profile cross OS issues
Post by: gromit on August 31, 2010, 06:36:18 am
I know what embedded profiles are, I don;t know why I explained that i don;t have it, i should have said that it's not the one I use when working in photoshop.

The default working space you've specified in Color Settings is irrelevant. Converting from one space to another should only be done if you have a specific reason for doing so (and using 16-bits). Just use the embedded profile. It makes no difference if the image originated on Windows or Mac.
Title: Re: PSD with embedded color profile cross OS issues
Post by: cripkd on August 31, 2010, 07:33:03 am
So am I to understand that the visual differences noticed come only from the different LCD screen's they are beeing watched on?
That is strange cos the client is comparing my html layout (which on my computer looks like the psd in photoshop) to the same psd opened in PS on his mac and he sais the colors are washed out to a certain degree.
Title: Re: PSD with embedded color profile cross OS issues
Post by: TimG on August 31, 2010, 08:15:50 am
Sounds like the issue is gamma, specifically, the client's is set to 1.8 and yours is set to 2.2
Title: Re: PSD with embedded color profile cross OS issues
Post by: Wayne Fox on September 02, 2010, 01:43:33 am
Sounds like the issue is gamma, specifically, the client's is set to 1.8 and yours is set to 2.2
Certainly gamma 1.8 might produce the described result, but gamma is set when you create the display profile, not a setting you change.  The Mac "default" (there really isn't a default) has been 2.2 for a while now, but 1.8 hasn't been practiced for a very long time (I can't remember using it since before OS X was introduced) One of those urban myths that just don't ever go away.

 I believe Apple's display profiles have been built using a different gamma setting since they went to all LCD panels away from CRT's - which was some time ago.  building a profile with 1.8 gives pretty crappy results, the default apple ones (which is the one mentioned) are not even close to that.  I don't know if they are 2.2 but they certainly aren't 1.8.

The question I would ask is why is a monitor profile embedded into the file.  that sounds like a disaster waiting to happen.  If the client is going to be preparing files it makes sense to work with them to set up their mac and photoshop so they are providing useful files.

And of course, once you prepare the web files,  best options for web is still non color managed jpegs  ... no embedded profiles.

If things are washed out, it could even be just a difference in the brightness of their display vs the one the web work was done on.  unfortunately how things look on the web right now is a crap shoot, with tons of variables (display, browser, color management settings, display brightness).
Title: Re: PSD with embedded color profile cross OS issues
Post by: jbrembat on September 02, 2010, 03:22:38 am
Quote
And of course, once you prepare the web files,  best options for web is still non color managed jpegs  ... no embedded profiles.
Best web options are:
1- jpg  (the best choice for good quality and small filesize)
2- sRGB (the best choice for non color managed browsers)
3- embedded profile (good for all color managed browsers)

Jacopo
Title: Re: PSD with embedded color profile cross OS issues
Post by: stamper on September 02, 2010, 04:10:41 am
Certainly gamma 1.8 might produce the described result, but gamma is set when you create the display profile, not a setting you change. 

This isn't true.

http://www.ledet.com/margulis/ACT_postings/ProfilingandProofing/ACT-False-Profile.htm



Title: Re: PSD with embedded color profile cross OS issues
Post by: TimG on September 02, 2010, 08:46:47 am
Certainly gamma 1.8 might produce the described result, but gamma is set when you create the display profile, not a setting you change.  The Mac "default" (there really isn't a default) has been 2.2 for a while now, but 1.8 hasn't been practiced for a very long time (I can't remember using it since before OS X was introduced) One of those urban myths that just don't ever go away.

While I agree with what you are saying, it's the OP's client who is seeing washed out colors, not the OP.  My response was based on an educated guess the client's display is not calibrated.  The embedded profile name is the default for Cinema Displays, which leads me to believe it is not (has not been) calibrated.

Actually, 1.8 was around after OSX was introduced, at least up until 10.4.  I think it changed after the move to Intel.  I have a G5 in my studio which shipped with 10.4 and it came from the factory set to 1.8.
Title: Re: PSD with embedded color profile cross OS issues
Post by: digitaldog on September 02, 2010, 10:05:42 am
Certainly gamma 1.8 might produce the described result, but gamma is set when you create the display profile, not a setting you change. 

This isn't true.

http://www.ledet.com/margulis/ACT_postings/ProfilingandProofing/ACT-False-Profile.htm

Best I can say is ignore anything posted by Margulis concerning color management, especially a post that old. Altering the gamma this way isn’t color management.
Title: Re: PSD with embedded color profile cross OS issues
Post by: stamper on September 02, 2010, 11:34:38 am
My reply was correct in the context of what Wayne posted. As to be any good it is a matter of opinion. Your outright condemnation of Dan does you no favours Andrew. He can't be wrong about everything?
Title: Re: PSD with embedded color profile cross OS issues
Post by: digitaldog on September 02, 2010, 12:31:01 pm
He's right about a lot of stuff. Color management in general, using a hack to a profile to affect the tone of an image, not so much as Chris Murphy and I pointed out in this very old thread. Making up terms that don’t exist nor need to (“false profile”) is a pet peeve.
Title: Re: PSD with embedded color profile cross OS issues
Post by: gromit on September 02, 2010, 06:16:14 pm
He's right about a lot of stuff. Color management in general, using a hack to a profile to affect the tone of an image, not so much as Chris Murphy and I pointed out in this very old thread. Making up terms that don’t exist nor need to (“false profile”) is a pet peeve.

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

Maybe you need to get out more ...
Title: Re: PSD with embedded color profile cross OS issues
Post by: digitaldog on September 02, 2010, 07:05:46 pm
Quote
"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).

No they don’t. Read the link again, read what Chris and I said about this. There is no such thing as a false profile. There are incorrectly embedded profiles. The assignment of this so called false profile doesn’t alter the numbers one bit until you convert the data (so there’s no free lunch here) and, if the incorrect profile was embedded in the first place, that’s the reason the data appears to have blocked shadows. Otherwise color management was correct and someone blocked up the shadows by incorrectly scanning or capturing the image and the numeric values need to be and can be altered using Photoshop or another image editor.

You can also use a kitchen knife as a screw driver but don’t delude yourself into thinking its the right tool for the job or that its better suited as a screw driver than a kitchen knife.
Title: Re: PSD with embedded color profile cross OS issues
Post by: gromit on September 02, 2010, 08:11:53 pm
No they don’t. Read the link again, read what Chris and I said about this.

They work for me, probably because I spent the time investigating how they could be used effectively in my own workflow rather than endlessly arguing on internet forums that they don't.
Title: Re: PSD with embedded color profile cross OS issues
Post by: digitaldog on September 02, 2010, 08:27:03 pm
They work for me, probably because I spent the time investigating how they could be used effectively in my own workflow rather than endlessly arguing on internet forums that they don't.

They work for you like the fellow who’s smoked 5 packs of cigarettes a day, then admits that having his left lung removed has worked well for him.

The questions you should be asking yourself is what is assigning the profile doing, why is the image blocked up in the first place. Assigning a profile has a role; its to provide the numbers a scale and definition. It doesn’t alter the values at all. If the original image has an incorrect profile, or its untagged, assign profile plays an important role. Its not a color correction move as Chris (and I) correctly point out. The failure of Dan and others to understand exactly what is happening is key here! Like Dan, polishing a turd is far less useful than avoiding turds in the first place by either properly capturing or handling images correctly. You are welcome to believe in magic underwear or “false profiles” (which again, is a made up term that has nothing to do with profiles or color management, or being false). Dan and his followers would end up spending far less work and end up with far better data if they simply strived to produce good data from the get-go. I fully understand that in some workflows, workflows from the 90’s when Dan thought up a lot of his techniques, getting lemons demanded one make lemonade. Its useful when there is no other option. No one does it better but it isn’t something we should hope for nor expect.

I would expect you have control over the images you create but maybe you work in a service bureau and have to polish images provided to you. If so, stick with Dan’s techniques. If not, ask yourself why you have a turd to polish in the first place! Its like the photographer who doesn’t understand how to properly expose his film, so the ‘fix’ is push it in the process. Or someone who doesn’t understand how to correctly develop their negs, so the ‘fix’ is to leave the print in the developer a lot longer, hoping for an acceptable image. Don’t you think proper exposure and development is a better approach? I do. But if like Dan, your lifes blood is teaching people how to fix crap images, its not in your best interest to get good data in the first place. That’s why he suggest silliness like setting ACR controls all to zero, then ‘fixing’ the resulting turd in Photoshop with a lame excuse that the curves in ACR are broken (despite the fact that it was designed this way from some very smart people at Adobe). If all you know is a hammer, everything looks like a long, extended Photoshop exercise to fix the sloppiness at capture.

So why are your shadows plugged up and why do think that assigning a profile that presumably isn’t the correct descriptor of the data is useful? Or is the original embedded profile just flat out wrong? I’m not interested in arguing, I’m interested in YOU looking a bit further under the hood here. Do it, don’t do it, makes little difference to me. But it may make a difference to you.
Title: Re: PSD with embedded color profile cross OS issues
Post by: stamper on September 03, 2010, 04:23:13 am
Quote

I would expect you have control over the images you create but maybe  you work in a service bureau and have to polish images provided to you. If so, stick with Dan’s techniques. If not, ask yourself why you have a turd to polish in the first place! Its like the photographer who doesn’t understand how to properly expose his film, so the ‘fix’ is push it in the process. Or someone who doesn’t understand how to correctly develop their negs, so the ‘fix’ is to leave the print in the developer a lot longer, hoping for an acceptable image. Don’t you think proper exposure and development is a better approach? I do. But if like Dan, your lifes blood is teaching people how to fix crap images, its not in your best interest to get good data in the first place. That’s why he suggest silliness like setting ACR controls all to zero, then ‘fixing’ the resulting turd in Photoshop with a lame excuse that the curves in ACR are broken (despite the fact that it was designed this way from some very smart people at Adobe). If all you know is a hammer, everything looks like a long, extended Photoshop exercise to fix the sloppiness at capture.

Unquote.

Andrew you seem to have a penchant for repeating the same attacks year after year in different forums using the same terms to attack Dan. Terms such as turd polishing etc etc. Are you saying that every image and every scan you deal with is "correct" to start with? As to the controls in ACR and zeroing them out, then you are the one who has it wrong. Camera Raw CS3 book by Fraser and Schewe page 129.

Quote

Camera Raw's "default" is only an arbitrary starting point. There's nothing sacred, nothing neither technically accurate nor particularly important with the default rendering of your capture. It's only a consistent place from which to start your evaluation and, ultimately your editing.

Unquote.

Are you going to condemn these two authors, one of which can't defend himself? I personally find the zero setting in ACR to be "best" but I am only an amateur.  You need to take a holiday from your attacks on Dan and check your facts now and again, otherwise your good work in other areas will become tainted and your deserved reputation damaged?

 
Title: Re: PSD with embedded color profile cross OS issues
Post by: stamper on September 03, 2010, 04:39:29 am
Quote

No they don’t. Read the link again, read what Chris and I said about this. There is no such thing as a false profile. There are incorrectly embedded profiles. The assignment of this so called false profile doesn’t alter the numbers one bit until you convert the data (so there’s no free lunch here) and, if the incorrect profile was embedded in the first place, that’s the reason the data appears to have blocked shadows. Otherwise color management was correct and someone blocked up the shadows by incorrectly scanning or capturing the image and the numeric values need to be and can be altered using Photoshop or another image editor.

Unquote.

I hesitate to step in here because I am no expert and only an amateur, but I will. My understanding of this is if someone inadvertently takes an image that has been underexposed by a couple of stops then re assigning the gamma will be a better starting point for editing an image. If the original image had curves and blend modes applied to it then noise and image degradation would soon be evident. Someone once asked me to salvage an image that was important to him. The false profile worked best. It wasn't perfect but he was pleased. Michael Kieran in Photoshop Color Correction advocates this approach to. Do you want to attack him as well. This isn't meant to be a mainstream method of image editing. Your black and white condemnation does you no favours?
Title: Re: PSD with embedded color profile cross OS issues
Post by: jbrembat on September 03, 2010, 06:22:28 am
I agree completely with Andrew.
If you assign a different (from the true one) color space to an image you have a different monitor rendition (RGB numbers are the same).

May be you can get a better monitor rendition, but RGB numbers are the same.
You are trying to optimize the monitor rendition acting on image profile instead of acting on RGB numbers.
This is a very involved system that doesn't guarantee anything when you convert to a different output color gamut.

In other words:this is a blind guess for the final rendition.
The trick may be optimized for a particular device, but may be inappropriate for another device.

This is exactly the contrary of color management that try to unify the rendition.And this is the right way.

Jacopo
Title: Re: PSD with embedded color profile cross OS issues
Post by: digitaldog on September 03, 2010, 09:56:47 am
Are you saying that every image and every scan you deal with is "correct" to start with?

My job as a scan operator (something I did professionally for years) is to either match as closely as possible, the original or improve it. The later happens globally with good scanning software at the scan stage not afterwards in Photoshop. The reason is the same as I stated; its faster and provides far better quality data.

Quote
Camera Raw's "default" is only an arbitrary starting point. There's nothing sacred, nothing neither technically accurate nor particularly important with the default rendering of your capture. It's only a consistent place from which to start your evaluation and, ultimately your editing.

You are either misunderstanding the writing here or using the text to imply that what Dan suggests makes any sense at all. Do you have any idea how butt awful nearly all images appear with the controls set to zero? Are you sure you are reading the above text to imply that making the image look awful using the supplied controls instead of providing a desired color appearance different from the defaults is what the authors are saying?

You need to read that book again, because in no way are the authors (both partners of mine) implying what Dan is saying to his minions is necessary nor why he proposes this nonsense (his idea about the “master” curve, another made up term**). They are not advocating anyone set the various controls at the settings other than that which produce a desired appearance IN ACR.

** I suggest you read this http://www.luminous-landscape.com/essays/Curves.shtml
Title: Re: PSD with embedded color profile cross OS issues
Post by: digitaldog on September 03, 2010, 10:01:05 am
My understanding of this is if someone inadvertently takes an image that has been underexposed by a couple of stops then re assigning the gamma will be a better starting point for editing an image.

Your understanding isn’t correct. Get to the root of the problem. Either you have an image with an incorrect embedded profile and the color appearance looks poor as a result and you need to provide the correct description of the values OR you did a piss-poor job capturing the data and you need to begin with the correct values. Profiles as the name implies describe existing values or values that will exist after a conversion using it and the source profile that define those values. They are not designed nor intended for color correction. Why are your images (the existing RGB values) under exposed? That’s the questions you should be asking and attempting to fix!
Title: Re: PSD with embedded color profile cross OS issues
Post by: stamper on September 03, 2010, 12:03:39 pm
Quote


You are either misunderstanding the writing here or using the text to imply that what Dan suggests makes any sense at all. Do you have any idea how butt awful nearly all images appear with the controls set to zero? Are you sure you are reading the above text to imply that making the image look awful using the supplied controls instead of providing a desired color appearance different from the defaults is what the authors are saying?

Unquote

I did state that I set everything to zero so I must see that they "are butt awful" ? They must be butt awful before Adobe sets an arbitrary setting to them? If I have a high contrast image imported to Camera raw then I don't want to start with an arbitrary setting that affects the image in a way that makes it even more high contrast. I want to start with a setting that is closer to the original. You seem to see everything in terms of a professional operator whilst most people try to see them from a photographic point of view? You also hector people when posting that is - imo - intended to bullying them into believing your theoretical point of view. You obviously know more about this subject than most but not from a practical point of view. I did state that the fixing of the photo was a favour and I recognized it was a poor image to start with but approached it in a practical manner rather than your theoretical scan operator ways which most people here aren't bothered about. To sum up a more practical approach rather than trying to browbeat people with profiles and RGB numbers would go down better?
Title: Re: PSD with embedded color profile cross OS issues
Post by: digitaldog on September 03, 2010, 01:15:49 pm
I did state that I set everything to zero so I must see that they "are butt awful" ?

So when you set everything at zero, the raw images appear ideal to you? OR you alter the sliders to produce a desired color appearance? Dan’s stance is, you set everything to zero, render the data into Photoshop and now make the image look good. That’s just dumb for so many reasons.  

Quote
They must be butt awful before Adobe sets an arbitrary setting to them? If I have a high contrast image imported to Camera raw then I don't want to start with an arbitrary setting that affects the image in a way that makes it even more high contrast. I want to start with a setting that is closer to the original.

Zero setting isn’t the original. The original is scene referred and ACR never produces that. A zero setting may attempt to get closer to a scene referred rendering but what’s the point of using a raw converter to render the data if you insist on setting everything to zero, then fixing the resulting mess in Photoshop? That’s exactly what Dan proposes. See: http://www.color.org/ICC_white_paper_20_Digital_photography_color_management_basics.pdf

Quote
You also hector people when posting that is - imo - intended to bullying them into believing your theoretical point of view.

Not my intent and I think you are taking this too personally. Someone posted a very old link to Dan’s Color Theory list about using a bogus technique using ICC profiles. The link has salient points by myself and Chris Murphy as to why this is bogus. Find one color scientist, color software engineer, member of the ICC, author of a color management book or even an advanced user who agrees this is just a silly technique. Its akin to having an image that is too dark on screen and “fixing” the issue by upping the backlight of the display to make it brighter. Well heck, the image doesn’t look dark anymore, issue fixed. That the numbers didn’t change didn’t occur to the person who thinks this made an improvement (as the numbers in the original image didn’t change with the new profile assignment). That the image is still dark and subsequent images will likely be captured too dark due to some error in operation isn’t on these people’s radar and it should be. A “false profile” fixed the issue. Well it didn’t.

Zeroing ACR sliders, rendering and then making the image appear as you desire later in Photoshop is equally silly. Think about it before you suggest that I’m bullying but rather asking you to use that organ between your ears. Instead of taking what Dan or I say as gospel, why not think about the practical implications here and do some testing.

And here lies the issue I have with Dan. He has designed controversial ideas and techniques that have very little peer review, or I should say, he never answers the peer review provided but instead hides behind his Color Theory Yahoo list which is heavily moderated and censored. Chris and I, among others were banned from posting because peer review isn’t on Dan’s mind and apparently those who read his list. There is a link to Mark’s article on Curves as a counter to Dan’s ideas and while Dan was invited to further discuss this, he never did. I wonder why? There are his flat earth theories about 16-bit editing that was addressed in a peer review by a very smart color scientist named Bruce Lindbloom (see: http://www.brucelindbloom.com/index.html?DanMargulis.html). Any reply to this peer review? Nope. In fact, outside his censored list, can you find any posts by Dan on any site where his ideas are questioned? Nope. The issue is, poor end users like yourself read this stuff and believe that setting ACR sliders to zero or using a false profile, or believing that high bit editing is unnecessary just take it like its a fact. Despite the facts that scanner and camera, display and some printer manufacturers support high bit workflows and have for years. The color scientists there are wrong and Dan’s right? Thomas Knoll who designed Photoshop is wrong about how he coded the curves and other sliders in ACR but Dan’s right?

Find an Adobe engineer, a color scientist, author or expert on color management who agrees with the three flat earth theories uncovered above.

Try this. Alter the sliders to your hearts content in ACR to produce a rendering you like and hit OK. Then do the same task with the sliders set to zero and fix the mess in Photoshop. Which took longer overall? Really look at the data, which is cleaner? Now consider you have to do this to 20 images let alone 200. Don’t use a “false profile”, just crank up the display luminance and would you agree the image looks better?

I think I own every book Dan’s written. I’ve seen him present a number of times at Photoshop world. We’ve even broken bread on occasions (in some cases I’ve seen bread thrown at him but that’s another story). He has some very useful information to provide, along with some severely silly ideas about image processing. The problem is, people read both and without testing the waters, or looking for true peer review, or asking others if the idea makes sense, they go off and believe its true and worse, post links to the dribble to others who are equally unable to decipher the good bits from the nonsense. If someone seriously questions these ideas to Dan, and the only place to do so is on his list, it doesn’t take long to get banned from the site. And the BS continues to float about the web which is a darn shame.
Title: Re: PSD with embedded color profile cross OS issues
Post by: Wayne Fox on September 03, 2010, 05:02:22 pm
Certainly gamma 1.8 might produce the described result, but gamma is set when you create the display profile, not a setting you change. 
This isn't true.

http://www.ledet.com/margulis/ACT_postings/ProfilingandProofing/ACT-False-Profile.htm

I'm not quite sure how this relates to the disucssion.  The problem is someone viewing an image that is suspected of not having a "calibrated" display, and the possible answer is that person has the gamma set wrong on their mac, something related to the way macs default gamma used to be different than windows.

But there is no gamma "setting" on a Mac.  You can't go to the display preference pane and "change" the gamma.(I certainly don't have one).  The gamma is built into the profile, and certainly the person viewing this image, if indeed their display is "uncalibrated" indicates they don't have the knowledge of doing some strange task as discussed in the linked thread. And based on the mentioned embedded profile which is a display profile built by Apple, I seriously doubt it was built with gamma 1.8.


Actually, 1.8 was around after OSX was introduced, at least up until 10.4.  I think it changed after the move to Intel.  I have a G5 in my studio which shipped with 10.4 and it came from the factory set to 1.8.
If you build a profile with a gamma of 1.8 it doesn't look anything like the supplied apple profile, and hasn't for a long time.  An in fact it hasn't been used by those creating display profiles for even longer.  So while it might have been "around" and been the "default", no one building display profiles including apple has used it for a long time.  (Of course, "long" is a relative term when speaking of computer technology).
Title: Re: PSD with embedded color profile cross OS issues
Post by: gromit on September 03, 2010, 10:08:27 pm
The questions you should be asking yourself is what is assigning the profile doing, why is the image blocked up in the first place.

Since your real world experience would appear to be somewhat limited, let me pass on the following:

A few days ago I printed a chiaroscuro image for a client. We were looking at the resultant print and she was telling me how important the detail in deep shadows in the foreground was and how she had recently bought a new monitor, carefully calibrated it (presumably to gamma 2.2) and tuned the shadows precisely. However, when I had opened the image on my monitor (hardware calibrated to L*) I could see the shadows were blocked. I precisely linearize all B&W output so printing it as is would result in these blocked shadows and kill the image. My role, as I see it, is to second guess what the client wants and deliver this. So I applied an Adobe RGB (1998) profile modified with an sRGB gamma curve and its linear toe opened up the shadows to what she intended, even if the file she supplied didn't convey this. It's a simple enough trick.

Now you can argue all you like about how "false profile" isn't a valid name and how this is counter to all colour-management principles (blah blah blah) but the fact is it delivered the results ... and has done on many, many occasions. In fact, pretty well every gamma 2.2 based file I receive with important shadow detail needs such treatment. Maybe you should give it a try. Or you could print the image as is, tell them that the blocked shadows are all their fault, they should know better than to use gamma 2.2 etc. Guess which one of us will have more repeat clients.
Title: Re: PSD with embedded color profile cross OS issues
Post by: stamper on September 04, 2010, 04:03:02 am
Quote

Zeroing ACR sliders, rendering and then making the image appear as you desire later in Photoshop is equally silly.

Unquote

That isn't what I do. I zero the sliders and then render the image in ACR first just as anyone does and then import to Photoshop. In your original post you didn't make clear that Dan was zeroing the sliders and importing the image directly to Photoshop hence the reason for defending the use of the zeroing method. I think in your haste to badmouth him you don't always do it in a "objective" manner but you give him both barrels without giving any leeway. This doesn't go down well with a lot of people. Like him or loath him he has sold a lot of books and I see him as a pioneer who doesn't always get it right? The fact that you and others attack him means that a lot of people learn from it. I just wish your attacks would be a bit better balanced and we could learn more?
Title: Re: PSD with embedded color profile cross OS issues
Post by: stamper on September 04, 2010, 04:07:35 am
This isn't true.

http://www.ledet.com/margulis/ACT_postings/ProfilingandProofing/ACT-False-Profile.htm


I'm not quite sure how this relates to the disucssion. 

Unquote

I was just pointing out that gamma could be changed. It wasn't a dig at you, but trying to add to the post. Unfortunately a bull in the China shop proceeded on a trampling operation bellowing bellicose that wasn't needed.
Title: Re: PSD with embedded color profile cross OS issues
Post by: jbrembat on September 04, 2010, 04:38:31 am
Quote
So I applied an Adobe RGB (1998) profile modified with an sRGB gamma curve and its linear toe opened up the shadows to what she intended, even if the file she supplied didn't convey this. It's a simple enough trick.
There are other methods to open shadows editing the image not the profile.

If you start to change profiles instead of RGB numbers, you are on the wrong way.
You can think that the results are about the same, but it isn't true.

Suppose you are preparing a photo for web publishing.
You can correct the lut of sRGB color space to make the image brighter.
But your change is in the profile, RGB numbers are the same.
On non color managed browser your editing does not exist.

Jacopo
Title: Re: PSD with embedded color profile cross OS issues
Post by: gromit on September 04, 2010, 04:41:15 am
There are other methods to open shadows editing the image not the profile.

If you start to change profiles instead of RGB numbers, you are on the wrong way.

OK, I'm game. Why?
Title: Re: PSD with embedded color profile cross OS issues
Post by: stamper on September 04, 2010, 04:42:02 am
Zero setting isn’t the original. The original is scene referred and ACR never produces that. A zero setting may attempt to get closer to a scene referred rendering but what’s the point of using a raw converter to render the data if you insist on setting everything to zero, then fixing the resulting mess in Photoshop? That’s exactly what Dan proposes. See: http://www.color.org/ICC_white_paper_20_Digital_photography_color_management_basics.pdf

Unquote
Quote

That’s why he suggest silliness like setting ACR controls all to zero, then ‘fixing’ the resulting turd in Photoshop with a lame excuse that the curves in ACR are broken (despite the fact that it was designed this way from some very smart people at Adobe). If all you know is a hammer, everything looks like a long, extended Photoshop exercise to fix the sloppiness at capture.

Unquote

Andrew please educate me if possible. I have read the link four or five times and I don't see a reference to zeroing sliders and importing directly to Photoshop. What I read is about the difficulties of getting data from Raw to Photoshop that is rendered the same. He writes about different converters doing it differently with different colour spaces. It is well known that different companies keep their secrets well guarded thus it is impossible to get the same result with different converters. You are obviously are clued up better than most, but I can't see where you draw this conclusion? You are deducing more than I can.
Title: Re: PSD with embedded color profile cross OS issues
Post by: digitaldog on September 04, 2010, 11:23:35 am
Andrew please educate me if possible. I have read the link four or five times and I don't see a reference to zeroing sliders and importing directly to Photoshop.

Just check the Color Theory archives, the only place you’ll find actual text by Dan, a often difficult cookie trail by design. Note “this new workflow” is some “fix the turd in Photoshop” that you broke by zeroing out all the sliders.

Here’s one such post by Dan:

On Apr 18, 2008, at 2:32 PM, Dan Margulis wrote:

With respect to doing things that might make the picture temporarily look
better, ACR should be avoided in this workflow because of its master-curve
approach to setting range. Instead, accept the camera's white balance and
zero everything else out
. I recommend this approach even in traditional
workflows, but in this new workflow it's particularly necessary.

------

In a reply post to Jerry asking about this strange idea the same day:

> Second, what is the meaning of zeroing everything out in ACR? My
> hypothesis is this:
>
> Start by setting the default ACR settings (below the white-balance
> settings), which includes these zeros: Exposure, Recovery, Fill
> Light, Clarity, Vibrance, and Saturation. Then, change the setting
> for Blacks from 5 to 0 (to leave the shadow point lighter). I think
> Brightness should probably be left at its default of +50.

It should not. this is an example of the sort of setting referred to earlier, one
that makes the image look better temporarily but in the long run is damaging.

The inadequacies of ACR's implementation of this command have been
discussed at some length in the thread and are also mentioned in Stephen
Marsh's post that hit the list at approximately the same time as yours.

> For me the main quandary is what to do with Contrast. Leave it at the
> default of +25?

No. Also, the curve setting should be set to Linear. Each of these defaults
suppress shadow and highlight detail in the interest of enhancing the
midrange of each channel. While that sacrifice may well be what we want to
do at some later time, in the context of this workflow it's premature to make the
decision in the raw module
. We have plenty of time to do it later on, if that's
what we want.
-------

And Dan’s take on ACR and perhaps raw rendering in general (hard to know if he’s ever use any other raw converter):

On Apr 28, 2008, at 10:27 PM, Dan Margulis wrote:
Additionally, some of the bells and whistles found in raw modules emulate
expert-only tools in Photoshop. Not as flexible, but still opening the door to the
less skilled.

I tested ACR carefully in Photoshop CS2, not from the point of view of the
beginner but the skilled user. I was not really concerned with how much time
was involved. I can see white balance as a useful, possibly time-saving
alternative to correcting certain casts in Photoshop, but it does not offer
superiority. The remainder of ACR/CS2 is seriously impacted by the
inadequate range-setting routines*. Consequently, I wrote that I was unable to
find any images where a better final result could be obtained by any
combination of ACR/CS2 commands than by opening with everything zeroed
out.


So the silly idea is two fold. One, there’s something wrong with ACR of which Mark addressed in his piece on curves referenced already. A peer review again ignored by Dan. 2nd, the idea you should build a turd in ACR because of this silly idea and then fix it in Photoshop. Note he’s referring to ACR in Photoshop CS2, I have seen nothing from Dan since then that states otherwise begging the question if Dan has looked at updates to the ACR engine since then. I suspect not.

*Another made up Dan term that needed clarification on the list (people asking, WTF are you referring to). But that’s a different story.
Title: Re: PSD with embedded color profile cross OS issues
Post by: digitaldog on September 04, 2010, 11:39:03 am

A few days ago I printed a chiaroscuro image for a client. We were looking at the resultant print and she was telling me how important the detail in deep shadows in the foreground was and how she had recently bought a new monitor, carefully calibrated it (presumably to gamma 2.2) and tuned the shadows precisely. However, when I had opened the image on my monitor (hardware calibrated to L*) I could see the shadows were blocked.

Why and how do you ensure this doesn’t happen again? This was from a scan? Raw capture with less than idea rendering? The damage is done so to speak. The shadows are blocked. Assigning a profile doesn’t change that fact.
You continue to ignore the facts that: A. The image had blocked up data and B, the “false profile” didn’t change that one bit (the numbers did not change). You could have cranked up the display luminance to make the image appear brighter and maybe seen the shadows more easily but this “fix” is no different from what you did with this so called false profile. The numbers are exactly the same as they were from the get go. Do you not see this correlation?

Quote
Now you can argue all you like about how "false profile" isn't a valid name and how this is counter to all colour-management principles (blah blah blah) but the fact is it delivered the results ... and has done on many, many occasions. In fact, pretty well every gamma 2.2 based file I receive with important shadow detail needs such treatment. Maybe you should give it a try. Or you could print the image as is, tell them that the blocked shadows are all their fault, they should know better than to use gamma 2.2 etc. Guess which one of us will have more repeat clients.

Again, you are missing what’s happening here. I’ll try once more. The values didn’t change. The description of the values did. When you converted to whatever output color space you used to print, this new definition was used as the source of the conversion. Had you pulled a curve or used some other more controllable function in Photoshop to change the numbers, you’d have ended up with different values prior to the conversion. The false profile and the original profile both produce different RGB values after a conversion. This magic false profile, in the case of a 2.2 gamma adjustment (or vise versa) is a very simple curve, nothing more, that is applied to the data when you convert. You had less control using this simple, preset curve (from the gamma adjustment) than had you just pulled a curve on an adjustment layer and worse, unlike an adjustment layer, you have no further control over a layer, its not non destructive in terms of the adjustment layer prior to flattening and printing. You pulled a simple and uneditable curve using the wrong (or one should suggest correct) profile assignment in the crudest fashion when you could have used the Photoshop tool set correctly, with more control and with more options. You basically moved to the “beginner” mistake of correcting tone using the old Contrast and Brightness slider rather than using the advanced and more controllable Curves on an Adjustment layer. Feel better about this silly “false profile” now?

What you need to do is sit down and contemplate what the assignment of an ICC profile does to an image when you use Assign Profile and after. Then contemplate what the goal of doing this is (why it was designed in the first place) and what you hope to accomplish in editing this image. You should see, as others besides myself have told you is, its a silly, not very effective use of the wrong tools found in Photoshop. A technique that can be done with far more control and options today and into the future editing of the document. You are using that funny looking knife used to clean a dirty horse hoof as a scalpel for delicate brain surgery which those of us who understand these things are telling you is not a good use of the toolset.
Title: Re: PSD with embedded color profile cross OS issues
Post by: digitaldog on September 04, 2010, 11:56:51 am
That isn't what I do. I zero the sliders and then render the image in ACR first just as anyone does and then import to Photoshop.

Good. I still see no reason to start with zero settings that would make most images look far worse than a default rendering you can build (you can create you own ACR defaults) but the bigger issue is you are NOT doing what Dan suggests. Zeroing out the sliders and using that as a rendering for all other work in Photoshop.


Quote
In your original post you didn't make clear that Dan was zeroing the sliders and importing the image directly to Photoshop hence the reason for defending the use of the zeroing method.

And your post, in reference to Dan’s ACR ideas didn’t make it clear you zero out the sliders as a starting point then make the image look good using those sliders (notice I did ask you about this). Hopefully you can see that zeroing out the sliders and hitting Open in ACR is a flat earth theory of an idea.

Quote
I think in your haste to badmouth him you don't always do it in a "objective" manner but you give him both barrels without giving any leeway. This doesn't go down well with a lot of people. Like him or loath him he has sold a lot of books and I see him as a pioneer who doesn't always get it right? The fact that you and others attack him means that a lot of people learn from it. I just wish your attacks would be a bit better balanced and we could learn more?

Dan’s a big boy and can defend his ideas outside his list if he wishes but he doesn’t dare do so thanks in large part to what happened in the early 90s when he did this on the old Compuserve Photo forum and Bruce Fraser (among others) tore him a new one on many occasions. That’s how far back Bruce and I (and Dan) go in terms of peer review of Dan’s ideas. I have some of this also archived, its hilarious how Bruce would chop Dan’s legs off as only Bruce could. God I miss him. But to get back to your point above, I don’t feel I’m bad mouthing him, I’ve got plenty of original text as seen here that allows his ideas to speak for themselves even if he will not outside his highly censored list. Its too bad I have to archive and present them outside the list. I’ve seen scores of end users drink this koolaid for years and I feel for them. Its not about getting it right or not. There is simply no peer review process here and one can only imagine how many unsuspecting readers think that the ACR zero idea, the misunderstanding of high bit editing or other such strange ideas are not worth questioning.
Title: Re: PSD with embedded color profile cross OS issues
Post by: gromit on September 04, 2010, 12:31:52 pm
You basically moved to the “beginner” mistake of correcting tone using the old Contrast and Brightness slider rather than using the advanced and more controllable Curves on an Adjustment layer.

We're talking about a micro adjustment here and Curves just don't do the same job. This was explained on the linked thread. Often a fixed tweak to the deepest shadows with the method outlined is just what's needed.

I honestly question whether you simply don't understand things outside of your limited world (you certainly show no evidence of trying them out in a practical sense) or your increasingly long-winded and belittling responses are just arguing for arguing sake.
Title: Re: PSD with embedded color profile cross OS issues
Post by: digitaldog on September 04, 2010, 12:44:54 pm
They work for me, probably because I spent the time investigating how they could be used effectively in my own workflow rather than endlessly arguing on internet forums that they don't.
We're talking about a micro adjustment here and Curves just don't do the same job.

With all due respect, that’s nonsense. The investigation is sloppy and incomplete! Look at the very simple curves used in the profiles, there is a single point curve in the 1.8, a tiny tweak in the 2.2, both or which are easily achieved using PS’s curves and then some. 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? And it doesn’t change the fact you using the wrong tool for the wrong job; the profiles were never intended for the purpose you are using them for as explained ad nauseam already.
Title: Re: PSD with embedded color profile cross OS issues
Post by: Mark D Segal on September 04, 2010, 01:12:11 pm
Now you can argue all you like about how "false profile" isn't a valid name and how this is counter to all colour-management principles (blah blah blah) but the fact is it delivered the results ... and has done on many, many occasions. In fact, pretty well every gamma 2.2 based file I receive with important shadow detail needs such treatment. Maybe you should give it a try. Or you could print the image as is, tell them that the blocked shadows are all their fault, they should know better than to use gamma 2.2 etc. Guess which one of us will have more repeat clients.

Setting aside all the colour management principles which Andrew has described very well here, I would just focus on this question of how to reveal shadow detail. Firstly of course the detail needs to be retrievable from the image data. As long as it is, there are far superior tools in Lightroom and Photoshop for doing this in a highly controlled and non-destructive manner. I'll just provide some examples - in Lightroom, the combination of Fill and Blacks is capable of opening shadow detail while restoring DMax and needed contrast in the shadow regions of the image. If that isn't good enough, the area can be masked in Lightroom and the exposure, brightness, contrast of the masked area increased. Once the image is sent to Photoshop, there are yet other ways of bringing out shadow detail so powerfully that they need to be carefully controlled - for example, masking the area needing attention into a Curves adjustment layer and changing the blend mode to Color Dodge or Screen, then adjusting the shape of the Curve and the layer opacity to fine-tune the result. Techniques such as these are far superior to fiddling with profiles because they are (a) non-destructive, (b) editable after the fact, and (c) capable of far more precision.

I'll just add a footnote about zeroing sliders in Camera Raw and Lightroom. My default settings in those programs are exactly that, with the Tone Curve set to linear. But this is just to provide myself with a starting point which features "no adjustments" in terms of the program's controls. It's useful, because contrastier starting points CAN indeed block shadows and clip highlights making you believe these are image problems rather than program settings problems. Then I build the image from there within LR or ACR, using those tools to the maximum effectiveness I can derive from them. Only then do I send the image to Photoshop. This is largely a matter of taste - other people may prefer to start their editing on the basis of one of Adobe's image defaults which provide more contrast and brightness from the get-go. The point is - wherever you start from it is best to then use these tools to their maximum effectiveness relative to your image requirements within these raw converters before rendering the image to Photoshop.
Title: Re: PSD with embedded color profile cross OS issues
Post by: Wayne Fox on September 04, 2010, 01:53:56 pm
Unfortunately a bull in the China shop proceeded on a trampling operation bellowing bellicose that wasn't needed.
Such is the internet.

As an aside to your bull in a china shop reference ( a saying I myself use frequently), amazingly enough as demonstrated by the Mythbusters on Discovery Channel, this may indeed be a myth as they successfully put several bulls in a "china shop" without any major damage to the china .  I was quite amazed personally. The beasts are amazingly nimble.
Title: Re: PSD with embedded color profile cross OS issues
Post by: stamper on September 05, 2010, 04:17:21 am
Quote

I'll just add a footnote about zeroing sliders in Camera Raw and Lightroom. My default settings in those programs are exactly that, with the Tone Curve set to linear. But this is just to provide myself with a starting point which features "no adjustments" in terms of the program's controls. It's useful, because contrastier starting points CAN indeed block shadows and clip highlights making you believe these are image problems rather than program settings problems. Then I build the image from there within LR or ACR, using those tools to the maximum effectiveness I can derive from them. Only then do I send the image to Photoshop. This is largely a matter of taste - other people may prefer to start their editing on the basis of one of Adobe's image defaults which provide more contrast and brightness from the get-go. The point is - wherever you start from it is best to then use these tools to their maximum effectiveness relative to your image requirements within these raw converters before rendering the image to Photoshop.

Unquote

My thoughts exactly thus the quote from the Camera raw CS2 book. Ironically a few years ago we were getting good images out of Photoshop without first using a raw converter. A comparison of images from that bygone era with what we have now would be interesting. Sometimes I think Dan MIGHT have a point when he says that 8 bit and no raw conversion is all it takes? Do we sometimes get too hung up with using all the whistles and bells? If someone shows you a good image that was processed with the tools from ten years ago then how do you feel?
Title: Re: PSD with embedded color profile cross OS issues
Post by: Mark D Segal on September 05, 2010, 08:56:21 am


My thoughts exactly thus the quote from the Camera raw CS2 book. Ironically a few years ago we were getting good images out of Photoshop without first using a raw converter. A comparison of images from that bygone era with what we have now would be interesting. Sometimes I think Dan MIGHT have a point when he says that 8 bit and no raw conversion is all it takes? Do we sometimes get too hung up with using all the whistles and bells? If someone shows you a good image that was processed with the tools from ten years ago then how do you feel?

I'm loathe to shadow-box with second-hand renditions of the thoughts of Dan, but of course I've heard this stuff too and if meant to be a general statement it's just rubbish. Converting a raw file is not an option, it's a necessity. The only issue is how you do the conversion - what you may be referring to as the "bells and whistles". An 8 bit conversion gives you 256 levels of luminosity and a 16 bit conversion gives you over 32,000 levels in the Photoshop implementation. The more levels in the data, the more leeway you have to perform very large image edits without loosing essential photographic quality. The wider the gamut, the more colors you will allow your printer to reproduce. This has all been tested and proven ad nauseum in theory and in practice by the best technologists and imaging professionals in the industry.

Now, you can avoid raw conversion altogether by shooting JPEGs from your camera. This is fine depending on the purpose of your photography. Remember, the JPEG format was developed for rapid, economically transmissible imaging at a time when bandwidth and speed weren't what they are today, but remains very useful today - particularly handy for photojournalists sending images from the field for immediate publication, posting images to websites, etc., and it's fine as far as it goes - in fact amazingly so - just last night I was processing some JPEGs my son-in-law shot of our grandchildren using his digi-cam; native resolution 240 PPI providing an image roughly 7*10 inches. At that size and with moderate editing in Lightroom (including some interesting conversions to sepia) they look great as family snapshots, which have a cherished place in our hearts. 

But as Andrew said repeatedly above - let's use the right tools for the job. If you want to make large prints of the highest photographic quality and have maximum editing flexibility on the way to your final result, you will be shooting raw, processing as much as possible in the raw converter (yes, using every bell and whistle they provide which the image needs) and rendering the image in 16-bit ProPhoto, if not printing directly from Lightroom (where you lose soft-proofing for now). That's just the way it is. You don't have to take my word for it, but the overwhelming conclusion of all the evidence out there is that these arguments with Dan were a waste of time and bandwidth when they happened, and they are even more so now. In fact I don't know where he stands on any of this these days and in any event it really doesn't matter. We know what we know based on our own experience and the contributions of the real technologists in this field.
Title: Re: PSD with embedded color profile cross OS issues
Post by: gromit on September 05, 2010, 07:42:48 pm
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.
Title: Re: PSD with embedded color profile cross OS issues
Post by: Mark D Segal on September 05, 2010, 07:58:41 pm
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.
Title: Re: PSD with embedded color profile cross OS issues
Post by: digitaldog on September 05, 2010, 09:54:07 pm
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.
Quote
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.
Quote
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.
Quote
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!
Quote
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.
Quote
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?
Quote
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?
Quote
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):
Quote
"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."
Title: Re: PSD with embedded color profile cross OS issues
Post by: Mark D Segal on September 05, 2010, 10:18:48 pm
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.
Title: Re: PSD with embedded color profile cross OS issues
Post by: digitaldog on September 05, 2010, 11:14:44 pm
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.
Quote
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.
Quote
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?
Quote
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).

Quote
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)?  
Title: Re: PSD with embedded color profile cross OS issues
Post by: digitaldog on September 06, 2010, 11:42:06 am
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).

Quote
"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 (8), 43/51 (8), 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.