Color Space Conversion but out of gamut color shift

[geo_lam]

<p>Link is:<br>

<a href="http://static.photo.net/attachments/bboard/00X/00XvTI-315071584.tif">http://static.photo.net/attachments/bboard/00X/00XvTI-315071584.tif</a></p>

[digitaldog]

<p>The link takes me to a web page with the image (some blue sky) but what color space is this in? What I’d really like is the TIFF with an embedded profile, is that what you’ve uploaded?</p>

[geo_lam]

<p>Hi Andrew,<br />Yes.<br />I cropped the photo with just the affected background (colour shift after conversion to sRGB) which is the blue background. The file is in ProPhoto profile.</p>

[digitaldog]

<p>It did come down in ProPhoto, good. <br>

When I use Convert to Profile and select sRGB, I see no visual difference at all. </p>

[geo_lam]

<p>That is strange. I did see the blue shifted to lighter color and some purple appears.<br>

I am using PhotoShop convert to function, with perceptual/Relative colorimetric. MOnitor is a very old Eizo with default sRGB mode.</p>

[Tim_Lookingbill]

<p>I get a shift on my 2004 G5 iMac running OS 10.4.11 and calibrated with EyeOne Display. See below the screenshot that's kept in my monitor's space because converting to sRGB would cancel out the difference so view that screenshot in a color managed app/browser.</p>

<p>It's probably a gamut issue with the display with mine being close to sRGB since Andrew who I'm assuming is using a wide gamut display says he doesn't get a shift.</p>

<p>BTW convert to your display profile and see if you get a shift. I don't get a shift.</p><div></div>

[Tim_Lookingbill]

<p>Conclusion:</p>

<p>Display gamut when even close to sRGB can clearly render that ProPhotoRGB blue,<br>

but sRGB 2.1 can't.</p>

<p>Anyone have a better explanation, please divulge.</p>

[digitaldog]

<p>Yes. In my case, I’m using an NEC 3090 wide gamut display. I see no color shifts. If there are differences, its visually insignificant. When I originally heard about the shift, I ought it was the old blue to magenta hue shift (which could still result going to the output profile). But based on what I’m seeing here, the ProPhoto to sRGB conversion isn’t worth a worry IMHO. </p>

[howard_owen]

<p>If you look at the histogram, the Red channel takes a hit during the conversion. It's forced into clipping in the shadows and is suppressed to near nothing where it's not clipped. For example, before conversion, I get a level of R=41 when sampling in the midtone (~128) blue area. After conversion, Red becomes R=0 at the same point. The Blue channel gains about 30 points in the midtones as well.</p>

<p>Having said all that, the change on the monitor is minimal, but it is there. (NEC P221W)</p>

[Tim_Lookingbill]

 

<blockquote>

<p>But based on what I’m seeing here, the ProPhoto to sRGB conversion isn’t worth a worry IMHO.</p>

 

</blockquote>

<p>And to add to that, there isn't a printer in the world with dye or pigment formulation that can reproduce that ProPhotoRGB blue that accurately anyway without having to resort to a toxic metal based ink formulation.</p>

<p>And according to Howard's Red=0 there's no telling how far that causes the math under the hood to find bottom mapping the rest of the color relationships for that particular hue/saturation appearance. This is probably why this shift varies in different degrees according to the level of hue/sat chosen based on my own observations converting other similar colors from ProPhotoRGB to sRGB.</p>

<p> </p>

[digitaldog]

<blockquote>

<p>And to add to that, there isn't a printer in the world with dye or pigment formulation that can reproduce that ProPhotoRGB blue that accurately anyway without having to resort to a toxic metal based ink formulation.</p>

</blockquote>

<p>And there never will be, at least until we evolve into one of those Arthur C. Clark super babies and our vision exceeds today limitations of which two primaries defined in ProPhoto exceed <g>. They fall outside human vision (gamut). Such are the rules when synthetic RGB color spaces, based on match are created to be this large. </p>

[geo_lam]

<p>Thanks all.<br>

What is the remedy for this out of gamut? Lower the saturation in several layers (desaturate a layer of -10 at a time)? or Make adjustment in curve layer to lower the red channel?</p>

[howard_owen]

<p>If you're having the file printed locally, maybe you should try a test print to see if the result is pleasing to you (and note that pleasing and accurate are not always the same thing). Those of us who have to shoehorn RGB images into the CMYK color space learned to live with "pleasing" a long time ago. :)</p>

<p>If you decide to correct with Curves, I'd do a global adjustment at the top of the layer stack and use a layer mask to shield areas that you don't want affected.</p>

[Tim_Lookingbill]

<p>

 

 

<blockquote>

<p >What is the remedy for this out of gamut? Lower the saturation in several layers (desaturate a layer of -10 at a time)? or Make adjustment in curve layer to lower the red channel?</p>

<p > </p>

</blockquote>

<p >Edit with Soft Proof on with the printer's profile loaded on a copy of the background. Start out using Hue/Saturation tool and stay in 16 bit ProPhotoRGB. Tweak with curves the areas that might band/posterize if needed.</p>

<p > </p>

<p >Some printers printing to glossy paper can come close to one particular hue of blue that is close to what you want but kick up posterized banding transitioning into another blue that's close to it like in your gradient. Soft Proofing will usually show this bad transition. You can always do a test print first.</p>

<p > </p>

<p >I've been surprised by some printer's capability of reproducing gorgeous blues that I thought would clip to some dull, dark cyan or purple compared to the vibrant cobalt blue I saw on the display. The vibrant blue I got in print as Howard pointed out wouldn't be dead on accurate to the display but still looked vibrant. </p>

<br />

 

 

</p>

[mirek_elsner1]

<p>I downloaded the picture and converted it to sRGB on my MBP. The display shows the converted image with a very slight purple tint. The display is calibrated with ColorMunki.</p>

[gooseberry]

<blockquote>

<p>Francisco Disilvestro wrote:<br /><em>Besides reducing saturation or, even better, reduce vibrance before converting to sRGB, another option is to use a version 4 sRGB, which do allow for perceptual conversion. You can find the profile <a rel="nofollow" href="http://www.color.org/srgbprofiles.xalter" target="_blank">here</a></em></p>

</blockquote>

<p>The first paragraph of the linked article reads...</p>

<blockquote>

<p>The sRGB v4 ICC preference profile is a v4 replacement for commonly used v2 sRGB profiles. It gives better results in workflows that implement the ICC v4 specification. <strong>It is intended to be used in combination with <em>other ICC v4 profiles</em>.</strong></p>

</blockquote>

<p>...so the questions I'd like to ask, hoping someone would be able to clarify, are:</p>

<ul>

<li>what <em>other ICC v4 profiles</em> are they talking about? -- monitor, printer, ??? -- how do I check and what if those other ICC profiles aren't v4?</li>

<li>is there any possible downside of using sRGB v4 (as opposed to the "default" v2), e.g., when saving for web?</li>

<li>do ProPhoto and Adobe RGB come in v4 as well? -- it doesn't say</li>

</ul>

<p>Thanks!</p>

[digitaldog]

<p>Your best bet is to ignore V4 profiles for the time being, they are not ready for prime time. Even newer packages that make V4 profiles (i1Profiler for example) don’t fully support the V4 spec (there’s no PRMG support) so its a V2 profile in disguise. Without a full set (source to destination) fully implemented V4 profile, nothing is gained. And a number of applications have issues with V4 profiles depending on OS and print driver. </p>

[gooseberry]

<p>Much appreciated, Andrew!<br />In a sense, that's a good news because I'm off the hook without feeling guilty that there is something I should be doing, or the uncomfortable feeling that instead of improving things I might be actually getting them worse by neglecting the <em>if it ain't broken, don't fix it</em> "wisdom," which is what I've already done -- need to revert back to sRGB IEC61996-2.1<br /> ...or should I instead use one of the new v2 sRGB profiles? -- I've read the latter half of the ICC article on the sRGB profiles (quoted below) and the statement that <em>the 'black scaled' profile has the preferred rendering intent in the header set to 'perceptual'</em> confuses me as my understanding has been that <a href="00XRH7">v2 profiles don't support perceptual intent</a> (?)<br /> <br />I use Relative Colorimetric intent with Black Point Compression, so I gather the 'no black scaling' profile would be more appropriate for me because:<br /> (a) it has the preferred rendering intent in the header set to 'relative colorimetric'; and<br /> (b) it can be used with BPC 'on' or 'off' in the CMM, and if it is used with BPC 'on' the results should be the same as when using the 'black scaled' profile;<br /> however, I thought I'd better confirm my half-educated guess with someone in-the-know.</p>

<blockquote>

<p><strong>sRGB profiles: v2 profiles </strong>@ http://www.color.org/srgbprofiles.xalter<br /> <br />Two ICC version 2 (v2) sRGB profiles are provided, one with XYZ black point scaling to zero, and one without. The 'black scaled' profile has the preferred rendering intent in the header set to 'perceptual'. and the 'no black scaling' profile has the preferred rendering intent in the header set to 'relative colorimetric'.<br /> <br />Both profiles contain the standard linearized Bradford D65 to D50 chromatic adaptation tag (this tag was often not present in older sRGB profiles), and the media white point tag is set to D50 (as is required for ICC v4 profiles). This avoids the inappropriate color casts that older sRGB v2 ICC profiles sometimes produced when the absolute colorimetric intent was used.<br /> <br />The 'black scaled' profile will work correctly when either Black Point Compensation (BPC) is on in the CMM/application, or the other profile transform to be used for the conversion is also black scaled. Black scaled profiles are needed when BPC is desired for the conversion but the CMM to be used does not support BPC. Most v2 sRGB profiles in current use are black scaled because they are intended to be used as the source profile in conversions where the destination profile perceptual intent will be used (v2 perceptual transforms typically include black scaling).<br /> <br />The 'no black scaling' profile produces sRGB colorimetry in the PCS that is more accurate to what a viewer of a sRGB calibrated display will observe in the reference sRGB viewing conditions. This is the case when the display has been calibrated to include the viewer-observed black level such as one might achieve with a non-contact monitor calibrator or other means to include ambient effects. It should be used in situations where greater colorimetric accuracy is desired, e.g. as the destination profile for preview on calibrated sRGB displays where the viewer-observed black has been included. However it should be noted that most current LCD displays, even those that use the sRGB primaries and gamma, have a higher white point luminance and dynamic range than the sRGB reference display. To produce accurate preview colorimetry on these displays they should be accurately profiled, instead of using an sRGB profile.<br /> <br />The 'no black scaling' profile can be used with BPC on or off in the CMM. If it is used with BPC on the results should be the same as when using the 'black scaled' profile. If it is used with BPC off it will produce un-black-scaled media-relative colorimetry: if the source encoding has tones darker than the destination encoding black point they will be clipped, and if the source black point is higher than the destination black point the source black point will be accurately reproduced.</p>

</blockquote>

<p>Any suggestions?</p>

[digitaldog]

<p>V2 matrix profiles do not support a Perceptual intent (there’s no such table in them). You’d be getting a Relative Colorimetric intent. BPC is an option if the CMM supports it (ACE of course does).</p>

[gooseberry]

<p>That's what I though. Does it mean that you'd also agree with my inference that I should use <em>sRGB_IEC61966-2-1_<strong>no_black_scaling</strong>.icc</em> rather than the <em>sRGB_IEC61966-2-1_<strong>black_scaled</strong>.icc</em> profile?</p>

[digitaldog]

<p>If you use ACE, doesn’t matter as it supports BPC. You control if you want it or not via the BPC checkbox. That said, depending on the source space being mapped to sRGB, both options will provide an identical result. I always keep BPC on for all conversions. </p>

[gooseberry]

<p>Yep, have Adobe (ACE) selected in the 'Engine' drop-down box, and have the BPC checkbox ticked "permanently" (as well as "Use Dither" and "Compensate for Scene-referred Profiles"). <br />I do conversion to sRGB as the next to the last step, just before changing the bit-depth to 8, mostly from ProPhoto (output from ACR and my PS default Working Space), potentially from LAB (if I make a detour that way).<br>

<br />So, if I understand you correctly, you're saying it won't matter the least which of the two new profiles I pick, or perhaps even whether I stay with the one that came with my Mac, correct?</p>

[digitaldog]

<p>I don’t believe there’s any difference but its easy to test. Do the conversions with each, then use the process described here to examine the data:<br>

http://digitaldog.net/files/Apply_Image.pdf</p>