Re: Perlin and simplex noise

On the topic of the noise() shorthand, a thing that comes to mind is that  
such a construct would need to take at least a couple of parameters to be  
useful, and it would still most likely need to be coupled with additional  
filter steps (to e.g threshold and colorize the result).

For an example of what feTurbulence produces when used without combining  
it with other filter primitives, see e.g  
https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/examples/feTurbulence.svg.

I think that if we decide to add a css noise() shorthand it's better  
suited as a filter shorthand than as a CSS <image> generator. The question  
I'm asking is: what kind of image is it that people expect to get from  
noise()? The same as in the svg example above? (those example use 3  
explicit parameters and one implicit (the random seed), I'm not counting  
the generated image size since I assume that'd be provided elsewhere in  
CSS as well).

/ed

On Thu, 06 Sep 2012 20:27:50 +0200, Dean Jackson <dino@apple.com> wrote:

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


-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Friday, 7 September 2012 08:58:09 UTC