<div dir="ltr"><div><div>Hi Hadrien,<br><br>>My hypothesis is that when loading an image, Fiji/SCIFIO look at free<br>
>memory in the system but not in the JVM. Is that possible ?<br><br></div>Yes, this is almost certainly what's happening. Unfortunately I am not aware of a way to differentiate between memory that is still in use, and memory that just hasn't been deallocated.<br><br></div><div>By default in these situations SCIFIO will look at the available memory, see that there's not enough to open the dataset and open it virtually. Note that it actually would be possible to open the full dataset - as the memory allocation approached the JVM's limit, it would automatically be released.<br><br></div><div>Right now this can be worked around programmatically by specifying a PLANAR or ARRAY[1] ImgMode in the SCIFIOConfig[2]. The Bio-Formats importer lets you specify whether the image should be opened virtually or not. The only other option is to click the status bar to force garbage collection.<br><br></div><div>We also have plans to improve the SCIFIO importer[3] to expose these settings in the UI. Ultimately the hope is that virtual (cell) images will incur minimal performance penalties though[4], making this issue moot.<br></div><div><br></div><div>Thanks!<br></div><div>- Mark<br></div><div><br>[1] <a href="https://github.com/scifio/scifio/blob/scifio-0.21.1/src/main/java/io/scif/config/SCIFIOConfig.java#L124">https://github.com/scifio/scifio/blob/scifio-0.21.1/src/main/java/io/scif/config/SCIFIOConfig.java#L124</a><br>[2] <a href="https://github.com/scifio/scifio/blob/scifio-0.21.1/src/main/java/io/scif/config/SCIFIOConfig.java#L370-373">https://github.com/scifio/scifio/blob/scifio-0.21.1/src/main/java/io/scif/config/SCIFIOConfig.java#L370-373</a><br>[3] <a href="https://github.com/imagej/imagej-plugins-commands/issues/4">https://github.com/imagej/imagej-plugins-commands/issues/4</a><br>[4] <a href="https://github.com/scifio/scifio/issues/201">https://github.com/scifio/scifio/issues/201</a><br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 26, 2015 at 5:57 AM, Hadrien Mary <span dir="ltr"><<a href="mailto:hadrien.mary@gmail.com" target="_blank">hadrien.mary@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
New SCIFIO I/O system in Fiji/IJ2 automatically detects wether virtual<br>
stack is needed according to system memory available and image size<br>
(if I understood correctly).<br>
<br>
Virtual stack is fine but it always better to work without when you<br>
can. For example working with timelapse stacks, sliding time is much<br>
faster when image is not a virtual stack (and it makes sense since RAM<br>
memory access is much faster than hard drive memory access...).<br>
<br>
Saying that I noticed something: when I close a big image (no virtual<br>
stack because moving time slider is fast), java does not release<br>
memory to system (and it's a normal behaviour according to this<br>
<a href="http://stackoverflow.com/questions/22912063/automatically-release-unused-memory-in-imagej-fiji" target="_blank">http://stackoverflow.com/questions/22912063/automatically-release-unused-memory-in-imagej-fiji</a>).<br>
Now when I load the same kind of image (same size), the JVM should use<br>
the free memory released by the previously closed image isn't it ? I<br>
have the feeling that it does not because, when I move the time slider<br>
on the second image, it's very slow....<br>
<br>
Some numbers:<br>
<br>
- image size : 4.6GB<br>
- Fiji memory after start : 0.3GB<br>
- Fiji memory after loading first image: 6.9GiB<br>
- Fiji memory after closing first image: 6.9GiB<br>
- Fiji memory after loading second image: 6.9GiB<br>
<br>
My hypothesis is that when loading an image, Fiji/SCIFIO look at free<br>
memory in the system but not in the JVM. Is that possible ? Did you<br>
already noticed that ?<br>
<br>
PS: I have attached to this mail some properties of my system.<br>
<br>
Best,<br>
<br>
--<br>
Hadrien Mary<br>
<br>
Ph.D student in Biology<br>
Tournier-Gachet Team<br>
CNRS - LBCMCP - UMR 5088<br>
<br>
UniversitĂ© de Toulouse - Bât. 4R3B1<br>
118, route de Narbonne - 31062 Toulouse<br>
<br>_______________________________________________<br>
ImageJ-devel mailing list<br>
<a href="mailto:ImageJ-devel@imagej.net">ImageJ-devel@imagej.net</a><br>
<a href="http://imagej.net/mailman/listinfo/imagej-devel" target="_blank">http://imagej.net/mailman/listinfo/imagej-devel</a><br>
<br></blockquote></div><br></div>