Fiji Debayer Image Plugin Issues

Hi,

I have a macro that opens a raw image, debayers it using the debayer image plugin, and saves it as a tiff. This process loops through each raw image in the directory indicated by the user. This macro works fine for the first 15 images or so, but after that I start to notice a substantial slow down on the debayer process. Around the 19th image, it takes ~10 minutes, where it usually took <1 minute for the first couple of images.

Another strange issue is sometimes I get a “RGB Stack window not found”. This issue arises from the selectWindow(“RGB Stack”) command. It seems as if the debayer image plugin does not output anything sometimes, so Fiji cannot find that window.

My questions are:
Why is there a massive slow down in the debayer image plugin if I’m passing an image to processes one-by-one?
Why does the debayer image plugin sometimes not output anything?

I suspect that the performance issue is due to the debayer image plugin chewing up memory. To counter this, I have placed these commands after the tiff is saved for each image:

run(“Close All”);
run(“Collect Garbage”);
call(“java.lang.System.gc”);
wait(1000);

However, this has done nothing to improve performance of the debayer plugin. I’ve even set the batch mode to true to no avail. Any image that is not being used anymore is closed immediately using the selectWindow() and close() combo; this should be freeing up resources.

Is this an issue with the debayer image plugin? Anyone run into these issues that might know how to improve the performance and reliability of the debayer image plugin?

Thanks.

Do you mean this plugin: http://www.umanitoba.ca/faculties/science/astronomy/jwest/plugins.html ?

I would contact the author of the plugin/macro to inform him/her about the problem.

It seems to be a memory (Java heap) issue.

Try to debug the plugin:

Or easily watch the memory for a start: Plugins->Utilities->Monitor Memory…

Another way is to investigate all kind off runtime errors with the VisualVM tool, which is shipped with the Java JDK:

https://visualvm.java.net/

Hi Bio17, thanks for the help. As you suspected, it is indeed a Java heap issue. Although, I don’t think it might be the plugin’s fault - after the plugin executes, some memory is released. I think the issue is that each time the plugin is executed it is compiled and saved in memory. Over iteration, more and more memory is used to store the compiled plugin.

Running fiji and the macro in headless mode gave me this output:

Compiling 1 file in /tmp/java6010447655137072085
Compiling 1 file in /tmp/java308156255833733739
Compiling 1 file in /tmp/java1996511508170296961
Compiling 1 file in /tmp/java4720595968417521038
Compiling 1 file in /tmp/java1451847254792873250
Compiling 1 file in /tmp/java2822784073869613168
Compiling 1 file in /tmp/java2526717088727972140
Compiling 1 file in /tmp/java7023556944130342314
Compiling 1 file in /tmp/java3147796988061766632
Compiling 1 file in /tmp/java5962760357399805525
Compiling 1 file in /tmp/java7335001137750370530
Compiling 1 file in /tmp/java7064286602109125190
Compiling 1 file in /tmp/java1531354356098908655
Compiling 1 file in /tmp/java3787863956643139495
Compiling 1 file in /tmp/java5178398309702647260
Compiling 1 file in /tmp/java924600738582818365
Compiling 1 file in /tmp/java5916758196364759730
java.lang.OutOfMemoryError: Java heap space
at ij.process.ShortProcessor.(ShortProcessor.java:31)
at Debayer_Image.replicate_decode(Debayer_Image.java:105)
at Debayer_Image.run(Debayer_Image.java:80)
at ij.plugin.filter.PlugInFilterRunner.processOneImage(PlugInFilterRunner.java:262)
at ij.plugin.filter.PlugInFilterRunner.(PlugInFilterRunner.java:111)
at net.imagej.legacy.IJ1Helper.run(IJ1Helper.java:543)
at net.imagej.legacy.LegacyJavaRunner.run(LegacyJavaRunner.java:54)
at org.scijava.plugins.scripting.java.DefaultJavaService.run(DefaultJavaService.java:61)
at org.scijava.plugins.scripting.java.JavaEngine.eval(JavaEngine.java:178)
at org.scijava.script.ScriptModule.run(ScriptModule.java:174)
at org.scijava.module.ModuleRunner.run(ModuleRunner.java:167)
at org.scijava.module.ModuleRunner.call(ModuleRunner.java:126)
at org.scijava.module.ModuleRunner.call(ModuleRunner.java:65)
at org.scijava.thread.DefaultThreadService$2.call(DefaultThreadService.java:164)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)

I’m not entirely familiar with the inner workings of ImageJ, but is there a way to compile a plugin once (or not at all) and keep using that compiled plugin instead of having to compile it each time to use it? I am using this command to execute the Debayer Image plugin:

run(“Debayer Image”, “order=R-G-R-G demosaicing=Replication radius=2 radius=2”);

This should be the default. I wonder that the plugin is compiled each time you call it from a macro.

In the *.zip file the *.class file (compiled java) has to added to the plugins folder of ImageJ.

See: http://imagej.net/Installing_3rd_party_plugins

It turns out that the plugin folder had both the *.class and *.java files. I believe Fiji was detecting the .java file first and compiling it each time. I removed the .java file from the plugins folder and Fiji does not compile the plugin anymore. The macro works flawlessly now. Thanks for all your help Bio7!

1 Like