[MINC-development] MINC2 file with floating-point voxels and slice normalization

[Alex Zijdenbos]

Hi all,

I wanted to throw a question into this discussion - while I understand the
original idea behind the slice-based scaling and it is undoubtedly still
useful to some, IMHO it is a solution for a special case that in all other
(majority of?) cases is nothing but an endless source of frustration and
confusion. I for one, working with MINC for he past 19 years, have not even
_once_ had a need for it; but I have certainly wasted enormous amounts of
time troubleshooting issued caused by it, and writing code to work around
it (I call mincreshape -normalize an awful lot).

I personally think it would make much more sense to make slice-based
scaling the special case, and global scaling the default. In other words,
let users turn slice-based scaling on when they have an application that
requires it; but keep it off by default. Alternatively, even adding an
option to turn it off explicitly would I think be phenomenally useful
(which I would promptly add to all my scripted minc* calls). Or even, let
output volumes inherit the scaling practice of the input volume(s), like
they inherit space variables.

Would this be feasible?

-- A




On Wed, Jan 23, 2013 at 1:12 AM, Andrew Janke <a.janke at gmail.com> wrote:

> Thanks Bert.
>
> So from all that has been said. I'll now re-iterate that I think we
> should dump slice scaling in float/double volumes. The viewing min/max
> functionality should be handled using the file min/max. Yes I know
> this *might* break a few edge cases of functional(time) data in which
> each slice is scaled differently. Still I won't loose much sleep
> breaking this as it will only work in one dimension in any case.
>
> As mentioned I can't see in the code where Register/Display or postf
> or any other viewer that I know of reads this slice scaling. the valid
> range yes, but that's different.
>
>
> a
>
>
> On 22 January 2013 07:12, Robert VINCENT <bert at bic.mni.mcgill.ca> wrote:
> > Hi all,
> >
> > My recollection is pretty dim at this point, but I think we probably
> assumed
> > that the image min and max could be used to scale even fp voxels, even
> if it
> > didn't really make sense. It's not like fp normalization is completely
> > unheard-of.
> >
> > FWIW, NIfTI-1 defined per-image scaling of fp voxels, although it was
> > clearly not the recommended usage. I probably found it hard to believe
> > NIfTI-1 would be more general than MINC in any area...
> >
> >     -bert
> >
> >
> > On Mon, 21 Jan 2013, Vladimir S. FONOV wrote:
> >
> >> Hell Everybody,
> >>
> >> On 2013-01-21, at 10:28 AM, "John G. Sled" <jgsled at phenogenomics.ca>
> >> wrote:
> >>>
> >>> Vlad's question of whether to dispense with slice scaling entirely is
> >>> worth further discussion.
> >>
> >>
> >>
> >> I never said that we need to dispose of slice-scaling in case of storing
> >> floating-point values in integer volume. I said that we need to dispose
> of
> >> per-slice min-max information in case of floating-point volume, since
> it is
> >> useless  and confusing.  At least it was confusing enough for the MINC2
> api
> >> authors to misinterpret.
> >> ---
> >> Best regards,
> >>
> >> Vladimir S. FONOV ~ v.s.fonov <at> ilmarin.info
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> MINC-development mailing list
> >> MINC-development at bic.mni.mcgill.ca
> >> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development
> >>
> > _______________________________________________
> > MINC-development mailing list
> > MINC-development at bic.mni.mcgill.ca
> > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development
> _______________________________________________
> MINC-development mailing list
> MINC-development at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.bic.mni.mcgill.ca/pipermail/minc-development/attachments/20130320/0a725f03/attachment.html>