From vladimir.fonov at gmail.com  Wed Nov 14 13:23:10 2012
From: vladimir.fonov at gmail.com (Vladimir S. FONOV)
Date: Wed, 14 Nov 2012 13:23:10 -0500
Subject: [MINC-users] new release of minc-toolkit 0.3.16
Message-ID: <50A3E18E.3050601@gmail.com>

Hello Everybody!

After making quite significant changes in MINC with Andrew Janke last 
September I have finally created a new binary release of minc-toolkit ( 
available at 
http://www.bic.mni.mcgill.ca/ServicesSoftware/ServicesSoftwareMincToolKit )


Note that, although commands are all the same, those of you who are 
using MINC or EZminc library to make your own software will see a 
different configuration files: instead of being called minc2 library, it 
is now called libminc , so if you are using minc with CMAKE you will 
have to replace code like:

FIND_PACKAGE( MINC2 )
INCLUDE( ${MINC2_USE_FILE} )

with

FIND_PACKAGE( LIBMINC )
INCLUDE( ${LIBMINC_USE_FILE} )


Note that new version of the package became significantly larger 
(~300Mb) because it includes full resolution segmentation library for 
BEaST ( 
http://www.bic.mni.mcgill.ca/ServicesSoftwareAdvancedImageProcessingTools/BEaST 
)

P.S. The old packages are still available in 
http://packages.bic.mni.mcgill.ca/minc-toolkit/

-- 
Best regards,

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

From zijdenbos at gmail.com  Mon Nov 19 10:31:48 2012
From: zijdenbos at gmail.com (Alex Zijdenbos)
Date: Mon, 19 Nov 2012 10:31:48 -0500
Subject: [MINC-users] multi-input output type/range
Message-ID: <CABEEk16ee+mBXhLWmKutHJCZbPL3JmeCDmLycMHG7QLziO5Qpw@mail.gmail.com>

Hello all,

I regularly run into issues with some of the minc tools, specifically
mincmath and minccalc, due to the fact that by default, they inherit
the data type of the first volume (only). For example, something like
this:

minccalc -expression "A[0] * A[1]" <mask.mnc> <vol.mnc> <masked.mnc>

will produce very expected results if <mask.mnc> is "unsigned byte 0
1"; or even when it is "unsigned byte 0 255". Of course you can choose
the output type and range that you like to see; but that implies being
explicitly aware of the data type of the input volumes to begin with
which is not always a given, especially not when this is buried deep
into a script.

I think it would make sense to have multi-input minc tools compute the
"largest" data type/range among the input volumes, rather than just
inheriting from the first volume. That wouldn't be perfect, but it
would reduce quantization errors in quite a few cases.

Thoughts?

-- A

From vladimir.fonov at gmail.com  Mon Nov 19 16:52:56 2012
From: vladimir.fonov at gmail.com (Vladimir S. FONOV)
Date: Mon, 19 Nov 2012 16:52:56 -0500
Subject: [MINC-users] multi-input output type/range
In-Reply-To: <CABEEk16ee+mBXhLWmKutHJCZbPL3JmeCDmLycMHG7QLziO5Qpw@mail.gmail.com>
References: <CABEEk16ee+mBXhLWmKutHJCZbPL3JmeCDmLycMHG7QLziO5Qpw@mail.gmail.com>
Message-ID: <50AAAA38.5040504@gmail.com>

Hello,

considering that inter-slice normalization does more evil than good 
especially in case of multiple labels maybe let's just treat all volumes 
as float , unless specified otherwise?

On 12-11-19 10:31 AM, Alex Zijdenbos wrote:
> Hello all,
>
> I regularly run into issues with some of the minc tools, specifically
> mincmath and minccalc, due to the fact that by default, they inherit
> the data type of the first volume (only). For example, something like
> this:
>
> minccalc -expression "A[0] * A[1]" <mask.mnc> <vol.mnc> <masked.mnc>
>
> will produce very expected results if <mask.mnc> is "unsigned byte 0
> 1"; or even when it is "unsigned byte 0 255". Of course you can choose
> the output type and range that you like to see; but that implies being
> explicitly aware of the data type of the input volumes to begin with
> which is not always a given, especially not when this is buried deep
> into a script.
>
> I think it would make sense to have multi-input minc tools compute the
> "largest" data type/range among the input volumes, rather than just
> inheriting from the first volume. That wouldn't be perfect, but it
> would reduce quantization errors in quite a few cases.
>
> Thoughts?


-- 
Best regards,

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

From a.janke at gmail.com  Mon Nov 19 18:30:07 2012
From: a.janke at gmail.com (Andrew Janke)
Date: Tue, 20 Nov 2012 09:30:07 +1000
Subject: [MINC-users] multi-input output type/range
In-Reply-To: <50AAAA38.5040504@gmail.com>
References: <CABEEk16ee+mBXhLWmKutHJCZbPL3JmeCDmLycMHG7QLziO5Qpw@mail.gmail.com>
	<50AAAA38.5040504@gmail.com>
Message-ID: <CAG0CB23NjKqB8PO_zaoPU0EMKCZD27bCyVRGV+ZpzSSj-xNXkA@mail.gmail.com>

I would be very adverse to changing tools such as mincmath and
minccalc's default behaviour, no doubt there are hundreds of buried
calls to these two tools that would then behave differently to
expected.

FWIW, the change you are requesting would have to be done in
voxel_loop.{c,h}. Voxel loop also does perform all internal
calculations as double so it's only the output stage where
quantization can creep in.

That said, I am not sure of the motivation for the change other than
your current itch? There are many times in scripts where I have relied
upon this behaviour and crafted minccalc lines to suit... I would
guess that Peter's original motivation for doing things the way they
are was disk space. Granted this isn't so much of an issue anymore but
it will still have some impact.

If you want to achieve what Vlad is suggesting this is already easily
achieved, just mincreshape all your input files to float and job done!
The file type will propagate through if things are in the right order.

Failing that add some hidden magic in your .bashrc...

   alias minccalc="minccalc -float"

That would be sure to cause headaches...  perhaps a small wrapper
script would be a better option!


a

On 20 November 2012 07:52, Vladimir S. FONOV <vladimir.fonov at gmail.com> wrote:
> Hello,
>
> considering that inter-slice normalization does more evil than good
> especially in case of multiple labels maybe let's just treat all volumes as
> float , unless specified otherwise?
>
>
> On 12-11-19 10:31 AM, Alex Zijdenbos wrote:
>>
>> Hello all,
>>
>> I regularly run into issues with some of the minc tools, specifically
>> mincmath and minccalc, due to the fact that by default, they inherit
>> the data type of the first volume (only). For example, something like
>> this:
>>
>> minccalc -expression "A[0] * A[1]" <mask.mnc> <vol.mnc> <masked.mnc>
>>
>> will produce very expected results if <mask.mnc> is "unsigned byte 0
>> 1"; or even when it is "unsigned byte 0 255". Of course you can choose
>> the output type and range that you like to see; but that implies being
>> explicitly aware of the data type of the input volumes to begin with
>> which is not always a given, especially not when this is buried deep
>> into a script.
>>
>> I think it would make sense to have multi-input minc tools compute the
>> "largest" data type/range among the input volumes, rather than just
>> inheriting from the first volume. That wouldn't be perfect, but it
>> would reduce quantization errors in quite a few cases.
>>
>> Thoughts?
>
>
>
> --
> Best regards,
>
>  Vladimir S. FONOV ~ vladimir.fonov <at> gmail.com
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users

From zijdenbos at gmail.com  Mon Nov 19 20:57:21 2012
From: zijdenbos at gmail.com (Alex Zijdenbos)
Date: Mon, 19 Nov 2012 20:57:21 -0500
Subject: [MINC-users] multi-input output type/range
In-Reply-To: <CAG0CB23NjKqB8PO_zaoPU0EMKCZD27bCyVRGV+ZpzSSj-xNXkA@mail.gmail.com>
References: <CABEEk16ee+mBXhLWmKutHJCZbPL3JmeCDmLycMHG7QLziO5Qpw@mail.gmail.com>
	<50AAAA38.5040504@gmail.com>
	<CAG0CB23NjKqB8PO_zaoPU0EMKCZD27bCyVRGV+ZpzSSj-xNXkA@mail.gmail.com>
Message-ID: <CABEEk16J8pk-XzY2FpkbpOTfE=Ge8QkDHitK2PPqBf8qq_tEmQ@mail.gmail.com>

Actually, the motivation for changing this is not a "current itch" - I
can scratch my current itch just fine. It is a concern that the
current default behaviour has a very high probability of giving
"wrong" output that will likely go unnoticed. With "wrong" I mean with
possibly severe quantization errors that the user did not expect; and
with "user" I mean those who may not have the knowledge of the ins and
outs of MINC like some of us do.

I was under the impression that one of the central ideas behind MINC
was that the user wouldn't need to care about or be aware of data
type. But when you want to add or multiply two volumes, one of which
is 8-bit, the other is 16-bit, you end up with a non-commutative
operation due to the quantization: A*B != B*A and A+B != B+A. It gets
(a lot) worse when performing math operations on label volumes that
may have small ranges on the data type. So in order to avoid this, one
would either have to use a blunt hammer and force a float output
volume; or first figure out what datatypes the input volumes have and
then do the right (or better) thing. Neither of these are obvious to
the average user who just wants to add two volumes together.

I actually cannot come up with a situation where I would *want* to
lose data in quantization, so I am curious: can you give an example of
how you relied on the current behaviour?

-- A


On Mon, Nov 19, 2012 at 6:30 PM, Andrew Janke <a.janke at gmail.com> wrote:
> I would be very adverse to changing tools such as mincmath and
> minccalc's default behaviour, no doubt there are hundreds of buried
> calls to these two tools that would then behave differently to
> expected.
>
> FWIW, the change you are requesting would have to be done in
> voxel_loop.{c,h}. Voxel loop also does perform all internal
> calculations as double so it's only the output stage where
> quantization can creep in.
>
> That said, I am not sure of the motivation for the change other than
> your current itch? There are many times in scripts where I have relied
> upon this behaviour and crafted minccalc lines to suit... I would
> guess that Peter's original motivation for doing things the way they
> are was disk space. Granted this isn't so much of an issue anymore but
> it will still have some impact.
>
> If you want to achieve what Vlad is suggesting this is already easily
> achieved, just mincreshape all your input files to float and job done!
> The file type will propagate through if things are in the right order.
>
> Failing that add some hidden magic in your .bashrc...
>
>    alias minccalc="minccalc -float"
>
> That would be sure to cause headaches...  perhaps a small wrapper
> script would be a better option!
>
>
> a
>
> On 20 November 2012 07:52, Vladimir S. FONOV <vladimir.fonov at gmail.com> wrote:
>> Hello,
>>
>> considering that inter-slice normalization does more evil than good
>> especially in case of multiple labels maybe let's just treat all volumes as
>> float , unless specified otherwise?
>>
>>
>> On 12-11-19 10:31 AM, Alex Zijdenbos wrote:
>>>
>>> Hello all,
>>>
>>> I regularly run into issues with some of the minc tools, specifically
>>> mincmath and minccalc, due to the fact that by default, they inherit
>>> the data type of the first volume (only). For example, something like
>>> this:
>>>
>>> minccalc -expression "A[0] * A[1]" <mask.mnc> <vol.mnc> <masked.mnc>
>>>
>>> will produce very expected results if <mask.mnc> is "unsigned byte 0
>>> 1"; or even when it is "unsigned byte 0 255". Of course you can choose
>>> the output type and range that you like to see; but that implies being
>>> explicitly aware of the data type of the input volumes to begin with
>>> which is not always a given, especially not when this is buried deep
>>> into a script.
>>>
>>> I think it would make sense to have multi-input minc tools compute the
>>> "largest" data type/range among the input volumes, rather than just
>>> inheriting from the first volume. That wouldn't be perfect, but it
>>> would reduce quantization errors in quite a few cases.
>>>
>>> Thoughts?
>>
>>
>>
>> --
>> Best regards,
>>
>>  Vladimir S. FONOV ~ vladimir.fonov <at> gmail.com
>> _______________________________________________
>> MINC-users at bic.mni.mcgill.ca
>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From a.janke at gmail.com  Mon Nov 19 21:45:35 2012
From: a.janke at gmail.com (Andrew Janke)
Date: Tue, 20 Nov 2012 12:45:35 +1000
Subject: [MINC-users] multi-input output type/range
In-Reply-To: <CABEEk16J8pk-XzY2FpkbpOTfE=Ge8QkDHitK2PPqBf8qq_tEmQ@mail.gmail.com>
References: <CABEEk16ee+mBXhLWmKutHJCZbPL3JmeCDmLycMHG7QLziO5Qpw@mail.gmail.com>
	<50AAAA38.5040504@gmail.com>
	<CAG0CB23NjKqB8PO_zaoPU0EMKCZD27bCyVRGV+ZpzSSj-xNXkA@mail.gmail.com>
	<CABEEk16J8pk-XzY2FpkbpOTfE=Ge8QkDHitK2PPqBf8qq_tEmQ@mail.gmail.com>
Message-ID: <CAG0CB20rKddUBM4Q9d-cvOn9wm=-GL9PjNKOG+MzrouBYYuSBQ@mail.gmail.com>

> Actually, the motivation for changing this is not a "current itch" - I
> can scratch my current itch just fine. It is a concern that the
> current default behaviour has a very high probability of giving
> "wrong" output that will likely go unnoticed. With "wrong" I mean with
> possibly severe quantization errors that the user did not expect; and
> with "user" I mean those who may not have the knowledge of the ins and
> outs of MINC like some of us do.

Ah, OK. Problem of course being is what to do with the ones who have
gotten used to the current behaviour.

> I was under the impression that one of the central ideas behind MINC
> was that the user wouldn't need to care about or be aware of data
> type.

In general that is the idea, and in general 16bits (short) is enough
for most people WRT precision, then of course you add in a divide
sign...  At this point it doesn't really matter if you are using
double, you still can't see your result!

> So in order to avoid this, one
> would either have to use a blunt hammer and force a float output
> volume; or first figure out what datatypes the input volumes have and
> then do the right (or better) thing. Neither of these are obvious to
> the average user who just wants to add two volumes together.

Well if we are just adding then I think this one is already reasonably
covered. Adding in multiplication and other nasty things like division
and everything goes bad. Still I can't think of a good way around this
as if you are dynamically calculating what the output should be you
are just going to end up with a double 99.9% of the time due to
outliers and noise in the image with really small values.

> I actually cannot come up with a situation where I would *want* to
> lose data in quantization, so I am curious: can you give an example of
> how you relied on the current behaviour?

Primarily it's about disk space. In my case models are nearly always
computed as float but the resulting model is generally converted to
short. So, this means that during the resampling and intensity
rescaling you be sure to put the model second or else you double the
amount of $TMPDIR required.


a

From claude at bic.mni.mcgill.ca  Mon Nov 19 22:55:55 2012
From: claude at bic.mni.mcgill.ca (Claude LEPAGE)
Date: Mon, 19 Nov 2012 22:55:55 -0500
Subject: [MINC-users] multi-input output type/range
In-Reply-To: <CAG0CB20rKddUBM4Q9d-cvOn9wm=-GL9PjNKOG+MzrouBYYuSBQ@mail.gmail.com>
Message-ID: <201211200355.qAK3ttrv021353@cassio.bic.mni.mcgill.ca>

Hi,

This discussion sounds like a good opportunity to add oil to the fire. :-)

With all software should come some documentation which the user is of
course invited to read before usage. I was made aware of the minccalc
behaviour when I started using the minc tools. It is now a well-
conditioned reflex to list the input files in the appropriate order
or to explicitly specify the output type. Maybe adding an option such
as "minccalc -like file.mnc -expression ...." would be an easy way to
remind the user to choose an output data type. This would also not 
change the default behaviour if -like is not specified.

About loss of data, I think this is a separate issue. Binarization 
of data is part of the minc concept, but what I don't like about it,
especially for integer data types, are the different min/max scaling
values by slice. This means a value of 100 can vary from slice to
slice. This is particularly annoying with labels. I think Andrew
once pointed out a global compilation variable to set to obtain 
a global min/max for the entire volume, but I forgot it since. I
would very much like to be able to enable this feature on a per 
file basis via a command line option.

ok, enough ramblings. 

Claude

From zijdenbos at gmail.com  Mon Nov 19 22:58:24 2012
From: zijdenbos at gmail.com (Alex Zijdenbos)
Date: Mon, 19 Nov 2012 22:58:24 -0500
Subject: [MINC-users] multi-input output type/range
In-Reply-To: <CAG0CB20rKddUBM4Q9d-cvOn9wm=-GL9PjNKOG+MzrouBYYuSBQ@mail.gmail.com>
References: <CABEEk16ee+mBXhLWmKutHJCZbPL3JmeCDmLycMHG7QLziO5Qpw@mail.gmail.com>
	<50AAAA38.5040504@gmail.com>
	<CAG0CB23NjKqB8PO_zaoPU0EMKCZD27bCyVRGV+ZpzSSj-xNXkA@mail.gmail.com>
	<CABEEk16J8pk-XzY2FpkbpOTfE=Ge8QkDHitK2PPqBf8qq_tEmQ@mail.gmail.com>
	<CAG0CB20rKddUBM4Q9d-cvOn9wm=-GL9PjNKOG+MzrouBYYuSBQ@mail.gmail.com>
Message-ID: <CABEEk141rDUeYg2d_1wyNxojGkBOUTs731Tnc6LACuR7bSnsQQ@mail.gmail.com>

> Ah, OK. Problem of course being is what to do with the ones who have
> gotten used to the current behaviour.

Well we don't necessarily need to take the old behaviour away :)

> Well if we are just adding then I think this one is already reasonably
> covered. Adding in multiplication and other nasty things like division
> and everything goes bad. Still I can't think of a good way around this
> as if you are dynamically calculating what the output should be you
> are just going to end up with a double 99.9% of the time due to
> outliers and noise in the image with really small values.

Obviously - there is no magic bullet. However I think that the vast
majority of MINC volumes out there are either byte or short, and often
have shrunken data ranges. Many of those are label volumes as well.
More than a few times I have been presented with a scenario like this:
"help! In my script I am masking volume X with the gray matter from
the classification, but my output looks funny". What would be
happening is something like this:

minccalc -expression "abs(A[0] - 2) < 0.5 ? A[1] : 0" <cls.mnc>
<in.mnc> <masked.mnc>

where <cls.mnc> happened to be "unsigned byte 0 4"; now resulting in
<masked.mnc> quantized to 5 values. Yes, easily solved by putting
<in.mnc> first; but I can't blame people for finding this at the very
least counter-intuitive. To me it seems (more) reasonable that if you
perform some sort of math/calc operation on two integer volumes, to
inherit the one with the widest range, not simply the first one. But
that is just my $0.02.

>> I actually cannot come up with a situation where I would *want* to
>> lose data in quantization, so I am curious: can you give an example of
>> how you relied on the current behaviour?
>
> Primarily it's about disk space. In my case models are nearly always
> computed as float but the resulting model is generally converted to
> short. So, this means that during the resampling and intensity
> rescaling you be sure to put the model second or else you double the
> amount of $TMPDIR required.

Right - but the difference being that in this case you are most likely
explicitly aware of the types you are using; so you could probably
also just add -short to the call.

In a lot of my code I have actually gone to the extent of - when I
don't want to clutter my tmp space with float volumes - writing subs
or wrappers that first run mincinfo on all input volumes, and then
force the output data type and range. It just seemed to me it would be
more natural to build that into minccalc/math.

-- A

From a.janke at gmail.com  Tue Nov 20 01:35:47 2012
From: a.janke at gmail.com (Andrew Janke)
Date: Tue, 20 Nov 2012 16:35:47 +1000
Subject: [MINC-users] multi-input output type/range
In-Reply-To: <201211200355.qAK3ttrv021353@cassio.bic.mni.mcgill.ca>
References: <CAG0CB20rKddUBM4Q9d-cvOn9wm=-GL9PjNKOG+MzrouBYYuSBQ@mail.gmail.com>
	<201211200355.qAK3ttrv021353@cassio.bic.mni.mcgill.ca>
Message-ID: <CAG0CB22EkxcOdReHmvKtK16UU=8MR3-wuMCoTwoFujRLneWrXw@mail.gmail.com>

Hi Claude,

> or to explicitly specify the output type. Maybe adding an option such
> as "minccalc -like file.mnc -expression ...." would be an easy way to
> remind the user to choose an output data type.

This sounds like a very sensible idea. There is a "-filetype" option
for minccalc that probably few know of which is along this track. I
would prefer to not use -like given that this is already used for a
different purpose in mincresample so would prefer not to muddy the
waters.

So I'm open to suggestions. -outtype?

> About loss of data, I think this is a separate issue. Binarization
> of data is part of the minc concept, but what I don't like about it,
> especially for integer data types, are the different min/max scaling
> values by slice. This means a value of 100 can vary from slice to
> slice. This is particularly annoying with labels. I think Andrew
> once pointed out a global compilation variable to set to obtain
> a global min/max for the entire volume, but I forgot it since. I
> would very much like to be able to enable this feature on a per
> file basis via a command line option.

This would mean some changes to voxel_loop.{c,h} which would then have
to be exposed via some C/L switch. Probably the easiest way to achieve
this functionality is to simple specify the -range option (eg: -range
0 255) in minccalc.


a

From a.janke at gmail.com  Tue Nov 20 01:39:04 2012
From: a.janke at gmail.com (Andrew Janke)
Date: Tue, 20 Nov 2012 16:39:04 +1000
Subject: [MINC-users] multi-input output type/range
In-Reply-To: <CABEEk141rDUeYg2d_1wyNxojGkBOUTs731Tnc6LACuR7bSnsQQ@mail.gmail.com>
References: <CABEEk16ee+mBXhLWmKutHJCZbPL3JmeCDmLycMHG7QLziO5Qpw@mail.gmail.com>
	<50AAAA38.5040504@gmail.com>
	<CAG0CB23NjKqB8PO_zaoPU0EMKCZD27bCyVRGV+ZpzSSj-xNXkA@mail.gmail.com>
	<CABEEk16J8pk-XzY2FpkbpOTfE=Ge8QkDHitK2PPqBf8qq_tEmQ@mail.gmail.com>
	<CAG0CB20rKddUBM4Q9d-cvOn9wm=-GL9PjNKOG+MzrouBYYuSBQ@mail.gmail.com>
	<CABEEk141rDUeYg2d_1wyNxojGkBOUTs731Tnc6LACuR7bSnsQQ@mail.gmail.com>
Message-ID: <CAG0CB20NNK9i=Mee8FU-p6+1V1mX4PxZykV-AQVxxzELodCH6Q@mail.gmail.com>

> What would be happening is something like this:
>
> minccalc -expression "abs(A[0] - 2) < 0.5 ? A[1] : 0" <cls.mnc>
> <in.mnc> <masked.mnc>
>
> where <cls.mnc> happened to be "unsigned byte 0 4"; now resulting in
> <masked.mnc> quantized to 5 values.

Hrm, well the range bit could probably be changed but again it's hard
to think of a way where we can handle all possibilities.

So what's the default? the full range of the type?  I can see this
breaking when I use minccalc on label volumes with restricted ranges
that I depend upon.

I am curious to know what happens (But haven't checked) if in the
above case you add a -byte option. Does this reset the range?


a

From zijdenbos at gmail.com  Tue Nov 20 09:03:13 2012
From: zijdenbos at gmail.com (Alex Zijdenbos)
Date: Tue, 20 Nov 2012 09:03:13 -0500
Subject: [MINC-users] multi-input output type/range
In-Reply-To: <CAG0CB20NNK9i=Mee8FU-p6+1V1mX4PxZykV-AQVxxzELodCH6Q@mail.gmail.com>
References: <CABEEk16ee+mBXhLWmKutHJCZbPL3JmeCDmLycMHG7QLziO5Qpw@mail.gmail.com>
	<50AAAA38.5040504@gmail.com>
	<CAG0CB23NjKqB8PO_zaoPU0EMKCZD27bCyVRGV+ZpzSSj-xNXkA@mail.gmail.com>
	<CABEEk16J8pk-XzY2FpkbpOTfE=Ge8QkDHitK2PPqBf8qq_tEmQ@mail.gmail.com>
	<CAG0CB20rKddUBM4Q9d-cvOn9wm=-GL9PjNKOG+MzrouBYYuSBQ@mail.gmail.com>
	<CABEEk141rDUeYg2d_1wyNxojGkBOUTs731Tnc6LACuR7bSnsQQ@mail.gmail.com>
	<CAG0CB20NNK9i=Mee8FU-p6+1V1mX4PxZykV-AQVxxzELodCH6Q@mail.gmail.com>
Message-ID: <CABEEk16Mx=OxvXQ+DPg9=8eom2WrNSyK7Uoa7FrEQeRKLKZR4g@mail.gmail.com>

On Tue, Nov 20, 2012 at 1:39 AM, Andrew Janke <a.janke at gmail.com> wrote:
>> What would be happening is something like this:
>>
>> minccalc -expression "abs(A[0] - 2) < 0.5 ? A[1] : 0" <cls.mnc>
>> <in.mnc> <masked.mnc>
>>
>> where <cls.mnc> happened to be "unsigned byte 0 4"; now resulting in
>> <masked.mnc> quantized to 5 values.
>
> Hrm, well the range bit could probably be changed but again it's hard
> to think of a way where we can handle all possibilities.

Agreed - but I think it is not so difficult to think of a way that
handles a lot more possibilities than the current implementation :)

> So what's the default? the full range of the type?  I can see this
> breaking when I use minccalc on label volumes with restricted ranges
> that I depend upon.

The way I have implemented in scripts, is to look through the input
volumes, find the "largest" data type among them; then find the
largest range among the volumes that have that data type, and pass the
result  along to the output file via -<datatype> -range <min> <max>.
(for float/double no need for -range of course). Works well in all
cases I have so far come across. Also handles the non-commutative
nature of mincmath/calc.

> I am curious to know what happens (But haven't checked) if in the
> above case you add a -byte option. Does this reset the range?

Yup - you'd have to specify -range as well to control that again.

-- A

From zijdenbos at gmail.com  Tue Nov 20 09:30:25 2012
From: zijdenbos at gmail.com (Alex Zijdenbos)
Date: Tue, 20 Nov 2012 09:30:25 -0500
Subject: [MINC-users] multi-input output type/range
In-Reply-To: <CAG0CB22EkxcOdReHmvKtK16UU=8MR3-wuMCoTwoFujRLneWrXw@mail.gmail.com>
References: <CAG0CB20rKddUBM4Q9d-cvOn9wm=-GL9PjNKOG+MzrouBYYuSBQ@mail.gmail.com>
	<201211200355.qAK3ttrv021353@cassio.bic.mni.mcgill.ca>
	<CAG0CB22EkxcOdReHmvKtK16UU=8MR3-wuMCoTwoFujRLneWrXw@mail.gmail.com>
Message-ID: <CABEEk16zLvLTnC9hpGsnoqyc_F2bLheU9+wQZ37HrHVfdPQ=ng@mail.gmail.com>

>> or to explicitly specify the output type. Maybe adding an option such
>> as "minccalc -like file.mnc -expression ...." would be an easy way to
>> remind the user to choose an output data type.
>
> This sounds like a very sensible idea. There is a "-filetype" option
> for minccalc that probably few know of which is along this track.

Well - mincmath has this option too, but this is currently a no-op, is
it not? It is the default and there is no alternative, other than
specifying the data type explicitly; so the option might as well not
exist :) I doubt that anybody has ever used it, for that reason.
Perhaps it could be re-used to do what Claude suggest - but it would
then have to take an argument.

> would prefer to not use -like given that this is already used for a
> different purpose in mincresample so would prefer not to muddy the
> waters.

Agreed. And if a -like option is going to be added anywhere, I vote
for mincreshape :)

> So I'm open to suggestions. -outtype?

Seems reasonable to me. Note that this option still requires that the
user is aware which file to use as a model, which I was hoping to
avoid. I think that conceptually, if I want to add two volumes (with
different data types) using

  mincmath -add A.mnc B.mnc sum.mnc

I shouldn't have to figure out which has the larger data type, but I
would nevertheless still expect to get the same result if I switch A
and B. That is currently not the case.

>> About loss of data, I think this is a separate issue. Binarization
>> of data is part of the minc concept, but what I don't like about it,
>> especially for integer data types, are the different min/max scaling
>> values by slice. This means a value of 100 can vary from slice to
>> slice. This is particularly annoying with labels. I think Andrew
>> once pointed out a global compilation variable to set to obtain
>> a global min/max for the entire volume, but I forgot it since. I
>> would very much like to be able to enable this feature on a per
>> file basis via a command line option.
>
> This would mean some changes to voxel_loop.{c,h} which would then have
> to be exposed via some C/L switch. Probably the easiest way to achieve
> this functionality is to simple specify the -range option (eg: -range
> 0 255) in minccalc.

The issue of label values and scaling comes up regularly, and in my
mind is one of the biggest problems MINC has/has had. I have scripts
that manipulate label volumes that call 'mincreshape -valid_range -
image_range' after practically *every* call to one of the other MINC
tools, which is really tedious. It is also quite difficult to explain
to novice users; I probably have a lengthy discussion about this with
somebody at least once a month.

Would there be any conceivable way to make MINC aware of a pure
integer data type without rewriting large swaths of the library? For
instance, could the scaling simply be turned off (like I assume it is
for float), under command-line control and/or a header attribute? Like
a -noscale option or some such?

-- A

From vladimir.fonov at gmail.com  Tue Nov 20 11:33:24 2012
From: vladimir.fonov at gmail.com (Vladimir S. FONOV)
Date: Tue, 20 Nov 2012 11:33:24 -0500
Subject: [MINC-users] multi-input output type/range
In-Reply-To: <CABEEk16zLvLTnC9hpGsnoqyc_F2bLheU9+wQZ37HrHVfdPQ=ng@mail.gmail.com>
References: <CAG0CB20rKddUBM4Q9d-cvOn9wm=-GL9PjNKOG+MzrouBYYuSBQ@mail.gmail.com>
	<201211200355.qAK3ttrv021353@cassio.bic.mni.mcgill.ca>
	<CAG0CB22EkxcOdReHmvKtK16UU=8MR3-wuMCoTwoFujRLneWrXw@mail.gmail.com>
	<CABEEk16zLvLTnC9hpGsnoqyc_F2bLheU9+wQZ37HrHVfdPQ=ng@mail.gmail.com>
Message-ID: <50ABB0D4.6010402@gmail.com>

Hello,


Actually MINC2 even has a 'label' data type , which breaks compatibility 
with minc1 layer, but behaves in a way that you want.

On 12-11-20 09:30 AM, Alex Zijdenbos wrote:
> The issue of label values and scaling comes up regularly, and in my
> mind is one of the biggest problems MINC has/has had. I have scripts
> that manipulate label volumes that call 'mincreshape -valid_range -
> image_range' after practically *every* call to one of the other MINC
> tools, which is really tedious. It is also quite difficult to explain
> to novice users; I probably have a lengthy discussion about this with
> somebody at least once a month.
>
> Would there be any conceivable way to make MINC aware of a pure
> integer data type without rewriting large swaths of the library? For
> instance, could the scaling simply be turned off (like I assume it is
> for float), under command-line control and/or a header attribute? Like
> a -noscale option or some such?




-- 
Best regards,

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

From zijdenbos at gmail.com  Tue Nov 20 16:53:52 2012
From: zijdenbos at gmail.com (Alex Zijdenbos)
Date: Tue, 20 Nov 2012 16:53:52 -0500
Subject: [MINC-users] multi-input output type/range
In-Reply-To: <50ABB0D4.6010402@gmail.com>
References: <CAG0CB20rKddUBM4Q9d-cvOn9wm=-GL9PjNKOG+MzrouBYYuSBQ@mail.gmail.com>
	<201211200355.qAK3ttrv021353@cassio.bic.mni.mcgill.ca>
	<CAG0CB22EkxcOdReHmvKtK16UU=8MR3-wuMCoTwoFujRLneWrXw@mail.gmail.com>
	<CABEEk16zLvLTnC9hpGsnoqyc_F2bLheU9+wQZ37HrHVfdPQ=ng@mail.gmail.com>
	<50ABB0D4.6010402@gmail.com>
Message-ID: <CABEEk16owc92P-ZMxjgzQoUYW5ggKBJdf9C4WA7WH85bVLPc1g@mail.gmail.com>

!! Who'd have thunk. Those who implemented MINC2 I guess :)

But this is so far not used above-hood - in any of the minc* tools, is it?

-- A

On Tue, Nov 20, 2012 at 11:33 AM, Vladimir S. FONOV
<vladimir.fonov at gmail.com> wrote:
> Hello,
>
>
> Actually MINC2 even has a 'label' data type , which breaks compatibility
> with minc1 layer, but behaves in a way that you want.
>
>
> On 12-11-20 09:30 AM, Alex Zijdenbos wrote:
>>
>> The issue of label values and scaling comes up regularly, and in my
>> mind is one of the biggest problems MINC has/has had. I have scripts
>> that manipulate label volumes that call 'mincreshape -valid_range -
>> image_range' after practically *every* call to one of the other MINC
>> tools, which is really tedious. It is also quite difficult to explain
>> to novice users; I probably have a lengthy discussion about this with
>> somebody at least once a month.
>>
>> Would there be any conceivable way to make MINC aware of a pure
>> integer data type without rewriting large swaths of the library? For
>> instance, could the scaling simply be turned off (like I assume it is
>> for float), under command-line control and/or a header attribute? Like
>> a -noscale option or some such?
>
>
>
>
>
> --
> Best regards,
>
>  Vladimir S. FONOV ~ vladimir.fonov <at> gmail.com
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From vladimir.fonov at gmail.com  Tue Nov 20 17:01:55 2012
From: vladimir.fonov at gmail.com (Vladimir S. FONOV)
Date: Tue, 20 Nov 2012 17:01:55 -0500
Subject: [MINC-users] multi-input output type/range
In-Reply-To: <CABEEk16owc92P-ZMxjgzQoUYW5ggKBJdf9C4WA7WH85bVLPc1g@mail.gmail.com>
References: <CAG0CB20rKddUBM4Q9d-cvOn9wm=-GL9PjNKOG+MzrouBYYuSBQ@mail.gmail.com>
	<201211200355.qAK3ttrv021353@cassio.bic.mni.mcgill.ca>
	<CAG0CB22EkxcOdReHmvKtK16UU=8MR3-wuMCoTwoFujRLneWrXw@mail.gmail.com>
	<CABEEk16zLvLTnC9hpGsnoqyc_F2bLheU9+wQZ37HrHVfdPQ=ng@mail.gmail.com>
	<50ABB0D4.6010402@gmail.com>
	<CABEEk16owc92P-ZMxjgzQoUYW5ggKBJdf9C4WA7WH85bVLPc1g@mail.gmail.com>
Message-ID: <50ABFDD3.4090104@gmail.com>

Unfortunately, as I said, it breaks compatibility with minc1 api, which 
is basis for most minc tools. So, it doesn't work with minccalc as far 
as I know. You can see example in
https://github.com/BIC-MNI/libminc/blob/master/testdir/minc2-label-test.c
- one can even store a lookup table describing what the numeric values 
mean (i.e 1 - CSF,  2 - Gray Matter, 3 - White Matter etc. ).


On 12-11-20 04:53 PM, Alex Zijdenbos wrote:
> !! Who'd have thunk. Those who implemented MINC2 I guess :)
>
> But this is so far not used above-hood - in any of the minc* tools, is it?
>
> -- A
>
> On Tue, Nov 20, 2012 at 11:33 AM, Vladimir S. FONOV
> <vladimir.fonov at gmail.com> wrote:
>> Hello,
>>
>>
>> Actually MINC2 even has a 'label' data type , which breaks compatibility
>> with minc1 layer, but behaves in a way that you want.
>>
>>
>> On 12-11-20 09:30 AM, Alex Zijdenbos wrote:
>>>
>>> The issue of label values and scaling comes up regularly, and in my
>>> mind is one of the biggest problems MINC has/has had. I have scripts
>>> that manipulate label volumes that call 'mincreshape -valid_range -
>>> image_range' after practically *every* call to one of the other MINC
>>> tools, which is really tedious. It is also quite difficult to explain
>>> to novice users; I probably have a lengthy discussion about this with
>>> somebody at least once a month.
>>>
>>> Would there be any conceivable way to make MINC aware of a pure
>>> integer data type without rewriting large swaths of the library? For
>>> instance, could the scaling simply be turned off (like I assume it is
>>> for float), under command-line control and/or a header attribute? Like
>>> a -noscale option or some such?


-- 
Best regards,

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

From peter.neelin at gmail.com  Thu Nov 22 06:21:11 2012
From: peter.neelin at gmail.com (Peter Neelin)
Date: Thu, 22 Nov 2012 06:21:11 -0500
Subject: [MINC-users] multi-input output type/range
In-Reply-To: <50ABB0D4.6010402@gmail.com>
References: <CAG0CB20rKddUBM4Q9d-cvOn9wm=-GL9PjNKOG+MzrouBYYuSBQ@mail.gmail.com>
	<201211200355.qAK3ttrv021353@cassio.bic.mni.mcgill.ca>
	<CAG0CB22EkxcOdReHmvKtK16UU=8MR3-wuMCoTwoFujRLneWrXw@mail.gmail.com>
	<CABEEk16zLvLTnC9hpGsnoqyc_F2bLheU9+wQZ37HrHVfdPQ=ng@mail.gmail.com>
	<50ABB0D4.6010402@gmail.com>
Message-ID: <CANcjydan7EZRffcmu1GQo0oMHGBqRhA0kzgNHH8U=uYT=o_vGg@mail.gmail.com>

On Nov 20, 2012 11:33 AM, "Vladimir S. FONOV" <vladimir.fonov at gmail.com>
wrote:

> Actually MINC2 even has a 'label' data type , which breaks compatibility
with minc1 layer, but behaves in a way that you want.

Oh, thank goodness! I was beginning to despair as I read this thread. It
was over twelve years ago (maybe fifteen) that I said that not adding a
label (integer) data type to minc was my biggest mistake. At the time of
creation of minc (1992), I was only dealing with real values, so minc only
supported float and fixed-point types (those types that you think of as
integer are in fact essentially fixed-point types). It was only when
Display became popular for segmentation that I became aware of the problem.
Labels really want to be treated as integers (although they have other
properties that are interesting - like the fact that neighbouring values
have no special relationship, so interpolation is just bad).

So it would seem to me that you want to be using minc2 (or getting someone
to implement a label type in minc1 and adding proper label awareness to all
of the core tools).

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

From redoute at cermep.fr  Thu Nov 29 10:59:36 2012
From: redoute at cermep.fr (=?ISO-8859-1?Q?J=E9r=F4me_Redout=E9?=)
Date: Thu, 29 Nov 2012 16:59:36 +0100
Subject: [MINC-users] mnc2nii voxel format
Message-ID: <50B78668.4000108@cermep.fr>

Dear all,
We need to convert minc volumes (PET volumes containing BP values) to 
Nifti images.
the minc image data type is: unsigned byte 0 to 255

Which "output voxel format" option (i.e. -short , -byte, -int..) should 
we use in order to preserve our BP values?

Thanks for your help
J.R


-- 
==================================================================
J?r?me Redout?
Ph.D. - Ing?nieur de Recherche - Universit? Claude Bernard - Lyon1
CERMEP - Imagerie du vivant
59 Bd Pinel. 69677 Bron - FRANCE
tel : 33 (0)4 72 68 86 13 (bureau)
tel : 33 (0)4 72 68 86 00 (standard)
fax : 33 (0)4 72 68 86 10
==================================================================



From a.janke at gmail.com  Thu Nov 29 14:40:06 2012
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 30 Nov 2012 05:40:06 +1000
Subject: [MINC-users] mnc2nii voxel format
In-Reply-To: <50B78668.4000108@cermep.fr>
References: <50B78668.4000108@cermep.fr>
Message-ID: <CAG0CB21JmY1r-Xts3n_PipXsOxr7JineOb_kDS5d6sn=pcJxTg@mail.gmail.com>

Hi Jerome,

Given the variation in Nifti files and how ranges are implemented I'd
recommend converting to nifti using float.

a

On 30 November 2012 01:59, J?r?me Redout? <redoute at cermep.fr> wrote:
> Dear all,
> We need to convert minc volumes (PET volumes containing BP values) to Nifti
> images.
> the minc image data type is: unsigned byte 0 to 255
>
> Which "output voxel format" option (i.e. -short , -byte, -int..) should we
> use in order to preserve our BP values?
>
> Thanks for your help
> J.R
>
>
> --
> ==================================================================
> J?r?me Redout?
> Ph.D. - Ing?nieur de Recherche - Universit? Claude Bernard - Lyon1
> CERMEP - Imagerie du vivant
> 59 Bd Pinel. 69677 Bron - FRANCE
> tel : 33 (0)4 72 68 86 13 (bureau)
> tel : 33 (0)4 72 68 86 00 (standard)
> fax : 33 (0)4 72 68 86 10
> ==================================================================
>
>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users