<div dir="ltr"><div><div><div><div>>Sorry if it is something obvious but I often see these modes without knowing how they work.<br><br></div>No problem at all.<br><br></div>This option decides which underlying ImgLib2 data structure is preferred to back the image data: Array[1], Planar[2], or Cell[3]. <br><br></div>Cell is the virtual option that reads planes on demand from disk (or cache). Array is faster but historically some operations could only operate on PlanarImgs.<br><br></div>You might find the ImgLib2 examples[4] helpful, as well.<br><div><div><div><br>[1] <a href="https://github.com/imglib/imglib2/blob/imglib2-2.2.1/src/main/java/net/imglib2/img/array/ArrayImg.java">https://github.com/imglib/imglib2/blob/imglib2-2.2.1/src/main/java/net/imglib2/img/array/ArrayImg.java</a><br>[2] <a href="https://github.com/imglib/imglib2/blob/imglib2-2.2.1/src/main/java/net/imglib2/img/planar/PlanarImg.java">https://github.com/imglib/imglib2/blob/imglib2-2.2.1/src/main/java/net/imglib2/img/planar/PlanarImg.java</a><br>[3] <a href="https://github.com/scifio/scifio/blob/scifio-0.21.1/src/main/java/io/scif/img/cell/SCIFIOCellImg.java">https://github.com/scifio/scifio/blob/scifio-0.21.1/src/main/java/io/scif/img/cell/SCIFIOCellImg.java</a><br>[4] <a href="http://fiji.sc/ImgLib2_Examples">http://fiji.sc/ImgLib2_Examples</a><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 13, 2015 at 1:54 PM, 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">Thank you Mark for the answer.<br>
<br>
About ImgMode I wonder what is the difference between these three modes :<br>
<br>
- ArrayImgFactory<br>
- CellImgFactory<br>
- PlanarImgFactory<br>
<br>
Sorry if it is something obvious but I often see these modes without<br>
knowing how they work.<br>
<span class="im HOEnZb"><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>
</span><div class="HOEnZb"><div class="h5">On Fri, Mar 13, 2015 at 7:43 PM, Mark Hiner <<a href="mailto:hiner@wisc.edu">hiner@wisc.edu</a>> wrote:<br>
> 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>
> Yes, this is almost certainly what's happening. Unfortunately I am not aware<br>
> of a way to differentiate between memory that is still in use, and memory<br>
> that just hasn't been deallocated.<br>
><br>
> By default in these situations SCIFIO will look at the available memory, see<br>
> that there's not enough to open the dataset and open it virtually. Note that<br>
> it actually would be possible to open the full dataset - as the memory<br>
> allocation approached the JVM's limit, it would automatically be released.<br>
><br>
> Right now this can be worked around programmatically by specifying a PLANAR<br>
> or ARRAY[1] ImgMode in the SCIFIOConfig[2]. The Bio-Formats importer lets<br>
> you specify whether the image should be opened virtually or not. The only<br>
> other option is to click the status bar to force garbage collection.<br>
><br>
> We also have plans to improve the SCIFIO importer[3] to expose these<br>
> settings in the UI. Ultimately the hope is that virtual (cell) images will<br>
> incur minimal performance penalties though[4], making this issue moot.<br>
><br>
> Thanks!<br>
> - Mark<br>
><br>
> [1]<br>
> <a href="https://github.com/scifio/scifio/blob/scifio-0.21.1/src/main/java/io/scif/config/SCIFIOConfig.java#L124" target="_blank">https://github.com/scifio/scifio/blob/scifio-0.21.1/src/main/java/io/scif/config/SCIFIOConfig.java#L124</a><br>
> [2]<br>
> <a href="https://github.com/scifio/scifio/blob/scifio-0.21.1/src/main/java/io/scif/config/SCIFIOConfig.java#L370-373" target="_blank">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" target="_blank">https://github.com/imagej/imagej-plugins-commands/issues/4</a><br>
> [4] <a href="https://github.com/scifio/scifio/issues/201" target="_blank">https://github.com/scifio/scifio/issues/201</a><br>
><br>
><br>
> On Mon, Jan 26, 2015 at 5:57 AM, Hadrien Mary <<a href="mailto:hadrien.mary@gmail.com">hadrien.mary@gmail.com</a>><br>
> wrote:<br>
>><br>
>> 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>
>><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>
><br>
</div></div></blockquote></div><br></div>