Re: memory limit and the 64-bit era

Posted by Michael Held on Apr 07, 2007; 9:25am
URL: http://imagej.273.s1.nabble.com/memory-limit-and-the-64-bit-era-tp3699808p3699810.html

hi albert,

thanks for your reply from the ETH :-)

Albert Cardona wrote:
> In my experience having all images opened at once doesn't help much. What does
> help is virtualization: either purely virtual stacks like those offered by the
> virtual stack opener plugin, or a virtualization layer with a fifo on-demand
> reloading cache like TrakEM2.
I will have a closer look on TrakEM2!

> I don't have experience with 5D, but for 4D we regularly open 15.000 16-bit
> images (from SPIM microscope) with the Virtual Stack Opener, and then apply the
> 4D hypervolume browser on it without problems. Scrolling through the stack is
> fast, almost unnoticeable (even when the files physically live on a
> gigabit-networked remote file server). ImageJ doesn't need more than a few
> hundred megabytes to handle the above seamlessly.
manual browsing and annotation is the major reason why we have to import
the *entire* stack. because of the volume most of our data is stored on
a NAS which will make image browsing slow.

> As for internal ImageJ-related 64-bit limitations: I am not aware of any. Only
> if single images are bigger than the 32-bit limit, or more than such 32-bit
> images are open, may you see strange behaviours.
that's very good to know! I was just concerned, because the ImageJ guys
write about 4GB limit.

> The JVM crashing after allocating -Xmx3000 for it and then just opening the
> 'About ImageJ' sounds to me like a JVM problem, not an ImageJ problem.
I test the JVM6.0 for it. thanks!


happy easter
michael