Login  Register

Re: Standalone ImgLib2 usage

Posted by Rex Kerr on Dec 04, 2013; 11:42am
URL: http://imagej.273.s1.nabble.com/Standalone-ImgLib2-usage-tp5005746p5005803.html

Thanks all for the responses, especially those from Curtis and Johannes!  I
appreciate all the time that went into them; that was enough to get me over
the sticking points that were making several ought-to-be-trivial tasks
apparently impossible.

I think my initial foray was worse than expected due to bad luck with the
snapshot of Fiji that I downloaded.  Using the dependencies for the current
imglib2 examples at least gives me a copy of SCIFIO that can save something
other than a jpg without throwing exceptions.  (I also tried building the
latest SCIFIO from source, but that was binary incompatible with everything
else.)  I should also have explained that my initial exasperation was in
large part because I had done the exact same automation with my own tools
plus Apache Commons plus jtransforms in literally 1/10th of the coding time
that it took me to not even get something working with ImgLib2; the reason
I wanted to use ImgLib2 was to make installation less clunky for others who
might want to use my code, and to keep me from having to maintain my random
set of personal tools.

For Curtis specifically, here is what I used (in Scala) to generate a
histogram:

  val hbm = new IntBinMapper[UnsignedByteType](0.ub, 255.ub)
  val h = new Histogram(hbm, im)
  h.process
  val ha = h.getHistogram

where .ub is an extension method (effectively) that wraps integers as
UnsignedByteType.  And, since it's Scala, types are inferred in most places.

If I'd had Curtis' example first, I'd have tried using
histogram.Histogram1d, but there's no indication which is the "right" one
to use, and algorithm.stats.Histogram seemed to have the simpler API.
 Except that it doesn't document the necessity of calling .process; if you
omit that line, h.getHistogram returns an array of zeros.

Note that none of my problems were caused by any of the interesting
capabilities or design of ImgLib2.  It was all bugs, missing features, or
lack of documentation.  In a way, that's good; it suggests that the
fundamental concepts are sound and can be picked up fairly quickly by at
least some people.  But I would add, respectfully, that giving new users a
poor initial experience due to bugs and lack of documentation is not the
best way to get them to be members of the community and to contribute.  (In
that vein, note that "getting started" doesn't tell you how to get started
but assumes you're ready to start compiling successfully, and "introduction
and required files" in examples doesn't give a complete list of the
required files.)

Thanks again to those who took time to get me back on track.

I will direct any further questions I have to some -devel list, as the
content will probably be more appropriate there.

  --Rex

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