Forced Buffering Optimization by Sphinx.

Further information that couldn't fit in the description field:

The blur module is a bitmap based filter, which means that in order for it to work, it must rasterize (render) its input to an internal bitmap. We don't want the actual blurring, but setting the radius to 0 makes the module bypass itself (hence no rasterization), so we need to set it to the minimum instead: 0.0000001

Now every module connected to the output of that blur will draw samples from the blur components internal bitmap and not its input

Since the blur module process red, green, blue and alpha, you can use this advantage to buffer several independant grayscale sources in one blur (look at the construction of the snippet).

The method has some sideeffects you should be aware of:

* Increased initialization time
Typically you'll see a slow start because the internal bitmap is being rasterized, but when that step is over (typically after a few rows of rendering), it'll fly!

* Increased memory usage
Because of the internal bitmaps, the memory usage will grow significantly. Be aware that the global FF configuration

* No real subpixel samples
Because the rasterized bitmap is same size as the output image, subpixel sampling (antialias) will fetch interpolated samples inbetween pixels. If sample for pixel 1 is black and sample for pixel 2 is white, all subsamples will be within this range (i.e. shades of gray). This means that high frequency inputs (like a perlin with high roughness), might not render out as crispy as they normally would.
Plugging the buffer blur output into refractions, offsets and noise distortions can of same reason also result in different results.
If you dare, you could experiement with the "Anti-alias sources for bitmap-based components" option in FF, but this will most probably negate out the speed-up advantage.

Understanding how this works and being aware of these sideffects is important. Also try to limit the amount of user controls for things going into the blur buffer - if possible use alternate "post blur" constructions as this will give very good control response for the user (since the blur doesn't need to update when its input is unchanged). Again look at the two controls in the snippet - they are placed after the blur, making their response changes render very fast.

With my recent Cell Leather filter I tried submitting twice, rejected both times because it was too slow.. So I applied this buffering method, which made a huge difference (its quite fast now)..

And actually the first submit of the buffer filter snippet were rejected too, because I included *one* reference preset without buffering

If the small offset issue (I think its a bug) with the Motion Blur doesn't matter, you should definitely use Motion Blurs for buffering (faster than normal blur).

I think the blur module fetches 9 (maybe just 5) samples per rasterized sample in the internal blur bitmap for even the lowest radius. Whereas the motion blur only fetches 3.
Ideally the method only requires one sample (that would be very fast), but unfortunatly there is no way to make that happen, since one sample in a blur filter equals radius = 0, and radius = 0 makes the blur filter bypass itself (seems its bitmap is not created here).

Quote
ronviers wrote: I wonder if the offset and refraction components would work too.

No, only bitmap based components - Blur, Motion Blur and High Pass, where motion blur is the one best suited due to the lower sample fetching.

Quote
Sphinx. wrote: only bitmap based components

Ok. I remember uberzev is often using refraction and offset set to zero in his snippets and I was just thinking that maybe they were working on the same princple. Thanks for the clarification.
This sure is cool.

Quote
Sphinx. wrote: include an option for the user to disable it, as a true procedural chain will give better details when antialiased

understood

Quote
ronviers wrote: Ok. I remember uberzev is often using refraction and offset set to zero in his snippets and I was just thinking that maybe they were working on the same princple

Interesting! Which of his filters does this? Need to check that out.. learned alot about FF from his snippets already - amongst others the fact that FF rounds control values < 0.005 to 0.00, which also explains why the checkbox for the blur modules in my snippet shows 0.00 (checked) and 0 (unchecked).. which ofcourse is not correct, should be 0.00000001 (or something) and 0.

Quote
Carl wrote: With your understanding of all this I'm curious what your field is

Its the field of nerd Been programming graphics stuff for some years now (I'm co-developer on Graphics32, an opensource graphics library for Delphi and C++ Builder)

Quote
ronviers wrote: 'Proportional Gradient' uses the offset component while the snipped called 'Moveable Spokes' in this thread: http://www.filterforge.com/forum/read...ssage20929 uses the refraction component.

Hmm.. can't see any "set to zero" settings in those.. both seem to utilize the extreme zoom in capabilities of the offset component. The spokes in the Moveable Spokes filter comes from zooming in alot on the refraction output, if you try zooming even more in (49.999 or something) you'll see that the seemingly infinite vanishing point is not infinite..

Quote
Carl wrote: can't see any "set to zero"

This cap is from the proportional gradient filter. What does the offset do?

Quote
ronviers wrote: This cap is from the proportional gradient filter. What does the offset do?

ahh... its the invert offset blend emboss trick - here it creates the minimum vertical offset possible, which then is mixed with the inverted offset source and threshold to create an invert mask. The attached filter shows whats going on, only here I adjusted the numbers to get a visible range..

invert offset emboss.ffxml

Quote
Sphinx. wrote: its the invert offset blend emboss trick

That gives me a lot to think about. Thanks for the explanation.

Quote
Sphinx. wrote: it seems to do nothing

I see my mistake - sorry.

temp.ffxml

Quote
Sphinx. wrote: still looks to me that it does nothing

Yes, I'm very sorry about this Michael, as I mentioned in the previous post I made a mistake and never should have posted the question. I will try to be more careful about asking dumb questions in the future. Thank you for taking a look at it.

Quote
Sphinx. wrote: I thought it was the attachment that was wrong

I see the ambiguity now. Actually I added the attachment with another post but then noticed my mistake and was unable to remove the attachment after I edited the post. I did not realize how it would read after the edit.

Quote
Sphinx. wrote: no dumb questions.. only dumb answers

This was the exception that proves the rule.

This is a great idea Sphinx. I was thinking about posting a feature request for a "rasterize now" component, but you seem to have achieved that functionality with this workaround.

:cool:

Quote
Sphinx. wrote: Ideally the method only requires one sample (that would be very fast), but unfortunatly there is no way to make that happen, since one sample in a blur filter equals radius = 0, and radius = 0 makes the blur filter bypass itself (seems its bitmap is not created here).

Is this true, in the sense that FF completely ignores the Blur component? I had hoped, having read this comment recently, that using a control setting Blur Radius to 0 would prevent FF from trying to initialize the bitmap, preventing that annoying 5 second or more lag at the start of a filter. Like threshold clipping and switching, it did not seem to have that effect; which is sad, because it makes the "responsive layout" portion of my filter virtually useless.

Short of going in and manually disconnecting and bypassing the bitmap based components, there's no way to get around that bottleneck.

Is there something else that would do it I haven't heard of yet?