DPP 4 exports in sRGB (only)?

Mark Vuleta wrote in post #17983934
You need to be a bit careful believing everything you read or watch on the internet. The above statement is not correct and/or misleading in many respects & appears to be extracted from Epson's literature.

It is pointless working in a colourspace that greatly exceeds the colour gamut of the scene captured. It limits the graduations available. There are a relatively few colour ranges that exist in nature that exceed sRGB. Please Note I said relatively few, of course there are but these are handled fairly well by rendering intents. There are exceptions of course, some flora colours, some rare deep blues etc.

Pro photo RGB also exceeds the visible spectrum by about 10%, good luck seeing those. In fact, good luck seeing anything on screen or print that gets anywhere near the most saturated greens of Pro Photo RGB.

It was a direct quote from Epson literature and literally the first or second thing that came up when I did a search. I agree about not believing everything I see or read on the internet. However, i do believe in the real world differences I see with my own eyes when doing side by side comparisons. I really don't think there is anything misleading about that particular statement, but I'm no pro so I could be wrong. I do know that often just a soft proof from Adobe RGB to sRGB shows changes I'm not fond of in most of my images. it often tames them, especially in the greens and blues. Maybe your experiences differ? In the image from the gentleman who did the video I referenced above the difference in the blue and greens was quite obvious after converting to the smaller gamut of sRGB and I am talking about the differences on an actual print from my printer not a soft proof or some images optimized for web display).

As for Pro Photo, to be honest that is a new term for me. I'm still stuck in the Adobe RGB world as I have been out of the game (or maybe not deep enough into to begin with). My intention however is to retain the data I have (Adobe RGB). I'm not trying and create more by converting to a larger gamut (Pro Photo RGB). If my camera can record Adobe RGB, I see no reason to try and upscale it to a wider gamut for the sake of a wider gamut. However, I see no reason to immediately discard information it may (or may not) have gathered by immediately converting to the smaller gamut of sRGB either. if and when camera capture Pro Photo I'll be into it, until then I'll stick with what they can capture .

Now if I am going to the web, sure I'll optimize it for that (sRGB). However I'm conversing about optimizing for print on a device that is near (I think) to Adobe RGB. the suggestion about it being handled "relatively well by rendering intents" is interesting. I'd rather use data I have then throw it away only to have software re-render it "relatively well". Alas maybe I don't understand that process very well. Maybe this is the extent of pixel peeping in some regards but really I'm not so sure it is. I know without doubt that converting a very colorful image to sRGB lowered the intensity of the blues. Would I have known if I just saw one print or the other in isolation? Probably not. However, it was quite obvious how much more saturated and dense the colors looked when using the wider color gamut. It might just be these subtle differences that people can't quite put there finger on that makes an image go from "nice" to "WOW", but that's just my opinion.

As for outsourcing, I think someone asked about. The one and only lab I've ever used accepts sRGB or Adobe RGB. They will color manage for you or accept a file from you keeping the color space you have (assuming it's sRGB or Adobe RGB) and then apply "no color management". they even allow a few free 8x10's from free to help you dial in your profile for their work.

IPTAK wrote in post #17983973
........ I really don't think there is anything misleading about that particular statement...........

Plenty misleading/incorrect stuff in the statement.

.........often just a soft proof from Adobe RGB to sRGB shows changes I'm not fond of in most of my images. it often tames them, especially in the greens and blues........

There should be very little difference in the blues between the two, the gamuts in this area are very close, perhaps your conversion process is odd. I did notice in an earlier screen capture Preferences/Colour Management that your using the OS colour space for the display. In a colour managed programe, the OS colour space can be different to the monitor profile. This could be causing a double profile issue.

In the image from the gentleman who did the video I referenced above the difference in the blue and greens was quite obvious after converting to the smaller gamut of sRGB and I am talking about the differences on an actual print from my printer not a soft proof or some images optimized for web display).

As for Pro Photo, to be honest that is a new term for me. I'm still stuck in the Adobe RGB world as I have been out of the game (or maybe not deep enough into to begin with). My intention however is to retain the data I have (Adobe RGB). I'm not trying and create more by converting to a larger gamut (Pro Photo RGB). If my camera can record Adobe RGB, I see no reason to try and upscale it to a wider gamut for the sake of a wider gamut. However, I see no reason to immediately discard information it may (or may not) have gathered by immediately converting to the smaller gamut of sRGB either. if and when camera capture Pro Photo I'll be into it, until then I'll stick with what they can capture .

You stated that you are shooting raw which does not have a colour space, the image sensor is capable of the full gamut of visible light more or less. sRGB or aRGB or any other colour space only come into it upon conversion to a visible image

Now if I am going to the web, sure I'll optimize it for that (sRGB). However I'm conversing about optimizing for print on a device that is near (I think) to Adobe RGB. the suggestion about it being handled "relatively well by rendering intents" is interesting. I'd rather use data I have then throw it away only to have software re-render it "relatively well". Alas maybe I don't understand that process very well. Maybe this is the extent of pixel peeping in some regards but really I'm not so sure it is. I know without doubt that converting a very colorful image to sRGB lowered the intensity of the blues. Would I have known if I just saw one print or the other in isolation? Probably not. However, it was quite obvious how much more saturated and dense the colors looked when using the wider color gamut. It might just be these subtle differences that people can't quite put there finger on that makes an image go from "nice" to "WOW", but that's just my opinion.

As for outsourcing, I think someone asked about. The one and only lab I've ever used accepts sRGB or Adobe RGB. They will color manage for you or accept a file from you keeping the color space you have (assuming it's sRGB or Adobe RGB) and then apply "no color management". they even allow a few free 8x10's from free to help you dial in your profile for their work.

Of course they are colour manageing to some extent, ask them for a profile and compare the gamut. I would image the "no color management" they are describing is in "brightness" as a lot of uncalibrated monitors are far too bright and prints come out dark. You would only ask them not to adjust your file if you gave them the file format and colour profile that they asked for and you had a colour managed system so that you knew your image is going to be printed too dark.

Finally, what type of photo's are you taking? On the screen print mentioned earlier, it appears to be a nature type of scene. Probably nothing out of sRGB in a bush scene under a canopy. Your image does appear to have a heavy green cast to it. White balance makes a difference as well.

Mark Vuleta wrote in post #17983934
You need to be a bit careful believing everything you read or watch on the internet. The above statement is not correct and/or misleading in many respects & appears to be extracted from Epson's literature.

It is pointless working in a colourspace that greatly exceeds the colour gamut of the scene captured. It limits the graduations available. There are a relatively few colour ranges that exist in nature that exceed sRGB. Please Note I said relatively few, of course there are but these are handled fairly well by rendering intents. There are exceptions of course, some flora colours, some rare deep blues etc.

Pro photo RGB also exceeds the visible spectrum by about 10%, good luck seeing those. In fact, good luck seeing anything on screen or print that gets anywhere near the most saturated greens of Pro Photo RGB.

I fully agree.

Two conditions must be met for saving an image to a color space wider than sRGB to make sense:

First, the image must also contain colors that are beyond the sRGB gamut. If it doesn't, you'd only be getting fewer color shades in your image (at any given bit depth) for absolutely no gain at all.

Second, the image is going to be displayed/printed on devices that are capable of rendering those exceeding colors faithfully - or, alternatively - you are planning to selectivelly pull the out of gamut areas into the target gamut, in order to do a better job than a direct save to sRGB could have accomplished.

We must keep in mind that "big name" color spaces do not supply "nicer" or "better" colors than the modest, smaller spaces at all. The color of each pixel is determined by the sensor and the raw converter, while the color space only provides the standardized code for that color to be written to file and unambiguously recognized by any destination software/device.

All the benefit of large color spaces is, that they also supply color codes for highly saturated colors, while the sRGB working space doesn't and therefore has to "cheat" on color fidelity if it's faced with the need to encode one of those.

That's because sRGB dedicates all the codes to the range of everyday colors, thus providing finer color resolution (i.e. finer shading) within the most used color range.

Bottom line: By using a wider color space than the image content requires, we are making available a set of color codes (those assigned to very saturated colors) which the image has no use for - for the price of reducing the number of hues available within the gamut region that the image is actually drawing upon. Or for the price of introducing 16-bit color depth with its own downside. Maybe both.

sRGB is not a color space meant to replicate the "range of everyday colors" - it is a color space that was designed for the capability and standardization of CRT displays in the 1990s. It has become the de facto lowest common denominator for display on the web and mobile devices. Research into the gamut of the reflectance of everyday surfaces has demonstrated the ongoing "need" for a color space that strikes a balance between an expanded color gamut that gives one an optimized space for containing all of these wonderful colors that are captured by devices like cameras with raw capture, and the capability and output devices and the intermediary steps of image processing prior to final output. Google "pointer's gamut" or BetaRGB for examples.

sRGB is a good target for your final image if it is meant to be displayed on the internet or on mobile devices in 8bit. It is not necessarily a very good candidate for conversion from a raw file if you intend to perform image processing or print to an inkjet printer, where raw image data may undergo unnecessary clipping during conversion into sRGB from the raw file (like shooting JPEG - oh the horror!) prior to final output. Most RGB inkjet printers can print colors that are outside of the sRGB color gamut, and raw files definitely capture and produce colors that will get clipped if one converts directly from the raw file into sRGB without some supervision during conversion. Rendering intent is a tool to help decide how to remap colors from a larger color space into a smaller color space; however, you have no choice in the matter when converting into sRGB, as conversion into it only supports a single rendering intent (perceptual).

Your workflow and your final image destination will determine, ultimately, the color space into which you will want to convert during raw file conversion (i.e. ,your "working" color space). If you have no intention of performing image processing or printing on an inkjet printer, and you simply want to convert your raw file for display on the web, then converting directly into sRGB and exporting as an 8bit JPEG may be a perfectly acceptable branch of your workflow, where you can essentially shoot raw and squeeze more DR from your raw file (i.e., highlight recovery) than you would have if shooting JPEG.

When advice is given that sRGB is the optimal color space for conversion from a raw file into an RGB image file, it often assumes many things about the the image content, the user's workflow and the user's intent for the image. Simply advising that sRGB is the best path for the image without knowing something about the image content and the final output (which could include multiple output devices) is probably hasty, at best.

kirk

kirkt wrote in post #17984177
Rendering intent is a tool to help decide how to remap colors from a larger color space into a smaller color space; however, you have no choice in the matter when converting into sRGB, as conversion into it only supports a single rendering intent (perceptual).

I suppose you meant Relative Colorimetric, i.e. the intent that clips the outliers.

yes - rel col, not perceptual when converting TO sRGB. Sorry about that. Rel Col will remap the outlying colors to the sRGB gamut boundary without changing the relation of the colors within the destination gamut.

kirk

kirkt wrote in post #17984177
sRGB is not a color space meant to replicate the "range of everyday colors" - it is a color space that was designed for the capability and standardization of CRT displays in the 1990s.

sRGB is a good target for your final image if it is meant to be displayed on the internet or on mobile devices in 8bit. It is not necessarily a very good candidate for conversion from a raw file if you intend to perform image processing or print to an inkjet printer, where raw image data may undergo unnecessary clipping during conversion into sRGB from the raw file (like shooting JPEG - oh the horror!) prior to final output. Most RGB inkjet printers can print colors that are outside of the sRGB color gamut, and raw files definitely capture and produce colors that will get clipped if one converts directly from the raw file into sRGB without some supervision during conversion. Rendering colorimetric is a tool to help decide how to remap colors from a larger color space into a smaller color space; however, you have no choice in the matter when converting into sRGB, as conversion into it only supports a single rendering intent (perceptual).

Your workflow and your final image destination will determine, ultimately, the color space into which you will want to convert during raw file conversion (i.e. ,your "working" color space).

When advice is given that sRGB is the optimal color space for conversion from a raw file into an RGB image file, it often assumes many things about the the image content, the user's workflow and the user's intent for the image. Simply advising that sRGB is the best path for the image without knowing something about the image content and the final output (which could include multiple output devices) is probably hasty, at best.

kirk

I think this is what I was trying to say.... - thanks Kirk.

Oh, and the woods picture (there's actually an owl in but it was under the dialog box) was just a random photo I used to test the exporting from DPP. I purposely skewed the color balance to distinguish it from other versions. I agree that with an image like that with the relatively muted colors sRGB would be fine. However, with an image of some Mexican Pottery or colorful blankets I think sRGB would throw away a lot of useful color.

This conversation did make me think though (and that's always a good thing). If I understand what you guys are saying, you're suggesting that by using a wider color space then needed you affect the transitions from shade to shade of color maybe in a negative way. How then do you decide the optimal color space to use (without randomly assigning sRGB because it works 95% of the time)? My guess is soft proofing, but I'm here to learn, so, how do you that actually evaluate for this go about it?

Mark Vuleta wrote in post #17984037
You would only ask them not to adjust your file if you gave them the file format and colour profile that they asked for and you had a colour managed system so that you knew your image is going to be printed too dark.

Yes, I am working toward a fully color managed workflow with calibration up to and including profiles for specific printers and papers. Thus my comment regarding if someone asked me for sRGB I'd move on. My intention is that I am standardized to my printer and or ones I outsource too. I intend to have full calibration and know how to use it so I know exactly what the print will look like no matter where it goes .

IPTAK wrote in post #17984652
Oh, and the woods picture (there's actually an owl in but it was under the dialog box) was just a random photo I used to test the exporting from DPP. I purposely skewed the color balance to distinguish it from other versions. I agree that with an image like that with the relatively muted colors sRGB would be fine. However, with an image of some Mexican Pottery or colorful blankets I think sRGB would throw away a lot of useful color.

This conversation did make me think though (and that's always a good thing). If I understand what you guys are saying, you're suggesting that by using a wider color space then needed you affect the transitions from shade to shade of color maybe in a negative way. How then do you decide the optimal color space to use (without randomly assigning sRGB because it works 95% of the time)? My guess is soft proofing, but I'm here to learn, so, how do you that actually evaluate for this go about it?

If an image contains colors beyond sRGB, then saving it to a wider CS certainly does make sense. If you have the means to render those colors faithfully (on the monitor or printer), that's great. Even if you can't render them, you will have the option to pull the problem colors down to the destination device's gamut in a way that will give you better results than directly saving to sRGB. So, in such a case, using a wider CS for the first save (out from DPP) is no question.

In DPP, when I suspect the presence of colors beyond sRGB (my default CS), I inspect the histogram under the RGB tab. If I see clippings, I try switching to AdobeRGB and Wide Gamut RGB (Adjustment > Work color space). If the clippings aren't due to overexposure but actually due to out of gamut colors, they will disappear when a large enough CS is selected. That's the indication which size CS the image needs to have all the colors encoded correctly.

It turns out that the majority of my captures fit into sRGB. On these, sRGB gives me absolute color fidelity and full color resolution without resorting to the 16-bit depth that a larger CS would have called for. Many people don't mind, but to me 16 bits mean more storage space, slower processing, incompatibility with some apps that I own and value and the need to convert (and do it properly!) to obtain the eventually needed sRGB version. So I'm happy when I can avoid all this hassle with no loss to image quality/color fidelity.

agedbriar wrote in post #17984751
If an image contains colors beyond sRGB, then saving it to a wider CS certainly does make sense. If you have the means to render those colors faithfully (on the monitor or printer), that's great. Even if you can't render them, you will have the option to pull the problem colors down to the destination device's gamut in a way that will give you better results than directly saving to sRGB. So, in such a case, using a wider CS for the first save (out from DPP) is no question.

Yes, yes, and yes

agedbriar wrote in post #17984751
In DPP, when I suspect the presence of colors beyond sRGB (my default CS), I inspect the histogram under the RGB tab. If I see clippings, I try switching to AdobeRGB and Wide Gamut RGB (Adjustment > Work color space). If the clippings aren't due to overexposure but actually due to out of gamut colors, they will disappear when a large enough CS is selected. That's the indication which size CS the image needs to have all the colors encoded correctly.

Perfect, I'll play with that, thanks.

So, have you answered your initial problem, which is how to transfer an image to PhotoShop and keep it in a "wider" color space (such as aRGB)?

Yes, . Apparently there are two ways. The way that worked for me was: Tools > Preferences > color management > and selecting Wide RGB/Use shooting settings. The part I missed that made it actually work was re-starting the program after choosing those settings! Apparently you can also go into: Adjustments > Work Color Space > Your choice of gamuts.

Thanks to those of you who got me there, and also everyone else for sharing their thoughts and understanding of color management.

Ah, I forgot to reply on the soft-proofing that you mentioned earlier.

Yes, that's what I use in the next step, when I need to control how much to desaturate some of the colors saved into Wide Gamut RGB (a TIFF file) to make them fit into my printer/paper gamut. I use PhotoLine as my pixel editor.

I too stick to DPP because I like its conversion quality, even if that means that I have to resort to the pixel editor more often.

And, welcome to POTN!