[Insight-users] moving image and memory

[Michael]

  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