[argyllcms] Re: Custom Illuminant

  • From: Roger Breton <graxx@xxxxxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Tue, 08 Jul 2014 08:12:23 -0400

Robert,

Many moons ago, Bruce Lindbloom demonstrated mathematically that g2.2 was
better than 1.8 for everything.

/ Roger

-----Original Message-----
From: argyllcms-bounce@xxxxxxxxxxxxx [mailto:argyllcms-bounce@xxxxxxxxxxxxx]
On Behalf Of robert@xxxxxxxxxxxxxxxxxx
Sent: 8 juillet 2014 07:50
To: argyllcms@xxxxxxxxxxxxx
Subject: [argyllcms] Re: Custom Illuminant

Hi Ben/Roger,

Here is an interesting observation: if you convert an image from ProPhoto to
Print via Beta RGB and compare it to the same image converted from ProPhoto
to Print direct, there's virtually no difference. If you do the same
comparison, but this time via eciRGB instead of BetaRGB, there is a
difference, albeit small.  I assume that the difference via eciRGB is
because of quantization errors due to the L* curve.

I did the comparison using the Difference mode in Photoshop.

Based on this ... there may be something to be said for going Lightroom to
ProPhoto and then ProPhoto to Beta RGB, as edits in Beta RGB should have
fewer quantization errors than in ProPhoto, I would have thought (because it
uses a gamma of 2.2 instead of 1.8, and because it's a smaller space), while
not clipping the viewable colors in the original image. 

Is it worth the trouble or not??  Does working in a gamma of 2.2
significantly reduce quantization errors when working in 16-bit (which I
always do)? Is it better, visually, to edit with a gamma of 2.2 instead of
1.8?  I couldn't begin to answer these questions (!), but perhaps you could?

Regarding the Lightroom/ACR raw processing being optimized for 'pleasing'
colors rather than accurate colors ... that's OK for me as I don't do fine
art reproduction type work.

Robert

-----Original Message-----
From: argyllcms-bounce@xxxxxxxxxxxxx [mailto:argyllcms-bounce@xxxxxxxxxxxxx]
On Behalf Of Ben Goren
Sent: 08 July 2014 01:20
To: argyllcms@xxxxxxxxxxxxx
Subject: [argyllcms] Re: Custom Illuminant

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.

b&

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
>> 
>> 
> 
> 
> 




Other related posts: