> I'm interested in writing the coregistration algorithm
> of SPM2 in C as a "standalone" application.
> Looking at spm_coreg.m I see the 2 functions
> "loaduint8" and "smoothuint8". Why is it that we fit
> the pixel values between 0..255? Especially when, in
> example, spm_convol.c seems to deal with any data type
> (if dtype=SPM_DOUBLE, SPM_FLOAT, etc..). Does it not
> result in a loss during conversion?
There is a slight loss of information, but as the joint histograms are 256x256
then it's not such a problem. You could preserve the original values and use
linear interpolation to fill the histograms, but I don't think it would
necessarily give you so much extra.
>
> Another question: in spm_conv_vol.c, what is the role
> of the parameters double *oVol and mxArray
> *wplane_args[3]?
oVol is there so that the convolved data can be returned in memory. It has the
deliberate side effect of changing a right-hand argument. This is very bad
coding practice - but it can save memory. It gets cast to whatever datatype
is required. The reason for this is that I don't code in C++, and instead
use a fudge in C.
wplane_args are used by "mexCallMATLAB(0, NULL, 3, wplane_args,
"spm_write_plane");" for writing a plane of data to disk.
> Since I'm not using MatLab API I have to get rid of
> all the mxFunctions, and I'd like to be sure I'm
> getting it right. oVol seems to represent a pointer to
> the second parameter of the function(prhs[1]), that is
> to say, when you call it from smooth_uint8 in
> spm_coregister.m, "V.uint8", which sould be, if I'm
> right, a pointer to the pixel data from 0 to 255. It
> seemed natural to use unsigned char for those data,
> but then oVol is a pointer to double... As far as
> wplane_args is concerned, I have no clue about what it
> is for.
>
> My final question is how is the data managed in
> memory?
> I mean, for example, in the MAPTYPE structure, how are
> the pixel data sorted? Looking at spm_mapping.c I see
> that the field maps.data is an array of pointers, more
> precisely an array of maps.dim[2] pointers which
> should represent the number of slices in a 3D volume.
> Does this mean that the data is represented as one big
> array, with pixel values sorted rows by rows and slice
> by slice? Or is it more tricky than that?
Data is represented as one big memory mapped array.
Best regards,
-John
|