making memory

[Robert Martin-3]

I have a question about the program memory.

I am downloading a sequence of DICOM images and was limited to about 15
slices because the log file told me that I was using all of my 256MB of
memory.  I then went into the edit/options/memory function to change my
maximum memory allowed to 1.5GB (I have 2.0 GB Ram).

After closing and restarting the program, the icon doesn't work and I
have to click the ij.jar file instead - but in this instance the log
file tells me that I have only 63MB of Ram to use, (about 5 images) -
much less than I started with.

Does anyone know what went wrong or can suggest an antedote? Does
having an external harddrive solve this or does it have to be ram
memory?  I ideally have to compile 1800 images or so into a 3-D data
viewer to do my analysis.

Thanks so much in advance

[Wayne Rasband]

\I have a question about the program memory.

>
> I am downloading a sequence of DICOM images and was limited
> to about 15 slices because the log file told me that I was
> using all of my 256MB of memory.  I then went into the
> edit/options/memory function to change my maximum memory
> allowed to 1.5GB (I have 2.0 GB Ram).
>
> After closing and restarting the program, the icon doesn't
> work and I have to click the ij.jar file instead - but in
> this instance the log file tells me that I have only 63MB of
> Ram to use, (about 5 images) - much less than I started
> with.

You should be able get ImageJ running again by using a text editor to
change the second line of the ImageJ.cfg file (in the ImageJ folder) to
something like:

      -Xmx512m -cp ij.jar ij.ImageJ

> Does anyone know what went wrong or can suggest an antedote?
> Does having an external harddrive solve this or does it have
> to be ram memory?  I ideally have to compile 1800 images or
> so into a 3-D data viewer to do my analysis.

ImageJ normally requires that all image reside in RAM but the Virtual
Stack Opener plugin at

     http://rsb.info.nih.gov/ij/plugins/virtual-opener.html

will allow you to view and analyze all 1800 images. Another way to look
at the images would be to use the Open Next command that was added in
ImageJ 1.35k. It allows you to view the next image in a sequence by
pressing shift-o and the previous one by pressing alt-shift-o.

-wayne

[Gary Chinga]

Hi!,

We have some applications written in Matlab (self executable) and I wonder if it is possible to call these applications from ImageJ, so we have a ImageJ plugin as the user interface for calling some external matlab applications.

Thanks for your help.

Gary.
 

[ToeKnee Lacey]

You might be interested in Daniel Sage's Matlab/ImageJ interface (http://bigwww.epfl.ch/sage/soft/mij/).
 This lets you run ImageJ within matlab (as long as you have the JVM running)
and exchange image data between them.  The source code is available so you
could extend it to suit your purposes.

-tony

--- ImageJ Interest Group
<[hidden email] wrote:
Hi!,
>
> We have some applications written
in Matlab (self executable) and I wonder if it is possible to call these applications
from ImageJ, so we have a ImageJ plugin as the user interface for calling
some external matlab applications.
>
> Thanks for your help.
>
> Gary.

>  
>
>
>

[Robert Martin-3]

I just realized that I was disabling the changes that I put into effect
and when I unblocked the changes, I was able to get 85 images from my
catscan which took 473MB of Memory ( the catscan has a very high
resolution!).  Although this is better than before (only 15 images) I
am wondering why the system conked out at only 473MB and not the 1500
MB that I changed it to (is some of this ram used for other processes
running the program that I am not aware of).  I noted that using 3-D
data viewer took a whole bunch of memory as well and I need to use this
program or something similar to look at vertical slices.

Basically, I need to have all 1800 images open in order to perform a
vertical slice and I'm wondering if this is a feasible idea or if I
should create some sort of file structure that 3-D data viewer could
call up data from a disk in a more regular format (I calculate that the
images would amount to 473MB*1800/85~=10GB Ram which no system has
these days though I might be able to convert the data to 8 or 16 bit
unsigned if that helps).  

Basically, I am wondering if you have any ideas on how to do this?

Thanks so much!
Robert



Wayne Rasband wrote:

>\I have a question about the program memory.
>>
>> I am downloading a sequence of DICOM images and was limited
>> to about 15 slices because the log file told me that I was
>> using all of my 256MB of memory.  I then went into the
>> edit/options/memory function to change my maximum memory
>> allowed to 1.5GB (I have 2.0 GB Ram).
>>
>> After closing and restarting the program, the icon doesn't
>> work and I have to click the ij.jar file instead - but in
>> this instance the log file tells me that I have only 63MB of
>> Ram to use, (about 5 images) - much less than I started
>> with.
>
>You should be able get ImageJ running again by using a text editor to
>change the second line of the ImageJ.cfg file (in the ImageJ folder) to
>something like:
>
>      -Xmx512m -cp ij.jar ij.ImageJ
>
>> Does anyone know what went wrong or can suggest an antedote?
>> Does having an external harddrive solve this or does it have
>> to be ram memory?  I ideally have to compile 1800 images or
>> so into a 3-D data viewer to do my analysis.
>
>ImageJ normally requires that all image reside in RAM but the Virtual
>Stack Opener plugin at
>
>     http://rsb.info.nih.gov/ij/plugins/virtual-opener.html
>
>will allow you to view and analyze all 1800 images. Another way to look
>at the images would be to use the Open Next command that was added in
>ImageJ 1.35k. It allows you to view the next image in a sequence by
>pressing shift-o and the previous one by pressing alt-shift-o.
>
>-wayne
>

[Jeff Brandenburg]

On Jan 16, 2006, at 4:14 PM, Robert Edward Martin wrote:
> Basically, I need to have all 1800 images open in order to perform a
> vertical slice and I'm wondering if this is a feasible idea or if I
> should create some sort of file structure that 3-D data viewer could
> call up data from a disk in a more regular format (I calculate that the
> images would amount to 473MB*1800/85~=10GB Ram which no system has
> these days though I might be able to convert the data to 8 or 16 bit
> unsigned if that helps).

We wrestle with the same problem here.  Even if you could get
everything into RAM, this kind of reslicing can be hideously expensive.
  It's not so bad to reslice row-wise, but if you have to reslice
column-wise ("rotate a cube left or right"), you essentially make your
system's caching strategies worthless.  It's worse if you're working
with ImageJ-style "virtual stacks", because there you're repeatedly
reopening and rereading files, and it can take minutes to generate a
single slice.

I've seen two approaches used with some success.  The first, and most
general, recasts the volume as a set of smaller cubes, ideally each
small enough to fit into the fastest cache RAM available -- say 8x8x8
or 16x16x16.  This slows things down for some special cases; for
example, if you start with axial data, displaying one axial slice would
require that you read ~2MB of data, while generating an axial slice
from the cube representation would make you read 16MB or 32MB of data.  
But generating a slice in *any* of the three basic orientations takes
the same amount of overhead with cubes, whereas the "wrong" reslice of
your original data could force you to read hundreds or thousands of
times more data.  Better yet, the cube representation lets you generate
arbitrary oblique slices with about the same overhead.  (Does anyone
know if this is what Volume Viewer does?)

The second, and easiest, reslices the volume up-front and stores three
copies, one in each orientation.  This means you'd need 30GB rather
than 10GB to store your volume, but it would let you use Virtual Stack
Opener (or any tool that works similarly) to do quick browsing in any
of the three orientations.  I'm considering adopting this approach to
let our users browse images in multiple orientations -- it's easy to
understand, easy to implement, and I'd claim that it gives optimal
speed (at the obvious expense of space).

Here's a team at Drexel that's developed a client-server system for
viewing large datasets in cube ("macrovoxel") format, although the
server isn't implemented in Java:

http://www.neuroterrain.org/

Here's a project at the Pittsburgh Supercomputing Center that serves up
*really* large datasets from a hierarchical-cube format:

http://www.psc.edu/biomed/research/VB/

Here's some more detailed discussion of the PSC system implementation
(again, alas, not in Java):

http://www.psc.edu/biomed/research/VH/PVB/implementation/implement.htm
http://www.psc.edu/~smp/files/vb-presentation.pdf

Note that they're aiming for interactive browsing within a 25-TERABYTE
TEM volume data set, where each "slice" is ~60K pixels on a side -- so
large that even a single slice can't fit into a 32-bit address space!  
So, there's plenty of room for our data sets to grow. :-)
--
        -jeffB (Jeff Brandenburg, Duke Center for In-Vivo Microscopy)