FF math: 30+1=163

Can someone please explain this to me?

I have a filter that takes 30 seconds on avarage to render an image. Let's call it Romancing the Gorrilla by Carl.
I take the resulting image and feed it as input to a socond filter, that takes around 1 second to render. Let's call this filter M_Shadows and Highlights by Morgantao

That took a total 31 seconds of render time, right?

So how it is that if I take the second filter AS IS and put it at the very end of the first filter, it takes 2 minutes and 43 seconds to render the exact same image??

I even added a switch so I can just turn my filter on/off inside of Carl's filter, and I get the exact same results... When the switch is set to pass through my filter, it takes alsmost 3 minutes, and with the switch set to bypass my filter it takes only 30 seconds.

What gives?!

Carl, is it ok with you if I upload the combined filter here?

I have tried it myself and have put your filter after the Switch component and is true that it is much slower after this and even more weird and strange is that if you put a switch to turn off your filter, THE TIME IS THE SAME

There something fishy in this mix of filters as this can´t be possible

I think there might be something like "too much" precision.

The Filter Forge algorithm seems to perform very poorly with long filter chains.
One reason might be to safe RAM, but there are times when it would clearly benefit from simply rendering each step in the chain and passing it on further down, instead of doing whatever it does. (Which has probably its advantages, too.)

Try linking several edge detection components and witness your system come to a grinding halt. Try running the same number of those edge detection components in parallel and it's no problem at all. For many cases that extra precision is not needed at all and there should be the possibility to switch to a more stupid/less precise/forward algorithm.

I imagine something like this happens:
A point of the last component needs 4 points of the second last component to be calculated.
Each of those 4 points needs 4 points of the third last component to be calculated
Each of those 4 points needs 4 points of the fourth last component to be calculated.
And so on.
Exponential growth, rendering frenzy, grinding halt.

While with a forward approach (with caching/setting back the precision after each step) the rendering time would increase more linearly. Each time it's the "same" four points that are used to render the next step, instead of a ever growing/finer mesh.

Both ways have their advantages so either the program or the filter author should be able to decide which way to go.

(I basically don't know what I'm talking about so bear with me )

Thinking about it, if the information about each pixel/point in each step is kept and the resolution stays the same down the chain there should be no difference. But even more RAM would be needed than building a cache for each step and flushing the older ones down the toilet. (Ok, you could render buckets either way like FF seems to do.)

But if you get finer and finer the deeper you go...

Nebukadnezar thanks for the theory and suggestion, well done

Good explained, fr om all of you have said I have a question

Does this mean that if FF could have more RAM would be faster and do not need to economy RAM ?

______________________________________________________

Could the Morgantao´s filter be put in another place than the end of Carl´s filter and this way would be faster ?

Although really I do not wh ere to put it because from the construction of Carl´s filter I think that you can´t put it before the last switch component

While Nebukadnezars observation about sample branching is a very important aspect to focus on regarding performance, I don't think that is the problem in this actual case:

The memory usage vs FF allocation restrictions seem to cause the bitmap buffers to get flushed (in blur, sharpen etc). I'm not sure about the details here. If this is correct, you should see a significant performance improvement at some point if you reduce the input image size (try e.g. 256x256 and see if the same strange performance penalties show up).

That is also why the blur buffer trick won't work (actually it will just use more mem.) - the reason you see a slightly increase in speed is most likely related to the anti alias process getting simplified by that blur..

Thanks Sphinx for the answer but I am sorry to say that I really do not have the enough knowledge about FF to understand your answer.

Morgantao, very well said, and totally agree with what you have put in your last post.

It would be really nice to have the opinion or any suggestion from FF inc. itself as they know really best how FF works and WHY this is happening and if there could be a good way to solve this if possible.

Well, I just tried testing with a 100x100 image, and pure gorilla takes around 8 seconds.
With my addition it's close to 40 seconds.

Do you still think it's just a memory thing?
Maybe there's anything else you could think of?

As the good Sphinx RAM theory could have been possible it seems that as Morgantao have showed it is not true, so does anybody else have another suggestion about WHY this is happening ?

We should call Sherlock Holmes to solve this mistery ?

I sure wish someone could test this out and see if he can find out what the problem is...

OK, I will try this as soon as GMM informs us that the ticket system is back online

Quote
SpaceRay wrote: you could contact the FF support and as ask to the experts at Filter Forge

I've already asked the developers to see into this.

I think we should zap the gorilla with a cattle prod a few times to see if it makes it work faster

I think this would interesting to be able to optimize filters more, because perhaps this is some kind of bug or unusual thing that happens only when combining certain components or mixing them and makes them very slow and could help to make them faster if it is discovered why this happens.

OK, here it is...
First, look at the top post, and get the 2 filters. Test them individualy, and see how long things take to render on each of the filters.

Then download the filter attached here, and test it. All it is, is Carl's gorilla filter, only with an option to have the result run through my shadow\highlight filter.
If you check the "++" option, you use my filter too. If you uncheck "++", you use Carl's filter as is.

Romancing the Gorrilla ++.ffxml

Anyone knows the phone or email of Sherlock Forger so he could investigate and know what is happening when you mix two filters and you may probably get unusually much higher render times?

I have seen that the same as it happens here, it can happen also with others combinations of filters that are good separate and when joined in one filter, the render time is much higher than the sum of the two.

To be able to detect and investigate and know ourselves what could be happening, I think that perhaps one way could be to have the ability to know the render times of each component in the filter editor as suggested very well by Betis in this thread --> Workspace Rendering Times

Another possible source of slowdown with merged filter trees is the evaluation of image information beyond output image boundaries. Blur and Noise Distortion are two examples of components that require a larger "input area" than their output.

By passing the intermediate result as a saved bitmap, these beyond-the-border calculations are replaced by a crude bitmap mirroring / tiling trick (because there's no other way to obtain beyond-the-bounds information from a bitmap), and this trick is extremely fast.

Please, anyone else is also having any possible misterious problems and the render time rises very much after combining fast components or mixing two filters?

Quote
Sharandra Ray, there is an entire article on that topic in the Wiki. I suggest you go read that

Sorry Sharandra that I did not know, please could you be so kind to tell me which article of the wiki are you refering to?

Thanks