W3C home > Mailing lists > Public > www-svg@w3.org > September 2012

Re: Perlin and simplex noise

From: Dean Jackson <dino@apple.com>
Date: Thu, 06 Sep 2012 11:27:50 -0700
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Rik Cabanier <cabanier@gmail.com>, www-svg@w3.org, public-fx@w3.org
Message-id: <CE11AB6B-A1BB-482E-84E1-F0CF5C7FD377@apple.com>
To: Dirk Schulze <dschulze@adobe.com>
I'm not adding much to the conversation, but I'd like to say that I generally agree with Tab on this topic. In particular:

- Adding noise to an image should be shorthand-level easy (not requiring markup, or even linking to a shader)

- We should add another algorithm for noise that can be easily implemented on hardware (this could be a new FE element, or an enhancement to feTurbulence)

- There should be a way to generate a noisy image directly in CSS (a while back we discussed generators like checkerboard or lens-flare (yuck!))

On that last topic, most of the noisy images I see on the Web are not one dimensional in colour - that is they are a blend between two (or maybe more) colours. This means such an <image> generator would either have to take a couple of parameters, or would require some extra blending syntax before it could replace the many wasteful PNG images that are clogging our pages.

Dean


On Sep 4, 2012, at 9:14 AM, Dirk Schulze <dschulze@adobe.com> wrote:

> 
> 
> On Sep 4, 2012, at 8:41 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
> 
>> On Mon, Sep 3, 2012 at 1:11 PM, Dirk Schulze <dschulze@adobe.com> wrote:
>>>> The type of noise I'm interested in is sufficient as a plain image.
>>>> It would also be useful as a filter function, sure, but I just want to
>>>> add a noise() function to the <image> type, and I'll rely on SVG
>>>> making a good decision about the type of algorithm to do it with.
>>>> 
>>> This is already specified by Filter Effects[1].
>> 
>> Yes, if you already have an <feTurbulence> filter set up.
> 
> That is correct. You would reference a SVG Filter.
>> 
>> Actually, though, I don't really understand how that works.
>> <feTurbulence> is one of the silly filter elements that's not a filter
>> at all, but actually just a paint server (created, if I recall earlier
>> explanations correctly, because nobody thought of just letting filters
>> accept paint servers directly as inputs, so you had to choose, and
>> turbulence seemed more useful as a filter input than a paint server).
>> This means it doesn't accept any inputs.  Do you just have to provide
>> a dummy image that then gets completely ignored and replaced with the
>> turbulence?
> If you rely on the referenced syntax, then yes. You would need to provide a dummy image, which is stupid. However, this syntax should change and take an optional image input instead - because of the primitives that create but don't take inputs like feFlood, feTurbulence and eventually custom().
> 
>> 
>> If so, then that's all the more reason to have a shorthand function
>> for this that's just an <image> type, not a filter at all.  
> No, it would be redundant which should not be the desired solution. If you take a look at the usage of feTurbulence, you'll see that most examples combine feTurbulence with other primitives like feComposite, feMerge, feColorMatrix and feBlur to create clouds, fire or even brushed metal. So like you said turbulence makes most sense in a filter chain. That would be the case for any generic noise algorithm.
> 
>> Like I
>> said, I'll just wait for SVG to settle on an algorithm, then I'll
>> reference it and define a new function in Image Values or something.
>> 
> Filter Effects don't live in SVG anymore but have their own module with the same name.
> 
> I am absolutely not opposed in moving filter() to CSS images, since it belongs to this specification anyway. But duplicating a feature that is mostly used in combination with filters doesn't sound like the best idea. Instead we should improve the filter() syntax and clarify if we want to have a noise() primitive function (maybe on top of a modified feTurbulence primitive or a new feNoise primitive).
> 
> I would like to hear the proposal on The Graphical Web conference before coming to a final conclusion.
> 
> To your paint server proposal: we discussed taking <image> as a paint server for SVG shapes during the last WG call. We thought that there are some things to clarify first before we do that and go at least with <gradient> from CSS3 images (or CSS4 images if it is ready before SVG2). But this would allow taking filter() (with turbulence) as paint server.
> 
> Greetings,
> Dirk
> 
>> ~TJ
> 
Received on Thursday, 6 September 2012 18:28:23 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:52 GMT