This content has been marked as final. Show 21 replies
just curious, so I have to ask, what are you gaining if you convert an 8 or 16 bit file to 32? you are just making up information that was not there originally.
Did you submit a bug report form to Adobe? If not, use The Contact link at the top of this page.
Ramon, I was not sure if this was indeed a bug or a design limitation, or is that "feature"? If the consensus is that this is indeed a bug or something that needs reporting, then I will do so.
Buko, I don't wish to derail this topic, you can contact me offlist if you wish go into your question.
Email communications would defeat the purpose of the forum, which is for everybody to benefit from all questions and answers, not just the original poster.
Topic drift is essential to the success of the forums.
Fair enough Ramón, I am am only here to note the issue "at the Mothership" for the good of all concerned.
It feels like being back in Photoshop 5, having to check what the document colour profile is and what the Photoshop colour setting is!
It is all in the OP (except the why, which does not matter - the "bug" is what matters). Hint second paragraph, last line.
Buko, it's the same reason you might take an 8 into 16 and perform a function like blur, to make use of the extended colour range on an operation or several, then return to 8.
There are gains to be made from jumping up and down the bit depths.
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?
Make your report because even though we have had a few extra engineers popping in since the release of CS4 the interaction here is mostly User to User.
Oh thanks for the explanation.
>Can anyone post a supporting argument for the current behavior (design or bug).
It is an unfortunate act of how screwed up things are.
This is not a bug - this is a forced requirement.
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 seems like there ought to be a way to automatically convert back to the original source profile instead of what happens to be loaded in Color Settings.
See how forced requirements turn into workflows for good reasons?
And another reason for the ozmosis color model. I get it and so will everyone if you just take the time.
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.
Peter - please define "original source profile"?
We can't use the 32 bit profile, and we can't track the entire history of your document.
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.
well if you want to work in ProPhotoRGB and go 32bit then you need to make sure that you are in the ProPhoto workspace to begin with.
Maybe someone in marketing would understand.
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.
>Unfortunately there is far too much confusion among even so called experts
I see it very clearly now.
Globalization as an option as the masses merge into sanity. Until then, I will sit back an watch Rome fall. Fitting actually if nothing is done.