[argyllcms] Re: Custom Illuminant

  • From: Ben Goren <ben@xxxxxxxxxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Mon, 7 Jul 2014 17:19:35 -0700

There's another elephant in the room. Adobe's RAW development engine is 
optimized for "pleasing" color, not accurate color. And, indeed, accurate color 
isn't really an option with Adobe's RAW development engine; you can't, for 
example, do decent fine art reproduction / giclee work with it.

RawPhotoProcessor is the best I've found. It outputs directly to BetaRGB, or 
even to Lab.

As a practical matter, I've not run into gamut limitations with Beta RGB. It 
encompasses either all or almost all of my iPF8100's gamut, even on baryta 
papers. AdobeRGB, on the other hand, clips a bit on my best matte paper (Museo 
Portfolio Rag), and substantially on baryta papers. The only other space I 
output to is sRGB, which, of course, is fully encompassed by Beta RGB.

In your shoes, ProPhoto may well be the least evil option, but it'd be worth 
spending some time comparing gamut plots.


On Jul 7, 2014, at 5:01 PM, Robert@xxxxxxxxxxxxxxxxxx wrote:

> Thanks for your suggestions!  The main reason I use ProPhoto is that
> Lightroom only gives the options of sRGB, Adobe RGB or ProPhoto RGB to
> export to Photoshop. Also, Lightroom itself uses a variant of ProPhoto as
> its internal working space, so that there is no clipping when going from a
> raw image developed in Lightroom to ProPhoto in Photoshop.
> I can see that there would be an advantage in having a D50 white point
> (which ProPhoto RGB has). 
> Beta RGB has a 2.2 gamma, eciRGB an L* curve and ProPhoto has a gamma of
> 1.8. I don't understand the pros and cons. Bruce Lindbloom says regarding
> gamma: "it is an important consideration for controlling quantization" and
> his conclusion is that a gamma of 2.2 is nearly optimal. 
> And, finally and perhaps more importantly, as I am constrained to (sRGB,
> AdobeRGB or) ProPhotoRGB when going from Lightroom to Photoshop ... would an
> extra conversion to eciRGB or Beta RGB not potentially cause damage to the
> image (for example in clipping OOG colors and quantization errors)?
> Robert
> -----Original Message-----
> From: argyllcms-bounce@xxxxxxxxxxxxx [mailto:argyllcms-bounce@xxxxxxxxxxxxx]
> On Behalf Of Brad Funkhouser
> Sent: 07 July 2014 23:28
> To: argyllcms@xxxxxxxxxxxxx
> Subject: [argyllcms] Re: Custom Illuminant
> I agree, BetaRGB is also D50, which I like versus the D65s.  I'll check out
> eciRGB... That's not one I'm familiar with.  
> Thanks for the suggestion.
> - Brad
>> On Jul 7, 2014, at 3:13 PM, Roger Breton <graxx@xxxxxxxxxxxx> wrote:
>> Also, what I like about eciRGB is the fact there is never any issues with
>> chromatic adaption since everything happens on a pure-D50 scale, from PCS
> to
>> RGB to XYZ to "infinite and beyond!" -- sorry, got carried away...
>> / Roger
>> -----Original Message-----
>> From: argyllcms-bounce@xxxxxxxxxxxxx
> [mailto:argyllcms-bounce@xxxxxxxxxxxxx]
>> On Behalf Of Brad Funkhouser
>> Sent: 7 juillet 2014 14:40
>> To: argyllcms@xxxxxxxxxxxxx
>> Subject: [argyllcms] Re: Custom Illuminant
>> When AdobeRGB is a little too small, and ProPhotoRGB is just too big, try
>> Bruce Lindbloom's BetaRGB, it might be just right.
>> - Brad
>>> On Jul 7, 2014, at 9:18 AM, <robert@xxxxxxxxxxxxxxxxxx> wrote:
>>> << How does the gamut mapping know that no mapping is required ? If 
>>> you tell it the source gamut is ProPhoto, then it will think that lots 
>>> of gamut mapping is needed, since the ProPhoto gamut is so much larger 
>>> than a printer !>>
>>> Well that has finally clarified that point for me!  So with Perceptual 
>>> the whole source gamut is squashed down to the destination gamut, even 
>>> if all the colors are within the destination gamut.  This means that 
>>> in a Perceptual mapping from ProPhoto to print, colors will be 
>>> compressed resulting in desaturation of the image, particularly of the 
>>> more saturated colors nearer the print gamut boundary.
>>> So the following strategy might make sense for a Relative intent
>> conversion:
>>> - Going from ProPhoto to print, make sure the colors are more or less 
>>> within the destination space to avoid too much clipping.
>>> And the following for Perceptual:
>>> - Do a Relative conversion from ProPhoto to AdobeRGB (making sure the 
>>> colors are more or less within the AdobeRGB space before the 
>>> conversion to avoid too much clipping).
>>> - Do a Perceptual mapping from AdobeRGB to print.
>>> I did a comparison of a 1-step ProPhoto [Perceptual to Print 
>>> conversion] with a 2-step [ProPhoto to AdobeRGB conversion, followed 
>>> by an AdobeRGB Perceptual to print conversion]:
>>> - If the original image colors are all within the AdobeRGB gamut there 
>>> is quite a difference if the print gamut is much smaller than 
>>> AdobeRGB, but none if it is of similar size.
>>> - If the original image colors are outside the AdobeRGB gamut, the 
>>> 2-step approach is significantly better even if the print gamut is 
>>> very close to the AdobeRGB gamut.
>>> This is a bit puzzling because I would have expected a difference in 
>>> all cases (if the full ProPhoto gamut is squashed down in a Perceptual 
>>> conversion).
>>> What would be nice would be to be able to make the smaller 
>>> intermediate working color space using tiffgamut/colprof (from a range 
>>> of typical images), but I don't see how that could be done.
>>> Robert

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Other related posts: