Remove slices from a virtual stack

[Michael Doube]

Hi all

Is there a quick way to remove slices from a virtual stack?

I have several GB of microCT slices that I drag 'n drop in their
directory (i.e. drag 'n drop the directory), but then I want to remove
the first 300 or so slices and the last 300 or so slices so that I can
crop the stack without running out of RAM (the result of the crop
operation is not a virtual stack so must be smaller than IJ's allocated
memory).

I have automated a slice range deletion with this macro, however it's
very slow as it has to open each image before deleting it.


macro "Delete Slice Range [b]"{
Dialog.create("Delete Slice Range");
Dialog.addMessage("Inclusive range of slices to delete");
Dialog.addNumber("First", getSliceNumber());
Dialog.addNumber("Last", getSliceNumber());
Dialog.show();
first = Dialog.getNumber();
last = Dialog.getNumber();
setBatchMode(true);
deletable = last - first +1;
for (deleted = 0; deleted < deletable; deleted++){
        showStatus("Deleting slices...");
        showProgress(deleted/(deletable-1));
        setSlice(first);
        run("Delete Slice");
       
}

}


Can I simply dereference the images on the hard disk from the virtual
stack instead?  I.e. tell the the virtual stack to no longer include
images within a specified range?  Another approach might be to create a
new virtual stack with the desired images by defining the new slice
range in File->Import->Image Sequence... and closing the original.


Mike

[Eddie Iannuccelli]

Hello,

my java application use ImageJ (1.41) as a library, I noticed that
memory always grows but never decreases so I made a test directly on
ImageJ. When starting ImageJ, the MS Windows task manager show a memory
occupation of 21 MB, after opening a stack  the memory occupation is
about 76 MB, after the stack is closed, the memory never decreases. The
ImageJ internal memory manager show the same memory retention, the same
issue occurs under Linux.

How can I fix this problem, is it an ImageJ problem or a java memory
management problem ?

Regards

--
******************************************
Eddie Iannuccelli
Laboratoire de génétique cellulaire
INRA - Castanet Tolosan
Tel: [phone] / Fax: [phone]

[Michael Doube]

Never mind,

I discovered the VirtualStack class and hacked a very quick plugin:

http://github.com/mdoube/BoneJ/blob/master/src/org/doube/bonej/VirtualDelete.java

Mike

Michael Doube wrote:

> Hi all
>
> Is there a quick way to remove slices from a virtual stack?
>
> I have several GB of microCT slices that I drag 'n drop in their
> directory (i.e. drag 'n drop the directory), but then I want to remove
> the first 300 or so slices and the last 300 or so slices so that I can
> crop the stack without running out of RAM (the result of the crop
> operation is not a virtual stack so must be smaller than IJ's allocated
> memory).
>
> I have automated a slice range deletion with this macro, however it's
> very slow as it has to open each image before deleting it.
>
>
> macro "Delete Slice Range [b]"{
> Dialog.create("Delete Slice Range");
> Dialog.addMessage("Inclusive range of slices to delete");
> Dialog.addNumber("First", getSliceNumber());
> Dialog.addNumber("Last", getSliceNumber());
> Dialog.show();
> first = Dialog.getNumber();
> last = Dialog.getNumber();
> setBatchMode(true);
> deletable = last - first +1;
> for (deleted = 0; deleted < deletable; deleted++){
> showStatus("Deleting slices...");
> showProgress(deleted/(deletable-1));
> setSlice(first);
> run("Delete Slice");
>
> }
>
> }
>
>
> Can I simply dereference the images on the hard disk from the virtual
> stack instead?  I.e. tell the the virtual stack to no longer include
> images within a specified range?  Another approach might be to create a
> new virtual stack with the desired images by defining the new slice
> range in File->Import->Image Sequence... and closing the original.
>
>
> Mike
>  

--
Dr Michael Doube  BPhil BVSc PhD MRCVS
Research Associate
Department of Bioengineering
Imperial College London
South Kensington Campus
London  SW7 2AZ
United Kingdom

[Dong, Hualing L.]

Hi:
 
I am brand new for Image J and not good at this computer software.
 
I have a perinuclear phenotype which I would like to quantify using Image J, but
since it took  while to be an expert, I wonder whether I could send the .TIFF
files to some expert who cold spend hour to find the parameters to analyze it
and send the parameters and results back to me, rather than spending weeks to
learn and find how to quantify this phenotype (I know what the results should
look like).
 
Thanks
 
linda


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

[Bill Mohler]

I thought there was already a deleteSlice(int n) method in
VirtualStack.java. Is that what you used?

Bill

Michael Doube wrote:

> Never mind,
>
> I discovered the VirtualStack class and hacked a very quick plugin:
>
> http://github.com/mdoube/BoneJ/blob/master/src/org/doube/bonej/VirtualDelete.java 
>
>
> Mike
>
> Michael Doube wrote:
>> Hi all
>>
>> Is there a quick way to remove slices from a virtual stack?
>>
>> I have several GB of microCT slices that I drag 'n drop in their
>> directory (i.e. drag 'n drop the directory), but then I want to
>> remove the first 300 or so slices and the last 300 or so slices so
>> that I can crop the stack without running out of RAM (the result of
>> the crop operation is not a virtual stack so must be smaller than
>> IJ's allocated memory).
>>
>> I have automated a slice range deletion with this macro, however it's
>> very slow as it has to open each image before deleting it.
>>
>>
>> macro "Delete Slice Range [b]"{
>> Dialog.create("Delete Slice Range");
>> Dialog.addMessage("Inclusive range of slices to delete");
>> Dialog.addNumber("First", getSliceNumber());
>> Dialog.addNumber("Last", getSliceNumber());
>> Dialog.show();
>> first = Dialog.getNumber();
>> last = Dialog.getNumber();
>> setBatchMode(true);
>> deletable = last - first +1;
>> for (deleted = 0; deleted < deletable; deleted++){
>>     showStatus("Deleting slices...");
>>     showProgress(deleted/(deletable-1));
>>     setSlice(first);
>>     run("Delete Slice");
>>    
>> }
>>
>> }
>>
>>
>> Can I simply dereference the images on the hard disk from the virtual
>> stack instead?  I.e. tell the the virtual stack to no longer include
>> images within a specified range?  Another approach might be to create
>> a new virtual stack with the desired images by defining the new slice
>> range in File->Import->Image Sequence... and closing the original.
>>
>>
>> Mike
>>  
>
>

[Wayne Rasband]

The Process>Batch>Virtual Stack command in the v1.43g daily build will
crop a virtual stack, creating a new virtual stack.

    1. Run Process>Batch>Virtual Stack
    2. Click "Output" and select an empty folder
    3. Select "Crop" from the "Add Macro Code" menu
    4. Edit the macro as needed
    5. Click "Process"

-wayne

 > Hi all

 > Is there a quick way to remove slices from a virtual stack?

 > I have several GB of microCT slices that I drag 'n drop in
 > their directory (i.e. drag 'n drop the directory), but then
 > I want to remove the first 300 or so slices and the last
 > 300 or so slices so that I can crop the stack without
 > running out of RAM (the result of the crop operation is not
 > a virtual stack so must be smaller than IJ's allocated
 > memory).

 > I have automated a slice range deletion with this macro,
 > however it's very slow as it has to open each image before
 > deleting it.


 > macro "Delete Slice Range [b]"{ Dialog.create("Delete Slice
 > Range"); Dialog.addMessage("Inclusive range of slices to
 > delete"); Dialog.addNumber("First", getSliceNumber());
 > Dialog.addNumber("Last", getSliceNumber()); Dialog.show();
 > first = Dialog.getNumber(); last = Dialog.getNumber();
 > setBatchMode(true); deletable = last - first +1; for
 > (deleted = 0; deleted < deletable; deleted++){
 > showStatus("Deleting slices...");
 > showProgress(deleted/(deletable-1)); setSlice(first);
 > run("Delete Slice");

 > }

 > }


 > Can I simply dereference the images on the hard disk from
 > the virtual stack instead?  I.e. tell the the virtual stack
 > to no longer include images within a specified range?
 > Another approach might be to create a new virtual stack
 > with the desired images by defining the new slice range in
 > File->Import->Image Sequence... and closing the original.


 > Mike

[Michael Doube]

Hi Bill

Yes, that's exactly it.  I've included it in my plugin as a command
under Image->Stacks and it now also handles regular stacks, since this
is a job I have to do quite often.  It's now basically instant instead
of taking several minutes.

Mike

Bill Mohler wrote:

> I thought there was already a deleteSlice(int n) method in
> VirtualStack.java. Is that what you used?
>
> Bill
>
> Michael Doube wrote:
>  
>> Never mind,
>>
>> I discovered the VirtualStack class and hacked a very quick plugin:
>>
>> http://github.com/mdoube/BoneJ/blob/master/src/org/doube/bonej/VirtualDelete.java 
>>
>>
>> Mike
>>
>> Michael Doube wrote:
>>    
>>> Hi all
>>>
>>> Is there a quick way to remove slices from a virtual stack?
>>>
>>> I have several GB of microCT slices that I drag 'n drop in their
>>> directory (i.e. drag 'n drop the directory), but then I want to
>>> remove the first 300 or so slices and the last 300 or so slices so
>>> that I can crop the stack without running out of RAM (the result of
>>> the crop operation is not a virtual stack so must be smaller than
>>> IJ's allocated memory).
>>>
>>> I have automated a slice range deletion with this macro, however it's
>>> very slow as it has to open each image before deleting it.
>>>
>>>
>>> macro "Delete Slice Range [b]"{
>>> Dialog.create("Delete Slice Range");
>>> Dialog.addMessage("Inclusive range of slices to delete");
>>> Dialog.addNumber("First", getSliceNumber());
>>> Dialog.addNumber("Last", getSliceNumber());
>>> Dialog.show();
>>> first = Dialog.getNumber();
>>> last = Dialog.getNumber();
>>> setBatchMode(true);
>>> deletable = last - first +1;
>>> for (deleted = 0; deleted < deletable; deleted++){
>>>     showStatus("Deleting slices...");
>>>     showProgress(deleted/(deletable-1));
>>>     setSlice(first);
>>>     run("Delete Slice");
>>>    
>>> }
>>>
>>> }
>>>
>>>
>>> Can I simply dereference the images on the hard disk from the virtual
>>> stack instead?  I.e. tell the the virtual stack to no longer include
>>> images within a specified range?  Another approach might be to create
>>> a new virtual stack with the desired images by defining the new slice
>>> range in File->Import->Image Sequence... and closing the original.
>>>
>>>
>>> Mike
>>>  
>>>      
>>    

--
Dr Michael Doube  BPhil BVSc PhD MRCVS
Research Associate
Department of Bioengineering
Imperial College London
South Kensington Campus
London  SW7 2AZ
United Kingdom

[Joachim Wesner]

Hi Eddie,

This is probably no problem at all!

It is a common misconception that "free memory" is "good memory", maybe
even dating back to the time of the old Commodore C64. Newer operating and
runtime system will keep their
old memory as long as possible and/or use it as a quick memory backup
storage for files. In this way, "free memory" is "bad memory", because it
is unused/idle memory!

This may be very dramatic for example under Linux, where people often ask,
"I now have x GB of memory in my system, but after working for a long time,
it´s almost all gone, what is going wrong?"

Nevertheless, a working OS/VM should trigger a garbage collection,  if
another tasks really request his own memory and finally release enough
ememory for the request,

This might cause a slight delay compared to the case that memory was
already "free" before the 2nd task was started, but the overall benefit of
trying to almost always benefit from ALL available memory in some way, is
generally considered larger!

You can however limit the maximum memory ImageJ will ever use in it´s
config file!

See also:

http://imagejdocu.tudor.lu/doku.php?id=howto:general:imagej_performance_tuning

http://imagejdocu.tudor.lu/doku.php?id=faq:technical:how_do_i_increase_the_memory_in_imagej


Mit freundlichen Grüßen / Best regards

Joachim
____________________________________________

Leica Microsystems CMS GmbH | GmbH mit Sitz in Wetzlar | Amtsgericht
Wetzlar  HRB 2432
Geschäftsführer:  Dr. Stefan Traeger | Dr. Wolf-Otto Reuter | Dr. David Roy
Martyr | Colin Davis
www.leica-microsystems.com



                                                                           
             Eddie Iannuccelli                                            
             <eddie.iannuccell                                            
             [hidden email]                                          An
             R>                         [hidden email]                
             Gesendet von:                                           Kopie
             ImageJ Interest                                              
             Group                                                   Thema
             <[hidden email].          How to release memory              
             GOV>                                                          
                                                                           
                                                                           
             23.09.2009 15:01                                              
                                                                           
                                                                           
              Bitte antworten                                              
                    an                                                    
             eddie.iannuccelli                                            
             @toulouse.inra.fr                                            
                                                                           
                                                                           




Hello,

my java application use ImageJ (1.41) as a library, I noticed that
memory always grows but never decreases so I made a test directly on
ImageJ. When starting ImageJ, the MS Windows task manager show a memory
occupation of 21 MB, after opening a stack  the memory occupation is
about 76 MB, after the stack is closed, the memory never decreases. The
ImageJ internal memory manager show the same memory retention, the same
issue occurs under Linux.

How can I fix this problem, is it an ImageJ problem or a java memory
management problem ?

Regards

--
******************************************
Eddie Iannuccelli
Laboratoire de génétique cellulaire
INRA - Castanet Tolosan
Tel: [phone] / Fax: [phone]



______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

[Eddie Iannuccelli]

I finally fix my problem by using the ImagePlus.flush() method on
ImagePlus instances just before setting them to null.
If it can help ...

Eddie Iannuccelli a écrit :

> Hello,
>
> my java application use ImageJ (1.41) as a library, I noticed that
> memory always grows but never decreases so I made a test directly on
> ImageJ. When starting ImageJ, the MS Windows task manager show a
> memory occupation of 21 MB, after opening a stack  the memory
> occupation is about 76 MB, after the stack is closed, the memory never
> decreases. The ImageJ internal memory manager show the same memory
> retention, the same issue occurs under Linux.
>
> How can I fix this problem, is it an ImageJ problem or a java memory
> management problem ?
>
> Regards
>

--
******************************************
Eddie Iannuccelli
Laboratoire de génétique cellulaire
INRA - Castanet Tolosan
Tel: [phone] / Fax: [phone]