Hi Tobias et. al,<br><br><blockquote style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">If you could do the split, Curtis, that would be great.<br></blockquote><br>
I have pushed changes to the ImgLib repository that split imglib2-algorithms into two halves:<br>1) imglib2-algorithms<br>2) imglib2-algorithms-gpl<br><br>For details, see:<br> <a href="https://github.com/imagej/imglib/commit/0bf737ca">https://github.com/imagej/imglib/commit/0bf737ca</a><br>
<br>The net.imglib2.algorithm interfaces live in imglib2-algorithms, as do most of the current algorithms. This project is licensed under BSD.<br><br>The imglib2-algorithms-gpl project contains the GPL-licensed algorithms, and has dependencies on mpicbg and mines-jtk.<br>
<br>With this change, the ImageJ2 build is now working again (see <a href="http://jenkins.imagej.net/">http://jenkins.imagej.net/</a>).<br><br>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:<br>
* componenttree<br> * floydsteinberg<br> * function<br> * gauss<br> * integral<br> * kdtree<br> * labeling<br> * stats<br><br>[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.)<br>
<br>Secondly, since the project structure was changing anyway, I took the opportunity to improve the names of the POM projects:<br> <a href="https://github.com/imagej/imglib/commit/23bf5218">https://github.com/imagej/imglib/commit/23bf5218</a><br>
<br>[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.<br>
<br>Hopefully this will be the last structural change before we release an ImgLib2 beta.<br>
<br>
Thanks,<br>Curtis<br><br><br><div class="gmail_quote">On Thu, Mar 1, 2012 at 4:39 AM, Tobias Pietzsch <span dir="ltr"><<a href="mailto:pietzsch@mpi-cbg.de">pietzsch@mpi-cbg.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all,<div class="im"><br>
<br>
On 02/29/2012 09:30 PM, Curtis Rueden wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2) Split imglib2-algorithms into multiple components:<br>
imglib2-algorithms-bsd and imglib2-algorithms-gpl, for example. Then we<br>
can include imglib2-algorithms-bsd as a dependency for ImageJ2.<br>
</blockquote>
<br></div>
This is the option I would prefer.<br>
If you could do the split, Curtis, that would be great.<br>
<br>
I do not think that the definition for "core" should be "everything<br>
needed by ImageJ2". I don't see a problem with splitting ImageJ2<br>
dependencies.<br>
<br>
I don't have a problem with having Histogram in the core, either.<br>
But then it should not implement the Algorithm interface (I don't<br>
get the point of the Algorithm interface, to be honest). Equally<br>
important: it should not _feel_ like an algorithm, rather it should<br>
_be_ the histogram. I.e., Histogram should not have an getHistogram()<br>
that returns an int[] array which represents the histogram. Rather,<br>
Histogram itself should represent the histogram. For example, it could<br>
implement RandomAccessibleInterval< IntType > to achieve that, and the<br>
histogram could be computed in the constructor.<br>
<br>
best regards,<br>
Tobias<br>
</blockquote></div><br>