Re: Gabor noise [was RE: Perlin and simplex noise]

I am not a graphics engineer, so this may be review for folks on this list,
but I found this 2010 survey of procedural noise generation algorithms from
to be helpful in understanding state of the art and trade offs among
various noise functions.

State of the Art in Procedural Noise Functions

A. Lagae1*,*2 S. Lefebvre2*,*3 R. Cook4 T. DeRose4 G. Drettakis2 D.S. Ebert5
J.P. Lewis6 K. Perlin7 M. Zwicker8

1Katholieke Universiteit Leuven 2REVES/INRIA Sophia-Antipolis 3ALICE/INRIA
Nancy Grand-Est / Loria

4Pixar Animation Studios 5Purdue University 6Weta Digital 7New York
University 8University of Bern

http://www-sop.inria.fr/reves/Basilic/2010/LLCDDELPZ10/LLCDDELPZ10STARPNF.pdf


On Tue, Nov 12, 2013 at 3:48 AM, David Dailey <ddailey@zoominternet.net>wrote:

> Hi folks,
>
> Nikos A., from Canon, gave a recent and very well-documented talk at The
> Graphical Web (some of you may remember it as SVG Open?) on diffusion
> curves [1]. I found the rationale for their inclusion in a future spec
> quite compelling, btw, but that's a different issue.
>
> He also mentioned something quite cool: Gabor noise (related to Gabor
> filters). [2]
>
> I'm not sure of the computational complexity of it relative to Perlin
> noise, but at the end of the paper [2] one can see a large variety of very
> interesting textural effects that are simply not expressible with
> feTurbulence at present, short of, for example, overlaying two or more
> feTurbulences with different frequencies, octaves and directionality, and
> thence using an feDisplacement to combine them. Likely, this strategy would
> be computationally more intense than unpacking the rather dense-looking
> math of Gabor filters.
>
> But Gabor noise appears to be scalable, like feTurbulence, and, most
> importantly, it adds a rich set of textures that would enable more
> naturalistic approximations to the sorts of things humans might want to
> draw.  Combine Diffusion curves with Gabor noise, and I suspect you'd go a
> very long way toward enabling very economical approximations to many real
> world images (hence, phenomenal image compression) and while image analysis
> is not, per se, a part of the SVG WG's purview, it is, nonetheless, the
> ancestor of zillions of use cases for SVG. And, of course, there is always
> the ability to draw pretty pictures with it!
>
> Regards
> David
>
> [1] I gather he's been working with Cyril, and mentions this paper.
> Apologies, if I misunderstood the relation between this work.
> http://biblio.telecom-paristech.fr/cgi-bin/download.cgi?id=14268
>
> [2]
> http://peterwonka.net/Publications/pdfs/2011.EG.Jeschke.DiffusionCurveFitting.AdditionalMaterial.pdf
>
>
> -----Original Message-----
> From: Erik Dahlstrom [mailto:ed@opera.com]
> Sent: Friday, August 31, 2012 4:58 AM
> To: www-svg@w3.org
> Cc: public-fx@w3.org
> Subject: Re: Perlin and simplex noise
>
> On Thu, 30 Aug 2012 18:51:32 +0200, David Dailey <ddailey@zoominternet.net>
> wrote:
>
> > I know you all found the concepts of declarative randomness a bit
> > distasteful (we're giving a talk on it at the conference in
> > Switzerland,
> > soon) and given the history of society's reaction to randomness, one
> > can perhaps understand if not appreciate that reaction.
> >
> >
> > However, I wondered if thought has been given to Simplex noise in
> > addition to Perlin noise[1]?
>
> Some thought has gone into that[2], but there's no concrete proposal for
> it yet. It's listed as issue 15 in the filter draft [3].
>
> I would like to see a more hardware friendly noise algorithm in the spec,
> e.g simplex noise (or something with the same characteristics), but if we
> want existing content to look the same we can't just switch the algorithm
> in feTurbulence since the algorithm in the spec and the simplex algorithm
> generate slightly different results. But, it may well be that the
> differences are small enough that it would be acceptable, anyhow I think
> that needs to be investigated.
>
> What do other people think? The computational cost of the noise algorithm
> in SVG 1.1 is fairly high, and that does limit what you can use it for in
> practice. If we chose to go for a new noise algorithm I would also like to
> be able to animate the noise continously (I think this means we'd need the
> 3d version of the algorithm). That is, I'd like to simulate say fire or
> smoke, and link the z dimension in the noise algorithm to the time
> dimension so that the animation is continous (without strange gaps and
> without it looking like the result is scrolled along either or both of the
> x and y-axis).
>
>
> [1] http://en.wikipedia.org/wiki/Simplex_noise
> [2] http://www.w3.org/2009/02/05-svg-minutes.html#item01
> [3]
>
> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#feTurbulenceElement
>
> --
> Erik Dahlstrom, Core Technology Developer, Opera Software Co-Chair, W3C
> SVG Working Group Personal blog: http://my.opera.com/macdev_ed
>
>
>
>
>
>


-- 
www.sencha.com
"Amazing Apps with Web Technologies"