FF is MUCH faster rendering result when used as plugin than standalone

I have discovered one very interesting and useful thing, and that it seems that if you are using Filter Forge (FF) as a plugin of a host software it will be faster or much faster than if you use the standalone version, depending on the filter you use, on some filters the difference could be lower than with others.

To have a proof of this and so you can test and reproduce it yourself in your computer I have made the following test using the Comic Rocks by BrianDP1977 and using Filter Forge 3.014

Using preset 1 and with a resolution of 3000x3000

Comic Rocks Reduced Preview 600x600 = ..4,78 seconds
Comic Rocks Actual Size Preview ...............39,29 seconds
Comic Rocks Saving as a TIFF 8 bit file.......42,01 seconds
Comic Rocks Apply filter in Photoshop ....16,05 seconds

__________________________________
__________________________________

Second test that you can make too, is with the following filter
Lotus patterns by Tim2501

Using preset 1 and with a resolution of 3000x3000

Lotus patterns Reduced Preview 600x600 =.. 13,80 seconds
Lotus patterns Actual Size Preview ...............3,12 minutes
Lotus patterns Saving as a TIFF 8 bit file ......3,22 minutes
Lotus patterns Apply filter in Photoshop...2,39 minutes

__________________________________
__________________________________

Third test that you can make too, is with the following filter
Gradient Circles by Skybase

Using preset 1 and with a resolution of 3000x3000

Gradient Circles Reduced Preview 600x600 =.. 1,52 seconds
Gradient Circles Actual Size Preview ...............13,65 seconds
Gradient Circles Saving as a TIFF 8 bit file ......15,02 seconds
Gradient Circles Apply filter in Photoshop.....8,20 seconds

__________________________________
__________________________________

I have choosen 3 filters that do not depend on any external image, so you can test yourself with your computer and see it on your side too.

To make the Photoshop version, just go to menu File --> New and choose then choose width 3000 height 3000 and then go to Filter-->Filter Forge --> Filter Forge 3 and when finished hit apply button

The first two times are measured by Filter Forge own clock, the other two has been done the measure using OnlyStopWatch free software

When it is put "Saving as TIFF" it means that in the FF software I went to "File--> Save As"

All have been with the default settings of Antialiasing and everything else, just loading the filter without changing any setting.

I have done other 4 tests to make sure that this is true, and in all of them applying the filter through the plugin version instead of saving it from FF is MUCH faster when rendering.

I will make more tests and take the time to be more sure about this, you could make your own tests too.

It's one of those things that's not as noticeable. I just use standalone because it makes my life easier but other than the differences are indistinguishable if you use it naturally.

Speaking of which, preview resolutions don't really matter in this test case. Point being what really matters is the final resolution at 3000x3000 which is what gets applied and transferred over to Photoshop!

Wonder if this has to do with the fact that preview is disabled as the render happens. Also bonus fact: some image formats take longer to save than others. Depends on the nature of the format and how information is stored and how large the data size is.

I have to say that for making the above test I have done I repeated it 3 times to make sure that the result were true and the was not something wrong in them.

Quote
Sharandra For me the rendertimes in the standalone and Photoshop are the same I tested it on some 4096x4096 Textures and render times were exactly the same.

Please, Skybase and Sharandra, have you tried to reproduce the same test above with same resolution and same filters?

Don´t you get a similar difference in speed between saving the image fr om FF standalone than the speed of applying the same filter to the image in the host software as a plugin?

I have already tested about 20 filters, and the results are different, and on some the difference is little, and others is high, it depends on what filter you use, but always the plugin version is faster.

Comic Rocks Saving as a TIFF 8 bit file.......42,01 seconds
Comic Rocks Apply filter in Photoshop ....16,05 seconds

For me having this result showing that if you just apply the result in Photoshop it takes just and only 16 seconds compared to 42 seconds that takes to render exactly the same thing when using as standalone, so is less than half the time and something really very noticeable, as it not because it takes more time to save, because this is the reason I have put the Actual Preview time that does save anything and the time is the same.

Quote
Skybase It's one of those things that's not as noticeable. I just use standalone because it makes my life easier but other than the differences are indistinguishable if you use it naturally.

I am sorry but I do not understand, what thing is not as noticeable?
What differences are indistinguishable if you use it naturally?
What means to use it "naturally"

If you mean that the difference in render times are not noticeable and indistinguishable, how is possible that as said above, on Comic Rocks it takes 42 seconds to render in standalone and 16 seconds if you use it as a plugin?

Quote
Skybase Speaking of which, preview resolutions don't really matter in this test case. Point being what really matters is the final resolution at 3000x3000 which is what gets applied and transferred over to Photoshop!

I agree that the preview resolution don´t really matters but is also a measure to test the same render result without FF saving the image, so is the raw time FF takes to render the filter result at the Actual resolution size.

Quote
Skybase Wonder if this has to do with the fact that preview is disabled as the render happens.

Good one, I did not thought it this way and could be something important and worth to consider

Quote
Skybase Also bonus fact: some image formats take longer to save than others.

Considering that in the FF render time when saving as you say very well is included also the time it takes to save I decided to include the raw time FF takes to render using the actual preview wh ere there is no saving time including.

I typically use FilterForge, I don't "test" as often so it's not like I get much say on it.

But there are things in the data we can look at, for example as you so lovingly point-out:

Comic Rocks Saving as a TIFF 8 bit file.......42,01 seconds
Comic Rocks Apply filter in Photoshop ....16,05 seconds

I really don't know how you managed that. In any case, I hypothesized that render times between FilterForge standalone and plugin should be synchronous with render durations with variance between times to some acceptable degree (0 to 10 seconds). Guess I'd be engaging in observation bias. But in either case 40 seconds is quite drastic of a difference between the two version uses.

All I can say is "I'm glad you got nicer render times" really. I don't know anything more.

Well you´re not comparing just the render times, but the time it takes to apply and save aswell. so yeah, maybe saving to tiff or whatever you´re using is faster in PS than in the standalone. I compared just render times and they are the same in both.

And no, I´m on a Windows PC.

I have run the test without any other program running at the same time and fr om a fresh start, so this way reduces the possible interferences with other things and avoid a fragmented RAM.

Quote
Sharandra How did you test it? I set preview to actual size and let it render both in PS and the standalone and the render times wh ere exactly the same. Just pure render times, no saving or anything.

Sorry I have understood it wrong the first time and did not know right what did you mean, now I got it.

The render time both in FF as standalone and in FF as a plugin setting using just and only the preview INSIDE FF software will give nearly exactly times because is exactly the same program, I mean that as far as I know, there is no two different software (one standalone and one plugin) as both are the same one, and the only difference is how is activated and started.

I think that the plugin is the same as the standalone software and the only difference is that it is activated and triggered by the plugin inside the host that calls the FF software instead of you open it and it takes the source from the host instead of you loading one, but as said, both are the same, so it can´t have different times if you ONLY use the FF for preview, because it is the same program

So the only way to test it is to see how much time do you take the render result, either by saving it through the FF software or applying the filter result to the image in the host software.

I had put the preview times only as reference.

Quote
Skybase I trust you on what you post SpaceRay. Here are several other suggestions to make numbers here more scientifically presentable:

Thanks for giving possible things that could affect and make this perhaps possible and different depending on wich computer you have and the many possible variable conditions.

Quote
Skybase Keep measurement methods consistent. FF's internal clock might be understanding when a render begins and ends differently fr om what you interpret as beginning and end. I suggest you just use the same stopwatch and measure it manually.

I have not told it before, but the first thing I have done on the first test was to see if I could trust in the FF internal clock and measurement, and so I made 4 tests using OnlyStopWatch at the same time as the FF internal time clock, and it works OK and can be trusted as it gives real time.

Quote
Also, from the video I noticed you enabled multi-pass preview. Disable it and give the render a shot from standalone edition. Multi-pass preview was intended for previewing as the name suggests. It's there for interactivity, but it apparently bites into some of the render time as well.

Yes, I have activated the multi-pass preview. I will disable it and try again.