- From: Tavmjong Bah <tavmjong@free.fr>
- Date: Sun, 08 Dec 2013 21:06:22 +0100
- To: Dirk Schulze <dschulze@adobe.com>
- Cc: "public-fx@w3.org" <public-fx@w3.org>, www-svg <www-svg@w3.org>
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