http://imagej.273.s1.nabble.com/Standalone-ImgLib2-usage-tp5005746p5014722.html
oddities as fast as I could grasp them. Unfortunately for practical reasons
still ImgLib 1 (even though it works very well). An updated version to
> 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>