[ImageJ-devel] [IMGLIB] moved algorithm and stats packages out of imglib2-core

[Curtis Rueden]

Hi Tobias et. al,

If you could do the split, Curtis, that would be great.
>

I have pushed changes to the ImgLib repository that split
imglib2-algorithms into two halves:
1) imglib2-algorithms
2) imglib2-algorithms-gpl

For details, see:
  https://github.com/imagej/imglib/commit/0bf737ca

The net.imglib2.algorithm interfaces live in imglib2-algorithms, as do most
of the current algorithms. This project is licensed under BSD.

The imglib2-algorithms-gpl project contains the GPL-licensed algorithms,
and has dependencies on mpicbg and mines-jtk.

With this change, the ImageJ2 build is now working again (see
http://jenkins.imagej.net/).

It may be that some of the algorithms in imglib2-algorithms should be moved
to imglib2-algorithms-gpl, to match the wishes of the authors. Currently,
only the fft and transformation packages reside in imglib2-algorithms-gpl.
All the others currently belong to imglib2-algorithms:
  * componenttree
  * floydsteinberg
  * function
  * gauss
  * integral
  * kdtree
  * labeling
  * stats

[ACTION ITEM] For the above packages, if the relevant author(s) would
prefer a GPL license, let me know and I will happily move them into
imglib2-algorithms-gpl. (The only one ImageJ2 currently needs to stay BSD
is stats.)

Secondly, since the project structure was changing anyway, I took the
opportunity to improve the names of the POM projects:
  https://github.com/imagej/imglib/commit/23bf5218

[ACTION ITEM] I recommend deleting your existing ImgLib Eclipse projects
(with "Delete project contents on disk" unchecked), and reimporting using
File > Import > Existing Maven Projects. This will give you the latest
project structure.

Hopefully this will be the last structural change before we release an
ImgLib2 beta.

Thanks,
Curtis


On Thu, Mar 1, 2012 at 4:39 AM, Tobias Pietzsch <pietzsch at mpi-cbg.de> wrote:

> Hi all,
>
>
> On 02/29/2012 09:30 PM, Curtis Rueden wrote:
>
>> 2) Split imglib2-algorithms into multiple components:
>> imglib2-algorithms-bsd and imglib2-algorithms-gpl, for example. Then we
>> can include imglib2-algorithms-bsd as a dependency for ImageJ2.
>>
>
> This is the option I would prefer.
> If you could do the split, Curtis, that would be great.
>
> I do not think that the definition for "core" should be "everything
> needed by ImageJ2". I don't see a problem with splitting ImageJ2
> dependencies.
>
> I don't have a problem with having Histogram in the core, either.
> But then it should not implement the Algorithm interface (I don't
> get the point of the Algorithm interface, to be honest).  Equally
> important: it should not _feel_ like an algorithm, rather it should
> _be_ the histogram.  I.e., Histogram should not have an getHistogram()
> that returns an int[] array which represents the histogram.  Rather,
> Histogram itself should represent the histogram.  For example, it could
> implement RandomAccessibleInterval< IntType > to achieve that, and the
> histogram could be computed in the constructor.
>
> best regards,
> Tobias
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20120301/f1313af3/attachment.html>