[MINC-users] mincblur and single slices

[Alex Zijdenbos]

On Mon, May 17, 2010 at 12:19 PM, Andrew Janke <a.janke at gmail.com> wrote:
> Hi Alex,
>
>> 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?

Not sure - I never tried with older netcdf volumes :) But I just
converted my test images to minc1/netcdf and ran the same mincblur
commands - same result. That may not be the test you were looking for
- if you think it useful I suppose I could dig out an old netcdf
volume and simulate the same scenario?

Also, Claude suggested it might be an issue of version; but I get the
same results both with 0.99.3 and 0.99.6.

-- A