- From: Chris Lilley <chris@w3.org>
- Date: Thu, 17 Oct 2013 17:58:32 +0200
- To: Dirk Schulze <dschulze@adobe.com>
- CC: Rik Cabanier <cabanier@gmail.com>, FX <public-fx@w3.org>
Hello Dirk, Thursday, October 17, 2013, 5:47:36 PM, you wrote: > I hardly believe that anyone wants to have the color clipping > within the filter primitive feColorMatrix. So I wonder (given that > we have the support of UAs) if we could change the behavior of hue > rotate and saturate types on feColorMatrix to operate on HSL directly? No, because its not a matrix operation. > The name feColorMatrix would be misleading, very > but the definition is just > <feColorMatrix type="hueRotate" values="30"/> > anyway. Same for saturate. This probably changes existing results. Yes, it certainly does. > But it probably just fixes the results also. No, it breaks them and introduces confusion. > I really don't want to add yet another SVGFE*Element. Adding a new one with a clear name seems *far preferable* to re-defining an existing name to have non-matrix-like behaviour and operate in a different colourspace depending. That just seems like a hack and a source for confusion (are you using the definition from 1998-2013 or the post-2013 definition of the same thing which is totally different). I would oppose such a redefinition of the longhand. Its better to introduce a new element and new, clear shorthands, and to direct users to the new shorthands. > On Oct 16, 2013, at 11:59 PM, Chris Lilley <chris@w3.org> wrote: >> Hello Rik, >> >> Wednesday, October 16, 2013, 10:59:11 PM, you wrote: >> >>> It seems that this should work and be lightweight. >> >> Thanks. >> >>> I'm unsure if we should add a new filter element or just update the CSS shorthands. >> >> I suggest both; update the CSS shorthands to point to this, and add >> the filter so that longhand (user constructed) filters can use it as >> one component. >> >> >>> On Wed, Oct 16, 2013 at 6:54 AM, Chris Lilley <chris@w3.org> wrote: >> >>> Hello Dirk, >>> >> >>> Tuesday, October 15, 2013, 7:37:18 PM, you wrote: >>> >>> >>>> On Oct 15, 2013, at 6:02 PM, Chris Lilley <chris@w3.org> wrote: >>> >>>>> Hello , >>>>> >>>>> >>>>> Here is a proposal for a new feHSL element which performs hue rotation >>>>> and saturation changes without suffering from internal clipping. Due >>>>> to filter effects clipping after each primitive, saturation increases >>>>> will still suffer from clipping in a multi-stage pipeline. >>>>> >>>>> I didn't provide for any operations on the L axis of HSL because >>>>> operations on lightness or luminance are already available by other >>>>> means. >>>>> >>> >>>> I wonder how the proposal solves the problem. >>> >>> Apparently I didn't describe it well enough. >>> >> >>>> The input is still RGB, the output is still RGB. >>> >>> Correct >>> >> >>>> It might differ between linearRGB or >>>> sRGB. >>> >>> No; in either case (as stated in the proposal) you convert to sRGB >>> and thence to HSL. >>> >> >>>> So you still have the clipping, no? >>> >>> No. >>> >>> OK, time for some 3D visualisation. Just close your eyes and >>> concentrate on the music. Ahem. >>> >>> In the current matrix approach, you have colour arranged in a cube >>> (RGB) and all values outside the cube are clipped. The filter tilts >>> the cube so the lightness axis (black to white) is upright. It then >>> rotates the cube about that axis, *clipping to the boundary of the >>> original, tilted, unrotated cube*. >>> >>> Visualize a sphere that is as big as it can be while still fitting in >>> the cube. When the cube is tilted, place a cylinder that is parallel >>> to the lightness axis and just fits over the sphere. Colours outside >>> that cylinder risk being clipped (depending on how large the rotation >>> angle is). >>> >>> In the HSL approach, the colourspace is already a cylinder and all >>> in-gamut RGB colours fit in that cylinder. Hue rotation rotates the >>> cylinder on its axis; no part of the cylinder falls outside the >>> cylinder so hue rotation does not produce clipping. Saturation >>> decreases do not produce clipping (though, because of the nature of >>> HSL, you do get a reduction in hue precision). Saturation increases >>> can result in clipping (but the clipping is to the cylinder surface so >>> hue and lightness are not affected and the result is less visually >>> objectionable). >>> >>> Hope that helped? >>> >> >>>> Could you elaborate more >>>> please? Also, would the new element ignore the >>>> color-interpolation-filters property? >>> >>> I covered that in the proposal. Perhaps too tersely? >>> >>> If c-i-f is sRGB, the conversion going into the filter is sRGB -> HSL >>> and going out, HSL -> sRGB. >>> >>> If c-i-f is linearRGB, the conversion going into the filter is >>> linearRGB -> sRGB -> HSL and going out, HSL -> sRGB -> linearRGB >>> >>> If c-i-f is some other value (SVG2 adds other values to c-i, maybe add >>> them to c-i-f too?), the conversion going into the filter is >>> someothervalue ->sRGB -> HSL and going out, HSL -> sRGB -> someothervalue. >>> >>> Of course, if the filter designer had set someothervalue to, say, >>> CIELCHab then they would more likely choose to do a different type of >>> hue rotate (directly on the H component of LCH) thus avoiding the >>> bunched up, uneven hue distribution of HSL, the non-independence of H >>> S and L in HSL, and the limited gamut of sRGB. >>> >> >>>>> ================================================= >>>>> >>>>> Name: feHSL >>>>> Categories: Filter primitive element >>>>> Content model: Any number of the following elements, in any order: >>>>> >>>>> <animate> >>>>> <set> >>>>> >>>>> Attributes: >>>>> >>>>> core attributes — ‘id’, ‘xml:base’, ‘xml:lang’, ‘xml:space’ >>>>> presentation attributes — ‘alignment-baseline’, ‘baseline-shift’, >>>>> ‘clip’, ‘clip-path’, ‘clip-rule’, ‘color’, ‘color-interpolation’, >>>>> ‘color-interpolation-filters’, ‘color-profile’, ‘color-rendering’, >>>>> ‘cursor’, ‘direction’, ‘display’, ‘dominant-baseline’, >>>>> ‘enable-background’, ‘fill’, ‘fill-opacity’, ‘fill-rule’, ‘filter’, >>>>> ‘flood-color’, ‘flood-opacity’, ‘font’, ‘font-family’, ‘font-size’, >>>>> ‘font-size-adjust’, ‘font-stretch’, ‘font-style’, ‘font-variant’, >>>>> ‘font-weight’, ‘glyph-orientation-horizontal’, >>>>> ‘glyph-orientation-vertical’, ‘image-rendering’, ‘isolation’, >>>>> ‘kerning’, ‘letter-spacing’, ‘lighting-color’, ‘marker’, >>>>> ‘marker-end’, ‘marker-mid’, ‘marker-start’, ‘mask’, ‘mix-blend-mode’, >>>>> ‘opacity’, ‘overflow’, ‘pointer-events’, ‘shape-rendering’, >>>>> ‘stop-color’, ‘stop-opacity’, ‘stroke’, ‘stroke-dasharray’, >>>>> ‘stroke-dashoffset’, ‘stroke-linecap’, ‘stroke-linejoin’, >>>>> ‘stroke-miterlimit’, ‘stroke-opacity’, ‘stroke-width’, ‘text-anchor’, >>>>> ‘text-decoration’, ‘text-rendering’, ‘unicode-bidi’, ‘visibility’, >>>>> ‘word-spacing’, ‘writing-mode’ >>>>> filter primitive attributes — ‘x’, ‘y’, ‘width’, ‘height’, ‘result’ >>>>> ‘class’ >>>>> ‘style’ >>>>> ‘in’ >>>>> ‘type’ >>>>> ‘value’ >>>>> >>>>> DOM Interfaces: SVGFEHSLElement >>>>> >>>>> This filter applies a transformation in HSL colorspace. Input values >>>>> are converted (if needed) from the colorspace given by >>>>> 'color-interpolation-filters' to sRGB, and then to HSL for processing. >>>>> Results are converted from HSL to the colorspace given by >>>>> 'color-interpolation-filters'. >>>>> >>>>> The calculations are performed on non-premultiplied color values. >>>>> >>>>> Attribute definitions: >>>>> >>>>> type = "hue" | "saturation" >>>>> Indicates the type of operation to be performed: hue rotation or >>>>> saturation/desaturation. The lacuna value for 'type' is "hue". >>>>> >>>>> value = <number> >>>>> For type="hue", the value represents a hue rotation in degrees. >>>>> Positive and negative angles may be specified. The new hue angle H' >>>>> is given by >>>>> >>>>> H' = (H + value) mod 360 >>>>> >>>>> For type="saturation", the value represents a saturation multiplier. >>>>> Values less than 1.0 represent desaturation; values greater than 1.0 >>>>> represent increases in saturation. A value of 0.0 results in full >>>>> desaturation to the L axis. The new saturation value S' is given by >>>>> >>>>> S' = S * value >>>>> >>>>> Note that results are clamped to the saturation range 0.0 ... 1.0 >>>>> >>>>> The lacuna value of 'value' depends on the value for 'type'. For >>>>> type="hue" the lacuna value for 'value' is 0.0 (no rotation); for >>>>> type="saturation" the lacuna value for 'value' is 1.0 (no change in >>>>> saturation). >>>>> >>>>> ============================================================= >>>>> >>>>> Add an example or two and some suitable definition for the DOM >>>>> interface. >>>>> >>>>> -- >>>>> Best regards, >>>>> Chris mailto:chris@w3.org >>>>> >>>>> >>> >>> >>> >>> >>> >>> -- >>> Best regards, >>> Chris mailto:chris@w3.org >>> >>> >>> >> >> >> >> >> -- >> Best regards, >> Chris mailto:chris@w3.org >> -- Best regards, Chris mailto:chris@w3.org
Received on Thursday, 17 October 2013 15:58:38 UTC