[MINC-users] voxel_loop-like hard-disk access for arbitrary voxel positions

Michel Audette m.audette@aist.go.jp
Thu Nov 25 02:07:03 2004


Hi Louis,

Max worked with me this past summer as a JSPS fellow, and I have his code,
but he didn't do the Level Set part of his research with voxel loop. He did
pre and post-processing with voxel loop, which involved sequential
processing of whole volumes, for which it is suited.

Anyhow, I'm also leaning more and more towards a Linux with Large File
Support capabilities. That should also address the problem, shouldn't it?

Michel

Michel Audette, Ph.D.,
Research Fellow, Surgical Simulation,
Surgical Assist Technology Group,
AIST,
Namiki 1-2,
Tsukuba, Japan,
305-8564.
--------------------------------------------------------
"If you think you can do it, you're right.
 If you think you can't do it, you're still right."
- Henry Ford
----- Original Message ----- 
From: "D. Louis Collins" <louis@bic.mni.mcgill.ca>
To: "Andrew Janke" <andrew_janke@iinet.net.au>; "Michel Audette"
<m.audette@aist.go.jp>
Cc: "Maxime Descoteaux" <mdesco@cim.mcgill.ca>
Sent: Monday, November 22, 2004 10:46 PM
Subject: Re: [MINC-users] voxel_loop-like hard-disk access for arbitrary
voxel positions


>
> Hi guys,
>
> A student of Kaleem worked a bit on this during his MSc (Maxime Descoteau)
> for vessel segmentation using level sets.  I was under the impression (but
> not sure) that he used voxel loop to do his processing since he was using
> ~512^3 volumes.  Michel, do you know if Max used this?
>
> He is currently in southeast asia until Xmas.  He starts a PhD in Nice in
> January.
>
> I think that he is reading mail from time-to-time...
>
> -Louis
>
> On 11/22/04 8:24 AM, "Andrew Janke" <andrew_janke@iinet.net.au> wrote:
>
> > On Wed, 10 Nov 2004, Michel Audette wrote:
> >
> > Michel, I have been giving this a bit of thought over the past few days
and
> > here
> > is what I can come up with...
> >
> >> Are you familiar with Level-set and Fast Marching Level-Set surface
models?
> >
> > Yup.
> >
> >> Basically, it involves an evolving front, and I'm trying to figure out
a way
> >> to implement something like this with voxel_loop-like management (i.e.:
use
> >> as little RAM as possible). In other words, it does not process the
whole
> >> volume at once, but iterates an evolving surface based on a moving
shell
> >> surrounding the surface at the previous simulated time iteration.
Wondering
> >> if this is feasible under MINC, in a manner comparable to voxel_loop...
In
> >> other words, I need to be able to access specific voxels of a given
volume
> >> on disk....
> >
> > ok...
> >
> >> Can anyone comment? I need to process MR volumes that have been
resampled to
> >> CT-density, actually greater than normal CT-density, in the sense that
I
> >> first resample CT data to be isotropic, typically .5mm resolution, and
do
> >> the same for MR. I need to do this with a 32-bit Linux machine, hence
the
> >> problem.
> >
> > The best solution I can think of is the data blocking features of HDF
(minc
> > 2.0)
> > I don't know just how much of this has been implmented in minc 2.0 as of
yet,
> > but at least you could load a set of sub-blocks using a prioritised list
of
> > local neighbouring blocks.
> >
> > There is no sensical way that I can think of where you are going to be
able to
> > prdict where your front will evolve to and thus approaches like
voxel_loop are
> > doomed to fail IMHO. ;(
> >
> > But given that you are iterating, (not recursing) what is the
possibility that
> > you could evolve your front with sub-blocks of the volume, and write
your
> > results out as you go? The simplest approach would be to take the volume
in 8
> > chunks to begin with first.
> >
> >
> >
> > --
> > Andrew Janke (andrew_janke@iinet.net DOT au || www.cmr.uq.edu.au/~rotor)
> > Australia->Brisbane            H: +61 7 3390 6332  || M: +61 4 2138 8581
> > _______________________________________________
> > MINC-users@bic.mni.mcgill.ca
> > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>
>