From thomas.funck at mail.mcgill.ca  Wed Oct 10 12:19:40 2012
From: thomas.funck at mail.mcgill.ca (Thomas Funck)
Date: Wed, 10 Oct 2012 16:19:40 +0000
Subject: [MINC-users] EBTKS compilation issue
Message-ID: <53F3FD0032C9CC4BA836E8F0FC2890650BCEF8@EXMBX2010-4.campus.MCGILL.CA>

Hi,

I'm trying to compile the EBTKS libraries and I'm coming up against the following errors after running make. Any ideas what is causing this? Configure seems to run fine.

I had a similar "memcpy was not declared in scope" error when compiling Array.cc, which I solved by adding "#include <string.h>" to Array.cc. Not sure what to do in this case though. 

Thanks for any help!

Thomas

templates/CachedArray.cc:1084:1:   required from here
templates/CachedArray.cc:870:3: error: 'extrema' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
templates/CachedArray.cc:870:3: note: declarations in dependent base 'SimpleArray<char>' are not found by unqualified lookup
templates/CachedArray.cc:870:3: note: use 'this->extrema' instead
templates/CachedArray.cc:897:3: error: 'removeAllNotIn' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
templates/CachedArray.cc:897:3: note: declarations in dependent base 'SimpleArray<char>' are not found by unqualified lookup
templates/CachedArray.cc:897:3: note: use 'this->removeAllNotIn' instead
templates/CachedArray.cc: In instantiation of 'Type CachedArray<Type>::_histMedian(unsigned int, unsigned int) [with Type = float]':
templates/CachedArray.cc:1085:1:   required from here
templates/CachedArray.cc:870:3: error: 'extrema' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
templates/CachedArray.cc:870:3: note: declarations in dependent base 'SimpleArray<float>' are not found by unqualified lookup
templates/CachedArray.cc:870:3: note: use 'this->extrema' instead
templates/CachedArray.cc:897:3: error: 'removeAllNotIn' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
templates/CachedArray.cc:897:3: note: declarations in dependent base 'SimpleArray<float>' are not found by unqualified lookup
templates/CachedArray.cc:897:3: note: use 'this->removeAllNotIn' instead

From vladimir.fonov at gmail.com  Wed Oct 10 12:25:31 2012
From: vladimir.fonov at gmail.com (Vladimir S. FONOV)
Date: Wed, 10 Oct 2012 12:25:31 -0400
Subject: [MINC-users] EBTKS compilation issue
In-Reply-To: <53F3FD0032C9CC4BA836E8F0FC2890650BCEF8@EXMBX2010-4.campus.MCGILL.CA>
References: <53F3FD0032C9CC4BA836E8F0FC2890650BCEF8@EXMBX2010-4.campus.MCGILL.CA>
Message-ID: <CAMCwi7OwvnnCf7A+PUDA-EmxhVpSusiXWpJOQQ4v61TRkcDQ9g@mail.gmail.com>

Hello Thomas,

which version of EBTKS are you compiling and also what environment
(i,e os, version of compiler etc.)

On Wed, Oct 10, 2012 at 12:19 PM, Thomas Funck
<thomas.funck at mail.mcgill.ca> wrote:
> Hi,
>
> I'm trying to compile the EBTKS libraries and I'm coming up against the following errors after running make. Any ideas what is causing this? Configure seems to run fine.
>
> I had a similar "memcpy was not declared in scope" error when compiling Array.cc, which I solved by adding "#include <string.h>" to Array.cc. Not sure what to do in this case though.
>
> Thanks for any help!
>
> Thomas
>
> templates/CachedArray.cc:1084:1:   required from here
> templates/CachedArray.cc:870:3: error: 'extrema' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
> templates/CachedArray.cc:870:3: note: declarations in dependent base 'SimpleArray<char>' are not found by unqualified lookup
> templates/CachedArray.cc:870:3: note: use 'this->extrema' instead
> templates/CachedArray.cc:897:3: error: 'removeAllNotIn' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
> templates/CachedArray.cc:897:3: note: declarations in dependent base 'SimpleArray<char>' are not found by unqualified lookup
> templates/CachedArray.cc:897:3: note: use 'this->removeAllNotIn' instead
> templates/CachedArray.cc: In instantiation of 'Type CachedArray<Type>::_histMedian(unsigned int, unsigned int) [with Type = float]':
> templates/CachedArray.cc:1085:1:   required from here
> templates/CachedArray.cc:870:3: error: 'extrema' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
> templates/CachedArray.cc:870:3: note: declarations in dependent base 'SimpleArray<float>' are not found by unqualified lookup
> templates/CachedArray.cc:870:3: note: use 'this->extrema' instead
> templates/CachedArray.cc:897:3: error: 'removeAllNotIn' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
> templates/CachedArray.cc:897:3: note: declarations in dependent base 'SimpleArray<float>' are not found by unqualified lookup
> templates/CachedArray.cc:897:3: note: use 'this->removeAllNotIn' instead
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users



-- 
Best regards,

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

From thomas.funck at mail.mcgill.ca  Mon Oct 15 09:32:11 2012
From: thomas.funck at mail.mcgill.ca (Thomas Funck)
Date: Mon, 15 Oct 2012 13:32:11 +0000
Subject: [MINC-users] MINC-users Digest, Vol 87, Issue 1
In-Reply-To: <mailman.3.1349971202.20909.minc-users@bic.mni.mcgill.ca>
References: <mailman.3.1349971202.20909.minc-users@bic.mni.mcgill.ca>
Message-ID: <53F3FD0032C9CC4BA836E8F0FC2890650BE15A@EXMBX2010-4.campus.MCGILL.CA>

Hi Vladimir,

I am attempting to compile EBTKS-1.6.4 on arch linux. 

Best,

Thomas
________________________________________
From: minc-users-bounces at bic.mni.mcgill.ca [minc-users-bounces at bic.mni.mcgill.ca] on behalf of minc-users-request at bic.mni.mcgill.ca [minc-users-request at bic.mni.mcgill.ca]
Sent: Thursday, October 11, 2012 12:00 PM
To: minc-users at bic.mni.mcgill.ca
Subject: MINC-users Digest, Vol 87, Issue 1

Send MINC-users mailing list submissions to
        minc-users at bic.mni.mcgill.ca

To subscribe or unsubscribe via the World Wide Web, visit
        http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
or, via email, send a message with subject or body 'help' to
        minc-users-request at bic.mni.mcgill.ca

You can reach the person managing the list at
        minc-users-owner at bic.mni.mcgill.ca

When replying, please edit your Subject line so it is more specific
than "Re: Contents of MINC-users digest..."


Today's Topics:

   1. EBTKS compilation issue (Thomas Funck)
   2. Re: EBTKS compilation issue (Vladimir S. FONOV)


----------------------------------------------------------------------

Message: 1
Date: Wed, 10 Oct 2012 16:19:40 +0000
From: Thomas Funck <thomas.funck at mail.mcgill.ca>
To: "minc-users at bic.mni.mcgill.ca" <minc-users at bic.mni.mcgill.ca>
Subject: [MINC-users] EBTKS compilation issue
Message-ID:
        <53F3FD0032C9CC4BA836E8F0FC2890650BCEF8 at EXMBX2010-4.campus.MCGILL.CA>
Content-Type: text/plain; charset="us-ascii"

Hi,

I'm trying to compile the EBTKS libraries and I'm coming up against the following errors after running make. Any ideas what is causing this? Configure seems to run fine.

I had a similar "memcpy was not declared in scope" error when compiling Array.cc, which I solved by adding "#include <string.h>" to Array.cc. Not sure what to do in this case though.

Thanks for any help!

Thomas

templates/CachedArray.cc:1084:1:   required from here
templates/CachedArray.cc:870:3: error: 'extrema' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
templates/CachedArray.cc:870:3: note: declarations in dependent base 'SimpleArray<char>' are not found by unqualified lookup
templates/CachedArray.cc:870:3: note: use 'this->extrema' instead
templates/CachedArray.cc:897:3: error: 'removeAllNotIn' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
templates/CachedArray.cc:897:3: note: declarations in dependent base 'SimpleArray<char>' are not found by unqualified lookup
templates/CachedArray.cc:897:3: note: use 'this->removeAllNotIn' instead
templates/CachedArray.cc: In instantiation of 'Type CachedArray<Type>::_histMedian(unsigned int, unsigned int) [with Type = float]':
templates/CachedArray.cc:1085:1:   required from here
templates/CachedArray.cc:870:3: error: 'extrema' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
templates/CachedArray.cc:870:3: note: declarations in dependent base 'SimpleArray<float>' are not found by unqualified lookup
templates/CachedArray.cc:870:3: note: use 'this->extrema' instead
templates/CachedArray.cc:897:3: error: 'removeAllNotIn' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
templates/CachedArray.cc:897:3: note: declarations in dependent base 'SimpleArray<float>' are not found by unqualified lookup
templates/CachedArray.cc:897:3: note: use 'this->removeAllNotIn' instead

------------------------------

Message: 2
Date: Wed, 10 Oct 2012 12:25:31 -0400
From: "Vladimir S. FONOV" <vladimir.fonov at gmail.com>
To: MINC users mailing list <minc-users at bic.mni.mcgill.ca>
Subject: Re: [MINC-users] EBTKS compilation issue
Message-ID:
        <CAMCwi7OwvnnCf7A+PUDA-EmxhVpSusiXWpJOQQ4v61TRkcDQ9g at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hello Thomas,

which version of EBTKS are you compiling and also what environment
(i,e os, version of compiler etc.)

On Wed, Oct 10, 2012 at 12:19 PM, Thomas Funck
<thomas.funck at mail.mcgill.ca> wrote:
> Hi,
>
> I'm trying to compile the EBTKS libraries and I'm coming up against the following errors after running make. Any ideas what is causing this? Configure seems to run fine.
>
> I had a similar "memcpy was not declared in scope" error when compiling Array.cc, which I solved by adding "#include <string.h>" to Array.cc. Not sure what to do in this case though.
>
> Thanks for any help!
>
> Thomas
>
> templates/CachedArray.cc:1084:1:   required from here
> templates/CachedArray.cc:870:3: error: 'extrema' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
> templates/CachedArray.cc:870:3: note: declarations in dependent base 'SimpleArray<char>' are not found by unqualified lookup
> templates/CachedArray.cc:870:3: note: use 'this->extrema' instead
> templates/CachedArray.cc:897:3: error: 'removeAllNotIn' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
> templates/CachedArray.cc:897:3: note: declarations in dependent base 'SimpleArray<char>' are not found by unqualified lookup
> templates/CachedArray.cc:897:3: note: use 'this->removeAllNotIn' instead
> templates/CachedArray.cc: In instantiation of 'Type CachedArray<Type>::_histMedian(unsigned int, unsigned int) [with Type = float]':
> templates/CachedArray.cc:1085:1:   required from here
> templates/CachedArray.cc:870:3: error: 'extrema' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
> templates/CachedArray.cc:870:3: note: declarations in dependent base 'SimpleArray<float>' are not found by unqualified lookup
> templates/CachedArray.cc:870:3: note: use 'this->extrema' instead
> templates/CachedArray.cc:897:3: error: 'removeAllNotIn' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
> templates/CachedArray.cc:897:3: note: declarations in dependent base 'SimpleArray<float>' are not found by unqualified lookup
> templates/CachedArray.cc:897:3: note: use 'this->removeAllNotIn' instead
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users



--
Best regards,

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


------------------------------

_______________________________________________
MINC-users mailing list
MINC-users at bic.mni.mcgill.ca
http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users


End of MINC-users Digest, Vol 87, Issue 1
*****************************************

From thomas.funck at mail.mcgill.ca  Mon Oct 15 10:34:22 2012
From: thomas.funck at mail.mcgill.ca (Thomas Funck)
Date: Mon, 15 Oct 2012 14:34:22 +0000
Subject: [MINC-users] MINC-users Digest, Vol 87, Issue 1
In-Reply-To: <mailman.3.1349971202.20909.minc-users@bic.mni.mcgill.ca>
References: <mailman.3.1349971202.20909.minc-users@bic.mni.mcgill.ca>
Message-ID: <53F3FD0032C9CC4BA836E8F0FC2890650BE18F@EXMBX2010-4.campus.MCGILL.CA>

Hi again,

Think I solved my problem. There appears to have been an update to gnu that change to the way g++ performs name look-ups (http://gcc.gnu.org/gcc-4.7/porting_to.html) that causes problems when compiling EBTKS. As the site recommends I added "-fpermissive" to the g++ command  and this seems to have sovled my problem. Specifically I added:

CPPFLAGS =  -I/usr/local/bic/include -fpermissive

to "Makefile". Does this sound like a reasonable solution? 

Best,

Thomas
 
________________________________________
From: minc-users-bounces at bic.mni.mcgill.ca [minc-users-bounces at bic.mni.mcgill.ca] on behalf of minc-users-request at bic.mni.mcgill.ca [minc-users-request at bic.mni.mcgill.ca]
Sent: Thursday, October 11, 2012 12:00 PM
To: minc-users at bic.mni.mcgill.ca
Subject: MINC-users Digest, Vol 87, Issue 1

Send MINC-users mailing list submissions to
        minc-users at bic.mni.mcgill.ca

To subscribe or unsubscribe via the World Wide Web, visit
        http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
or, via email, send a message with subject or body 'help' to
        minc-users-request at bic.mni.mcgill.ca

You can reach the person managing the list at
        minc-users-owner at bic.mni.mcgill.ca

When replying, please edit your Subject line so it is more specific
than "Re: Contents of MINC-users digest..."


Today's Topics:

   1. EBTKS compilation issue (Thomas Funck)
   2. Re: EBTKS compilation issue (Vladimir S. FONOV)


----------------------------------------------------------------------

Message: 1
Date: Wed, 10 Oct 2012 16:19:40 +0000
From: Thomas Funck <thomas.funck at mail.mcgill.ca>
To: "minc-users at bic.mni.mcgill.ca" <minc-users at bic.mni.mcgill.ca>
Subject: [MINC-users] EBTKS compilation issue
Message-ID:
        <53F3FD0032C9CC4BA836E8F0FC2890650BCEF8 at EXMBX2010-4.campus.MCGILL.CA>
Content-Type: text/plain; charset="us-ascii"

Hi,

I'm trying to compile the EBTKS libraries and I'm coming up against the following errors after running make. Any ideas what is causing this? Configure seems to run fine.

I had a similar "memcpy was not declared in scope" error when compiling Array.cc, which I solved by adding "#include <string.h>" to Array.cc. Not sure what to do in this case though.

Thanks for any help!

Thomas

templates/CachedArray.cc:1084:1:   required from here
templates/CachedArray.cc:870:3: error: 'extrema' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
templates/CachedArray.cc:870:3: note: declarations in dependent base 'SimpleArray<char>' are not found by unqualified lookup
templates/CachedArray.cc:870:3: note: use 'this->extrema' instead
templates/CachedArray.cc:897:3: error: 'removeAllNotIn' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
templates/CachedArray.cc:897:3: note: declarations in dependent base 'SimpleArray<char>' are not found by unqualified lookup
templates/CachedArray.cc:897:3: note: use 'this->removeAllNotIn' instead
templates/CachedArray.cc: In instantiation of 'Type CachedArray<Type>::_histMedian(unsigned int, unsigned int) [with Type = float]':
templates/CachedArray.cc:1085:1:   required from here
templates/CachedArray.cc:870:3: error: 'extrema' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
templates/CachedArray.cc:870:3: note: declarations in dependent base 'SimpleArray<float>' are not found by unqualified lookup
templates/CachedArray.cc:870:3: note: use 'this->extrema' instead
templates/CachedArray.cc:897:3: error: 'removeAllNotIn' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
templates/CachedArray.cc:897:3: note: declarations in dependent base 'SimpleArray<float>' are not found by unqualified lookup
templates/CachedArray.cc:897:3: note: use 'this->removeAllNotIn' instead

------------------------------

Message: 2
Date: Wed, 10 Oct 2012 12:25:31 -0400
From: "Vladimir S. FONOV" <vladimir.fonov at gmail.com>
To: MINC users mailing list <minc-users at bic.mni.mcgill.ca>
Subject: Re: [MINC-users] EBTKS compilation issue
Message-ID:
        <CAMCwi7OwvnnCf7A+PUDA-EmxhVpSusiXWpJOQQ4v61TRkcDQ9g at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hello Thomas,

which version of EBTKS are you compiling and also what environment
(i,e os, version of compiler etc.)

On Wed, Oct 10, 2012 at 12:19 PM, Thomas Funck
<thomas.funck at mail.mcgill.ca> wrote:
> Hi,
>
> I'm trying to compile the EBTKS libraries and I'm coming up against the following errors after running make. Any ideas what is causing this? Configure seems to run fine.
>
> I had a similar "memcpy was not declared in scope" error when compiling Array.cc, which I solved by adding "#include <string.h>" to Array.cc. Not sure what to do in this case though.
>
> Thanks for any help!
>
> Thomas
>
> templates/CachedArray.cc:1084:1:   required from here
> templates/CachedArray.cc:870:3: error: 'extrema' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
> templates/CachedArray.cc:870:3: note: declarations in dependent base 'SimpleArray<char>' are not found by unqualified lookup
> templates/CachedArray.cc:870:3: note: use 'this->extrema' instead
> templates/CachedArray.cc:897:3: error: 'removeAllNotIn' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
> templates/CachedArray.cc:897:3: note: declarations in dependent base 'SimpleArray<char>' are not found by unqualified lookup
> templates/CachedArray.cc:897:3: note: use 'this->removeAllNotIn' instead
> templates/CachedArray.cc: In instantiation of 'Type CachedArray<Type>::_histMedian(unsigned int, unsigned int) [with Type = float]':
> templates/CachedArray.cc:1085:1:   required from here
> templates/CachedArray.cc:870:3: error: 'extrema' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
> templates/CachedArray.cc:870:3: note: declarations in dependent base 'SimpleArray<float>' are not found by unqualified lookup
> templates/CachedArray.cc:870:3: note: use 'this->extrema' instead
> templates/CachedArray.cc:897:3: error: 'removeAllNotIn' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
> templates/CachedArray.cc:897:3: note: declarations in dependent base 'SimpleArray<float>' are not found by unqualified lookup
> templates/CachedArray.cc:897:3: note: use 'this->removeAllNotIn' instead
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users



--
Best regards,

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


------------------------------

_______________________________________________
MINC-users mailing list
MINC-users at bic.mni.mcgill.ca
http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users


End of MINC-users Digest, Vol 87, Issue 1
*****************************************

From Johnathon.Walls at regeneron.com  Tue Oct 16 15:05:40 2012
From: Johnathon.Walls at regeneron.com (Johnathon Walls)
Date: Tue, 16 Oct 2012 15:05:40 -0400
Subject: [MINC-users] mincaverage behaviour
Message-ID: <CCA32843.A89A%Johnathon.Walls@regeneron.com>

   Hello,
   I am running across some unexpected behaviour for mincaverage using
   -normalize and I'm not sure if it's a bug or not.
   Description:
   mincaverage -normalize in1.mnc in2.mnc in3.mnc out.mnc
   results in out.mnc with all zeros if the input files have a mean less
   than zero.
   I can reproduce this every time.
   At the moment I am able to 'hack' my minc files by adding a constant so
   that they all have means > 0.
   I think perhaps the issue might lie in lines 533-561 here:
   [1]https://github.com/BIC-MNI/minc/blob/master/progs/mincaverage/mincav
   erage.c
   Where vol_mean[ifile] is included in the determination of vol_total and
   global_mean (lines 537 and 554), but the value of
   average_data.norm_factor[ifile] is conditional upon the vol_mean[ifile]
   being > 0 (otherwise, the norm_factor[ifile] is set to 0.0).
   Any ideas if this is a bug (though perhaps not in the lines that I am
   suggesting) or a design decision?  If it's a design decision, can I ask
   the reasoning? (Maybe I'm not understanding the meaning of world values
   in minc files?)
   Thanks
   Johnathon
   --
   Johnathon R. Walls, PhD
   Scientist - Therapeutic Target Discovery
   Regeneron Pharmaceuticals
   777 Old Saw Mill River Road
   Tarrytown, NY USA 10591-6707
   Phone: 914.847.3006 Fax: 914.847.7544
   Email: johnathon.walls at regeneron.com

   This e-mail and any attachment hereto, is intended only for use by the
   addressee(s) named above and may contain legally privileged and/or
   confidential information. If you are not the intended recipient of this
   e-mail, any dissemination, distribution or copying of this email, or
   any attachment hereto, is strictly prohibited. If you receive this
   email in error please immediately notify me by return electronic mail
   and permanently delete this email and any attachment hereto, any copy
   of this e-mail and of any such attachment, and any printout thereof.
   Finally, please note that only authorized representatives of Regeneron
   Pharmaceuticals, Inc. have the power and authority to enter into
   business dealings with any third party.

References

   1. https://github.com/BIC-MNI/minc/blob/master/progs/mincaverage/mincaverage.c

From peter.neelin at gmail.com  Tue Oct 16 22:28:56 2012
From: peter.neelin at gmail.com (Peter Neelin)
Date: Tue, 16 Oct 2012 22:28:56 -0400
Subject: [MINC-users] mincaverage behaviour
In-Reply-To: <CCA32843.A89A%Johnathon.Walls@regeneron.com>
References: <CCA32843.A89A%Johnathon.Walls@regeneron.com>
Message-ID: <CANcjydZFPo4nmy-0fjE+f5HZrdoROfB_XAviCSamENjRHs74cA@mail.gmail.com>

On Oct 16, 2012 3:05 PM, "Johnathon Walls" <Johnathon.Walls at regeneron.com>
wrote:

>    I think perhaps the issue might lie in lines 533-561 here:
>    [1]
https://github.com/BIC-MNI/minc/blob/master/progs/mincaverage/mincaverage.c
>    Where vol_mean[ifile] is included in the determination of vol_total and
>    global_mean (lines 537 and 554), but the value of
>    average_data.norm_factor[ifile] is conditional upon the vol_mean[ifile]
>    being > 0 (otherwise, the norm_factor[ifile] is set to 0.0).
>    Any ideas if this is a bug (though perhaps not in the lines that I am
>    suggesting) or a design decision?  If it's a design decision, can I ask
>    the reasoning? (Maybe I'm not understanding the meaning of world values
>    in minc files?)

Looks like a bug to me. Not sure why I would not have tested for == 0.0 (or
better, abs(mean) > epsilon) - perhaps I copied the test for sum0 > 0
(which does make sense, since sum0 is a count). Remarkable that no one has
found it in the past 17 years.

(Boy, that main() is embarrassingly long! If I were doing a code review I
would definitely have something to say to the kid who wrote that!)

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

From george.he at yale.edu  Wed Oct 17 10:10:17 2012
From: george.he at yale.edu (George He)
Date: Wed, 17 Oct 2012 10:10:17 -0400
Subject: [MINC-users] source compile
Message-ID: <CAAsg+B37G1h_vpfZDD57=78hbQ9owVHGdQg4wo=61zmhdDHTiw@mail.gmail.com>

Hi there,

I have been using a few programs from the minc-toolkit on an SGI machine
and my goal is to compile it on Fedora/Centos machines.
I downloaded minc-toolkit source code from
https://github.com/BIC-MNI/minc-toolkit and then I tried to follow the
instructions on that page to compile it (since I'm using Fedora/Centos).

cmake ../minc-toolkit   -- this seemed working.
make stopped at here:

[ 58%] Building CXX object
oobicpl/CMakeFiles/vertstats_math.dir/src/vertstats_math.cc.o
In file included from
/home/jhe/Downloads/minc-toolkit/oobicpl/src/vertstats_math.cc:2:0:
/home/jhe/Downloads/minc-toolkit/oobicpl/src/mniVertstatsMath.h: In
instantiation of ?T vectorMean(std::vector<T>&) [with T = float]?:
/home/jhe/Downloads/minc-toolkit/oobicpl/src/mniVertstatsMath.h:93:25:
required from ?std::vector<T> vectorNormalise(std::vector<T>&) [with T =
float]?
/home/jhe/Downloads/minc-toolkit/oobicpl/src/vertstats_math.cc:215:38:
required from here
/home/jhe/Downloads/minc-toolkit/oobicpl/src/mniVertstatsMath.h:58:23:
error: ?vectorSum? was not declared in this scope, and no declarations were
found by argument-dependent lookup at the point of instantiation
[-fpermissive]
/home/jhe/Downloads/minc-toolkit/oobicpl/src/mniVertstatsMath.h:65:3: note:
?template<class T> T vectorSum(std::vector<T>)? declared here, later in the
translation unit
make[2]: ***
[oobicpl/CMakeFiles/vertstats_math.dir/src/vertstats_math.cc.o] Error 1
make[1]: *** [oobicpl/CMakeFiles/vertstats_math.dir/all] Error 2
make: *** [all] Error 2

But it's OK since I only need a few functions in conglomerate, so I just cd
into conglomerate and did make and make install.
It worked. but then I found I need the program "deform_surface", which was
not compiled by default. Further, I found it was declared but not defined
anywhere in the source code I have.

My question is: where can I get the source code that defines
deform_surface? If it was replace by another program, what is it? and how
do I use that program to achieve what deform_surface was doing?
It would be even better if you could help to compile the whole package.

Thanks for the help.
George

From george.he at yale.edu  Wed Oct 17 11:31:37 2012
From: george.he at yale.edu (George He)
Date: Wed, 17 Oct 2012 11:31:37 -0400
Subject: [MINC-users] source compile
In-Reply-To: <CAAsg+B37G1h_vpfZDD57=78hbQ9owVHGdQg4wo=61zmhdDHTiw@mail.gmail.com>
References: <CAAsg+B37G1h_vpfZDD57=78hbQ9owVHGdQg4wo=61zmhdDHTiw@mail.gmail.com>
Message-ID: <CAAsg+B2cF3NtVZq4q2GQBvgwJEZiO2cj1gy0dUOkdtgzvxdtpQ@mail.gmail.com>

correction:
The function declared but not defined is deform_polygons, which is called
by deform_surface.
Thanks,
George

On Wed, Oct 17, 2012 at 10:10 AM, George He <george.he at yale.edu> wrote:

> Hi there,
>
> I have been using a few programs from the minc-toolkit on an SGI machine
> and my goal is to compile it on Fedora/Centos machines.
> I downloaded minc-toolkit source code from
> https://github.com/BIC-MNI/minc-toolkit and then I tried to follow the
> instructions on that page to compile it (since I'm using Fedora/Centos).
>
> cmake ../minc-toolkit   -- this seemed working.
> make stopped at here:
>
> [ 58%] Building CXX object
> oobicpl/CMakeFiles/vertstats_math.dir/src/vertstats_math.cc.o
> In file included from
> /home/jhe/Downloads/minc-toolkit/oobicpl/src/vertstats_math.cc:2:0:
> /home/jhe/Downloads/minc-toolkit/oobicpl/src/mniVertstatsMath.h: In
> instantiation of ?T vectorMean(std::vector<T>&) [with T = float]?:
> /home/jhe/Downloads/minc-toolkit/oobicpl/src/mniVertstatsMath.h:93:25:
> required from ?std::vector<T> vectorNormalise(std::vector<T>&) [with T =
> float]?
> /home/jhe/Downloads/minc-toolkit/oobicpl/src/vertstats_math.cc:215:38:
> required from here
> /home/jhe/Downloads/minc-toolkit/oobicpl/src/mniVertstatsMath.h:58:23:
> error: ?vectorSum? was not declared in this scope, and no declarations were
> found by argument-dependent lookup at the point of instantiation
> [-fpermissive]
> /home/jhe/Downloads/minc-toolkit/oobicpl/src/mniVertstatsMath.h:65:3:
> note: ?template<class T> T vectorSum(std::vector<T>)? declared here, later
> in the translation unit
> make[2]: ***
> [oobicpl/CMakeFiles/vertstats_math.dir/src/vertstats_math.cc.o] Error 1
> make[1]: *** [oobicpl/CMakeFiles/vertstats_math.dir/all] Error 2
> make: *** [all] Error 2
>
> But it's OK since I only need a few functions in conglomerate, so I just
> cd into conglomerate and did make and make install.
> It worked. but then I found I need the program "deform_surface", which was
> not compiled by default. Further, I found it was declared but not defined
> anywhere in the source code I have.
>
> My question is: where can I get the source code that defines
> deform_surface? If it was replace by another program, what is it? and how
> do I use that program to achieve what deform_surface was doing?
> It would be even better if you could help to compile the whole package.
>
> Thanks for the help.
> George
>
>

From trash001 at odu.edu  Wed Oct 17 14:09:28 2012
From: trash001 at odu.edu (Tanweer Rashid)
Date: Wed, 17 Oct 2012 14:09:28 -0400
Subject: [MINC-users] Invalid voxel values
Message-ID: <CAE1j2ujeWBzeAvE7fDzTyApMu0UL-teRbnw5Ke+EuMw-=qGyDA@mail.gmail.com>

Hi,

I am getting invalid/inconsistent voxel values when I use
miget_voxel_value(). The MINC volume has a minimum voxel value of 0 and max
voxel value of 123. However, in some cases, miget_voxel_value() returns
values greater than 123. Is there some scaling/computation that needs to be
done after miget_voxel_value()?

Thanks,
-- 
Tanweer Rashid
MSVE Dept.
Old Dominion University

From Johnathon.Walls at regeneron.com  Wed Oct 17 18:50:07 2012
From: Johnathon.Walls at regeneron.com (Johnathon Walls)
Date: Wed, 17 Oct 2012 18:50:07 -0400
Subject: [MINC-users] mincaverage behaviour
In-Reply-To: <CANcjydZFPo4nmy-0fjE+f5HZrdoROfB_XAviCSamENjRHs74cA@mail.gmail.com>
Message-ID: <CCA4AE2E.AB04%Johnathon.Walls@regeneron.com>

Ok, thanks for letting me know!

jrw
-- 
Johnathon R. Walls, PhD
Scientist - Therapeutic Target Discovery
Regeneron Pharmaceuticals
777 Old Saw Mill River Road
Tarrytown, NY USA 10591-6707
Phone: 914.847.3006 Fax: 914.847.7544
Email: johnathon.walls at regeneron.com




On 10/16/12 10:28 PM, "Peter Neelin" <peter.neelin at gmail.com> wrote:

>On Oct 16, 2012 3:05 PM, "Johnathon Walls" <Johnathon.Walls at regeneron.com>
>wrote:
>
>>    I think perhaps the issue might lie in lines 533-561 here:
>>    [1]
>https://github.com/BIC-MNI/minc/blob/master/progs/mincaverage/mincaverage.
>c
>>    Where vol_mean[ifile] is included in the determination of vol_total
>>and
>>    global_mean (lines 537 and 554), but the value of
>>    average_data.norm_factor[ifile] is conditional upon the
>>vol_mean[ifile]
>>    being > 0 (otherwise, the norm_factor[ifile] is set to 0.0).
>>    Any ideas if this is a bug (though perhaps not in the lines that I am
>>    suggesting) or a design decision?  If it's a design decision, can I
>>ask
>>    the reasoning? (Maybe I'm not understanding the meaning of world
>>values
>>    in minc files?)
>
>Looks like a bug to me. Not sure why I would not have tested for == 0.0
>(or
>better, abs(mean) > epsilon) - perhaps I copied the test for sum0 > 0
>(which does make sense, since sum0 is a count). Remarkable that no one has
>found it in the past 17 years.
>
>(Boy, that main() is embarrassingly long! If I were doing a code review I
>would definitely have something to say to the kid who wrote that!)
>
>Peter
>--
>Peter Neelin
>peter.neelin at gmail.com
>_______________________________________________
>MINC-users at bic.mni.mcgill.ca
>http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users

*
*******************************************************************
This e-mail and any attachment hereto, is intended only for use by
the addressee(s) named above and may contain legally privileged
and/or confidential information. If you are not the intended
recipient of this e-mail, any dissemination, distribution or
copying of this email, or any attachment hereto, is strictly
prohibited. If you receive this email in error please immediately
notify me by return electronic mail and permanently delete this
email and any attachment hereto, any copy of this e-mail and of any
such attachment, and any printout thereof. Finally, please note
that only authorized representatives of Regeneron Pharmaceuticals,
Inc. have the power and authority to enter into business dealings
with any third party.
*******************************************************************
*

From maudette at odu.edu  Fri Oct 19 14:52:48 2012
From: maudette at odu.edu (Audette, Michel A.)
Date: Fri, 19 Oct 2012 18:52:48 +0000
Subject: [MINC-users] my student needs help with a scaling issue
Message-ID: <22EC75E8215562428ACADFA35877A25A04E69E@JANEWAY.ts.odu.edu>

Dear Minc users,

my student Tanweer Rashid seems to be having a scaling issue related to reading a minc image.

We are trying to read a digital deep-brain atlas graciously supplied by Mallar Chakravarty, and the voxel values that we get with minc routines are not quite consistent with the values that we get with the print_all_labels command run offline.

See below, which features the output of print_all_labels (which looks reasonable), calls to miget_voxel_value() within Tanweer's program, and the source code of his that calls it.

Can anyone spot something that we are doing wrong, and offer guidance on correcting Tanweer's bug?

Thanks for your kind support.

Michel

Michel Audette, Ph.D.
Assistant Professor,
Department of Modeling, Simulation and Visualization Engineering,
Old Dominion University,
Norfolk, VA.

________________________________
From: Tanweer Rashid [trash001 at odu.edu]
Sent: Friday, October 19, 2012 11:49 AM
To: Audette, Michel A.
Subject: Code and results

Results from print_all_labels():
trash001 at LCARS:/usr/local/bin$ print_all_labels ~/Desktop/labels_on_colin_Nov2010_minc2.mnc
Label: 1 933459
Label: 2 1433227
Label: 3 50946
Label: 4 893200
Label: 5 37056
Label: 6 38333
Label: 7 47522
Label: 8 11922
Label: 9 9238
Label: 10 7369
Label: 11 39738
Label: 12 53097
Label: 13 10502
Label: 14 5301
Label: 15 147
Label: 16 33782
Label: 17 918
Label: 18 296
Label: 19 504
Label: 20 5060
Label: 21 9438
Label: 22 1739
Label: 23 574
Label: 24 138283
Label: 25 16869
Label: 26 22419
Label: 27 5337
Label: 28 10464
Label: 29 9293
Label: 30 1191
Label: 31 201
Label: 32 190
Label: 33 513
Label: 34 166
Label: 35 71684
Label: 36 11454
Label: 37 72714
Label: 38 153


Results from using miget_voxel_value():
Label 0: 26653169
Label 1: 0
Label 2: 933459
Label 3: 0
Label 4: 1433227
Label 5: 0
Label 6: 50946
Label 7: 0
Label 8: 670661
Label 9: 222539
Label 10: 20739
Label 11: 16317
Label 12: 3187
Label 13: 35146
Label 14: 25484
Label 15: 22038
Label 16: 4324
Label 17: 7598
Label 18: 1261
Label 19: 7977
Label 20: 0
Label 21: 7369
Label 22: 3099
Label 23: 36639
Label 24: 0
Label 25: 53097
Label 26: 0
Label 27: 10502
Label 28: 0
Label 29: 5192
Label 30: 109
Label 31: 147
Label 32: 0
Label 33: 32633
Label 34: 1149
Label 35: 918
Label 36: 0
Label 37: 258
Label 38: 38
Label 39: 244
Label 40: 260
Label 41: 4869

Code:
    mihandle_t volume;
    int result;

    result = miopen_volume("/home/trash001/Desktop/labels_on_colin_Nov2010_minc2.mnc", MI2_OPEN_READ, &volume);
    if (result == MI_ERROR) cout << "Error in opening MINC file. " << endl;

    int labels[125];
    for (int q = 0; q < 125; q++) labels[q] = 0;

    unsigned long location[3];
    double voxel;
    for (int i = 0; i < 334; i++) {
        for (int j = 0; j < 334; j++) {
            for (int k = 0; k < 334; k++) {
                location[0] = i;
                location[1] = j;
                location[2] = k;

                result = miget_voxel_value(volume, location, 3, &voxel);
                if (result == MI_ERROR) cout << "Error in reading voxels" << endl;
                else {
                    if (voxel >= 0 && voxel <= 123) {
                        labels[(int)voxel] = labels[(int)voxel] + 1;
                    }
                    else if (voxel > 123) {
                        labels[124] = labels[124] + 1;
                    }
                }
            }
        }
    }

--
Tanweer Rashid
MSVE Dept.
Old Dominion University

________________________________

Spam<https://www.spamtrap.odu.edu/canit/b.php?i=01Id3Nqxx&m=7100c97e3076&t=20121019&c=s>
Not spam<https://www.spamtrap.odu.edu/canit/b.php?i=01Id3Nqxx&m=7100c97e3076&t=20121019&c=n>
Forget previous vote<https://www.spamtrap.odu.edu/canit/b.php?i=01Id3Nqxx&m=7100c97e3076&t=20121019&c=f>

From zijdenbos at gmail.com  Fri Oct 19 15:09:26 2012
From: zijdenbos at gmail.com (Alex Zijdenbos)
Date: Fri, 19 Oct 2012 15:09:26 -0400
Subject: [MINC-users] my student needs help with a scaling issue
In-Reply-To: <22EC75E8215562428ACADFA35877A25A04E69E@JANEWAY.ts.odu.edu>
References: <22EC75E8215562428ACADFA35877A25A04E69E@JANEWAY.ts.odu.edu>
Message-ID: <CABEEk14A=beagC5fCyAPMeW4K61sJV7vmTPFHLUFqPoo9ckujA@mail.gmail.com>

Hi Michel,

Looks to me that you are bitten by the difference between the "real"
values (which you would normally use, and which I assume
print_all_labels produces), and the "voxel" values? There is a linear
mapping between voxel values (as stored in the data type) and the real
values. This mapping is determined by the range of the data type of
the file, and the range of your data. In other words,

real = a*voxel + b

the advantage of this is that this way MINC can represent arbitrary
data ranges even though the data type may be limited; the disadvantage
is that discrete values, such as those used in atlases, may be mapped
to floating point values or show odd discretization effects like you
have here. For label volumes, the best is to remove the range scaling
(and make sure that the data type as enough resolution for your data).
Try this:

mincreshape -image_range 0 255 -valid_range 0 255 <in.mnc> <out.mnc>

which should remove the scaling (or rather, turn it into a one-to-one mapping).

-- A

On Fri, Oct 19, 2012 at 2:52 PM, Audette, Michel A. <maudette at odu.edu> wrote:
> Dear Minc users,
>
> my student Tanweer Rashid seems to be having a scaling issue related to reading a minc image.
>
> We are trying to read a digital deep-brain atlas graciously supplied by Mallar Chakravarty, and the voxel values that we get with minc routines are not quite consistent with the values that we get with the print_all_labels command run offline.
>
> See below, which features the output of print_all_labels (which looks reasonable), calls to miget_voxel_value() within Tanweer's program, and the source code of his that calls it.
>
> Can anyone spot something that we are doing wrong, and offer guidance on correcting Tanweer's bug?
>
> Thanks for your kind support.
>
> Michel
>
> Michel Audette, Ph.D.
> Assistant Professor,
> Department of Modeling, Simulation and Visualization Engineering,
> Old Dominion University,
> Norfolk, VA.
>
> ________________________________
> From: Tanweer Rashid [trash001 at odu.edu]
> Sent: Friday, October 19, 2012 11:49 AM
> To: Audette, Michel A.
> Subject: Code and results
>
> Results from print_all_labels():
> trash001 at LCARS:/usr/local/bin$ print_all_labels ~/Desktop/labels_on_colin_Nov2010_minc2.mnc
> Label: 1 933459
> Label: 2 1433227
> Label: 3 50946
> Label: 4 893200
> Label: 5 37056
> Label: 6 38333
> Label: 7 47522
> Label: 8 11922
> Label: 9 9238
> Label: 10 7369
> Label: 11 39738
> Label: 12 53097
> Label: 13 10502
> Label: 14 5301
> Label: 15 147
> Label: 16 33782
> Label: 17 918
> Label: 18 296
> Label: 19 504
> Label: 20 5060
> Label: 21 9438
> Label: 22 1739
> Label: 23 574
> Label: 24 138283
> Label: 25 16869
> Label: 26 22419
> Label: 27 5337
> Label: 28 10464
> Label: 29 9293
> Label: 30 1191
> Label: 31 201
> Label: 32 190
> Label: 33 513
> Label: 34 166
> Label: 35 71684
> Label: 36 11454
> Label: 37 72714
> Label: 38 153
>
>
> Results from using miget_voxel_value():
> Label 0: 26653169
> Label 1: 0
> Label 2: 933459
> Label 3: 0
> Label 4: 1433227
> Label 5: 0
> Label 6: 50946
> Label 7: 0
> Label 8: 670661
> Label 9: 222539
> Label 10: 20739
> Label 11: 16317
> Label 12: 3187
> Label 13: 35146
> Label 14: 25484
> Label 15: 22038
> Label 16: 4324
> Label 17: 7598
> Label 18: 1261
> Label 19: 7977
> Label 20: 0
> Label 21: 7369
> Label 22: 3099
> Label 23: 36639
> Label 24: 0
> Label 25: 53097
> Label 26: 0
> Label 27: 10502
> Label 28: 0
> Label 29: 5192
> Label 30: 109
> Label 31: 147
> Label 32: 0
> Label 33: 32633
> Label 34: 1149
> Label 35: 918
> Label 36: 0
> Label 37: 258
> Label 38: 38
> Label 39: 244
> Label 40: 260
> Label 41: 4869
>
> Code:
>     mihandle_t volume;
>     int result;
>
>     result = miopen_volume("/home/trash001/Desktop/labels_on_colin_Nov2010_minc2.mnc", MI2_OPEN_READ, &volume);
>     if (result == MI_ERROR) cout << "Error in opening MINC file. " << endl;
>
>     int labels[125];
>     for (int q = 0; q < 125; q++) labels[q] = 0;
>
>     unsigned long location[3];
>     double voxel;
>     for (int i = 0; i < 334; i++) {
>         for (int j = 0; j < 334; j++) {
>             for (int k = 0; k < 334; k++) {
>                 location[0] = i;
>                 location[1] = j;
>                 location[2] = k;
>
>                 result = miget_voxel_value(volume, location, 3, &voxel);
>                 if (result == MI_ERROR) cout << "Error in reading voxels" << endl;
>                 else {
>                     if (voxel >= 0 && voxel <= 123) {
>                         labels[(int)voxel] = labels[(int)voxel] + 1;
>                     }
>                     else if (voxel > 123) {
>                         labels[124] = labels[124] + 1;
>                     }
>                 }
>             }
>         }
>     }
>
> --
> Tanweer Rashid
> MSVE Dept.
> Old Dominion University
>
> ________________________________
>
> Spam<https://www.spamtrap.odu.edu/canit/b.php?i=01Id3Nqxx&m=7100c97e3076&t=20121019&c=s>
> Not spam<https://www.spamtrap.odu.edu/canit/b.php?i=01Id3Nqxx&m=7100c97e3076&t=20121019&c=n>
> Forget previous vote<https://www.spamtrap.odu.edu/canit/b.php?i=01Id3Nqxx&m=7100c97e3076&t=20121019&c=f>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From maudette at odu.edu  Fri Oct 19 15:16:15 2012
From: maudette at odu.edu (Audette, Michel A.)
Date: Fri, 19 Oct 2012 19:16:15 +0000
Subject: [MINC-users] my student needs help with a scaling issue
In-Reply-To: <CABEEk14A=beagC5fCyAPMeW4K61sJV7vmTPFHLUFqPoo9ckujA@mail.gmail.com>
References: <22EC75E8215562428ACADFA35877A25A04E69E@JANEWAY.ts.odu.edu>,
	<CABEEk14A=beagC5fCyAPMeW4K61sJV7vmTPFHLUFqPoo9ckujA@mail.gmail.com>
Message-ID: <22EC75E8215562428ACADFA35877A25A04E70E@JANEWAY.ts.odu.edu>

Hi Alex, 

thanks for your kind reply. I'll get Tanweer right on it and report back. 

Warm wishes,

Michel


Michel Audette, Ph.D.
Assistant Professor,
Department of Modeling, Simulation and Visualization Engineering,
Old Dominion University,
Norfolk, VA.
________________________________________
From: minc-users-bounces at bic.mni.mcgill.ca [minc-users-bounces at bic.mni.mcgill.ca] on behalf of Alex Zijdenbos [zijdenbos at gmail.com]
Sent: Friday, October 19, 2012 3:09 PM
To: MINC users mailing list
Subject: Re: [MINC-users] my student needs help with a scaling issue

Hi Michel,

Looks to me that you are bitten by the difference between the "real"
values (which you would normally use, and which I assume
print_all_labels produces), and the "voxel" values? There is a linear
mapping between voxel values (as stored in the data type) and the real
values. This mapping is determined by the range of the data type of
the file, and the range of your data. In other words,

real = a*voxel + b

the advantage of this is that this way MINC can represent arbitrary
data ranges even though the data type may be limited; the disadvantage
is that discrete values, such as those used in atlases, may be mapped
to floating point values or show odd discretization effects like you
have here. For label volumes, the best is to remove the range scaling
(and make sure that the data type as enough resolution for your data).
Try this:

mincreshape -image_range 0 255 -valid_range 0 255 <in.mnc> <out.mnc>

which should remove the scaling (or rather, turn it into a one-to-one mapping).

-- A

On Fri, Oct 19, 2012 at 2:52 PM, Audette, Michel A. <maudette at odu.edu> wrote:
> Dear Minc users,
>
> my student Tanweer Rashid seems to be having a scaling issue related to reading a minc image.
>
> We are trying to read a digital deep-brain atlas graciously supplied by Mallar Chakravarty, and the voxel values that we get with minc routines are not quite consistent with the values that we get with the print_all_labels command run offline.
>
> See below, which features the output of print_all_labels (which looks reasonable), calls to miget_voxel_value() within Tanweer's program, and the source code of his that calls it.
>
> Can anyone spot something that we are doing wrong, and offer guidance on correcting Tanweer's bug?
>
> Thanks for your kind support.
>
> Michel
>
> Michel Audette, Ph.D.
> Assistant Professor,
> Department of Modeling, Simulation and Visualization Engineering,
> Old Dominion University,
> Norfolk, VA.
>
> ________________________________
> From: Tanweer Rashid [trash001 at odu.edu]
> Sent: Friday, October 19, 2012 11:49 AM
> To: Audette, Michel A.
> Subject: Code and results
>
> Results from print_all_labels():
> trash001 at LCARS:/usr/local/bin$ print_all_labels ~/Desktop/labels_on_colin_Nov2010_minc2.mnc
> Label: 1 933459
> Label: 2 1433227
> Label: 3 50946
> Label: 4 893200
> Label: 5 37056
> Label: 6 38333
> Label: 7 47522
> Label: 8 11922
> Label: 9 9238
> Label: 10 7369
> Label: 11 39738
> Label: 12 53097
> Label: 13 10502
> Label: 14 5301
> Label: 15 147
> Label: 16 33782
> Label: 17 918
> Label: 18 296
> Label: 19 504
> Label: 20 5060
> Label: 21 9438
> Label: 22 1739
> Label: 23 574
> Label: 24 138283
> Label: 25 16869
> Label: 26 22419
> Label: 27 5337
> Label: 28 10464
> Label: 29 9293
> Label: 30 1191
> Label: 31 201
> Label: 32 190
> Label: 33 513
> Label: 34 166
> Label: 35 71684
> Label: 36 11454
> Label: 37 72714
> Label: 38 153
>
>
> Results from using miget_voxel_value():
> Label 0: 26653169
> Label 1: 0
> Label 2: 933459
> Label 3: 0
> Label 4: 1433227
> Label 5: 0
> Label 6: 50946
> Label 7: 0
> Label 8: 670661
> Label 9: 222539
> Label 10: 20739
> Label 11: 16317
> Label 12: 3187
> Label 13: 35146
> Label 14: 25484
> Label 15: 22038
> Label 16: 4324
> Label 17: 7598
> Label 18: 1261
> Label 19: 7977
> Label 20: 0
> Label 21: 7369
> Label 22: 3099
> Label 23: 36639
> Label 24: 0
> Label 25: 53097
> Label 26: 0
> Label 27: 10502
> Label 28: 0
> Label 29: 5192
> Label 30: 109
> Label 31: 147
> Label 32: 0
> Label 33: 32633
> Label 34: 1149
> Label 35: 918
> Label 36: 0
> Label 37: 258
> Label 38: 38
> Label 39: 244
> Label 40: 260
> Label 41: 4869
>
> Code:
>     mihandle_t volume;
>     int result;
>
>     result = miopen_volume("/home/trash001/Desktop/labels_on_colin_Nov2010_minc2.mnc", MI2_OPEN_READ, &volume);
>     if (result == MI_ERROR) cout << "Error in opening MINC file. " << endl;
>
>     int labels[125];
>     for (int q = 0; q < 125; q++) labels[q] = 0;
>
>     unsigned long location[3];
>     double voxel;
>     for (int i = 0; i < 334; i++) {
>         for (int j = 0; j < 334; j++) {
>             for (int k = 0; k < 334; k++) {
>                 location[0] = i;
>                 location[1] = j;
>                 location[2] = k;
>
>                 result = miget_voxel_value(volume, location, 3, &voxel);
>                 if (result == MI_ERROR) cout << "Error in reading voxels" << endl;
>                 else {
>                     if (voxel >= 0 && voxel <= 123) {
>                         labels[(int)voxel] = labels[(int)voxel] + 1;
>                     }
>                     else if (voxel > 123) {
>                         labels[124] = labels[124] + 1;
>                     }
>                 }
>             }
>         }
>     }
>
> --
> Tanweer Rashid
> MSVE Dept.
> Old Dominion University
>
> ________________________________
>
> _______________________________________________
> 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


--
BEGIN-ANTISPAM-VOTING-LINKS
------------------------------------------------------

Teach CanIt if this mail (ID 01Id7eHSp) is spam:
Spam:        https://www.spamtrap.odu.edu/canit/b.php?i=01Id7eHSp&m=4b5f8a753cae&t=20121019&c=s
Not spam:    https://www.spamtrap.odu.edu/canit/b.php?i=01Id7eHSp&m=4b5f8a753cae&t=20121019&c=n
Forget vote: https://www.spamtrap.odu.edu/canit/b.php?i=01Id7eHSp&m=4b5f8a753cae&t=20121019&c=f
------------------------------------------------------
END-ANTISPAM-VOTING-LINKS


From a.janke at gmail.com  Sat Oct 20 06:11:28 2012
From: a.janke at gmail.com (Andrew Janke)
Date: Sat, 20 Oct 2012 20:11:28 +1000
Subject: [MINC-users] my student needs help with a scaling issue
In-Reply-To: <22EC75E8215562428ACADFA35877A25A04E70E@JANEWAY.ts.odu.edu>
References: <22EC75E8215562428ACADFA35877A25A04E69E@JANEWAY.ts.odu.edu>
	<CABEEk14A=beagC5fCyAPMeW4K61sJV7vmTPFHLUFqPoo9ckujA@mail.gmail.com>
	<22EC75E8215562428ACADFA35877A25A04E70E@JANEWAY.ts.odu.edu>
Message-ID: <CAG0CB20eOrVWsawD03EJ-bp1Nv928Hmp8EiYduX3nY8LBW+WYg@mail.gmail.com>

There is also no reason as to why you wouldn't use miget_real_value if
the voxel to world mapping is correct for the label file.

a

On 20 October 2012 05:16, Audette, Michel A. <maudette at odu.edu> wrote:
> thanks for your kind reply. I'll get Tanweer right on it and report back.

From george.he at yale.edu  Mon Oct 22 08:20:40 2012
From: george.he at yale.edu (George He)
Date: Mon, 22 Oct 2012 08:20:40 -0400
Subject: [MINC-users] deform_polygons
Message-ID: <CAAsg+B2-kBpv3cu9z_148PELmYyRJ-WVpWJLOpJpvyhg82Kvjg@mail.gmail.com>

Hello minc-toolkit developers,
Does anybody know where I can find the deform_polygons function source code?
which is declared in conglomerate/deform_prototypes.h, and called in
conglomerate/deform_surface.c, but I cannot find where it is defined.
Thanks,
George

From r.muetzel at erasmusmc.nl  Fri Oct 26 09:13:21 2012
From: r.muetzel at erasmusmc.nl (R.L. Muetzel)
Date: Fri, 26 Oct 2012 13:13:21 +0000
Subject: [MINC-users] 4d data with dcm2mnc
Message-ID: <4842C2F14EDDF7448ECB275088A2FB232E1485@EXCH-HE04.erasmusmc.nl>

Hello all,


We are having trouble converting 4D data with dcm2mnc?.basically, we get a 3D image out, and no error messages in the command line.

We compiled this version (the tar.gz file):

http://www.bic.mni.mcgill.ca/pipermail/minc-users/2012-September/003522.html

The output from dcm2mnc -version:

~$ dcm2mnc -version
program: 2.0.07 built Oct 25 2012 16:57:03
libminc: 2.2.00
netcdf : 4.1.1 of Nov  7 2011 11:35:16 $
HDF5   : 1.8.4

Any thoughts on what might be going on?  would it be helpful for us to send you the output from -debug?  

Thanks in advance for any help!

(also, sorry if this is a duplicate post, as I'm not sure if it got sent through twice)

Ryan Muetzel
Generation R/Department of Child and Adolescent Psychiatry
Erasmus MC - Sophia Children's Hospital
Rotterdam, the Netherlands

From vladimir.fonov at gmail.com  Fri Oct 26 15:30:36 2012
From: vladimir.fonov at gmail.com (Vladimir S. FONOV)
Date: Fri, 26 Oct 2012 15:30:36 -0400
Subject: [MINC-users] 4d data with dcm2mnc
In-Reply-To: <4842C2F14EDDF7448ECB275088A2FB232E1485@EXCH-HE04.erasmusmc.nl>
References: <4842C2F14EDDF7448ECB275088A2FB232E1485@EXCH-HE04.erasmusmc.nl>
Message-ID: <508AE4DC.4060007@gmail.com>

Hello Ryan,

I suppose exact command line and the output of -debug would be useful. 
Also, can you describe what kind of dicom files you have got?

On 12-10-26 09:13 AM, R.L. Muetzel wrote:
> Hello all,
>
>
> We are having trouble converting 4D data with dcm2mnc?.basically, we get a 3D image out, and no error messages in the command line.
>
> We compiled this version (the tar.gz file):
>
> http://www.bic.mni.mcgill.ca/pipermail/minc-users/2012-September/003522.html
>
> The output from dcm2mnc -version:
>
> ~$ dcm2mnc -version
> program: 2.0.07 built Oct 25 2012 16:57:03
> libminc: 2.2.00
> netcdf : 4.1.1 of Nov  7 2011 11:35:16 $
> HDF5   : 1.8.4
>
> Any thoughts on what might be going on?  would it be helpful for us to send you the output from -debug?
>
> Thanks in advance for any help!
>
> (also, sorry if this is a duplicate post, as I'm not sure if it got sent through twice)
>
> Ryan Muetzel
> Generation R/Department of Child and Adolescent Psychiatry
> Erasmus MC - Sophia Children's Hospital
> Rotterdam, the Netherlands
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>


-- 
Best regards,

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

From r.muetzel at erasmusmc.nl  Sat Oct 27 04:58:15 2012
From: r.muetzel at erasmusmc.nl (R.L. Muetzel)
Date: Sat, 27 Oct 2012 08:58:15 +0000
Subject: [MINC-users] 4d data with dcm2mnc
In-Reply-To: <508AE4DC.4060007@gmail.com>
References: <4842C2F14EDDF7448ECB275088A2FB232E1485@EXCH-HE04.erasmusmc.nl>
	<508AE4DC.4060007@gmail.com>
Message-ID: <4842C2F14EDDF7448ECB275088A2FB232E2C87@EXCH-HE04.erasmusmc.nl>

Dear Dr. Fonov,

Thank you for your help!

Below in the text, you'll find the screen output with the -debug flag turned off, and attached you'll find the output from both the -debug and from mincheader.

We are using a clinical GE MR750 3T.  These are EPI fMRI data.  Each dicom file is a single slice (i.e., we're not using any kind of mosaic format, 37 slices, 160TRs = 5290 files).  I have also included the output from dcmtk /dcmdump for one of the dicom files, which includes some of the dicom headers.  Does this give you enough info about the dicom?  Let me know if there are other questions I can answer about the type of dicom.

Thank you again for your time and help!

All the best,

Ryan


lorisadmin at rietveld:~/sample_scans/R112749_100$ dcm2mnc RestingState__160_Volumes37slices2sec_7 ./rs_160_dcm2mnc
Checking file types...
File RestingState__160_Volumes37slices2sec_7/IM-0006-0906.dcm appears to be DICOM (CD/Export).
Parsing 5920 files   |<--------------------------------------------------->|
Sorting 5920 files...   Done sorting files.
Processing files, one series at a time...
-Parsing series info |<--------------------------------------------------->|
WARNING: Coordinate spacing (-3.99999) differs from DICOM slice spacing (4)
 (perhaps you should consider the -usecoordinates option)
 Using -3.99999 for the slice spacing value.
-Creating minc file  |<--------------------------------------------------->|
Done processing files.





lorisadmin at rietveld:~/sample_scans/R112749_100$ On Oct 26, 2012, at 9:30 PM, Vladimir S. FONOV wrote:

> Hello Ryan,
>
> I suppose exact command line and the output of -debug would be useful. Also, can you describe what kind of dicom files you have got?
>
> On 12-10-26 09:13 AM, R.L. Muetzel wrote:
>> Hello all,
>>

>>
>> We are having trouble converting 4D data with dcm2mnc?.basically, we get a 3D image out, and no error messages in the command line.
>>
>> We compiled this version (the tar.gz file):
>>
>> http://www.bic.mni.mcgill.ca/pipermail/minc-users/2012-September/003522.html
>>
>> The output from dcm2mnc -version:
>>
>> ~$ dcm2mnc -version
>> program: 2.0.07 built Oct 25 2012 16:57:03
>> libminc: 2.2.00
>> netcdf : 4.1.1 of Nov  7 2011 11:35:16 $
>> HDF5   : 1.8.4
>>
>> Any thoughts on what might be going on?  would it be helpful for us to send you the output from -debug?
>>
>> Thanks in advance for any help!
>>
>> (also, sorry if this is a duplicate post, as I'm not sure if it got sent through twice)
>>
>> Ryan Muetzel
>> Generation R/Department of Child and Adolescent Psychiatry
>> Erasmus MC - Sophia Children's Hospital
>> Rotterdam, the Netherlands
>> _______________________________________________
>> MINC-users at bic.mni.mcgill.ca
>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>>
>
>
> --
> 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

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: rsfmri_160TR_dcm2mnc.mincheader.txt
URL: <http://www.bic.mni.mcgill.ca/pipermail/minc-users/attachments/20121027/e3599865/attachment-0003.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: rsfmri_160TR_dcm2mnc.debug.txt
URL: <http://www.bic.mni.mcgill.ca/pipermail/minc-users/attachments/20121027/e3599865/attachment-0004.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dcmdump.txt
URL: <http://www.bic.mni.mcgill.ca/pipermail/minc-users/attachments/20121027/e3599865/attachment-0005.txt>

From vladimir.fonov at gmail.com  Sun Oct 28 18:23:55 2012
From: vladimir.fonov at gmail.com (Vladimir S. FONOV)
Date: Sun, 28 Oct 2012 18:23:55 -0400
Subject: [MINC-users] 4d data with dcm2mnc
In-Reply-To: <4842C2F14EDDF7448ECB275088A2FB232E2C87@EXCH-HE04.erasmusmc.nl>
References: <4842C2F14EDDF7448ECB275088A2FB232E1485@EXCH-HE04.erasmusmc.nl>
	<508AE4DC.4060007@gmail.com>
	<4842C2F14EDDF7448ECB275088A2FB232E2C87@EXCH-HE04.erasmusmc.nl>
Message-ID: <508DB07B.7020604@gmail.com>

Hello,

it looks like dcm2mnc doesn't recognize that these is a time series and 
extracts only the first one ... Maybe you can try following things:

1. use -splitdynamic option - this probably will not work anyway , but 
worth trying

2. make a script which will run dcm2mnc with groups of 16 files, writing 
output in a separate minc files:

something like that (in bash):

for i in $(seq 1 160);do j in $(seq 1 37);do n=$((i*37+j));
printf 
"RestingState__160_Volumes37slices2sec_7/IM-0006-%04d.dcm\n">>/tmp/$i.lst
done
dcm2mnc -stdin -dname . -fname r112749_100_20111106_160551_`printf 
"%03d" $i`.mnc  rs_160_dcm2mnc < /tmp/$i.lst
rm /tmp/$i.lst
done

this will create series of 160 files with names
rs_160_dcm2mnc/r112749_100_20111106_160551_????.mnc  corresponding to 
the individual scans, which you can later concatenate using mincconcat 
to create a single 4D MINC file.

Hope this will help.

On 12-10-27 04:58 AM, R.L. Muetzel wrote:
> Dear Dr. Fonov,
>
> Thank you for your help!
>
> Below in the text, you'll find the screen output with the -debug flag turned off, and attached you'll find the output from both the -debug and from mincheader.
>
> We are using a clinical GE MR750 3T.  These are EPI fMRI data.  Each dicom file is a single slice (i.e., we're not using any kind of mosaic format, 37 slices, 160TRs = 5290 files).  I have also included the output from dcmtk /dcmdump for one of the dicom files, which includes some of the dicom headers.  Does this give you enough info about the dicom?  Let me know if there are other questions I can answer about the type of dicom.
>
> Thank you again for your time and help!
>
> All the best,
>
> Ryan
>
>
> lorisadmin at rietveld:~/sample_scans/R112749_100$ dcm2mnc RestingState__160_Volumes37slices2sec_7 ./rs_160_dcm2mnc
> Checking file types...
> File RestingState__160_Volumes37slices2sec_7/IM-0006-0906.dcm appears to be DICOM (CD/Export).
> Parsing 5920 files   |<--------------------------------------------------->|
> Sorting 5920 files...   Done sorting files.
> Processing files, one series at a time...
> -Parsing series info |<--------------------------------------------------->|
> WARNING: Coordinate spacing (-3.99999) differs from DICOM slice spacing (4)
>   (perhaps you should consider the -usecoordinates option)
>   Using -3.99999 for the slice spacing value.
> -Creating minc file  |<--------------------------------------------------->|
> Done processing files.
>
>
>
>
>
> lorisadmin at rietveld:~/sample_scans/R112749_100$ On Oct 26, 2012, at 9:30 PM, Vladimir S. FONOV wrote:
>
>> Hello Ryan,
>>
>> I suppose exact command line and the output of -debug would be useful. Also, can you describe what kind of dicom files you have got?
>>
>> On 12-10-26 09:13 AM, R.L. Muetzel wrote:
>>> Hello all,
>>>
>
>>>
>>> We are having trouble converting 4D data with dcm2mnc?.basically, we get a 3D image out, and no error messages in the command line.
>>>
>>> We compiled this version (the tar.gz file):
>>>
>>> http://www.bic.mni.mcgill.ca/pipermail/minc-users/2012-September/003522.html
>>>
>>> The output from dcm2mnc -version:
>>>
>>> ~$ dcm2mnc -version
>>> program: 2.0.07 built Oct 25 2012 16:57:03
>>> libminc: 2.2.00
>>> netcdf : 4.1.1 of Nov  7 2011 11:35:16 $
>>> HDF5   : 1.8.4
>>>
>>> Any thoughts on what might be going on?  would it be helpful for us to send you the output from -debug?
>>>
>>> Thanks in advance for any help!
>>>
>>> (also, sorry if this is a duplicate post, as I'm not sure if it got sent through twice)
>>>
>>> Ryan Muetzel
>>> Generation R/Department of Child and Adolescent Psychiatry
>>> Erasmus MC - Sophia Children's Hospital
>>> Rotterdam, the Netherlands


-- 
Best regards,

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