Re: [filter-effects] Maximum of octaves for feTurbulence

On Fri, 2013-12-06 at 09:12 -0800, Dirk Schulze wrote:
> Hi all,
> 
> There is a request to limit numOctaves for feTurbulence to a number of 10 [1]. The value of numOctaves describes the number of iterations the coherent-noise is generated by increasing frequency and decreasing amplitude. As noted in [2], at a certain iteration one can not expect more information while the time to calculate the noise still increases with increasing iteration. The libnoise tutorial says:
> 
> “”
> Notice that the amount of detail increases when the number of octaves increases. Beyond a certain number of octaves (determined by the resolution of the terrain height map), the frequency of the Perlin noise is greater than the resolution of the height map and you are doing more work than needed, for no effect.
> “”
> (The tutorial take the creation of terrains as one example for Perlin noise.)
> 
> I discussed this manner with Fredrik and Erik. Frederik explained that the terrain resolution in the quote is the number of bits per component for feTurbulence. UAs usually have 8bpc. Therefore, for UAs with 8bpc, an iteration >9 doesn’t give much value. For UAs with > 8bpc, more iterations (numOctaves > 9) could be of value.
> 
> Therefore, I don’t think that we can specify a fixed limit for numOctaves. Instead, I suggest to use the quote of above:
> 
> Note: The amount of detail increases when the number of octaves increases. Beyond a certain number of octaves, the frequency of the Perlin noise is greater than the color depth. The amount of information does not increase any further [2 informative reference]. UAs may clamp the specified value for numOctaves during the processing depending on the supported color depth. (For example: For a color depth of 8 bit per channel, the UA may clamp the value of numOctaves to 9.)

I think that two different things are being mixed up in the above
statement/explanation. There are two different effects with increasing
octave number. The first is due to the resolution (geometric) of the
generated bitmap. At some point, determined by 'baseFrequency' and zoom
level, the detail becomes smaller than a screen pixel and thus cannot be
resolved. I believe this is what is referred to in the quoted part from
[2].

The second effect is that the amplitude (maximum value) of each
additional octave is smaller than the previous octave and thus makes a
smaller contribution to the final pixel values. This is referred to in
the description of the figure with separate images for each octave in
[2]. For SVG, the amplitude of each octave is half of the previous
octave (the persistence is 0.5 in the language of [2]). For example, the
first octave contributes one-half of the total possible pixel value
(given an infinite number of octaves), the second one-fourth, ... the
eighth 1/256th.

It is not clear from the spec if the final value must be an integer,
only that the range be from 0 to 255. (The given algorithm returns a
double.) If the final value must be an integer, then the eighth octave
is the last octave to really contribute. It contributes in the range
+/-0.5 out of 255 (it can actually slightly exceed this range but with
low probability). Higher octaves may contribute only through influencing
rounding up or down.

In playing with the numOctaves in Inkscape, I saw very little difference
between going from 5 to 6 with a simple turbulence filter. There was
some visible difference in a quite complex filter in going from 9 to 10
in one case where the output of the turbulence primitive was the input
to a displacement map primitive but in the overall image the difference
was negligible.


A better wording for the note might be:

Note: The contribution of each additional octave to the color and alpha
values in the final image is one-half of the preceding octave. At some
point, the contribution of additional octaves becomes smaller than the
color resolution for a given color depth. UAs may clamp the specified
value for numOctaves during the processing depending on the supported
color depth. (For example: For a color depth of 8 bits per channel, the
UA may clamp the value of numOctaves to 9.)

Tav

> Greetings,
> Dirk
> 
> [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=22435
> [2] http://libnoise.sourceforge.net/tutorials/tutorial4.html#octaves

Received on Sunday, 8 December 2013 20:21:35 UTC