Hi Albert,<br><br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">
Thoughts on large files. ImageJ 1 cannot open images larger than the<br>
maximum signed int value, but there is no reason why ImageJ 2<br>
shouldn't be able to.<br></blockquote><br>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.<br>
<br>Relevant tickets in our issue tracking system include:<br> <a href="http://dev.imagejdev.org/trac/imagej/ticket/19">http://dev.imagejdev.org/trac/imagej/ticket/19</a><br> <a href="http://dev.imagejdev.org/trac/imagej/ticket/216">http://dev.imagejdev.org/trac/imagej/ticket/216</a><br>
<br>As Aivar notes in one of ticket #19's comments, he began development at the last Fiji hackathon on a <a href="http://dev.imagejdev.org/trac/imagej/browser/trunk/zoomviewer/src/imagej/display/zoomview">tiled image viewer for ImageJ</a>. We plan to pursue this capability further early next year.<br>
<br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">
Are you guys planning for imglib2 on a PlanarCellContainer that<br>
behaves like a PlanarArrayContainer that has been internally chopped<br>
up into as many cells as necessary, circumventing the array size<br>
limit? And given the large size, extra bonus if the file is lazily<br>
loaded, that is, each cell is loaded on demand from the large file on<br>
disk.<br></blockquote><br>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.<br>
<br>Regards,<br>Curtis<br><br><br><div class="gmail_quote">On Fri, Oct 14, 2011 at 5:53 PM, Albert Cardona <span dir="ltr"><<a href="mailto:sapristi@gmail.com">sapristi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Melissa, Curtis, Johannes,<br>
<br>
Thoughts on large files. ImageJ 1 cannot open images larger than the<br>
maximum signed int value, but there is no reason why ImageJ 2<br>
shouldn't be able to.<br>
<br>
Are you guys planning for imglib2 on a PlanarCellContainer that<br>
behaves like a PlanarArrayContainer that has been internally chopped<br>
up into as many cells as necessary, circumventing the array size<br>
limit? And given the large size, extra bonus if the file is lazily<br>
loaded, that is, each cell is loaded on demand from the large file on<br>
disk.<br>
<br>
>From some time ago I recall having heard or read that LOCI Bioformats<br>
can already read ROIs from images in disk. Is that right? If you could<br>
point me to an example that would b appreciated.<br>
<br>
What motivated the above is that we are currently dealing with 32k x<br>
32k 16-bit images, which we had to cut into tiles. And larger images<br>
are bound to come.<br>
<br>
Albert<br>
<br>
--<br>
<a href="http://albert.rierol.net" target="_blank">http://albert.rierol.net</a><br>
<a href="http://www.ini.uzh.ch/%7Eacardona/" target="_blank">http://www.ini.uzh.ch/~acardona/</a><br>
<font color="#888888"><br>
--<br>
You received this message because you are subscribed to the Google Groups "Fiji-devel" group.<br>
To post to this group, send email to <a href="mailto:fiji-devel@googlegroups.com">fiji-devel@googlegroups.com</a>.<br>
To unsubscribe from this group, send email to <a href="mailto:fiji-devel%2Bunsubscribe@googlegroups.com">fiji-devel+unsubscribe@googlegroups.com</a>.<br>
For more options, visit this group at <a href="http://groups.google.com/group/fiji-devel?hl=en" target="_blank">http://groups.google.com/group/fiji-devel?hl=en</a>.<br>
<br>
</font></blockquote></div><br>