Re: [css4-color] unclamped values for RGB

On Tue, Jul 17, 2012 at 6:23 AM, Chris Lilley <chris@w3.org> wrote:

> On Sunday, June 17, 2012, 9:18:56 PM, Rik wrote:
>
> RC> The problem I see with the current spec, is that it is wrong and
> RC> that it will make decent color management in the future
> RC> impossible.
>
> I don't believe that it is wrong, nor that it makes color management
> impossible.
>
> RC> CMS is primarily about mapping gamuts from one
> RC> colorspace to another [1]. By removing the clamping, the gamut is
> RC> made infinite so this becomes impossible.
>
> No.
>
> The gamut is still there and is unchanged. Unclamped values just allows
> values which are outside the gamut to be specified, and to be treated,
> without multiple round-off steps.
>

My specific issue here was with gamut mapping.
For instance, if you go from a large to a small gamut device, you will see
a sudden jump in output color when the input color goes outside of the
gamut.
I was since told that this is only a problem with perceptual profiles so
it's fine with sRGB or AdobeRGB which can only do colorimetric (at least
with the Adobe CMM)


>
> (This is clearly easier in a linear space, because the transfer function
> outside the gamut is obvious, but it can also be done in gamma-companded
> space by reflecting the transfer curve about zero and using a linear
> extension above 1.0. The most common out of gamut values are small negative
> values in the red channel).
>
> I understand that some color engines are unable to deal with out of gamut
> colors, and will clamp anyway. But that is not universal, and forcing
> better implementations to clamp when they don't need to artificially
> constrains the better implementations to do a less good job than they are
> capable of.
>
> A useful paper on unbounded values in an ICC workflow is
>
> Unbounded Color Engines
> Marti Maria
> http://www.littlecms.com/CIC18_UnboundedCMM.pdf
>
> (Marti Maria is the author of the LittleCMS engine, which is used for
> example in HP large-format inkjets).
>
> Note that this is now a part of ICC v.4, with the Floating Point Encoding
> Range addendum. So I have to agree with the ICC (and thus disagree with
> Rik) on the assertion about unbounded values being incompatible with an ICC
> workflow :)
>

I think this paper agrees that out-of-bounds colors are sometimes
problematic.
For instance, if a profile is table based, this workflow is not going to
work unless you work around it by going to/from a matrix based profile
first.


>
> On the consumer electronics side, HDMI supports a wide-gamut colorspace,
> xvYCC. Note that this encodes an sRGB gamut (in the video range of 16..240
> rather than the computer range of 0..255) for compatibility with older
> equipment, and encodes the out of gamut colors as ... out of gamut colors
> :) or in other words, unclamped values.
>
> "Opto-electronic transfer characteristics [Extended]
> ?? Extended ITU-R BT.709 tone curve by
> defining over-ranged values.
> ?? Unchanged for inside the ?0-1? range."
>
> See this presentation, and in particular slides 14-16:
> http://data.memberclicks.com/site/hopa/2007_xvYCC_forHPA_FINAL.pdf
>
> "The xvYCC color space permits YCC values that, while within the encoding
> range of YCC, have chroma values outside the range 16?240, or that
> correspond to negative RGB values, and hence would not have previously been
> valid. These are used to encode more saturated colors."
> http://en.wikipedia.org/wiki/XvYCC
>
> DisplayPort did not support that at first, although DisplayPort 1.2 added
> this.
>
> There has also been some recent discussion of colorimetric
> characterisation of digital cameras; it turns out that negative values are
> needed for a full characterisation.
>
> So various industry segments are supporting unclamped, out of gamut colors.
>

Yes, under the hood.
How will a poor user come up with these values?


>
> RC> I think if CSS implements the SVG color-profile property [2]
> RC> (without the <name> keyword), that would be a great step forward.
> RC> Old implementations would ignore it, so their colors will look
> RC> slightly off but would most likely still be reasonable.
>
> Yes, implementing the color-profile property (and the rendering colorspace
> support) would be a big improvement. I don't see why you want to drop the
> name keyword though, since that is how you refer to the ICC profile!
>

I misunderstood what 'name' does. I assumed it had to point to a
'color-profile' element which would mean extending the HTML spec. After
rereading it, it's clear that it can point to a CSS rule.


> RC> Lab would be really great since it corresponds to how we perceive
> RC> color. This makes gradients and meshes more pleasing to the eye
> RC> and has no need for profiles from the user's side.
>
> Agreed.
>
> RC> It's not unthinkable that in the near future there will be a race
> RC> for best color displays (like there now is for resolution) so it would
> be good to be prepared.
>
> This has already started.
>
> Wide-gamut desktop displays have moved down in price from the
> multi-thousand dollar products of a decade ago. Products like the NEC
> spectraview are more competively priced, EIZO do a range of more affordable
> wide-gamut models. Mainstream manufacturers like Dell, HP and Asus
> (Ultrasharp, Dreamcolor and Pro-Art ranges, respectively) offer affordable
> wide-gamut displays that cover most of AdobeRGB (although without the
> display linearity circuits of the more expensive offerings).
>
> Although these are marketed towards the graphics arts community, it is the
> larger amateur photographer market that seems to be driving this
> popularisation.
>
> A couple of laptops (HP and Dell) have wide-gamut displays available in
> their 15inch and 17inch models.
>
> The 'new iPAD' has a wider gamut (most of sRGB) than the very desaturated
> much-less-than-sRGB displays of the original iPad and iPad2.
>
>
True, but it has not been brought up as a compelling feature to the general
consumer.
After resolution goes to levels beyond necessity, that might change and we
will get wide color gamut displays (which will actually be more useful IMO).

Thanks for all the good info!
I'm now convinced that unclamped values are OK in an sRGB world.

How would we proceed with adding support for profiles? Someone must have
proposed this before...

Rik