From m.shrawankumar at gmail.com Wed Apr 5 15:17:00 2017 From: m.shrawankumar at gmail.com (Shrawan) Date: Wed, 5 Apr 2017 12:17:00 -0700 Subject: [Neuroimaging] 3D to 2D projective transformation Message-ID: Dear all, I had previously posted this question on scikit-image and I was advised to post it in this forum. Could any one help me with a problem that involves finding registration parameters between a 3D volume data and a 2D perspective projection? The 3D data is a z-stack of light microscopy images and the 2D data is from scanning electron microscopy. I can provide more details if needed. Thank you in advance Best, Shrawan -- Shrawan Kumar Mageswaran Postdoctoral Scholar Jensen Lab California Institute of Technology -------------- next part -------------- An HTML attachment was scrubbed... URL: From yann at cointepas.net Thu Apr 6 08:49:34 2017 From: yann at cointepas.net (Yann Cointepas) Date: Thu, 6 Apr 2017 14:49:34 +0200 Subject: [Neuroimaging] [Job offer] Development Engineer for Neuroimaging (Paris, France) Message-ID: The CATI (http://cati-neuroimaging.com) is recruiting an engineer for its brain imaging acquisition and analysis platform. Details of the offer can be found in the attached document. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IngeDev2017-en.pdf Type: application/pdf Size: 245018 bytes Desc: not available URL: From yann at cointepas.net Thu Apr 6 11:54:42 2017 From: yann at cointepas.net (Yann Cointepas) Date: Thu, 6 Apr 2017 17:54:42 +0200 Subject: [Neuroimaging] [Job offer] Computer Scientist contributing to the European Human Brain Project Message-ID: The CEA Neurospin is recruiting an engineer for the Human Brain Project. Details of the offer can be found in the attached document. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PosteInfoHBP.pdf Type: application/pdf Size: 54559 bytes Desc: not available URL: From emma.robinson01 at gmail.com Wed Apr 12 09:54:10 2017 From: emma.robinson01 at gmail.com (Emma Robinson) Date: Wed, 12 Apr 2017 14:54:10 +0100 Subject: [Neuroimaging] writing gifti files Message-ID: Hi I have a problem reading giftis that I write from nibabel. It works if I replace the data with data taken straight out of another gifti data array, but if I add a matrix of floats I am unable to read it into the HCP's workbench viewer, not use the FSL gifti reader. I get the following error messages: from wb_view Parse Error while reading /vol/medic01/users/ecr05/TESTINGRESULT2.func.gii: Decoding of GZip Base64 Binary data failed.Decoded 0 bytes but should be 0 bytes. line number: 15 column number: 68831 from FSL terminate called after throwing an instance of 'GiftiException' what(): Requested non-float data from float GIFTI field I've attached some test code and the gifti file I tested it with. Any suggestions of how to fix this would be appreciated, thanks Emma -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: testgiftisave.py Type: text/x-python Size: 881 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Q1-Q6_RelatedParcellation210.MyelinMap_BC_MSMAll_2_d41_WRN_DeDrift.32k_fs_LR.L.func.gii Type: application/octet-stream Size: 133495 bytes Desc: not available URL: From Michiel.Cottaar at ndcn.ox.ac.uk Fri Apr 14 16:41:47 2017 From: Michiel.Cottaar at ndcn.ox.ac.uk (Michiel Cottaar) Date: Fri, 14 Apr 2017 16:41:47 -0400 Subject: [Neuroimaging] writing gifti files In-Reply-To: References: Message-ID: Hi Emma, The problem is that wb_view only supports float32 while python likes to convert everything to float64. The produced gifti file opens normally in wb_view, when I convert your data to float32 just before creating the data arrays (see attached file). Michiel On 12/04/2017 09:54, Emma Robinson wrote: > Hi > > I have a problem reading giftis that I write from nibabel. It works if > I replace the data with data taken straight out of another gifti data > array, but if I add a matrix of floats I am unable to read it into the > HCP's workbench viewer, not use the FSL gifti reader. I get the > following error messages: > > from wb_view > > Parse Error while reading > /vol/medic01/users/ecr05/TESTINGRESULT2.func.gii: Decoding of GZip > Base64 Binary data failed.Decoded 0 bytes but should be 0 bytes. line > number: 15 column number: 68831 > > > from FSL > > terminate called after throwing an instance of 'GiftiException' > what(): Requested non-float data from float GIFTI field > > I've attached some test code and the gifti file I tested it with. Any > suggestions of how to fix this would be appreciated, thanks > > Emma > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: testgiftisave.py Type: text/x-python Size: 900 bytes Desc: not available URL: From emma.robinson01 at gmail.com Sat Apr 15 03:35:59 2017 From: emma.robinson01 at gmail.com (Emma Robinson) Date: Sat, 15 Apr 2017 08:35:59 +0100 Subject: [Neuroimaging] writing gifti files In-Reply-To: References: Message-ID: That's really helpful, thanks. On 14 April 2017 at 21:41, Michiel Cottaar wrote: > Hi Emma, > > The problem is that wb_view only supports float32 while python likes to > convert everything to float64. The produced gifti file opens normally in > wb_view, when I convert your data to float32 just before creating the data > arrays (see attached file). > > Michiel > > On 12/04/2017 09:54, Emma Robinson wrote: > > Hi > > I have a problem reading giftis that I write from nibabel. It works if I > replace the data with data taken straight out of another gifti data array, > but if I add a matrix of floats I am unable to read it into the HCP's > workbench viewer, not use the FSL gifti reader. I get the following error > messages: > > from wb_view > > Parse Error while reading /vol/medic01/users/ecr05/TESTINGRESULT2.func.gii: > Decoding of GZip Base64 Binary data failed.Decoded 0 bytes but should be 0 > bytes. line number: 15 column number: 68831 > > from FSL > > terminate called after throwing an instance of 'GiftiException' > what(): Requested non-float data from float GIFTI field > > I've attached some test code and the gifti file I tested it with. Any > suggestions of how to fix this would be appreciated, thanks > > Emma > > > _______________________________________________ > Neuroimaging mailing listNeuroimaging at python.orghttps://mail.python.org/mailman/listinfo/neuroimaging > > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Tue Apr 18 11:01:00 2017 From: matthew.brett at gmail.com (Matthew Brett) Date: Tue, 18 Apr 2017 16:01:00 +0100 Subject: [Neuroimaging] Nibabel API change - always read as float In-Reply-To: References: <20150706155516.GA28964@onerussian.com> <5F6A858FD00E5F4A82E3206D2D854EF87F74B4AE@EXMB10.ohsu.edu> <5F6A858FD00E5F4A82E3206D2D854EF87F74B622@EXMB10.ohsu.edu> Message-ID: Hi, On Wed, Jul 22, 2015 at 3:53 PM, Satrajit Ghosh wrote: > hi matthew, > >> I'm not sure what you mean by 'did not interpret this' unless you are >> agreeing with me that the niftiio library gives no clues as what the >> intention for the in-memory type was. If anything I think that >> supports my reading that the authors had not considered the >> interpretation of "scl_slope != 0 -> in-memory float". > > > i simply meant they left any interpretation of how to scale or change of > in-memory data type to the end developer. > >> I can surely attach the raw scalefactors to the array proxy (dataobj), > > > that would be great > >> >> but I think it's a terrible idea to use the scl_slope == 0 as an >> indication for in-memory type, because it's not a convention that (as >> far as I know) anyone else uses, > > > all the examples of the code bases i provided in fact leave the in-memory > type to be the same as the native dtype for scalefactors (0, X) and (1, 0). > i agree, that this is an implementation of the standard as interpreted by > those developers, similar to present nibabel. i do agree that nifti authors > had nothing to say about such an interpretation. Following up on this one, much later - I have a new proposal, that I have written up here: https://github.com/nipy/nibabel/wiki/BIAP8 Shortest possible summary: * add "get_fdata" method to images, returning floating point data; * deprecate "get_data" method in one year; * raise error for "get_data" method in three years. This has the advantage that older code using nibabel will not silently return a different result, but will error, with an informative message, for the foreseeable future. Any thoughts on this version? Cheers, Matthew From njvack at wisc.edu Tue Apr 18 11:10:09 2017 From: njvack at wisc.edu (Nate Vack) Date: Tue, 18 Apr 2017 15:10:09 +0000 Subject: [Neuroimaging] Nibabel API change - always read as float In-Reply-To: References: <20150706155516.GA28964@onerussian.com> <5F6A858FD00E5F4A82E3206D2D854EF87F74B4AE@EXMB10.ohsu.edu> <5F6A858FD00E5F4A82E3206D2D854EF87F74B622@EXMB10.ohsu.edu> Message-ID: Sounds excellent to me. I'd suggest the deprecation and error messages mention both get_fdata() and the technique to get native-type data. Best, -Nate On Tue, Apr 18, 2017 at 10:03 AM Matthew Brett wrote: > Hi, > > On Wed, Jul 22, 2015 at 3:53 PM, Satrajit Ghosh wrote: > > hi matthew, > > > >> I'm not sure what you mean by 'did not interpret this' unless you are > >> agreeing with me that the niftiio library gives no clues as what the > >> intention for the in-memory type was. If anything I think that > >> supports my reading that the authors had not considered the > >> interpretation of "scl_slope != 0 -> in-memory float". > > > > > > i simply meant they left any interpretation of how to scale or change of > > in-memory data type to the end developer. > > > >> I can surely attach the raw scalefactors to the array proxy (dataobj), > > > > > > that would be great > > > >> > >> but I think it's a terrible idea to use the scl_slope == 0 as an > >> indication for in-memory type, because it's not a convention that (as > >> far as I know) anyone else uses, > > > > > > all the examples of the code bases i provided in fact leave the in-memory > > type to be the same as the native dtype for scalefactors (0, X) and (1, > 0). > > i agree, that this is an implementation of the standard as interpreted by > > those developers, similar to present nibabel. i do agree that nifti > authors > > had nothing to say about such an interpretation. > > Following up on this one, much later - I have a new proposal, that I > have written up here: > > https://github.com/nipy/nibabel/wiki/BIAP8 > > Shortest possible summary: > > * add "get_fdata" method to images, returning floating point data; > * deprecate "get_data" method in one year; > * raise error for "get_data" method in three years. > > This has the advantage that older code using nibabel will not silently > return a different result, but will error, with an informative > message, for the foreseeable future. > > Any thoughts on this version? > > Cheers, > > Matthew > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Tue Apr 18 12:53:01 2017 From: matthew.brett at gmail.com (Matthew Brett) Date: Tue, 18 Apr 2017 17:53:01 +0100 Subject: [Neuroimaging] Nibabel API change - always read as float In-Reply-To: References: <20150706155516.GA28964@onerussian.com> <5F6A858FD00E5F4A82E3206D2D854EF87F74B4AE@EXMB10.ohsu.edu> <5F6A858FD00E5F4A82E3206D2D854EF87F74B622@EXMB10.ohsu.edu> Message-ID: Hi, On Tue, Apr 18, 2017 at 4:10 PM, Nate Vack wrote: > Sounds excellent to me. I'd suggest the deprecation and error messages > mention both get_fdata() and the technique to get native-type data. Thanks - I added a suggestion for the deprecation / error messages in the BIAP doc, Cheers, Matthew From satra at mit.edu Wed Apr 19 13:45:42 2017 From: satra at mit.edu (Satrajit Ghosh) Date: Wed, 19 Apr 2017 13:45:42 -0400 Subject: [Neuroimaging] Nibabel API change - always read as float In-Reply-To: References: <20150706155516.GA28964@onerussian.com> <5F6A858FD00E5F4A82E3206D2D854EF87F74B4AE@EXMB10.ohsu.edu> <5F6A858FD00E5F4A82E3206D2D854EF87F74B622@EXMB10.ohsu.edu> Message-ID: hi matthew, updates look good. cheers, satra On Tue, Apr 18, 2017 at 11:10 AM, Nate Vack wrote: > Sounds excellent to me. I'd suggest the deprecation and error messages > mention both get_fdata() and the technique to get native-type data. > > Best, > -Nate > > On Tue, Apr 18, 2017 at 10:03 AM Matthew Brett > wrote: > >> Hi, >> >> On Wed, Jul 22, 2015 at 3:53 PM, Satrajit Ghosh wrote: >> > hi matthew, >> > >> >> I'm not sure what you mean by 'did not interpret this' unless you are >> >> agreeing with me that the niftiio library gives no clues as what the >> >> intention for the in-memory type was. If anything I think that >> >> supports my reading that the authors had not considered the >> >> interpretation of "scl_slope != 0 -> in-memory float". >> > >> > >> > i simply meant they left any interpretation of how to scale or change of >> > in-memory data type to the end developer. >> > >> >> I can surely attach the raw scalefactors to the array proxy (dataobj), >> > >> > >> > that would be great >> > >> >> >> >> but I think it's a terrible idea to use the scl_slope == 0 as an >> >> indication for in-memory type, because it's not a convention that (as >> >> far as I know) anyone else uses, >> > >> > >> > all the examples of the code bases i provided in fact leave the >> in-memory >> > type to be the same as the native dtype for scalefactors (0, X) and (1, >> 0). >> > i agree, that this is an implementation of the standard as interpreted >> by >> > those developers, similar to present nibabel. i do agree that nifti >> authors >> > had nothing to say about such an interpretation. >> >> Following up on this one, much later - I have a new proposal, that I >> have written up here: >> >> https://github.com/nipy/nibabel/wiki/BIAP8 >> >> Shortest possible summary: >> >> * add "get_fdata" method to images, returning floating point data; >> * deprecate "get_data" method in one year; >> * raise error for "get_data" method in three years. >> >> This has the advantage that older code using nibabel will not silently >> return a different result, but will error, with an informative >> message, for the foreseeable future. >> >> Any thoughts on this version? >> >> Cheers, >> >> Matthew >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arokem at gmail.com Sat Apr 22 22:15:57 2017 From: arokem at gmail.com (Ariel Rokem) Date: Sat, 22 Apr 2017 19:15:57 -0700 Subject: [Neuroimaging] Nibabel API change - always read as float In-Reply-To: References: <20150706155516.GA28964@onerussian.com> <5F6A858FD00E5F4A82E3206D2D854EF87F74B4AE@EXMB10.ohsu.edu> <5F6A858FD00E5F4A82E3206D2D854EF87F74B622@EXMB10.ohsu.edu> Message-ID: On Tue, Apr 18, 2017 at 8:01 AM, Matthew Brett wrote: > Hi, > > On Wed, Jul 22, 2015 at 3:53 PM, Satrajit Ghosh wrote: > > hi matthew, > > > >> I'm not sure what you mean by 'did not interpret this' unless you are > >> agreeing with me that the niftiio library gives no clues as what the > >> intention for the in-memory type was. If anything I think that > >> supports my reading that the authors had not considered the > >> interpretation of "scl_slope != 0 -> in-memory float". > > > > > > i simply meant they left any interpretation of how to scale or change of > > in-memory data type to the end developer. > > > >> I can surely attach the raw scalefactors to the array proxy (dataobj), > > > > > > that would be great > > > >> > >> but I think it's a terrible idea to use the scl_slope == 0 as an > >> indication for in-memory type, because it's not a convention that (as > >> far as I know) anyone else uses, > > > > > > all the examples of the code bases i provided in fact leave the in-memory > > type to be the same as the native dtype for scalefactors (0, X) and (1, > 0). > > i agree, that this is an implementation of the standard as interpreted by > > those developers, similar to present nibabel. i do agree that nifti > authors > > had nothing to say about such an interpretation. > > Following up on this one, much later - I have a new proposal, that I > have written up here: > > https://github.com/nipy/nibabel/wiki/BIAP8 > > Shortest possible summary: > > * add "get_fdata" method to images, returning floating point data; > * deprecate "get_data" method in one year; > * raise error for "get_data" method in three years. > > Just to clarify: after the removal of "get_data", what would a user need to do to produce the current behavior of a `get_data()` call? Something like this was mentioned somewhere along this thread: data = img.dataobj.get_unscaled() Is that it? This has the advantage that older code using nibabel will not silently > return a different result, but will error, with an informative > message, for the foreseeable future. > > Any thoughts on this version? > > Cheers, > > Matthew > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > -------------- next part -------------- An HTML attachment was scrubbed... URL: From satra at mit.edu Sun Apr 23 09:22:59 2017 From: satra at mit.edu (Satrajit Ghosh) Date: Sun, 23 Apr 2017 09:22:59 -0400 Subject: [Neuroimaging] Nibabel API change - always read as float In-Reply-To: References: <20150706155516.GA28964@onerussian.com> <5F6A858FD00E5F4A82E3206D2D854EF87F74B4AE@EXMB10.ohsu.edu> <5F6A858FD00E5F4A82E3206D2D854EF87F74B622@EXMB10.ohsu.edu> Message-ID: hi ariel, i believe get_unscaled does not scale if scale factor=1 and intercept=0 and then the call is equivalent to get_data. however, if those values are different from (1, 0), then get_unscaled differs from get_data. cheers, satra On Sat, Apr 22, 2017 at 10:15 PM, Ariel Rokem wrote: > > > On Tue, Apr 18, 2017 at 8:01 AM, Matthew Brett > wrote: > >> Hi, >> >> On Wed, Jul 22, 2015 at 3:53 PM, Satrajit Ghosh wrote: >> > hi matthew, >> > >> >> I'm not sure what you mean by 'did not interpret this' unless you are >> >> agreeing with me that the niftiio library gives no clues as what the >> >> intention for the in-memory type was. If anything I think that >> >> supports my reading that the authors had not considered the >> >> interpretation of "scl_slope != 0 -> in-memory float". >> > >> > >> > i simply meant they left any interpretation of how to scale or change of >> > in-memory data type to the end developer. >> > >> >> I can surely attach the raw scalefactors to the array proxy (dataobj), >> > >> > >> > that would be great >> > >> >> >> >> but I think it's a terrible idea to use the scl_slope == 0 as an >> >> indication for in-memory type, because it's not a convention that (as >> >> far as I know) anyone else uses, >> > >> > >> > all the examples of the code bases i provided in fact leave the >> in-memory >> > type to be the same as the native dtype for scalefactors (0, X) and (1, >> 0). >> > i agree, that this is an implementation of the standard as interpreted >> by >> > those developers, similar to present nibabel. i do agree that nifti >> authors >> > had nothing to say about such an interpretation. >> >> Following up on this one, much later - I have a new proposal, that I >> have written up here: >> >> https://github.com/nipy/nibabel/wiki/BIAP8 >> >> Shortest possible summary: >> >> * add "get_fdata" method to images, returning floating point data; >> * deprecate "get_data" method in one year; >> * raise error for "get_data" method in three years. >> >> > Just to clarify: after the removal of "get_data", what would a user need > to do to produce the current behavior of a `get_data()` call? > > Something like this was mentioned somewhere along this thread: > > data = img.dataobj.get_unscaled() > > Is that it? > > This has the advantage that older code using nibabel will not silently >> return a different result, but will error, with an informative >> message, for the foreseeable future. >> >> Any thoughts on this version? >> >> Cheers, >> >> Matthew >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bcipolli at ucsd.edu Sun Apr 23 09:25:23 2017 From: bcipolli at ucsd.edu (Ben Cipollini) Date: Sun, 23 Apr 2017 06:25:23 -0700 Subject: [Neuroimaging] Nibabel API change - always read as float In-Reply-To: References: <20150706155516.GA28964@onerussian.com> <5F6A858FD00E5F4A82E3206D2D854EF87F74B4AE@EXMB10.ohsu.edu> <5F6A858FD00E5F4A82E3206D2D854EF87F74B622@EXMB10.ohsu.edu> Message-ID: My understanding of the discussion above was that get_fdata() would lead to the same behavior as get_data() now. On Sat, Apr 22, 2017 at 7:15 PM, Ariel Rokem wrote: > > > On Tue, Apr 18, 2017 at 8:01 AM, Matthew Brett > wrote: > >> Hi, >> >> On Wed, Jul 22, 2015 at 3:53 PM, Satrajit Ghosh wrote: >> > hi matthew, >> > >> >> I'm not sure what you mean by 'did not interpret this' unless you are >> >> agreeing with me that the niftiio library gives no clues as what the >> >> intention for the in-memory type was. If anything I think that >> >> supports my reading that the authors had not considered the >> >> interpretation of "scl_slope != 0 -> in-memory float". >> > >> > >> > i simply meant they left any interpretation of how to scale or change of >> > in-memory data type to the end developer. >> > >> >> I can surely attach the raw scalefactors to the array proxy (dataobj), >> > >> > >> > that would be great >> > >> >> >> >> but I think it's a terrible idea to use the scl_slope == 0 as an >> >> indication for in-memory type, because it's not a convention that (as >> >> far as I know) anyone else uses, >> > >> > >> > all the examples of the code bases i provided in fact leave the >> in-memory >> > type to be the same as the native dtype for scalefactors (0, X) and (1, >> 0). >> > i agree, that this is an implementation of the standard as interpreted >> by >> > those developers, similar to present nibabel. i do agree that nifti >> authors >> > had nothing to say about such an interpretation. >> >> Following up on this one, much later - I have a new proposal, that I >> have written up here: >> >> https://github.com/nipy/nibabel/wiki/BIAP8 >> >> Shortest possible summary: >> >> * add "get_fdata" method to images, returning floating point data; >> * deprecate "get_data" method in one year; >> * raise error for "get_data" method in three years. >> >> > Just to clarify: after the removal of "get_data", what would a user need > to do to produce the current behavior of a `get_data()` call? > > Something like this was mentioned somewhere along this thread: > > data = img.dataobj.get_unscaled() > > Is that it? > > This has the advantage that older code using nibabel will not silently >> return a different result, but will error, with an informative >> message, for the foreseeable future. >> >> Any thoughts on this version? >> >> Cheers, >> >> Matthew >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From satra at mit.edu Sun Apr 23 09:34:27 2017 From: satra at mit.edu (Satrajit Ghosh) Date: Sun, 23 Apr 2017 09:34:27 -0400 Subject: [Neuroimaging] Nibabel API change - always read as float In-Reply-To: References: <20150706155516.GA28964@onerussian.com> <5F6A858FD00E5F4A82E3206D2D854EF87F74B4AE@EXMB10.ohsu.edu> <5F6A858FD00E5F4A82E3206D2D854EF87F74B622@EXMB10.ohsu.edu> Message-ID: hi ben, i thought get_fdata() would always return float independent of whether the data needs to be scaled or not. so in that sense a little different from get_data, which would return datatype of disk if the data did not need to be scaled, but float otherwise. cheers, satra On Sun, Apr 23, 2017 at 9:25 AM, Ben Cipollini wrote: > My understanding of the discussion above was that get_fdata() would lead > to the same behavior as get_data() now. > > On Sat, Apr 22, 2017 at 7:15 PM, Ariel Rokem wrote: > >> >> >> On Tue, Apr 18, 2017 at 8:01 AM, Matthew Brett >> wrote: >> >>> Hi, >>> >>> On Wed, Jul 22, 2015 at 3:53 PM, Satrajit Ghosh wrote: >>> > hi matthew, >>> > >>> >> I'm not sure what you mean by 'did not interpret this' unless you are >>> >> agreeing with me that the niftiio library gives no clues as what the >>> >> intention for the in-memory type was. If anything I think that >>> >> supports my reading that the authors had not considered the >>> >> interpretation of "scl_slope != 0 -> in-memory float". >>> > >>> > >>> > i simply meant they left any interpretation of how to scale or change >>> of >>> > in-memory data type to the end developer. >>> > >>> >> I can surely attach the raw scalefactors to the array proxy (dataobj), >>> > >>> > >>> > that would be great >>> > >>> >> >>> >> but I think it's a terrible idea to use the scl_slope == 0 as an >>> >> indication for in-memory type, because it's not a convention that (as >>> >> far as I know) anyone else uses, >>> > >>> > >>> > all the examples of the code bases i provided in fact leave the >>> in-memory >>> > type to be the same as the native dtype for scalefactors (0, X) and >>> (1, 0). >>> > i agree, that this is an implementation of the standard as interpreted >>> by >>> > those developers, similar to present nibabel. i do agree that nifti >>> authors >>> > had nothing to say about such an interpretation. >>> >>> Following up on this one, much later - I have a new proposal, that I >>> have written up here: >>> >>> https://github.com/nipy/nibabel/wiki/BIAP8 >>> >>> Shortest possible summary: >>> >>> * add "get_fdata" method to images, returning floating point data; >>> * deprecate "get_data" method in one year; >>> * raise error for "get_data" method in three years. >>> >>> >> Just to clarify: after the removal of "get_data", what would a user need >> to do to produce the current behavior of a `get_data()` call? >> >> Something like this was mentioned somewhere along this thread: >> >> data = img.dataobj.get_unscaled() >> >> Is that it? >> >> This has the advantage that older code using nibabel will not silently >>> return a different result, but will error, with an informative >>> message, for the foreseeable future. >>> >>> Any thoughts on this version? >>> >>> Cheers, >>> >>> Matthew >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bcipolli at ucsd.edu Sun Apr 23 09:38:29 2017 From: bcipolli at ucsd.edu (Ben Cipollini) Date: Sun, 23 Apr 2017 06:38:29 -0700 Subject: [Neuroimaging] Nibabel API change - always read as float In-Reply-To: References: <20150706155516.GA28964@onerussian.com> <5F6A858FD00E5F4A82E3206D2D854EF87F74B4AE@EXMB10.ohsu.edu> <5F6A858FD00E5F4A82E3206D2D854EF87F74B622@EXMB10.ohsu.edu> Message-ID: Ah, sorry, my misunderstanding. Thanks for the clarification. On Sun, Apr 23, 2017 at 6:34 AM, Satrajit Ghosh wrote: > hi ben, > > i thought get_fdata() would always return float independent of whether the > data needs to be scaled or not. so in that sense a little different from > get_data, which would return datatype of disk if the data did not need to > be scaled, but float otherwise. > > cheers, > > satra > > On Sun, Apr 23, 2017 at 9:25 AM, Ben Cipollini wrote: > >> My understanding of the discussion above was that get_fdata() would lead >> to the same behavior as get_data() now. >> >> On Sat, Apr 22, 2017 at 7:15 PM, Ariel Rokem wrote: >> >>> >>> >>> On Tue, Apr 18, 2017 at 8:01 AM, Matthew Brett >>> wrote: >>> >>>> Hi, >>>> >>>> On Wed, Jul 22, 2015 at 3:53 PM, Satrajit Ghosh wrote: >>>> > hi matthew, >>>> > >>>> >> I'm not sure what you mean by 'did not interpret this' unless you are >>>> >> agreeing with me that the niftiio library gives no clues as what the >>>> >> intention for the in-memory type was. If anything I think that >>>> >> supports my reading that the authors had not considered the >>>> >> interpretation of "scl_slope != 0 -> in-memory float". >>>> > >>>> > >>>> > i simply meant they left any interpretation of how to scale or change >>>> of >>>> > in-memory data type to the end developer. >>>> > >>>> >> I can surely attach the raw scalefactors to the array proxy >>>> (dataobj), >>>> > >>>> > >>>> > that would be great >>>> > >>>> >> >>>> >> but I think it's a terrible idea to use the scl_slope == 0 as an >>>> >> indication for in-memory type, because it's not a convention that (as >>>> >> far as I know) anyone else uses, >>>> > >>>> > >>>> > all the examples of the code bases i provided in fact leave the >>>> in-memory >>>> > type to be the same as the native dtype for scalefactors (0, X) and >>>> (1, 0). >>>> > i agree, that this is an implementation of the standard as >>>> interpreted by >>>> > those developers, similar to present nibabel. i do agree that nifti >>>> authors >>>> > had nothing to say about such an interpretation. >>>> >>>> Following up on this one, much later - I have a new proposal, that I >>>> have written up here: >>>> >>>> https://github.com/nipy/nibabel/wiki/BIAP8 >>>> >>>> Shortest possible summary: >>>> >>>> * add "get_fdata" method to images, returning floating point data; >>>> * deprecate "get_data" method in one year; >>>> * raise error for "get_data" method in three years. >>>> >>>> >>> Just to clarify: after the removal of "get_data", what would a user need >>> to do to produce the current behavior of a `get_data()` call? >>> >>> Something like this was mentioned somewhere along this thread: >>> >>> data = img.dataobj.get_unscaled() >>> >>> Is that it? >>> >>> This has the advantage that older code using nibabel will not silently >>>> return a different result, but will error, with an informative >>>> message, for the foreseeable future. >>>> >>>> Any thoughts on this version? >>>> >>>> Cheers, >>>> >>>> Matthew >>>> _______________________________________________ >>>> Neuroimaging mailing list >>>> Neuroimaging at python.org >>>> https://mail.python.org/mailman/listinfo/neuroimaging >>>> >>> >>> >>> _______________________________________________ >>> Neuroimaging mailing list >>> Neuroimaging at python.org >>> https://mail.python.org/mailman/listinfo/neuroimaging >>> >>> >> >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> >> > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From effigies at bu.edu Sun Apr 23 09:44:12 2017 From: effigies at bu.edu (Christopher Markiewicz) Date: Sun, 23 Apr 2017 09:44:12 -0400 Subject: [Neuroimaging] Nibabel API change - always read as float In-Reply-To: References: <20150706155516.GA28964@onerussian.com> <5F6A858FD00E5F4A82E3206D2D854EF87F74B4AE@EXMB10.ohsu.edu> <5F6A858FD00E5F4A82E3206D2D854EF87F74B622@EXMB10.ohsu.edu> Message-ID: My understanding (not checking the code): Currently, get_data has two modes: scaling and not, depending on the parameters. get_fdata will always be float, even if no scaling needs to be applied. If you want current behavior, you use np.asanyarray(img.dataobj); if you want unscaled, you use img.dataobj.get_unscaled(). Chris On Apr 23, 2017 9:26 AM, "Ben Cipollini" wrote: My understanding of the discussion above was that get_fdata() would lead to the same behavior as get_data() now. On Sat, Apr 22, 2017 at 7:15 PM, Ariel Rokem wrote: > > > On Tue, Apr 18, 2017 at 8:01 AM, Matthew Brett > wrote: > >> Hi, >> >> On Wed, Jul 22, 2015 at 3:53 PM, Satrajit Ghosh wrote: >> > hi matthew, >> > >> >> I'm not sure what you mean by 'did not interpret this' unless you are >> >> agreeing with me that the niftiio library gives no clues as what the >> >> intention for the in-memory type was. If anything I think that >> >> supports my reading that the authors had not considered the >> >> interpretation of "scl_slope != 0 -> in-memory float". >> > >> > >> > i simply meant they left any interpretation of how to scale or change of >> > in-memory data type to the end developer. >> > >> >> I can surely attach the raw scalefactors to the array proxy (dataobj), >> > >> > >> > that would be great >> > >> >> >> >> but I think it's a terrible idea to use the scl_slope == 0 as an >> >> indication for in-memory type, because it's not a convention that (as >> >> far as I know) anyone else uses, >> > >> > >> > all the examples of the code bases i provided in fact leave the >> in-memory >> > type to be the same as the native dtype for scalefactors (0, X) and (1, >> 0). >> > i agree, that this is an implementation of the standard as interpreted >> by >> > those developers, similar to present nibabel. i do agree that nifti >> authors >> > had nothing to say about such an interpretation. >> >> Following up on this one, much later - I have a new proposal, that I >> have written up here: >> >> https://github.com/nipy/nibabel/wiki/BIAP8 >> >> Shortest possible summary: >> >> * add "get_fdata" method to images, returning floating point data; >> * deprecate "get_data" method in one year; >> * raise error for "get_data" method in three years. >> >> > Just to clarify: after the removal of "get_data", what would a user need > to do to produce the current behavior of a `get_data()` call? > > Something like this was mentioned somewhere along this thread: > > data = img.dataobj.get_unscaled() > > Is that it? > > This has the advantage that older code using nibabel will not silently >> return a different result, but will error, with an informative >> message, for the foreseeable future. >> >> Any thoughts on this version? >> >> Cheers, >> >> Matthew >> _______________________________________________ >> Neuroimaging mailing list >> Neuroimaging at python.org >> https://mail.python.org/mailman/listinfo/neuroimaging >> > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > _______________________________________________ Neuroimaging mailing list Neuroimaging at python.org https://mail.python.org/mailman/listinfo/neuroimaging -------------- next part -------------- An HTML attachment was scrubbed... URL: From elef at indiana.edu Sun Apr 23 23:01:11 2017 From: elef at indiana.edu (Eleftherios Garyfallidis) Date: Mon, 24 Apr 2017 03:01:11 +0000 Subject: [Neuroimaging] DIPY @ ISMRM 2017 Message-ID: Hi all, Me, Julio and other DIPY contributors are in ISMRM in Honolulu. Here are some of our oral and poster numbers. Rafael Neto Henriques #1270, #1787 Stephan Meesters #3476 Tingyi Wanyan # 3497 Maryam Afzali # 3370 If you are using DIPY send us your abstract numbers. Nonetheless, it would be great to meet you all! Best regards, Eleftherios -------------- next part -------------- An HTML attachment was scrubbed... URL: From elef at indiana.edu Mon Apr 24 15:01:05 2017 From: elef at indiana.edu (Eleftherios Garyfallidis) Date: Mon, 24 Apr 2017 19:01:05 +0000 Subject: [Neuroimaging] DIPY @ ISMRM 2017 In-Reply-To: References: Message-ID: Also, Demian informed me there is another DIPY related poster by Rutger Fick # 1761 Best regards, Eleftherios On Sun, Apr 23, 2017 at 11:01 PM Eleftherios Garyfallidis wrote: > Hi all, > > Me, Julio and other DIPY contributors are in ISMRM in Honolulu. Here are > some of our oral and poster numbers. > > Rafael Neto Henriques #1270, #1787 > Stephan Meesters #3476 > Tingyi Wanyan # 3497 > Maryam Afzali # 3370 > > If you are using DIPY send us your abstract numbers. > Nonetheless, it would be great to meet you all! > > Best regards, > Eleftherios > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elef at indiana.edu Tue Apr 25 22:45:12 2017 From: elef at indiana.edu (Eleftherios Garyfallidis) Date: Wed, 26 Apr 2017 02:45:12 +0000 Subject: [Neuroimaging] DIPY @ ISMRM 2017 In-Reply-To: References: Message-ID: Great news from ISMRM! Our own Rafael Neto Henriquez won today best poster award with his work on fitting properly the free water DTI model which he implemented in DIPY. This work is already merged and available master. Many congratulations Rafael! Best regards, Eleftherios On Mon, Apr 24, 2017 at 3:01 PM Eleftherios Garyfallidis wrote: > Also, > > Demian informed me there is another DIPY related poster by > Rutger Fick # 1761 > > Best regards, > Eleftherios > > > On Sun, Apr 23, 2017 at 11:01 PM Eleftherios Garyfallidis < > elef at indiana.edu> wrote: > >> Hi all, >> >> Me, Julio and other DIPY contributors are in ISMRM in Honolulu. Here are >> some of our oral and poster numbers. >> >> Rafael Neto Henriques #1270, #1787 >> Stephan Meesters #3476 >> Tingyi Wanyan # 3497 >> Maryam Afzali # 3370 >> >> If you are using DIPY send us your abstract numbers. >> Nonetheless, it would be great to meet you all! >> >> Best regards, >> Eleftherios >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From njvack at wisc.edu Fri Apr 28 15:27:49 2017 From: njvack at wisc.edu (Nate Vack) Date: Fri, 28 Apr 2017 19:27:49 +0000 Subject: [Neuroimaging] OT: Anyone have a copy of Biopac Acqknowledge 5? Message-ID: Hi everyone, Sorry for the slightly off-topic nature of this post, but: I'm looking for someone who has a copy of AcqKnowledge 5 and would be willing to convert a few files for me. Please drop me a note off-list if you do and you would. Many thanks, -Nate -------------- next part -------------- An HTML attachment was scrubbed... URL: