From khamael at gmail.com Sat Jul 9 19:25:53 2016 From: khamael at gmail.com (paulo rodrigues) Date: Sat, 9 Jul 2016 19:25:53 -0400 Subject: [Neuroimaging] [position] Neuroimaging pipeline engineer Message-ID: *Job Description* -------------------------- You know dipy, nipype, ANTs, freesurfer, and all of that? The challenge is to develop analysis systems for multidimensional medical datasets that include imaging. Mint Labs is a SaaS platform that focus on integrating diverse clinical, imaging, genomic, and other data to better evaluate disease progression and response to interventions. You thrive in analyzing data, developing pipelines to process imaging data, and integrate multiple data points into meaningful group conclusions? You are experienced in volumetric, diffusion, rs-fMRI studies, and are not shy about Python, bash, R or whatever tool fits the work? *Objectives of the position * -------------------------- The position hinges on building sophisticated processing pipelines for neuroimaging datasets. Building, improving advanced connectomics and brain-parcellation techniques in dMRI / fMRI. Support the interaction with several external research partners and clients to develop neuroimaging analysis *About Mint Labs* -------------------------- Mint Labs is a Barcelona based building a neuroimaging data analytics cloud-based platform. system employs software tools to integrate thousands of images and data from a patient and creates a specific detailed 3D map of the brain. We can quantify the effect of the treatment in the damage of the brain and characterise patients for clinical trials. The images are directly sent from the scanners to our servers, and there the data is automatically processed and analysed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stjeansam at gmail.com Mon Jul 11 02:48:31 2016 From: stjeansam at gmail.com (Samuel St-Jean) Date: Mon, 11 Jul 2016 08:48:31 +0200 Subject: [Neuroimaging] [nibabel] sform/qform flipping left - right in the affine and (possibly) fsl In-Reply-To: References: <91ecab46-10b5-ef86-aedf-f8b3781beffa@gmail.com> Message-ID: <34725dc2-92fa-c72d-6714-39a8d6e25a31@gmail.com> So, if nibabel reads and write everything correctly, must be something down the fsl path doing non cool stuff. Question now is if I should bother fixing it and risk breaking stuff for other people as unseen side effects. At least I learned stuff, had no idea qform can not store all possible transformations, so that explains why it differs slightly from the sform after saving back. --------- And one week later (this above was an earlier draft) I got around to actually fix it, but I cannot explain why. If I save back the header with it, I do not experience the flip. If I tell nibabel to create an header because I did not pass anything, it seems to put back my data in RAS (think I saw this on the website, but I though it was only for internal representation). So, saving back header + I change the dtype manually (since the dtype from the header is used, which is almost always int16 to float32 for me) does not flip anything. Although I still can't figure out why the created header gives me flipped data, here is a small excerpt of said header. Nibabel saved back original header qform_name Scanner Anat qform_code 1 qto_xyz:1 -1.796652 0.000000 -0.000000 112.420448 qto_xyz:2 0.000000 1.795833 -0.054337 -90.885376 qto_xyz:3 0.000000 0.054236 1.799180 54.572971 qto_xyz:4 0.000000 0.000000 0.000000 1.000000 qform_xorient Right-to-Left qform_yorient Posterior-to-Anterior qform_zorient Inferior-to-Superior sform_name Scanner Anat sform_code 1 sto_xyz:1 -1.796652 0.000000 0.000000 112.420448 sto_xyz:2 0.000000 1.795833 -0.054337 -90.885376 sto_xyz:3 0.000000 0.054236 1.799180 54.572971 sto_xyz:4 0.000000 0.000000 0.000000 1.000000 sform_xorient Right-to-Left sform_yorient Posterior-to-Anterior sform_zorient Inferior-to-Superior Nibabel recreated header qform_name Unknown qform_code 0 qto_xyz:1 1.796652 0.000000 0.000000 0.000000 qto_xyz:2 0.000000 1.796652 0.000000 0.000000 qto_xyz:3 0.000000 0.000000 1.800000 0.000000 qto_xyz:4 0.000000 0.000000 0.000000 1.000000 qform_xorient Left-to-Right qform_yorient Posterior-to-Anterior qform_zorient Inferior-to-Superior sform_name Aligned Anat sform_code 2 sto_xyz:1 -1.796652 0.000000 0.000000 112.420448 sto_xyz:2 0.000000 1.795833 -0.054337 -90.885376 sto_xyz:3 0.000000 0.054236 1.799180 54.572971 sto_xyz:4 0.000000 0.000000 0.000000 1.000000 sform_xorient Right-to-Left sform_yorient Posterior-to-Anterior sform_zorient Inferior-to-Superior Notice how the qform has shearing in the first case (and original also), while it has flipped orientation and no shearing in the recreated header case. So, two questions : - Is there any adverse effect to using original headers if I know for certain nothing changed except dtype? - Well, I still can't figure out the flipping (is it the same when transformation would be applied in world space? So it still is flipped for all software in image space in this case then) or is that some nibabel RAS convention? I am still confused as to what happened to the orientation for the recreated header. Samuel P.S. Quick snippet to reproduce flipping with fslorient, adapt filename of course but any random nifti should work, this was diffusion data. Check header with fslhd afterwards. fslorient -swaporient 'out.nii.gz' In [1]: import nibabel as nib In [3]: vol=nib.load('out.nii.gz') In [4]: data=vol.get_data() In [5]: aff=vol.get_affine() In [6]: hdr=vol.get_header() In [7]: nib.save(nib.Nifti1Image(data,aff,hdr),'out2.nii.gz') In [8]: nib.save(nib.Nifti1Image(data,aff),'out3.nii.gz') 2016-06-28 15:13 GMT+02:00 Matthew Brett >: Hi, On Mon, Jun 27, 2016 at 11:50 PM, Samuel St-Jean > wrote: > I'll need to play a bit with it today and ask some guy about the flipping, I > am reporting for someone else actually. So, it seems to be harmless to put > back the header in the case of unchanged affine (as it is in my situation), > could be that other software downstream does not really like something else. > I did not reuse it because of dtypes, voxelsize and other things which may > wildly change on processed data. > > > Anyway, this example is using your case number 1, no header, affine is > gotten from get_affine. Of course it was not modified during the processing, > and I end up with a different sform/qform. Accoridng to your first point, I > expected them to be identical, but I end up with a sligthly different (and > diagonal) qform. They also have different names, so ifthey were set to the > same thing I would expect them to be pristine copies. > > That's a bit troublesome now as JC pointed out, since we all use the same > set of scripts for the heavy processing, which don't reuse headers as I can > remember. Does not seem to cause any problem for us, don't want to receive > hate mail by other people using some of our stuff and saying we broke their > data though. > > Are sform and qform set to match the affine in exactly the same way, or does > some transformation is applied and then they are identical? I went through > the info on the nibabel website about headers and affine, so maybe I just > missed it also if anyone has other info to add. Well - remember that the qform is stored differently from the sform. In particular, the qform cannot store shears, because it's the composition of the translations on a pure rotation on the zooms, whereas the sform can, because it stores a full 3 x 4 affine matrix. The sform and the qform will have different so-called "transform codes", if the sform and qform both get set (rules as described in my last email). This is because the default transform codes are different for the sform and qform, and we use the defaults. The flip should always be the same though, when the sform and qform get set together - at least if the external software is reading the header correctly. 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 Mon Jul 11 04:29:54 2016 From: matthew.brett at gmail.com (Matthew Brett) Date: Mon, 11 Jul 2016 01:29:54 -0700 Subject: [Neuroimaging] [nibabel] sform/qform flipping left - right in the affine and (possibly) fsl In-Reply-To: <34725dc2-92fa-c72d-6714-39a8d6e25a31@gmail.com> References: <91ecab46-10b5-ef86-aedf-f8b3781beffa@gmail.com> <34725dc2-92fa-c72d-6714-39a8d6e25a31@gmail.com> Message-ID: Hi, On Sun, Jul 10, 2016 at 11:48 PM, Samuel St-Jean wrote: > So, if nibabel reads and write everything correctly, must be something down > the fsl path doing non cool stuff. Question now is if I should bother fixing > it and risk breaking stuff for other people as unseen side effects. > At least I learned stuff, had no idea qform can not store all possible > transformations, so that explains why it differs slightly from the sform > after saving back. > > --------- > > And one week later (this above was an earlier draft) I got around to > actually fix it, but I cannot explain why. If I save back the header with > it, I do not experience the flip. If I tell nibabel to create an header > because I did not pass anything, it seems to put back my data in RAS (think > I saw this on the website, but I though it was only for internal > representation). > > So, saving back header + I change the dtype manually (since the dtype from > the header is used, which is almost always int16 to float32 for me) does not > flip anything. Although I still can't figure out why the created header > gives me flipped data, here is a small excerpt of said header. > > Nibabel saved back original header > > qform_name Scanner Anat > qform_code 1 > qto_xyz:1 -1.796652 0.000000 -0.000000 112.420448 > qto_xyz:2 0.000000 1.795833 -0.054337 -90.885376 > qto_xyz:3 0.000000 0.054236 1.799180 54.572971 > qto_xyz:4 0.000000 0.000000 0.000000 1.000000 > qform_xorient Right-to-Left > qform_yorient Posterior-to-Anterior > qform_zorient Inferior-to-Superior > sform_name Scanner Anat > sform_code 1 > sto_xyz:1 -1.796652 0.000000 0.000000 112.420448 > sto_xyz:2 0.000000 1.795833 -0.054337 -90.885376 > sto_xyz:3 0.000000 0.054236 1.799180 54.572971 > sto_xyz:4 0.000000 0.000000 0.000000 1.000000 > sform_xorient Right-to-Left > sform_yorient Posterior-to-Anterior > sform_zorient Inferior-to-Superior > > Nibabel recreated header > > > qform_name Unknown > qform_code 0 > qto_xyz:1 1.796652 0.000000 0.000000 0.000000 > qto_xyz:2 0.000000 1.796652 0.000000 0.000000 > qto_xyz:3 0.000000 0.000000 1.800000 0.000000 > qto_xyz:4 0.000000 0.000000 0.000000 1.000000 > qform_xorient Left-to-Right > qform_yorient Posterior-to-Anterior > qform_zorient Inferior-to-Superior > sform_name Aligned Anat > sform_code 2 > sto_xyz:1 -1.796652 0.000000 0.000000 112.420448 > sto_xyz:2 0.000000 1.795833 -0.054337 -90.885376 > sto_xyz:3 0.000000 0.054236 1.799180 54.572971 > sto_xyz:4 0.000000 0.000000 0.000000 1.000000 > sform_xorient Right-to-Left > sform_yorient Posterior-to-Anterior > sform_zorient Inferior-to-Superior > Notice how the qform has shearing in the first case (and original also), > while it has flipped orientation and no shearing in the recreated header > case. I don't think the qform does have shearing, it has a small rotation - see https://en.wikipedia.org/wiki/Rotation_matrix#Basic_rotations . Playing with nibabel and fsl, I think what is happening is the FSL is doing something weird to the qform, when the qform code is 0 - 'unknown'. The qform is correctly stored in the header, according to nibabel. This script: ``` import numpy as np np.set_printoptions(suppress=True, precision=4) import nibabel as nib aff = np.array([[-1.796652, 0.000000, 0.000000, 112.420448], [ 0.000000, 1.795833, -0.054337, -90.885376 ], [ 0.000000, 0.054236, 1.799180, 54.572971], [ 0.000000, 0.000000, 0.000000, 1.000000]]) data = np.zeros((2, 3, 4)) img = nib.Nifti1Image(data, aff) nib.save(img, 'out.nii') img2 = nib.load('out.nii') print(img2.get_qform()) ``` gives: [[ -1.7967 0. 0.0008 112.4204] [ -0. 1.7958 -0.0543 -90.8854] [ 0.0008 0.0542 1.7992 54.573 ] [ 0. 0. 0. 1. ]] whereas `fslhd` on the same file gives the same output as you got: qto_xyz:1 1.796652 0.000000 0.000000 0.000000 qto_xyz:2 0.000000 1.796652 0.000000 0.000000 qto_xyz:3 0.000000 0.000000 1.800000 0.000000 qto_xyz:4 0.000000 0.000000 0.000000 1.000000 > So, two questions : > - Is there any adverse effect to using original headers if I know for > certain nothing changed except dtype? Nothing that I can think of. > - Well, I still can't figure out the flipping (is it the same when > transformation would be applied in world space? So it still is flipped for > all software in image space in this case then) > or is that some nibabel RAS convention? I am still confused as to what > happened to the orientation for the recreated header. I think the difference must be in the interpretation that [whatever software shows the flip] gives to a header with a qform with code 0 (unknown). If you want to solve this, you might want to set the qform explicitly, with something like 'img.set_qform(affine, 'aligned')' before you save the image. Cheers, Matthew From stjeansam at gmail.com Mon Jul 11 04:59:46 2016 From: stjeansam at gmail.com (Samuel St-Jean) Date: Mon, 11 Jul 2016 10:59:46 +0200 Subject: [Neuroimaging] [nibabel] sform/qform flipping left - right in the affine and (possibly) fsl In-Reply-To: References: <91ecab46-10b5-ef86-aedf-f8b3781beffa@gmail.com> <34725dc2-92fa-c72d-6714-39a8d6e25a31@gmail.com> Message-ID: I guess I got my homogeneous coordinate wrong, haven't touched these in 5 years or so. I think in the end I'll go with saving the original header, that way I won't have to play with setting q-form name codes, even though it is still intact but misread. Should also prevent unforeseen weird stuff with other tools this way after all. If only everyone would follow the same conventions, one can dream I guess. I still wonder why fslhd changes the q-form that way, seems like they (unintentionally) flips the data themselves in their tools, guess I'll try asking them. Hopefully I won't get angry emails that now I flip people data when it was fine before though. Thanks for the detailed explanation. 2016-07-11 10:29 GMT+02:00 Matthew Brett : > Hi, > > On Sun, Jul 10, 2016 at 11:48 PM, Samuel St-Jean > wrote: > > So, if nibabel reads and write everything correctly, must be something > down > > the fsl path doing non cool stuff. Question now is if I should bother > fixing > > it and risk breaking stuff for other people as unseen side effects. > > At least I learned stuff, had no idea qform can not store all possible > > transformations, so that explains why it differs slightly from the sform > > after saving back. > > > > --------- > > > > And one week later (this above was an earlier draft) I got around to > > actually fix it, but I cannot explain why. If I save back the header with > > it, I do not experience the flip. If I tell nibabel to create an header > > because I did not pass anything, it seems to put back my data in RAS > (think > > I saw this on the website, but I though it was only for internal > > representation). > > > > So, saving back header + I change the dtype manually (since the dtype > from > > the header is used, which is almost always int16 to float32 for me) does > not > > flip anything. Although I still can't figure out why the created header > > gives me flipped data, here is a small excerpt of said header. > > > > Nibabel saved back original header > > > > qform_name Scanner Anat > > qform_code 1 > > qto_xyz:1 -1.796652 0.000000 -0.000000 112.420448 > > qto_xyz:2 0.000000 1.795833 -0.054337 -90.885376 > > qto_xyz:3 0.000000 0.054236 1.799180 54.572971 > > qto_xyz:4 0.000000 0.000000 0.000000 1.000000 > > qform_xorient Right-to-Left > > qform_yorient Posterior-to-Anterior > > qform_zorient Inferior-to-Superior > > sform_name Scanner Anat > > sform_code 1 > > sto_xyz:1 -1.796652 0.000000 0.000000 112.420448 > > sto_xyz:2 0.000000 1.795833 -0.054337 -90.885376 > > sto_xyz:3 0.000000 0.054236 1.799180 54.572971 > > sto_xyz:4 0.000000 0.000000 0.000000 1.000000 > > sform_xorient Right-to-Left > > sform_yorient Posterior-to-Anterior > > sform_zorient Inferior-to-Superior > > > > Nibabel recreated header > > > > > > qform_name Unknown > > qform_code 0 > > qto_xyz:1 1.796652 0.000000 0.000000 0.000000 > > qto_xyz:2 0.000000 1.796652 0.000000 0.000000 > > qto_xyz:3 0.000000 0.000000 1.800000 0.000000 > > qto_xyz:4 0.000000 0.000000 0.000000 1.000000 > > qform_xorient Left-to-Right > > qform_yorient Posterior-to-Anterior > > qform_zorient Inferior-to-Superior > > sform_name Aligned Anat > > sform_code 2 > > sto_xyz:1 -1.796652 0.000000 0.000000 112.420448 > > sto_xyz:2 0.000000 1.795833 -0.054337 -90.885376 > > sto_xyz:3 0.000000 0.054236 1.799180 54.572971 > > sto_xyz:4 0.000000 0.000000 0.000000 1.000000 > > sform_xorient Right-to-Left > > sform_yorient Posterior-to-Anterior > > sform_zorient Inferior-to-Superior > > > Notice how the qform has shearing in the first case (and original also), > > while it has flipped orientation and no shearing in the recreated header > > case. > > I don't think the qform does have shearing, it has a small rotation - > see https://en.wikipedia.org/wiki/Rotation_matrix#Basic_rotations . > > Playing with nibabel and fsl, I think what is happening is the FSL is > doing something weird to the qform, when the qform code is 0 - > 'unknown'. The qform is correctly stored in the header, according to > nibabel. This script: > > ``` > import numpy as np > np.set_printoptions(suppress=True, precision=4) > > import nibabel as nib > > aff = np.array([[-1.796652, 0.000000, 0.000000, 112.420448], > [ 0.000000, 1.795833, -0.054337, -90.885376 ], > [ 0.000000, 0.054236, 1.799180, 54.572971], > [ 0.000000, 0.000000, 0.000000, 1.000000]]) > data = np.zeros((2, 3, 4)) > > img = nib.Nifti1Image(data, aff) > nib.save(img, 'out.nii') > > img2 = nib.load('out.nii') > print(img2.get_qform()) > ``` > > gives: > > [[ -1.7967 0. 0.0008 112.4204] > [ -0. 1.7958 -0.0543 -90.8854] > [ 0.0008 0.0542 1.7992 54.573 ] > [ 0. 0. 0. 1. ]] > > whereas `fslhd` on the same file gives the same output as you got: > > qto_xyz:1 1.796652 0.000000 0.000000 0.000000 > qto_xyz:2 0.000000 1.796652 0.000000 0.000000 > qto_xyz:3 0.000000 0.000000 1.800000 0.000000 > qto_xyz:4 0.000000 0.000000 0.000000 1.000000 > > > So, two questions : > > - Is there any adverse effect to using original headers if I know for > > certain nothing changed except dtype? > > Nothing that I can think of. > > > - Well, I still can't figure out the flipping (is it the same when > > transformation would be applied in world space? So it still is flipped > for > > all software in image space in this case then) > > or is that some nibabel RAS convention? I am still confused as to what > > happened to the orientation for the recreated header. > > I think the difference must be in the interpretation that [whatever > software shows the flip] gives to a header with a qform with code 0 > (unknown). If you want to solve this, you might want to set the > qform explicitly, with something like 'img.set_qform(affine, > 'aligned')' before you save the image. > > 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 stefanv at berkeley.edu Tue Jul 12 02:09:49 2016 From: stefanv at berkeley.edu (=?UTF-8?Q?St=C3=A9fan_van_der_Walt?=) Date: Mon, 11 Jul 2016 23:09:49 -0700 Subject: [Neuroimaging] Spherical Bessel functions in SciPy Message-ID: >From the latest release notes: Vectorized forms of spherical Bessel functions have been implemented as `scipy.special.spherical_jn`, `scipy.special.spherical_kn`, `scipy.special.spherical_in` and `scipy.special.spherical_yn`. They are recommended for use over ``sph_*`` functions, which are now deprecated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Olaf.Hauk at mrc-cbu.cam.ac.uk Wed Jul 13 12:12:50 2016 From: Olaf.Hauk at mrc-cbu.cam.ac.uk (Olaf Hauk) Date: Wed, 13 Jul 2016 16:12:50 +0000 Subject: [Neuroimaging] post-doctoral position at MRC Cognition and Brain Sciences Unit Message-ID: MRC Cognition and Brain Sciences Unit - Cambridge Postdoctoral Scientist Salary ?27,355 - ?30,791 per annum plus benefits Ref OH/260 The MRC Cognition and Brain Sciences Unit (CBSU) is an internationally renowned research institute of cognitive neuroscience. Onsite facilities include dedicated MRI and MEG scanners, a hearing laboratory, and the developmental research centre suitable for infants through to older children. The CBSU is also a stakeholder in a clinical research facility and a new 7T ultra high field MRI scanner on the Addenbrooke's campus in Cambridge. An open-ended post-doctoral position is available in the Methods Team to support the optimisation, standardisation and development of fMRI data analysis pipelines, e.g. for standard fMRI time series analysis, functional and effective connectivity analysis, and multivariate pattern analysis. Methods support may extend to EEG/MEG analysis where appropriate. The successful candidate will also participate in a skills-oriented neuroimaging training programme aimed at PhD students and post-doctoral researchers. The position offers scope for independent research and methods development. You will have, or be in the final stages of, a PhD related to physics, signal processing, or neuroimaging methods. You should have experience in fMRI analysis, scientific computing (e.g. Linux, Matlab, Python), and an appreciation of methodological issues in cognitive brain imaging. Experience with MRI data acquisition and EEG and MEG methodology would be desirable. You will be thorough, efficient, effective, a good communicator, and enjoy working as part of a diverse and energetic, interdisciplinary team. Choosing to come to work at the MRC CBSU means that you will have access to a whole host of benefits from a final salary pension scheme, 30 days annual leave entitlement, flexible working arrangements, childcare vouchers, and additionally a salary sacrifice cycle scheme, as well as access to employee/shopping travel discounts. On site car and bicycle parking is available. We also provide a wide range of training opportunities to all our staff. Our success is dependent on our ability to embrace diversity and draw on the skills, understanding and experience of all our staff. As holders of an Athena SWAN bronze award we welcome applications from all sections of the community irrespective of gender, race, ethnic or national origin, religion or belief, sexual orientation, disability or age. As users of the "Two Ticks" disability symbol we guarantee to interview all applicants with disabilities who meet the minimum essential criteria for the post. For full details of this post and to complete an online application form visit https://mrc.tal.net/vx/lang-en-GB/appcentre-1/candidate/postings/280 and upload your CV along with a covering letter stating why you are applying for the post. Closing date: 9th August 2016 [https://encrypted-tbn1.gstatic.com/images?q=tbn:ANd9GcS606DGyDyDGODetutPc9bDKlXBNw0LLZz0u4DLt7WVhx0M6EHfug] [https://encrypted-tbn1.gstatic.com/images?q=tbn:ANd9GcS606DGyDyDGODetutPc9bDKlXBNw0LLZz0u4DLt7WVhx0M6EHfug] [https://encrypted-tbn1.gstatic.com/images?q=tbn:ANd9GcS606DGyDyDGODetutPc9bDKlXBNw0LLZz0u4DLt7WVhx0M6EHfug] [https://encrypted-tbn1.gstatic.com/images?q=tbn:ANd9GcS606DGyDyDGODetutPc9bDKlXBNw0LLZz0u4DLt7WVhx0M6EHfug] This position is subject to pre-employment screening The Medical Research Council is an Equal Opportunities Employer Olaf Hauk, PhD MRC Cognition and Brain Sciences Unit Phone: +44(0)1223 273702 Fax: +44(0)1223 359062 Web: http://www.mrc-cbu.cam.ac.uk/people/olaf.hauk/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 4946 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 1787 bytes Desc: image003.jpg URL: From antony at usc.edu Tue Jul 12 18:21:07 2016 From: antony at usc.edu (Jacob Antony) Date: Tue, 12 Jul 2016 15:21:07 -0700 Subject: [Neuroimaging] Dipy Error in ROI Streamlines and Tracking Message-ID: Hello, I am having issues with reading a trackvis file into the pipeline for ROI filtering: http://nipy.org/dipy/examples_built/streamline_tools.html I have checked the affine of the .trk file's header and it is [0 0 0 0; 0 0 0 0; 0 0 0 0; 0 0 0 1] However the .trk file and my DTI image have been registered together so they should have the same affine. Ultimately this leads to an error when I attempt to run utils.target ValueError: streamlines points are outside of target_mask This occurs when the include parameter is set to either true or false. What could be the issue? I have included a google drive with the T1 image, tractography file, corpus callosum mask, and the script I am using. https://drive.google.com/folderview?id=0B02Ea96nn-Igb0dYbU5QazRoMEE&usp=sharing Please let me know if you have an idea of what could be causing the error. Thank you all! Best, Jacob Antony -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Thu Jul 28 20:08:06 2016 From: matthew.brett at gmail.com (Matthew Brett) Date: Fri, 29 Jul 2016 01:08:06 +0100 Subject: [Neuroimaging] Nibabel release imminent Message-ID: Hi, I'd like to do a nibabel release soon. There are some ongoing PRs at the moment, most active being Thomas Emmerling's tireless work on BrainVoyager formats, but I'd like to release in the next week or so, to get out the new trackvis format stuff by Marc Alex Cote, as well as Alex Gramfort's fixes to the freesurfer surface reading. I just put in a PR https://github.com/nipy/nibabel/pull/464 to deal with some unchecked assumptions in the new spatial processing code - I'd be very happy of a review. Are there any other changes that people want to push for, for this next release? Cheers, Matthew From lists at onerussian.com Fri Jul 29 09:35:44 2016 From: lists at onerussian.com (Yaroslav Halchenko) Date: Fri, 29 Jul 2016 09:35:44 -0400 Subject: [Neuroimaging] Nibabel release imminent In-Reply-To: References: Message-ID: <20160729133544.GI22292@onerussian.com> On Fri, 29 Jul 2016, Matthew Brett wrote: > Hi, > I'd like to do a nibabel release soon. > There are some ongoing PRs at the moment, most active being Thomas > Emmerling's tireless work on BrainVoyager formats, but I'd like to > release in the next week or so, to get out the new trackvis format > stuff by Marc Alex Cote, as well as Alex Gramfort's fixes to the > freesurfer surface reading. > I just put in a PR https://github.com/nipy/nibabel/pull/464 to deal > with some unchecked assumptions in the new spatial processing code - > I'd be very happy of a review. > Are there any other changes that people want to push for, for this next release? FWIW, builds/tests seems pass ok across majority of Debian/Ubuntus (on 12.04 need to do more dancing around mpl to test). I would really appreciate feedback on my "selfish" idea: https://github.com/nipy/nibabel/pull/466 -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik From marc.cote.19 at gmail.com Fri Jul 29 11:39:41 2016 From: marc.cote.19 at gmail.com (=?UTF-8?B?TWFyYy1BbGV4YW5kcmUgQ8O0dMOp?=) Date: Fri, 29 Jul 2016 11:39:41 -0400 Subject: [Neuroimaging] Nibabel release imminent In-Reply-To: References: Message-ID: <5584e7b7-ae5a-747a-b60b-1e9a62fa5262@gmail.com> How soon would that be? I have a branch that adds support for another streamlines file format: TCK (from MRtrix). I'm using it since April so I had time to debug it plenty but it is still missing some unit tests. I won't be able to make a proper PR before August 9th, would it be too late then? Cheers, Marc On 16-07-28 08:08 PM, Matthew Brett wrote: > Hi, > > I'd like to do a nibabel release soon. > > There are some ongoing PRs at the moment, most active being Thomas > Emmerling's tireless work on BrainVoyager formats, but I'd like to > release in the next week or so, to get out the new trackvis format > stuff by Marc Alex Cote, as well as Alex Gramfort's fixes to the > freesurfer surface reading. > > I just put in a PR https://github.com/nipy/nibabel/pull/464 to deal > with some unchecked assumptions in the new spatial processing code - > I'd be very happy of a review. > > Are there any other changes that people want to push for, for this next release? > > Cheers, > > Matthew > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging From helmer at nmr.mgh.harvard.edu Fri Jul 29 12:24:48 2016 From: helmer at nmr.mgh.harvard.edu (Karl Helmer) Date: Fri, 29 Jul 2016 12:24:48 -0400 (EDT) Subject: [Neuroimaging] nibabel / pkg_resources /setuptools question Message-ID: <35554.71.174.1.104.1469809488.squirrel@mail.nmr.mgh.harvard.edu> Hi Everyone, I've just started to get the error message below when I "import nibabel" in a piece of code. I've just updated my anaconda, but was getting the error before then, and also used apt-get to get the latest python-nipype (that apt-get has anyway). I'm using Lubuntu: DISTRIB_DESCRIPTION="Ubuntu 14.04.4 LTS" and this is what it installed: "Preparing to unpack .../python-nibabel_2.0.2-1~nd14.04+1_all.deb ... Unpacking python-nibabel (2.0.2-1~nd14.04+1) ..." ... Setting up python-nibabel (2.0.2-1~nd14.04+1) ... It looks like it's not nibabel it's unhappy with, it's the setuptools version or maybe the interaction between the two? Has anyone seen this and have a fix? thanks, Karl --------------------------------------------------------- Traceback (most recent call last): File "edited_histograms.py", line 24, in import nibabel as nib File "/home/karl/anaconda/lib/python2.7/site-packages/nibabel/__init__.py", line 45, in from .loadsave import load, save File "/home/karl/anaconda/lib/python2.7/site-packages/nibabel/loadsave.py", line 21, in from .minc2 import Minc2Image File "/home/karl/anaconda/lib/python2.7/site-packages/nibabel/minc2.py", line 30, in from .optpkg import optional_package File "/home/karl/anaconda/lib/python2.7/site-packages/nibabel/optpkg.py", line 4, in import nose File "/home/karl/anaconda/lib/python2.7/site-packages/nose/__init__.py", line 1, in from nose.core import collector, main, run, run_exit, runmodule File "/home/karl/anaconda/lib/python2.7/site-packages/nose/core.py", line 11, in from nose.config import Config, all_config_files File "/home/karl/anaconda/lib/python2.7/site-packages/nose/config.py", line 9, in from nose.plugins.manager import NoPlugins File "/home/karl/anaconda/lib/python2.7/site-packages/nose/plugins/__init__.py", line 185, in from nose.plugins.manager import * File "/home/karl/anaconda/lib/python2.7/site-packages/nose/plugins/manager.py", line 418, in import pkg_resources File "/home/karl/anaconda/lib/python2.7/site-packages/distribute-0.6.17-py2.7.egg/pkg_resources.py", line 2729, in add_activation_listener(lambda dist: dist.activate()) File "/home/karl/anaconda/lib/python2.7/site-packages/distribute-0.6.17-py2.7.egg/pkg_resources.py", line 700, in subscribe callback(dist) File "/home/karl/anaconda/lib/python2.7/site-packages/distribute-0.6.17-py2.7.egg/pkg_resources.py", line 2729, in add_activation_listener(lambda dist: dist.activate()) File "/home/karl/anaconda/lib/python2.7/site-packages/distribute-0.6.17-py2.7.egg/pkg_resources.py", line 2229, in activate self.insert_on(path) File "/home/karl/anaconda/lib/python2.7/site-packages/distribute-0.6.17-py2.7.egg/pkg_resources.py", line 2330, in insert_on "with distribute. Found one at %s" % str(self.location)) ValueError: A 0.7-series setuptools cannot be installed with distribute. Found one at /home/karl/anaconda/lib/python2.7/site-packages/setuptools-20.7.0-py2.7.egg -- Karl Helmer, PhD Athinoula A Martinos Center for Biomedical Imaging Massachusetts General Hospital 149 - 13th St Room 2301 Charlestown, MA 02129 (p) 617.726.8636 (f) 617.726.7422 helmer at nmr.mgh.harvard.edu 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 matthew.brett at gmail.com Fri Jul 29 12:37:16 2016 From: matthew.brett at gmail.com (Matthew Brett) Date: Fri, 29 Jul 2016 17:37:16 +0100 Subject: [Neuroimaging] nibabel / pkg_resources /setuptools question In-Reply-To: <35554.71.174.1.104.1469809488.squirrel@mail.nmr.mgh.harvard.edu> References: <35554.71.174.1.104.1469809488.squirrel@mail.nmr.mgh.harvard.edu> Message-ID: Hi, On Fri, Jul 29, 2016 at 5:24 PM, Karl Helmer wrote: > Hi Everyone, > > I've just started to get the error message below when I "import > nibabel" in a piece of code. I've just updated my anaconda, but was > getting the error before then, and also used apt-get to get the latest > python-nipype (that apt-get has anyway). I'm using Lubuntu: > DISTRIB_DESCRIPTION="Ubuntu 14.04.4 LTS" > and this is what it installed: > "Preparing to unpack .../python-nibabel_2.0.2-1~nd14.04+1_all.deb ... > Unpacking python-nibabel (2.0.2-1~nd14.04+1) ..." > ... > Setting up python-nibabel (2.0.2-1~nd14.04+1) ... > > It looks like it's not nibabel it's unhappy with, it's the setuptools > version or maybe the interaction between the two? Has anyone seen this > and have a fix? > > thanks, > Karl > --------------------------------------------------------- > > Traceback (most recent call last): > File "edited_histograms.py", line 24, in > import nibabel as nib > File > "/home/karl/anaconda/lib/python2.7/site-packages/nibabel/__init__.py", > line 45, in > from .loadsave import load, save > File > "/home/karl/anaconda/lib/python2.7/site-packages/nibabel/loadsave.py", > line 21, in > from .minc2 import Minc2Image > File "/home/karl/anaconda/lib/python2.7/site-packages/nibabel/minc2.py", > line 30, in > from .optpkg import optional_package > File > "/home/karl/anaconda/lib/python2.7/site-packages/nibabel/optpkg.py", > line 4, in > import nose > File "/home/karl/anaconda/lib/python2.7/site-packages/nose/__init__.py", > line 1, in > from nose.core import collector, main, run, run_exit, runmodule > File "/home/karl/anaconda/lib/python2.7/site-packages/nose/core.py", > line 11, in > from nose.config import Config, all_config_files > File "/home/karl/anaconda/lib/python2.7/site-packages/nose/config.py", > line 9, in > from nose.plugins.manager import NoPlugins > File > "/home/karl/anaconda/lib/python2.7/site-packages/nose/plugins/__init__.py", > line 185, in > from nose.plugins.manager import * > File > "/home/karl/anaconda/lib/python2.7/site-packages/nose/plugins/manager.py", > line 418, in > import pkg_resources > File > "/home/karl/anaconda/lib/python2.7/site-packages/distribute-0.6.17-py2.7.egg/pkg_resources.py", > line 2729, in > add_activation_listener(lambda dist: dist.activate()) > File > "/home/karl/anaconda/lib/python2.7/site-packages/distribute-0.6.17-py2.7.egg/pkg_resources.py", > line 700, in subscribe > callback(dist) > File > "/home/karl/anaconda/lib/python2.7/site-packages/distribute-0.6.17-py2.7.egg/pkg_resources.py", > line 2729, in > add_activation_listener(lambda dist: dist.activate()) > File > "/home/karl/anaconda/lib/python2.7/site-packages/distribute-0.6.17-py2.7.egg/pkg_resources.py", > line 2229, in activate > self.insert_on(path) > File > "/home/karl/anaconda/lib/python2.7/site-packages/distribute-0.6.17-py2.7.egg/pkg_resources.py", > line 2330, in insert_on > "with distribute. Found one at %s" % str(self.location)) > ValueError: A 0.7-series setuptools cannot be installed with distribute. > Found one at > /home/karl/anaconda/lib/python2.7/site-packages/setuptools-20.7.0-py2.7.egg That's a frightening mix of apt-get, neurodebian and anaconda! Have you also been using easy_install by any chance? I see that your setuptools and distribute packages are in .egg directories. If it were me, I would start by clearing out the easy_install installs, as these can make a real mess of your imports - does https://matthew-brett.github.io/pydagogue/un_easy_install.html help? (you need to look in your anaconda directory rather than the system directories, I suspect). Do you need anaconda for anything specific, not covered by neurodebian? I suspect your life would be simpler if you could use either `apt-get` or `conda` and not both. Cheers, Matthew From satra at mit.edu Fri Jul 29 12:56:07 2016 From: satra at mit.edu (Satrajit Ghosh) Date: Fri, 29 Jul 2016 12:56:07 -0400 Subject: [Neuroimaging] nibabel / pkg_resources /setuptools question In-Reply-To: References: <35554.71.174.1.104.1469809488.squirrel@mail.nmr.mgh.harvard.edu> Message-ID: hi karl, if you are using conda through miniconda/anaconda, you may consider adding conda-forge channels. conda config --add channels conda-forge conda install nibabel # or nipype or dipy or any one of these packages: https://conda-forge.github.io/feedstocks.html it is a community supported package repository for conda. i agree with matthew that it would be good not to mix apt-get and anaconda. cheers, satra On Fri, Jul 29, 2016 at 12:37 PM, Matthew Brett wrote: > Hi, > > On Fri, Jul 29, 2016 at 5:24 PM, Karl Helmer > wrote: > > Hi Everyone, > > > > I've just started to get the error message below when I "import > > nibabel" in a piece of code. I've just updated my anaconda, but was > > getting the error before then, and also used apt-get to get the latest > > python-nipype (that apt-get has anyway). I'm using Lubuntu: > > DISTRIB_DESCRIPTION="Ubuntu 14.04.4 LTS" > > and this is what it installed: > > "Preparing to unpack .../python-nibabel_2.0.2-1~nd14.04+1_all.deb ... > > Unpacking python-nibabel (2.0.2-1~nd14.04+1) ..." > > ... > > Setting up python-nibabel (2.0.2-1~nd14.04+1) ... > > > > It looks like it's not nibabel it's unhappy with, it's the setuptools > > version or maybe the interaction between the two? Has anyone seen this > > and have a fix? > > > > thanks, > > Karl > > --------------------------------------------------------- > > > > Traceback (most recent call last): > > File "edited_histograms.py", line 24, in > > import nibabel as nib > > File > > "/home/karl/anaconda/lib/python2.7/site-packages/nibabel/__init__.py", > > line 45, in > > from .loadsave import load, save > > File > > "/home/karl/anaconda/lib/python2.7/site-packages/nibabel/loadsave.py", > > line 21, in > > from .minc2 import Minc2Image > > File > "/home/karl/anaconda/lib/python2.7/site-packages/nibabel/minc2.py", > > line 30, in > > from .optpkg import optional_package > > File > > "/home/karl/anaconda/lib/python2.7/site-packages/nibabel/optpkg.py", > > line 4, in > > import nose > > File > "/home/karl/anaconda/lib/python2.7/site-packages/nose/__init__.py", > > line 1, in > > from nose.core import collector, main, run, run_exit, runmodule > > File "/home/karl/anaconda/lib/python2.7/site-packages/nose/core.py", > > line 11, in > > from nose.config import Config, all_config_files > > File "/home/karl/anaconda/lib/python2.7/site-packages/nose/config.py", > > line 9, in > > from nose.plugins.manager import NoPlugins > > File > > > "/home/karl/anaconda/lib/python2.7/site-packages/nose/plugins/__init__.py", > > line 185, in > > from nose.plugins.manager import * > > File > > > "/home/karl/anaconda/lib/python2.7/site-packages/nose/plugins/manager.py", > > line 418, in > > import pkg_resources > > File > > > "/home/karl/anaconda/lib/python2.7/site-packages/distribute-0.6.17-py2.7.egg/pkg_resources.py", > > line 2729, in > > add_activation_listener(lambda dist: dist.activate()) > > File > > > "/home/karl/anaconda/lib/python2.7/site-packages/distribute-0.6.17-py2.7.egg/pkg_resources.py", > > line 700, in subscribe > > callback(dist) > > File > > > "/home/karl/anaconda/lib/python2.7/site-packages/distribute-0.6.17-py2.7.egg/pkg_resources.py", > > line 2729, in > > add_activation_listener(lambda dist: dist.activate()) > > File > > > "/home/karl/anaconda/lib/python2.7/site-packages/distribute-0.6.17-py2.7.egg/pkg_resources.py", > > line 2229, in activate > > self.insert_on(path) > > File > > > "/home/karl/anaconda/lib/python2.7/site-packages/distribute-0.6.17-py2.7.egg/pkg_resources.py", > > line 2330, in insert_on > > "with distribute. Found one at %s" % str(self.location)) > > ValueError: A 0.7-series setuptools cannot be installed with distribute. > > Found one at > > > /home/karl/anaconda/lib/python2.7/site-packages/setuptools-20.7.0-py2.7.egg > > That's a frightening mix of apt-get, neurodebian and anaconda! > > Have you also been using easy_install by any chance? I see that your > setuptools and distribute packages are in .egg directories. > > If it were me, I would start by clearing out the easy_install > installs, as these can make a real mess of your imports - does > https://matthew-brett.github.io/pydagogue/un_easy_install.html help? > (you need to look in your anaconda directory rather than the system > directories, I suspect). > > Do you need anaconda for anything specific, not covered by > neurodebian? I suspect your life would be simpler if you could use > either `apt-get` or `conda` and not both. > > 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 helmer at nmr.mgh.harvard.edu Fri Jul 29 14:44:54 2016 From: helmer at nmr.mgh.harvard.edu (Karl Helmer) Date: Fri, 29 Jul 2016 14:44:54 -0400 (EDT) Subject: [Neuroimaging] nibabel / pkg_resources /setuptools question In-Reply-To: References: <35554.71.174.1.104.1469809488.squirrel@mail.nmr.mgh.harvard.edu> Message-ID: <63187.71.174.1.104.1469817894.squirrel@mail.nmr.mgh.harvard.edu> Thanks for the suggestion Matthew. I cleaned out all of the .egg packages and reinstalled from pip. Once I did that for setuptools, all was well again. regards, Karl > Hi, > > On Fri, Jul 29, 2016 at 5:24 PM, Karl Helmer > wrote: >> Hi Everyone, >> >> I've just started to get the error message below when I "import >> nibabel" in a piece of code. I've just updated my anaconda, but was >> getting the error before then, and also used apt-get to get the latest >> python-nipype (that apt-get has anyway). I'm using Lubuntu: >> DISTRIB_DESCRIPTION="Ubuntu 14.04.4 LTS" >> and this is what it installed: >> "Preparing to unpack .../python-nibabel_2.0.2-1~nd14.04+1_all.deb ... >> Unpacking python-nibabel (2.0.2-1~nd14.04+1) ..." >> ... >> Setting up python-nibabel (2.0.2-1~nd14.04+1) ... >> >> It looks like it's not nibabel it's unhappy with, it's the setuptools >> version or maybe the interaction between the two? Has anyone seen this >> and have a fix? >> >> thanks, >> Karl >> --------------------------------------------------------- >> >> Traceback (most recent call last): >> File "edited_histograms.py", line 24, in >> import nibabel as nib >> File >> "/home/karl/anaconda/lib/python2.7/site-packages/nibabel/__init__.py", >> line 45, in >> from .loadsave import load, save >> File >> "/home/karl/anaconda/lib/python2.7/site-packages/nibabel/loadsave.py", >> line 21, in >> from .minc2 import Minc2Image >> File >> "/home/karl/anaconda/lib/python2.7/site-packages/nibabel/minc2.py", >> line 30, in >> from .optpkg import optional_package >> File >> "/home/karl/anaconda/lib/python2.7/site-packages/nibabel/optpkg.py", >> line 4, in >> import nose >> File >> "/home/karl/anaconda/lib/python2.7/site-packages/nose/__init__.py", >> line 1, in >> from nose.core import collector, main, run, run_exit, runmodule >> File "/home/karl/anaconda/lib/python2.7/site-packages/nose/core.py", >> line 11, in >> from nose.config import Config, all_config_files >> File "/home/karl/anaconda/lib/python2.7/site-packages/nose/config.py", >> line 9, in >> from nose.plugins.manager import NoPlugins >> File >> "/home/karl/anaconda/lib/python2.7/site-packages/nose/plugins/__init__.py", >> line 185, in >> from nose.plugins.manager import * >> File >> "/home/karl/anaconda/lib/python2.7/site-packages/nose/plugins/manager.py", >> line 418, in >> import pkg_resources >> File >> "/home/karl/anaconda/lib/python2.7/site-packages/distribute-0.6.17-py2.7.egg/pkg_resources.py", >> line 2729, in >> add_activation_listener(lambda dist: dist.activate()) >> File >> "/home/karl/anaconda/lib/python2.7/site-packages/distribute-0.6.17-py2.7.egg/pkg_resources.py", >> line 700, in subscribe >> callback(dist) >> File >> "/home/karl/anaconda/lib/python2.7/site-packages/distribute-0.6.17-py2.7.egg/pkg_resources.py", >> line 2729, in >> add_activation_listener(lambda dist: dist.activate()) >> File >> "/home/karl/anaconda/lib/python2.7/site-packages/distribute-0.6.17-py2.7.egg/pkg_resources.py", >> line 2229, in activate >> self.insert_on(path) >> File >> "/home/karl/anaconda/lib/python2.7/site-packages/distribute-0.6.17-py2.7.egg/pkg_resources.py", >> line 2330, in insert_on >> "with distribute. Found one at %s" % str(self.location)) >> ValueError: A 0.7-series setuptools cannot be installed with distribute. >> Found one at >> /home/karl/anaconda/lib/python2.7/site-packages/setuptools-20.7.0-py2.7.egg > > That's a frightening mix of apt-get, neurodebian and anaconda! > > Have you also been using easy_install by any chance? I see that your > setuptools and distribute packages are in .egg directories. > > If it were me, I would start by clearing out the easy_install > installs, as these can make a real mess of your imports - does > https://matthew-brett.github.io/pydagogue/un_easy_install.html help? > (you need to look in your anaconda directory rather than the system > directories, I suspect). > > Do you need anaconda for anything specific, not covered by > neurodebian? I suspect your life would be simpler if you could use > either `apt-get` or `conda` and not both. > > Cheers, > > Matthew > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > > -- Karl Helmer, PhD Athinoula A Martinos Center for Biomedical Imaging Massachusetts General Hospital 149 - 13th St Room 2301 Charlestown, MA 02129 (p) 617.726.8636 (f) 617.726.7422 helmer at nmr.mgh.harvard.edu 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 helmer at nmr.mgh.harvard.edu Fri Jul 29 14:50:27 2016 From: helmer at nmr.mgh.harvard.edu (Karl Helmer) Date: Fri, 29 Jul 2016 14:50:27 -0400 (EDT) Subject: [Neuroimaging] nibabel / pkg_resources /setuptools question In-Reply-To: References: <35554.71.174.1.104.1469809488.squirrel@mail.nmr.mgh.harvard.edu> Message-ID: <63210.71.174.1.104.1469818227.squirrel@mail.nmr.mgh.harvard.edu> Thanks Satra for the link, I'll reinstall using that to make sure. regards, Karl > hi karl, > > if you are using conda through miniconda/anaconda, you may consider adding > conda-forge channels. > > conda config --add channels conda-forge > > conda install nibabel # or nipype or dipy > > or any one of these packages: > https://conda-forge.github.io/feedstocks.html > > it is a community supported package repository for conda. > > i agree with matthew that it would be good not to mix apt-get and > anaconda. > > cheers, > > satra > > On Fri, Jul 29, 2016 at 12:37 PM, Matthew Brett > wrote: > >> Hi, >> >> On Fri, Jul 29, 2016 at 5:24 PM, Karl Helmer >> >> wrote: >> > Hi Everyone, >> > >> > I've just started to get the error message below when I "import >> > nibabel" in a piece of code. I've just updated my anaconda, but was >> > getting the error before then, and also used apt-get to get the latest >> > python-nipype (that apt-get has anyway). I'm using Lubuntu: >> > DISTRIB_DESCRIPTION="Ubuntu 14.04.4 LTS" >> > and this is what it installed: >> > "Preparing to unpack .../python-nibabel_2.0.2-1~nd14.04+1_all.deb ... >> > Unpacking python-nibabel (2.0.2-1~nd14.04+1) ..." >> > ... >> > Setting up python-nibabel (2.0.2-1~nd14.04+1) ... >> > >> > It looks like it's not nibabel it's unhappy with, it's the setuptools >> > version or maybe the interaction between the two? Has anyone seen >> this >> > and have a fix? >> > >> > thanks, >> > Karl >> > --------------------------------------------------------- >> > >> > Traceback (most recent call last): >> > File "edited_histograms.py", line 24, in >> > import nibabel as nib >> > File >> > "/home/karl/anaconda/lib/python2.7/site-packages/nibabel/__init__.py", >> > line 45, in >> > from .loadsave import load, save >> > File >> > "/home/karl/anaconda/lib/python2.7/site-packages/nibabel/loadsave.py", >> > line 21, in >> > from .minc2 import Minc2Image >> > File >> "/home/karl/anaconda/lib/python2.7/site-packages/nibabel/minc2.py", >> > line 30, in >> > from .optpkg import optional_package >> > File >> > "/home/karl/anaconda/lib/python2.7/site-packages/nibabel/optpkg.py", >> > line 4, in >> > import nose >> > File >> "/home/karl/anaconda/lib/python2.7/site-packages/nose/__init__.py", >> > line 1, in >> > from nose.core import collector, main, run, run_exit, runmodule >> > File "/home/karl/anaconda/lib/python2.7/site-packages/nose/core.py", >> > line 11, in >> > from nose.config import Config, all_config_files >> > File >> "/home/karl/anaconda/lib/python2.7/site-packages/nose/config.py", >> > line 9, in >> > from nose.plugins.manager import NoPlugins >> > File >> > >> "/home/karl/anaconda/lib/python2.7/site-packages/nose/plugins/__init__.py", >> > line 185, in >> > from nose.plugins.manager import * >> > File >> > >> "/home/karl/anaconda/lib/python2.7/site-packages/nose/plugins/manager.py", >> > line 418, in >> > import pkg_resources >> > File >> > >> "/home/karl/anaconda/lib/python2.7/site-packages/distribute-0.6.17-py2.7.egg/pkg_resources.py", >> > line 2729, in >> > add_activation_listener(lambda dist: dist.activate()) >> > File >> > >> "/home/karl/anaconda/lib/python2.7/site-packages/distribute-0.6.17-py2.7.egg/pkg_resources.py", >> > line 700, in subscribe >> > callback(dist) >> > File >> > >> "/home/karl/anaconda/lib/python2.7/site-packages/distribute-0.6.17-py2.7.egg/pkg_resources.py", >> > line 2729, in >> > add_activation_listener(lambda dist: dist.activate()) >> > File >> > >> "/home/karl/anaconda/lib/python2.7/site-packages/distribute-0.6.17-py2.7.egg/pkg_resources.py", >> > line 2229, in activate >> > self.insert_on(path) >> > File >> > >> "/home/karl/anaconda/lib/python2.7/site-packages/distribute-0.6.17-py2.7.egg/pkg_resources.py", >> > line 2330, in insert_on >> > "with distribute. Found one at %s" % str(self.location)) >> > ValueError: A 0.7-series setuptools cannot be installed with >> distribute. >> > Found one at >> > >> /home/karl/anaconda/lib/python2.7/site-packages/setuptools-20.7.0-py2.7.egg >> >> That's a frightening mix of apt-get, neurodebian and anaconda! >> >> Have you also been using easy_install by any chance? I see that your >> setuptools and distribute packages are in .egg directories. >> >> If it were me, I would start by clearing out the easy_install >> installs, as these can make a real mess of your imports - does >> https://matthew-brett.github.io/pydagogue/un_easy_install.html help? >> (you need to look in your anaconda directory rather than the system >> directories, I suspect). >> >> Do you need anaconda for anything specific, not covered by >> neurodebian? I suspect your life would be simpler if you could use >> either `apt-get` or `conda` and not both. >> >> 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 > -- Karl Helmer, PhD Athinoula A Martinos Center for Biomedical Imaging Massachusetts General Hospital 149 - 13th St Room 2301 Charlestown, MA 02129 (p) 617.726.8636 (f) 617.726.7422 helmer at nmr.mgh.harvard.edu 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 lists at onerussian.com Fri Jul 29 20:44:30 2016 From: lists at onerussian.com (Yaroslav Halchenko) Date: Fri, 29 Jul 2016 20:44:30 -0400 Subject: [Neuroimaging] Nibabel release imminent In-Reply-To: <20160729133544.GI22292@onerussian.com> References: <20160729133544.GI22292@onerussian.com> Message-ID: <20160730004430.GQ22292@onerussian.com> On Fri, 29 Jul 2016, Yaroslav Halchenko wrote: > > I just put in a PR https://github.com/nipy/nibabel/pull/464 to deal > > with some unchecked assumptions in the new spatial processing code - > > I'd be very happy of a review. > > Are there any other changes that people want to push for, for this next release? > FWIW, builds/tests seems pass ok across majority of Debian/Ubuntus (on > 12.04 need to do more dancing around mpl to test). > I would really appreciate feedback on my "selfish" idea: > https://github.com/nipy/nibabel/pull/466 some detected changes in behaviour of nibabel are detected within pymvpa tests... yet to look in details ====================================================================== ERROR: test_surf_gifti (mvpa2.tests.test_surfing.SurfTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/build/pymvpa2-2.3.1/debian/tmp/usr/lib/python2.7/dist-packages/mvpa2/testing/tools.py", line 165, in newfunc func(*(arg + (filename,)), **kw) File "/build/pymvpa2-2.3.1/debian/tmp/usr/lib/python2.7/dist-packages/mvpa2/tests/test_surfing.py", line 1081, in test_surf_gifti surf.write(fn, s) File "/build/pymvpa2-2.3.1/debian/tmp/usr/lib/python2.7/dist-packages/mvpa2/support/nibabel/surf.py", line 2229, in write surf_gifti.write(fn, s, overwrite=overwrite) File "/build/pymvpa2-2.3.1/debian/tmp/usr/lib/python2.7/dist-packages/mvpa2/support/nibabel/surf_gifti.py", line 254, in write xml = to_xml(s, fn) File "/build/pymvpa2-2.3.1/debian/tmp/usr/lib/python2.7/dist-packages/mvpa2/support/nibabel/surf_gifti.py", line 203, in to_xml img = to_gifti_image(img) File "/build/pymvpa2-2.3.1/debian/tmp/usr/lib/python2.7/dist-packages/mvpa2/support/nibabel/surf_gifti.py", line 162, in to_gifti_image arr.num_dim = len(arr.dims) AttributeError: can't set attribute ====================================================================== FAIL: mvpa2.tests.test_niftidataset.test_assumptions_on_nibabel_behavior ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/build/pymvpa2-2.3.1/debian/tmp/usr/lib/python2.7/dist-packages/mvpa2/testing/tools.py", line 165, in newfunc func(*(arg + (filename,)), **kw) File "/build/pymvpa2-2.3.1/debian/tmp/usr/lib/python2.7/dist-packages/mvpa2/tests/test_niftidataset.py", line 425, in test_assumptions_on_nibabel_behavior assert_equal(slope, 1.0) AssertionError: None != 1.0 -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik From matthew.brett at gmail.com Fri Jul 29 21:12:11 2016 From: matthew.brett at gmail.com (Matthew Brett) Date: Sat, 30 Jul 2016 02:12:11 +0100 Subject: [Neuroimaging] Nibabel release imminent In-Reply-To: <20160730004430.GQ22292@onerussian.com> References: <20160729133544.GI22292@onerussian.com> <20160730004430.GQ22292@onerussian.com> Message-ID: Hi, On Sat, Jul 30, 2016 at 1:44 AM, Yaroslav Halchenko wrote: > > On Fri, 29 Jul 2016, Yaroslav Halchenko wrote: > >> > I just put in a PR https://github.com/nipy/nibabel/pull/464 to deal >> > with some unchecked assumptions in the new spatial processing code - >> > I'd be very happy of a review. > >> > Are there any other changes that people want to push for, for this next release? > >> FWIW, builds/tests seems pass ok across majority of Debian/Ubuntus (on >> 12.04 need to do more dancing around mpl to test). > >> I would really appreciate feedback on my "selfish" idea: >> https://github.com/nipy/nibabel/pull/466 > > some detected changes in behaviour of nibabel are detected within pymvpa > tests... yet to look in details > > ====================================================================== > ERROR: test_surf_gifti (mvpa2.tests.test_surfing.SurfTests) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/build/pymvpa2-2.3.1/debian/tmp/usr/lib/python2.7/dist-packages/mvpa2/testing/tools.py", line 165, in newfunc > func(*(arg + (filename,)), **kw) > File "/build/pymvpa2-2.3.1/debian/tmp/usr/lib/python2.7/dist-packages/mvpa2/tests/test_surfing.py", line 1081, in test_surf_gifti > surf.write(fn, s) > File "/build/pymvpa2-2.3.1/debian/tmp/usr/lib/python2.7/dist-packages/mvpa2/support/nibabel/surf.py", line 2229, in write > surf_gifti.write(fn, s, overwrite=overwrite) > File "/build/pymvpa2-2.3.1/debian/tmp/usr/lib/python2.7/dist-packages/mvpa2/support/nibabel/surf_gifti.py", line 254, in write > xml = to_xml(s, fn) > File "/build/pymvpa2-2.3.1/debian/tmp/usr/lib/python2.7/dist-packages/mvpa2/support/nibabel/surf_gifti.py", line 203, in to_xml > img = to_gifti_image(img) > File "/build/pymvpa2-2.3.1/debian/tmp/usr/lib/python2.7/dist-packages/mvpa2/support/nibabel/surf_gifti.py", line 162, in to_gifti_image > arr.num_dim = len(arr.dims) > AttributeError: can't set attribute The GiftiDataArray object now has `num_dims` as a property. We could add a setter that raises an error if the value is not as expected, and a deprecation warning otherwise - OK with you? > ====================================================================== > FAIL: mvpa2.tests.test_niftidataset.test_assumptions_on_nibabel_behavior > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest > self.test(*self.arg) > File "/build/pymvpa2-2.3.1/debian/tmp/usr/lib/python2.7/dist-packages/mvpa2/testing/tools.py", line 165, in newfunc > func(*(arg + (filename,)), **kw) > File "/build/pymvpa2-2.3.1/debian/tmp/usr/lib/python2.7/dist-packages/mvpa2/tests/test_niftidataset.py", line 425, in test_assumptions_on_nibabel_behavior > assert_equal(slope, 1.0) > AssertionError: None != 1.0 Does this one work on current released nibabel? This behavior changed before version 2 as I remember - the slope and intercept are recorded as None in the header by default, after reading. Cheers, Matthew From matthew.brett at gmail.com Fri Jul 29 21:23:12 2016 From: matthew.brett at gmail.com (Matthew Brett) Date: Sat, 30 Jul 2016 02:23:12 +0100 Subject: [Neuroimaging] Nibabel release imminent In-Reply-To: References: <20160729133544.GI22292@onerussian.com> <20160730004430.GQ22292@onerussian.com> Message-ID: On Sat, Jul 30, 2016 at 2:12 AM, Matthew Brett wrote: > Hi, > > On Sat, Jul 30, 2016 at 1:44 AM, Yaroslav Halchenko > wrote: >> >> On Fri, 29 Jul 2016, Yaroslav Halchenko wrote: >> >>> > I just put in a PR https://github.com/nipy/nibabel/pull/464 to deal >>> > with some unchecked assumptions in the new spatial processing code - >>> > I'd be very happy of a review. >> >>> > Are there any other changes that people want to push for, for this next release? >> >>> FWIW, builds/tests seems pass ok across majority of Debian/Ubuntus (on >>> 12.04 need to do more dancing around mpl to test). >> >>> I would really appreciate feedback on my "selfish" idea: >>> https://github.com/nipy/nibabel/pull/466 >> >> some detected changes in behaviour of nibabel are detected within pymvpa >> tests... yet to look in details >> >> ====================================================================== >> ERROR: test_surf_gifti (mvpa2.tests.test_surfing.SurfTests) >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File "/build/pymvpa2-2.3.1/debian/tmp/usr/lib/python2.7/dist-packages/mvpa2/testing/tools.py", line 165, in newfunc >> func(*(arg + (filename,)), **kw) >> File "/build/pymvpa2-2.3.1/debian/tmp/usr/lib/python2.7/dist-packages/mvpa2/tests/test_surfing.py", line 1081, in test_surf_gifti >> surf.write(fn, s) >> File "/build/pymvpa2-2.3.1/debian/tmp/usr/lib/python2.7/dist-packages/mvpa2/support/nibabel/surf.py", line 2229, in write >> surf_gifti.write(fn, s, overwrite=overwrite) >> File "/build/pymvpa2-2.3.1/debian/tmp/usr/lib/python2.7/dist-packages/mvpa2/support/nibabel/surf_gifti.py", line 254, in write >> xml = to_xml(s, fn) >> File "/build/pymvpa2-2.3.1/debian/tmp/usr/lib/python2.7/dist-packages/mvpa2/support/nibabel/surf_gifti.py", line 203, in to_xml >> img = to_gifti_image(img) >> File "/build/pymvpa2-2.3.1/debian/tmp/usr/lib/python2.7/dist-packages/mvpa2/support/nibabel/surf_gifti.py", line 162, in to_gifti_image >> arr.num_dim = len(arr.dims) >> AttributeError: can't set attribute > > The GiftiDataArray object now has `num_dims` as a property. We could > add a setter that raises an error if the value is not as expected, and > a deprecation warning otherwise - OK with you? https://github.com/nipy/nibabel/pull/468 Matthew From matthew.brett at gmail.com Fri Jul 29 21:24:35 2016 From: matthew.brett at gmail.com (Matthew Brett) Date: Sat, 30 Jul 2016 02:24:35 +0100 Subject: [Neuroimaging] Nibabel release imminent In-Reply-To: <5584e7b7-ae5a-747a-b60b-1e9a62fa5262@gmail.com> References: <5584e7b7-ae5a-747a-b60b-1e9a62fa5262@gmail.com> Message-ID: Hi, On Fri, Jul 29, 2016 at 4:39 PM, Marc-Alexandre C?t? wrote: > How soon would that be? Planning for the end of next week. > I have a branch that adds support for another streamlines file format: TCK > (from MRtrix). I'm using it since April so I had time to debug it plenty but > it is still missing some unit tests. I won't be able to make a proper PR > before August 9th, would it be too late then? To get all review done, yes, I think too late. But - Thomas Emmerling has nearly finished his BrainVoyager PR, and I promised him a release when that is ready, so I'm expecting to do another release about a month later. OK to wait until then? Cheers, Matthew From matthew.brett at gmail.com Fri Jul 29 21:35:57 2016 From: matthew.brett at gmail.com (Matthew Brett) Date: Sat, 30 Jul 2016 02:35:57 +0100 Subject: [Neuroimaging] Nibabel release imminent In-Reply-To: <20160729133544.GI22292@onerussian.com> References: <20160729133544.GI22292@onerussian.com> Message-ID: On Fri, Jul 29, 2016 at 2:35 PM, Yaroslav Halchenko wrote: > > I would really appreciate feedback on my "selfish" idea: > https://github.com/nipy/nibabel/pull/466 I'd like feedback too. In summary - at the moment, if you ask nibabel to write to a filename, that is symlink, it will write to the file pointed to by the symlink. Yarik would like nibabel to overwrite the symlink file, with the written image. Imagine 'afile.nii' is a symlink, pointing to a file 'somefile'. Current behavior with `nib.save(img, 'afile.nii') will be to write to `somefile`, leaving the symlink intact. New behavior would be to replace the symlink `afile.nii` with the written image (and therefore, to orphan `somefile`. This seems like a pretty radical change to me - what do others think? Cheers, Matthew From stjeansam at gmail.com Sat Jul 30 05:38:19 2016 From: stjeansam at gmail.com (Samuel St-Jean) Date: Sat, 30 Jul 2016 11:38:19 +0200 Subject: [Neuroimaging] Nibabel release imminent In-Reply-To: References: <20160729133544.GI22292@onerussian.com> Message-ID: <2788851d-7d1f-3f3a-246e-e44692054060@gmail.com> Add (bool) option to do so but not enforce it, so everyone can be happy? It also won't produce undesired side effects, I remember when I bench stuff I always have a tons of symlink in the same folder (tractometer style stuff actually) coming from everywhere, and replacing those with new original files might break people stuff in hard to find out way. Le 2016-07-30 ? 03:35, Matthew Brett a ?crit : > On Fri, Jul 29, 2016 at 2:35 PM, Yaroslav Halchenko > wrote: >> I would really appreciate feedback on my "selfish" idea: >> https://github.com/nipy/nibabel/pull/466 > I'd like feedback too. > > In summary - at the moment, if you ask nibabel to write to a filename, > that is symlink, it will write to the file pointed to by the symlink. > > Yarik would like nibabel to overwrite the symlink file, with the written image. > > Imagine 'afile.nii' is a symlink, pointing to a file 'somefile'. > Current behavior with `nib.save(img, 'afile.nii') will be to write to > `somefile`, leaving the symlink intact. New behavior would be to > replace the symlink `afile.nii` with the written image (and therefore, > to orphan `somefile`. > > This seems like a pretty radical change to me - what do others think? > > Cheers, > > Matthew > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging From marc.cote.19 at gmail.com Sun Jul 31 18:38:22 2016 From: marc.cote.19 at gmail.com (=?UTF-8?B?TWFyYy1BbGV4YW5kcmUgQ8O0dMOp?=) Date: Sun, 31 Jul 2016 18:38:22 -0400 Subject: [Neuroimaging] Nibabel release imminent In-Reply-To: References: <5584e7b7-ae5a-747a-b60b-1e9a62fa5262@gmail.com> Message-ID: On 16-07-29 09:24 PM, Matthew Brett wrote: > Hi, > > On Fri, Jul 29, 2016 at 4:39 PM, Marc-Alexandre C?t? > wrote: >> How soon would that be? > Planning for the end of next week. > >> I have a branch that adds support for another streamlines file format: TCK >> (from MRtrix). I'm using it since April so I had time to debug it plenty but >> it is still missing some unit tests. I won't be able to make a proper PR >> before August 9th, would it be too late then? > To get all review done, yes, I think too late. But - Thomas Emmerling > has nearly finished his BrainVoyager PR, and I promised him a release > when that is ready, so I'm expecting to do another release about a > month later. OK to wait until then? Yes, that works for me. > > Cheers, > > Matthew > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging From arokem at gmail.com Sun Jul 31 21:01:08 2016 From: arokem at gmail.com (Ariel Rokem) Date: Sun, 31 Jul 2016 18:01:08 -0700 Subject: [Neuroimaging] Dipy Error in ROI Streamlines and Tracking In-Reply-To: References: Message-ID: Hi Jacob Antony, I have finally had some time to investigate this and I posted an answer to your same question over on neurostars: http://neurostars.org/p/4002/ Let me know if you have any further questions. Cheers, Ariel On Tue, Jul 12, 2016 at 3:21 PM, Jacob Antony wrote: > Hello, > > I am having issues with reading a trackvis file into the pipeline for ROI > filtering: http://nipy.org/dipy/examples_built/streamline_tools.html > I have checked the affine of the .trk file's header and it is [0 0 0 0; 0 > 0 0 0; 0 0 0 0; 0 0 0 1] > However the .trk file and my DTI image have been registered together so > they should have the same affine. Ultimately this leads to an error when I > attempt to run utils.target > ValueError: streamlines points are outside of target_mask > > This occurs when the include parameter is set to either true or false. > What could be the issue? I have included a google drive with the T1 image, > tractography file, corpus callosum mask, and the script I am using. > > > https://drive.google.com/folderview?id=0B02Ea96nn-Igb0dYbU5QazRoMEE&usp=sharing > > Please let me know if you have an idea of what could be causing the error. > Thank you all! > > Best, > > Jacob Antony > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: