Error when running ScientiFig on windows 10

scientifig
Tags: #<Tag:0x00007fa2ffd46738>

#1

Hey, so Im trying to run ScientiFig on windows 10 and I get the following message:

(Fiji Is Just) ImageJ 2.0.0-rc-68/1.52d; Java 1.8.0_172 [64-bit]; Windows 10 10.0; 73MB of 12134MB (<1%)
 
java.lang.NoClassDefFoundError: Could not initialize class GUIs.ScientiFig
	at SF_ext_lancher.SF_ext_lancher.run(SF_ext_lancher.java:228)
	at ij.IJ.runUserPlugIn(IJ.java:228)
	at ij.IJ.runPlugIn(IJ.java:192)
	at ij.Executer.runCommand(Executer.java:137)
	at ij.Executer.run(Executer.java:66)
	at java.lang.Thread.run(Thread.java:748)

I found a similar post describing some problems with this plugin and it says there that this was an issue with Java 8, so I have downloaded the latest version of Fiji (which is supposed to be bundled with Java 8) and Ive made sure that the Java 8 plugin is enabled, but I still get this error message…

Any ideas of how I can solve this problem?


#2

Unfortunately, the source code repository at https://github.com/baigouy/ScientiFig (last updated Oct 2017) and the contents of the update site (last updated June 11, 2018) are not in sync, so it’s hard to find out what might be going wrong here.

I’ll mention @baigouy, the author of this plugin, maybe he can provide more insight.


#3

Hi,

@mava @imagejan, sorry for the inconvenience. I was able to reproduce the error on Windows 7, I really don’t know what happened, I guess there must have been a mismatch between the launcher (that checks the Batik version shipping with FIJI) and the associated ScientiFig plugin. I just re-updated both and it now works (I mean ScientiFig launches fine). Please note however that ScientiFig is NOT FUNCTIONAL YET (since the last FIJI update). This is because some of the batik libraries used by SF are no longer shipping with FIJI (i.e. batik-codec and batik-transcoder, making the batik library incomplete).

@imagejan Without these libraries FIJI (and my soft) cannot open SVG files that contain Base64 embedded PNGs (here is an example of SVG that used to open fine with FIJI and cannot be read since the last update base64 SVG. I have to see with you what is the best way to proceed now, but first: is the suppression of two of the batik jars intended or just an error ? If it’s intended, I guess I should upload them with my software ? If I upload them, where do you recommend to place them ? In the ScientiFig plugin directory or in the FIJI “jars” directory where all the other Batik libraries belong ? Sorry Jan, for not updating the site, I just forgot (again), but that would not have changed much this time. I have started mavenizing the project for a better integration with another project of mine and this caused a lot of changes and issues, then when I finally got things working I forgot to file an update on github, I’ll do that soon.

@mava @imagejan Once the batik issue is sorted out, I can file an update and ScientiFig will be fully functional again.

@mava, please note that ScientiFig is deprecated, I have finalized another software (that is backwards compatible with ScientiFig) that still relies on the ScientiFig core but is much more user intuitive, better documented and more powerful (it supports among other things image stacks, channels, free placing of images, …). This software is called “EzFig” and it also has its own FIJI update site. I strongly recommend using this tool rather than ScientiFig if you are starting a new series of figures or if you have some free time. This is also an open source project and I’ll create a github page for it when I have time.


#4

I don’t know.

But what I can see from the file listings on the Fiji and Java-8 update sites, they used to ship a single batik “Fat JAR” until about 2016, when the single file was replaced by its individual components. Maybe the two components you mention – batik-codec and batik-transcoder – happened to be part of the fat Jar, but no other Fiji component used them, so they got removed when Fiji switched to shipping component Jars.

Yes. If you defined the dependencies properly in your pom.xml, then running:

mvn -Dimagej.app.directory=/path/to/your/ImageJ.app

will automatically copy the required jars into ./jars/, and you can upload them to your update site.

There are many advantages of having an up-to-date source repository online:

  • It’s a good backup for your local code repositories
  • The community can contribute bug fixes and improvements directly, working with the latest version of your code
  • You can implement continuous integration, e.g. with Travis, making sure your plugin always works well with the current version of other ImageJ components (and again, people in the community can help you setting this up)

I hope you see the benefits and don’t think of updating the github repo as a burden :slight_smile:

Thanks for this useful information. I suggest you also add a sentence mentioning this on your plugin page, or (even better) add new pages to the ImageJ wiki describing both ScientiFig and EzFig.


#5

They were still shipping with FIJI even after the fat jar was removed, then they were shipped but with a version mismatch i.e. all batik libraries were 1.91 except for the transcoder or codec (I don’t remember) that remained at version 1.9 (even though version 1.91 existed) then most recently when batik 1.10 came out (one or two days ago) the transcoder and codec were removed.

Thanks for the tip. I’ll do that.

I guess I’m still a bit old fashioned… I’ll have a look at this when I find the time, but thanks again for the tip

True, good point I’ll do that when I have some spare time. I guess I will delete the plugin page as it’s totally outdated and not easy to maintain now that I have moved to a new place.


#6

@mava @imagejan the issues with the software should now be fixed. Please let me know otherwise.

Best,

Benoit


#7

@baigouy @imagejan thank you very much for all your help, it is now working perfectly and thanks for the tip about EzFig, i will take a look at that as well :slight_smile: