Posted by
Albert Cardona-2 on
Jul 11, 2013; 6:07pm
URL: http://imagej.273.s1.nabble.com/TrakEM-Mipmap-regeneration-slow-tp5003921p5003924.html
2013/7/11 Ashwin <
[hidden email]>
> Ashwin,
>
> 1. what are the type and dimensions of your images?
>
> The images are all 8bit .tiff and they are 8kx8K. Each layer had 16x 8K
> images and there are 1300 layers in the stack.
>
Considering the capabilities of your computer, consider processing multiple
tiles at a time. Every tile needs about 10x its size in RAM, e.g. ~700 MB
for your tiles. With a heap of 55 GB, you should be able to process a
couple dozen easily. Use then a single thread for the Gaussian downsampling.
>
> 2. CompressedOops won't work when allocating over 31 GB of heap.
>
> OK. So how do I call Fiji if I want to assign more heap space. Also is it
> correct to assume larger heap space equals faster processing?
>
Larger heap results in larger garbage collection in general.
Overall, I have no idea why the process would stall to the point that it
takes 20 minutes to generate mipmaps for a single tile. If garbage
collection is the culprit, you will see it in the terminal if you add the
-verbose:gc parameter to the launcher command.
Albert
--
http://albert.rierol.nethttp://www.ini.uzh.ch/~acardona/--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html