- From: Alex Danilo <adanilo@google.com>
- Date: Tue, 21 Feb 2012 08:11:03 +1100
- To: Leonard Rosenthol <lrosenth@adobe.com>
- Cc: Rik Cabanier <cabanier@adobe.com>, Chris Lilley <chris@w3.org>, Erik Dahlstrom <ed@opera.com>, "public-svg-wg@w3.org" <public-svg-wg@w3.org>
- Message-ID: <CAGdNekSeLcrbBsSXWZnv0Tnb75vBuLOdg0BTFpk1aqbaUrVeQQ@mail.gmail.com>
A value of L > 1 in an Lab color space is valid and may not be representable by an ICC profile. You are talking about 2 different things - able to be processed by an ICC color model engine, and out of gamut. Regardless 1 + 2 - 2 = 1 although the intermediate results can peak at 3 is what this is supposed to be discussing. Alex On Tue, Feb 21, 2012 at 2:22 AM, Leonard Rosenthol <lrosenth@adobe.com>wrote: > Colors outside the current profile (which may be the default sRGB or may > be an arbitrary one if the icc-profile() is used) are indeed invalid.**** > > ** ** > > Leonard**** > > ** ** > > *From:* Rik Cabanier > *Sent:* Sunday, February 19, 2012 10:57 PM > *To:* Leonard Rosenthol; Alex Danilo > *Cc:* Chris Lilley; Erik Dahlstrom; public-svg-wg@w3.org > *Subject:* RE: Agenda, 16 February 2012 SVG WG telcon**** > > ** ** > > Leonard,**** > > ** ** > > so do you agree that colors outside the normal RGB range are invalid?**** > > ** ** > > His colorspace is sRGB which means that his profile is created from/for > colors that can be displayed by the monitor.**** > > Doing math with colors that fall outside that boundary, is invalid and > will produce incorrect results.**** > > In this case, he should be working in more complete colorspace (like lab). > Of course, few clients actually want this, just like few want a DIC > workflow.**** > > ** ** > > Rik**** > > ** ** > > *From:* Leonard Rosenthol > *Sent:* Sunday, February 19, 2012 7:21 PM > *To:* Alex Danilo; Rik Cabanier > *Cc:* Chris Lilley; Erik Dahlstrom; public-svg-wg@w3.org > *Subject:* RE: Agenda, 16 February 2012 SVG WG telcon**** > > ** ** > > There’s a difference between a color being out of gamut and a color not > being valid for a given profile. And it also depends on whether it’s a > LUT-based profile or a calculated profile. So if you are going to base > your color model around that of the ICC (which would make sense, since it’s > the industry standard for color management), then you need to be sure to > map to that model.**** > > ** ** > > If you want to be future looking in terms of color, then look at Spectral > color models – which is where ICC.2 is headed.**** > > ** ** > > Leonard**** > > ** ** > > *From:* Alex Danilo [mailto:adanilo@google.com] > *Sent:* Sunday, February 19, 2012 7:03 PM > *To:* Rik Cabanier > *Cc:* Chris Lilley; Erik Dahlstrom; public-svg-wg@w3.org > *Subject:* Re: Agenda, 16 February 2012 SVG WG telcon**** > > ** ** > > Hi Rik,**** > > ** ** > > Yes they are valid results - but not necessarily useful:-)**** > > ** ** > > Implementations usually can't store them - especially if you're using > 8-bit per component RGB. So in many cases they get clamped at intermediate > stages but certainly there's no color science reason those values aren't > legit.**** > > ** ** > > In RGB the > 100% values represent fluorescent colors, i.e. they are > brighter than full white, so that could represent a light source > fluorescing under sunlight, etc.**** > > ** ** > > When I did filters some time last year I ended up having to move to 16-bit > linearRGB space to eliminate banding, and there no reason a color > management engine shouldn't be able to handle out of gamut colors etc. by > using floats/fixed point or similar.**** > > ** ** > > However, practical considerations may well limit what is nice to process > as intermediate results. So I can see why people don't like the idea of > unusual values in the intermediate filter results, and the spec. doesn't > limit intermediate color values, but clamping to something sensible at the > end of the chain may well produce better results than limiting each stage > of the pipe.**** > > ** ** > > Alex**** > > On Sat, Feb 18, 2012 at 3:02 AM, Rik Cabanier <cabanier@adobe.com> wrote:* > *** > > Hi Alex,**** > > **** > > Are you saying premultiplied alpha where the color component are greater > than the alpha value (or negative) are valid results?**** > > Even with linearRGB, we are still in the RGB colorspace (not XYZ or some > other hypothetical space)…**** > > **** > > Rik**** > > **** > > *From:* Alex Danilo [mailto:adanilo@google.com] > *Sent:* Thursday, February 16, 2012 4:45 PM > *To:* Chris Lilley > *Cc:* Erik Dahlstrom; public-svg-wg@w3.org > *Subject:* Re: Agenda, 16 February 2012 SVG WG telcon**** > > **** > > +1 to that.**** > > **** > > There seems to be some disconnect between what colour management is about > recently.**** > > **** > > For example the recent thread (on webkit-dev perhaps?) about filters > generating colour that's 'illegal' - i.e. the colour channels greater than > the alpha in pre-multiplied form is wrong. It's just a fluorescent colour. > **** > > **** > > We really should ensure we do colour science properly.**** > > **** > > Alex**** > > On Thu, Feb 16, 2012 at 11:49 PM, Chris Lilley <chris@w3.org> wrote:**** > > On Thursday, February 16, 2012, 10:14:36 AM, Erik wrote: > > ED> Missed one thing: > > ED> * color-interpolation-filters > ED> > ED> > http://www.w3.org/mid/CAGN7qDDh_yJX_EzWNtuvW3N_eywgvB3MioMn6FoP_p8kHTwh-A@mail.gmail.com > > > Are we discussing: > > a) how to specify the longhand, element-based equivalent to each of the > css shorthand properties (which will include the value of the > color-interpolation-filters property, > > or > > b) whether to remove color-interpolation-filters and color-interpolation, > thus breaking backwards compatibility and destroying improvements in color > management in SVG2, because of flawed understanding of basic concepts like > gamma, chromaticity, and so forth? > > If a) then I am all in favour of providing the longhand equivalents and > would like to see tests that put the longhand and shorthand side by side so > we can check that implementors are doing the right thing. > > If b) and we are seriously considering legislating the dumb approach to > RGB, then I have strong objections to such a wrong-headed approach. > > I can provide links to further reading if people need to brush up on basic > concepts. > > > -- > Chris Lilley Technical Director, Interaction Domain > W3C Graphics Activity Lead, Fonts Activity Lead > Co-Chair, W3C Hypertext CG > Member, CSS, WebFonts, SVG Working Groups**** > > **** > > ** ** >
Received on Monday, 20 February 2012 21:11:31 UTC