[ImageJ-devel] [fiji-devel] reading images larger than signed int max value

[Curtis Rueden]

Hi Albert,

Thoughts on large files. ImageJ 1 cannot open images larger than the
> maximum signed int value, but there is no reason why ImageJ 2
> shouldn't be able to.
>

Absolutely. This has been a goal of IJ2 from the beginning. However, given
the magnitude of the project, the first release will not provide a full
solution. However, the architecture (i.e., ImgLib2) is in place for a full
solution to be implemented in a reasonable time frame.

Relevant tickets in our issue tracking system include:
  http://dev.imagejdev.org/trac/imagej/ticket/19
  http://dev.imagejdev.org/trac/imagej/ticket/216

As Aivar notes in one of ticket #19's comments, he began development at the
last Fiji hackathon on a tiled image viewer for
ImageJ<http://dev.imagejdev.org/trac/imagej/browser/trunk/zoomviewer/src/imagej/display/zoomview>.
We plan to pursue this capability further early next year.

Are you guys planning for imglib2 on a PlanarCellContainer that
> behaves like a PlanarArrayContainer that has been internally chopped
> up into as many cells as necessary, circumventing the array size
> limit? And given the large size, extra bonus if the file is lazily
> loaded, that is, each cell is loaded on demand from the large file on
> disk.
>

Yes, we don't have a ticket for it yet, but it is very similar to #216. We
will definitely need to create an ImgLib2 cell container (of which a planar
cell container is just a special case). It will be needed not only for
tiling, but also for caching image processing operations on huge datasets in
general. For example, you can currently open a 200GB dataset (e.g., 1024 x
1024 x 100 focal planes x 1000 time points x 16-bit) as a virtual stack. But
you can't easily process every plane with a plugin filter and then keep
browsing the processed planes. With a cell container that caches out blocks
to disk as needed, it would at least be possible, if slow. And this
capability would make it easier to implement undo as well, since prior
dataset states could be cached to and from disk in a similar way.

Regards,
Curtis


On Fri, Oct 14, 2011 at 5:53 PM, Albert Cardona <sapristi at gmail.com> wrote:

> Melissa, Curtis, Johannes,
>
> Thoughts on large files. ImageJ 1 cannot open images larger than the
> maximum signed int value, but there is no reason why ImageJ 2
> shouldn't be able to.
>
> Are you guys planning for imglib2 on a PlanarCellContainer that
> behaves like a PlanarArrayContainer that has been internally chopped
> up into as many cells as necessary, circumventing the array size
> limit? And given the large size, extra bonus if the file is lazily
> loaded, that is, each cell is loaded on demand from the large file on
> disk.
>
> From some time ago I recall having heard or read that LOCI Bioformats
> can already read ROIs from images in disk. Is that right? If you could
> point me to an example that would b appreciated.
>
> What motivated the above is that we are currently dealing with 32k x
> 32k 16-bit images, which we had to cut into tiles. And larger images
> are bound to come.
>
> Albert
>
> --
> http://albert.rierol.net
> http://www.ini.uzh.ch/~acardona/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Fiji-devel" group.
> To post to this group, send email to fiji-devel at googlegroups.com.
> To unsubscribe from this group, send email to
> fiji-devel+unsubscribe at googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/fiji-devel?hl=en.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20111021/f4092339/attachment.html>