linux - Fiji(ImageJ) 加载时间太长(在 Linux 上)，以及冗长的错误消息

Question

我在 Linux 上(在虚拟机内)从命令行使用 Fiji。 具体来说，我有一个调用许多 fiji 宏的 python 脚本。 fiji 每次加载都需要大约一分钟，这使它成为流程的瓶颈并大大减慢了我的速度。

我想知道这是否正常。斐济可以加载得更快吗？ Fiji 在调用时也会输出一条冗长的错误信息。不知道是不是跟加载时间长有关。

我用来调用它的命令(举例)

//shared_directory/projects/Fiji.app/ImageJ-linux64 --headless 
-macro //shared_directory/projects/retracted/fiji_scripts/patch_cropper.txt

错误信息如下

java.awt.HeadlessException
        at java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:204)
        at java.awt.Window.<init>(Window.java:536)
        at java.awt.Frame.<init>(Frame.java:420)
        at ij.plugin.frame.PlugInFrame.<init>(PlugInFrame.java:13)
        at ij.plugin.frame.RoiManager.<init>(RoiManager.java:94)
        at ij.macro.Interpreter.getBatchModeRoiManager(Interpreter.java:1875)
        at ij.plugin.frame.RoiManager.getInstance(RoiManager.java:1795)
        at ij.ImagePlus.deleteRoi(ImagePlus.java:1735)
        at ij.ImagePlus.close(ImagePlus.java:391)
        at ij.plugin.Commands.closeImage(Commands.java:136)
        at ij.plugin.Commands.close(Commands.java:83)
        at ij.plugin.Commands.run(Commands.java:29)
        at ij.IJ.runPlugIn(IJ.java:187)
        at ij.Executer.runCommand(Executer.java:137)
        at ij.Executer.run(Executer.java:66)
        at ij.IJ.run(IJ.java:297)
        at ij.IJ.run(IJ.java:272)
        at ij.macro.Functions.doRun(Functions.java:603)
        at ij.macro.Functions.doFunction(Functions.java:96)
        at ij.macro.Interpreter.doStatement(Interpreter.java:230)
        at ij.macro.Interpreter.doStatements(Interpreter.java:218)
        at ij.macro.Interpreter.run(Interpreter.java:115)
        at ij.macro.Interpreter.run(Interpreter.java:85)
        at ij.macro.Interpreter.run(Interpreter.java:96)
        at ij.plugin.Macro_Runner.runMacro(Macro_Runner.java:155)
        at ij.plugin.Macro_Runner.runMacroFile(Macro_Runner.java:139)
        at ij.IJ.runMacroFile(IJ.java:148)
        at net.imagej.legacy.IJ1Helper$4.call(IJ1Helper.java:1056)
        at net.imagej.legacy.IJ1Helper$4.call(IJ1Helper.java:1052)
        at net.imagej.legacy.IJ1Helper.runMacroFriendly(IJ1Helper.java:986)
        at net.imagej.legacy.IJ1Helper.runMacroFile(IJ1Helper.java:1052)
        at net.imagej.legacy.LegacyCommandline$Macro.handle(LegacyCommandline.java:188)
        at org.scijava.console.DefaultConsoleService.processArgs(DefaultConsoleService.java:102)
        at net.imagej.legacy.LegacyConsoleService.processArgs(LegacyConsoleService.java:81)
        at org.scijava.AbstractGateway.launch(AbstractGateway.java:95)
        at net.imagej.Main.launch(Main.java:62)
        at net.imagej.Main.main(Main.java:68)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:497)
        at net.imagej.launcher.ClassLauncher.launch(ClassLauncher.java:279)
        at net.imagej.launcher.ClassLauncher.run(ClassLauncher.java:186)
        at net.imagej.launcher.ClassLauncher.main(ClassLauncher.java:77)

Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=128m; support was removed in 8.0
Java HotSpot(TM) 64-Bit Server VM warning: Using incremental CMS is deprecated and will likely be removed in a future release
java.lang.IllegalArgumentException: Cannot handle app name in ij.gui.YesNoCancelDialog's public <init>(java.awt.Frame parent, java.lang.String title, java.lang.String msg)
        at net.imagej.patcher.CodeHacker.replaceAppNameInCall(CodeHacker.java:446)
        at net.imagej.patcher.LegacyExtensions.insertAppNameHooks(LegacyExtensions.java:419)
        at net.imagej.patcher.LegacyExtensions.injectHooks(LegacyExtensions.java:291)
        at net.imagej.patcher.LegacyInjector.inject(LegacyInjector.java:308)
        at net.imagej.patcher.LegacyInjector.injectHooks(LegacyInjector.java:109)
        at net.imagej.patcher.LegacyEnvironment.initialize(LegacyEnvironment.java:101)
        at net.imagej.patcher.LegacyEnvironment.applyPatches(LegacyEnvironment.java:495)
        at net.imagej.patcher.LegacyInjector.preinit(LegacyInjector.java:397)
        at net.imagej.patcher.LegacyInjector.preinit(LegacyInjector.java:376)
        at net.imagej.legacy.LegacyService.<clinit>(LegacyService.java:134)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
        at java.lang.Class.newInstance(Class.java:442)
        at org.scijava.service.ServiceHelper.createServiceRecursively(ServiceHelper.java:302)
        at org.scijava.service.ServiceHelper.createExactService(ServiceHelper.java:269)
        at org.scijava.service.ServiceHelper.loadService(ServiceHelper.java:231)
        at org.scijava.service.ServiceHelper.createServiceRecursively(ServiceHelper.java:340)
        at org.scijava.service.ServiceHelper.createExactService(ServiceHelper.java:269)
        at org.scijava.service.ServiceHelper.loadService(ServiceHelper.java:231)
        at org.scijava.service.ServiceHelper.loadService(ServiceHelper.java:194)
        at org.scijava.service.ServiceHelper.loadServices(ServiceHelper.java:166)
        at org.scijava.Context.<init>(Context.java:278)
        at org.scijava.Context.<init>(Context.java:234)
        at org.scijava.Context.<init>(Context.java:174)
        at org.scijava.Context.<init>(Context.java:160)
        at net.imagej.ImageJ.<init>(ImageJ.java:77)
        at net.imagej.Main.launch(Main.java:61)
        at net.imagej.Main.main(Main.java:68)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:497)
        at net.imagej.launcher.ClassLauncher.launch(ClassLauncher.java:279)
        at net.imagej.launcher.ClassLauncher.run(ClassLauncher.java:186)
        at net.imagej.launcher.ClassLauncher.main(ClassLauncher.java:77)
Caused by: javassist.CannotCompileException: No code replaced!
        at net.imagej.patcher.CodeHacker$EagerExprEditor.instrument(CodeHacker.java:1280)
        at net.imagej.patcher.CodeHacker.replaceAppNameInCall(CodeHacker.java:443)
        ... 36 more

谢谢!

Answer 1

I wonder if this is normal. Could fiji perhaps be made to load more quickly?

我认为这不是预期的行为。由于此问题是 ImageJ/Fiji 特有的，您最好在 ImageJ forum 上提出这一点.

java.lang.IllegalArgumentException: Cannot handle app name in ij.gui.YesNoCancelDialog's public <init>(java.awt.Frame parent, java.lang.String title, java.lang.String msg)

这可能是由于 ij1-patcher不处理 ij.gui.YesNoCancelDialog使其独立于 Java AWT 框架(这干扰了 headless 运行的目标)。

欢迎您提交补丁到 ij1-patcher project让它处理YesNoCancelDialog与目前对 GenericDialog 的处理方式类似, 请参阅 these lines .

作为解决方法，只需使用不使用 YesNoCancelDialog 的宏即可，即不运行 getBoolean() macro function .

编辑:正如 ImageJ forum topic 中所述，已提交补丁 here .

在合并和发布之前，您可以通过使用Help > Update ImageJ... 降级 ij.jar 来解决此问题