These are chat archives for fiji/fiji
Hello @kapoorlab! I cloned both of your repos, and neither one built for me. I was able to get your imglib2-algorithm fork to build by adding dependencies to the pom for mpicbg and apache commons-math3. However, imglib2-algorithm cannot depend on mpicbg since it is GPL licensed. Additionally, it would cause imglib2-algorithm to depend on ImageJ 1.x.
For the Bubbleator, the enforcer is failing and it can’t find imports for
preProcessing.Utils. It looks like these are only being used for Otsu and
Dothinning. Imagej-ops has an Otsu command you could use, and if
Dothinning is an erosion operation imagej-ops has that as well.
In terms of using some of the implementations on my shape-rois branch, I definitely think there are places where this would be nice! I think your Ellipsoid and HyperEllipsoid classes could possibly extend ClosedEllipsoid or at least implement the Ellipsoid interface. You might also be able to use my DefaultLine implementation for your tangent lines. However, in order to display the ROIs on my shape-rois branch you’d need to convert them to ImageJ 1.x ROIs still. Though I am working on converters to do this in imagej-legacy (see roi-converters branch).
On a separate note, do
GeneralEllipsoid need to be separate classes? Could you just add an additional constructor to Ellipsoid and a
getCoefficients() method? It just seems to me like it would be simpler if they were one class rather than constantly dealing with a
Pair<Ellipsoid, GeneralEllipsoid>, but I haven’t fully thought through the repercussions.
Additionally, in your RansacEllipsoid#GetEllipsePoints(...) method it looks like you’re converting to an ImageJ 1.x
EllipseRoi just to get the coordinates of the boundary pixels. Unfortunately I don’t know if we currently have an implementation that can do this, but it would be nice to have. If anyone else knows a way, please let me know!
Those are my thoughts/comments, sorry its so long! Feel free to let me know if you have any questions!