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

[Vladimir S. FONOV]

The question would be how to implement it for all the existing minc 
tools. And who will do it.

On 13-03-20 02:11 PM, Alex Zijdenbos wrote:
> 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
> <mailto: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
>     <mailto: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 <mailto: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
>     <http://ilmarin.info>

-- 
Best regards,

  Vladimir S. FONOV ~ vladimir.fonov <at> gmail.com