This has been confirmed on both Mac and PC by different users
(this topic was confirmed on another list before posting here).
One may be working on an image that has a different colour profile
than set as default in colour settings. For example, colour settings
has Adobe RGB while the current document is in ProPhoto RGB. If the
ProPhoto RGB (16 bpc) file is taken to 32 bpc mode, the status message
reports that the file is in a modified linear space based on the input
profile. One may then perform USM, for example and then return to 16
bpc or 8 bpc mode.
Here is the bug: Once the ProPhoto RGB file is returned to 16 or 8
bpc, it now has the working RGB space tagged of Adobe RGB, rather than
the original ProPhoto RGB as input before 32 bpc conversion. This is
not just a tagging issue, the numbers have been converted to working
RGB rather than the input ICC that was tagged to the image prior to
entering 32 bpc mode.
ICC tagged image operations have been divorced from colour settings
since version 6, the document can reside in a space that is
independent of colour settings. I can't recall other operations that
change the files colour space and tag without user intention.
If using 32 bpc edits, to preserve the input space, one either has to
change their colour settings to match the document or convert the
document to working RGB.
So why this reversion to working RGB and not the document RGB - bug or
design feature/limitation? Did CS3 work this way, is it only my
version of CS4?
I have searched the help notes, this forum and other Adobe support docs,
however I could not find this issue documented.
Can anyone post a supporting argument for the current behaviour (design or bug). While in 32 bpc Photoshop "knows" what the original profile is (it is listed as being in a linear state), while on default conversion to lower bit depth the data is converted to working RGB, rather than the document RGB prior to conversion (if different to working RGB). Am I missing something - is this a good thing, should this be behaviour be changed?
OK, topic drift it is!
Buko/progress, it is not so much bit depth in this case, it is gamma encoding - or lack thereof. 32 bpc mode processes in linear gamma, which can have an effect on some operations for certain receptive image content (tonal moves, USM, interpolation etc).
As one example, some links to linear resampling can be found in the comments at this blog:
I prefer the 32 bpc route to linear processing rather than the alternative, which is 16 bpc and a hacked custom RGB profile set to gamma 1.0.
I don't like linear USM for output sharpening (nasty dark halo artifacts). However, for subtle capture/acquisition sharpening linear USM may be preferred for certain images. I generally sharpen with blend if sliders limiting the intensity of the light halo, which comes close to one aspect of linear sharpening (light halo reduction). This can also be achieved by blending the USM in two separate layers, set to darken and lighten blending with reduced opacity.
While on USM and gamma, there are some L* based RGB working spaces such as L*RGB or the new ECI RGB which behave the same way as Lab mode Lightness channel sharpening (when set to Luminosity blend). As the response of the Lightness channel is different to linear gamma and standard gamma encoded spaces, for some image content one may be preferred over the other as the processing space.
I would still like to explore the original topic/post before submitting a bug report. How do you think things should work?
The profile used in 32 bit/channel is linear (gamma 1.0) and inappropriate for 8/16 bit content (and many overranged profiles are REALLY inappropriate). We might be able to prompt the user for the target profile when converting - but the profiles cannot be preserved. This is just like converting RGB to CMYK - the old profile no longer applies.
it's the same situation when you do a CMYK to Multichannel to CMYK transformation. The application can't have color space memory. The logic makes sense from a certain stand point, the implementation does not. It needs to change Chris. All of this is far too confusing and will get worse with every build.
In Steven's case, it was ProPhoto RGB. He converted a ProPhotoRGB to 32 bit for his operations and when bringing it back to 16 bit is when it went straight to working space. Is there no way that can be tracked from the point of the 32 bit conversion?
I'm glad Steven has brought this to everyone's attention. It's a little like going back to Ps5 and its implementation - as long as you're aware of what's going on, you can deal with it, but it seems to add an extra layer of complexity to keep in mind.
Peter - it could only be tracked in the simplest case ( 8->32->8 ). Saving and reopening, playing with smart objects, etc. could make it untrackable.
This is more like "why don't my colors look the same after converting to CMYK" -- there is a certain minimal level of knowledge needed to work with the tools. We've documented the process, but we can't force everyone to appreciate all the consequences of their actions.
Thanks to all for the replies to the original topic.
Chris, thanks - after I discovered this behaviour in CS3 and CS4 on Mac or PC I had the feeling that it was then a design limitation rather than a bug, you wrote:
> This is more like "why don't my colors look the same after converting to CMYK" -- there is a certain minimal level of knowledge needed to work with the tools. We've documented the process, but we can't force everyone to appreciate all the consequences of their actions. <<br />
I have looked for any documentation and or mention of this behaviour, yet I can't find it. Please point out the user help guide reference, online help reference and knowledge base link/s (which I have searched for without luck).
The first documentation that I saw was when I posted this topic and I get the impression that others are in the same position as this is news to them too (are we all missing the obvious bold 72pt text?).
I have not been on the pre-release team since CS, I would like to think that I would have raised this issue particular earlier if I was still involved in the pre-release testing (who should I contact to get back on the list?).
For me personally, it's usually enough just knowing and remembering what the behavior is, as I'm constantly working in multiple color spaces, assigning false profiles and doing whatever is needed to make the image work. Unfortunately there is far too much confusion among even so called experts and anything that adds to that anywhere along the line only ends up causing me grief at some point or another. To be certain, there probably aren't alot of people doing what Stephen is here, but it's certainly good to know.