From ptcougopinto at gmail.com  Thu Sep  1 14:54:30 2016
From: ptcougopinto at gmail.com (Pedro)
Date: Thu, 1 Sep 2016 15:54:30 -0300
Subject: [MINC-users] Fill ROI
In-Reply-To: <CAG0CB20HNL7rP7a7+oK0HjQaHoz8Bo5FfNZwJku1YM1C-UcHiw@mail.gmail.com>
References: <1773343C-BA3F-4A75-819C-1704E5D1524F@gmail.com>
	<CAG0CB20HNL7rP7a7+oK0HjQaHoz8Bo5FfNZwJku1YM1C-UcHiw@mail.gmail.com>
Message-ID: <37CC7335-26CA-4057-8025-2A606FE8777B@gmail.com>

Hi, Andrew. mincmorph did the job. I was meaning 3d continuity, so it worked perfectly with your suggestion.

Pedro
> Em 16 de ago de 2016, ?(s) 12:51, Andrew Janke <a.janke at gmail.com> escreveu:
> 
> Hi Pedro,
> 
> Vladimir has some tools in ITK to do this but it depends on what you
> means by holes and if the remainder of the binary image is contiguous.
> 
> If the latter then have a look at mincmorph, you can then frame the
> problem as removing the smallest contiguous object of the inverse of
> the binary mask. To do this use the Group and K[] - keep operations.
> 
> 
> a
> 
> On 17 August 2016 at 01:47, Pedro Telles Cougo Pinto
> <ptcougopinto at gmail.com> wrote:
>> Hi, everyone
>> 
>> Is there a way to fill holes in binary volumes? Such as in the -fill option from mincbeast.
>> 
>> Thanks
>> Pedro
>> _______________________________________________
>> 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 dbolar at nmr.mgh.harvard.edu  Fri Sep  9 12:46:42 2016
From: dbolar at nmr.mgh.harvard.edu (Divya Bolar)
Date: Fri, 9 Sep 2016 12:46:42 -0400
Subject: [MINC-users] dcm2mnc freezes at end on OS X
Message-ID: <48EF4567-3609-44A4-AAAE-8017AE45C63F@nmr.mgh.harvard.edu>

Hi all, 

I know dcm2mnc has been discussed ad nauseam, but I can't seem to find any solutions in my searches.  

No matter what I do, dcm2mnc appears to freeze at the end (i.e. when writing out the mnc, which ends up being "zero bytes").    I am able to load the images into other DICOM viewers including OsiriX, so the data seems intact.  Notably,  if I import then export these DICOMs from Osirix, dcm2mnc still fails.... It seems like it is having a problem outputting (writing out) the mnc, perhaps with micreate, but I have no idea how to debug.... 

I am using the version below on MacOS X 10.9.5 mavericks.   
program: 2.01.03 built Feb  5 2016 14:01:49
libminc: 2.3.01
netcdf : 4.3.3 of Feb  5 2016 12:15:31 $
HDF5   : 1.8.15

This the command line I use (I have also tried without the -usecoordinates and lots of other combinations)
dcm2mnc -usecoordinates ./DICOM/ ./


File ./DICOM/MoCoSeries-PASL-anon/0001-1.3.12.2.1107.5.2.32.35235.2016080612385213830244495.dcm appears to be DICOM (CD/Export).
Parsing 91 files     |<--------------------------------------------------->|
Sorting 91 files...   Done sorting files.
Processing files, one series at a time...
WARNING: Acquisition number is per scan.
WARNING: Image number is a mystery.
INFO: Acquisition number ranges from 1 to 91
INFO: Image number ranges from 1 to 91
-Parsing series info |<--First Slice at 1,18.478516,0.000000               |
First Echo at 1,0.011000,0.000000
First Time at 1,0.000000,0.000000
First Phase at 1,0.000000,0.000000
First ChmSh at 1,0.000000,0.000000
-------------------------------------------------->

And then it just hangs here!


I have also tried on a 3D data set (rather than 4D)

Parsing 64 files     |<--------------------------------------------------->|
Sorting 64 files...   Done sorting files.
Processing files, one series at a time...
WARNING: Acquisition number is not informative.
WARNING: Image number is per slice.
INFO: Acquisition number ranges from 1 to 1
INFO: Image number ranges from 1 to 64
-Parsing series info |<--First Slice at 1,-41.735644,0.000000              |
First Echo at 1,0.091000,0.000000
First Time at 1,-206.275000,0.000000
First Phase at 1,0.000000,0.000000
First ChmSh at 1,0.000000,0.000000
Warning: merging extra indices on Time axis:   1 2
->Warning: merging extra indices on Time axis:   1 3

.....

Warning: merging extra indices on Time axis:   1 60
->Warning: merging extra indices on Time axis:   1 61
->Warning: merging extra indices on Time axis:   1 62
->Warning: merging extra indices on Time axis:   1 63
->
Warning: merging extra indices on Time axis:   1 64

And then it just hangs here..... 


Any assistance would be greatly appreciated, thanks so much!
Div





The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

From vladimir.fonov at gmail.com  Fri Sep  9 12:49:27 2016
From: vladimir.fonov at gmail.com (Vladimir S. FONOV)
Date: Fri, 9 Sep 2016 12:49:27 -0400
Subject: [MINC-users] dcm2mnc freezes at end on OS X
In-Reply-To: <48EF4567-3609-44A4-AAAE-8017AE45C63F@nmr.mgh.harvard.edu>
References: <48EF4567-3609-44A4-AAAE-8017AE45C63F@nmr.mgh.harvard.edu>
Message-ID: <CAMCwi7PJqJWiP4=Pa8PLEKr-Tx2P2TOmvHtB7iF9bssmrm0sFw@mail.gmail.com>

Is it minc-toolkit binary installation ? If it is - which version did you
install?

On Fri, Sep 9, 2016 at 12:46 PM, Divya Bolar <dbolar at nmr.mgh.harvard.edu>
wrote:

> Hi all,
>
> I know dcm2mnc has been discussed ad nauseam, but I can't seem to find any
> solutions in my searches.
>
> No matter what I do, dcm2mnc appears to freeze at the end (i.e. when
> writing out the mnc, which ends up being "zero bytes").    I am able to
> load the images into other DICOM viewers including OsiriX, so the data
> seems intact.  Notably,  if I import then export these DICOMs from Osirix,
> dcm2mnc still fails.... It seems like it is having a problem outputting
> (writing out) the mnc, perhaps with micreate, but I have no idea how to
> debug....
>
> I am using the version below on MacOS X 10.9.5 mavericks.
> program: 2.01.03 built Feb  5 2016 14:01:49
> libminc: 2.3.01
> netcdf : 4.3.3 of Feb  5 2016 12:15:31 $
> HDF5   : 1.8.15
>
> This the command line I use (I have also tried without the -usecoordinates
> and lots of other combinations)
> dcm2mnc -usecoordinates ./DICOM/ ./
>
>
> File ./DICOM/MoCoSeries-PASL-anon/0001-1.3.12.2.1107.5.2.32.35235.2016080612385213830244495.dcm
> appears to be DICOM (CD/Export).
> Parsing 91 files     |<----------------------------
> ----------------------->|
> Sorting 91 files...   Done sorting files.
> Processing files, one series at a time...
> WARNING: Acquisition number is per scan.
> WARNING: Image number is a mystery.
> INFO: Acquisition number ranges from 1 to 91
> INFO: Image number ranges from 1 to 91
> -Parsing series info |<--First Slice at 1,18.478516,0.000000
>  |
> First Echo at 1,0.011000,0.000000
> First Time at 1,0.000000,0.000000
> First Phase at 1,0.000000,0.000000
> First ChmSh at 1,0.000000,0.000000
> -------------------------------------------------->
>
> And then it just hangs here!
>
>
> I have also tried on a 3D data set (rather than 4D)
>
> Parsing 64 files     |<----------------------------
> ----------------------->|
> Sorting 64 files...   Done sorting files.
> Processing files, one series at a time...
> WARNING: Acquisition number is not informative.
> WARNING: Image number is per slice.
> INFO: Acquisition number ranges from 1 to 1
> INFO: Image number ranges from 1 to 64
> -Parsing series info |<--First Slice at 1,-41.735644,0.000000
> |
> First Echo at 1,0.091000,0.000000
> First Time at 1,-206.275000,0.000000
> First Phase at 1,0.000000,0.000000
> First ChmSh at 1,0.000000,0.000000
> Warning: merging extra indices on Time axis:   1 2
> ->Warning: merging extra indices on Time axis:   1 3
>
> .....
>
> Warning: merging extra indices on Time axis:   1 60
> ->Warning: merging extra indices on Time axis:   1 61
> ->Warning: merging extra indices on Time axis:   1 62
> ->Warning: merging extra indices on Time axis:   1 63
> ->
> Warning: merging extra indices on Time axis:   1 64
>
> And then it just hangs here.....
>
>
> Any assistance would be greatly appreciated, thanks so much!
> Div
>
>
>
>
>
> The information in this e-mail is intended only for the person to whom it
> is
> addressed. If you believe this e-mail was sent to you in error and the
> e-mail
> contains patient information, please contact the Partners Compliance
> HelpLine at
> http://www.partners.org/complianceline . If the e-mail was sent to you in
> error
> but does not contain patient information, please contact the sender and
> properly
> dispose of the e-mail.
> _______________________________________________
> 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 robert.d.vincent at mcgill.ca  Fri Sep  9 12:51:36 2016
From: robert.d.vincent at mcgill.ca (Robert D. Vincent)
Date: Fri, 9 Sep 2016 12:51:36 -0400
Subject: [MINC-users] dcm2mnc freezes at end on OS X
In-Reply-To: <48EF4567-3609-44A4-AAAE-8017AE45C63F@nmr.mgh.harvard.edu>
References: <48EF4567-3609-44A4-AAAE-8017AE45C63F@nmr.mgh.harvard.edu>
Message-ID: <CAAd5DeTMUwceZCggSQn0hzH4Yh3KGK47qB508Rt=zutUR7=YoQ@mail.gmail.com>

Hi,

Sorry, I've not heard this one before. I'll try to reproduce the problem on
OS X today. Is there any chance you can share a sample dataset that
exhibits the problem?

    -bert

On Fri, Sep 9, 2016 at 12:46 PM, Divya Bolar <dbolar at nmr.mgh.harvard.edu>
wrote:

> Hi all,
>
> I know dcm2mnc has been discussed ad nauseam, but I can't seem to find any
> solutions in my searches.
>
> No matter what I do, dcm2mnc appears to freeze at the end (i.e. when
> writing out the mnc, which ends up being "zero bytes").    I am able to
> load the images into other DICOM viewers including OsiriX, so the data
> seems intact.  Notably,  if I import then export these DICOMs from Osirix,
> dcm2mnc still fails.... It seems like it is having a problem outputting
> (writing out) the mnc, perhaps with micreate, but I have no idea how to
> debug....
>
> I am using the version below on MacOS X 10.9.5 mavericks.
> program: 2.01.03 built Feb  5 2016 14:01:49
> libminc: 2.3.01
> netcdf : 4.3.3 of Feb  5 2016 12:15:31 $
> HDF5   : 1.8.15
>
> This the command line I use (I have also tried without the -usecoordinates
> and lots of other combinations)
> dcm2mnc -usecoordinates ./DICOM/ ./
>
>
> File ./DICOM/MoCoSeries-PASL-anon/0001-1.3.12.2.1107.5.2.32.35235.2016080612385213830244495.dcm
> appears to be DICOM (CD/Export).
> Parsing 91 files     |<----------------------------
> ----------------------->|
> Sorting 91 files...   Done sorting files.
> Processing files, one series at a time...
> WARNING: Acquisition number is per scan.
> WARNING: Image number is a mystery.
> INFO: Acquisition number ranges from 1 to 91
> INFO: Image number ranges from 1 to 91
> -Parsing series info |<--First Slice at 1,18.478516,0.000000
>  |
> First Echo at 1,0.011000,0.000000
> First Time at 1,0.000000,0.000000
> First Phase at 1,0.000000,0.000000
> First ChmSh at 1,0.000000,0.000000
> -------------------------------------------------->
>
> And then it just hangs here!
>
>
> I have also tried on a 3D data set (rather than 4D)
>
> Parsing 64 files     |<----------------------------
> ----------------------->|
> Sorting 64 files...   Done sorting files.
> Processing files, one series at a time...
> WARNING: Acquisition number is not informative.
> WARNING: Image number is per slice.
> INFO: Acquisition number ranges from 1 to 1
> INFO: Image number ranges from 1 to 64
> -Parsing series info |<--First Slice at 1,-41.735644,0.000000
> |
> First Echo at 1,0.091000,0.000000
> First Time at 1,-206.275000,0.000000
> First Phase at 1,0.000000,0.000000
> First ChmSh at 1,0.000000,0.000000
> Warning: merging extra indices on Time axis:   1 2
> ->Warning: merging extra indices on Time axis:   1 3
>
> .....
>
> Warning: merging extra indices on Time axis:   1 60
> ->Warning: merging extra indices on Time axis:   1 61
> ->Warning: merging extra indices on Time axis:   1 62
> ->Warning: merging extra indices on Time axis:   1 63
> ->
> Warning: merging extra indices on Time axis:   1 64
>
> And then it just hangs here.....
>
>
> Any assistance would be greatly appreciated, thanks so much!
> Div
>
>
>
>
>
> The information in this e-mail is intended only for the person to whom it
> is
> addressed. If you believe this e-mail was sent to you in error and the
> e-mail
> contains patient information, please contact the Partners Compliance
> HelpLine at
> http://www.partners.org/complianceline . If the e-mail was sent to you in
> error
> but does not contain patient information, please contact the sender and
> properly
> dispose of the e-mail.
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From dbolar at nmr.mgh.harvard.edu  Fri Sep  9 12:54:20 2016
From: dbolar at nmr.mgh.harvard.edu (Divya Bolar)
Date: Fri, 9 Sep 2016 12:54:20 -0400
Subject: [MINC-users] dcm2mnc freezes at end on OS X
In-Reply-To: <CAMCwi7PJqJWiP4=Pa8PLEKr-Tx2P2TOmvHtB7iF9bssmrm0sFw@mail.gmail.com>
References: <48EF4567-3609-44A4-AAAE-8017AE45C63F@nmr.mgh.harvard.edu>
	<CAMCwi7PJqJWiP4=Pa8PLEKr-Tx2P2TOmvHtB7iF9bssmrm0sFw@mail.gmail.com>
Message-ID: <9BA0D954-F456-4094-921F-B782C8606865@nmr.mgh.harvard.edu>

Yes, apologies:

minc-toolkit-1.0.08-20160205-Darwin-10.7-x86_64.dmg

Thanks also for such a quick reply!
div

On Sep 9, 2016, at 12:49 PM, Vladimir S. FONOV <vladimir.fonov at gmail.com> wrote:

> Is it minc-toolkit binary installation ? If it is - which version did you
> install?
> 
> On Fri, Sep 9, 2016 at 12:46 PM, Divya Bolar <dbolar at nmr.mgh.harvard.edu>
> wrote:
> 
>> Hi all,
>> 
>> I know dcm2mnc has been discussed ad nauseam, but I can't seem to find any
>> solutions in my searches.
>> 
>> No matter what I do, dcm2mnc appears to freeze at the end (i.e. when
>> writing out the mnc, which ends up being "zero bytes").    I am able to
>> load the images into other DICOM viewers including OsiriX, so the data
>> seems intact.  Notably,  if I import then export these DICOMs from Osirix,
>> dcm2mnc still fails.... It seems like it is having a problem outputting
>> (writing out) the mnc, perhaps with micreate, but I have no idea how to
>> debug....
>> 
>> I am using the version below on MacOS X 10.9.5 mavericks.
>> program: 2.01.03 built Feb  5 2016 14:01:49
>> libminc: 2.3.01
>> netcdf : 4.3.3 of Feb  5 2016 12:15:31 $
>> HDF5   : 1.8.15
>> 
>> This the command line I use (I have also tried without the -usecoordinates
>> and lots of other combinations)
>> dcm2mnc -usecoordinates ./DICOM/ ./
>> 
>> 
>> File ./DICOM/MoCoSeries-PASL-anon/0001-1.3.12.2.1107.5.2.32.35235.2016080612385213830244495.dcm
>> appears to be DICOM (CD/Export).
>> Parsing 91 files     |<----------------------------
>> ----------------------->|
>> Sorting 91 files...   Done sorting files.
>> Processing files, one series at a time...
>> WARNING: Acquisition number is per scan.
>> WARNING: Image number is a mystery.
>> INFO: Acquisition number ranges from 1 to 91
>> INFO: Image number ranges from 1 to 91
>> -Parsing series info |<--First Slice at 1,18.478516,0.000000
>> |
>> First Echo at 1,0.011000,0.000000
>> First Time at 1,0.000000,0.000000
>> First Phase at 1,0.000000,0.000000
>> First ChmSh at 1,0.000000,0.000000
>> -------------------------------------------------->
>> 
>> And then it just hangs here!
>> 
>> 
>> I have also tried on a 3D data set (rather than 4D)
>> 
>> Parsing 64 files     |<----------------------------
>> ----------------------->|
>> Sorting 64 files...   Done sorting files.
>> Processing files, one series at a time...
>> WARNING: Acquisition number is not informative.
>> WARNING: Image number is per slice.
>> INFO: Acquisition number ranges from 1 to 1
>> INFO: Image number ranges from 1 to 64
>> -Parsing series info |<--First Slice at 1,-41.735644,0.000000
>> |
>> First Echo at 1,0.091000,0.000000
>> First Time at 1,-206.275000,0.000000
>> First Phase at 1,0.000000,0.000000
>> First ChmSh at 1,0.000000,0.000000
>> Warning: merging extra indices on Time axis:   1 2
>> ->Warning: merging extra indices on Time axis:   1 3
>> 
>> .....
>> 
>> Warning: merging extra indices on Time axis:   1 60
>> ->Warning: merging extra indices on Time axis:   1 61
>> ->Warning: merging extra indices on Time axis:   1 62
>> ->Warning: merging extra indices on Time axis:   1 63
>> ->
>> Warning: merging extra indices on Time axis:   1 64
>> 
>> And then it just hangs here.....
>> 
>> 
>> Any assistance would be greatly appreciated, thanks so much!
>> Div
>> 
>> 
>> 
>> 
>> 
>> The information in this e-mail is intended only for the person to whom it
>> is
>> addressed. If you believe this e-mail was sent to you in error and the
>> e-mail
>> contains patient information, please contact the Partners Compliance
>> HelpLine at
>> http://www.partners.org/complianceline . If the e-mail was sent to you in
>> error
>> but does not contain patient information, please contact the sender and
>> properly
>> dispose of the e-mail.
>> _______________________________________________
>> 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 at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
> 
> 


From thomas.funck at mail.mcgill.ca  Mon Sep 12 17:42:14 2016
From: thomas.funck at mail.mcgill.ca (Thomas Funck, Mr)
Date: Mon, 12 Sep 2016 21:42:14 +0000
Subject: [MINC-users] Modify frame times in mincheader
Message-ID: <CY4PR03MB2421A729B480DEA348FBC5DFA6FF0@CY4PR03MB2421.namprd03.prod.outlook.com>

Hi,


I would like to modify the time frames for a MINC image, but am not sure how. At the moment, the frame times are:


mincheader pet.mnc | grep "time ="

time = 6 ;

time = 0, 1, 2, 3, 4, 5 ;



I tried several variations using minc_modify_header, but I wasn't able to overwrite the original time frames with the new ones I specified in the command line. For example:


minc_modify_header -sinsert data:time=2,4,6,8,10,12 pet.mnc


mincheader ADNI_0295_FDG_pet.mnc | grep "time ="
time = 6 ;
data:time = "2,4,6,8,10,12" ;
 time = 0, 1, 2, 3, 4, 5 ;


Any ideas on how to modify the frame time values in the header?

Thanks,

Thomas






From vladimir.fonov at gmail.com  Mon Sep 12 17:52:48 2016
From: vladimir.fonov at gmail.com (Vladimir S. FONOV)
Date: Mon, 12 Sep 2016 17:52:48 -0400
Subject: [MINC-users] Modify frame times in mincheader
In-Reply-To: <CY4PR03MB2421A729B480DEA348FBC5DFA6FF0@CY4PR03MB2421.namprd03.prod.outlook.com>
References: <CY4PR03MB2421A729B480DEA348FBC5DFA6FF0@CY4PR03MB2421.namprd03.prod.outlook.com>
Message-ID: <647de97c-4821-2f97-dcb6-3f80f703f1fa@gmail.com>

Hello,

I think the only possibility right now is to use mincedit. Because time 
is actually not an attribute, but rather a dataset.


On 2016-09-12 05:42 PM, Thomas Funck, Mr wrote:
> Hi,
>
>
> I would like to modify the time frames for a MINC image, but am not sure how. At the moment, the frame times are:
>
>
> mincheader pet.mnc | grep "time ="
>
> time = 6 ;
>
> time = 0, 1, 2, 3, 4, 5 ;
>
>
>
> I tried several variations using minc_modify_header, but I wasn't able to overwrite the original time frames with the new ones I specified in the command line. For example:
>
>
> minc_modify_header -sinsert data:time=2,4,6,8,10,12 pet.mnc
>
>
> mincheader ADNI_0295_FDG_pet.mnc | grep "time ="
> time = 6 ;
> data:time = "2,4,6,8,10,12" ;
>  time = 0, 1, 2, 3, 4, 5 ;
>
>
> Any ideas on how to modify the frame time values in the header?
>
> Thanks,
>
> Thomas
>
>
>
>
>
> _______________________________________________
> 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 robert.d.vincent at mcgill.ca  Mon Sep 12 20:59:15 2016
From: robert.d.vincent at mcgill.ca (Robert D. Vincent)
Date: Mon, 12 Sep 2016 20:59:15 -0400
Subject: [MINC-users] Modify frame times in mincheader
In-Reply-To: <647de97c-4821-2f97-dcb6-3f80f703f1fa@gmail.com>
References: <CY4PR03MB2421A729B480DEA348FBC5DFA6FF0@CY4PR03MB2421.namprd03.prod.outlook.com>
	<647de97c-4821-2f97-dcb6-3f80f703f1fa@gmail.com>
Message-ID: <CAAd5DeTHiNtVL-S43q51FTEN1id-1HOi39idqamO-G6JWA1vqA@mail.gmail.com>

Hi Thomas,

Vlad is correct. There is no minc command other than mincedit that allows
you to modify the contents of a dataset - and the acquisition times are
stored in a dataset.

If this is something you need to automate in a script, it would be pretty
easy to extend minc_modify_header to support this case.

    -bert

On Mon, Sep 12, 2016 at 5:52 PM, Vladimir S. FONOV <vladimir.fonov at gmail.com
> wrote:

> Hello,
>
> I think the only possibility right now is to use mincedit. Because time is
> actually not an attribute, but rather a dataset.
>
>
>
> On 2016-09-12 05:42 PM, Thomas Funck, Mr wrote:
>
>> Hi,
>>
>>
>> I would like to modify the time frames for a MINC image, but am not sure
>> how. At the moment, the frame times are:
>>
>>
>> mincheader pet.mnc | grep "time ="
>>
>> time = 6 ;
>>
>> time = 0, 1, 2, 3, 4, 5 ;
>>
>>
>>
>> I tried several variations using minc_modify_header, but I wasn't able to
>> overwrite the original time frames with the new ones I specified in the
>> command line. For example:
>>
>>
>> minc_modify_header -sinsert data:time=2,4,6,8,10,12 pet.mnc
>>
>>
>> mincheader ADNI_0295_FDG_pet.mnc | grep "time ="
>> time = 6 ;
>> data:time = "2,4,6,8,10,12" ;
>>  time = 0, 1, 2, 3, 4, 5 ;
>>
>>
>> Any ideas on how to modify the frame time values in the header?
>>
>> Thanks,
>>
>> Thomas
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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
>

From redoute at cermep.fr  Thu Sep 15 05:59:56 2016
From: redoute at cermep.fr (=?UTF-8?B?SsOpcsO0bWUgUmVkb3V0w6k=?=)
Date: Thu, 15 Sep 2016 11:59:56 +0200
Subject: [MINC-users] retrieve coregistration
Message-ID: <7a94de4b-83f7-616d-390e-dec99a271fcf@cermep.fr>

Hi all,

I need your help concerning a coregistration loss problem during image 
processing.

I have a mnc PET 4D volume that I need to process in ECAT format.

My processing steps are as follows:

DYN.mnc => ecat with minctoecat

ecat processing (imgratio) to generate a ratio image => ratio.v

convert back to minc using ecattominc => ratio.mnc

my problem is that ratio.mnc is not in alignment with DYN.mnc


How should I correct ratio.mnc header to bring this alignment back?

Thanks for your help

Jerome

-- 
==================================================================
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 18 (bureau)
tel : 33 (0)4 72 68 86 00 (standard)
fax : 33 (0)4 72 68 86 10
==================================================================



From robert.d.vincent at mcgill.ca  Thu Sep 15 06:23:24 2016
From: robert.d.vincent at mcgill.ca (Robert D. Vincent)
Date: Thu, 15 Sep 2016 06:23:24 -0400
Subject: [MINC-users] retrieve coregistration
In-Reply-To: <7a94de4b-83f7-616d-390e-dec99a271fcf@cermep.fr>
References: <7a94de4b-83f7-616d-390e-dec99a271fcf@cermep.fr>
Message-ID: <CAAd5DeSRdj1f8uyG9xh3oAGdGZ5GNzUNYXA2hwTaxNVi2CZ9Bw@mail.gmail.com>

Hi J?r?me,

I don't know the "imgratio" tool, is it possible it is changing or deleting
the voxel-to-world transform? What is the output of mincinfo on the two mnc
files?

If the basic sampling grid hasn't changed, you should be able to use
minc_modify_header to put the original voxel-to-world transform back into
the ratio.mnc header.

    -bert

On Thu, Sep 15, 2016 at 5:59 AM, J?r?me Redout? <redoute at cermep.fr> wrote:

> Hi all,
>
> I need your help concerning a coregistration loss problem during image
> processing.
>
> I have a mnc PET 4D volume that I need to process in ECAT format.
>
> My processing steps are as follows:
>
> DYN.mnc => ecat with minctoecat
>
> ecat processing (imgratio) to generate a ratio image => ratio.v
>
> convert back to minc using ecattominc => ratio.mnc
>
> my problem is that ratio.mnc is not in alignment with DYN.mnc
>
>
> How should I correct ratio.mnc header to bring this alignment back?
>
> Thanks for your help
>
> Jerome
>
> --
> ==================================================================
> 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 18 (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
>

From redoute at cermep.fr  Thu Sep 15 08:24:18 2016
From: redoute at cermep.fr (=?UTF-8?B?SsOpcsO0bWUgUmVkb3V0w6k=?=)
Date: Thu, 15 Sep 2016 14:24:18 +0200
Subject: [MINC-users] retrieve coregistration
In-Reply-To: <CAAd5DeSRdj1f8uyG9xh3oAGdGZ5GNzUNYXA2hwTaxNVi2CZ9Bw@mail.gmail.com>
References: <7a94de4b-83f7-616d-390e-dec99a271fcf@cermep.fr>
	<CAAd5DeSRdj1f8uyG9xh3oAGdGZ5GNzUNYXA2hwTaxNVi2CZ9Bw@mail.gmail.com>
Message-ID: <21be46e2-a5d0-dfda-71a9-9200e127c75c@cermep.fr>

Hi Robert,
here is the output of mincinfo

> file: CHAPO06620_F15_04_DYN_avg.mnc
> image: signed__ short -32768 to 32767
> image dimensions: xspace zspace yspace
>     dimension name         length         step        start
>     --------------         ------         ----        -----
>     xspace                    176          0.6        -52.8
>     zspace                    164    -0.601562         48.3
>     yspace                    208    -0.601562      63.8531
>
>
> file: ratio_original.mnc
> image: signed__ short -32000 to 32000
> image dimensions: zspace yspace xspace
>     dimension name         length         step        start
>     --------------         ------         ----        -----
>     zspace                    164    -0.601562           -0
>     yspace                    208     0.601562     -62.2617
>     xspace                    176          0.6        -52.5

PS: imgratio is a tool from Turku's PET center

Jerome



Le 15/09/2016 ? 12:23, Robert D. Vincent a ?crit :
> Hi J?r?me,
>
> I don't know the "imgratio" tool, is it possible it is changing or deleting
> the voxel-to-world transform? What is the output of mincinfo on the two mnc
> files?
>
> If the basic sampling grid hasn't changed, you should be able to use
> minc_modify_header to put the original voxel-to-world transform back into
> the ratio.mnc header.
>
>      -bert
>
> On Thu, Sep 15, 2016 at 5:59 AM, J?r?me Redout? <redoute at cermep.fr> wrote:
>
>> Hi all,
>>
>> I need your help concerning a coregistration loss problem during image
>> processing.
>>
>> I have a mnc PET 4D volume that I need to process in ECAT format.
>>
>> My processing steps are as follows:
>>
>> DYN.mnc => ecat with minctoecat
>>
>> ecat processing (imgratio) to generate a ratio image => ratio.v
>>
>> convert back to minc using ecattominc => ratio.mnc
>>
>> my problem is that ratio.mnc is not in alignment with DYN.mnc
>>
>>
>> How should I correct ratio.mnc header to bring this alignment back?
>>
>> Thanks for your help
>>
>> Jerome
>>
>> --
>> ==================================================================
>> 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 18 (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
>>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>


-- 
==================================================================
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 18 (bureau)
tel : 33 (0)4 72 68 86 00 (standard)
fax : 33 (0)4 72 68 86 10
==================================================================



From robert.d.vincent at mcgill.ca  Thu Sep 15 08:58:02 2016
From: robert.d.vincent at mcgill.ca (Robert D. Vincent)
Date: Thu, 15 Sep 2016 08:58:02 -0400
Subject: [MINC-users] retrieve coregistration
In-Reply-To: <21be46e2-a5d0-dfda-71a9-9200e127c75c@cermep.fr>
References: <7a94de4b-83f7-616d-390e-dec99a271fcf@cermep.fr>
	<CAAd5DeSRdj1f8uyG9xh3oAGdGZ5GNzUNYXA2hwTaxNVi2CZ9Bw@mail.gmail.com>
	<21be46e2-a5d0-dfda-71a9-9200e127c75c@cermep.fr>
Message-ID: <CAAd5DeSDQiYxjFVzmvHLGFhL6EqXU-NSq3v26GY3PkPAQhGaqw@mail.gmail.com>

Hi,

So the xspace and yspace values have changed slightly, but the zspace
origin has been changed dramatically.

If you do the following command:

minc_modify_header -dinsert zspace:start=48.3 ratio_original.mnc

Do the files line up correctly?



On Thu, Sep 15, 2016 at 8:24 AM, J?r?me Redout? <redoute at cermep.fr> wrote:

> Hi Robert,
> here is the output of mincinfo
>
> file: CHAPO06620_F15_04_DYN_avg.mnc
>> image: signed__ short -32768 to 32767
>> image dimensions: xspace zspace yspace
>>     dimension name         length         step        start
>>     --------------         ------         ----        -----
>>     xspace                    176          0.6        -52.8
>>     zspace                    164    -0.601562         48.3
>>     yspace                    208    -0.601562      63.8531
>>
>>
>> file: ratio_original.mnc
>> image: signed__ short -32000 to 32000
>> image dimensions: zspace yspace xspace
>>     dimension name         length         step        start
>>     --------------         ------         ----        -----
>>     zspace                    164    -0.601562           -0
>>     yspace                    208     0.601562     -62.2617
>>     xspace                    176          0.6        -52.5
>>
>
> PS: imgratio is a tool from Turku's PET center
>
> Jerome
>
>
>
>
> Le 15/09/2016 ? 12:23, Robert D. Vincent a ?crit :
>
>> Hi J?r?me,
>>
>> I don't know the "imgratio" tool, is it possible it is changing or
>> deleting
>> the voxel-to-world transform? What is the output of mincinfo on the two
>> mnc
>> files?
>>
>> If the basic sampling grid hasn't changed, you should be able to use
>> minc_modify_header to put the original voxel-to-world transform back into
>> the ratio.mnc header.
>>
>>      -bert
>>
>> On Thu, Sep 15, 2016 at 5:59 AM, J?r?me Redout? <redoute at cermep.fr>
>> wrote:
>>
>> Hi all,
>>>
>>> I need your help concerning a coregistration loss problem during image
>>> processing.
>>>
>>> I have a mnc PET 4D volume that I need to process in ECAT format.
>>>
>>> My processing steps are as follows:
>>>
>>> DYN.mnc => ecat with minctoecat
>>>
>>> ecat processing (imgratio) to generate a ratio image => ratio.v
>>>
>>> convert back to minc using ecattominc => ratio.mnc
>>>
>>> my problem is that ratio.mnc is not in alignment with DYN.mnc
>>>
>>>
>>> How should I correct ratio.mnc header to bring this alignment back?
>>>
>>> Thanks for your help
>>>
>>> Jerome
>>>
>>> --
>>> ==================================================================
>>> 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 18 (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
>>>
>>> _______________________________________________
>> MINC-users at bic.mni.mcgill.ca
>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>>
>>
>
> --
> ==================================================================
> 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 18 (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
>

From redoute at cermep.fr  Fri Sep 16 04:58:34 2016
From: redoute at cermep.fr (=?UTF-8?B?SsOpcsO0bWUgUmVkb3V0w6k=?=)
Date: Fri, 16 Sep 2016 10:58:34 +0200
Subject: [MINC-users] retrieve coregistration
In-Reply-To: <CAAd5DeSDQiYxjFVzmvHLGFhL6EqXU-NSq3v26GY3PkPAQhGaqw@mail.gmail.com>
References: <7a94de4b-83f7-616d-390e-dec99a271fcf@cermep.fr>
	<CAAd5DeSRdj1f8uyG9xh3oAGdGZ5GNzUNYXA2hwTaxNVi2CZ9Bw@mail.gmail.com>
	<21be46e2-a5d0-dfda-71a9-9200e127c75c@cermep.fr>
	<CAAd5DeSDQiYxjFVzmvHLGFhL6EqXU-NSq3v26GY3PkPAQhGaqw@mail.gmail.com>
Message-ID: <5d73f7b2-7e8b-3da3-fd61-922b5b395b61@cermep.fr>

Hi,
modifying zstart effectively corrects z mismatch
unfortunately, x and y do not align files correctly and I keep a small 
mismatch
Here is an example of dataset:
https://dl.univ-lyon1.fr/iulbw8zre0
Thanks
Jerome


Le 15/09/2016 ? 14:58, Robert D. Vincent a ?crit :
> Hi,
>
> So the xspace and yspace values have changed slightly, but the zspace
> origin has been changed dramatically.
>
> If you do the following command:
>
> minc_modify_header -dinsert zspace:start=48.3 ratio_original.mnc
>
> Do the files line up correctly?
>
>
>
> On Thu, Sep 15, 2016 at 8:24 AM, J?r?me Redout? <redoute at cermep.fr> wrote:
>
>> Hi Robert,
>> here is the output of mincinfo
>>
>> file: CHAPO06620_F15_04_DYN_avg.mnc
>>> image: signed__ short -32768 to 32767
>>> image dimensions: xspace zspace yspace
>>>      dimension name         length         step        start
>>>      --------------         ------         ----        -----
>>>      xspace                    176          0.6        -52.8
>>>      zspace                    164    -0.601562         48.3
>>>      yspace                    208    -0.601562      63.8531
>>>
>>>
>>> file: ratio_original.mnc
>>> image: signed__ short -32000 to 32000
>>> image dimensions: zspace yspace xspace
>>>      dimension name         length         step        start
>>>      --------------         ------         ----        -----
>>>      zspace                    164    -0.601562           -0
>>>      yspace                    208     0.601562     -62.2617
>>>      xspace                    176          0.6        -52.5
>>>
>> PS: imgratio is a tool from Turku's PET center
>>
>> Jerome
>>
>>
>>
>>
>> Le 15/09/2016 ? 12:23, Robert D. Vincent a ?crit :
>>
>>> Hi J?r?me,
>>>
>>> I don't know the "imgratio" tool, is it possible it is changing or
>>> deleting
>>> the voxel-to-world transform? What is the output of mincinfo on the two
>>> mnc
>>> files?
>>>
>>> If the basic sampling grid hasn't changed, you should be able to use
>>> minc_modify_header to put the original voxel-to-world transform back into
>>> the ratio.mnc header.
>>>
>>>       -bert
>>>
>>> On Thu, Sep 15, 2016 at 5:59 AM, J?r?me Redout? <redoute at cermep.fr>
>>> wrote:
>>>
>>> Hi all,
>>>> I need your help concerning a coregistration loss problem during image
>>>> processing.
>>>>
>>>> I have a mnc PET 4D volume that I need to process in ECAT format.
>>>>
>>>> My processing steps are as follows:
>>>>
>>>> DYN.mnc => ecat with minctoecat
>>>>
>>>> ecat processing (imgratio) to generate a ratio image => ratio.v
>>>>
>>>> convert back to minc using ecattominc => ratio.mnc
>>>>
>>>> my problem is that ratio.mnc is not in alignment with DYN.mnc
>>>>
>>>>
>>>> How should I correct ratio.mnc header to bring this alignment back?
>>>>
>>>> Thanks for your help
>>>>
>>>> Jerome
>>>>
>>>> --
>>>> ==================================================================
>>>> 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 18 (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
>>>>
>>>> _______________________________________________
>>> MINC-users at bic.mni.mcgill.ca
>>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>>>
>>>
>> --
>> ==================================================================
>> 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 18 (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
>>
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>


-- 
==================================================================
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 18 (bureau)
tel : 33 (0)4 72 68 86 00 (standard)
fax : 33 (0)4 72 68 86 10
==================================================================



From robert.d.vincent at mcgill.ca  Tue Sep 20 11:37:13 2016
From: robert.d.vincent at mcgill.ca (Robert D. Vincent)
Date: Tue, 20 Sep 2016 11:37:13 -0400
Subject: [MINC-users] retrieve coregistration
In-Reply-To: <5d73f7b2-7e8b-3da3-fd61-922b5b395b61@cermep.fr>
References: <7a94de4b-83f7-616d-390e-dec99a271fcf@cermep.fr>
	<CAAd5DeSRdj1f8uyG9xh3oAGdGZ5GNzUNYXA2hwTaxNVi2CZ9Bw@mail.gmail.com>
	<21be46e2-a5d0-dfda-71a9-9200e127c75c@cermep.fr>
	<CAAd5DeSDQiYxjFVzmvHLGFhL6EqXU-NSq3v26GY3PkPAQhGaqw@mail.gmail.com>
	<5d73f7b2-7e8b-3da3-fd61-922b5b395b61@cermep.fr>
Message-ID: <CAAd5DeSS90cnx-4EqXwyZw1MqzTyqskHEvC7_3u1oAVeoZM_Aw@mail.gmail.com>

Hi J?r?me,

Thank you for the files. So I tried just converting your original file to
ecat using minctoecat, and then converting it back with ecat to minc:

minctoecat CHAPO06620_F15_04_DYN_avg.mnc test.v
ecattominc test.v test.mnc

The resulting test.mnc has reordered dimensions, but the two MINC volumes
align properly. So it does seem as though there is an issue with the
imgratio tool, it is somehow changing the voxel-to-world transform in an
unexpected way.

I wrote a little Python 3 script that fixes this - it's enclosed (and
poorly tested at this point, so be careful).

Here's a link to the ratio file with the corrected transform:

https://www.dropbox.com/s/nwe7r2cqaik97vw/ratio_fixed.mnc?dl=0

The corrected file looks fairly good when overlaid on the original in
Display, so hopefully imgratio isn't changing the underlying sampling of
the data, but rather it is only failing to properly preserve the transform.

    -bert


On Fri, Sep 16, 2016 at 4:58 AM, J?r?me Redout? <redoute at cermep.fr> wrote:

> Hi,
> modifying zstart effectively corrects z mismatch
> unfortunately, x and y do not align files correctly and I keep a small
> mismatch
> Here is an example of dataset:
> https://dl.univ-lyon1.fr/iulbw8zre0
> Thanks
> Jerome
>
>
>
> Le 15/09/2016 ? 14:58, Robert D. Vincent a ?crit :
>
>> Hi,
>>
>> So the xspace and yspace values have changed slightly, but the zspace
>> origin has been changed dramatically.
>>
>> If you do the following command:
>>
>> minc_modify_header -dinsert zspace:start=48.3 ratio_original.mnc
>>
>> Do the files line up correctly?
>>
>>
>>
>> On Thu, Sep 15, 2016 at 8:24 AM, J?r?me Redout? <redoute at cermep.fr>
>> wrote:
>>
>> Hi Robert,
>>> here is the output of mincinfo
>>>
>>> file: CHAPO06620_F15_04_DYN_avg.mnc
>>>
>>>> image: signed__ short -32768 to 32767
>>>> image dimensions: xspace zspace yspace
>>>>      dimension name         length         step        start
>>>>      --------------         ------         ----        -----
>>>>      xspace                    176          0.6        -52.8
>>>>      zspace                    164    -0.601562         48.3
>>>>      yspace                    208    -0.601562      63.8531
>>>>
>>>>
>>>> file: ratio_original.mnc
>>>> image: signed__ short -32000 to 32000
>>>> image dimensions: zspace yspace xspace
>>>>      dimension name         length         step        start
>>>>      --------------         ------         ----        -----
>>>>      zspace                    164    -0.601562           -0
>>>>      yspace                    208     0.601562     -62.2617
>>>>      xspace                    176          0.6        -52.5
>>>>
>>>> PS: imgratio is a tool from Turku's PET center
>>>
>>> Jerome
>>>
>>>
>>>
>>>
>>> Le 15/09/2016 ? 12:23, Robert D. Vincent a ?crit :
>>>
>>> Hi J?r?me,
>>>>
>>>> I don't know the "imgratio" tool, is it possible it is changing or
>>>> deleting
>>>> the voxel-to-world transform? What is the output of mincinfo on the two
>>>> mnc
>>>> files?
>>>>
>>>> If the basic sampling grid hasn't changed, you should be able to use
>>>> minc_modify_header to put the original voxel-to-world transform back
>>>> into
>>>> the ratio.mnc header.
>>>>
>>>>       -bert
>>>>
>>>> On Thu, Sep 15, 2016 at 5:59 AM, J?r?me Redout? <redoute at cermep.fr>
>>>> wrote:
>>>>
>>>> Hi all,
>>>>
>>>>> I need your help concerning a coregistration loss problem during image
>>>>> processing.
>>>>>
>>>>> I have a mnc PET 4D volume that I need to process in ECAT format.
>>>>>
>>>>> My processing steps are as follows:
>>>>>
>>>>> DYN.mnc => ecat with minctoecat
>>>>>
>>>>> ecat processing (imgratio) to generate a ratio image => ratio.v
>>>>>
>>>>> convert back to minc using ecattominc => ratio.mnc
>>>>>
>>>>> my problem is that ratio.mnc is not in alignment with DYN.mnc
>>>>>
>>>>>
>>>>> How should I correct ratio.mnc header to bring this alignment back?
>>>>>
>>>>> Thanks for your help
>>>>>
>>>>> Jerome
>>>>>
>>>>> --
>>>>> ==================================================================
>>>>> 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 18 (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
>>>>>
>>>>> _______________________________________________
>>>>>
>>>> MINC-users at bic.mni.mcgill.ca
>>>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>>>>
>>>>
>>>> --
>>> ==================================================================
>>> 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 18 (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
>>>
>>> _______________________________________________
>> MINC-users at bic.mni.mcgill.ca
>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>>
>>
>
> --
> ==================================================================
> 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 18 (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
>

From redoute at cermep.fr  Wed Sep 21 05:14:45 2016
From: redoute at cermep.fr (=?UTF-8?B?SsOpcsO0bWUgUmVkb3V0w6k=?=)
Date: Wed, 21 Sep 2016 11:14:45 +0200
Subject: [MINC-users] retrieve coregistration
In-Reply-To: <CAAd5DeSS90cnx-4EqXwyZw1MqzTyqskHEvC7_3u1oAVeoZM_Aw@mail.gmail.com>
References: <7a94de4b-83f7-616d-390e-dec99a271fcf@cermep.fr>
	<CAAd5DeSRdj1f8uyG9xh3oAGdGZ5GNzUNYXA2hwTaxNVi2CZ9Bw@mail.gmail.com>
	<21be46e2-a5d0-dfda-71a9-9200e127c75c@cermep.fr>
	<CAAd5DeSDQiYxjFVzmvHLGFhL6EqXU-NSq3v26GY3PkPAQhGaqw@mail.gmail.com>
	<5d73f7b2-7e8b-3da3-fd61-922b5b395b61@cermep.fr>
	<CAAd5DeSS90cnx-4EqXwyZw1MqzTyqskHEvC7_3u1oAVeoZM_Aw@mail.gmail.com>
Message-ID: <b503cebf-8aba-5945-c581-b6a5f43c4334@cermep.fr>

Thank you Robert!
just can't finfd you python scipt ;)
Best
Jerome

Le 20/09/2016 ? 17:37, Robert D. Vincent a ?crit :
> Hi J?r?me,
>
> Thank you for the files. So I tried just converting your original file to
> ecat using minctoecat, and then converting it back with ecat to minc:
>
> minctoecat CHAPO06620_F15_04_DYN_avg.mnc test.v
> ecattominc test.v test.mnc
>
> The resulting test.mnc has reordered dimensions, but the two MINC volumes
> align properly. So it does seem as though there is an issue with the
> imgratio tool, it is somehow changing the voxel-to-world transform in an
> unexpected way.
>
> I wrote a little Python 3 script that fixes this - it's enclosed (and
> poorly tested at this point, so be careful).
>
> Here's a link to the ratio file with the corrected transform:
>
> https://www.dropbox.com/s/nwe7r2cqaik97vw/ratio_fixed.mnc?dl=0
>
> The corrected file looks fairly good when overlaid on the original in
> Display, so hopefully imgratio isn't changing the underlying sampling of
> the data, but rather it is only failing to properly preserve the transform.
>
>      -bert
>
>
> On Fri, Sep 16, 2016 at 4:58 AM, J?r?me Redout? <redoute at cermep.fr> wrote:
>
>> Hi,
>> modifying zstart effectively corrects z mismatch
>> unfortunately, x and y do not align files correctly and I keep a small
>> mismatch
>> Here is an example of dataset:
>> https://dl.univ-lyon1.fr/iulbw8zre0
>> Thanks
>> Jerome
>>
>>
>>
>> Le 15/09/2016 ? 14:58, Robert D. Vincent a ?crit :
>>
>>> Hi,
>>>
>>> So the xspace and yspace values have changed slightly, but the zspace
>>> origin has been changed dramatically.
>>>
>>> If you do the following command:
>>>
>>> minc_modify_header -dinsert zspace:start=48.3 ratio_original.mnc
>>>
>>> Do the files line up correctly?
>>>
>>>
>>>
>>> On Thu, Sep 15, 2016 at 8:24 AM, J?r?me Redout? <redoute at cermep.fr>
>>> wrote:
>>>
>>> Hi Robert,
>>>> here is the output of mincinfo
>>>>
>>>> file: CHAPO06620_F15_04_DYN_avg.mnc
>>>>
>>>>> image: signed__ short -32768 to 32767
>>>>> image dimensions: xspace zspace yspace
>>>>>       dimension name         length         step        start
>>>>>       --------------         ------         ----        -----
>>>>>       xspace                    176          0.6        -52.8
>>>>>       zspace                    164    -0.601562         48.3
>>>>>       yspace                    208    -0.601562      63.8531
>>>>>
>>>>>
>>>>> file: ratio_original.mnc
>>>>> image: signed__ short -32000 to 32000
>>>>> image dimensions: zspace yspace xspace
>>>>>       dimension name         length         step        start
>>>>>       --------------         ------         ----        -----
>>>>>       zspace                    164    -0.601562           -0
>>>>>       yspace                    208     0.601562     -62.2617
>>>>>       xspace                    176          0.6        -52.5
>>>>>
>>>>> PS: imgratio is a tool from Turku's PET center
>>>> Jerome
>>>>
>>>>
>>>>
>>>>
>>>> Le 15/09/2016 ? 12:23, Robert D. Vincent a ?crit :
>>>>
>>>> Hi J?r?me,
>>>>> I don't know the "imgratio" tool, is it possible it is changing or
>>>>> deleting
>>>>> the voxel-to-world transform? What is the output of mincinfo on the two
>>>>> mnc
>>>>> files?
>>>>>
>>>>> If the basic sampling grid hasn't changed, you should be able to use
>>>>> minc_modify_header to put the original voxel-to-world transform back
>>>>> into
>>>>> the ratio.mnc header.
>>>>>
>>>>>        -bert
>>>>>
>>>>> On Thu, Sep 15, 2016 at 5:59 AM, J?r?me Redout? <redoute at cermep.fr>
>>>>> wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>>> I need your help concerning a coregistration loss problem during image
>>>>>> processing.
>>>>>>
>>>>>> I have a mnc PET 4D volume that I need to process in ECAT format.
>>>>>>
>>>>>> My processing steps are as follows:
>>>>>>
>>>>>> DYN.mnc => ecat with minctoecat
>>>>>>
>>>>>> ecat processing (imgratio) to generate a ratio image => ratio.v
>>>>>>
>>>>>> convert back to minc using ecattominc => ratio.mnc
>>>>>>
>>>>>> my problem is that ratio.mnc is not in alignment with DYN.mnc
>>>>>>
>>>>>>
>>>>>> How should I correct ratio.mnc header to bring this alignment back?
>>>>>>
>>>>>> Thanks for your help
>>>>>>
>>>>>> Jerome
>>>>>>
>>>>>> --
>>>>>> ==================================================================
>>>>>> 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 18 (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
>>>>>>
>>>>>> _______________________________________________
>>>>>>
>>>>> MINC-users at bic.mni.mcgill.ca
>>>>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>>>>>
>>>>>
>>>>> --
>>>> ==================================================================
>>>> 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 18 (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
>>>>
>>>> _______________________________________________
>>> MINC-users at bic.mni.mcgill.ca
>>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>>>
>>>
>> --
>> ==================================================================
>> 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 18 (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
>>
>>
>>
>> _______________________________________________
>> MINC-users at bic.mni.mcgill.ca
>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users


-- 
==================================================================
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 18 (bureau)
tel : 33 (0)4 72 68 86 00 (standard)
fax : 33 (0)4 72 68 86 10
==================================================================


From robert.d.vincent at mcgill.ca  Wed Sep 21 07:19:26 2016
From: robert.d.vincent at mcgill.ca (Robert D. Vincent)
Date: Wed, 21 Sep 2016 07:19:26 -0400
Subject: [MINC-users] retrieve coregistration
In-Reply-To: <b503cebf-8aba-5945-c581-b6a5f43c4334@cermep.fr>
References: <7a94de4b-83f7-616d-390e-dec99a271fcf@cermep.fr>
	<CAAd5DeSRdj1f8uyG9xh3oAGdGZ5GNzUNYXA2hwTaxNVi2CZ9Bw@mail.gmail.com>
	<21be46e2-a5d0-dfda-71a9-9200e127c75c@cermep.fr>
	<CAAd5DeSDQiYxjFVzmvHLGFhL6EqXU-NSq3v26GY3PkPAQhGaqw@mail.gmail.com>
	<5d73f7b2-7e8b-3da3-fd61-922b5b395b61@cermep.fr>
	<CAAd5DeSS90cnx-4EqXwyZw1MqzTyqskHEvC7_3u1oAVeoZM_Aw@mail.gmail.com>
	<b503cebf-8aba-5945-c581-b6a5f43c4334@cermep.fr>
Message-ID: <CAAd5DeR9E+xfMOKhyixB7hsbF5TFrxK-T69zV-f5UaqabDV+LA@mail.gmail.com>

Hi,

It was enclosed in the email... Here it is again (I am cc'ing you directly
in case the mailing list software filtered out the enclosure).

    -bert


On Wed, Sep 21, 2016 at 5:14 AM, J?r?me Redout? <redoute at cermep.fr> wrote:

> Thank you Robert!
> just can't finfd you python scipt ;)
> Best
> Jerome
>
>
> Le 20/09/2016 ? 17:37, Robert D. Vincent a ?crit :
>
>> Hi J?r?me,
>>
>> Thank you for the files. So I tried just converting your original file to
>> ecat using minctoecat, and then converting it back with ecat to minc:
>>
>> minctoecat CHAPO06620_F15_04_DYN_avg.mnc test.v
>> ecattominc test.v test.mnc
>>
>> The resulting test.mnc has reordered dimensions, but the two MINC volumes
>> align properly. So it does seem as though there is an issue with the
>> imgratio tool, it is somehow changing the voxel-to-world transform in an
>> unexpected way.
>>
>> I wrote a little Python 3 script that fixes this - it's enclosed (and
>> poorly tested at this point, so be careful).
>>
>> Here's a link to the ratio file with the corrected transform:
>>
>> https://www.dropbox.com/s/nwe7r2cqaik97vw/ratio_fixed.mnc?dl=0
>>
>> The corrected file looks fairly good when overlaid on the original in
>> Display, so hopefully imgratio isn't changing the underlying sampling of
>> the data, but rather it is only failing to properly preserve the
>> transform.
>>
>>      -bert
>>
>>
>> On Fri, Sep 16, 2016 at 4:58 AM, J?r?me Redout? <redoute at cermep.fr>
>> wrote:
>>
>> Hi,
>>> modifying zstart effectively corrects z mismatch
>>> unfortunately, x and y do not align files correctly and I keep a small
>>> mismatch
>>> Here is an example of dataset:
>>> https://dl.univ-lyon1.fr/iulbw8zre0
>>> Thanks
>>> Jerome
>>>
>>>
>>>
>>> Le 15/09/2016 ? 14:58, Robert D. Vincent a ?crit :
>>>
>>> Hi,
>>>>
>>>> So the xspace and yspace values have changed slightly, but the zspace
>>>> origin has been changed dramatically.
>>>>
>>>> If you do the following command:
>>>>
>>>> minc_modify_header -dinsert zspace:start=48.3 ratio_original.mnc
>>>>
>>>> Do the files line up correctly?
>>>>
>>>>
>>>>
>>>> On Thu, Sep 15, 2016 at 8:24 AM, J?r?me Redout? <redoute at cermep.fr>
>>>> wrote:
>>>>
>>>> Hi Robert,
>>>>
>>>>> here is the output of mincinfo
>>>>>
>>>>> file: CHAPO06620_F15_04_DYN_avg.mnc
>>>>>
>>>>> image: signed__ short -32768 to 32767
>>>>>> image dimensions: xspace zspace yspace
>>>>>>       dimension name         length         step        start
>>>>>>       --------------         ------         ----        -----
>>>>>>       xspace                    176          0.6        -52.8
>>>>>>       zspace                    164    -0.601562         48.3
>>>>>>       yspace                    208    -0.601562      63.8531
>>>>>>
>>>>>>
>>>>>> file: ratio_original.mnc
>>>>>> image: signed__ short -32000 to 32000
>>>>>> image dimensions: zspace yspace xspace
>>>>>>       dimension name         length         step        start
>>>>>>       --------------         ------         ----        -----
>>>>>>       zspace                    164    -0.601562           -0
>>>>>>       yspace                    208     0.601562     -62.2617
>>>>>>       xspace                    176          0.6        -52.5
>>>>>>
>>>>>> PS: imgratio is a tool from Turku's PET center
>>>>>>
>>>>> Jerome
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Le 15/09/2016 ? 12:23, Robert D. Vincent a ?crit :
>>>>>
>>>>> Hi J?r?me,
>>>>>
>>>>>> I don't know the "imgratio" tool, is it possible it is changing or
>>>>>> deleting
>>>>>> the voxel-to-world transform? What is the output of mincinfo on the
>>>>>> two
>>>>>> mnc
>>>>>> files?
>>>>>>
>>>>>> If the basic sampling grid hasn't changed, you should be able to use
>>>>>> minc_modify_header to put the original voxel-to-world transform back
>>>>>> into
>>>>>> the ratio.mnc header.
>>>>>>
>>>>>>        -bert
>>>>>>
>>>>>> On Thu, Sep 15, 2016 at 5:59 AM, J?r?me Redout? <redoute at cermep.fr>
>>>>>> wrote:
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I need your help concerning a coregistration loss problem during image
>>>>>>> processing.
>>>>>>>
>>>>>>> I have a mnc PET 4D volume that I need to process in ECAT format.
>>>>>>>
>>>>>>> My processing steps are as follows:
>>>>>>>
>>>>>>> DYN.mnc => ecat with minctoecat
>>>>>>>
>>>>>>> ecat processing (imgratio) to generate a ratio image => ratio.v
>>>>>>>
>>>>>>> convert back to minc using ecattominc => ratio.mnc
>>>>>>>
>>>>>>> my problem is that ratio.mnc is not in alignment with DYN.mnc
>>>>>>>
>>>>>>>
>>>>>>> How should I correct ratio.mnc header to bring this alignment back?
>>>>>>>
>>>>>>> Thanks for your help
>>>>>>>
>>>>>>> Jerome
>>>>>>>
>>>>>>> --
>>>>>>> ==================================================================
>>>>>>> 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 18 (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
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>>
>>>>>>> MINC-users at bic.mni.mcgill.ca
>>>>>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>> ==================================================================
>>>>> 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 18 (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
>>>>>
>>>>> _______________________________________________
>>>>>
>>>> MINC-users at bic.mni.mcgill.ca
>>>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>>>>
>>>>
>>>> --
>>> ==================================================================
>>> 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 18 (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
>>>
>>>
>>>
>>> _______________________________________________
>>> MINC-users at bic.mni.mcgill.ca
>>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>>>
>>
>
> --
> ==================================================================
> 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 18 (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
>

From mishkind at gmail.com  Sun Sep 25 04:13:45 2016
From: mishkind at gmail.com (Mishkin Derakhshan)
Date: Sat, 24 Sep 2016 22:13:45 -1000
Subject: [MINC-users] [minctracc] segfault when using -measure option
Message-ID: <CAB-GmL0i_fQzjftNWuhVbUm780JAVtCQ5ShCrai_nKaqfTYcZw@mail.gmail.com>

Hi,
I get a segfault whenever I try to use the -measure option.
Here is the simplest example to reproduce the bug.

$ minctracc -measure out.txt t1p.mnc.gz t1p.mnc.gz -transformation
identity.xfm

I'm using:
$ minctracc -version
The program <minctracc> was built from:
mni_autoreg 0.99.60

Here is some info on the files, but I don't think it has to do with the
files themselves as I've tried 100s. Maybe someone else can confirm.
$ mincinfo t1p.mnc.gz
file: t1p.mnc.gz
image: signed__ short 0 to 4095
image dimensions: zspace yspace xspace
    dimension name         length         step        start
    --------------         ------         ----        -----
    zspace                     60            3     -93.0427
    yspace                    256    -0.976562      119.239
    xspace                    192    -0.976562      91.5716

$ cat identity.xfm
MNI Transform File
%Sun Sep 25 03:59:15 2016>>> param2xfm -scale 1 1 1 identity.xfm
%(mni_autoreg 0.99.60)

Transform_Type = Linear;
Linear_Transform =
 1 0 0 0
 0 1 0 0
 0 0 1 0;

Looking at the print statements in the debug output from minctracc, and
comparing with minctracc/Main/measure_code.c I have a rough idea where the
segfault must be happening, but it's a little outside my depth at this
point.

Bug happens somewhere in here:
                            /* do var_ratio */

    main_args.obj_function = vr_objective;
    obj_func_val = measure_fit( data, model, mask_data, mask_model,
&main_args );
    (void)fprintf (ofd, "%f - var_ratio\n",obj_func_val);
    (void)fflush(ofd);
    DEBUG_PRINT1 ( "%f - var_ratio\n",obj_func_val);

    delete_volume(data);
    delete_volume(model);

                                /* do ssc / zero-crossings */

    status = input_volume( main_args.filenames.data, 3, default_dim_names,
                          NC_UNSPECIFIED, FALSE, 0.0, 0.0,
                          TRUE, &data, (minc_input_options *)NULL );
    status = input_volume( main_args.filenames.model, 3, default_dim_names,
                          NC_UNSPECIFIED, FALSE, 0.0, 0.0,
                          TRUE, &model, (minc_input_options *)NULL );

    main_args.obj_function = ssc_objective;
    obj_func_val = measure_fit( data, model, mask_data, mask_model,
&main_args );
    (void)fprintf (ofd, "%f - ssc\n",obj_func_val);
    (void)fflush(ofd);
    DEBUG_PRINT1 ( "%f - ssc\n",obj_func_val);


The good news is that the out.txt measure file still gets output, albeit
incomplete, but so does a large core file. Not to mention I can't sleep at
night having a seg fault that is built into the pipeline, er, at least one
that that I know about!

any help?
mishkin

Here is the debugging output from minctracc if that helps:

$ minctracc -measure out.txt t1p.mnc.gz t1p.mnc.gz -transformation
identity.xfm -debug
===== Debugging information from minctracc =====
Data filename       = t1p.mnc.gz
Model filename      = t1p.mnc.gz
Data mask filename  =
Model mask filename =
Input xform name    = identity.xfm
Measure filename    = out.txt

Step size           = 4.000000 4.000000 4.000000
Sub-lattice dia     = 24.000000 24.000000 24.000000
Objective function  = cross correlation (threshold = 0.000000 0.000000)
Transform linear    = TRUE
Transform inverted? = FALSE
Transform type      = 4
Transform matrix    =    1.0000    0.0000    0.0000    0.0000
                         0.0000    1.0000    0.0000    0.0000
                         0.0000    0.0000    1.0000    0.0000
Transform center   =    0.000    0.000    0.000
Transform rotation   =    0.000    0.000    0.000

Transform trans    =    0.000    0.000    0.000
Transform scale    =    1.000    1.000    1.000

Source volume size:  60  by 256  by 192
Source voxel size =    3.000   -0.977   -0.977
Source min/max real range =    0.000 2083.000
Source min/max voxel=    0.000 2083.000

Target volume size:  60  by 256  by 192
Target voxel =    3.000   -0.977   -0.977
Target min/max real range=    0.000 2083.000
Target min/max voxel =    0.000 2083.000


  using input transformation to get initial parameters:
   Center of rot/scale not forced, will be set to : 0.000000 0.000000
0.000000
In set_up_lattice, xyzv[axes] = 2, 1, 0, -1
slice lim 0 44
row lim   1 62
col lim   1 46
thresh =    0.00000    0.00000
In set_up_lattice, xyzv[axes] = 2, 1, 0, -1
Source volume is smallest
Lattice step size  =   -4.000   -4.000    4.000
Lattice start      =   88.104  129.917  -72.203
Lattice count      =       46       62       45

 128340  128340  128340 ->        inf
inf - zscore
 128340  128340 -> 0.00000000
0.000000 - xcorr
 128340  128340       0 -> 0.20877945
0.208779 - var_ratio
Segmentation fault

From robert.d.vincent at mcgill.ca  Sun Sep 25 07:28:57 2016
From: robert.d.vincent at mcgill.ca (Robert D. Vincent)
Date: Sun, 25 Sep 2016 07:28:57 -0400
Subject: [MINC-users] [minctracc] segfault when using -measure option
In-Reply-To: <CAB-GmL0i_fQzjftNWuhVbUm780JAVtCQ5ShCrai_nKaqfTYcZw@mail.gmail.com>
References: <CAB-GmL0i_fQzjftNWuhVbUm780JAVtCQ5ShCrai_nKaqfTYcZw@mail.gmail.com>
Message-ID: <CAAd5DeT3DJokFHu6moN5Xn9SPUH9pijjR9q2XrNkGeJiWZuenQ@mail.gmail.com>

Thanks for the example, I'll look into it.


On Sun, Sep 25, 2016 at 4:13 AM, Mishkin Derakhshan <mishkind at gmail.com>
wrote:

> Hi,
> I get a segfault whenever I try to use the -measure option.
> Here is the simplest example to reproduce the bug.
>
> $ minctracc -measure out.txt t1p.mnc.gz t1p.mnc.gz -transformation
> identity.xfm
>
> I'm using:
> $ minctracc -version
> The program <minctracc> was built from:
> mni_autoreg 0.99.60
>
> Here is some info on the files, but I don't think it has to do with the
> files themselves as I've tried 100s. Maybe someone else can confirm.
> $ mincinfo t1p.mnc.gz
> file: t1p.mnc.gz
> image: signed__ short 0 to 4095
> image dimensions: zspace yspace xspace
>     dimension name         length         step        start
>     --------------         ------         ----        -----
>     zspace                     60            3     -93.0427
>     yspace                    256    -0.976562      119.239
>     xspace                    192    -0.976562      91.5716
>
> $ cat identity.xfm
> MNI Transform File
> %Sun Sep 25 03:59:15 2016>>> param2xfm -scale 1 1 1 identity.xfm
> %(mni_autoreg 0.99.60)
>
> Transform_Type = Linear;
> Linear_Transform =
>  1 0 0 0
>  0 1 0 0
>  0 0 1 0;
>
> Looking at the print statements in the debug output from minctracc, and
> comparing with minctracc/Main/measure_code.c I have a rough idea where the
> segfault must be happening, but it's a little outside my depth at this
> point.
>
> Bug happens somewhere in here:
>                             /* do var_ratio */
>
>     main_args.obj_function = vr_objective;
>     obj_func_val = measure_fit( data, model, mask_data, mask_model,
> &main_args );
>     (void)fprintf (ofd, "%f - var_ratio\n",obj_func_val);
>     (void)fflush(ofd);
>     DEBUG_PRINT1 ( "%f - var_ratio\n",obj_func_val);
>
>     delete_volume(data);
>     delete_volume(model);
>
>                                 /* do ssc / zero-crossings */
>
>     status = input_volume( main_args.filenames.data, 3, default_dim_names,
>                           NC_UNSPECIFIED, FALSE, 0.0, 0.0,
>                           TRUE, &data, (minc_input_options *)NULL );
>     status = input_volume( main_args.filenames.model, 3, default_dim_names,
>                           NC_UNSPECIFIED, FALSE, 0.0, 0.0,
>                           TRUE, &model, (minc_input_options *)NULL );
>
>     main_args.obj_function = ssc_objective;
>     obj_func_val = measure_fit( data, model, mask_data, mask_model,
> &main_args );
>     (void)fprintf (ofd, "%f - ssc\n",obj_func_val);
>     (void)fflush(ofd);
>     DEBUG_PRINT1 ( "%f - ssc\n",obj_func_val);
>
>
> The good news is that the out.txt measure file still gets output, albeit
> incomplete, but so does a large core file. Not to mention I can't sleep at
> night having a seg fault that is built into the pipeline, er, at least one
> that that I know about!
>
> any help?
> mishkin
>
> Here is the debugging output from minctracc if that helps:
>
> $ minctracc -measure out.txt t1p.mnc.gz t1p.mnc.gz -transformation
> identity.xfm -debug
> ===== Debugging information from minctracc =====
> Data filename       = t1p.mnc.gz
> Model filename      = t1p.mnc.gz
> Data mask filename  =
> Model mask filename =
> Input xform name    = identity.xfm
> Measure filename    = out.txt
>
> Step size           = 4.000000 4.000000 4.000000
> Sub-lattice dia     = 24.000000 24.000000 24.000000
> Objective function  = cross correlation (threshold = 0.000000 0.000000)
> Transform linear    = TRUE
> Transform inverted? = FALSE
> Transform type      = 4
> Transform matrix    =    1.0000    0.0000    0.0000    0.0000
>                          0.0000    1.0000    0.0000    0.0000
>                          0.0000    0.0000    1.0000    0.0000
> Transform center   =    0.000    0.000    0.000
> Transform rotation   =    0.000    0.000    0.000
>
> Transform trans    =    0.000    0.000    0.000
> Transform scale    =    1.000    1.000    1.000
>
> Source volume size:  60  by 256  by 192
> Source voxel size =    3.000   -0.977   -0.977
> Source min/max real range =    0.000 2083.000
> Source min/max voxel=    0.000 2083.000
>
> Target volume size:  60  by 256  by 192
> Target voxel =    3.000   -0.977   -0.977
> Target min/max real range=    0.000 2083.000
> Target min/max voxel =    0.000 2083.000
>
>
>   using input transformation to get initial parameters:
>    Center of rot/scale not forced, will be set to : 0.000000 0.000000
> 0.000000
> In set_up_lattice, xyzv[axes] = 2, 1, 0, -1
> slice lim 0 44
> row lim   1 62
> col lim   1 46
> thresh =    0.00000    0.00000
> In set_up_lattice, xyzv[axes] = 2, 1, 0, -1
> Source volume is smallest
> Lattice step size  =   -4.000   -4.000    4.000
> Lattice start      =   88.104  129.917  -72.203
> Lattice count      =       46       62       45
>
>  128340  128340  128340 ->        inf
> inf - zscore
>  128340  128340 -> 0.00000000
> 0.000000 - xcorr
>  128340  128340       0 -> 0.20877945
> 0.208779 - var_ratio
> Segmentation fault
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From robert.d.vincent at mcgill.ca  Sun Sep 25 09:01:50 2016
From: robert.d.vincent at mcgill.ca (Robert D. Vincent)
Date: Sun, 25 Sep 2016 09:01:50 -0400
Subject: [MINC-users] [minctracc] segfault when using -measure option
In-Reply-To: <CAAd5DeT3DJokFHu6moN5Xn9SPUH9pijjR9q2XrNkGeJiWZuenQ@mail.gmail.com>
References: <CAB-GmL0i_fQzjftNWuhVbUm780JAVtCQ5ShCrai_nKaqfTYcZw@mail.gmail.com>
	<CAAd5DeT3DJokFHu6moN5Xn9SPUH9pijjR9q2XrNkGeJiWZuenQ@mail.gmail.com>
Message-ID: <CAAd5DeSkwfcuCJ5db5cNsQMxsz3cC3PhuCCHXQ3VKfc_y_gomA@mail.gmail.com>

Hi again,

So I have a couple of clues about the possible problem. It appears that
minctracc can misbehave for some files with negative steps. Can you try the
following with your example:

mincreshape -valid_range 0 4095 +xdirection +ydirection +zdirection t1p.mnc
t1c.mnc

and re-run minctracc with t1c.mnc instead of t1p.mnc. Let me know if this
still produces a segfault. It seems to fix it for me.

    -bert

On Sun, Sep 25, 2016 at 7:28 AM, Robert D. Vincent <
robert.d.vincent at mcgill.ca> wrote:

> Thanks for the example, I'll look into it.
>
>
> On Sun, Sep 25, 2016 at 4:13 AM, Mishkin Derakhshan <mishkind at gmail.com>
> wrote:
>
>> Hi,
>> I get a segfault whenever I try to use the -measure option.
>> Here is the simplest example to reproduce the bug.
>>
>> $ minctracc -measure out.txt t1p.mnc.gz t1p.mnc.gz -transformation
>> identity.xfm
>>
>> I'm using:
>> $ minctracc -version
>> The program <minctracc> was built from:
>> mni_autoreg 0.99.60
>>
>> Here is some info on the files, but I don't think it has to do with the
>> files themselves as I've tried 100s. Maybe someone else can confirm.
>> $ mincinfo t1p.mnc.gz
>> file: t1p.mnc.gz
>> image: signed__ short 0 to 4095
>> image dimensions: zspace yspace xspace
>>     dimension name         length         step        start
>>     --------------         ------         ----        -----
>>     zspace                     60            3     -93.0427
>>     yspace                    256    -0.976562      119.239
>>     xspace                    192    -0.976562      91.5716
>>
>> $ cat identity.xfm
>> MNI Transform File
>> %Sun Sep 25 03:59:15 2016>>> param2xfm -scale 1 1 1 identity.xfm
>> %(mni_autoreg 0.99.60)
>>
>> Transform_Type = Linear;
>> Linear_Transform =
>>  1 0 0 0
>>  0 1 0 0
>>  0 0 1 0;
>>
>> Looking at the print statements in the debug output from minctracc, and
>> comparing with minctracc/Main/measure_code.c I have a rough idea where the
>> segfault must be happening, but it's a little outside my depth at this
>> point.
>>
>> Bug happens somewhere in here:
>>                             /* do var_ratio */
>>
>>     main_args.obj_function = vr_objective;
>>     obj_func_val = measure_fit( data, model, mask_data, mask_model,
>> &main_args );
>>     (void)fprintf (ofd, "%f - var_ratio\n",obj_func_val);
>>     (void)fflush(ofd);
>>     DEBUG_PRINT1 ( "%f - var_ratio\n",obj_func_val);
>>
>>     delete_volume(data);
>>     delete_volume(model);
>>
>>                                 /* do ssc / zero-crossings */
>>
>>     status = input_volume( main_args.filenames.data, 3, default_dim_names,
>>                           NC_UNSPECIFIED, FALSE, 0.0, 0.0,
>>                           TRUE, &data, (minc_input_options *)NULL );
>>     status = input_volume( main_args.filenames.model, 3,
>> default_dim_names,
>>                           NC_UNSPECIFIED, FALSE, 0.0, 0.0,
>>                           TRUE, &model, (minc_input_options *)NULL );
>>
>>     main_args.obj_function = ssc_objective;
>>     obj_func_val = measure_fit( data, model, mask_data, mask_model,
>> &main_args );
>>     (void)fprintf (ofd, "%f - ssc\n",obj_func_val);
>>     (void)fflush(ofd);
>>     DEBUG_PRINT1 ( "%f - ssc\n",obj_func_val);
>>
>>
>> The good news is that the out.txt measure file still gets output, albeit
>> incomplete, but so does a large core file. Not to mention I can't sleep at
>> night having a seg fault that is built into the pipeline, er, at least one
>> that that I know about!
>>
>> any help?
>> mishkin
>>
>> Here is the debugging output from minctracc if that helps:
>>
>> $ minctracc -measure out.txt t1p.mnc.gz t1p.mnc.gz -transformation
>> identity.xfm -debug
>> ===== Debugging information from minctracc =====
>> Data filename       = t1p.mnc.gz
>> Model filename      = t1p.mnc.gz
>> Data mask filename  =
>> Model mask filename =
>> Input xform name    = identity.xfm
>> Measure filename    = out.txt
>>
>> Step size           = 4.000000 4.000000 4.000000
>> Sub-lattice dia     = 24.000000 24.000000 24.000000
>> Objective function  = cross correlation (threshold = 0.000000 0.000000)
>> Transform linear    = TRUE
>> Transform inverted? = FALSE
>> Transform type      = 4
>> Transform matrix    =    1.0000    0.0000    0.0000    0.0000
>>                          0.0000    1.0000    0.0000    0.0000
>>                          0.0000    0.0000    1.0000    0.0000
>> Transform center   =    0.000    0.000    0.000
>> Transform rotation   =    0.000    0.000    0.000
>>
>> Transform trans    =    0.000    0.000    0.000
>> Transform scale    =    1.000    1.000    1.000
>>
>> Source volume size:  60  by 256  by 192
>> Source voxel size =    3.000   -0.977   -0.977
>> Source min/max real range =    0.000 2083.000
>> Source min/max voxel=    0.000 2083.000
>>
>> Target volume size:  60  by 256  by 192
>> Target voxel =    3.000   -0.977   -0.977
>> Target min/max real range=    0.000 2083.000
>> Target min/max voxel =    0.000 2083.000
>>
>>
>>   using input transformation to get initial parameters:
>>    Center of rot/scale not forced, will be set to : 0.000000 0.000000
>> 0.000000
>> In set_up_lattice, xyzv[axes] = 2, 1, 0, -1
>> slice lim 0 44
>> row lim   1 62
>> col lim   1 46
>> thresh =    0.00000    0.00000
>> In set_up_lattice, xyzv[axes] = 2, 1, 0, -1
>> Source volume is smallest
>> Lattice step size  =   -4.000   -4.000    4.000
>> Lattice start      =   88.104  129.917  -72.203
>> Lattice count      =       46       62       45
>>
>>  128340  128340  128340 ->        inf
>> inf - zscore
>>  128340  128340 -> 0.00000000
>> 0.000000 - xcorr
>>  128340  128340       0 -> 0.20877945
>> 0.208779 - var_ratio
>> Segmentation fault
>> _______________________________________________
>> MINC-users at bic.mni.mcgill.ca
>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>>
>
>

From mishkind at gmail.com  Sun Sep 25 19:13:48 2016
From: mishkind at gmail.com (Mishkin Derakhshan)
Date: Sun, 25 Sep 2016 13:13:48 -1000
Subject: [MINC-users] [minctracc] segfault when using -measure option
In-Reply-To: <CAAd5DeSkwfcuCJ5db5cNsQMxsz3cC3PhuCCHXQ3VKfc_y_gomA@mail.gmail.com>
References: <CAB-GmL0i_fQzjftNWuhVbUm780JAVtCQ5ShCrai_nKaqfTYcZw@mail.gmail.com>
	<CAAd5DeT3DJokFHu6moN5Xn9SPUH9pijjR9q2XrNkGeJiWZuenQ@mail.gmail.com>
	<CAAd5DeSkwfcuCJ5db5cNsQMxsz3cC3PhuCCHXQ3VKfc_y_gomA@mail.gmail.com>
Message-ID: <CAB-GmL3ThRGLUxoKC4S-EGOoH8Km0=i-GsZ9rfyLLZ-3VeT1ug@mail.gmail.com>

That fixed it!
many thanks.

I'm assuming though that the original xfm calculated with the -ve steps
would not be appropriate to use for the newly reshaped files. Is there a
tool or a simple way to fix the original xfms so I don't need to calculate
them from scratch again on the +ve direction files?

On Sun, Sep 25, 2016 at 3:01 AM, Robert D. Vincent <
robert.d.vincent at mcgill.ca> wrote:

> Hi again,
>
> So I have a couple of clues about the possible problem. It appears that
> minctracc can misbehave for some files with negative steps. Can you try the
> following with your example:
>
> mincreshape -valid_range 0 4095 +xdirection +ydirection +zdirection t1p.mnc
> t1c.mnc
>
> and re-run minctracc with t1c.mnc instead of t1p.mnc. Let me know if this
> still produces a segfault. It seems to fix it for me.
>
>     -bert
>
> On Sun, Sep 25, 2016 at 7:28 AM, Robert D. Vincent <
> robert.d.vincent at mcgill.ca> wrote:
>
> > Thanks for the example, I'll look into it.
> >
> >
> > On Sun, Sep 25, 2016 at 4:13 AM, Mishkin Derakhshan <mishkind at gmail.com>
> > wrote:
> >
> >> Hi,
> >> I get a segfault whenever I try to use the -measure option.
> >> Here is the simplest example to reproduce the bug.
> >>
> >> $ minctracc -measure out.txt t1p.mnc.gz t1p.mnc.gz -transformation
> >> identity.xfm
> >>
> >> I'm using:
> >> $ minctracc -version
> >> The program <minctracc> was built from:
> >> mni_autoreg 0.99.60
> >>
> >> Here is some info on the files, but I don't think it has to do with the
> >> files themselves as I've tried 100s. Maybe someone else can confirm.
> >> $ mincinfo t1p.mnc.gz
> >> file: t1p.mnc.gz
> >> image: signed__ short 0 to 4095
> >> image dimensions: zspace yspace xspace
> >>     dimension name         length         step        start
> >>     --------------         ------         ----        -----
> >>     zspace                     60            3     -93.0427
> >>     yspace                    256    -0.976562      119.239
> >>     xspace                    192    -0.976562      91.5716
> >>
> >> $ cat identity.xfm
> >> MNI Transform File
> >> %Sun Sep 25 03:59:15 2016>>> param2xfm -scale 1 1 1 identity.xfm
> >> %(mni_autoreg 0.99.60)
> >>
> >> Transform_Type = Linear;
> >> Linear_Transform =
> >>  1 0 0 0
> >>  0 1 0 0
> >>  0 0 1 0;
> >>
> >> Looking at the print statements in the debug output from minctracc, and
> >> comparing with minctracc/Main/measure_code.c I have a rough idea where
> the
> >> segfault must be happening, but it's a little outside my depth at this
> >> point.
> >>
> >> Bug happens somewhere in here:
> >>                             /* do var_ratio */
> >>
> >>     main_args.obj_function = vr_objective;
> >>     obj_func_val = measure_fit( data, model, mask_data, mask_model,
> >> &main_args );
> >>     (void)fprintf (ofd, "%f - var_ratio\n",obj_func_val);
> >>     (void)fflush(ofd);
> >>     DEBUG_PRINT1 ( "%f - var_ratio\n",obj_func_val);
> >>
> >>     delete_volume(data);
> >>     delete_volume(model);
> >>
> >>                                 /* do ssc / zero-crossings */
> >>
> >>     status = input_volume( main_args.filenames.data, 3,
> default_dim_names,
> >>                           NC_UNSPECIFIED, FALSE, 0.0, 0.0,
> >>                           TRUE, &data, (minc_input_options *)NULL );
> >>     status = input_volume( main_args.filenames.model, 3,
> >> default_dim_names,
> >>                           NC_UNSPECIFIED, FALSE, 0.0, 0.0,
> >>                           TRUE, &model, (minc_input_options *)NULL );
> >>
> >>     main_args.obj_function = ssc_objective;
> >>     obj_func_val = measure_fit( data, model, mask_data, mask_model,
> >> &main_args );
> >>     (void)fprintf (ofd, "%f - ssc\n",obj_func_val);
> >>     (void)fflush(ofd);
> >>     DEBUG_PRINT1 ( "%f - ssc\n",obj_func_val);
> >>
> >>
> >> The good news is that the out.txt measure file still gets output, albeit
> >> incomplete, but so does a large core file. Not to mention I can't sleep
> at
> >> night having a seg fault that is built into the pipeline, er, at least
> one
> >> that that I know about!
> >>
> >> any help?
> >> mishkin
> >>
> >> Here is the debugging output from minctracc if that helps:
> >>
> >> $ minctracc -measure out.txt t1p.mnc.gz t1p.mnc.gz -transformation
> >> identity.xfm -debug
> >> ===== Debugging information from minctracc =====
> >> Data filename       = t1p.mnc.gz
> >> Model filename      = t1p.mnc.gz
> >> Data mask filename  =
> >> Model mask filename =
> >> Input xform name    = identity.xfm
> >> Measure filename    = out.txt
> >>
> >> Step size           = 4.000000 4.000000 4.000000
> >> Sub-lattice dia     = 24.000000 24.000000 24.000000
> >> Objective function  = cross correlation (threshold = 0.000000 0.000000)
> >> Transform linear    = TRUE
> >> Transform inverted? = FALSE
> >> Transform type      = 4
> >> Transform matrix    =    1.0000    0.0000    0.0000    0.0000
> >>                          0.0000    1.0000    0.0000    0.0000
> >>                          0.0000    0.0000    1.0000    0.0000
> >> Transform center   =    0.000    0.000    0.000
> >> Transform rotation   =    0.000    0.000    0.000
> >>
> >> Transform trans    =    0.000    0.000    0.000
> >> Transform scale    =    1.000    1.000    1.000
> >>
> >> Source volume size:  60  by 256  by 192
> >> Source voxel size =    3.000   -0.977   -0.977
> >> Source min/max real range =    0.000 2083.000
> >> Source min/max voxel=    0.000 2083.000
> >>
> >> Target volume size:  60  by 256  by 192
> >> Target voxel =    3.000   -0.977   -0.977
> >> Target min/max real range=    0.000 2083.000
> >> Target min/max voxel =    0.000 2083.000
> >>
> >>
> >>   using input transformation to get initial parameters:
> >>    Center of rot/scale not forced, will be set to : 0.000000 0.000000
> >> 0.000000
> >> In set_up_lattice, xyzv[axes] = 2, 1, 0, -1
> >> slice lim 0 44
> >> row lim   1 62
> >> col lim   1 46
> >> thresh =    0.00000    0.00000
> >> In set_up_lattice, xyzv[axes] = 2, 1, 0, -1
> >> Source volume is smallest
> >> Lattice step size  =   -4.000   -4.000    4.000
> >> Lattice start      =   88.104  129.917  -72.203
> >> Lattice count      =       46       62       45
> >>
> >>  128340  128340  128340 ->        inf
> >> inf - zscore
> >>  128340  128340 -> 0.00000000
> >> 0.000000 - xcorr
> >>  128340  128340       0 -> 0.20877945
> >> 0.208779 - var_ratio
> >> Segmentation fault
> >> _______________________________________________
> >> 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 robert.d.vincent at mcgill.ca  Sun Sep 25 20:44:47 2016
From: robert.d.vincent at mcgill.ca (Robert D. Vincent)
Date: Sun, 25 Sep 2016 20:44:47 -0400
Subject: [MINC-users] [minctracc] segfault when using -measure option
In-Reply-To: <CAB-GmL3ThRGLUxoKC4S-EGOoH8Km0=i-GsZ9rfyLLZ-3VeT1ug@mail.gmail.com>
References: <CAB-GmL0i_fQzjftNWuhVbUm780JAVtCQ5ShCrai_nKaqfTYcZw@mail.gmail.com>
	<CAAd5DeT3DJokFHu6moN5Xn9SPUH9pijjR9q2XrNkGeJiWZuenQ@mail.gmail.com>
	<CAAd5DeSkwfcuCJ5db5cNsQMxsz3cC3PhuCCHXQ3VKfc_y_gomA@mail.gmail.com>
	<CAB-GmL3ThRGLUxoKC4S-EGOoH8Km0=i-GsZ9rfyLLZ-3VeT1ug@mail.gmail.com>
Message-ID: <CAAd5DeQOyT8cAto8LYSqf_NspF2+EvyGYFk4-h9sQLhb1n4hKQ@mail.gmail.com>

Hi Mishkin,

The beauty of this is that I don't think you should have to recalculate
your transforms. The transforms express an operation in world coordinates.
The world coordinates of the files remains the same after reshaping, it's
only the relationship between the voxel space and the world space that is
changing.

I'm not completely expert with minctracc, so I hope someone else on this
list will correct me if I'm wrong.

    -bert

On Sun, Sep 25, 2016 at 7:13 PM, Mishkin Derakhshan <mishkind at gmail.com>
wrote:

> That fixed it!
> many thanks.
>
> I'm assuming though that the original xfm calculated with the -ve steps
> would not be appropriate to use for the newly reshaped files. Is there a
> tool or a simple way to fix the original xfms so I don't need to calculate
> them from scratch again on the +ve direction files?
>
> On Sun, Sep 25, 2016 at 3:01 AM, Robert D. Vincent <
> robert.d.vincent at mcgill.ca> wrote:
>
> > Hi again,
> >
> > So I have a couple of clues about the possible problem. It appears that
> > minctracc can misbehave for some files with negative steps. Can you try
> the
> > following with your example:
> >
> > mincreshape -valid_range 0 4095 +xdirection +ydirection +zdirection
> t1p.mnc
> > t1c.mnc
> >
> > and re-run minctracc with t1c.mnc instead of t1p.mnc. Let me know if this
> > still produces a segfault. It seems to fix it for me.
> >
> >     -bert
> >
> > On Sun, Sep 25, 2016 at 7:28 AM, Robert D. Vincent <
> > robert.d.vincent at mcgill.ca> wrote:
> >
> > > Thanks for the example, I'll look into it.
> > >
> > >
> > > On Sun, Sep 25, 2016 at 4:13 AM, Mishkin Derakhshan <
> mishkind at gmail.com>
> > > wrote:
> > >
> > >> Hi,
> > >> I get a segfault whenever I try to use the -measure option.
> > >> Here is the simplest example to reproduce the bug.
> > >>
> > >> $ minctracc -measure out.txt t1p.mnc.gz t1p.mnc.gz -transformation
> > >> identity.xfm
> > >>
> > >> I'm using:
> > >> $ minctracc -version
> > >> The program <minctracc> was built from:
> > >> mni_autoreg 0.99.60
> > >>
> > >> Here is some info on the files, but I don't think it has to do with
> the
> > >> files themselves as I've tried 100s. Maybe someone else can confirm.
> > >> $ mincinfo t1p.mnc.gz
> > >> file: t1p.mnc.gz
> > >> image: signed__ short 0 to 4095
> > >> image dimensions: zspace yspace xspace
> > >>     dimension name         length         step        start
> > >>     --------------         ------         ----        -----
> > >>     zspace                     60            3     -93.0427
> > >>     yspace                    256    -0.976562      119.239
> > >>     xspace                    192    -0.976562      91.5716
> > >>
> > >> $ cat identity.xfm
> > >> MNI Transform File
> > >> %Sun Sep 25 03:59:15 2016>>> param2xfm -scale 1 1 1 identity.xfm
> > >> %(mni_autoreg 0.99.60)
> > >>
> > >> Transform_Type = Linear;
> > >> Linear_Transform =
> > >>  1 0 0 0
> > >>  0 1 0 0
> > >>  0 0 1 0;
> > >>
> > >> Looking at the print statements in the debug output from minctracc,
> and
> > >> comparing with minctracc/Main/measure_code.c I have a rough idea where
> > the
> > >> segfault must be happening, but it's a little outside my depth at this
> > >> point.
> > >>
> > >> Bug happens somewhere in here:
> > >>                             /* do var_ratio */
> > >>
> > >>     main_args.obj_function = vr_objective;
> > >>     obj_func_val = measure_fit( data, model, mask_data, mask_model,
> > >> &main_args );
> > >>     (void)fprintf (ofd, "%f - var_ratio\n",obj_func_val);
> > >>     (void)fflush(ofd);
> > >>     DEBUG_PRINT1 ( "%f - var_ratio\n",obj_func_val);
> > >>
> > >>     delete_volume(data);
> > >>     delete_volume(model);
> > >>
> > >>                                 /* do ssc / zero-crossings */
> > >>
> > >>     status = input_volume( main_args.filenames.data, 3,
> > default_dim_names,
> > >>                           NC_UNSPECIFIED, FALSE, 0.0, 0.0,
> > >>                           TRUE, &data, (minc_input_options *)NULL );
> > >>     status = input_volume( main_args.filenames.model, 3,
> > >> default_dim_names,
> > >>                           NC_UNSPECIFIED, FALSE, 0.0, 0.0,
> > >>                           TRUE, &model, (minc_input_options *)NULL );
> > >>
> > >>     main_args.obj_function = ssc_objective;
> > >>     obj_func_val = measure_fit( data, model, mask_data, mask_model,
> > >> &main_args );
> > >>     (void)fprintf (ofd, "%f - ssc\n",obj_func_val);
> > >>     (void)fflush(ofd);
> > >>     DEBUG_PRINT1 ( "%f - ssc\n",obj_func_val);
> > >>
> > >>
> > >> The good news is that the out.txt measure file still gets output,
> albeit
> > >> incomplete, but so does a large core file. Not to mention I can't
> sleep
> > at
> > >> night having a seg fault that is built into the pipeline, er, at least
> > one
> > >> that that I know about!
> > >>
> > >> any help?
> > >> mishkin
> > >>
> > >> Here is the debugging output from minctracc if that helps:
> > >>
> > >> $ minctracc -measure out.txt t1p.mnc.gz t1p.mnc.gz -transformation
> > >> identity.xfm -debug
> > >> ===== Debugging information from minctracc =====
> > >> Data filename       = t1p.mnc.gz
> > >> Model filename      = t1p.mnc.gz
> > >> Data mask filename  =
> > >> Model mask filename =
> > >> Input xform name    = identity.xfm
> > >> Measure filename    = out.txt
> > >>
> > >> Step size           = 4.000000 4.000000 4.000000
> > >> Sub-lattice dia     = 24.000000 24.000000 24.000000
> > >> Objective function  = cross correlation (threshold = 0.000000
> 0.000000)
> > >> Transform linear    = TRUE
> > >> Transform inverted? = FALSE
> > >> Transform type      = 4
> > >> Transform matrix    =    1.0000    0.0000    0.0000    0.0000
> > >>                          0.0000    1.0000    0.0000    0.0000
> > >>                          0.0000    0.0000    1.0000    0.0000
> > >> Transform center   =    0.000    0.000    0.000
> > >> Transform rotation   =    0.000    0.000    0.000
> > >>
> > >> Transform trans    =    0.000    0.000    0.000
> > >> Transform scale    =    1.000    1.000    1.000
> > >>
> > >> Source volume size:  60  by 256  by 192
> > >> Source voxel size =    3.000   -0.977   -0.977
> > >> Source min/max real range =    0.000 2083.000
> > >> Source min/max voxel=    0.000 2083.000
> > >>
> > >> Target volume size:  60  by 256  by 192
> > >> Target voxel =    3.000   -0.977   -0.977
> > >> Target min/max real range=    0.000 2083.000
> > >> Target min/max voxel =    0.000 2083.000
> > >>
> > >>
> > >>   using input transformation to get initial parameters:
> > >>    Center of rot/scale not forced, will be set to : 0.000000 0.000000
> > >> 0.000000
> > >> In set_up_lattice, xyzv[axes] = 2, 1, 0, -1
> > >> slice lim 0 44
> > >> row lim   1 62
> > >> col lim   1 46
> > >> thresh =    0.00000    0.00000
> > >> In set_up_lattice, xyzv[axes] = 2, 1, 0, -1
> > >> Source volume is smallest
> > >> Lattice step size  =   -4.000   -4.000    4.000
> > >> Lattice start      =   88.104  129.917  -72.203
> > >> Lattice count      =       46       62       45
> > >>
> > >>  128340  128340  128340 ->        inf
> > >> inf - zscore
> > >>  128340  128340 -> 0.00000000
> > >> 0.000000 - xcorr
> > >>  128340  128340       0 -> 0.20877945
> > >> 0.208779 - var_ratio
> > >> Segmentation fault
> > >> _______________________________________________
> > >> 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
> >
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From gabriel.devenyi at mcgill.ca  Thu Sep 29 13:45:32 2016
From: gabriel.devenyi at mcgill.ca (Gabriel A. Devenyi)
Date: Thu, 29 Sep 2016 13:45:32 -0400
Subject: [MINC-users] Mapping surface (verstats) data into volume space
Message-ID: <CAFQOoOr7q72xmD+gRy4obK_W709NnZybU386g8TFFfr_FFvuCg@mail.gmail.com>

Hi all,

I?m wondering if anyone knows of a method to map verstats data (data on a
MNI object) into volume space.

I know I can convert an object into a volume representation with
scan_object_to_volume. I?d like to then assign values to those voxels from
a verstats file.

Thanks!

?
Gabriel A. Devenyi B.Eng. Ph.D.
Research Computing Associate
Computational Brain Anatomy Laboratory
Cerebral Imaging Center
Douglas Mental Health University Institute
McGill University
t: 514.761.6131x4781
e: gabriel.devenyi at mcgill.ca
?

From mishkind at gmail.com  Thu Sep 29 15:23:31 2016
From: mishkind at gmail.com (Mishkin Derakhshan)
Date: Thu, 29 Sep 2016 09:23:31 -1000
Subject: [MINC-users] Mapping surface (verstats) data into volume space
In-Reply-To: <CAFQOoOr7q72xmD+gRy4obK_W709NnZybU386g8TFFfr_FFvuCg@mail.gmail.com>
References: <CAFQOoOr7q72xmD+gRy4obK_W709NnZybU386g8TFFfr_FFvuCg@mail.gmail.com>
Message-ID: <CAB-GmL0aZLiD-4RrdBjtPo37UcrK9gR+ZoXbT7c6GM51-K5jrA@mail.gmail.com>

Have you tried making a colored object and then scanning it to volume?

Most .obj files default to having just one color per object, and for good
reason, this lets you overlay different vertstats data and the like on the
same object. But you can also create a .obj file where the color is stored
per vertex. The program to do this is colour_object and should come with
the default minc installation.

With some luck, scan_object_to_volume will not ignore the colored data.
worth a shot anyway.

Here is some reference material for .obj files:
http://www.bic.mni.mcgill.ca/Services/HowToWorkWithObjectFiles

In particular you can see how things are colored here:
http://www.bic.mni.mcgill.ca/users/david/FAQ/polygons_format.txt


On Thu, Sep 29, 2016 at 7:45 AM, Gabriel A. Devenyi <
gabriel.devenyi at mcgill.ca> wrote:

> Hi all,
>
> I?m wondering if anyone knows of a method to map verstats data (data on a
> MNI object) into volume space.
>
> I know I can convert an object into a volume representation with
> scan_object_to_volume. I?d like to then assign values to those voxels from
> a verstats file.
>
> Thanks!
>
> ?
> Gabriel A. Devenyi B.Eng. Ph.D.
> Research Computing Associate
> Computational Brain Anatomy Laboratory
> Cerebral Imaging Center
> Douglas Mental Health University Institute
> McGill University
> t: 514.761.6131x4781
> e: gabriel.devenyi at mcgill.ca
> ?
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From gabriel.devenyi at mcgill.ca  Thu Sep 29 15:27:48 2016
From: gabriel.devenyi at mcgill.ca (Gabriel A. Devenyi)
Date: Thu, 29 Sep 2016 15:27:48 -0400
Subject: [MINC-users] Mapping surface (verstats) data into volume space
In-Reply-To: <CAB-GmL0aZLiD-4RrdBjtPo37UcrK9gR+ZoXbT7c6GM51-K5jrA@mail.gmail.com>
References: <CAFQOoOr7q72xmD+gRy4obK_W709NnZybU386g8TFFfr_FFvuCg@mail.gmail.com>
	<CAB-GmL0aZLiD-4RrdBjtPo37UcrK9gR+ZoXbT7c6GM51-K5jrA@mail.gmail.com>
Message-ID: <CAFQOoOoP=fYE0FEOUd_fcQfdTmQgeC0X9spzV-=4cPjMN8Jz-w@mail.gmail.com>

Thanks!

I did indeed try after another reply off-list, sadly, scan_object_to_volume
seems to ignore colours.

--
Gabriel A. Devenyi B.Eng. Ph.D.
Research Computing Associate
Computational Brain Anatomy Laboratory
Cerebral Imaging Center
Douglas Mental Health University Institute
McGill University
t: 514.761.6131x4781
e: gabriel.devenyi at mcgill.ca

On Thu, Sep 29, 2016 at 3:23 PM, Mishkin Derakhshan <mishkind at gmail.com>
wrote:

> Have you tried making a colored object and then scanning it to volume?
>
> Most .obj files default to having just one color per object, and for good
> reason, this lets you overlay different vertstats data and the like on the
> same object. But you can also create a .obj file where the color is stored
> per vertex. The program to do this is colour_object and should come with
> the default minc installation.
>
> With some luck, scan_object_to_volume will not ignore the colored data.
> worth a shot anyway.
>
> Here is some reference material for .obj files:
> http://www.bic.mni.mcgill.ca/Services/HowToWorkWithObjectFiles
>
> In particular you can see how things are colored here:
> http://www.bic.mni.mcgill.ca/users/david/FAQ/polygons_format.txt
>
>
> On Thu, Sep 29, 2016 at 7:45 AM, Gabriel A. Devenyi <
> gabriel.devenyi at mcgill.ca> wrote:
>
> > Hi all,
> >
> > I?m wondering if anyone knows of a method to map verstats data (data on a
> > MNI object) into volume space.
> >
> > I know I can convert an object into a volume representation with
> > scan_object_to_volume. I?d like to then assign values to those voxels
> from
> > a verstats file.
> >
> > Thanks!
> >
> > ?
> > Gabriel A. Devenyi B.Eng. Ph.D.
> > Research Computing Associate
> > Computational Brain Anatomy Laboratory
> > Cerebral Imaging Center
> > Douglas Mental Health University Institute
> > McGill University
> > t: 514.761.6131x4781
> > e: gabriel.devenyi at mcgill.ca
> > ?
> > _______________________________________________
> > 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 robert.d.vincent at mcgill.ca  Thu Sep 29 15:31:34 2016
From: robert.d.vincent at mcgill.ca (Robert D. Vincent)
Date: Thu, 29 Sep 2016 15:31:34 -0400
Subject: [MINC-users] Mapping surface (verstats) data into volume space
In-Reply-To: <30148_1475177378_57ED6BA2_30148_205_4_CAFQOoOoP=fYE0FEOUd_fcQfdTmQgeC0X9spzV-=4cPjMN8Jz-w@mail.gmail.com>
References: <CAFQOoOr7q72xmD+gRy4obK_W709NnZybU386g8TFFfr_FFvuCg@mail.gmail.com>
	<CAB-GmL0aZLiD-4RrdBjtPo37UcrK9gR+ZoXbT7c6GM51-K5jrA@mail.gmail.com>
	<30148_1475177378_57ED6BA2_30148_205_4_CAFQOoOoP=fYE0FEOUd_fcQfdTmQgeC0X9spzV-=4cPjMN8Jz-w@mail.gmail.com>
Message-ID: <CAAd5DeSZxyRTyTfa1EUP0jV8E4K5TE01u1y0rtQgX=fk+hiHiA@mail.gmail.com>

Hi Gabriel,

I don't know of a way to do it, but it would be easy to create. I'll look
into it if nobody else comes up with a good suggestion.

    -bert


On Thu, Sep 29, 2016 at 3:27 PM, Gabriel A. Devenyi <
gabriel.devenyi at mcgill.ca> wrote:

> Thanks!
>
> I did indeed try after another reply off-list, sadly, scan_object_to_volume
> seems to ignore colours.
>
> --
> Gabriel A. Devenyi B.Eng. Ph.D.
> Research Computing Associate
> Computational Brain Anatomy Laboratory
> Cerebral Imaging Center
> Douglas Mental Health University Institute
> McGill University
> t: 514.761.6131x4781
> e: gabriel.devenyi at mcgill.ca
>
> On Thu, Sep 29, 2016 at 3:23 PM, Mishkin Derakhshan <mishkind at gmail.com>
> wrote:
>
> > Have you tried making a colored object and then scanning it to volume?
> >
> > Most .obj files default to having just one color per object, and for good
> > reason, this lets you overlay different vertstats data and the like on
> the
> > same object. But you can also create a .obj file where the color is
> stored
> > per vertex. The program to do this is colour_object and should come with
> > the default minc installation.
> >
> > With some luck, scan_object_to_volume will not ignore the colored data.
> > worth a shot anyway.
> >
> > Here is some reference material for .obj files:
> > http://www.bic.mni.mcgill.ca/Services/HowToWorkWithObjectFiles
> >
> > In particular you can see how things are colored here:
> > http://www.bic.mni.mcgill.ca/users/david/FAQ/polygons_format.txt
> >
> >
> > On Thu, Sep 29, 2016 at 7:45 AM, Gabriel A. Devenyi <
> > gabriel.devenyi at mcgill.ca> wrote:
> >
> > > Hi all,
> > >
> > > I?m wondering if anyone knows of a method to map verstats data (data
> on a
> > > MNI object) into volume space.
> > >
> > > I know I can convert an object into a volume representation with
> > > scan_object_to_volume. I?d like to then assign values to those voxels
> > from
> > > a verstats file.
> > >
> > > Thanks!
> > >
> > > ?
> > > Gabriel A. Devenyi B.Eng. Ph.D.
> > > Research Computing Associate
> > > Computational Brain Anatomy Laboratory
> > > Cerebral Imaging Center
> > > Douglas Mental Health University Institute
> > > McGill University
> > > t: 514.761.6131x4781
> > > e: gabriel.devenyi at mcgill.ca
> > > ?
> > > _______________________________________________
> > > 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
> >
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From gdevenyi at gmail.com  Thu Sep 29 15:45:36 2016
From: gdevenyi at gmail.com (Gabriel A. Devenyi)
Date: Thu, 29 Sep 2016 15:45:36 -0400
Subject: [MINC-users] Mapping surface (verstats) data into volume space
In-Reply-To: <CAAd5DeSZxyRTyTfa1EUP0jV8E4K5TE01u1y0rtQgX=fk+hiHiA@mail.gmail.com>
References: <CAFQOoOr7q72xmD+gRy4obK_W709NnZybU386g8TFFfr_FFvuCg@mail.gmail.com>
	<CAB-GmL0aZLiD-4RrdBjtPo37UcrK9gR+ZoXbT7c6GM51-K5jrA@mail.gmail.com>
	<30148_1475177378_57ED6BA2_30148_205_4_CAFQOoOoP=fYE0FEOUd_fcQfdTmQgeC0X9spzV-=4cPjMN8Jz-w@mail.gmail.com>
	<CAAd5DeSZxyRTyTfa1EUP0jV8E4K5TE01u1y0rtQgX=fk+hiHiA@mail.gmail.com>
Message-ID: <CAFQOoOqor5i3NoQf-b40greKiKGodkH19UE-gPr+_bojR-sWow@mail.gmail.com>

If scan_object_to_volume could honour colour (optionally), that would
probably work well. Thanks bert!

--
Gabriel A. Devenyi B.Eng. Ph.D.
Research Computing Associate
Computational Brain Anatomy Laboratory
Cerebral Imaging Center
Douglas Mental Health University Institute
Affiliate, Department of Psychiatry
McGill University
t: 514.761.6131x4781
e: gdevenyi at gmail.com

On Thu, Sep 29, 2016 at 3:31 PM, Robert D. Vincent <
robert.d.vincent at mcgill.ca> wrote:

> Hi Gabriel,
>
> I don't know of a way to do it, but it would be easy to create. I'll look
> into it if nobody else comes up with a good suggestion.
>
>     -bert
>
>
> On Thu, Sep 29, 2016 at 3:27 PM, Gabriel A. Devenyi <
> gabriel.devenyi at mcgill.ca> wrote:
>
> > Thanks!
> >
> > I did indeed try after another reply off-list, sadly,
> scan_object_to_volume
> > seems to ignore colours.
> >
> > --
> > Gabriel A. Devenyi B.Eng. Ph.D.
> > Research Computing Associate
> > Computational Brain Anatomy Laboratory
> > Cerebral Imaging Center
> > Douglas Mental Health University Institute
> > McGill University
> > t: 514.761.6131x4781
> > e: gabriel.devenyi at mcgill.ca
> >
> > On Thu, Sep 29, 2016 at 3:23 PM, Mishkin Derakhshan <mishkind at gmail.com>
> > wrote:
> >
> > > Have you tried making a colored object and then scanning it to volume?
> > >
> > > Most .obj files default to having just one color per object, and for
> good
> > > reason, this lets you overlay different vertstats data and the like on
> > the
> > > same object. But you can also create a .obj file where the color is
> > stored
> > > per vertex. The program to do this is colour_object and should come
> with
> > > the default minc installation.
> > >
> > > With some luck, scan_object_to_volume will not ignore the colored data.
> > > worth a shot anyway.
> > >
> > > Here is some reference material for .obj files:
> > > http://www.bic.mni.mcgill.ca/Services/HowToWorkWithObjectFiles
> > >
> > > In particular you can see how things are colored here:
> > > http://www.bic.mni.mcgill.ca/users/david/FAQ/polygons_format.txt
> > >
> > >
> > > On Thu, Sep 29, 2016 at 7:45 AM, Gabriel A. Devenyi <
> > > gabriel.devenyi at mcgill.ca> wrote:
> > >
> > > > Hi all,
> > > >
> > > > I?m wondering if anyone knows of a method to map verstats data (data
> > on a
> > > > MNI object) into volume space.
> > > >
> > > > I know I can convert an object into a volume representation with
> > > > scan_object_to_volume. I?d like to then assign values to those voxels
> > > from
> > > > a verstats file.
> > > >
> > > > Thanks!
> > > >
> > > > ?
> > > > Gabriel A. Devenyi B.Eng. Ph.D.
> > > > Research Computing Associate
> > > > Computational Brain Anatomy Laboratory
> > > > Cerebral Imaging Center
> > > > Douglas Mental Health University Institute
> > > > McGill University
> > > > t: 514.761.6131x4781
> > > > e: gabriel.devenyi at mcgill.ca
> > > > ?
> > > > _______________________________________________
> > > > 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
> > >
> > _______________________________________________
> > 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 robert.d.vincent at mcgill.ca  Thu Sep 29 15:53:28 2016
From: robert.d.vincent at mcgill.ca (Robert D. Vincent)
Date: Thu, 29 Sep 2016 15:53:28 -0400
Subject: [MINC-users] Mapping surface (verstats) data into volume space
In-Reply-To: <CAFQOoOqor5i3NoQf-b40greKiKGodkH19UE-gPr+_bojR-sWow@mail.gmail.com>
References: <CAFQOoOr7q72xmD+gRy4obK_W709NnZybU386g8TFFfr_FFvuCg@mail.gmail.com>
	<CAB-GmL0aZLiD-4RrdBjtPo37UcrK9gR+ZoXbT7c6GM51-K5jrA@mail.gmail.com>
	<30148_1475177378_57ED6BA2_30148_205_4_CAFQOoOoP=fYE0FEOUd_fcQfdTmQgeC0X9spzV-=4cPjMN8Jz-w@mail.gmail.com>
	<CAAd5DeSZxyRTyTfa1EUP0jV8E4K5TE01u1y0rtQgX=fk+hiHiA@mail.gmail.com>
	<CAFQOoOqor5i3NoQf-b40greKiKGodkH19UE-gPr+_bojR-sWow@mail.gmail.com>
Message-ID: <CAAd5DeQkZm=PGNghTU1JybZxFrGqhuDx9_8bqGpgs8ZWFjfjoQ@mail.gmail.com>

What I imagine would be something like this:

1. Input a volume template, a surface, and a vertstats file.

2. Every voxel that intersects the surface would be set to the appropriate
value from the vertstats file (possibly using  nearest neighbor or linear
interpolation).

An alternative would be to take a coloured image and copy the colours into
an RGB volume, if you don't care about the actual vertstats values.

On Thu, Sep 29, 2016 at 3:45 PM, Gabriel A. Devenyi <gdevenyi at gmail.com>
wrote:

> If scan_object_to_volume could honour colour (optionally), that would
> probably work well. Thanks bert!
>
> --
> Gabriel A. Devenyi B.Eng. Ph.D.
> Research Computing Associate
> Computational Brain Anatomy Laboratory
> Cerebral Imaging Center
> Douglas Mental Health University Institute
> Affiliate, Department of Psychiatry
> McGill University
> t: 514.761.6131x4781
> e: gdevenyi at gmail.com
>
> On Thu, Sep 29, 2016 at 3:31 PM, Robert D. Vincent <
> robert.d.vincent at mcgill.ca> wrote:
>
> > Hi Gabriel,
> >
> > I don't know of a way to do it, but it would be easy to create. I'll look
> > into it if nobody else comes up with a good suggestion.
> >
> >     -bert
> >
> >
> > On Thu, Sep 29, 2016 at 3:27 PM, Gabriel A. Devenyi <
> > gabriel.devenyi at mcgill.ca> wrote:
> >
> > > Thanks!
> > >
> > > I did indeed try after another reply off-list, sadly,
> > scan_object_to_volume
> > > seems to ignore colours.
> > >
> > > --
> > > Gabriel A. Devenyi B.Eng. Ph.D.
> > > Research Computing Associate
> > > Computational Brain Anatomy Laboratory
> > > Cerebral Imaging Center
> > > Douglas Mental Health University Institute
> > > McGill University
> > > t: 514.761.6131x4781
> > > e: gabriel.devenyi at mcgill.ca
> > >
> > > On Thu, Sep 29, 2016 at 3:23 PM, Mishkin Derakhshan <
> mishkind at gmail.com>
> > > wrote:
> > >
> > > > Have you tried making a colored object and then scanning it to
> volume?
> > > >
> > > > Most .obj files default to having just one color per object, and for
> > good
> > > > reason, this lets you overlay different vertstats data and the like
> on
> > > the
> > > > same object. But you can also create a .obj file where the color is
> > > stored
> > > > per vertex. The program to do this is colour_object and should come
> > with
> > > > the default minc installation.
> > > >
> > > > With some luck, scan_object_to_volume will not ignore the colored
> data.
> > > > worth a shot anyway.
> > > >
> > > > Here is some reference material for .obj files:
> > > > http://www.bic.mni.mcgill.ca/Services/HowToWorkWithObjectFiles
> > > >
> > > > In particular you can see how things are colored here:
> > > > http://www.bic.mni.mcgill.ca/users/david/FAQ/polygons_format.txt
> > > >
> > > >
> > > > On Thu, Sep 29, 2016 at 7:45 AM, Gabriel A. Devenyi <
> > > > gabriel.devenyi at mcgill.ca> wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > I?m wondering if anyone knows of a method to map verstats data
> (data
> > > on a
> > > > > MNI object) into volume space.
> > > > >
> > > > > I know I can convert an object into a volume representation with
> > > > > scan_object_to_volume. I?d like to then assign values to those
> voxels
> > > > from
> > > > > a verstats file.
> > > > >
> > > > > Thanks!
> > > > >
> > > > > ?
> > > > > Gabriel A. Devenyi B.Eng. Ph.D.
> > > > > Research Computing Associate
> > > > > Computational Brain Anatomy Laboratory
> > > > > Cerebral Imaging Center
> > > > > Douglas Mental Health University Institute
> > > > > McGill University
> > > > > t: 514.761.6131x4781
> > > > > e: gabriel.devenyi at mcgill.ca
> > > > > ?
> > > > > _______________________________________________
> > > > > 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
> > > >
> > > _______________________________________________
> > > 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
> >
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>

From gdevenyi at gmail.com  Thu Sep 29 16:07:32 2016
From: gdevenyi at gmail.com (Gabriel A. Devenyi)
Date: Thu, 29 Sep 2016 16:07:32 -0400
Subject: [MINC-users] Mapping surface (verstats) data into volume space
In-Reply-To: <CAAd5DeQkZm=PGNghTU1JybZxFrGqhuDx9_8bqGpgs8ZWFjfjoQ@mail.gmail.com>
References: <CAFQOoOr7q72xmD+gRy4obK_W709NnZybU386g8TFFfr_FFvuCg@mail.gmail.com>
	<CAB-GmL0aZLiD-4RrdBjtPo37UcrK9gR+ZoXbT7c6GM51-K5jrA@mail.gmail.com>
	<30148_1475177378_57ED6BA2_30148_205_4_CAFQOoOoP=fYE0FEOUd_fcQfdTmQgeC0X9spzV-=4cPjMN8Jz-w@mail.gmail.com>
	<CAAd5DeSZxyRTyTfa1EUP0jV8E4K5TE01u1y0rtQgX=fk+hiHiA@mail.gmail.com>
	<CAFQOoOqor5i3NoQf-b40greKiKGodkH19UE-gPr+_bojR-sWow@mail.gmail.com>
	<CAAd5DeQkZm=PGNghTU1JybZxFrGqhuDx9_8bqGpgs8ZWFjfjoQ@mail.gmail.com>
Message-ID: <CAFQOoOqXOsxKB=WFdDops8oHsyz2AdSdEj0W10ikhHSKup0uhg@mail.gmail.com>

I care about the vertstats values, so option #1 sounds like the better deal.

--
Gabriel A. Devenyi B.Eng. Ph.D.
Research Computing Associate
Computational Brain Anatomy Laboratory
Cerebral Imaging Center
Douglas Mental Health University Institute
Affiliate, Department of Psychiatry
McGill University
t: 514.761.6131x4781
e: gdevenyi at gmail.com

On Thu, Sep 29, 2016 at 3:53 PM, Robert D. Vincent <
robert.d.vincent at mcgill.ca> wrote:

> What I imagine would be something like this:
>
> 1. Input a volume template, a surface, and a vertstats file.
>
> 2. Every voxel that intersects the surface would be set to the appropriate
> value from the vertstats file (possibly using  nearest neighbor or linear
> interpolation).
>
> An alternative would be to take a coloured image and copy the colours into
> an RGB volume, if you don't care about the actual vertstats values.
>
> On Thu, Sep 29, 2016 at 3:45 PM, Gabriel A. Devenyi <gdevenyi at gmail.com>
> wrote:
>
> > If scan_object_to_volume could honour colour (optionally), that would
> > probably work well. Thanks bert!
> >
> > --
> > Gabriel A. Devenyi B.Eng. Ph.D.
> > Research Computing Associate
> > Computational Brain Anatomy Laboratory
> > Cerebral Imaging Center
> > Douglas Mental Health University Institute
> > Affiliate, Department of Psychiatry
> > McGill University
> > t: 514.761.6131x4781
> > e: gdevenyi at gmail.com
> >
> > On Thu, Sep 29, 2016 at 3:31 PM, Robert D. Vincent <
> > robert.d.vincent at mcgill.ca> wrote:
> >
> > > Hi Gabriel,
> > >
> > > I don't know of a way to do it, but it would be easy to create. I'll
> look
> > > into it if nobody else comes up with a good suggestion.
> > >
> > >     -bert
> > >
> > >
> > > On Thu, Sep 29, 2016 at 3:27 PM, Gabriel A. Devenyi <
> > > gabriel.devenyi at mcgill.ca> wrote:
> > >
> > > > Thanks!
> > > >
> > > > I did indeed try after another reply off-list, sadly,
> > > scan_object_to_volume
> > > > seems to ignore colours.
> > > >
> > > > --
> > > > Gabriel A. Devenyi B.Eng. Ph.D.
> > > > Research Computing Associate
> > > > Computational Brain Anatomy Laboratory
> > > > Cerebral Imaging Center
> > > > Douglas Mental Health University Institute
> > > > McGill University
> > > > t: 514.761.6131x4781
> > > > e: gabriel.devenyi at mcgill.ca
> > > >
> > > > On Thu, Sep 29, 2016 at 3:23 PM, Mishkin Derakhshan <
> > mishkind at gmail.com>
> > > > wrote:
> > > >
> > > > > Have you tried making a colored object and then scanning it to
> > volume?
> > > > >
> > > > > Most .obj files default to having just one color per object, and
> for
> > > good
> > > > > reason, this lets you overlay different vertstats data and the like
> > on
> > > > the
> > > > > same object. But you can also create a .obj file where the color is
> > > > stored
> > > > > per vertex. The program to do this is colour_object and should come
> > > with
> > > > > the default minc installation.
> > > > >
> > > > > With some luck, scan_object_to_volume will not ignore the colored
> > data.
> > > > > worth a shot anyway.
> > > > >
> > > > > Here is some reference material for .obj files:
> > > > > http://www.bic.mni.mcgill.ca/Services/HowToWorkWithObjectFiles
> > > > >
> > > > > In particular you can see how things are colored here:
> > > > > http://www.bic.mni.mcgill.ca/users/david/FAQ/polygons_format.txt
> > > > >
> > > > >
> > > > > On Thu, Sep 29, 2016 at 7:45 AM, Gabriel A. Devenyi <
> > > > > gabriel.devenyi at mcgill.ca> wrote:
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > I?m wondering if anyone knows of a method to map verstats data
> > (data
> > > > on a
> > > > > > MNI object) into volume space.
> > > > > >
> > > > > > I know I can convert an object into a volume representation with
> > > > > > scan_object_to_volume. I?d like to then assign values to those
> > voxels
> > > > > from
> > > > > > a verstats file.
> > > > > >
> > > > > > Thanks!
> > > > > >
> > > > > > ?
> > > > > > Gabriel A. Devenyi B.Eng. Ph.D.
> > > > > > Research Computing Associate
> > > > > > Computational Brain Anatomy Laboratory
> > > > > > Cerebral Imaging Center
> > > > > > Douglas Mental Health University Institute
> > > > > > McGill University
> > > > > > t: 514.761.6131x4781
> > > > > > e: gabriel.devenyi at mcgill.ca
> > > > > > ?
> > > > > > _______________________________________________
> > > > > > 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
> > > > >
> > > > _______________________________________________
> > > > 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
> > >
> > _______________________________________________
> > 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 robert.d.vincent at mcgill.ca  Fri Sep 30 10:14:29 2016
From: robert.d.vincent at mcgill.ca (Robert D. Vincent)
Date: Fri, 30 Sep 2016 10:14:29 -0400
Subject: [MINC-users] Mapping surface (verstats) data into volume space
In-Reply-To: <CAFQOoOqXOsxKB=WFdDops8oHsyz2AdSdEj0W10ikhHSKup0uhg@mail.gmail.com>
References: <CAFQOoOr7q72xmD+gRy4obK_W709NnZybU386g8TFFfr_FFvuCg@mail.gmail.com>
	<CAB-GmL0aZLiD-4RrdBjtPo37UcrK9gR+ZoXbT7c6GM51-K5jrA@mail.gmail.com>
	<30148_1475177378_57ED6BA2_30148_205_4_CAFQOoOoP=fYE0FEOUd_fcQfdTmQgeC0X9spzV-=4cPjMN8Jz-w@mail.gmail.com>
	<CAAd5DeSZxyRTyTfa1EUP0jV8E4K5TE01u1y0rtQgX=fk+hiHiA@mail.gmail.com>
	<CAFQOoOqor5i3NoQf-b40greKiKGodkH19UE-gPr+_bojR-sWow@mail.gmail.com>
	<CAAd5DeQkZm=PGNghTU1JybZxFrGqhuDx9_8bqGpgs8ZWFjfjoQ@mail.gmail.com>
	<CAFQOoOqXOsxKB=WFdDops8oHsyz2AdSdEj0W10ikhHSKup0uhg@mail.gmail.com>
Message-ID: <CAAd5DeTtAV=_TCMa-sNcfeyjmKa5JiwF_LGr_euG9Gyxk4K6Jw@mail.gmail.com>

Hi Gabriel,

So I have a partial solution. It's a new tool that runs after
scan_object_to_volume and creates a new volume that is a nearest-neighbor
assignment of vertex values to the scanned voxels. As of now, it can only
read a "simple" statistics file that consists of a list of floating point
numbers, but getting basic vertstats support shouldn't be a big deal.

I'll send you the details so you can try it out and see if it seems to work.

    -bert

On Thu, Sep 29, 2016 at 4:07 PM, Gabriel A. Devenyi <gdevenyi at gmail.com>
wrote:

> I care about the vertstats values, so option #1 sounds like the better
> deal.
>
> --
> Gabriel A. Devenyi B.Eng. Ph.D.
> Research Computing Associate
> Computational Brain Anatomy Laboratory
> Cerebral Imaging Center
> Douglas Mental Health University Institute
> Affiliate, Department of Psychiatry
> McGill University
> t: 514.761.6131x4781
> e: gdevenyi at gmail.com
>
> On Thu, Sep 29, 2016 at 3:53 PM, Robert D. Vincent <
> robert.d.vincent at mcgill.ca> wrote:
>
> > What I imagine would be something like this:
> >
> > 1. Input a volume template, a surface, and a vertstats file.
> >
> > 2. Every voxel that intersects the surface would be set to the
> appropriate
> > value from the vertstats file (possibly using  nearest neighbor or linear
> > interpolation).
> >
> > An alternative would be to take a coloured image and copy the colours
> into
> > an RGB volume, if you don't care about the actual vertstats values.
> >
> > On Thu, Sep 29, 2016 at 3:45 PM, Gabriel A. Devenyi <gdevenyi at gmail.com>
> > wrote:
> >
> > > If scan_object_to_volume could honour colour (optionally), that would
> > > probably work well. Thanks bert!
> > >
> > > --
> > > Gabriel A. Devenyi B.Eng. Ph.D.
> > > Research Computing Associate
> > > Computational Brain Anatomy Laboratory
> > > Cerebral Imaging Center
> > > Douglas Mental Health University Institute
> > > Affiliate, Department of Psychiatry
> > > McGill University
> > > t: 514.761.6131x4781
> > > e: gdevenyi at gmail.com
> > >
> > > On Thu, Sep 29, 2016 at 3:31 PM, Robert D. Vincent <
> > > robert.d.vincent at mcgill.ca> wrote:
> > >
> > > > Hi Gabriel,
> > > >
> > > > I don't know of a way to do it, but it would be easy to create. I'll
> > look
> > > > into it if nobody else comes up with a good suggestion.
> > > >
> > > >     -bert
> > > >
> > > >
> > > > On Thu, Sep 29, 2016 at 3:27 PM, Gabriel A. Devenyi <
> > > > gabriel.devenyi at mcgill.ca> wrote:
> > > >
> > > > > Thanks!
> > > > >
> > > > > I did indeed try after another reply off-list, sadly,
> > > > scan_object_to_volume
> > > > > seems to ignore colours.
> > > > >
> > > > > --
> > > > > Gabriel A. Devenyi B.Eng. Ph.D.
> > > > > Research Computing Associate
> > > > > Computational Brain Anatomy Laboratory
> > > > > Cerebral Imaging Center
> > > > > Douglas Mental Health University Institute
> > > > > McGill University
> > > > > t: 514.761.6131x4781
> > > > > e: gabriel.devenyi at mcgill.ca
> > > > >
> > > > > On Thu, Sep 29, 2016 at 3:23 PM, Mishkin Derakhshan <
> > > mishkind at gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Have you tried making a colored object and then scanning it to
> > > volume?
> > > > > >
> > > > > > Most .obj files default to having just one color per object, and
> > for
> > > > good
> > > > > > reason, this lets you overlay different vertstats data and the
> like
> > > on
> > > > > the
> > > > > > same object. But you can also create a .obj file where the color
> is
> > > > > stored
> > > > > > per vertex. The program to do this is colour_object and should
> come
> > > > with
> > > > > > the default minc installation.
> > > > > >
> > > > > > With some luck, scan_object_to_volume will not ignore the colored
> > > data.
> > > > > > worth a shot anyway.
> > > > > >
> > > > > > Here is some reference material for .obj files:
> > > > > > http://www.bic.mni.mcgill.ca/Services/HowToWorkWithObjectFiles
> > > > > >
> > > > > > In particular you can see how things are colored here:
> > > > > > http://www.bic.mni.mcgill.ca/users/david/FAQ/polygons_format.txt
> > > > > >
> > > > > >
> > > > > > On Thu, Sep 29, 2016 at 7:45 AM, Gabriel A. Devenyi <
> > > > > > gabriel.devenyi at mcgill.ca> wrote:
> > > > > >
> > > > > > > Hi all,
> > > > > > >
> > > > > > > I?m wondering if anyone knows of a method to map verstats data
> > > (data
> > > > > on a
> > > > > > > MNI object) into volume space.
> > > > > > >
> > > > > > > I know I can convert an object into a volume representation
> with
> > > > > > > scan_object_to_volume. I?d like to then assign values to those
> > > voxels
> > > > > > from
> > > > > > > a verstats file.
> > > > > > >
> > > > > > > Thanks!
> > > > > > >
> > > > > > > ?
> > > > > > > Gabriel A. Devenyi B.Eng. Ph.D.
> > > > > > > Research Computing Associate
> > > > > > > Computational Brain Anatomy Laboratory
> > > > > > > Cerebral Imaging Center
> > > > > > > Douglas Mental Health University Institute
> > > > > > > McGill University
> > > > > > > t: 514.761.6131x4781
> > > > > > > e: gabriel.devenyi at mcgill.ca
> > > > > > > ?
> > > > > > > _______________________________________________
> > > > > > > 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
> > > > > >
> > > > > _______________________________________________
> > > > > 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
> > > >
> > > _______________________________________________
> > > 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
> >
> _______________________________________________
> MINC-users at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users
>