ImageJ

Potential updates to ImageJ + a question

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

21 messages Options

haider

Potential updates to ImageJ + a question

Hello

I just finished writing a plugin for ImageJ and I observed a few things that I thought could be changed. I wrote my project in Jython primarily (but there is one Java class that calls native code). The first point is that the default python version used by ImageJ is old and does not allow the use of “with” statements. I overcame this by using try and finally but unless there is good reason like backward compatibility, I think the python used by ImageJ should allow the use of with statements to make things easier. Also, I had to use the source and target options for javac to compile my classes to an older version of java but I assume the older version is used for compatibility reasons.

Another problem is that I am unable to import the “os” module in python. I wanted to use the os module to modify the python class path because as it currently stands, the installation process (for our plugin) requires placing different folders in too many different places. I have a “.dat” file that I have to place in the main ImageJ folder (alongside luts, macros, plugins). I would like to put this in the folder along with my python scripts. I also have a couple of jar files as dependencies (the ones that call the C code) in the jar folder and the shared library for the C outside in the plunge folder. Is there a way to play with the paths to organize these folders as such so that users have to put these files in a minus number of places.

Thank you
Haider
--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

John Minter

Re: Potential updates to ImageJ + a question

As noted here http://fiji.sc/Jython_Scripting Jython scripting currently
implements Python 2.5. To change this would require development upstream of
Fiji/ImageJ.

If you want to use os, there is a trick you can use. Package your functions
into a python file (e.g. myLib.py) and place it in the $FIJI_ROOT/jars/Lib
directory. You will have to create Lib. Then from any Jython script you can
import myLib and call myLib.myFunction(). Your jars can be in the usual
places...

Best regards,
John

On Sat, Feb 14, 2015 at 6:41 AM, haider riaz <[hidden email]>
wrote:

> Hello
>
> I just finished writing a plugin for ImageJ and I observed a few things
> that I thought could be changed. I wrote my project in Jython primarily
> (but there is one Java class that calls native code). The first point is
> that the default python version used by ImageJ is old and does not allow
> the use of "with" statements. I overcame this by using try and finally but
> unless there is good reason like backward compatibility, I think the python
> used by ImageJ should allow the use of with statements to make things
> easier. Also, I had to use the source and target options for javac to
> compile my classes to an older version of java but I assume the older
> version is used for compatibility reasons.
>
> Another problem is that I am unable to import the "os" module in python.
> I wanted to use the os module to modify the python class path because as it
> currently stands, the installation process (for our plugin) requires
> placing different folders in too many different places. I have a ".dat"
> file that I have to place in the main ImageJ folder (alongside luts,
> macros, plugins). I would like to put this in the folder along with my
> python scripts. I also have a couple of jar files as dependencies (the ones
> that call the C code) in the jar folder and the shared library for the C
> outside in the plunge folder. Is there a way to play with the paths to
> organize these folders as such so that users have to put these files in a
> minus number of places.
>
>
> Thank you
> Haider
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

Peter Haub

Problems executing Fiji plugins in ImageJ

Dear list,

I thought that Fiji is just ImageJ.
It seems as if there are slight differences in the way plugins (packed
in jar archives) are treated.
Maybe someone can point to a place where I can find some information
regarding the necessary structure of plugin jar archives - for ImageJ
and for Fiji.

My problem:
I would like to use a Fiji plugin in an ImageJ installation (Stitching
plugin, S. Preibisch).
The plugin is encapsulated in a jar archive.
The main classes to be accessed as plugin are located in a subdirectory
(\pluin) inside the jar file.
The classes are made available to Fiji/ImageJ by a plugin.config file.
I can run this (jar packed) plugin in Fiji without problems.
In ImageJ the plugin command is available and the plugin user interface
(UI) can be started. But when the UI is closed with OK an error is shown:
Plugin or class not found: "Stitching Grid"
(java.lang.ClassNotFoundException: Stitching_Grid)

There is no conflict with additional libraries or wrong configurations.

If I recompile the source code by placing the relevant class files in
the default package instead of the plugin package the relevant class
files are located in the root of the jar archive. This recompiled plugin
packed as jar archive can be executed without error message in ImageJ.

My questions are:
Is there a difference in the handling of plugin jar archives in ImageJ
and Fiji?
Should it be possible to us plugin jar archives from Fiji without
changes in ImageJ?
Do I miss something in my specific case?
Or do I have to recompile the classes in the way described above?

A personal comment:
These kinds of differences of complex dependencies are confusing and are
challenging the close connection of the two project streams.

I would be happy for any hint.

Regards
Peter

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

Peter Haub

Re: Problems executing Fiji plugins in ImageJ

Hi,
I have to correct my statement.

After writing a SSCCE I found that ImageJ and Fiji both do access
plugins located in subdirectories of jar archives in the same way.

After all - my problem arises because of missing libraries when using
the original plugin jar in ImageJ.

The message
Plugin or class not found: "Stitching Grid"
(java.lang.ClassNotFoundException: Stitching_Grid)
was misleading.
There is no problem in the class file and no problem in the class
handling in ImageJ/Fiji.

The question I still have is if plugins written in the Fiji environment
are thought to be (easily) available as ImageJ plugins too or if -
because of the complex library dependencies - this compatibility is
achievable only with time and expert knowhow?

Regards,
Peter

On 14.02.2015 21:13, Peter Haub wrote:

> Dear list,
>
> I thought that Fiji is just ImageJ.
> It seems as if there are slight differences in the way plugins (packed
> in jar archives) are treated.
> Maybe someone can point to a place where I can find some information
> regarding the necessary structure of plugin jar archives - for ImageJ
> and for Fiji.
>
> My problem:
> I would like to use a Fiji plugin in an ImageJ installation (Stitching
> plugin, S. Preibisch).
> The plugin is encapsulated in a jar archive.
> The main classes to be accessed as plugin are located in a
> subdirectory (\pluin) inside the jar file.
> The classes are made available to Fiji/ImageJ by a plugin.config file.
> I can run this (jar packed) plugin in Fiji without problems.
> In ImageJ the plugin command is available and the plugin user
> interface (UI) can be started. But when the UI is closed with OK an
> error is shown:
> Plugin or class not found: "Stitching Grid"
> (java.lang.ClassNotFoundException: Stitching_Grid)
>
> There is no conflict with additional libraries or wrong configurations.
>
> If I recompile the source code by placing the relevant class files in
> the default package instead of the plugin package the relevant class
> files are located in the root of the jar archive. This recompiled
> plugin packed as jar archive can be executed without error message in
> ImageJ.
>
> My questions are:
> Is there a difference in the handling of plugin jar archives in ImageJ
> and Fiji?
> Should it be possible to us plugin jar archives from Fiji without
> changes in ImageJ?
> Do I miss something in my specific case?
> Or do I have to recompile the classes in the way described above?
>
> A personal comment:
> These kinds of differences of complex dependencies are confusing and
> are challenging the close connection of the two project streams.
>
> I would be happy for any hint.
>
> Regards
> Peter
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

Niko Ehrenfeuchter

Re: Potential updates to ImageJ + a question

In reply to this post by John Minter

Hi,

On 14.02.2015 15:02, John Minter wrote:
> As noted here http://fiji.sc/Jython_Scripting Jython scripting currently
> implements Python 2.5. To change this would require development upstream of
> Fiji/ImageJ.

this is true, but mostly for the reason that the latest officially
"stable" release of Jython is 2.5, see http://www.jython.org/ for details.

If you want a 2.7 version of Jython within Fiji (which I do), you can
simply enable my update site "IMCF Uni Basel" (see [1] for details and
instructions), which will install Jython-2.7-beta1.

Please note that this release is considered beta for a reason (although
it has proven stable and reliable for my tasks). Also note that this is
-beta1 instead of -beta3 as the Jython project decided to drop support
for Java 6 with the release of -beta2 [2] - whereas core Fiji is still
shipped with Java 6 to support some old Mac OS releases which don't
receive newer Java versions anymore.

> If you want to use os, there is a trick you can use. Package your functions
> into a python file (e.g. myLib.py) and place it in the $FIJI_ROOT/jars/Lib
> directory. You will have to create Lib. Then from any Jython script you can
> import myLib and call myLib.myFunction(). Your jars can be in the usual
> places...

I'm actually using the "os" module at several points in my Fiji-Jython
scripts, so you might want to give it a try with 2.7.

Cheers
~Niko

[1] http://fiji.sc/List_of_update_sites
[2] http://fwierzbicki.blogspot.ch/2014/05/jython-27-beta2-released.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

Mark Hiner

Re: Problems executing Fiji plugins in ImageJ

In reply to this post by Peter Haub

Hi Peter,

>The question I still have is if plugins written in the Fiji environment
are thought to be (easily) available as ImageJ plugins too or if - because
of the complex library
>dependencies - this compatibility is achievable only with time and expert
knowhow?

It depends on the plugin. In the case of Stitching, for example, there is
an ImageJ 1.x download[1] provided by the author.

But yes as a general rule a you need to consider any dependencies. All the
Fiji plugins are Mavenized for dependency management[2].
Also, the ImageJ updater (Help > Update...) that ships with Fiji will show
you the dependencies it knows of for any library if you go to Advanced Mode.

Best,
Mark

[1] http://fiji.sc/Image_Stitching#Download_for_ImageJ_.26_Acknowledgements
[2] https://github.com/fiji/Stitching/blob/master/pom.xml#L42-121

On Mon, Feb 16, 2015 at 2:02 AM, Peter Haub <[hidden email]> wrote:

> Hi,
> I have to correct my statement.
>
> After writing a SSCCE I found that ImageJ and Fiji both do access plugins
> located in subdirectories of jar archives in the same way.
>
> After all - my problem arises because of missing libraries when using the
> original plugin jar in ImageJ.
>
> The message
> Plugin or class not found: "Stitching Grid"
> (java.lang.ClassNotFoundException: Stitching_Grid)
> was misleading.
> There is no problem in the class file and no problem in the class handling
> in ImageJ/Fiji.
>
> The question I still have is if plugins written in the Fiji environment
> are thought to be (easily) available as ImageJ plugins too or if - because
> of the complex library dependencies - this compatibility is achievable only
> with time and expert knowhow?
>
> Regards,
> Peter
>
>
> On 14.02.2015 21:13, Peter Haub wrote:
>
>> Dear list,
>>
>> I thought that Fiji is just ImageJ.
>> It seems as if there are slight differences in the way plugins (packed in
>> jar archives) are treated.
>> Maybe someone can point to a place where I can find some information
>> regarding the necessary structure of plugin jar archives - for ImageJ and
>> for Fiji.
>>
>> My problem:
>> I would like to use a Fiji plugin in an ImageJ installation (Stitching
>> plugin, S. Preibisch).
>> The plugin is encapsulated in a jar archive.
>> The main classes to be accessed as plugin are located in a subdirectory
>> (\pluin) inside the jar file.
>> The classes are made available to Fiji/ImageJ by a plugin.config file.
>> I can run this (jar packed) plugin in Fiji without problems.
>> In ImageJ the plugin command is available and the plugin user interface
>> (UI) can be started. But when the UI is closed with OK an error is shown:
>> Plugin or class not found: "Stitching Grid"
>> (java.lang.ClassNotFoundException: Stitching_Grid)
>>
>> There is no conflict with additional libraries or wrong configurations.
>>
>> If I recompile the source code by placing the relevant class files in the
>> default package instead of the plugin package the relevant class files are
>> located in the root of the jar archive. This recompiled plugin packed as
>> jar archive can be executed without error message in ImageJ.
>>
>> My questions are:
>> Is there a difference in the handling of plugin jar archives in ImageJ
>> and Fiji?
>> Should it be possible to us plugin jar archives from Fiji without changes
>> in ImageJ?
>> Do I miss something in my specific case?
>> Or do I have to recompile the classes in the way described above?
>>
>> A personal comment:
>> These kinds of differences of complex dependencies are confusing and are
>> challenging the close connection of the two project streams.
>>
>> I would be happy for any hint.
>>
>> Regards
>> Peter
>>
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>
>>
>>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

ctrueden

Re: Problems executing Fiji plugins in ImageJ

In reply to this post by Peter Haub

Hi Peter,

> The question I still have is if plugins written in the Fiji
> environment are thought to be (easily) available as ImageJ plugins too
> or if - because of the complex library dependencies - this
> compatibility is achievable only with time and expert knowhow?

Yes, you can use Fiji plugins in a vanilla ImageJ 1.x installation, as long
as you copy all its dependencies with it.

You can do this easily as follows:

git clone git://github.com/fiji/Stitching
cd Stitching
mvn dependency:copy-dependencies

Then copy target/dependency/*.jar into your ImageJ directory.

You will need Git and Maven installed for this to work.

That said, note that Fiji plugin authors test their plugins in Fiji, not
vanilla ImageJ 1.x, so you might save yourself some pain by using Fiji
instead.

Regards,
Curtis

On Mon, Feb 16, 2015 at 2:02 AM, Peter Haub <[hidden email]> wrote:

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

ctrueden

Re: Problems executing Fiji plugins in ImageJ

Hi Peter,

> Yes, you can use Fiji plugins in a vanilla ImageJ 1.x installation

I added a FAQ entry on it:

http://imagej.net/Frequently_Asked_Questions#How_do_I_install_a_Fiji_plugin_into_vanilla_ImageJ_1.x.3F

There are several downsides to doing things this way, which I explain
further there. In particular, it places the burden of dependency version
management on the end user, which is something Fiji was specifically
created to avoid doing.

Regards,
Curtis

On Mon, Feb 16, 2015 at 8:40 AM, Curtis Rueden <[hidden email]> wrote:

> Hi Peter,
>
> > The question I still have is if plugins written in the Fiji
> > environment are thought to be (easily) available as ImageJ plugins too
> > or if - because of the complex library dependencies - this
> > compatibility is achievable only with time and expert knowhow?
>
> Yes, you can use Fiji plugins in a vanilla ImageJ 1.x installation, as
> long as you copy all its dependencies with it.
>
> You can do this easily as follows:
>
> git clone git://github.com/fiji/Stitching
> cd Stitching
> mvn dependency:copy-dependencies
>
> Then copy target/dependency/*.jar into your ImageJ directory.
>
> You will need Git and Maven installed for this to work.
>
> That said, note that Fiji plugin authors test their plugins in Fiji, not
> vanilla ImageJ 1.x, so you might save yourself some pain by using Fiji
> instead.
>
> Regards,
> Curtis
>
>
> On Mon, Feb 16, 2015 at 2:02 AM, Peter Haub <[hidden email]> wrote:
>
>> Hi,
>> I have to correct my statement.
>>
>> After writing a SSCCE I found that ImageJ and Fiji both do access plugins
>> located in subdirectories of jar archives in the same way.
>>
>> After all - my problem arises because of missing libraries when using
>> the original plugin jar in ImageJ.
>>
>> The message
>> Plugin or class not found: "Stitching Grid"
>> (java.lang.ClassNotFoundException: Stitching_Grid)
>> was misleading.
>> There is no problem in the class file and no problem in the class
>> handling in ImageJ/Fiji.
>>
>> The question I still have is if plugins written in the Fiji environment
>> are thought to be (easily) available as ImageJ plugins too or if - because
>> of the complex library dependencies - this compatibility is achievable only
>> with time and expert knowhow?
>>
>> Regards,
>> Peter
>>
>>
>> On 14.02.2015 21:13, Peter Haub wrote:
>>
>>> Dear list,
>>>
>>> I thought that Fiji is just ImageJ.
>>> It seems as if there are slight differences in the way plugins (packed
>>> in jar archives) are treated.
>>> Maybe someone can point to a place where I can find some information
>>> regarding the necessary structure of plugin jar archives - for ImageJ and
>>> for Fiji.
>>>
>>> My problem:
>>> I would like to use a Fiji plugin in an ImageJ installation (Stitching
>>> plugin, S. Preibisch).
>>> The plugin is encapsulated in a jar archive.
>>> The main classes to be accessed as plugin are located in a subdirectory
>>> (\pluin) inside the jar file.
>>> The classes are made available to Fiji/ImageJ by a plugin.config file.
>>> I can run this (jar packed) plugin in Fiji without problems.
>>> In ImageJ the plugin command is available and the plugin user interface
>>> (UI) can be started. But when the UI is closed with OK an error is shown:
>>> Plugin or class not found: "Stitching Grid"
>>> (java.lang.ClassNotFoundException: Stitching_Grid)
>>>
>>> There is no conflict with additional libraries or wrong configurations.
>>>
>>> If I recompile the source code by placing the relevant class files in
>>> the default package instead of the plugin package the relevant class files
>>> are located in the root of the jar archive. This recompiled plugin packed
>>> as jar archive can be executed without error message in ImageJ.
>>>
>>> My questions are:
>>> Is there a difference in the handling of plugin jar archives in ImageJ
>>> and Fiji?
>>> Should it be possible to us plugin jar archives from Fiji without
>>> changes in ImageJ?
>>> Do I miss something in my specific case?
>>> Or do I have to recompile the classes in the way described above?
>>>
>>> A personal comment:
>>> These kinds of differences of complex dependencies are confusing and are
>>> challenging the close connection of the two project streams.
>>>
>>> I would be happy for any hint.
>>>
>>> Regards
>>> Peter
>>>
>>> --
>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>>
>>>
>>>
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>
>
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

Peter Haub

Re: Problems executing Fiji plugins in ImageJ

In reply to this post by Mark Hiner

Hi Mark,

Thanks for your feedback. Let me give some comments ..

On 16.02.2015 14:53, Mark Hiner wrote:
> It depends on the plugin. In the case of Stitching, for example, there is
> an ImageJ 1.x download[1] provided by the author.
Yes, but this is not the latest version.
> But yes as a general rule a you need to consider any dependencies. All the
> Fiji plugins are Mavenized for dependency management[2].
> Also, the ImageJ updater (Help > Update...) that ships with Fiji will show
> you the dependencies it knows of for any library if you go to Advanced Mode.
This is a very helpful function. Thanks for the information!

So I started to check the necessary libs for the stitching plugin and
copied them to ImageJ. Then I started ImageJ, tested the stitching
command and got the error message mentioned before. I went back and
check the dependencies of all libs I had copied in the first round. I
copied all additional libs to ImageJ, started ImageJ, tested the
stitching command and got the error message. Then I repeated the
procedure a third time ... ...

As a consequence this type of plugin will never be usable in ImageJ for
'standard users'. For non-experts this looks like an incompatibility.

Here in my case this is not a big issue. I can deal with it.
But I thought I will use the chance to give some feedback to the
development team by describing how 'standard users' face the situation.
I am often asked what the relation respectively the difference between
ImageJ and Fiji is. The answer is not such easy as putting batteries in
a flashlight. The nice aspect with ImageJ is that its complexity allows
even beginners to dig into the complete source and get an overview and a
feeling for an efficient and useful image processing software. Also very
nice is its flexibility to extend the functionality by plugins. This is
- I thought - wath Fiji is doing. So Fiji is just ImageJ .... But in
fact the IJ/Fiji question can not be answered in this way. Using ImageJ
means deciding not to use a bundle of very helpful plugins (as we saw
above). Using Fiji means losing the 'backward' compatibility and the
manageable complexity of ImageJ. So the decision between ImageJ and Fiji
is not just a personal preference but leads at the end to different
software tools. Ermm, ...

Mark, do you have an idea how complex it is to develop a function which
could list all dependencies of a plugin such as Stitching_.jar
recursively. This would help at least in the situation above. And more
perfect would be if all the listed libs could be copied to some location.

Hopefully I will find the time to familiarize with with the details of
Fiji, with Maven, with ImgLib2 and all the other nice and very powerful
and advanced capabilities of Fiji.

Regards,
Peter

>
> Best,
> Mark
>
> [1] http://fiji.sc/Image_Stitching#Download_for_ImageJ_.26_Acknowledgements
> [2] https://github.com/fiji/Stitching/blob/master/pom.xml#L42-121
>
> On Mon, Feb 16, 2015 at 2:02 AM, Peter Haub <[hidden email]> wrote:
>
>> Hi,
>> I have to correct my statement.
>>
>> After writing a SSCCE I found that ImageJ and Fiji both do access plugins
>> located in subdirectories of jar archives in the same way.
>>
>> After all - my problem arises because of missing libraries when using the
>> original plugin jar in ImageJ.
>>
>> The message
>> Plugin or class not found: "Stitching Grid"
>> (java.lang.ClassNotFoundException: Stitching_Grid)
>> was misleading.
>> There is no problem in the class file and no problem in the class handling
>> in ImageJ/Fiji.
>>
>> The question I still have is if plugins written in the Fiji environment
>> are thought to be (easily) available as ImageJ plugins too or if - because
>> of the complex library dependencies - this compatibility is achievable only
>> with time and expert knowhow?
>>
>> Regards,
>> Peter
>>
>>
>> On 14.02.2015 21:13, Peter Haub wrote:
>>
>>> Dear list,
>>>
>>> I thought that Fiji is just ImageJ.
>>> It seems as if there are slight differences in the way plugins (packed in
>>> jar archives) are treated.
>>> Maybe someone can point to a place where I can find some information
>>> regarding the necessary structure of plugin jar archives - for ImageJ and
>>> for Fiji.
>>>
>>> My problem:
>>> I would like to use a Fiji plugin in an ImageJ installation (Stitching
>>> plugin, S. Preibisch).
>>> The plugin is encapsulated in a jar archive.
>>> The main classes to be accessed as plugin are located in a subdirectory
>>> (\pluin) inside the jar file.
>>> The classes are made available to Fiji/ImageJ by a plugin.config file.
>>> I can run this (jar packed) plugin in Fiji without problems.
>>> In ImageJ the plugin command is available and the plugin user interface
>>> (UI) can be started. But when the UI is closed with OK an error is shown:
>>> Plugin or class not found: "Stitching Grid"
>>> (java.lang.ClassNotFoundException: Stitching_Grid)
>>>
>>> There is no conflict with additional libraries or wrong configurations.
>>>
>>> If I recompile the source code by placing the relevant class files in the
>>> default package instead of the plugin package the relevant class files are
>>> located in the root of the jar archive. This recompiled plugin packed as
>>> jar archive can be executed without error message in ImageJ.
>>>
>>> My questions are:
>>> Is there a difference in the handling of plugin jar archives in ImageJ
>>> and Fiji?
>>> Should it be possible to us plugin jar archives from Fiji without changes
>>> in ImageJ?
>>> Do I miss something in my specific case?
>>> Or do I have to recompile the classes in the way described above?
>>>
>>> A personal comment:
>>> These kinds of differences of complex dependencies are confusing and are
>>> challenging the close connection of the two project streams.
>>>
>>> I would be happy for any hint.
>>>
>>> Regards
>>> Peter
>>>
>>> --
>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>>
>>>
>>>
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

Peter Haub

Re: Problems executing Fiji plugins in ImageJ

In reply to this post by ctrueden

Hi Curtis,

Thanks for your answer and the description on how the dependencies can
be copied.
That makes it a lot easier.

Peter

On 16.02.2015 16:01, Curtis Rueden wrote:

> Hi Peter,
>
>> Yes, you can use Fiji plugins in a vanilla ImageJ 1.x installation
> I added a FAQ entry on it:
>
> http://imagej.net/Frequently_Asked_Questions#How_do_I_install_a_Fiji_plugin_into_vanilla_ImageJ_1.x.3F
>
> There are several downsides to doing things this way, which I explain
> further there. In particular, it places the burden of dependency version
> management on the end user, which is something Fiji was specifically
> created to avoid doing.
>
> Regards,
> Curtis
>
> On Mon, Feb 16, 2015 at 8:40 AM, Curtis Rueden <[hidden email]> wrote:
>
>> Hi Peter,
>>
>>> The question I still have is if plugins written in the Fiji
>>> environment are thought to be (easily) available as ImageJ plugins too
>>> or if - because of the complex library dependencies - this
>>> compatibility is achievable only with time and expert knowhow?
>> Yes, you can use Fiji plugins in a vanilla ImageJ 1.x installation, as
>> long as you copy all its dependencies with it.
>>
>> You can do this easily as follows:
>>
>> git clone git://github.com/fiji/Stitching
>> cd Stitching
>> mvn dependency:copy-dependencies
>>
>> Then copy target/dependency/*.jar into your ImageJ directory.
>>
>> You will need Git and Maven installed for this to work.
>>
>> That said, note that Fiji plugin authors test their plugins in Fiji, not
>> vanilla ImageJ 1.x, so you might save yourself some pain by using Fiji
>> instead.
>>
>> Regards,
>> Curtis
>>
>>
>> On Mon, Feb 16, 2015 at 2:02 AM, Peter Haub <[hidden email]> wrote:
>>
>>> Hi,
>>> I have to correct my statement.
>>>
>>> After writing a SSCCE I found that ImageJ and Fiji both do access plugins
>>> located in subdirectories of jar archives in the same way.
>>>
>>> After all - my problem arises because of missing libraries when using
>>> the original plugin jar in ImageJ.
>>>
>>> The message
>>> Plugin or class not found: "Stitching Grid"
>>> (java.lang.ClassNotFoundException: Stitching_Grid)
>>> was misleading.
>>> There is no problem in the class file and no problem in the class
>>> handling in ImageJ/Fiji.
>>>
>>> The question I still have is if plugins written in the Fiji environment
>>> are thought to be (easily) available as ImageJ plugins too or if - because
>>> of the complex library dependencies - this compatibility is achievable only
>>> with time and expert knowhow?
>>>
>>> Regards,
>>> Peter
>>>
>>>
>>> On 14.02.2015 21:13, Peter Haub wrote:
>>>
>>>> Dear list,
>>>>
>>>> I thought that Fiji is just ImageJ.
>>>> It seems as if there are slight differences in the way plugins (packed
>>>> in jar archives) are treated.
>>>> Maybe someone can point to a place where I can find some information
>>>> regarding the necessary structure of plugin jar archives - for ImageJ and
>>>> for Fiji.
>>>>
>>>> My problem:
>>>> I would like to use a Fiji plugin in an ImageJ installation (Stitching
>>>> plugin, S. Preibisch).
>>>> The plugin is encapsulated in a jar archive.
>>>> The main classes to be accessed as plugin are located in a subdirectory
>>>> (\pluin) inside the jar file.
>>>> The classes are made available to Fiji/ImageJ by a plugin.config file.
>>>> I can run this (jar packed) plugin in Fiji without problems.
>>>> In ImageJ the plugin command is available and the plugin user interface
>>>> (UI) can be started. But when the UI is closed with OK an error is shown:
>>>> Plugin or class not found: "Stitching Grid"
>>>> (java.lang.ClassNotFoundException: Stitching_Grid)
>>>>
>>>> There is no conflict with additional libraries or wrong configurations.
>>>>
>>>> If I recompile the source code by placing the relevant class files in
>>>> the default package instead of the plugin package the relevant class files
>>>> are located in the root of the jar archive. This recompiled plugin packed
>>>> as jar archive can be executed without error message in ImageJ.
>>>>
>>>> My questions are:
>>>> Is there a difference in the handling of plugin jar archives in ImageJ
>>>> and Fiji?
>>>> Should it be possible to us plugin jar archives from Fiji without
>>>> changes in ImageJ?
>>>> Do I miss something in my specific case?
>>>> Or do I have to recompile the classes in the way described above?
>>>>
>>>> A personal comment:
>>>> These kinds of differences of complex dependencies are confusing and are
>>>> challenging the close connection of the two project streams.
>>>>
>>>> I would be happy for any hint.
>>>>
>>>> Regards
>>>> Peter
>>>>
>>>> --
>>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>>>
>>>>
>>>>
>>> --
>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>>
>>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

Michael Schmid

Re: Problems executing Fiji plugins in ImageJ

In reply to this post by Peter Haub

Hi Peter,

just a hint for using plugins that use additional packages/jars:
Make sure you have Image version 1.49o (or later). In this version, the misleading "Plugin or class not found" error messages are fixed, and it tells you which class is actually missing. With this information one can usually identify the package that is actually missing.

Michael
________________________________________________________________
On Feb 16, 2015, at 16:58, Peter Haub wrote:

> Hi Mark,
>
> Thanks for your feedback. Let me give some comments ..
>
> On 16.02.2015 14:53, Mark Hiner wrote:
>> It depends on the plugin. In the case of Stitching, for example, there is
>> an ImageJ 1.x download[1] provided by the author.
> Yes, but this is not the latest version.
>> But yes as a general rule a you need to consider any dependencies. All the
>> Fiji plugins are Mavenized for dependency management[2].
>> Also, the ImageJ updater (Help > Update...) that ships with Fiji will show
>> you the dependencies it knows of for any library if you go to Advanced Mode.
> This is a very helpful function. Thanks for the information!
>
> So I started to check the necessary libs for the stitching plugin and copied them to ImageJ. Then I started ImageJ, tested the stitching command and got the error message mentioned before. I went back and check the dependencies of all libs I had copied in the first round. I copied all additional libs to ImageJ, started ImageJ, tested the stitching command and got the error message. Then I repeated the procedure a third time ... ...
>
> As a consequence this type of plugin will never be usable in ImageJ for 'standard users'. For non-experts this looks like an incompatibility.
>
> Here in my case this is not a big issue. I can deal with it.
> But I thought I will use the chance to give some feedback to the development team by describing how 'standard users' face the situation. I am often asked what the relation respectively the difference between ImageJ and Fiji is. The answer is not such easy as putting batteries in a flashlight. The nice aspect with ImageJ is that its complexity allows even beginners to dig into the complete source and get an overview and a feeling for an efficient and useful image processing software. Also very nice is its flexibility to extend the functionality by plugins. This is - I thought - wath Fiji is doing. So Fiji is just ImageJ .... But in fact the IJ/Fiji question can not be answered in this way. Using ImageJ means deciding not to use a bundle of very helpful plugins (as we saw above). Using Fiji means losing the 'backward' compatibility and the manageable complexity of ImageJ. So the decision between ImageJ and Fiji is not just a personal preference but leads at the end to different software tools. Ermm, ...
>
> Mark, do you have an idea how complex it is to develop a function which could list all dependencies of a plugin such as Stitching_.jar recursively. This would help at least in the situation above. And more perfect would be if all the listed libs could be copied to some location.
>
> Hopefully I will find the time to familiarize with with the details of Fiji, with Maven, with ImgLib2 and all the other nice and very powerful and advanced capabilities of Fiji.
>
> Regards,
> Peter
>
>>
>> Best,
>> Mark
>>
>> [1] http://fiji.sc/Image_Stitching#Download_for_ImageJ_.26_Acknowledgements
>> [2] https://github.com/fiji/Stitching/blob/master/pom.xml#L42-121
>>
>> On Mon, Feb 16, 2015 at 2:02 AM, Peter Haub <[hidden email]> wrote:
>>
>>> Hi,
>>> I have to correct my statement.
>>>
>>> After writing a SSCCE I found that ImageJ and Fiji both do access plugins
>>> located in subdirectories of jar archives in the same way.
>>>
>>> After all - my problem arises because of missing libraries when using the
>>> original plugin jar in ImageJ.
>>>
>>> The message
>>> Plugin or class not found: "Stitching Grid"
>>> (java.lang.ClassNotFoundException: Stitching_Grid)
>>> was misleading.
>>> There is no problem in the class file and no problem in the class handling
>>> in ImageJ/Fiji.
>>>
>>> The question I still have is if plugins written in the Fiji environment
>>> are thought to be (easily) available as ImageJ plugins too or if - because
>>> of the complex library dependencies - this compatibility is achievable only
>>> with time and expert knowhow?
>>>
>>> Regards,
>>> Peter
>>>
>>>
>>> On 14.02.2015 21:13, Peter Haub wrote:
>>>
>>>> Dear list,
>>>>
>>>> I thought that Fiji is just ImageJ.
>>>> It seems as if there are slight differences in the way plugins (packed in
>>>> jar archives) are treated.
>>>> Maybe someone can point to a place where I can find some information
>>>> regarding the necessary structure of plugin jar archives - for ImageJ and
>>>> for Fiji.
>>>>
>>>> My problem:
>>>> I would like to use a Fiji plugin in an ImageJ installation (Stitching
>>>> plugin, S. Preibisch).
>>>> The plugin is encapsulated in a jar archive.
>>>> The main classes to be accessed as plugin are located in a subdirectory
>>>> (\pluin) inside the jar file.
>>>> The classes are made available to Fiji/ImageJ by a plugin.config file.
>>>> I can run this (jar packed) plugin in Fiji without problems.
>>>> In ImageJ the plugin command is available and the plugin user interface
>>>> (UI) can be started. But when the UI is closed with OK an error is shown:
>>>> Plugin or class not found: "Stitching Grid"
>>>> (java.lang.ClassNotFoundException: Stitching_Grid)
>>>>
>>>> There is no conflict with additional libraries or wrong configurations.
>>>>
>>>> If I recompile the source code by placing the relevant class files in the
>>>> default package instead of the plugin package the relevant class files are
>>>> located in the root of the jar archive. This recompiled plugin packed as
>>>> jar archive can be executed without error message in ImageJ.
>>>>
>>>> My questions are:
>>>> Is there a difference in the handling of plugin jar archives in ImageJ
>>>> and Fiji?
>>>> Should it be possible to us plugin jar archives from Fiji without changes
>>>> in ImageJ?
>>>> Do I miss something in my specific case?
>>>> Or do I have to recompile the classes in the way described above?
>>>>
>>>> A personal comment:
>>>> These kinds of differences of complex dependencies are confusing and are
>>>> challenging the close connection of the two project streams.
>>>>
>>>> I would be happy for any hint.
>>>>
>>>> Regards
>>>> Peter
>>>>
>>>> --
>>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>>>
>>>>
>>>>
>>> --
>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>>
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

Peter Haub

Re: Problems executing Fiji plugins in ImageJ

In reply to this post by ctrueden

Hi Curtis,

I have tested the git clone / mvn command you have suggested.
It runs without any problem. Thanks for this recommendation.

I got 121 jar files in the dependency folder. The file list looks very
similar to the list of files in the Fiji\jars folder. Nearly all jar
files from Fiji\jars have been downloaded with the maven command.
From this 121 jars at least more then 55 can be removed because they
are not needed to run the stitching plugin.

Do you know if there is a more specific command in Maven to download
only the really relevant jar files.
If not then it would be more easy to copy the whole Fiji\jars folder
instead of using Maven.

Thanks and regards,
Peter

On 16.02.2015 15:40, Curtis Rueden wrote:

> Hi Peter,
>
>> The question I still have is if plugins written in the Fiji
>> environment are thought to be (easily) available as ImageJ plugins too
>> or if - because of the complex library dependencies - this
>> compatibility is achievable only with time and expert knowhow?
> Yes, you can use Fiji plugins in a vanilla ImageJ 1.x installation, as long
> as you copy all its dependencies with it.
>
> You can do this easily as follows:
>
> git clone git://github.com/fiji/Stitching
> cd Stitching
> mvn dependency:copy-dependencies
>
> Then copy target/dependency/*.jar into your ImageJ directory.
>
> You will need Git and Maven installed for this to work.
>
> That said, note that Fiji plugin authors test their plugins in Fiji, not
> vanilla ImageJ 1.x, so you might save yourself some pain by using Fiji
> instead.
>
> Regards,
> Curtis
>
>
> On Mon, Feb 16, 2015 at 2:02 AM, Peter Haub <[hidden email]> wrote:
>
>> Hi,
>> I have to correct my statement.
>>
>> After writing a SSCCE I found that ImageJ and Fiji both do access plugins
>> located in subdirectories of jar archives in the same way.
>>
>> After all - my problem arises because of missing libraries when using the
>> original plugin jar in ImageJ.
>>
>> The message
>> Plugin or class not found: "Stitching Grid"
>> (java.lang.ClassNotFoundException: Stitching_Grid)
>> was misleading.
>> There is no problem in the class file and no problem in the class handling
>> in ImageJ/Fiji.
>>
>> The question I still have is if plugins written in the Fiji environment
>> are thought to be (easily) available as ImageJ plugins too or if - because
>> of the complex library dependencies - this compatibility is achievable only
>> with time and expert knowhow?
>>
>> Regards,
>> Peter
>>
>>
>> On 14.02.2015 21:13, Peter Haub wrote:
>>
>>> Dear list,
>>>
>>> I thought that Fiji is just ImageJ.
>>> It seems as if there are slight differences in the way plugins (packed in
>>> jar archives) are treated.
>>> Maybe someone can point to a place where I can find some information
>>> regarding the necessary structure of plugin jar archives - for ImageJ and
>>> for Fiji.
>>>
>>> My problem:
>>> I would like to use a Fiji plugin in an ImageJ installation (Stitching
>>> plugin, S. Preibisch).
>>> The plugin is encapsulated in a jar archive.
>>> The main classes to be accessed as plugin are located in a subdirectory
>>> (\pluin) inside the jar file.
>>> The classes are made available to Fiji/ImageJ by a plugin.config file.
>>> I can run this (jar packed) plugin in Fiji without problems.
>>> In ImageJ the plugin command is available and the plugin user interface
>>> (UI) can be started. But when the UI is closed with OK an error is shown:
>>> Plugin or class not found: "Stitching Grid"
>>> (java.lang.ClassNotFoundException: Stitching_Grid)
>>>
>>> There is no conflict with additional libraries or wrong configurations.
>>>
>>> If I recompile the source code by placing the relevant class files in the
>>> default package instead of the plugin package the relevant class files are
>>> located in the root of the jar archive. This recompiled plugin packed as
>>> jar archive can be executed without error message in ImageJ.
>>>
>>> My questions are:
>>> Is there a difference in the handling of plugin jar archives in ImageJ
>>> and Fiji?
>>> Should it be possible to us plugin jar archives from Fiji without changes
>>> in ImageJ?
>>> Do I miss something in my specific case?
>>> Or do I have to recompile the classes in the way described above?
>>>
>>> A personal comment:
>>> These kinds of differences of complex dependencies are confusing and are
>>> challenging the close connection of the two project streams.
>>>
>>> I would be happy for any hint.
>>>
>>> Regards
>>> Peter
>>>
>>> --
>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>>
>>>
>>>
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

Peter Haub

Re: Problems executing Fiji plugins in ImageJ

In reply to this post by Michael Schmid

Hi Michael,

Thanks for your answer.

I tested the version 1.49p13 (latest daily build) and I still got the
misleading "Plugin or class not found" error message.

By the way, if it would have been fixed would it be display the name of
the missing jar file or only the name of the missing class and one has
to find the jar file containing the class manually?

Thanks and regards,
Peter

On 16.02.2015 18:22, Michael Schmid wrote:

> Hi Peter,
>
> just a hint for using plugins that use additional packages/jars:
> Make sure you have Image version 1.49o (or later). In this version, the misleading "Plugin or class not found" error messages are fixed, and it tells you which class is actually missing. With this information one can usually identify the package that is actually missing.
>
> Michael
> ________________________________________________________________
> On Feb 16, 2015, at 16:58, Peter Haub wrote:
>
>> Hi Mark,
>>
>> Thanks for your feedback. Let me give some comments ..
>>
>> On 16.02.2015 14:53, Mark Hiner wrote:
>>> It depends on the plugin. In the case of Stitching, for example, there is
>>> an ImageJ 1.x download[1] provided by the author.
>> Yes, but this is not the latest version.
>>> But yes as a general rule a you need to consider any dependencies. All the
>>> Fiji plugins are Mavenized for dependency management[2].
>>> Also, the ImageJ updater (Help > Update...) that ships with Fiji will show
>>> you the dependencies it knows of for any library if you go to Advanced Mode.
>> This is a very helpful function. Thanks for the information!
>>
>> So I started to check the necessary libs for the stitching plugin and copied them to ImageJ. Then I started ImageJ, tested the stitching command and got the error message mentioned before. I went back and check the dependencies of all libs I had copied in the first round. I copied all additional libs to ImageJ, started ImageJ, tested the stitching command and got the error message. Then I repeated the procedure a third time ... ...
>>
>> As a consequence this type of plugin will never be usable in ImageJ for 'standard users'. For non-experts this looks like an incompatibility.
>>
>> Here in my case this is not a big issue. I can deal with it.
>> But I thought I will use the chance to give some feedback to the development team by describing how 'standard users' face the situation. I am often asked what the relation respectively the difference between ImageJ and Fiji is. The answer is not such easy as putting batteries in a flashlight. The nice aspect with ImageJ is that its complexity allows even beginners to dig into the complete source and get an overview and a feeling for an efficient and useful image processing software. Also very nice is its flexibility to extend the functionality by plugins. This is - I thought - wath Fiji is doing. So Fiji is just ImageJ .... But in fact the IJ/Fiji question can not be answered in this way. Using ImageJ means deciding not to use a bundle of very helpful plugins (as we saw above). Using Fiji means losing the 'backward' compatibility and the manageable complexity of ImageJ. So the decision between ImageJ and Fiji is not just a personal preference but leads at the end to different software tools. Ermm, ...
>>
>> Mark, do you have an idea how complex it is to develop a function which could list all dependencies of a plugin such as Stitching_.jar recursively. This would help at least in the situation above. And more perfect would be if all the listed libs could be copied to some location.
>>
>> Hopefully I will find the time to familiarize with with the details of Fiji, with Maven, with ImgLib2 and all the other nice and very powerful and advanced capabilities of Fiji.
>>
>> Regards,
>> Peter
>>
>>> Best,
>>> Mark
>>>
>>> [1] http://fiji.sc/Image_Stitching#Download_for_ImageJ_.26_Acknowledgements
>>> [2] https://github.com/fiji/Stitching/blob/master/pom.xml#L42-121
>>>
>>> On Mon, Feb 16, 2015 at 2:02 AM, Peter Haub <[hidden email]> wrote:
>>>
>>>> Hi,
>>>> I have to correct my statement.
>>>>
>>>> After writing a SSCCE I found that ImageJ and Fiji both do access plugins
>>>> located in subdirectories of jar archives in the same way.
>>>>
>>>> After all - my problem arises because of missing libraries when using the
>>>> original plugin jar in ImageJ.
>>>>
>>>> The message
>>>> Plugin or class not found: "Stitching Grid"
>>>> (java.lang.ClassNotFoundException: Stitching_Grid)
>>>> was misleading.
>>>> There is no problem in the class file and no problem in the class handling
>>>> in ImageJ/Fiji.
>>>>
>>>> The question I still have is if plugins written in the Fiji environment
>>>> are thought to be (easily) available as ImageJ plugins too or if - because
>>>> of the complex library dependencies - this compatibility is achievable only
>>>> with time and expert knowhow?
>>>>
>>>> Regards,
>>>> Peter
>>>>
>>>>
>>>> On 14.02.2015 21:13, Peter Haub wrote:
>>>>
>>>>> Dear list,
>>>>>
>>>>> I thought that Fiji is just ImageJ.
>>>>> It seems as if there are slight differences in the way plugins (packed in
>>>>> jar archives) are treated.
>>>>> Maybe someone can point to a place where I can find some information
>>>>> regarding the necessary structure of plugin jar archives - for ImageJ and
>>>>> for Fiji.
>>>>>
>>>>> My problem:
>>>>> I would like to use a Fiji plugin in an ImageJ installation (Stitching
>>>>> plugin, S. Preibisch).
>>>>> The plugin is encapsulated in a jar archive.
>>>>> The main classes to be accessed as plugin are located in a subdirectory
>>>>> (\pluin) inside the jar file.
>>>>> The classes are made available to Fiji/ImageJ by a plugin.config file.
>>>>> I can run this (jar packed) plugin in Fiji without problems.
>>>>> In ImageJ the plugin command is available and the plugin user interface
>>>>> (UI) can be started. But when the UI is closed with OK an error is shown:
>>>>> Plugin or class not found: "Stitching Grid"
>>>>> (java.lang.ClassNotFoundException: Stitching_Grid)
>>>>>
>>>>> There is no conflict with additional libraries or wrong configurations.
>>>>>
>>>>> If I recompile the source code by placing the relevant class files in the
>>>>> default package instead of the plugin package the relevant class files are
>>>>> located in the root of the jar archive. This recompiled plugin packed as
>>>>> jar archive can be executed without error message in ImageJ.
>>>>>
>>>>> My questions are:
>>>>> Is there a difference in the handling of plugin jar archives in ImageJ
>>>>> and Fiji?
>>>>> Should it be possible to us plugin jar archives from Fiji without changes
>>>>> in ImageJ?
>>>>> Do I miss something in my specific case?
>>>>> Or do I have to recompile the classes in the way described above?
>>>>>
>>>>> A personal comment:
>>>>> These kinds of differences of complex dependencies are confusing and are
>>>>> challenging the close connection of the two project streams.
>>>>>
>>>>> I would be happy for any hint.
>>>>>
>>>>> Regards
>>>>> Peter
>>>>>
>>>>> --
>>>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>>>>
>>>>>
>>>>>
>>>> --
>>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>>>
>>> --
>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

Michael Schmid

Re: Problems executing Fiji plugins in ImageJ

Hi Peter,

sorry, I did not write it clearly enough:
In the old versions, the "Plugin or class not found" did not report the class that is actually missing but erroneously a class that is not missing, with the beginning of its name (up to the first dot) stripped off.

Since 1.49o, ImageJ should report the class that is really missing in "Plugin or class not found".

You may also get a "Plugin or class not found" error if the file is not in the ImageJ/plugins directory or an immediate subdirectory thereof.
E.g. ImageJ/plugins/subdir/subsubdir/ThePlugIn.class won't work.

Michael
________________________________________________________________
On Feb 17, 2015, at 06:54, Peter Haub wrote:

> Hi Michael,
>
> Thanks for your answer.
>
> I tested the version 1.49p13 (latest daily build) and I still got the misleading "Plugin or class not found" error message.
>
> By the way, if it would have been fixed would it be display the name of the missing jar file or only the name of the missing class and one has to find the jar file containing the class manually?
>
> Thanks and regards,
> Peter
>
> On 16.02.2015 18:22, Michael Schmid wrote:
>> Hi Peter,
>>
>> just a hint for using plugins that use additional packages/jars:
>> Make sure you have Image version 1.49o (or later). In this version, the misleading "Plugin or class not found" error messages are fixed, and it tells you which class is actually missing. With this information one can usually identify the package that is actually missing.
>>
>> Michael
>> ________________________________________________________________
>> On Feb 16, 2015, at 16:58, Peter Haub wrote:
>>
>>> Hi Mark,
>>>
>>> Thanks for your feedback. Let me give some comments ..
>>>
>>> On 16.02.2015 14:53, Mark Hiner wrote:
>>>> It depends on the plugin. In the case of Stitching, for example, there is
>>>> an ImageJ 1.x download[1] provided by the author.
>>> Yes, but this is not the latest version.
>>>> But yes as a general rule a you need to consider any dependencies. All the
>>>> Fiji plugins are Mavenized for dependency management[2].
>>>> Also, the ImageJ updater (Help > Update...) that ships with Fiji will show
>>>> you the dependencies it knows of for any library if you go to Advanced Mode.
>>> This is a very helpful function. Thanks for the information!
>>>
>>> So I started to check the necessary libs for the stitching plugin and copied them to ImageJ. Then I started ImageJ, tested the stitching command and got the error message mentioned before. I went back and check the dependencies of all libs I had copied in the first round. I copied all additional libs to ImageJ, started ImageJ, tested the stitching command and got the error message. Then I repeated the procedure a third time ... ...
>>>
>>> As a consequence this type of plugin will never be usable in ImageJ for 'standard users'. For non-experts this looks like an incompatibility.
>>>
>>> Here in my case this is not a big issue. I can deal with it.
>>> But I thought I will use the chance to give some feedback to the development team by describing how 'standard users' face the situation. I am often asked what the relation respectively the difference between ImageJ and Fiji is. The answer is not such easy as putting batteries in a flashlight. The nice aspect with ImageJ is that its complexity allows even beginners to dig into the complete source and get an overview and a feeling for an efficient and useful image processing software. Also very nice is its flexibility to extend the functionality by plugins. This is - I thought - wath Fiji is doing. So Fiji is just ImageJ .... But in fact the IJ/Fiji question can not be answered in this way. Using ImageJ means deciding not to use a bundle of very helpful plugins (as we saw above). Using Fiji means losing the 'backward' compatibility and the manageable complexity of ImageJ. So the decision between ImageJ and Fiji is not just a personal preference but leads at the end to different software tools. Ermm, ...
>>>
>>> Mark, do you have an idea how complex it is to develop a function which could list all dependencies of a plugin such as Stitching_.jar recursively. This would help at least in the situation above. And more perfect would be if all the listed libs could be copied to some location.
>>>
>>> Hopefully I will find the time to familiarize with with the details of Fiji, with Maven, with ImgLib2 and all the other nice and very powerful and advanced capabilities of Fiji.
>>>
>>> Regards,
>>> Peter
>>>
>>>> Best,
>>>> Mark
>>>>
>>>> [1] http://fiji.sc/Image_Stitching#Download_for_ImageJ_.26_Acknowledgements
>>>> [2] https://github.com/fiji/Stitching/blob/master/pom.xml#L42-121
>>>>
>>>> On Mon, Feb 16, 2015 at 2:02 AM, Peter Haub <[hidden email]> wrote:
>>>>
>>>>> Hi,
>>>>> I have to correct my statement.
>>>>>
>>>>> After writing a SSCCE I found that ImageJ and Fiji both do access plugins
>>>>> located in subdirectories of jar archives in the same way.
>>>>>
>>>>> After all - my problem arises because of missing libraries when using the
>>>>> original plugin jar in ImageJ.
>>>>>
>>>>> The message
>>>>> Plugin or class not found: "Stitching Grid"
>>>>> (java.lang.ClassNotFoundException: Stitching_Grid)
>>>>> was misleading.
>>>>> There is no problem in the class file and no problem in the class handling
>>>>> in ImageJ/Fiji.
>>>>>
>>>>> The question I still have is if plugins written in the Fiji environment
>>>>> are thought to be (easily) available as ImageJ plugins too or if - because
>>>>> of the complex library dependencies - this compatibility is achievable only
>>>>> with time and expert knowhow?
>>>>>
>>>>> Regards,
>>>>> Peter
>>>>>
>>>>>
>>>>> On 14.02.2015 21:13, Peter Haub wrote:
>>>>>
>>>>>> Dear list,
>>>>>>
>>>>>> I thought that Fiji is just ImageJ.
>>>>>> It seems as if there are slight differences in the way plugins (packed in
>>>>>> jar archives) are treated.
>>>>>> Maybe someone can point to a place where I can find some information
>>>>>> regarding the necessary structure of plugin jar archives - for ImageJ and
>>>>>> for Fiji.
>>>>>>
>>>>>> My problem:
>>>>>> I would like to use a Fiji plugin in an ImageJ installation (Stitching
>>>>>> plugin, S. Preibisch).
>>>>>> The plugin is encapsulated in a jar archive.
>>>>>> The main classes to be accessed as plugin are located in a subdirectory
>>>>>> (\pluin) inside the jar file.
>>>>>> The classes are made available to Fiji/ImageJ by a plugin.config file.
>>>>>> I can run this (jar packed) plugin in Fiji without problems.
>>>>>> In ImageJ the plugin command is available and the plugin user interface
>>>>>> (UI) can be started. But when the UI is closed with OK an error is shown:
>>>>>> Plugin or class not found: "Stitching Grid"
>>>>>> (java.lang.ClassNotFoundException: Stitching_Grid)
>>>>>>
>>>>>> There is no conflict with additional libraries or wrong configurations.
>>>>>>
>>>>>> If I recompile the source code by placing the relevant class files in the
>>>>>> default package instead of the plugin package the relevant class files are
>>>>>> located in the root of the jar archive. This recompiled plugin packed as
>>>>>> jar archive can be executed without error message in ImageJ.
>>>>>>
>>>>>> My questions are:
>>>>>> Is there a difference in the handling of plugin jar archives in ImageJ
>>>>>> and Fiji?
>>>>>> Should it be possible to us plugin jar archives from Fiji without changes
>>>>>> in ImageJ?
>>>>>> Do I miss something in my specific case?
>>>>>> Or do I have to recompile the classes in the way described above?
>>>>>>
>>>>>> A personal comment:
>>>>>> These kinds of differences of complex dependencies are confusing and are
>>>>>> challenging the close connection of the two project streams.
>>>>>>
>>>>>> I would be happy for any hint.
>>>>>>
>>>>>> Regards
>>>>>> Peter
>>>>>>
>>>>>> --
>>>>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>>>>>
>>>>>>
>>>>>>
>>>>> --
>>>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>>>>
>>>> --
>>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>> --
>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>
>>
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

Peter Haub

Re: Problems executing Fiji plugins in ImageJ

Hi Michael,

yes, that's the way I understood your info.

I have removed a jar file which is necessary to run a certain plugin.
When I started the plugin I got the message "Plugin or class not found"
where the plugin itself is reported instead of the missing class file.
For me, the situation has not changed.

Sorry for my unclarity.

Peter

On 17.02.2015 10:37, Michael Schmid wrote:

> Hi Peter,
>
> sorry, I did not write it clearly enough:
> In the old versions, the "Plugin or class not found" did not report the class that is actually missing but erroneously a class that is not missing, with the beginning of its name (up to the first dot) stripped off.
>
> Since 1.49o, ImageJ should report the class that is really missing in "Plugin or class not found".
>
> You may also get a "Plugin or class not found" error if the file is not in the ImageJ/plugins directory or an immediate subdirectory thereof.
> E.g. ImageJ/plugins/subdir/subsubdir/ThePlugIn.class won't work.
>
> Michael
> ________________________________________________________________
> On Feb 17, 2015, at 06:54, Peter Haub wrote:
>
>> Hi Michael,
>>
>> Thanks for your answer.
>>
>> I tested the version 1.49p13 (latest daily build) and I still got the misleading "Plugin or class not found" error message.
>>
>> By the way, if it would have been fixed would it be display the name of the missing jar file or only the name of the missing class and one has to find the jar file containing the class manually?
>>
>> Thanks and regards,
>> Peter
>>
>> On 16.02.2015 18:22, Michael Schmid wrote:
>>> Hi Peter,
>>>
>>> just a hint for using plugins that use additional packages/jars:
>>> Make sure you have Image version 1.49o (or later). In this version, the misleading "Plugin or class not found" error messages are fixed, and it tells you which class is actually missing. With this information one can usually identify the package that is actually missing.
>>>
>>> Michael
>>> ________________________________________________________________
>>> On Feb 16, 2015, at 16:58, Peter Haub wrote:
>>>
>>>> Hi Mark,
>>>>
>>>> Thanks for your feedback. Let me give some comments ..
>>>>
>>>> On 16.02.2015 14:53, Mark Hiner wrote:
>>>>> It depends on the plugin. In the case of Stitching, for example, there is
>>>>> an ImageJ 1.x download[1] provided by the author.
>>>> Yes, but this is not the latest version.
>>>>> But yes as a general rule a you need to consider any dependencies. All the
>>>>> Fiji plugins are Mavenized for dependency management[2].
>>>>> Also, the ImageJ updater (Help > Update...) that ships with Fiji will show
>>>>> you the dependencies it knows of for any library if you go to Advanced Mode.
>>>> This is a very helpful function. Thanks for the information!
>>>>
>>>> So I started to check the necessary libs for the stitching plugin and copied them to ImageJ. Then I started ImageJ, tested the stitching command and got the error message mentioned before. I went back and check the dependencies of all libs I had copied in the first round. I copied all additional libs to ImageJ, started ImageJ, tested the stitching command and got the error message. Then I repeated the procedure a third time ... ...
>>>>
>>>> As a consequence this type of plugin will never be usable in ImageJ for 'standard users'. For non-experts this looks like an incompatibility.
>>>>
>>>> Here in my case this is not a big issue. I can deal with it.
>>>> But I thought I will use the chance to give some feedback to the development team by describing how 'standard users' face the situation. I am often asked what the relation respectively the difference between ImageJ and Fiji is. The answer is not such easy as putting batteries in a flashlight. The nice aspect with ImageJ is that its complexity allows even beginners to dig into the complete source and get an overview and a feeling for an efficient and useful image processing software. Also very nice is its flexibility to extend the functionality by plugins. This is - I thought - wath Fiji is doing. So Fiji is just ImageJ .... But in fact the IJ/Fiji question can not be answered in this way. Using ImageJ means deciding not to use a bundle of very helpful plugins (as we saw above). Using Fiji means losing the 'backward' compatibility and the manageable complexity of ImageJ. So the decision between ImageJ and Fiji is not just a personal preference but leads at the end to different software tools. Ermm, ...
>>>>
>>>> Mark, do you have an idea how complex it is to develop a function which could list all dependencies of a plugin such as Stitching_.jar recursively. This would help at least in the situation above. And more perfect would be if all the listed libs could be copied to some location.
>>>>
>>>> Hopefully I will find the time to familiarize with with the details of Fiji, with Maven, with ImgLib2 and all the other nice and very powerful and advanced capabilities of Fiji.
>>>>
>>>> Regards,
>>>> Peter
>>>>
>>>>> Best,
>>>>> Mark
>>>>>
>>>>> [1] http://fiji.sc/Image_Stitching#Download_for_ImageJ_.26_Acknowledgements
>>>>> [2] https://github.com/fiji/Stitching/blob/master/pom.xml#L42-121
>>>>>
>>>>> On Mon, Feb 16, 2015 at 2:02 AM, Peter Haub <[hidden email]> wrote:
>>>>>
>>>>>> Hi,
>>>>>> I have to correct my statement.
>>>>>>
>>>>>> After writing a SSCCE I found that ImageJ and Fiji both do access plugins
>>>>>> located in subdirectories of jar archives in the same way.
>>>>>>
>>>>>> After all - my problem arises because of missing libraries when using the
>>>>>> original plugin jar in ImageJ.
>>>>>>
>>>>>> The message
>>>>>> Plugin or class not found: "Stitching Grid"
>>>>>> (java.lang.ClassNotFoundException: Stitching_Grid)
>>>>>> was misleading.
>>>>>> There is no problem in the class file and no problem in the class handling
>>>>>> in ImageJ/Fiji.
>>>>>>
>>>>>> The question I still have is if plugins written in the Fiji environment
>>>>>> are thought to be (easily) available as ImageJ plugins too or if - because
>>>>>> of the complex library dependencies - this compatibility is achievable only
>>>>>> with time and expert knowhow?
>>>>>>
>>>>>> Regards,
>>>>>> Peter
>>>>>>
>>>>>>
>>>>>> On 14.02.2015 21:13, Peter Haub wrote:
>>>>>>
>>>>>>> Dear list,
>>>>>>>
>>>>>>> I thought that Fiji is just ImageJ.
>>>>>>> It seems as if there are slight differences in the way plugins (packed in
>>>>>>> jar archives) are treated.
>>>>>>> Maybe someone can point to a place where I can find some information
>>>>>>> regarding the necessary structure of plugin jar archives - for ImageJ and
>>>>>>> for Fiji.
>>>>>>>
>>>>>>> My problem:
>>>>>>> I would like to use a Fiji plugin in an ImageJ installation (Stitching
>>>>>>> plugin, S. Preibisch).
>>>>>>> The plugin is encapsulated in a jar archive.
>>>>>>> The main classes to be accessed as plugin are located in a subdirectory
>>>>>>> (\pluin) inside the jar file.
>>>>>>> The classes are made available to Fiji/ImageJ by a plugin.config file.
>>>>>>> I can run this (jar packed) plugin in Fiji without problems.
>>>>>>> In ImageJ the plugin command is available and the plugin user interface
>>>>>>> (UI) can be started. But when the UI is closed with OK an error is shown:
>>>>>>> Plugin or class not found: "Stitching Grid"
>>>>>>> (java.lang.ClassNotFoundException: Stitching_Grid)
>>>>>>>
>>>>>>> There is no conflict with additional libraries or wrong configurations.
>>>>>>>
>>>>>>> If I recompile the source code by placing the relevant class files in the
>>>>>>> default package instead of the plugin package the relevant class files are
>>>>>>> located in the root of the jar archive. This recompiled plugin packed as
>>>>>>> jar archive can be executed without error message in ImageJ.
>>>>>>>
>>>>>>> My questions are:
>>>>>>> Is there a difference in the handling of plugin jar archives in ImageJ
>>>>>>> and Fiji?
>>>>>>> Should it be possible to us plugin jar archives from Fiji without changes
>>>>>>> in ImageJ?
>>>>>>> Do I miss something in my specific case?
>>>>>>> Or do I have to recompile the classes in the way described above?
>>>>>>>
>>>>>>> A personal comment:
>>>>>>> These kinds of differences of complex dependencies are confusing and are
>>>>>>> challenging the close connection of the two project streams.
>>>>>>>
>>>>>>> I would be happy for any hint.
>>>>>>>
>>>>>>> Regards
>>>>>>> Peter
>>>>>>>
>>>>>>> --
>>>>>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>>>>>
>>>>> --
>>>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>>> --
>>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>> --
>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>>
>>>
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

Herbie-4

Convolve with kernel size > 25

Dear experts,

(with IJ version 1-49o) I feel unable to convolve images with
_normalized_ kernels of side lengths greater 25 pixel (e.g. 27).

I encounter no problems without normalization.

Best

Herbie

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

ctrueden

Re: Problems executing Fiji plugins in ImageJ

In reply to this post by Peter Haub

Hi Peter,

> From this 121 jars at least more then 55 can be removed because they
> are not needed to run the stitching plugin.

Thank you for pointing out this problem. It was an issue with the
dependency structure of some Fiji components, which I have now fixed [1].
Please give it another shot.

Regards,
Curtis

[1] Relevant commits:
*
https://github.com/fiji/Fiji_Plugins/commit/95b945aad99c0041b580491766caf005ef821acd
*
https://github.com/fiji/pom-fiji/commit/1a3e1db03478edb45a8d9e20e4d17532c846b906
*
https://github.com/fiji/Stitching/commit/2b4add61621649fe95ec1c65153033e210b03ceb

On Mon, Feb 16, 2015 at 11:41 PM, Peter Haub <[hidden email]> wrote:

> Hi Curtis,
>
> I have tested the git clone / mvn command you have suggested.
> It runs without any problem. Thanks for this recommendation.
>
> I got 121 jar files in the dependency folder. The file list looks very
> similar to the list of files in the Fiji\jars folder. Nearly all jar files
> from Fiji\jars have been downloaded with the maven command.
> From this 121 jars at least more then 55 can be removed because they are
> not needed to run the stitching plugin.
>
> Do you know if there is a more specific command in Maven to download only
> the really relevant jar files.
> If not then it would be more easy to copy the whole Fiji\jars folder
> instead of using Maven.
>
> Thanks and regards,
> Peter
>
>
>
> On 16.02.2015 15:40, Curtis Rueden wrote:
>
>> Hi Peter,
>>
>> The question I still have is if plugins written in the Fiji
>>> environment are thought to be (easily) available as ImageJ plugins too
>>> or if - because of the complex library dependencies - this
>>> compatibility is achievable only with time and expert knowhow?
>>>
>> Yes, you can use Fiji plugins in a vanilla ImageJ 1.x installation, as
>> long
>> as you copy all its dependencies with it.
>>
>> You can do this easily as follows:
>>
>> git clone git://github.com/fiji/Stitching
>> cd Stitching
>> mvn dependency:copy-dependencies
>>
>> Then copy target/dependency/*.jar into your ImageJ directory.
>>
>> You will need Git and Maven installed for this to work.
>>
>> That said, note that Fiji plugin authors test their plugins in Fiji, not
>> vanilla ImageJ 1.x, so you might save yourself some pain by using Fiji
>> instead.
>>
>> Regards,
>> Curtis
>>
>>
>> On Mon, Feb 16, 2015 at 2:02 AM, Peter Haub <[hidden email]> wrote:
>>
>> Hi,
>>> I have to correct my statement.
>>>
>>> After writing a SSCCE I found that ImageJ and Fiji both do access plugins
>>> located in subdirectories of jar archives in the same way.
>>>
>>> After all - my problem arises because of missing libraries when using
>>> the
>>> original plugin jar in ImageJ.
>>>
>>> The message
>>> Plugin or class not found: "Stitching Grid"
>>> (java.lang.ClassNotFoundException: Stitching_Grid)
>>> was misleading.
>>> There is no problem in the class file and no problem in the class
>>> handling
>>> in ImageJ/Fiji.
>>>
>>> The question I still have is if plugins written in the Fiji environment
>>> are thought to be (easily) available as ImageJ plugins too or if -
>>> because
>>> of the complex library dependencies - this compatibility is achievable
>>> only
>>> with time and expert knowhow?
>>>
>>> Regards,
>>> Peter
>>>
>>>
>>> On 14.02.2015 21:13, Peter Haub wrote:
>>>
>>> Dear list,
>>>>
>>>> I thought that Fiji is just ImageJ.
>>>> It seems as if there are slight differences in the way plugins (packed
>>>> in
>>>> jar archives) are treated.
>>>> Maybe someone can point to a place where I can find some information
>>>> regarding the necessary structure of plugin jar archives - for ImageJ
>>>> and
>>>> for Fiji.
>>>>
>>>> My problem:
>>>> I would like to use a Fiji plugin in an ImageJ installation (Stitching
>>>> plugin, S. Preibisch).
>>>> The plugin is encapsulated in a jar archive.
>>>> The main classes to be accessed as plugin are located in a subdirectory
>>>> (\pluin) inside the jar file.
>>>> The classes are made available to Fiji/ImageJ by a plugin.config file.
>>>> I can run this (jar packed) plugin in Fiji without problems.
>>>> In ImageJ the plugin command is available and the plugin user interface
>>>> (UI) can be started. But when the UI is closed with OK an error is
>>>> shown:
>>>> Plugin or class not found: "Stitching Grid"
>>>> (java.lang.ClassNotFoundException: Stitching_Grid)
>>>>
>>>> There is no conflict with additional libraries or wrong configurations.
>>>>
>>>> If I recompile the source code by placing the relevant class files in
>>>> the
>>>> default package instead of the plugin package the relevant class files
>>>> are
>>>> located in the root of the jar archive. This recompiled plugin packed as
>>>> jar archive can be executed without error message in ImageJ.
>>>>
>>>> My questions are:
>>>> Is there a difference in the handling of plugin jar archives in ImageJ
>>>> and Fiji?
>>>> Should it be possible to us plugin jar archives from Fiji without
>>>> changes
>>>> in ImageJ?
>>>> Do I miss something in my specific case?
>>>> Or do I have to recompile the classes in the way described above?
>>>>
>>>> A personal comment:
>>>> These kinds of differences of complex dependencies are confusing and are
>>>> challenging the close connection of the two project streams.
>>>>
>>>> I would be happy for any hint.
>>>>
>>>> Regards
>>>> Peter
>>>>
>>>> --
>>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>>>
>>>>
>>>>
>>>> --
>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>>
>>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>
>>
>>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

Michael Schmid

Re: Convolve with kernel size > 25

In reply to this post by Herbie-4

Hi Herbie,

there is no obvious problem that I see for large vs. small normalized kernels.
Normalized kernels don't work well if the sum of the kernel elements is very close to zero: "Normalized" means that the kernel is divided by the sum of the elements, and devision by a very small number gives huge numbers as output. Maybe that is the reason for your problem?

Michael
________________________________________________________________
On Feb 17, 2015, at 14:00, Herbie wrote:

> Dear experts,
>
> (with IJ version 1-49o) I feel unable to convolve images with _normalized_ kernels of side lengths greater 25 pixel (e.g. 27).
>
> I encounter no problems without normalization.
>
> Best
>
> Herbie

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

Herbie-4

Re: Convolve with kernel size > 25

In reply to this post by Herbie-4

Dear experts,

apologies for my request!

As Michael Schmid kindly pointed out, the normalized kernel option may
fail with 8bit images (the ones I used), if the kernels are large. All
is well with 32bit images.

Best Herbie

::::::::::::::::::::::::::::::::
On 17.02.15 14:00, Herbie wrote:

> Dear experts,
>
> (with IJ version 1-49o) I feel unable to convolve images with
> _normalized_ kernels of side lengths greater 25 pixel (e.g. 27).
>
> I encounter no problems without normalization.
>
> Best
>
> Herbie
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

ctrueden

Re: Potential updates to ImageJ + a question

In reply to this post by Niko Ehrenfeuchter

Hi everyone,

> Fiji is still shipped with Java 6 to support some old Mac OS releases

That is true, and there are other reasons too. See also this FAQ entry:
http://imagej.net/Frequently_Asked_Questions#Why_does_ImageJ_still_target_Java_6.3F

> Another problem is that I am unable to import the “os” module in
> python.

A lot of effort [1] actually went into making sure that things like "import
os" _do_ work (including with the current Jython 2.5.3). So please let us
know the details of the failure if it is still not working for you with a
fully up-to-date ImageJ.

[1] http://fiji.sc/bugzilla/show_bug.cgi?id=741

On Mon, Feb 16, 2015 at 2:33 AM, Niko Ehrenfeuchter <
[hidden email]> wrote:

> Hi,
>
> On 14.02.2015 15:02, John Minter wrote:
>
>> As noted here http://fiji.sc/Jython_Scripting Jython scripting currently
>> implements Python 2.5. To change this would require development upstream
>> of
>> Fiji/ImageJ.
>>
>
> this is true, but mostly for the reason that the latest officially
> "stable" release of Jython is 2.5, see http://www.jython.org/ for details.
>
> If you want a 2.7 version of Jython within Fiji (which I do), you can
> simply enable my update site "IMCF Uni Basel" (see [1] for details and
> instructions), which will install Jython-2.7-beta1.
>
> Please note that this release is considered beta for a reason (although it
> has proven stable and reliable for my tasks). Also note that this is -beta1
> instead of -beta3 as the Jython project decided to drop support for Java 6
> with the release of -beta2 [2] - whereas core Fiji is still shipped with
> Java 6 to support some old Mac OS releases which don't receive newer Java
> versions anymore.
>
>
> If you want to use os, there is a trick you can use. Package your
>> functions
>> into a python file (e.g. myLib.py) and place it in the $FIJI_ROOT/jars/Lib
>> directory. You will have to create Lib. Then from any Jython script you
>> can
>> import myLib and call myLib.myFunction(). Your jars can be in the usual
>> places...
>>
>
> I'm actually using the "os" module at several points in my Fiji-Jython
> scripts, so you might want to give it a try with 2.7.
>
> Cheers
> ~Niko
>
> [1] http://fiji.sc/List_of_update_sites
> [2] http://fwierzbicki.blogspot.ch/2014/05/jython-27-beta2-released.html
>
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html