[Insight-users] moving image and memory

Tue Jul 6 22:03:16 EDT 2004

Hi Michael,

A naive option is to compute the bounding box of the projection
of the fixed image onto the moving image given the current transform.

Then add some security margins to that bounding box in order to
define a region and use that region for extracting that piece of the
moving image.

If you are doing this in a distributed environment you could probably
have one or several machines dedicated to providing the right subregions
of the  moving image to the machines that are actually computing
contributions to the image metric.

This naive method will not be very effective if your transform has
rotations with large angles. In that case you may even save some time
by creating an intermediate resampled version of the moving image
in order to get a better aligned dataset. At the end for the
registration you should compensate for the transfrom used for creating
the intermediate resampled image.

We will be quite interested to hear back from you regarding the
solution you find to this problem, since this situation will become
more and more common as dataset sizes grow bigger.

  Regards,

    Luis

--------------
Michael wrote:

>  Hi,
> 
> I'm thinking about the following problem... In a registration task, 
> there might be a fixed image that is much smaller than the corresponding 
> moving image, i.e. it contains only a part of what is represented by the 
> moving image. In this case, it's obviously a waste of memory to keep the 
> entire moving image in memory during the whole registration run, since 
> during each iteration only a small part is accessed.
> 
> In my case (which differs slightly from above explanation), I want to 
> calculate partial results of the metric value based on parts of the 
> fixed image (similar as done in the ThreadedGetValue of the 
> MatchCardinalityImageToImageMetric) on different computers. The case is 
> similar to above situation, because a small fixed image (a subimage of 
> the original fixed image) is mapped to a large moving image on each 
> host. However, the case differs in that it there might be parts where 
> the region of the initial mapping (i.e. initial transform parameters 
> applied) is entirely outside of the region of the final mapping. 
> Consider for example a 2D rigid transform: For a slightly wrong angle, a 
> (transformed) region around the center of the transform is almost 
> identical to the region for the correct angle. If the region is far away 
> from the center, however, they might not even overlap. I'd say this 
> situation is rather unusual for a registration where a small fixed image 
> is registered to a large moving image. In my opinion, this fact makes it 
> (even more) difficult to estimate the region of the moving image that 
> will be accessed during the whole registration run.
> 
> So, the question is, how is it efficiently possible to keep the right 
> parts of the moving image in memory? Considering the access 
> characteristics it seems to me that some kind of "caching" would be 
> appropriate. That is, keeping those regions in memory that have been 
> accessed recently and store regions that have not been accessed for a 
> long time on disk. If a region is accessed and not in main memory, it 
> would just have to be loaded from disk.
> 
> Obviously, the operating system provides some support for this (paging). 
> However, I'm not quite sure whether this support is quite optimal for 
> the described problem. Consider the following (2D-) image:
> 
> -----------------------------
> ¦01 02 03 04 05 06 07 08 09 10¦
> ¦                             ¦
> ¦11 12 13 14 15 16 17 18 19 20¦
> ¦                             ¦
> ¦21 22 23 24 25 26 27 28 29 30¦
> ¦                             ¦
> ¦31 32 33 34 35 36 37 38 39 40¦
> ¦                             ¦
> ¦41 42 43 44 45 46 47 48 49 50¦
> ¦                             ¦
> ¦51 52 53 54 55 56 57 58 59 60¦
> ¦                             ¦
> ¦61 62 63 64 65 66 67 68 69 70¦
> ¦-----------------------------¦
> 
> and the indicated subimage:
> 
> ------------------------------
> ¦01 02 03 04 05 06 07 08 09 10¦
> ¦         -----               ¦
> ¦11 12 13¦14 15¦16 17 18 19 20¦
> ¦        ¦     ¦              ¦
> ¦21 22 23¦24 25¦26 27 28 29 30¦
> ¦        ¦     ¦              ¦
> ¦31 32 33¦34 35¦36 37 38 39 40¦
> ¦        ¦     ¦              ¦
> ¦41 42 43¦44 45¦46 47 48 49 50¦
> ¦        ¦     ¦              ¦
> ¦51 52 53¦54 55¦56 57 58 59 60¦
> ¦         -----               ¦
> ¦61 62 63 64 65 66 67 68 69 70¦
> ¦-----------------------------¦
> 
> I expect that the data is stored as a contiugous block in the order of 
> the numbers in the pictures.
> 
> Say one of the numbers in above images represents x bytes and we have a 
> page size of 8*x bytes. In order to keep the indicated area in memory, 
> we have to have 5 pages (one for each line of the region of interest) in 
> main memory, that is 5*8*x bytes. However, we only require 5*2*x bytes 
> (size of the region), which is 4 times less.
> 
> Another problem with the OS support is, how can I avoid that large 
> amounts of swap-space are used to store data that might never be 
> accessed? Maybe the image could be stored on disk as an ordinary file 
> instead of having (parts of) it swapped out on disk. That way swap space 
> is free for other processes. Are there any reasons that argue for having 
> the data in swap space instead of having it in an ordinary file?
> 
> Because of above considerations, I think that it might be better to 
> manually (that is, not by the OS) control which blocks have to be stored 
> on disk and which ones have to be kept in memory. This would maybe even 
> allow to apply some prediction methods (that might be more appropriate 
> than those of the OS).
> 
> Is there some built-in support in ITK, that helps to solve this problem 
> (e.g. a way to store an image in blocks that can be loaded from disk if 
> necessary)? Could maybe memory mapped files help to provide optimal 
> access to the image data (it seems to me that the problem about page 
> size remains...)? If yes, is there some support for this in ITK? Does 
> anybody see a better solution than what I've called "caching" or any 
> fundamental problems with that approach?
> 
> Any comments are appreciated.
> 
> Thanks,
> 
> Michael
> 
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
> 