[ImageJ-devel] imglib2-io as a test phase dependency of imglib-algorithms

Lee Kamentsky leek at broadinstitute.org
Thu Jun 20 15:49:43 CDT 2013


Hi all,

On Thu, Jun 20, 2013 at 12:27 PM, Curtis Rueden <ctrueden at wisc.edu> wrote:

> Hi Lee,
>
> > I was thinking it would be nice (= makes my life a little easier) if
> > imglib2-io was a test phase dependency of imglib-algorithms so you
> > could use test images in imglib2 tests.
>
> I think that's a good idea. However, a couple of comments:
>
> 1) net.imglib2:imglib2-io:2.0.0-SNAPSHOT will go away soon, in favor of
> io.scif:scifio:0.3.0. In other words: the latest ImgOpener/ImgSaver work is
> being done in the SCIFIO repository (https://github.com/scifio/scifio)
> rather than in the ImgLib2 repo. The reason is that imglib2-io already
> depends on SCIFIO to do this stuff, and SCIFIO depends on imglib2 core, so
> why not consolidate and give all SCIFIO users the capability of working
> with ImgLib2 data structures?
>
> So, imglib-algorithms would then have a test-phase dependency on scifio.
> Same difference though.
>

I'll look at pulling in scifio instead or possibly hold off on committing
the tests until things gel a bit more.


>
> I'm thinking of storing very small .tifs as resources
>
> 2) Rather than TIFFs, you can use .fake file paths for testing without
> needing to commit any actual images to the repository. The .fake "file
> format" was invented for exactly such a purpose, to make unit testing easy.
> The only downside is that you can't precisely control the pixel contents,
> but for unit tests you rarely need to. Rather, you typically want the test
> to verify that it processes data in various structures properly (RGB vs.
> grayscale, huge plane sizes, etc.).
>
> Would that work for you?
>
> For the pyramids, I want to compare the output of the C reference
implementation against my own. That means that I have to generate the
results using an image with known contents. Johannes suggested generating
test images. In CellProfiler, I often do similar - use a pseudo-random
number generator with fixed seed to generate the same image every time. I
was planning to include the reference implementation outputs (there are six
different variants = 6 outputs), but perhaps it's enough to randomly sample
the values at a handful of coordinates and check those instead of checking
the entire image.

For CP unit tests, we have a standard set of images that we use throughout
the tests (stored in an svn repository, not GIT). ImageJ has those example
images and maybe those are enough for testing.

Regards,
> Curtis
>
>
> On Thu, Jun 20, 2013 at 8:53 AM, Lee Kamentsky <leek at broadinstitute.org>wrote:
>
>> Hi all,
>> I was thinking it would be nice (= makes my life a little easier) if
>> imglib2-io was a test phase dependency of imglib-algorithms so you could
>> use test images in imglib2 tests. I'm thinking of storing very small .tifs
>> as resources in the test packages, hope 100x100 pixels is a reasonable size
>> for GIT, still haven't figured out the best strategy for writing the
>> resource to a file so that it can be loaded.
>>
>> --Lee
>>
>> _______________________________________________
>> ImageJ-devel mailing list
>> ImageJ-devel at imagej.net
>> http://imagej.net/mailman/listinfo/imagej-devel
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20130620/87a694e5/attachment.html>


More information about the ImageJ-devel mailing list