The only time that several images are in memory at once is when the
"adjustment for sampling errors" is being used. Personally, I'm not
that keen on this option, as I believe that this type of adjustment is
best done at the stats stage of the analysis. The adjustment loads a
plane of data from each image within a session, subtracts (some) signal
that correllates with movement, and writes the plane out for all images.
This is why several images need to be in memory at once.
Reading the images as "planks" rather than whole planes would be slower,
requiring more paging, rather than less. This is because reading
larger chunks is more efficient. Memory mapping allows files on disk
to be treated as arrays in memory, and basically acts as extra read only
swap space. When SPM needs to access a voxel, it is read into RAM.
It stays there until the RAM runs out. Therefore, if there is enough
memory, then all data can be loaded in, and will stay there.
In order to resample using sinc interpolation, many neighbouring voxels
are required to sample a single point. This means that the same voxels
are accessed over and over again. When there is limited memory, they
need to be repeatedly paged in from disk. This is almost certainly
what is slowing things down.
As I consider this adjustment to be a bit of a fudge (see the help
comments for spm_realign_ui.m), I did not spend much time optimising
it. The code in question starts at line 405 of spm_reslice.m (the
function reslice_adjust). At the moment, the outer loop is over all
planes (for all images in a session). This could be modified so that
the outer loop is over sessions, the next is over planes (within
session) and the innermost loop is over images within a session.
I suspect that you probably have few enough images within a session
for things to be done efficiently, but too many when lots of sessions
are included within the outer loop. Fixing the ordering of the loops
should speed up this part of the processing.
Regards,
-John
| But i) for motion correction I don't quite understand. As the motion
| correction is rigid body, and everything get's corrected to the first
| image (as reference), but does image 1000 (as an example) need to be
| in memory the same time as image 10, especially when it is in different
| session?
|
| I guess the issue is that when I ran two jobs in parallel that had small
| number of images (200/session) these ran fine.
|
| When I then setup a bigger job in which I have 6 sessions per subject,
| the whole 6 sessions worth of data need not be in memory all at once.
| Especially since these data are seperated in time by up to a few minutes.
| However, the behavior of spm99 is such that it does bring in 1200 images
| when really it should only bring in the 200 at a time. Certainly that
| could be fixed and this is what I am suggesting.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|