Skip navigation
Currently Being Moderated

Colour Profile Bug in CS4 32 bpc Mode?

Nov 17, 2008 6:50 PM

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.

Sincerely,

Stephen Marsh
 
Replies
  • Currently Being Moderated
    Nov 17, 2008 7:00 PM   in reply to Stephen_Marsh
    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.
     
    |
    Mark as:
  • Ramón G Castañeda
    11,247 posts
    Jul 27, 2006
    Currently Being Moderated
    Nov 17, 2008 7:49 PM   in reply to Stephen_Marsh
    Stephen,

    Did you submit a bug report form to Adobe? If not, use The Contact link at the top of this page.
     
    |
    Mark as:
  • Ramón G Castañeda
    11,247 posts
    Jul 27, 2006
    Currently Being Moderated
    Nov 17, 2008 9:07 PM   in reply to Stephen_Marsh
    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.
     
    |
    Mark as:
  • Currently Being Moderated
    Nov 18, 2008 3:42 AM   in reply to Stephen_Marsh
    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.
     
    |
    Mark as:
  • Currently Being Moderated
    Nov 18, 2008 5:40 AM   in reply to Stephen_Marsh
    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.
     
    |
    Mark as:
  • Currently Being Moderated
    Nov 18, 2008 8:18 AM   in reply to Stephen_Marsh
    >Can anyone post a supporting argument for the current behavior (design or bug).

    It is an unfortunate act of how screwed up things are.
     
    |
    Mark as:
  • Currently Being Moderated
    Nov 18, 2008 11:29 AM   in reply to Stephen_Marsh
    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.
     
    |
    Mark as:
  • Currently Being Moderated
    Nov 18, 2008 11:37 AM   in reply to Stephen_Marsh
    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.
     
    |
    Mark as:
  • Currently Being Moderated
    Nov 18, 2008 11:37 AM   in reply to Stephen_Marsh
    yep -

    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.
     
    |
    Mark as:
  • Currently Being Moderated
    Nov 18, 2008 11:43 AM   in reply to Stephen_Marsh
    Peter -

    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.
     
    |
    Mark as:
  • Currently Being Moderated
    Nov 18, 2008 11:51 AM   in reply to Stephen_Marsh
    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.
     
    |
    Mark as:
  • Currently Being Moderated
    Nov 18, 2008 12:12 PM   in reply to Stephen_Marsh
    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.
     
    |
    Mark as:
  • Currently Being Moderated
    Nov 18, 2008 1:09 PM   in reply to Stephen_Marsh
    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.
     
    |
    Mark as:
  • Currently Being Moderated
    Nov 18, 2008 3:15 PM   in reply to Stephen_Marsh
    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.
     
    |
    Mark as:
  • Currently Being Moderated
    Nov 18, 2008 3:22 PM   in reply to Stephen_Marsh
    Maybe someone in marketing would understand.
     
    |
    Mark as:
  • Currently Being Moderated
    Nov 18, 2008 6:12 PM   in reply to Stephen_Marsh
    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.
     
    |
    Mark as:
  • Currently Being Moderated
    Nov 18, 2008 8:04 PM   in reply to Stephen_Marsh
    >Unfortunately there is far too much confusion among even so called experts

    yep.

    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.
     
    |
    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)