[Insight-users] discreteGaussianImageFilter has problemswithinteger images

[Miller, James V (Research)]

Martin, 

I am thinking of embedding a StreamingImageFilter in the DiscreteGaussian
filter, this will cause the DiscreteGaussian to be calculated in chunks
automatically.  This will allow the intermediate results to be done held 
in floats but the input and output to be in shorts.  I am thinking of using
a heuristic where the image in split into something like 2N or N^2 blocks
where N is the number of dimensions of the image.

I am not sure that a memory mapped image would buy much.  I think a 
memory mapped image would still count against your processes address space
(i.e. eat up your virtual memory address space for the process).  In my 
experience, whenever I have used memory mapped techniques, I end up
throwing them away for various reasons (performance, cross platform issues, etc.)
But we could certainly revisit the issue.  One possibility is to provide
another PixelContainer class that is memory mapped.

Jim



-----Original Message-----
From: Martin Urschler [mailto:martin at urschler.info]
Sent: Friday, April 29, 2005 4:09 AM
To: Miller, James V (Research)
Cc: insight-users at itk.org
Subject: Re: [Insight-users] discreteGaussianImageFilter has
problemswithinteger images


hi james,

Miller, James V (Research) wrote:
> Martin, 
> 
> I have made some changes to the DiscreteGaussianImageFilter and the 
> NeighborhoodOperatorImageFilter to support having an operator with
> a different kernel type than the pixel type of the image.
> I need to clean some things up and run some tests then I will 
> try to check it in tomorrow.
> 

thanks for that


as for the round-off errors, I think it is not a question of how much 
round-off error I'll accept but a question of how much memory do I have 
for my operations...
Imagine a 512x512x595 signed short input image (300MB in memory) and a 
signed short output image of the same size that should hold the smoothed 
version. Then (as far as I figured it out) I need during the separable 
convolution either with Discrete or Recursive Gaussian two intermediate 
float volumes of the same size. Even if I use the ReleaseDataFlagOn() 
method for the mini pipeline performing the convolutions, the maximum 
allocation of memory is still 1,8GB (during the y axis convolution 
step)!!! That's already too much for many current workstations.

Btw., are there any plans for transparently creating memory mapped itk 
images, where the access interface is the same as in itk::Image, but the 
raw data is not held in memory entirely but on the hard disk with only a 
certain portion in the memory? I'm not so familiar with the whole 
process object thing so I don't know how hard it would be to implement. 
Naively I would think of "simply" creating a class 
itk::MemoryMappedImage with the identical interface but a different raw 
data model. It might even be possible to put it into the existing image 
with a memory allocation policy...
I'm also not really familiar with the Streaming concept, I guess it 
should be something in that direction but I stopped looking at it, when 
I noticed that only very few ImageFilters support it. Or did I miss 
something there?

thanks,
Martin


-- 
Martin Urschler
TU Graz - Institute for Computer Graphics & Vision
EMail: martin at urschler.info  ICQ: 41586273
Web: http://www.urschler.info
-----------------------------------------------------------
"Wehre nichts ab, was zu dir kommt, und halte nichts fest, was von dir 
geht."