Re: Proposal: feHSL element (was Re: [filter-effects] hue-rotate() and saturate() filters)

Hello Tab,

Tuesday, October 15, 2013, 7:28:40 PM, you wrote:

> On Tue, Oct 15, 2013 at 9:02 AM, Chris Lilley <chris@w3.org> wrote:
>> 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 was going to comment that it seemed like you've have issues on the
> the low end too (you lose the hue information),

Yes. Finite and barely-enough precision combined with a poorly
designed colourspace (hue and saturation progressively loose precision
as L moves away from 50%) is always going to give you that.

> but it looks like you
> can't recover from a 0 saturation in a later filter, as you only have
> multiplicative adjustments.

Correct.

>  (My color adjusters in Colors 4 can do
> additive adjustments to saturation, so I keep the hue information
> around when possible.)

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

> Even if they are available by other means, I think it's worthwhile to
> reproduce them here, so that you have a complete and
> easy-to-understand interface.

Okay, I can think of two L adjustments: lighten/darken (add a bipolar
offset to L, clamping any values outside 0% ... 100%) and contrast
(multiply by a number around L=50%, where 1.0 is no change, numbers
below 1 reduce contrast and numbers above increase it).

However, neither additive or multiplicative adjustment is as useful as
a curve-based approach; you want to roll-off the effect as it
approaches a boundary, not hard clip.

This is analogous to Phooshop beginners using the 'nice, easy'
contrast and lightness sliders, until they realise that gives them
nasty clipping and they learn about curves and histograms.

I'm reluctant to introduce something with obvious problems. We can
always add new types later

But if you insist and after some thought: maybe value takes a list of
number pairs which produces a transfer curve; a smooth curve (like a
Catmull-Rom curve) is run through the supplied points). An
implementation would likely compute the curve and then produce a
256-element lookup table based on that curve.

-- 
Best regards,
 Chris                            mailto:chris@w3.org

Received on Wednesday, 16 October 2013 13:32:56 UTC