[MINC-users] mincblur and single slices

[Claude LEPAGE]

Hi Alex,

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). :-)

Claude


> 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
>
>    http://dl.dropbox.com/u/5709165/mincblur/test_blur.jpg
>
> 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.
>
> Thanks,
>
> -- Alex
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>