Q:I ran into a number of mincblur oddities when dealing with single-slice minc volumes. For example, I have a single-slice image that, when blurred with:

  mincblur -no_apodize -dim 2 -fwhm 1 <in.mnc> <out>

generates the expected result; However, when I happened to convert the datatype of that same slice from byte to short ran the same mincblur call, the result suffered from a wraparound effect. See the image at

with the underlying data in

  http://dl.dropbox.com/u/5709165/mincblur/test_blur.tar.gz

I have also seen such wraparound effects appear as a function of image dimensions (regardless of data type). So from what I can tell mincblur is broken when it comes to dealing with single-slice data; but broken in a somewhat unpredictable way because in certain circumstances it will actually do the right thing (as in the ‘byte’ example I gave). Padding the image with a slice above and below will make the problem from this example go away; but again, I am not sure how the failures depend on the number of slices added.

Is anybody familiar enough with the innards of mincblur to address this issue? Ideally it would be fixed such as to allow proper 2D blurring on single-slice volumes; but barring that, it would be good if at least it generated an error as opposed to silently and unpredictably doing the right or wrong thing. http://www.bic.mni.mcgill.ca/pipermail/minc-users/2010-May/002745.html

A: I have also seen such wraparound effects appear as a function of image dimensions (regardless of data type). So from what I can tell mincblur is broken when it comes to dealing with single-slice data; but broken in a somewhat unpredictable way because in certain circumstances it will actually do the right thing (as in the ‘byte’ example I gave). Padding the image with a slice above and below will make the problem from this example go away; but again, I am not sure how the failures depend on the number of slices added.

Louis wrote mincblur and used an FFT to do the blurring, thus there is a fair bit of dimension re-ordering going on before and after the blur. From my looking in the code of mincblur regarding this I suspect there is a hardcoded dimension name going wrong somewhere in pathological cases. Especially if these are MINC 2 files and apparent dimension ordering is being used…

Would this match your experience or is this happening with older netcdf based MINC files also?

A: After some investigation, this bug has been fixed. Somewhere deep in initialize_minc_input_from_minc_id() (file minc/volume_io/Volumes/input_mnc.c), the new code looks like:

   file→n_slab_dims = 0;
   slab_size = 1;
   int unit_size = get_type_size( get_volume_data_type(volume) );
   int full_dim = 1;

   for( d = file→n_file_dimensions-1; d ≥ 0; d— ) {
     if( file→to_volume_index[d] != INVALID_AXIS ) {
       if( MI_MAX_VAR_BUFFER_SIZE > file→sizes_in_file[d] * slab_size * unit_size && full_dim ) {
         slab_size *= file→sizes_in_file[d];
         file→n_slab_dims++;  /* integral number of complete dimensions */
       } else {
         slab_size *= MIN( file→sizes_in_file[d],
                           (hsize_t)( MI_MAX_VAR_BUFFER_SIZE / ( slab_size * unit_size ) ) );
         full_dim = 0;
       }
     }
   }

In comparison, the old code from minc-2.0.18 does not have the full_dim check. There is an analogous piece of code in output_mnc.c. Do I really need to explain what this cryptic piece of code is doing or can your trust me? The changes are in CVS:

2009–11–06 Claude Lepage <claude@@bic.mni.mcgill.ca>

  * volume_io/Volumes/output_mnc.c: fix output buffers for a slice
         as only first buffer would be written out

So either checkout minc from cvs or wait till Andrew releases the next version (which should be two months ago). :-)