Options

Mis tagged color spaces ARGB vs sRGB or Hey, am I in a pickle?

2»

Comments

  • Options
    BinaryFxBinaryFx Registered Users Posts: 707 Major grins
    edited March 5, 2010
    NeilL wrote:
    Just another point, Stephen. How can one set perceptual intent in a profile (do you mean a calibration color profile here, or color space?)?

    Neil

    Neil, as you are likely aware, when performing the conversion from one profile to another, the Colour Management Module offers the choice of rendering intent (perceptual, saturation, relative colorimetric and absolute colorimetric).

    When the profile is built, rendering intents are included in the profile.

    The CMM is "dumb", it does not ask the profile what intents are available and then only offer these intenets - it simply lets one select any of the four possible intents (whether or not it actually exists).

    EDIT: As the perceputal intent is a CLUT, it is generally found in output profiles (not input profiles, monitor or working space). There are of course exceptions, such as the previously mentioned "Photo Gamut RGB" working/editing space (Google it).


    Stephen Marsh

    http://members.ozemail.com.au/~binaryfx/
    http://prepression.blogspot.com/
  • Options
    BinaryFxBinaryFx Registered Users Posts: 707 Major grins
    edited March 5, 2010
    Richard wrote:
    Yeah, but they expect an sRGB file as input, as do many cheap desktop printers, my own included. So I don't understand what your point is here.

    This is "faux ICC colour management". It is colour management, the source state or colour (ICC profile) is assumed.

    The photo printer at SmugMug has it's own unique gamut, which is different to sRGB. Often these devices have two settings, I will name these "consumer" and "pro". Some photo labs only offer one workflow, while others offer both and charge a nominally higher rate for the "pro" workflow.

    The "consumer" setting is not profile aware and expects sRGB input, it then internally converts from sRGB to the ouptut profile, before the print is imaged. The gamut is clipped at sRGB early in the process, limiting what can be converted to the printer output profile. Additionally, the consumer setting may also offer some internal preprocessing "logic", where it attempts to increase tonal range and saturation (similar to JPEG processing in a camera in scene mode). The idea being is to create contrasty, saturated pics that "mom & pop" will be happy with and less likely to complain about (as we all know it must be the equipment and not the photographer at fualt).

    The "pro" setting is ICC profile aware and likely uses perceptual rendering from any profiled input "direct" to the output profile, making use of the perceptual CLUT. Automatic image processing features are also likely to be turned off. As the "pro" workflow does not clip the colour to sRGB - if the scene contains wider gamut colour then this may (or may not) survive gamut compression when converted into the output profile.

    If the photo lab can provide an output profile to the customer, they can softproof the "pro" workflow - otherwise they will be flying blind. Without softproofing or conversion to an output space, it is not possible to see the effects of the wider gamut, as the monitor is clipping these colours/tones. What you see on the monitor is not what you get when printing.

    If the lab does not offer an output profile for softproofing, then one may indeed be better off duping the wider gamut source file and converting the dupe to sRGB. This sRGB file can then be tweaked to retain detail in saturated areas (if they exist). One can also control the "separation" and "gradation" of tone and hue in this smaller space. As the working space is close to many monitors, there is no surprise, what you see on the monitor is close to what you get when printing.

    EDIT: Richard, if you measured and created a custom printer profile for your cheap home printer/ink/stock combo, and converted a wider gamut original to this printer profile - you may see a difference in gamut or detail when compared to the "assumed sRGB" workflow.


    Stephen Marsh

    http://members.ozemail.com.au/~binaryfx/
    http://prepression.blogspot.com/
  • Options
    BinaryFxBinaryFx Registered Users Posts: 707 Major grins
    edited March 5, 2010
    NeilL wrote:
    Yes, of course working space is independent of output space, but the worrying area for me is the transition between the two.

    One could argue that if the working space is independent of the output, then there is no need to be concerned if you have some images in Adobe RGB and some in sRGB (if one are correctly using ICC colour management). It is not as if we are using Photoshop v5, since v6 one can have multiple images open at the same time in many different spaces than what the working space is set to.

    One issue is that many think that sRGB is an "output space", when it is usually being used as an "assumed source" or a "substitute" for being ICC profile aware.

    As noted during this thread on a few occasions, one can render as Relative Colorimetric, or if the table exists, perceptual.

    Independently of these intents, one can perform post conversion editing tricks to build separation of tone or hue and or add detail where it has been "clipped" or "compressed".

    My philosophy has always been to keep them the same, ie sRGB. But maybe there is some confusion in my thinking, so let me ask: if an image is in ProPhotoRGB on my HDD and I show it on my sRGB display, does a conversion of the color space data take place (from ProPhotoRGB to sRGB) to accomplish that, equal to an on-purpose conversion of the file from ProPhotRGB to sRGB color space in PS?

    As I said before, I really want to avoid exchanging color space currencies under any circumstances if at all possible.

    Neil


    Neil, I am not sure if I fully understand the question, however the ProPhoto image would be converted on the fly to your *monitor profile* (which may or may not be sRGB). This may not use exactly the same math as a conversion using the convert to profile command, however they should be no different to the naked eye.

    This is not a "hard" conversion, it is display conversion, the original file's RGB numbers do not change.


    Stephen Marsh

    http://members.ozemail.com.au/~binaryfx/
    http://prepression.blogspot.com/
  • Options
    NeilLNeilL Registered Users Posts: 4,201 Major grins
    edited March 6, 2010
    BinaryFx wrote:
    One could argue that if the working space is independent of the output, then there is no need to be concerned if you have some images in Adobe RGB and some in sRGB (if one are correctly using ICC colour management). It is not as if we are using Photoshop v5, since v6 one can have multiple images open at the same time in many different spaces than what the working space is set to.

    One issue is that many think that sRGB is an "output space", when it is usually being used as an "assumed source" or a "substitute" for being ICC profile aware.

    As noted during this thread on a few occasions, one can render as Relative Colorimetric, or if the table exists, perceptual.

    Independently of these intents, one can perform post conversion editing tricks to build separation of tone or hue and or add detail where it has been "clipped" or "compressed".





    Neil, I am not sure if I fully understand the question, however the ProPhoto image would be converted on the fly to your *monitor profile* (which may or may not be sRGB). This may not use exactly the same math as a conversion using the convert to profile command, however they should be no different to the naked eye.

    This is not a "hard" conversion, it is display conversion, the original file's RGB numbers do not change.


    Stephen Marsh

    http://members.ozemail.com.au/~binaryfx/
    http://prepression.blogspot.com/

    Stephen, thanks very much for this reply and the previous one above. I understand what you are saying. You have answered my concerns about the use of a non-sRGB image by outputs using a sRGB color space.

    The bottom line seems to be it is best to edit in a wide color space and then choose where possible output media that allows rendering using relative colorimetric or perceptual tables.

    You have piqued my curiosity by your reference to "post conversion editing tricks to build separation of tone or hue and or add detail". Can you briefly indicate what kind of thing you had in mind here.

    Neil
    "Snow. Ice. Slow!" "Half-winter. Half-moon. Half-asleep!"

    http://www.behance.net/brosepix
  • Options
    RichardRichard Administrators, Vanilla Admin Posts: 19,931 moderator
    edited March 6, 2010
    pathfinder wrote:
    That is true, yet the image I will finally see will not be in ProPhoto, but will be an 8 bit file in AdobeRGB or sRGB. My monitor can only really display sRGB, so why bother with 16 bits at all.

    Hmmm...I may be even dumber than I thought about this stuff. Are you saying that if I use sRGB as a working space while editing, I am actually working in 8 bits, even though ACR and PS say the image is in 16 bit mode? I remember working in 8 bits when I had a computer that was too wimpy to work in 16 without taking forever to do stuff, but it is a moot point on any recent machine. I must say, I never detected a visible difference, but that's all irrelevant to me now. Or is it? headscratch.gif
  • Options
    pathfinderpathfinder Super Moderators Posts: 14,698 moderator
    edited March 6, 2010
    Richard,

    After opening a RAW file in ACR and doing my initial edits I then open/transfer the file to CS4 as a 16 bit ProPhoto format file. If I then simply convert the file from ProPhoto to sRGB with Edit>Convert to Profile, I do indeed see an sRGB file that Image>Mode says is still 16 bits.

    But if I try to SAVE that file, I am not allowed to save it as a jpg; the only file types offered in the drop down box are Photoshop, Genuine Fractals 6.0, Cineon, FXG, IFF Format, Large Document format, Photoshop PDF, Photoshop RAW, PNG, Portable bit map, or TIFF - No jpg or jpg2000 or even pcx or gif. So maybe you can edit in 16bit sRGB, but you cannot save the file that way. So I am not sure if you are really even editing an actual 16 bit jpg sRGB file.

    Maybe Andrew can answer this question.

    I avoid this issue by not down converting until I want to save the file, or I cannot do the editing in 16 bit mode, since computer power is no longer limiting in this regard, but there are some commands CS4 does not yet perform in 16 bit.

    I save my intermediate tiffs in 16 bits, but my final files for smugmug are 8 bit sRGB files.

    As Andrew says, the beauty of Lightroom is that the file is always in 16bit ProPhoto from RAW to finished file, unless/until you export it to a different file format. When you print from within Lightroom, you can print from a 16 bit Pro Photo space if you have not exported the file for external editing. You will only be limited by the gamut of your printer, and your chosen rendering intent. That is why there is such a desire to be able to do soft proofing within Lightroom, not PS. I have not heard if soft proofing is made available in LR3 yet, does anyone know the answer to this yet?
    Pathfinder - www.pathfinder.smugmug.com

    Moderator of the Technique Forum and Finishing School on Dgrin
  • Options
    arodneyarodney Registered Users Posts: 2,005 Major grins
    edited March 6, 2010
    pathfinder wrote:
    But if I try to SAVE that file, I am not allowed to save it as a jpg

    JPEG doesn’t support 16-bit so you have to drop that down to 8-bit first. Same with Save for Web in the current version of Photoshop. You’d think it would be smart enough to know you want a JPEG and convert to 8-bit as part of the process. Another reason why Lightroom is in so many areas, superior to Photoshop in terms of ease of use and workflow.
    Andrew Rodney
    Author "Color Management for Photographers"
    http://www.digitaldog.net/
  • Options
    BinaryFxBinaryFx Registered Users Posts: 707 Major grins
    edited March 6, 2010
    NeilL wrote:
    You have answered my concerns about the use of a non-sRGB image by outputs using a sRGB color space.

    Glad to be of help Neil. As long as everybody in the production chain is using colour management correctly, there should not be a problem with different source spaces, as long as they are all converted to the correct ouput/delivery space.

    The bottom line seems to be it is best to edit in a wide color space and then choose where possible output media that allows rendering using relative colorimetric or perceptual tables.

    One of two possible workflows that most people use.

    Most agree that it is good to capture and archive a master copy in the original capture space (raw) or if shooting direct into JPEG to use Adobe RGB or a wider gamut space if offered in-camera. This provides future flexibility.

    Some will work in the widest colour space*, then convert this to the final destination right at the end of their workflow. Using simple matrix based ICC profiles, out of gamut colours will be clipped if rendering with Relative Colorimetric intent. If the destination profile offers a perceptual table, one can compress these OoG colours, rather than clip. They can then choose to "tweak" the final conversion to make up for any losses in the conversion.

    * Widest space may be a choice of one that suits the image/edits such as Adobe RGB, or a much wider gamut such as ProPhoto RGB. There are of course pros/cons to selecting a small or wide gamut space - there is no perfect RGB editing space.

    Some may work on the wider gamut file and use softproofing to see what happens during a conversion to the final space. They then use adjustment layers or other layers targeted to this softproof condition. This way they can have various layer set groups targeted to different softproofed output conditions in the one wide gamut master file.

    Others may elect to work on a copy of the archive file, and convert to the known and intended output space right away, making all edits specific to that space, knowing that this may be less flexible if output changes but also knowing that there will be no surprises as they are working in the "final" colour space (sRGB is often not the final space, there is commonly one more conversion from sRGB to the native printer space and the native printer space is often not available, which is why sRGB is often used as a "delivery" space for output).

    You have piqued my curiosity by your reference to "post conversion editing tricks to build separation of tone or hue and or add detail". Can you briefly indicate what kind of thing you had in mind here.Neil

    It will depend on the individual image and output. That being said, two common methods are with channel blends. This could involve using the separate R, G or B channels of various RGB spaces or it could involve the separate Lab channel modes as the source for the blend. Commonly the apply image command is used to blend the source into the target. The target may be a single channel or the composite, often in a duped layer to allow the layer blending mode to be changed independently of the apply image blending mode. Blending modes are commonly normal, luminosity or the various "contrast" or "light" blending modes (overlay, soft light, hard light etc).


    Stephen Marsh

    http://members.ozemail.com.au/~binaryfx/
    http://prepression.blogspot.com/
  • Options
    NeilLNeilL Registered Users Posts: 4,201 Major grins
    edited March 8, 2010
    BinaryFx wrote:
    Glad to be of help Neil. As long as everybody in the production chain is using colour management correctly, there should not be a problem with different source spaces, as long as they are all converted to the correct ouput/delivery space.




    One of two possible workflows that most people use.

    Most agree that it is good to capture and archive a master copy in the original capture space (raw) or if shooting direct into JPEG to use Adobe RGB or a wider gamut space if offered in-camera. This provides future flexibility.

    Some will work in the widest colour space*, then convert this to the final destination right at the end of their workflow. Using simple matrix based ICC profiles, out of gamut colours will be clipped if rendering with Relative Colorimetric intent. If the destination profile offers a perceptual table, one can compress these OoG colours, rather than clip. They can then choose to "tweak" the final conversion to make up for any losses in the conversion.

    * Widest space may be a choice of one that suits the image/edits such as Adobe RGB, or a much wider gamut such as ProPhoto RGB. There are of course pros/cons to selecting a small or wide gamut space - there is no perfect RGB editing space.

    Some may work on the wider gamut file and use softproofing to see what happens during a conversion to the final space. They then use adjustment layers or other layers targeted to this softproof condition. This way they can have various layer set groups targeted to different softproofed output conditions in the one wide gamut master file.

    Others may elect to work on a copy of the archive file, and convert to the known and intended output space right away, making all edits specific to that space, knowing that this may be less flexible if output changes but also knowing that there will be no surprises as they are working in the "final" colour space (sRGB is often not the final space, there is commonly one more conversion from sRGB to the native printer space and the native printer space is often not available, which is why sRGB is often used as a "delivery" space for output).




    It will depend on the individual image and output. That being said, two common methods are with channel blends. This could involve using the separate R, G or B channels of various RGB spaces or it could involve the separate Lab channel modes as the source for the blend. Commonly the apply image command is used to blend the source into the target. The target may be a single channel or the composite, often in a duped layer to allow the layer blending mode to be changed independently of the apply image blending mode. Blending modes are commonly normal, luminosity or the various "contrast" or "light" blending modes (overlay, soft light, hard light etc).


    Stephen Marsh

    http://members.ozemail.com.au/~binaryfx/
    http://prepression.blogspot.com/

    Just got back to this, Stephen. Excellent information which helps me to clarify for myself what I am doing and why.

    Thank you.

    Neil
    "Snow. Ice. Slow!" "Half-winter. Half-moon. Half-asleep!"

    http://www.behance.net/brosepix
Sign In or Register to comment.