Optimizing Filters for Speed
|
Vladimir Golovin
Administrator |
1. SLOWEST: Image-based components (Blur, Motion Blur, Sharpen and High Pass) with any slow component (like Worley-based noise) as a source. 2. SLOW: Worley-based noises (any Noise except Perlin, which is very fast). 3. SLOW: Image-based components (see above) in general, because they need to prepare a source bitmap before rendering themselves. 4. CAN BE SLOW: Refraction, especially with a slow component as a source. Refraction takes 3 samples of the source input. 5. CAN BE SLOW: Any Noise (or any component based on Noise such as Noise Gradient, Noise Distortion or Noise Curve) with high Detail and Roughness (they are interdependent) especially with a custom curve as a profile. 6. CAN BE SLOW: Any Noise with a custom curve as a profile -- the curve is sampled once for each noise octave (for Details = 10 you have 10 samples of the curve per one noise sample). 5. CAN BE SLOW IN CERTAIN CASES: Any component that generates edges for anti-aliasing (Patterns, Worley noises, some of the adjustments). But since anti-aliasing is done in a separate pass, that shouldn't impact speed too much. 6. FAST: Patterns, Channels, Adjustments, Gradients (except for Noise gradient). 7. ULTRA-FAST: Externals (Image and Selection), Checker, Switch, Blend, Offset. |
|||
| Posted: June 1, 2006 8:15 am | ||||
| rilos |
Thats a good hint, thanks a lot!
regards, rilos |
|||
| Posted: June 7, 2006 12:28 pm | ||||
byRo
 |
Sometimes a filter may use the External Image as an input to many different components. Often the connections can cross the whole filter from start to end. In this "ULTRA-FAST" case, can I interpret that we can sprinkle duplicates of the External Image throughout the filter without suffering any (or too much) delay. i.e. increased legibility, without sacrificing speed. 
If so, is the same true of the other components quoted? Rô _________________________________
My favourite question is "Why?". My second favourite is "Why not?" |
|||
| Posted: June 9, 2006 2:21 pm | ||||
|
Vladimir Golovin
Administrator |
Yes, you can use multiple duplicates of the Image component, this won't affect the speed. |
|||
| Posted: June 10, 2006 1:50 am | ||||
|
Vladimir Golovin
Administrator |
External > Selection. As for other components, I would not recommend duplicating them. The renderer has an optimization called "sample cache" that can save you a significant amount of rendering time in situations when a single component has multiple outbound connections -- you won't get the speedup when using duplicates instead of connections. |
|||
| Posted: June 10, 2006 1:54 am | ||||
|
byRo
|
Thank you, Vladimir.
Rô _________________________________
My favourite question is "Why?". My second favourite is "Why not?" |
|||
| Posted: June 10, 2006 9:03 am | ||||
Crapadilla
 |
Maybe these optimization tips should also go into the help wiki (I couldn't find them in the wiki anywhere). And how about a rendering knowledge-base with its own sub-section? --- Crapadilla says: "Damn you, stupid redundant feature requests!" ;) |
|||
| Posted: January 23, 2007 3:35 pm | ||||
Torley
Posts: 303 |
Good tips to keep in mind! Thanx.  I'm enjoying using Filter Forge to create http://torley.com/textures |
|||
| Posted: February 3, 2007 9:43 pm | ||||
StevieJ
 |
Great info!!! Thanx Vladimir  Steve
"Buzzards gotta eat...same as worms..." - Clint :) |
|||
| Posted: February 13, 2007 6:09 pm | ||||
uberzev
 |
|
|||
| Posted: February 15, 2007 3:24 pm | ||||
|
Vladimir Golovin
Administrator |
A sample is a single evaluation of the image function (built by the filter tree) at given coordinates. To determine the surface normal vector, we need to know the surface heights of at least two more points near the location of the central sample. Hence, three samples. | |||
| Posted: February 15, 2007 3:47 pm | ||||
|
Crapadilla
|
Vladimir,
the average user probably won't be too familiar with the technicalities of sample-based architectures (and neither am I). Although there already is good info on this in the 'Result Component' Wiki entry, I sincerely hope to see a section that delves deeper into the topics of 'rendering', 'samples', the 'image function' and the 'filter tree', sort of a 'Filter Forge under the hood' article. --- Crapadilla says: "Damn you, stupid redundant feature requests!" ;) |
|||
| Posted: February 17, 2007 2:24 pm | ||||
|
Vladimir Golovin
Administrator |
Some info can be found here:
http://www.filterforge.com/more/help/...nents.html |
|||
| Posted: February 20, 2007 9:46 am | ||||
David S
 |
Obviously one would want to create the most efficient filter possible, so the User does not have to "wait for the paint to dry", but at times efficiency and creativity seem to be at the opposite ends of the spectrum. How long is too long, when it comes to rendering, for a filter to be accepted in the library? | |||
| Posted: June 25, 2007 3:20 pm | ||||
|
Vladimir Golovin
Administrator |
We usually don't reject filters based on their rendering time, except for filters with absurdly long rendering time which blocks our rendering queue. You can look at the filters included with Filter Forge to get the idea of acceptable rendering time. |
|||
| Posted: June 26, 2007 7:35 am | ||||
|
StevieJ
|
Carl had one rejected because of it.....I think it took 7 or 8 minutes to render..... Steve
"Buzzards gotta eat...same as worms..." - Clint :) |
|||
| Posted: June 26, 2007 11:58 am | ||||
| divi |
does extracting channels improve performance aswell? let's say you have a b/w noise and extract the lightness-channel and continue to perform whatever it is with that channel only - will this improve performance compared to using just the noiseoutput or is this approach useless because an empty hue and saturation channel dont cost performance anyway?
cheers |
|||
| Posted: June 15, 2009 9:46 am | ||||
Sphinx.
 |
No, you will simply be processing R = G = B after that. However if you have different grayscale sources that will be processed exactly the same way, you can assemble them into a composite source (e.g. Assemble RGB), do your processing and extract the channels when needed seperately. That might speed up things a little. Njyldgarkn sample cache! |
|||
| Posted: June 16, 2009 2:16 am | ||||
Carl
 |
Vlad is there a speed list for the new components, or can you update your first post - I seem to have taken a backward step with speed of V2 filters |
|||
| Posted: June 28, 2010 2:33 am | ||||
|
Vladimir Golovin
Administrator |
Sure, I'll update the post after the release. For now, here's the quick info:
- Everything in the RGB Math category is very fast. Derivative is a bit slower due to two samples per incoming sample. - All Transforms are very fast. - Polygon, Ellipse and Rectangle (and their Free counterparts) are generally fast. - Free Gradient is very fast, but the Relative Repeat continuation mode slows things down a bit. - Both Bombers are fast, but watch the Density parameter, larger values can slow things down. - Median/Minimum/Maximum can be slow on high Radius valyes, plus they're bitmap-based. - Speed of Map Script and Curve Script, obviously, depends on what you write there. Compared to native components, scripts are slower due to Lua interpretation/execution overhead. - HDRness doesn't make components slow, so new HDRized components should be as fast as their LDR counterparts and older versions. |
|||
| Posted: June 28, 2010 4:23 am | ||||
|
Carl
|
Thanks, that's a help, the Median/Minimum/Maximum is my problem I think then |
|||
| Posted: June 28, 2010 4:32 am | ||||
|
smoocherz
Posts: 6 |
Hello Vladimir, I have been a Filter Forge user for some time now and have created many wonderful images with its help. However the "Speed" issue is a major concern to me. Might I suggest that you either create a new category based on speed or simply add a rating to each filter with a 1 - 10 scale so people like myself can avoid the ones that are just too time consuming.
I have a Dell Precision T3400 with an Intel Core2 Duo CPU E4500 @ 2.20 Ghz, # GB Ram, 32 Bit Operating System, NVidia 8500 GT Video Card. I am open to getting a new PC that will be more effective and faster if y0ou can suggest any for a reasonable price. Thank You for your time. Regards, David Kessler |
|||
| Posted: January 11, 2011 7:48 am | ||||
|
Sphinx.
|
That is an excellent idea! I have a few comments/ideas for that. First of all, since rendering now takes place clientside, we have many different systems, so the rating should be normalized somehow. For that I suggest either a benchmark of the system that can be used as normalization factor, or a test rendering of a specific default filter that is used to measure the performance on a given system. This could be done the first time FF is installed or when the first filter is submitted. When a filter is submitted and the preset rendering starts, an average tile rendering time is calculated. This average time is normalized with system bench value from earlier. This should ensure a consistent measurement Njyldgarkn sample cache! |
|||
| Posted: January 11, 2011 10:46 am | ||||
inujima
 |
I had been thinking that I could raise filter speed by making component composition simpler. but it was a misunderstanding.
In the above example, outputs of A and B are same results. However, rendering time is greatly different. Rendering time of A is 13.01 seconds, but B is 1.48 seconds. I thought that the function of the offset component caches the value of a result temporarily, and if it would be called with same arguments at next time , the cached value is returned. But... 
In this example, rendering time of C is 4.30 seconds and D is 27.52 seconds. Perhaps, in this case, the function of C is called seven times by calling one time the function of D. However, like assumption of the previous example, if the function of the offset component has a cache, numbers of times of calling the function of C should be two. I have not understood well about this structure. 
One more example. In this example, added multiblend component which is same as C in the last example, and they are connected to each offset components. Although this looks inefficient, the rendering time of E is 9.31 seconds. It is 3 times faster than previous example. Method of Increasing a speed of filters seems so complicated more than I had thought.  |
|||
| Posted: February 14, 2012 5:31 pm | ||||
SpaceRay
 |
Very interesting inujima. thanks | |||
| Posted: February 14, 2012 5:59 pm | ||||
Morgantao
 |
Inujima, in the first example, what the heck makes B so much faster than A?
If anything I would imagine ading another component would SLOW everything down a bit, not make it almost 9 times FASTER  |
|||
| Posted: February 14, 2012 6:46 pm | ||||
|
SpaceRay
|
I know another way that it could help to increase the speed of filters, and this is that the FF developers team can make a new better and more optimized render engine for FF 4.0 and so all is supossed that would be faster. HINT HINT Do you listen FF Inc.? |
|||
| Posted: February 15, 2012 1:59 am | ||||
|
Morgantao
|
Probably not  |
|||
| Posted: February 15, 2012 3:53 am | ||||
|
Sphinx.
|
Looks like the sample cache mechanism is broken - I bet thats what the new 3.007 release is about.
Btw here is an informative discussion on the sample cache stuff.. Njyldgarkn sample cache! |
|||
| Posted: February 15, 2012 12:17 pm | ||||
|
inujima
|
The reason is that sample cache is working in B but is not working in A. All the components may have sample cache function as Vladimir wrote at above link, but it is working only in limited situation. The sample cache mechanism may be broken as Sphinx said, otherwise the system might have been changed. |
|||
| Posted: February 16, 2012 5:36 pm | ||||
|
SpaceRay
|
Regretably this has NOT been included in the 3.007 update, so we will have to wait until another update. |
|||
| Posted: February 21, 2012 10:41 am | ||||
|
SpaceRay
|
Good question, as how long is too long for waiting for a filter to render the result so the User does not have to "wait for the paint to dry" and I agree that we want to make the most efficient filter possible but for creative and innovative filters are many times complex and with lots of components, so it depends on the FF render engine speed to process all of them to offer the final result. Again with the question, How long is too long for you ? How much can you wait for a result you want and need ? |
|||
| Posted: February 27, 2012 1:13 am | ||||
|
Morgantao
|
Yep, there's no magic number on how long is too long. It totaly depends on the user and how much he wants the result a filter gives. | |||
| Posted: February 27, 2012 2:50 am | ||||
Join Our Community!
Filter Forge has a thriving, vibrant, knowledgeable user community. Feel free to join us and have fun!
15,377 Registered Users
+6 new last day!
112,622 Posts
+90 new in 7 days!
10,102 Topics
+16 new in 7 days!
Online Users Last 15 minutes:
13 unregistered users.
Recent Forum Posts:
- Toonstone by jitspoe by Skybase
3 hours ago - matching frame by simple but powerful by simple but powerful
yesterday - Need programmer for bomber by Betis
yesterday - Library Capability by IgnisSerpentus
2 days ago - Flame Painter by jitspoe
May 17, 2013 - FF ordering system is down. (UPD: Fixed) by GMM
May 16, 2013 - The Orange Head by Indigo Ray
May 16, 2013 - Photoshop CS6 - Interesting and useful information and free tutorials by scavot
May 16, 2013 - Free Simplifier Plugin (Win only) by CorvusCroax
May 15, 2013 - Paint HDRtist by lipebianc by SpaceRay
May 15, 2013 - Sketchy Painting by emme by SpaceRay
May 15, 2013 - Filter Forge 3 and PS CS6 extended 64 bit by GMM
May 15, 2013
Recent Wiki Edits:
- Indigo_
Ray by Indigo Ray
February 25, 2013 - Optimizing_
Filters_ by Crapadillafor_ Speed
February 22, 2013 - Feature_
Wishlist by Crapadilla
September 19, 2012 - Main_
Page by Crapadilla
September 19, 2012 - Filter_
Construction:_ by CrapadillaFundamental_ Techniques
September 19, 2012
