2017-03-27 1 views
1

나는 명령 행에서 (가상 머신 내부의) 피지를 사용하고 있습니다. 특히 많은 피지 매크로를 호출하는 python 스크립트가 있습니다. 피지가로드 될 때마다 약 1 분이 걸리므로 프로세스의 병목 현상을 일으키고 상당히 느려집니다.피지 (ImageJ)가 오랜 시간 (Linux에서)로드하는 데 오랜 시간이 걸리며 오랜 오류 메시지가 표시됩니다.

이것이 정상적인 것인지 궁금합니다. 피지가 더 빨리로드 될 수 있습니까? Fiji는 호출시 긴 오류 메시지도 출력합니다. 그것이로드하는 데 걸리는 오랜 시간과 관련이 있는지 궁금합니다.

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 

감사를 다음과 같이

I (예를 들어)를 호출하는 데 사용하는 명령

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

오류 메시지입니다!

답변

2

이것이 정상적인 것인지 궁금합니다. 피지가 아마도 더 빨리 적재 될 수 있습니까?

나는 이것이 의도 된 행동이라고 생각하지 않습니다. 이 문제는 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에 (머리가없는 일을 실행하는 목표를 방해하는) 자바 AWT 프레임 워크에 독립적 인 상태로 만들 ij.gui.YesNoCancelDialog을 처리하지. , these lines를 참조

귀하는 현재 GenericDialog와 마찬가지로이 비슷한 방법으로 YesNoCancelDialog 처리 만들기 위해 ij1-patcher project에 패치를 제출하실 수 있습니다.

YesNoCancelDialog을 사용하지 않는 매크로를 사용하십시오 (즉, getBoolean() macro function을 실행하지 않음).

편집 : 또한 ImageJ forum topic에 표시된대로 here 패치를 제출하십시오. 이 합병 발표 때까지

, 당신은 도움말> 업데이트 ImageJ에 ...

+0

감사를 사용 ij.jar 다운 그레이드하여이 문제를 해결할 수 있습니다. 해결 방법을 모르겠다는 두려움이 있습니다. 필자는 매크로를 작성해 봤고 (최선을 다해서) 매크로에 'YesNoCancelDialog'를 사용하지 않았습니다. 실제로 매크로를 호출하지 않고도이 오류가 발생합니다. '//shared_directory/projects/Fiji.app/ImageJ-linux64 --headless -macro' – user2182857

+1

[ImageJ 포럼에 같은 질문] (http : //forum.imagej.net/t/fiji-imagej-takes-to-long-to-load-on-linux-together-with-a-lengthy-error-message/4628?u=imagejan) 이제 계속하겠습니다. 저기서의 토론. –

관련 문제