From zijdenbos at gmail.com  Wed Mar 20 14:11:21 2013
From: zijdenbos at gmail.com (Alex Zijdenbos)
Date: Wed, 20 Mar 2013 14:11:21 -0400
Subject: [MINC-development] MINC2 file with floating-point voxels and
 slice normalization
In-Reply-To: <CAG0CB20SkC14zzFxFwU_HA5wZwn8e4c1fmMBOe+K-ZzheyofAw@mail.gmail.com>
References: <CAMCwi7PfmmFG23EHfa43QL6O2hq0V6ZspkgjNh3BP2wvNpKpEg@mail.gmail.com>
	<50FD5E95.9070800@phenogenomics.ca>
	<C2869AB6-34F0-49CD-B703-2E9405569B91@gmail.com>
	<Pine.LNX.4.64.1301211530360.5780@agrippa.bic.mni.mcgill.ca>
	<CAG0CB20SkC14zzFxFwU_HA5wZwn8e4c1fmMBOe+K-ZzheyofAw@mail.gmail.com>
Message-ID: <CABEEk15Z4aJ1xupWODObeCww-bchPmZusjocS2yPE2qRwM+YkA@mail.gmail.com>

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>

From vladimir.fonov at gmail.com  Wed Mar 20 14:17:12 2013
From: vladimir.fonov at gmail.com (Vladimir S. FONOV)
Date: Wed, 20 Mar 2013 14:17:12 -0400
Subject: [MINC-development] MINC2 file with floating-point voxels and
 slice normalization
In-Reply-To: <CABEEk15Z4aJ1xupWODObeCww-bchPmZusjocS2yPE2qRwM+YkA@mail.gmail.com>
References: <CAMCwi7PfmmFG23EHfa43QL6O2hq0V6ZspkgjNh3BP2wvNpKpEg@mail.gmail.com>
	<50FD5E95.9070800@phenogenomics.ca>
	<C2869AB6-34F0-49CD-B703-2E9405569B91@gmail.com>
	<Pine.LNX.4.64.1301211530360.5780@agrippa.bic.mni.mcgill.ca>
	<CAG0CB20SkC14zzFxFwU_HA5wZwn8e4c1fmMBOe+K-ZzheyofAw@mail.gmail.com>
	<CABEEk15Z4aJ1xupWODObeCww-bchPmZusjocS2yPE2qRwM+YkA@mail.gmail.com>
Message-ID: <5149FD28.7010809@gmail.com>

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

From a.janke at gmail.com  Wed Mar 20 15:39:41 2013
From: a.janke at gmail.com (Andrew Janke)
Date: Thu, 21 Mar 2013 05:39:41 +1000
Subject: [MINC-development] MINC2 file with floating-point voxels and
 slice normalization
In-Reply-To: <CABEEk15Z4aJ1xupWODObeCww-bchPmZusjocS2yPE2qRwM+YkA@mail.gmail.com>
References: <CAMCwi7PfmmFG23EHfa43QL6O2hq0V6ZspkgjNh3BP2wvNpKpEg@mail.gmail.com>
	<50FD5E95.9070800@phenogenomics.ca>
	<C2869AB6-34F0-49CD-B703-2E9405569B91@gmail.com>
	<Pine.LNX.4.64.1301211530360.5780@agrippa.bic.mni.mcgill.ca>
	<CAG0CB20SkC14zzFxFwU_HA5wZwn8e4c1fmMBOe+K-ZzheyofAw@mail.gmail.com>
	<CABEEk15Z4aJ1xupWODObeCww-bchPmZusjocS2yPE2qRwM+YkA@mail.gmail.com>
Message-ID: <CAG0CB234ERg=0OsiB=wYaFJ6Cvaa0Tg3J40f2LD6pQoYCD9NPA@mail.gmail.com>

Hi Alex,

On 21 March 2013 04:11, Alex Zijdenbos <zijdenbos at gmail.com> wrote:
> 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?

If space is cheap then you already have a solution for this, just
convert all your native datasets to float. This will then mean that
every bit of processing past this will inherit global scaling.


a

From vladimir.fonov at gmail.com  Wed Mar 20 15:50:52 2013
From: vladimir.fonov at gmail.com (Vladimir S. FONOV)
Date: Wed, 20 Mar 2013 15:50:52 -0400
Subject: [MINC-development] MINC2 file with floating-point voxels and
 slice normalization
In-Reply-To: <CAG0CB234ERg=0OsiB=wYaFJ6Cvaa0Tg3J40f2LD6pQoYCD9NPA@mail.gmail.com>
References: <CAMCwi7PfmmFG23EHfa43QL6O2hq0V6ZspkgjNh3BP2wvNpKpEg@mail.gmail.com>
	<50FD5E95.9070800@phenogenomics.ca>
	<C2869AB6-34F0-49CD-B703-2E9405569B91@gmail.com>
	<Pine.LNX.4.64.1301211530360.5780@agrippa.bic.mni.mcgill.ca>
	<CAG0CB20SkC14zzFxFwU_HA5wZwn8e4c1fmMBOe+K-ZzheyofAw@mail.gmail.com>
	<CABEEk15Z4aJ1xupWODObeCww-bchPmZusjocS2yPE2qRwM+YkA@mail.gmail.com>
	<CAG0CB234ERg=0OsiB=wYaFJ6Cvaa0Tg3J40f2LD6pQoYCD9NPA@mail.gmail.com>
Message-ID: <CAMCwi7P7eR5UrDoFkUJ9t+5_k3Ph7_oKJjhqbNPdZ0F_OGM9Zw@mail.gmail.com>

I think the question here is how to disable it for non floating point data?

On Wed, Mar 20, 2013 at 3:39 PM, Andrew Janke <a.janke at gmail.com> wrote:
> Hi Alex,
>
> On 21 March 2013 04:11, Alex Zijdenbos <zijdenbos at gmail.com> wrote:
>> 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?
>
> If space is cheap then you already have a solution for this, just
> convert all your native datasets to float. This will then mean that
> every bit of processing past this will inherit global scaling.

--
Best regards,

 Vladimir S. Fonov ~ vladimir <dot> fonov <at> gmail <dot> com

On Wed, Mar 20, 2013 at 3:39 PM, Andrew Janke <a.janke at gmail.com> wrote:
> Hi Alex,
>
> On 21 March 2013 04:11, Alex Zijdenbos <zijdenbos at gmail.com> wrote:
>> 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?
>
> If space is cheap then you already have a solution for this, just
> convert all your native datasets to float. This will then mean that
> every bit of processing past this will inherit global scaling.
>
>
> a
> _______________________________________________
> MINC-development mailing list
> MINC-development at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development



-- 
Best regards,

 Vladimir S. Fonov ~ v.s.fonov <@> ilmarin.info

From zijdenbos at gmail.com  Wed Mar 20 15:56:09 2013
From: zijdenbos at gmail.com (Alex Zijdenbos)
Date: Wed, 20 Mar 2013 15:56:09 -0400
Subject: [MINC-development] MINC2 file with floating-point voxels and
 slice normalization
In-Reply-To: <CAMCwi7P7eR5UrDoFkUJ9t+5_k3Ph7_oKJjhqbNPdZ0F_OGM9Zw@mail.gmail.com>
References: <CAMCwi7PfmmFG23EHfa43QL6O2hq0V6ZspkgjNh3BP2wvNpKpEg@mail.gmail.com>
	<50FD5E95.9070800@phenogenomics.ca>
	<C2869AB6-34F0-49CD-B703-2E9405569B91@gmail.com>
	<Pine.LNX.4.64.1301211530360.5780@agrippa.bic.mni.mcgill.ca>
	<CAG0CB20SkC14zzFxFwU_HA5wZwn8e4c1fmMBOe+K-ZzheyofAw@mail.gmail.com>
	<CABEEk15Z4aJ1xupWODObeCww-bchPmZusjocS2yPE2qRwM+YkA@mail.gmail.com>
	<CAG0CB234ERg=0OsiB=wYaFJ6Cvaa0Tg3J40f2LD6pQoYCD9NPA@mail.gmail.com>
	<CAMCwi7P7eR5UrDoFkUJ9t+5_k3Ph7_oKJjhqbNPdZ0F_OGM9Zw@mail.gmail.com>
Message-ID: <CABEEk16seZ9qdqxpdys_1Hoh6aGBJ3ReA-pn8aWFE8egq4CSmQ@mail.gmail.com>

Right - and in fact I think this should actually be the default; but I'd
settle for a way to turn slice-based scaling off :)
Switching over to float volumes would be prohibitive space-wise for much of
the data I work with nowadays (which is high on resolution but low on
dynamic range).

-- A


On Wed, Mar 20, 2013 at 3:50 PM, Vladimir S. FONOV <vladimir.fonov at gmail.com
> wrote:

> I think the question here is how to disable it for non floating point data?
>
> On Wed, Mar 20, 2013 at 3:39 PM, Andrew Janke <a.janke at gmail.com> wrote:
> > Hi Alex,
> >
> > On 21 March 2013 04:11, Alex Zijdenbos <zijdenbos at gmail.com> wrote:
> >> 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?
> >
> > If space is cheap then you already have a solution for this, just
> > convert all your native datasets to float. This will then mean that
> > every bit of processing past this will inherit global scaling.
>
> --
> Best regards,
>
>  Vladimir S. Fonov ~ vladimir <dot> fonov <at> gmail <dot> com
>
> On Wed, Mar 20, 2013 at 3:39 PM, Andrew Janke <a.janke at gmail.com> wrote:
> > Hi Alex,
> >
> > On 21 March 2013 04:11, Alex Zijdenbos <zijdenbos at gmail.com> wrote:
> >> 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?
> >
> > If space is cheap then you already have a solution for this, just
> > convert all your native datasets to float. This will then mean that
> > every bit of processing past this will inherit global scaling.
> >
> >
> > a
> > _______________________________________________
> > MINC-development mailing list
> > MINC-development at bic.mni.mcgill.ca
> > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development
>
>
>
> --
> Best regards,
>
>  Vladimir S. Fonov ~ v.s.fonov <@> ilmarin.info
> _______________________________________________
> 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/e23f7e5e/attachment.html>

From a.janke at gmail.com  Wed Mar 20 16:00:28 2013
From: a.janke at gmail.com (Andrew Janke)
Date: Thu, 21 Mar 2013 06:00:28 +1000
Subject: [MINC-development] MINC2 file with floating-point voxels and
 slice normalization
In-Reply-To: <CABEEk16seZ9qdqxpdys_1Hoh6aGBJ3ReA-pn8aWFE8egq4CSmQ@mail.gmail.com>
References: <CAMCwi7PfmmFG23EHfa43QL6O2hq0V6ZspkgjNh3BP2wvNpKpEg@mail.gmail.com>
	<50FD5E95.9070800@phenogenomics.ca>
	<C2869AB6-34F0-49CD-B703-2E9405569B91@gmail.com>
	<Pine.LNX.4.64.1301211530360.5780@agrippa.bic.mni.mcgill.ca>
	<CAG0CB20SkC14zzFxFwU_HA5wZwn8e4c1fmMBOe+K-ZzheyofAw@mail.gmail.com>
	<CABEEk15Z4aJ1xupWODObeCww-bchPmZusjocS2yPE2qRwM+YkA@mail.gmail.com>
	<CAG0CB234ERg=0OsiB=wYaFJ6Cvaa0Tg3J40f2LD6pQoYCD9NPA@mail.gmail.com>
	<CAMCwi7P7eR5UrDoFkUJ9t+5_k3Ph7_oKJjhqbNPdZ0F_OGM9Zw@mail.gmail.com>
	<CABEEk16seZ9qdqxpdys_1Hoh6aGBJ3ReA-pn8aWFE8egq4CSmQ@mail.gmail.com>
Message-ID: <CAG0CB22hEghz+GnH43EtE2b8VyLwYKyHxNxtNMNqNpX2Es8pXw@mail.gmail.com>

On 21 March 2013 05:56, Alex Zijdenbos <zijdenbos at gmail.com> wrote:
> Right - and in fact I think this should actually be the default; but I'd
> settle for a way to turn slice-based scaling off :)
> Switching over to float volumes would be prohibitive space-wise for much of
> the data I work with nowadays (which is high on resolution but low on
> dynamic range)

I was always of the impression that most MINC tools if given an input
volume with no slice scaling will output a volume without slice
scaling. Perhaps this is wrong?


a

From vladimir.fonov at gmail.com  Wed Mar 20 16:05:41 2013
From: vladimir.fonov at gmail.com (Vladimir S. FONOV)
Date: Wed, 20 Mar 2013 16:05:41 -0400
Subject: [MINC-development] MINC2 file with floating-point voxels and
 slice normalization
In-Reply-To: <CAG0CB22hEghz+GnH43EtE2b8VyLwYKyHxNxtNMNqNpX2Es8pXw@mail.gmail.com>
References: <CAMCwi7PfmmFG23EHfa43QL6O2hq0V6ZspkgjNh3BP2wvNpKpEg@mail.gmail.com>
	<50FD5E95.9070800@phenogenomics.ca>
	<C2869AB6-34F0-49CD-B703-2E9405569B91@gmail.com>
	<Pine.LNX.4.64.1301211530360.5780@agrippa.bic.mni.mcgill.ca>
	<CAG0CB20SkC14zzFxFwU_HA5wZwn8e4c1fmMBOe+K-ZzheyofAw@mail.gmail.com>
	<CABEEk15Z4aJ1xupWODObeCww-bchPmZusjocS2yPE2qRwM+YkA@mail.gmail.com>
	<CAG0CB234ERg=0OsiB=wYaFJ6Cvaa0Tg3J40f2LD6pQoYCD9NPA@mail.gmail.com>
	<CAMCwi7P7eR5UrDoFkUJ9t+5_k3Ph7_oKJjhqbNPdZ0F_OGM9Zw@mail.gmail.com>
	<CABEEk16seZ9qdqxpdys_1Hoh6aGBJ3ReA-pn8aWFE8egq4CSmQ@mail.gmail.com>
	<CAG0CB22hEghz+GnH43EtE2b8VyLwYKyHxNxtNMNqNpX2Es8pXw@mail.gmail.com>
Message-ID: <514A1695.6010800@gmail.com>

This is definitely not the case for mincresample and mincreshape without 
-image_range options

On 13-03-20 04:00 PM, Andrew Janke wrote:
> On 21 March 2013 05:56, Alex Zijdenbos <zijdenbos at gmail.com> wrote:
>> Right - and in fact I think this should actually be the default; but I'd
>> settle for a way to turn slice-based scaling off :)
>> Switching over to float volumes would be prohibitive space-wise for much of
>> the data I work with nowadays (which is high on resolution but low on
>> dynamic range)
>
> I was always of the impression that most MINC tools if given an input
> volume with no slice scaling will output a volume without slice
> scaling. Perhaps this is wrong?


-- 
Best regards,

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

From zijdenbos at gmail.com  Wed Mar 20 16:06:24 2013
From: zijdenbos at gmail.com (Alex Zijdenbos)
Date: Wed, 20 Mar 2013 16:06:24 -0400
Subject: [MINC-development] MINC2 file with floating-point voxels and
 slice normalization
In-Reply-To: <CAG0CB22hEghz+GnH43EtE2b8VyLwYKyHxNxtNMNqNpX2Es8pXw@mail.gmail.com>
References: <CAMCwi7PfmmFG23EHfa43QL6O2hq0V6ZspkgjNh3BP2wvNpKpEg@mail.gmail.com>
	<50FD5E95.9070800@phenogenomics.ca>
	<C2869AB6-34F0-49CD-B703-2E9405569B91@gmail.com>
	<Pine.LNX.4.64.1301211530360.5780@agrippa.bic.mni.mcgill.ca>
	<CAG0CB20SkC14zzFxFwU_HA5wZwn8e4c1fmMBOe+K-ZzheyofAw@mail.gmail.com>
	<CABEEk15Z4aJ1xupWODObeCww-bchPmZusjocS2yPE2qRwM+YkA@mail.gmail.com>
	<CAG0CB234ERg=0OsiB=wYaFJ6Cvaa0Tg3J40f2LD6pQoYCD9NPA@mail.gmail.com>
	<CAMCwi7P7eR5UrDoFkUJ9t+5_k3Ph7_oKJjhqbNPdZ0F_OGM9Zw@mail.gmail.com>
	<CABEEk16seZ9qdqxpdys_1Hoh6aGBJ3ReA-pn8aWFE8egq4CSmQ@mail.gmail.com>
	<CAG0CB22hEghz+GnH43EtE2b8VyLwYKyHxNxtNMNqNpX2Es8pXw@mail.gmail.com>
Message-ID: <CABEEk17UitOaauA2F5GX94rUuzk91eeTfUFvtx0+U8CT_0scTA@mail.gmail.com>

Yup - as best I can tell, all MINC tools will always generate output with
slice scaling, regardless of what you give them.


On Wed, Mar 20, 2013 at 4:00 PM, Andrew Janke <a.janke at gmail.com> wrote:

> On 21 March 2013 05:56, Alex Zijdenbos <zijdenbos at gmail.com> wrote:
> > Right - and in fact I think this should actually be the default; but I'd
> > settle for a way to turn slice-based scaling off :)
> > Switching over to float volumes would be prohibitive space-wise for much
> of
> > the data I work with nowadays (which is high on resolution but low on
> > dynamic range)
>
> I was always of the impression that most MINC tools if given an input
> volume with no slice scaling will output a volume without slice
> scaling. Perhaps this is wrong?
>
>
> a
> _______________________________________________
> 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/45c9a053/attachment.html>

From a.janke at gmail.com  Wed Mar 20 18:40:21 2013
From: a.janke at gmail.com (Andrew Janke)
Date: Thu, 21 Mar 2013 08:40:21 +1000
Subject: [MINC-development] MINC2 file with floating-point voxels and
 slice normalization
In-Reply-To: <CABEEk17UitOaauA2F5GX94rUuzk91eeTfUFvtx0+U8CT_0scTA@mail.gmail.com>
References: <CAMCwi7PfmmFG23EHfa43QL6O2hq0V6ZspkgjNh3BP2wvNpKpEg@mail.gmail.com>
	<50FD5E95.9070800@phenogenomics.ca>
	<C2869AB6-34F0-49CD-B703-2E9405569B91@gmail.com>
	<Pine.LNX.4.64.1301211530360.5780@agrippa.bic.mni.mcgill.ca>
	<CAG0CB20SkC14zzFxFwU_HA5wZwn8e4c1fmMBOe+K-ZzheyofAw@mail.gmail.com>
	<CABEEk15Z4aJ1xupWODObeCww-bchPmZusjocS2yPE2qRwM+YkA@mail.gmail.com>
	<CAG0CB234ERg=0OsiB=wYaFJ6Cvaa0Tg3J40f2LD6pQoYCD9NPA@mail.gmail.com>
	<CAMCwi7P7eR5UrDoFkUJ9t+5_k3Ph7_oKJjhqbNPdZ0F_OGM9Zw@mail.gmail.com>
	<CABEEk16seZ9qdqxpdys_1Hoh6aGBJ3ReA-pn8aWFE8egq4CSmQ@mail.gmail.com>
	<CAG0CB22hEghz+GnH43EtE2b8VyLwYKyHxNxtNMNqNpX2Es8pXw@mail.gmail.com>
	<CABEEk17UitOaauA2F5GX94rUuzk91eeTfUFvtx0+U8CT_0scTA@mail.gmail.com>
Message-ID: <CAG0CB21n8X3gHxWa3y0u95QErGJAxBsoSEMzwMEOQPcXM9M9ig@mail.gmail.com>

OK, well from your comment and Vlad's I suspect this is a feature of
voxel_loop, this is the code that is used in mincmath, minccalc,
minclookup, .... (pretty much anything in which you can do things
voxel by voxel across the volumes).

So if you are keen I'd look into modifying the guts of voxel_loop.
This will not be easy though as you will have to pretty much destroy
how voxel loop works (opening a sliding window of a series of files).
You would have to first run through, find your resulting min/max from
the calculation and then re-run through the data....

a





On 21 March 2013 06:06, Alex Zijdenbos <zijdenbos at gmail.com> wrote:
> Yup - as best I can tell, all MINC tools will always generate output with
> slice scaling, regardless of what you give them.

From peter.neelin at gmail.com  Wed Mar 20 20:25:55 2013
From: peter.neelin at gmail.com (Peter Neelin)
Date: Wed, 20 Mar 2013 20:25:55 -0400
Subject: [MINC-development] MINC2 file with floating-point voxels and
 slice normalization
In-Reply-To: <CAG0CB21n8X3gHxWa3y0u95QErGJAxBsoSEMzwMEOQPcXM9M9ig@mail.gmail.com>
References: <CAMCwi7PfmmFG23EHfa43QL6O2hq0V6ZspkgjNh3BP2wvNpKpEg@mail.gmail.com>
	<50FD5E95.9070800@phenogenomics.ca>
	<C2869AB6-34F0-49CD-B703-2E9405569B91@gmail.com>
	<Pine.LNX.4.64.1301211530360.5780@agrippa.bic.mni.mcgill.ca>
	<CAG0CB20SkC14zzFxFwU_HA5wZwn8e4c1fmMBOe+K-ZzheyofAw@mail.gmail.com>
	<CABEEk15Z4aJ1xupWODObeCww-bchPmZusjocS2yPE2qRwM+YkA@mail.gmail.com>
	<CAG0CB234ERg=0OsiB=wYaFJ6Cvaa0Tg3J40f2LD6pQoYCD9NPA@mail.gmail.com>
	<CAMCwi7P7eR5UrDoFkUJ9t+5_k3Ph7_oKJjhqbNPdZ0F_OGM9Zw@mail.gmail.com>
	<CABEEk16seZ9qdqxpdys_1Hoh6aGBJ3ReA-pn8aWFE8egq4CSmQ@mail.gmail.com>
	<CAG0CB22hEghz+GnH43EtE2b8VyLwYKyHxNxtNMNqNpX2Es8pXw@mail.gmail.com>
	<CABEEk17UitOaauA2F5GX94rUuzk91eeTfUFvtx0+U8CT_0scTA@mail.gmail.com>
	<CAG0CB21n8X3gHxWa3y0u95QErGJAxBsoSEMzwMEOQPcXM9M9ig@mail.gmail.com>
Message-ID: <CANcjydbx_9pFFDVeFqWgJtMDFQBRQug2zX8POLxqAqvP5DF5wg@mail.gmail.com>

On Wed, Mar 20, 2013 at 6:40 PM, Andrew Janke <a.janke at gmail.com> wrote:
> OK, well from your comment and Vlad's I suspect this is a feature of
> voxel_loop, this is the code that is used in mincmath, minccalc,
> minclookup, .... (pretty much anything in which you can do things
> voxel by voxel across the volumes).

Yup. voxel_loop is designed to be memory efficient (back in the days
when 32 MB was a lot of memory, or something - it's a bit hazy now).

> So if you are keen I'd look into modifying the guts of voxel_loop.
> This will not be easy though as you will have to pretty much destroy
> how voxel loop works (opening a sliding window of a series of files).

I believe that voxel_loop is designed to do no more than an image at a
time. Perhaps it could be modified to slurp up more data in one shot -
not sure how hard that would be.

> You would have to first run through, find your resulting min/max from
> the calculation and then re-run through the data....

You would end up discretizing the data a second time - that's not ideal.

Also, anything like mincresample that does not use voxel_loop would
have to have a custom fix.

Unfortunately for you, all of the minc primitives were designed with
memory limitation in mind and so slice scaling is pretty deeply
entrenched.

I do have a question though - why do you need to keep renormalizing?
It would surprise me if you really cared about the discretization of
continuous data. Is it because minc does not support integer, boolean
or label data? For years, I have felt that this is the big gap in minc
and should really be addressed. If you know that the data is integer
or labels (IDs for which proximity in value means nothing, so
interpolating between 10 and 12 to get 11 is nonsense), don't do nasty
things to it like scale it to real values or interpolate it.

If this is the real issue, then perhaps it would be more useful to
invest energy into a better handling of this data. The advantage is
that reformulating the problem this way allows data representation
decisions to be made on local data and does not require access to the
whole volume - I suspect that the code changes would be easier and
would also benefit the big data people (like Andrew showing off with
his monster volumes :)).

Peter
-- 
Peter Neelin
(peter.neelin at gmail.com)

From a.janke at gmail.com  Wed Mar 20 21:12:27 2013
From: a.janke at gmail.com (Andrew Janke)
Date: Thu, 21 Mar 2013 11:12:27 +1000
Subject: [MINC-development] MINC2 file with floating-point voxels and
 slice normalization
In-Reply-To: <CANcjydbx_9pFFDVeFqWgJtMDFQBRQug2zX8POLxqAqvP5DF5wg@mail.gmail.com>
References: <CAMCwi7PfmmFG23EHfa43QL6O2hq0V6ZspkgjNh3BP2wvNpKpEg@mail.gmail.com>
	<50FD5E95.9070800@phenogenomics.ca>
	<C2869AB6-34F0-49CD-B703-2E9405569B91@gmail.com>
	<Pine.LNX.4.64.1301211530360.5780@agrippa.bic.mni.mcgill.ca>
	<CAG0CB20SkC14zzFxFwU_HA5wZwn8e4c1fmMBOe+K-ZzheyofAw@mail.gmail.com>
	<CABEEk15Z4aJ1xupWODObeCww-bchPmZusjocS2yPE2qRwM+YkA@mail.gmail.com>
	<CAG0CB234ERg=0OsiB=wYaFJ6Cvaa0Tg3J40f2LD6pQoYCD9NPA@mail.gmail.com>
	<CAMCwi7P7eR5UrDoFkUJ9t+5_k3Ph7_oKJjhqbNPdZ0F_OGM9Zw@mail.gmail.com>
	<CABEEk16seZ9qdqxpdys_1Hoh6aGBJ3ReA-pn8aWFE8egq4CSmQ@mail.gmail.com>
	<CAG0CB22hEghz+GnH43EtE2b8VyLwYKyHxNxtNMNqNpX2Es8pXw@mail.gmail.com>
	<CABEEk17UitOaauA2F5GX94rUuzk91eeTfUFvtx0+U8CT_0scTA@mail.gmail.com>
	<CAG0CB21n8X3gHxWa3y0u95QErGJAxBsoSEMzwMEOQPcXM9M9ig@mail.gmail.com>
	<CANcjydbx_9pFFDVeFqWgJtMDFQBRQug2zX8POLxqAqvP5DF5wg@mail.gmail.com>
Message-ID: <CAG0CB227SMWcvKHD9vvATxcTNDaZkDuGiH=JbK6ZKYaJFAt9Ow@mail.gmail.com>

> Yup. voxel_loop is designed to be memory efficient (back in the days
> when 32 MB was a lot of memory, or something - it's a bit hazy now).

To me this was a good decision and has allowed MINC to stand the test
of time. Over time we have of course increased this memory "chunk"
size but the ability to mash through 100 files and not have to read
them all into memory just to average/compute across them is something
that "the others" don't have.

> I believe that voxel_loop is designed to do no more than an image at a
> time. Perhaps it could be modified to slurp up more data in one shot -
> not sure how hard that would be.

image? I think you mean slice?

> You would end up discretizing the data a second time - that's not ideal.

Agree. It's not me that wants this change, it's for this reason that
I'll keep suggesting that people who think they don't want slice
scaling buy two disks and use float. :)

> Is it because minc does not support integer, boolean
> or label data? For years, I have felt that this is the big gap in minc
> and should really be addressed. If you know that the data is integer
> or labels (IDs for which proximity in value means nothing, so
> interpolating between 10 and 12 to get 11 is nonsense), don't do nasty
> things to it like scale it to real values or interpolate it.

Agree. And the shift to HDF was a big step in this direction, one of
the initial problems was that MINC2 was still very strongly tied to
netCDF data types. Vlad has a working port of minc_lite that is HDF
only that we are using in production here now. Once we are happy with
its stability we should think pretty seriously about releasing this
code as "MINC2 proper" as it will allow all the recoding that will be
needed to add such discrete types into MINC.

For now pretty much everything can be done with labels but you need to
be aware of tools like resample_labels from conglomerate.

> I suspect that the code changes would be easier and
> would also benefit the big data people (like Andrew showing off with
> his monster volumes :)).

I'll bet it's not only me. Our u-CT and u-MRI machines are now
routinely churning out multi-GB volumes and we aren't the only ones in
the world with such machines. It's minctracc I now have to fix as it
seems to have a size limit in there somewhere. ANTS chokes on these
volumes unless you downsample them so back to the well polished
hammer(s) I know.

Change mincaverage/mincmath/minccalc such that I can't perform a
calculation across 10x 12GB volumes because I'd need 120GB of RAM?  I
think not...  it'd be quicker to just use niftilib.


a

From zijdenbos at gmail.com  Wed Mar 20 22:09:03 2013
From: zijdenbos at gmail.com (Alex Zijdenbos)
Date: Wed, 20 Mar 2013 22:09:03 -0400
Subject: [MINC-development] MINC2 file with floating-point voxels and
 slice normalization
In-Reply-To: <CAG0CB227SMWcvKHD9vvATxcTNDaZkDuGiH=JbK6ZKYaJFAt9Ow@mail.gmail.com>
References: <CAMCwi7PfmmFG23EHfa43QL6O2hq0V6ZspkgjNh3BP2wvNpKpEg@mail.gmail.com>
	<50FD5E95.9070800@phenogenomics.ca>
	<C2869AB6-34F0-49CD-B703-2E9405569B91@gmail.com>
	<Pine.LNX.4.64.1301211530360.5780@agrippa.bic.mni.mcgill.ca>
	<CAG0CB20SkC14zzFxFwU_HA5wZwn8e4c1fmMBOe+K-ZzheyofAw@mail.gmail.com>
	<CABEEk15Z4aJ1xupWODObeCww-bchPmZusjocS2yPE2qRwM+YkA@mail.gmail.com>
	<CAG0CB234ERg=0OsiB=wYaFJ6Cvaa0Tg3J40f2LD6pQoYCD9NPA@mail.gmail.com>
	<CAMCwi7P7eR5UrDoFkUJ9t+5_k3Ph7_oKJjhqbNPdZ0F_OGM9Zw@mail.gmail.com>
	<CABEEk16seZ9qdqxpdys_1Hoh6aGBJ3ReA-pn8aWFE8egq4CSmQ@mail.gmail.com>
	<CAG0CB22hEghz+GnH43EtE2b8VyLwYKyHxNxtNMNqNpX2Es8pXw@mail.gmail.com>
	<CABEEk17UitOaauA2F5GX94rUuzk91eeTfUFvtx0+U8CT_0scTA@mail.gmail.com>
	<CAG0CB21n8X3gHxWa3y0u95QErGJAxBsoSEMzwMEOQPcXM9M9ig@mail.gmail.com>
	<CANcjydbx_9pFFDVeFqWgJtMDFQBRQug2zX8POLxqAqvP5DF5wg@mail.gmail.com>
	<CAG0CB227SMWcvKHD9vvATxcTNDaZkDuGiH=JbK6ZKYaJFAt9Ow@mail.gmail.com>
Message-ID: <CABEEk15fFokuKt-LFSPaY9RO2_5-PZgo8++Zzrc-DFO_PJW=rA@mail.gmail.com>

On Wed, Mar 20, 2013 at 9:12 PM, Andrew Janke <a.janke at gmail.com> wrote:
>> Yup. voxel_loop is designed to be memory efficient (back in the days
>> when 32 MB was a lot of memory, or something - it's a bit hazy now).
>
> To me this was a good decision and has allowed MINC to stand the test
> of time. Over time we have of course increased this memory "chunk"
> size but the ability to mash through 100 files and not have to read
> them all into memory just to average/compute across them is something
> that "the others" don't have.

Agreed; of course the issue I raised is only with the writing of a
volume, not with reading them. Obviously when running mincaverage on
100s of volumes you have no hopes of reading them all into memory;
however, most of these tools create only a single output volume (I
suppose minccalc could create an arbitrary number of them in
principle). One crude way of course could be to write a float output
volume (assuming that the slice scaling on those will be turned off as
per the beginning of this discussion), and then discretize that;
assuming you have sufficient temp space that would be fairly
transparent. Could be handled by wrapper scripts; would be ugly either
way.

>> I believe that voxel_loop is designed to do no more than an image at a
>> time. Perhaps it could be modified to slurp up more data in one shot -
>> not sure how hard that would be.
>
> image? I think you mean slice?

On that note - how does voxel_loop divvy things up on >3D volumes?
Still per 2D slice? Or per unit of the slowest-varying dimension
(i.e., a volume)?

>> You would end up discretizing the data a second time - that's not ideal.
>
> Agree. It's not me that wants this change, it's for this reason that
> I'll keep suggesting that people who think they don't want slice
> scaling buy two disks and use float. :)

Yah - with a rapidly growing number of 1000 cubed data sets, that
would get a little pricey :) Definitely agree that
double-discretization should be avoided.

>> Is it because minc does not support integer, boolean
>> or label data? For years, I have felt that this is the big gap in minc
>> and should really be addressed. If you know that the data is integer
>> or labels (IDs for which proximity in value means nothing, so
>> interpolating between 10 and 12 to get 11 is nonsense), don't do nasty
>> things to it like scale it to real values or interpolate it.
>
> Agree. And the shift to HDF was a big step in this direction, one of
> the initial problems was that MINC2 was still very strongly tied to
> netCDF data types. Vlad has a working port of minc_lite that is HDF
> only that we are using in production here now. Once we are happy with
> its stability we should think pretty seriously about releasing this
> code as "MINC2 proper" as it will allow all the recoding that will be
> needed to add such discrete types into MINC.

Clearly, label volumes are by far the most affected by the slice-based
scaling; however, I often get bitten by the same effect on
"continuous" data as well. Especially masked volumes, or volumes with
poor dynamic range; you might get single slices that are suddenly
discretized differently, causing odd striping artifacts. Similarly, if
you have a volume with poor dynamic range and slice scaling that your
resample at an angle to the original slice direction, you may actually
start seeing that in the data. My point really is: discretizing data
is a necessary evil, but if we need to do it, I would prefer to apply
the evil in a consistent way across a volume.

But I'm a bit confused about the label volume argument. Presumably if
MINC would properly handle label volumes (and Vlad mentioned that
support for that already exists in MINC2), the slice-based scaling
issue would have to be dealt with? Isn't a central issue of properly
handling label volumes the ability to turn off slice-based scaling?

> For now pretty much everything can be done with labels but you need to
> be aware of tools like resample_labels from conglomerate.
>
>> I suspect that the code changes would be easier and
>> would also benefit the big data people (like Andrew showing off with
>> his monster volumes :)).
>
> I'll bet it's not only me.

Definitely not :)

> Change mincaverage/mincmath/minccalc such that I can't perform a
> calculation across 10x 12GB volumes because I'd need 120GB of RAM?  I
> think not...  it'd be quicker to just use niftilib.

Memory is cheap, much like disks - perhaps think SSD ;-)

More seriously, I never suggested we take any functionality away; just
that he slice-based scaling (or any scaling in the case of label
volumes) be under user control. Hey - it will even make mincheader
output easier to read.

But from what I gather this would (at minimum) require control over
the size of the sliding window in voxel_loop; possibly even on a
per-volume basis. I have no idea how feasible that would be, but it
sounds daunting (and that is recalling the meeting at MNI where Peter
first presented his new invention "voxel_loop", and very few - if any
- of us were able to follow at the time :-) )

-- A

From a.janke at gmail.com  Wed Mar 20 23:19:30 2013
From: a.janke at gmail.com (Andrew Janke)
Date: Thu, 21 Mar 2013 13:19:30 +1000
Subject: [MINC-development] MINC2 file with floating-point voxels and
 slice normalization
In-Reply-To: <CABEEk15fFokuKt-LFSPaY9RO2_5-PZgo8++Zzrc-DFO_PJW=rA@mail.gmail.com>
References: <CAMCwi7PfmmFG23EHfa43QL6O2hq0V6ZspkgjNh3BP2wvNpKpEg@mail.gmail.com>
	<50FD5E95.9070800@phenogenomics.ca>
	<C2869AB6-34F0-49CD-B703-2E9405569B91@gmail.com>
	<Pine.LNX.4.64.1301211530360.5780@agrippa.bic.mni.mcgill.ca>
	<CAG0CB20SkC14zzFxFwU_HA5wZwn8e4c1fmMBOe+K-ZzheyofAw@mail.gmail.com>
	<CABEEk15Z4aJ1xupWODObeCww-bchPmZusjocS2yPE2qRwM+YkA@mail.gmail.com>
	<CAG0CB234ERg=0OsiB=wYaFJ6Cvaa0Tg3J40f2LD6pQoYCD9NPA@mail.gmail.com>
	<CAMCwi7P7eR5UrDoFkUJ9t+5_k3Ph7_oKJjhqbNPdZ0F_OGM9Zw@mail.gmail.com>
	<CABEEk16seZ9qdqxpdys_1Hoh6aGBJ3ReA-pn8aWFE8egq4CSmQ@mail.gmail.com>
	<CAG0CB22hEghz+GnH43EtE2b8VyLwYKyHxNxtNMNqNpX2Es8pXw@mail.gmail.com>
	<CABEEk17UitOaauA2F5GX94rUuzk91eeTfUFvtx0+U8CT_0scTA@mail.gmail.com>
	<CAG0CB21n8X3gHxWa3y0u95QErGJAxBsoSEMzwMEOQPcXM9M9ig@mail.gmail.com>
	<CANcjydbx_9pFFDVeFqWgJtMDFQBRQug2zX8POLxqAqvP5DF5wg@mail.gmail.com>
	<CAG0CB227SMWcvKHD9vvATxcTNDaZkDuGiH=JbK6ZKYaJFAt9Ow@mail.gmail.com>
	<CABEEk15fFokuKt-LFSPaY9RO2_5-PZgo8++Zzrc-DFO_PJW=rA@mail.gmail.com>
Message-ID: <CAG0CB22MHgyR8m3LDs2K3=P-qyVmyNxKE8P+pTvq8VFjC=1G_Q@mail.gmail.com>

> Could be handled by wrapper scripts; would be ugly either
> way.

Indeed and very much the exception from the norm. From how you
describe the problem it sounds like poorly "ranged" data to begin
with. I take my "mincnorm" hammer to all such data and reset ranges to
histogram pCT's. This is done in all pre-processing.

> On that note - how does voxel_loop divvy things up on >3D volumes?
> Still per 2D slice? Or per unit of the slowest-varying dimension
> (i.e., a volume)?

Per 2D slice (sort of). In essence voxel_loop takes an input buffer of
data that will end up fitting in the output as a slice. (or image as
Peter calls it).

> But I'm a bit confused about the label volume argument. Presumably if
> MINC would properly handle label volumes (and Vlad mentioned that
> support for that already exists in MINC2), the slice-based scaling
> issue would have to be dealt with?

Well no, because in the case of label volumes, the voxel value is the
real value. So slice scaling isn't "turned off" it just doesn't exist.

> But from what I gather this would (at minimum) require control over
> the size of the sliding window in voxel_loop; possibly even on a
> per-volume basis. I have no idea how feasible that would be

>From the short conversation I just had with Peter about this I'd say
doable but it'd destroy what voxel_loop originally set out to do.

> sounds daunting (and that is recalling the meeting at MNI where Peter
> first presented his new invention "voxel_loop", and very few - if any
> - of us were able to follow at the time :-) )

Hrmpfh! why wasn't I invited??  Probably was still in 1st year uni.  I
can claim that I have broken voxel_loop and caused Peter to have to
add a few extra functions for mincstats...  Hardly a claim to fame.


a

From vladimir.fonov at gmail.com  Fri Mar 22 12:57:35 2013
From: vladimir.fonov at gmail.com (Vladimir S. FONOV)
Date: Fri, 22 Mar 2013 12:57:35 -0400
Subject: [MINC-development] uniting libvolume_io2 with libminc2
Message-ID: <CAMCwi7P0viRB-7fdTQysBQf5sG8yXN8CGUenvzxGvsmQCNnN_Q@mail.gmail.com>

Hello Everybody,


could it be feasible to have a single libminc2 library, which will
include both volume_io2 and minc2 functions? I already added an option
to minc_lite branch to have them integrated, but does anybody actually
need a separate volume_io library?

--
Best regards,

 Vladimir S. Fonov ~ vladimir <dot> fonov <at> gmail <dot> com

From jason at phenogenomics.ca  Fri Mar 22 14:52:54 2013
From: jason at phenogenomics.ca (Jason Lerch)
Date: Fri, 22 Mar 2013 14:52:54 -0400
Subject: [MINC-development] uniting libvolume_io2 with libminc2
In-Reply-To: <CAMCwi7P0viRB-7fdTQysBQf5sG8yXN8CGUenvzxGvsmQCNnN_Q@mail.gmail.com>
References: <CAMCwi7P0viRB-7fdTQysBQf5sG8yXN8CGUenvzxGvsmQCNnN_Q@mail.gmail.com>
Message-ID: <F7E10242-E744-43A8-9DC6-E227361E0366@phenogenomics.ca>

I see no reason to keep them separate - I don't think I've ever linked to volume_io without also linking to libminc ?

Jason

On 2013-03-22, at 12:57 PM, "Vladimir S. FONOV" <vladimir.fonov at gmail.com> wrote:

> Hello Everybody,
> 
> 
> could it be feasible to have a single libminc2 library, which will
> include both volume_io2 and minc2 functions? I already added an option
> to minc_lite branch to have them integrated, but does anybody actually
> need a separate volume_io library?
> 
> --
> Best regards,
> 
> Vladimir S. Fonov ~ vladimir <dot> fonov <at> gmail <dot> com
> _______________________________________________
> MINC-development mailing list
> MINC-development at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development


From fumi at bic.mni.mcgill.ca  Fri Mar 22 16:24:13 2013
From: fumi at bic.mni.mcgill.ca (fumi at bic.mni.mcgill.ca)
Date: Fri, 22 Mar 2013 15:24:13 -0500
Subject: [MINC-development] Attention! The international company needs
	partners.
Message-ID: <44182557E1D4BEDE1E5F9471CEC3E7DC@sdghfgeitrctraussb.twaron.com>

Spam detection software, running on the system "kurma.bic.mni.mcgill.ca", has
identified this incoming email as possible spam.  The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email.  If you have any questions, see
@@CONTACT_ADDRESS@@ for details.

Content preview:  We have an opening for a person with great people skills,
  attentive to instructions and a determination to succeed. In addition the
  individual must have working knowledge of Microsoft Office, be able to effectively
   use social networking sites such as Twitter and Facebook, be organized, well
   turned out, a team player and can work independently, are punctual and reliable,
   have basic knowledge of internet marketing and have a sharp eye for detail.
   [...] 

Content analysis details:   (17.0 points, 5.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
 1.7 URIBL_DBL_SPAM         Contains an URL listed in the DBL blocklist
                            [URIs: allstarjobsca.com]
 3.5 BAYES_99               BODY: Bayes spam probability is 99 to 100%
                            [score: 1.0000]
 0.0 FREEMAIL_FROM          Sender email is freemail (intermediaryb6[at]gmail.com)
 1.4 RCVD_IN_BRBL_LASTEXT   RBL: RCVD_IN_BRBL_LASTEXT
                            [201.240.21.219 listed in bb.barracudacentral.org]
 0.0 RCVD_IN_SORBS_DUL      RBL: SORBS: sent directly from dynamic IP address
                            [201.240.21.219 listed in dnsbl.sorbs.net]
 3.3 RCVD_IN_PBL            RBL: Received via a relay in Spamhaus PBL
                            [201.240.21.219 listed in zen.spamhaus.org]
 0.8 SPF_NEUTRAL            SPF: sender does not match SPF record (neutral)
 1.6 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
                            digit (intermediaryb6[at]gmail.com)
 1.7 URIBL_BLACK            Contains an URL listed in the URIBL blacklist
                            [URIs: allstarjobsca.com]
 1.0 RDNS_DYNAMIC           Delivered to internal network by host with
                            dynamic-looking rDNS
 2.0 HELO_DYNAMIC_IPADDR    Relay HELO'd using suspicious hostname (IP addr
                            1)


-------------- next part --------------
An embedded message was scrubbed...
From: <fumi at bic.mni.mcgill.ca>,
	<helene at bic.mni.mcgill.ca>,
	<ilana at bic.mni.mcgill.ca>,
	<minc-development at bic.mni.mcgill.ca>,
	<jurgen at bic.mni.mcgill.ca>
Subject: Attention! The international company needs partners.
Date: Fri, 22 Mar 2013 15:24:13 -0500
Size: 2232
URL: <http://www.bic.mni.mcgill.ca/pipermail/minc-development/attachments/20130322/7cab5600/attachment.mht>

From helene at bic.mni.mcgill.ca  Sat Mar 23 08:11:53 2013
From: helene at bic.mni.mcgill.ca (helene at bic.mni.mcgill.ca)
Date: Sat, 23 Mar 2013 09:11:53 -0300
Subject: [MINC-development] You need administrator
Message-ID: <6389642876.IC7PUQRT146161@zwlbyrprk.qxeqpgcdze.va>

Spam detection software, running on the system "kurma.bic.mni.mcgill.ca", has
identified this incoming email as possible spam.  The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email.  If you have any questions, see
@@CONTACT_ADDRESS@@ for details.

Content preview:  We have an opening for a person with great people skills,
  attentive to instructions and a determination to succeed. In addition the
  individual must have working knowledge of Microsoft Office, be able to effectively
   use social networking sites such as Twitter and Facebook, be organized, well
   turned out, a team player and can work independently, are punctual and reliable,
   have basic knowledge of internet marketing and have a sharp eye for detail.
   [...] 

Content analysis details:   (25.3 points, 5.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
 3.3 RCVD_IN_PBL            RBL: Received via a relay in Spamhaus PBL
                            [190.193.6.16 listed in zen.spamhaus.org]
 1.3 RCVD_IN_RP_RNBL        RBL: Relay in RNBL,
                            https://senderscore.org/blacklistlookup/
                            [190.193.6.16 listed in bl.score.senderscore.com]
 1.4 RCVD_IN_BRBL_LASTEXT   RBL: RCVD_IN_BRBL_LASTEXT
                            [190.193.6.16 listed in bb.barracudacentral.org]
 1.7 URIBL_DBL_SPAM         Contains an URL listed in the DBL blocklist
                            [URIs: allstarjobsca.com]
 1.7 URIBL_BLACK            Contains an URL listed in the URIBL blacklist
                            [URIs: allstarjobsca.com]
 1.5 URIBL_RHS_DOB          Contains an URI of a new domain (Day Old Bread)
                            [URIs: allstarjobsca.com]
 3.5 BAYES_99               BODY: Bayes spam probability is 99 to 100%
                            [score: 1.0000]
 3.6 HELO_DYNAMIC_IPADDR2   Relay HELO'd using suspicious hostname (IP addr
                            2)
 3.2 FH_HELO_EQ_D_D_D_D     Helo is d-d-d-d
 0.7 TVD_RCVD_IP            TVD_RCVD_IP
 0.0 FREEMAIL_FROM          Sender email is freemail (norrisr07[at]gmail.com)
 0.8 SPF_NEUTRAL            SPF: sender does not match SPF record (neutral)
 1.6 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
                            digit (norrisr07[at]gmail.com)
 1.0 RDNS_DYNAMIC           Delivered to internal network by host with
                            dynamic-looking rDNS


-------------- next part --------------
An embedded message was scrubbed...
From: <helene at bic.mni.mcgill.ca>,
	<ilana at bic.mni.mcgill.ca>,
	<minc-development at bic.mni.mcgill.ca>
Subject: You need administrator
Date: Sat, 23 Mar 2013 09:11:53 -0300
Size: 1759
URL: <http://www.bic.mni.mcgill.ca/pipermail/minc-development/attachments/20130323/965b0d79/attachment.mht>

From ilana at bic.mni.mcgill.ca  Sat Mar 23 10:22:03 2013
From: ilana at bic.mni.mcgill.ca (ilana at bic.mni.mcgill.ca)
Date: Sat, 23 Mar 2013 09:22:03 -0500
Subject: [MINC-development] Job
Message-ID: <JDG07Y-L26MEI-D0@kbkfkgkfajijda.scccontrols.com>

Spam detection software, running on the system "kurma.bic.mni.mcgill.ca", has
identified this incoming email as possible spam.  The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email.  If you have any questions, see
@@CONTACT_ADDRESS@@ for details.

Content preview:  We have an opening for a person with great people skills,
  attentive to instructions and a determination to succeed. In addition the
  individual must have working knowledge of Microsoft Office, be able to effectively
   use social networking sites such as Twitter and Facebook, be organized, well
   turned out, a team player and can work independently, are punctual and reliable,
   have basic knowledge of internet marketing and have a sharp eye for detail.
   [...] 

Content analysis details:   (16.3 points, 5.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
 1.7 URIBL_DBL_SPAM         Contains an URL listed in the DBL blocklist
                            [URIs: allstarjobsca.com]
 1.5 URIBL_RHS_DOB          Contains an URI of a new domain (Day Old Bread)
                            [URIs: allstarjobsca.com]
 3.5 BAYES_99               BODY: Bayes spam probability is 99 to 100%
                            [score: 1.0000]
 0.0 FREEMAIL_FROM          Sender email is freemail (hawsero762[at]gmail.com)
 1.4 RCVD_IN_BRBL_LASTEXT   RBL: RCVD_IN_BRBL_LASTEXT
                            [178.131.73.93 listed in bb.barracudacentral.org]
 3.3 RCVD_IN_PBL            RBL: Received via a relay in Spamhaus PBL
                            [178.131.73.93 listed in zen.spamhaus.org]
 0.8 SPF_NEUTRAL            SPF: sender does not match SPF record (neutral)
 1.6 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
                            digit (hawsero762[at]gmail.com)
 1.7 URIBL_BLACK            Contains an URL listed in the URIBL blacklist
                            [URIs: allstarjobsca.com]
 0.8 RDNS_NONE              Delivered to internal network by a host with no rDNS


-------------- next part --------------
An embedded message was scrubbed...
From: <ilana at bic.mni.mcgill.ca>,
	<minc-development at bic.mni.mcgill.ca>,
	<jurgen at bic.mni.mcgill.ca>,
	<albertodd at bic.mni.mcgill.ca>
Subject: Job
Date: Sat, 23 Mar 2013 09:22:03 -0500
Size: 2068
URL: <http://www.bic.mni.mcgill.ca/pipermail/minc-development/attachments/20130323/91734bad/attachment-0001.mht>

From a.janke at gmail.com  Sun Mar 24 17:44:10 2013
From: a.janke at gmail.com (Andrew Janke)
Date: Mon, 25 Mar 2013 07:44:10 +1000
Subject: [MINC-development] uniting libvolume_io2 with libminc2
In-Reply-To: <CAMCwi7P0viRB-7fdTQysBQf5sG8yXN8CGUenvzxGvsmQCNnN_Q@mail.gmail.com>
References: <CAMCwi7P0viRB-7fdTQysBQf5sG8yXN8CGUenvzxGvsmQCNnN_Q@mail.gmail.com>
Message-ID: <CAG0CB23ccrfQoFTutbOtW9WSQVHscKrH6ajfmvjRtiCAVTFKTQ@mail.gmail.com>

I'm with Jason. I see no reason to keep them apart.  (Despite their
methods of getting stuff out and the data model being somewhat
different!).

I'd be for a more ambitious plan in which we rewrite some of the
volume_io calls to minc2 if and where possible. The easy ones would be
a good start -- getting steps/starts/dimensions/comments/headers. Then
we are just left with the "get big chunk of data" volume_io calls.

Happy to help with the latter via GIT if this is required.

ta


a

On 23 March 2013 02:57, Vladimir S. FONOV <vladimir.fonov at gmail.com> wrote:
> could it be feasible to have a single libminc2 library, which will
> include both volume_io2 and minc2 functions? I already added an option
> to minc_lite branch to have them integrated, but does anybody actually
> need a separate volume_io library?