[argyllcms] Re: Beta RGB As a Color Workspace
- From: Chris Lilley <chris@xxxxxx>
- To: "Andreas F.X. Siegert" <lists@xxxxxxxxxxxxx>
- Date: Sat, 19 Jul 2014 11:34:48 +0200
Hello Andreas,
Friday, July 18, 2014, 11:00:17 PM, you wrote:
> Hi Chris,
> On 2014-07-17 10:13, Chris Lilley wrote:
>> Firstly, the rendering intent used for gamut mapping is not
>> discussed. When a wide gamut image is reduced down to a very small
>> one, relative colorimetric tends to keep the in-gamut colours the same
>> and piles up all the OOG colours at the boundary to give flat areas
>> where there used to be gradients. Perceptual, aka do something magic
>> and undefined, tends to map the entire source gamut to the destination
>> gamut in a content-unaware way which results in significant and
>> needless desaturation.
> But that is irrelevant for the topic of whether to keep stuff wide till
> the end or convert to small at the beginning.
I don't think so, because the gamut of an input-referred capture
device does not seem to be well defined. So there are two mapping
stages - input device to working gamut, and working to one or more
eventual output gamuts.
After the first mapping, then keeping stuff in a wide space is
certainly a benefit.
> The conversion will have
> to happen anyway. The question is, where do your losses happen or where
> is the bigger chance that you loose something in your path from camera
> to output.
> And it also depends whether the tool chain you use even allows that
> selection.
> Export from Lightroom or AfterShot for example is hardwired.
I agree that is problematic, but my point was made without regarding
the additional limitations of specific products.
>> The second thing that is missing is an examination of whether 16 bits
>> per component is actually sufficient for ProPhoto. It isn't, really,
>> for Lab and it needs to be shown, rather than assumed, that 16 bit is
>> sufficient resolution for ProPhoto.
> Well, in all practicality, there are only a few image editors out there
> that can handle more than 16bits, so it becomes theoretical issue.
> I rather stick to practical stuff I can test empirically. And it is so
> easy, even with a $100 toy printer (and appropriately profiled paper) to
> see that staying wide 'till the end gives the most realistic rendering
> of saturated colors.
I recall seeing a demonstration of required bit depth which started
with a 16M colours sRGB image (in other words it had one pixel of
every colour), converted to 8bit per component Lab and
back, then just counting the number of distinct colours.
ICC has added support for float profiles. Software like Krita can
handle 32bit, float, and double working spaces. Software aimed at the
film industry also tends to support higher bit depths.
Certainly, software like Photoshop has never prioritized higher bit
depths. Lok at the number of filters available with an 8bit RGB image;
then convert it to 16bit RGB and look how many are greyed out; convert
to 16bit Lab and look again. (And it used to be much worse).
The point I was making is this: sRGB has a lot of problems, but it
also has the benefit that 8bits per component is nearly good enough to
avoid visible quantization banding anywhere in the space.
All wider gamuts, or colour spaces that use a linear transfer
function, need 16 bits. BetaRGB has some problems, but it seems (to me
and again, mostly from empirical testing) that 16bits is enough for
BetaRGB (which is what I use as the working space in Nikon CaptureNX,
and also in Photoshop).
Lindbloom has shown that 16bit is insufficient for the physically
realizable surface colour gamut in Lab. It therefore makes sense to
ask whether an ultra-wide space like ProPhoto, with non-physical
primaries, introduces a problem (banding) at the same time that it
removes another (clipping).
>> Some words on the gamut of your printer, and links to the various
>> profiles used, would also round out a nicely argued article.
> Yup, it is somewhere on my todo list.
Thanks.
--
Best regards,
Chris mailto:chris@xxxxxx
Other related posts:
