From elef at indiana.edu Sat Jul 1 21:33:31 2017 From: elef at indiana.edu (Eleftherios Garyfallidis) Date: Sun, 02 Jul 2017 01:33:31 +0000 Subject: [Neuroimaging] ANN: DIPY 0.12.0 release Message-ID: We are excited to announce a new public release of Diffusion Imaging in Python (DIPY). DIPY 0.12 (Tuesday, 26 June 2017) This release received contributions from 48 developers (the full release notes are at: http://nipy.org/dipy/release0.12.html) Highlights of this release include: - IVIM Simultaneous modeling of perfusion and diffusion. - MAPL, tissue microstructure estimation using Laplacian-regularized MAP-MRI. - DKI-based microstructural modelling. - Free water diffusion tensor imaging. - Denoising using Local PCA. - Streamline-based registration (SLR). - Fiber to bundle coherence (FBC) measures. - Bayesian MRF-based tissue classification. - New API for integrated user interfaces. - New hdf5 file (.pam5) for saving reconstruction results. - Interactive slicing of images, ODFs and peaks. - Updated API to support latest numpy versions. - New system for automatically generating command line interfaces. - Faster computation of cross correlation for image registration. To upgrade, run the following command in your terminal: pip install --upgrade dipy or conda install -c conda-forge dipy This version of DIPY depends on the latest version of nibabel (2.1.0). For any questions go to http://dipy.org, or send an e-mail to neuroimaging at python.org We also have an instant messaging service and chat room available at https://gitter.im/nipy/dipy On behalf of the DIPY developers, Eleftherios Garyfallidis, Ariel Rokem, Serge Koudoro http://dipy.org/developers.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From gael.varoquaux at normalesup.org Sun Jul 2 06:29:46 2017 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Sun, 2 Jul 2017 12:29:46 +0200 Subject: [Neuroimaging] ANN: DIPY 0.12.0 release In-Reply-To: References: Message-ID: <20170702102946.GS4067506@phare.normalesup.org> Congratulations! It's good to see the dipy team going strongly. Ga?l On Sun, Jul 02, 2017 at 01:33:31AM +0000, Eleftherios Garyfallidis wrote: > We are excited to announce a new public release of Diffusion Imaging in Python > (DIPY). > DIPY 0.12 (Tuesday, 26 June 2017) > This release received contributions from 48 developers (the full release notes > are at: http://nipy.org/dipy/release0.12.html) > Highlights of this release include: > - IVIM Simultaneous modeling of perfusion and diffusion. > - MAPL, tissue microstructure estimation using Laplacian-regularized MAP-MRI. > - DKI-based microstructural modelling. > - Free water diffusion tensor imaging. > - Denoising using Local PCA. > - Streamline-based registration (SLR). > - Fiber to bundle coherence (FBC) measures. > - Bayesian MRF-based tissue classification. > - New API for integrated user interfaces. > - New hdf5 file (.pam5) for saving reconstruction results. > - Interactive slicing of images, ODFs and peaks. > - Updated API to support latest numpy versions. > - New system for automatically generating command line interfaces. > - Faster computation of cross correlation for image registration. > To upgrade, run the following command in your terminal: > pip install --upgrade dipy > or > conda install -c conda-forge dipy > This version of DIPY depends on the latest version of nibabel (2.1.0). > For any questions go to http://dipy.org, or send an e-mail to > neuroimaging at python.org ? > We also have an instant messaging service and chat room available at https:// > gitter.im/nipy/dipy > On behalf of the DIPY developers, > Eleftherios Garyfallidis, Ariel Rokem, Serge Koudoro > http://dipy.org/developers.html > [btw_ic_min] > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging -- Gael Varoquaux Researcher, INRIA Parietal NeuroSpin/CEA Saclay , Bat 145, 91191 Gif-sur-Yvette France Phone: ++ 33-1-69-08-79-68 http://gael-varoquaux.info http://twitter.com/GaelVaroquaux From bertrand.thirion at inria.fr Sun Jul 2 13:55:24 2017 From: bertrand.thirion at inria.fr (Bertrand Thirion) Date: Sun, 2 Jul 2017 19:55:24 +0200 (CEST) Subject: [Neuroimaging] ANN: DIPY 0.12.0 release In-Reply-To: References: Message-ID: <643286048.12646179.1499018124690.JavaMail.zimbra@inria.fr> Congratulations for the release ! Best, Bertrand ----- Mail original ----- > De: "Eleftherios Garyfallidis" > ?: "Neuroimaging analysis in Python" > Envoy?: Dimanche 2 Juillet 2017 03:33:31 > Objet: [Neuroimaging] ANN: DIPY 0.12.0 release > We are excited to announce a new public release of Diffusion Imaging in > Python (DIPY). > DIPY 0.12 (Tuesday, 26 June 2017) > This release received contributions from 48 developers (the full release > notes are at: http://nipy.org/dipy/release0.12.html ) > Highlights of this release include: > - IVIM Simultaneous modeling of perfusion and diffusion. > - MAPL, tissue microstructure estimation using Laplacian-regularized MAP-MRI. > - DKI-based microstructural modelling. > - Free water diffusion tensor imaging. > - Denoising using Local PCA. > - Streamline-based registration (SLR). > - Fiber to bundle coherence (FBC) measures. > - Bayesian MRF-based tissue classification. > - New API for integrated user interfaces. > - New hdf5 file (.pam5) for saving reconstruction results. > - Interactive slicing of images, ODFs and peaks. > - Updated API to support latest numpy versions. > - New system for automatically generating command line interfaces. > - Faster computation of cross correlation for image registration. > T o upgrade, run the following command in your terminal: > pip install --upgrade dipy > or > conda install -c conda-forge dipy > This version of DIPY depends on the latest version of nibabel (2.1.0). > For any questions go to http://dipy.org , or send an e-mail to > neuroimaging at python.org > We also have an instant messaging service and chat room available at > https://gitter.im/nipy/dipy > On behalf of the DIPY developers, > Eleftherios Garyfallidis, Ariel Rokem, Serge Koudoro > http://dipy.org/developers.html > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging -------------- next part -------------- An HTML attachment was scrubbed... URL: From krzysztof.gorgolewski at gmail.com Sun Jul 2 14:13:04 2017 From: krzysztof.gorgolewski at gmail.com (Chris Gorgolewski) Date: Sun, 2 Jul 2017 11:13:04 -0700 Subject: [Neuroimaging] ANN: DIPY 0.12.0 release In-Reply-To: <643286048.12646179.1499018124690.JavaMail.zimbra@inria.fr> References: <643286048.12646179.1499018124690.JavaMail.zimbra@inria.fr> Message-ID: Congrats! On Jul 2, 2017 10:55 AM, "Bertrand Thirion" wrote: > Congratulations for the release ! > Best, > > Bertrand > > ------------------------------ > > *De: *"Eleftherios Garyfallidis" > *?: *"Neuroimaging analysis in Python" > *Envoy?: *Dimanche 2 Juillet 2017 03:33:31 > *Objet: *[Neuroimaging] ANN: DIPY 0.12.0 release > > We are excited to announce a new public release of Diffusion Imaging in > Python (DIPY). > > > DIPY 0.12 (Tuesday, 26 June 2017) > > This release received contributions from 48 developers (the full release > notes are at: http://nipy.org/dipy/release0.12.html) > > Highlights of this release include: > > > - IVIM Simultaneous modeling of perfusion and diffusion. > - MAPL, tissue microstructure estimation using Laplacian-regularized > MAP-MRI. > - DKI-based microstructural modelling. > - Free water diffusion tensor imaging. > - Denoising using Local PCA. > - Streamline-based registration (SLR). > - Fiber to bundle coherence (FBC) measures. > - Bayesian MRF-based tissue classification. > - New API for integrated user interfaces. > - New hdf5 file (.pam5) for saving reconstruction results. > - Interactive slicing of images, ODFs and peaks. > - Updated API to support latest numpy versions. > - New system for automatically generating command line interfaces. > - Faster computation of cross correlation for image registration. > > To upgrade, run the following command in your terminal: > > > > pip install --upgrade dipy > > or > > conda install -c conda-forge dipy > > This version of DIPY depends on the latest version of nibabel (2.1.0). > > For any questions go to http://dipy.org, or send an e-mail to > neuroimaging at python.org > > We also have an instant messaging service and chat room available at > https://gitter.im/nipy/dipy > > On behalf of the DIPY developers, > > Eleftherios Garyfallidis, Ariel Rokem, Serge Koudoro > > http://dipy.org/developers.html > > > _______________________________________________ > 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 romain.valabregue at upmc.fr Mon Jul 3 04:21:56 2017 From: romain.valabregue at upmc.fr (valabregue) Date: Mon, 3 Jul 2017 10:21:56 +0200 Subject: [Neuroimaging] JSON-LD and DICOM? In-Reply-To: References: Message-ID: <2085d0ba-e774-1637-617d-be7cf9b2884a@upmc.fr> Hi all, On 06/30/2017 09:57 PM, Matthew Brett wrote: > Hi, > > On Fri, Jun 30, 2017 at 5:35 PM, Jasper van den Bosch wrote: >> Hi all, >> I have to agree with Andrey on the yet another format argument. Also, tools >> will have to convert it to other formats anyway, so if you do end up storing >> something in the header, as long as you document it, just like you would >> other nibabel properties, I'd go for the simplest solution. > There is going to be a JSON header extension quite soon, so it's not > really another format, but another way of storing metadata in NIfTI. > Then the question is - should we also store DICOM metadata there? Yes we should store the Dicom metadata, this is the less effort, and it fulfills the needs ... May be I miss the point. What would be the alternative ? (to define a new ontologie for the metadata ?) I am using (since a couple a years) the dcmstack that convert dicom to nifti + a json file (with all dicom meta data AND more importantly all private siemens fields). The nice feature of this conversion is that it aggregates field that are identical in all split dicom file (and keep array only when it is necessary). Why not use this solution ? I do not see any clear advantage to have this meta data information directly in the nifti file (a naming convention make it easy to keep a link) chears Romain From matthew.brett at gmail.com Mon Jul 3 05:54:53 2017 From: matthew.brett at gmail.com (Matthew Brett) Date: Mon, 3 Jul 2017 10:54:53 +0100 Subject: [Neuroimaging] JSON-LD and DICOM? In-Reply-To: <2085d0ba-e774-1637-617d-be7cf9b2884a@upmc.fr> References: <2085d0ba-e774-1637-617d-be7cf9b2884a@upmc.fr> Message-ID: Hi, On Mon, Jul 3, 2017 at 9:21 AM, valabregue wrote: > Hi all, > > > > On 06/30/2017 09:57 PM, Matthew Brett wrote: >> >> Hi, >> >> On Fri, Jun 30, 2017 at 5:35 PM, Jasper van den Bosch >> wrote: >>> >>> Hi all, >>> I have to agree with Andrey on the yet another format argument. Also, >>> tools >>> will have to convert it to other formats anyway, so if you do end up >>> storing >>> something in the header, as long as you document it, just like you would >>> other nibabel properties, I'd go for the simplest solution. >> >> There is going to be a JSON header extension quite soon, so it's not >> really another format, but another way of storing metadata in NIfTI. >> Then the question is - should we also store DICOM metadata there? > > Yes we should store the Dicom metadata, this is the less effort, and it > fulfills the needs ... May be I miss the point. What would be the > alternative ? (to define a new ontologie for the metadata ?) > > I am using (since a couple a years) the dcmstack that convert dicom to nifti > + a json file (with all dicom meta data AND more importantly all private > siemens fields). The nice feature of this conversion is that it aggregates > field that are identical in all split dicom file (and keep array only when > it is necessary). > > Why not use this solution ? Actually, the reason I'm interested in this now is because I am thinking about how to integrate dcmstack into nibabel. So I wanted to fuse the dcmstack metadata analysis into the NIfTI header. > I do not see any clear advantage to have this meta data information directly > in the nifti file (a naming convention make it easy to keep a link) Well - let's say there are two options: * A NIfTI file with a JSON header, where the JSON header contains the DICOM metadata; * A NIfTI file with a JSON header, where the the DICOM metadata is in a separate JSON file. To me the first seems more obvious than the second. Surely it also makes things like provenance just a little bit easier - because it is just a little bit harder to lose the relationship between the image and the metadata. Cheers, Matthew From romain.valabregue at upmc.fr Mon Jul 3 08:00:07 2017 From: romain.valabregue at upmc.fr (valabregue) Date: Mon, 3 Jul 2017 14:00:07 +0200 Subject: [Neuroimaging] JSON-LD and DICOM? In-Reply-To: References: <2085d0ba-e774-1637-617d-be7cf9b2884a@upmc.fr> Message-ID: <90ff7947-0803-8724-a9b3-3bc0631a134c@upmc.fr> On 07/03/2017 11:54 AM, Matthew Brett wrote: > Hi, > > On Mon, Jul 3, 2017 at 9:21 AM, valabregue wrote: >> Hi all, >> >> >> >> On 06/30/2017 09:57 PM, Matthew Brett wrote: >>> Hi, >>> >>> On Fri, Jun 30, 2017 at 5:35 PM, Jasper van den Bosch >>> wrote: >>>> Hi all, >>>> I have to agree with Andrey on the yet another format argument. Also, >>>> tools >>>> will have to convert it to other formats anyway, so if you do end up >>>> storing >>>> something in the header, as long as you document it, just like you would >>>> other nibabel properties, I'd go for the simplest solution. >>> There is going to be a JSON header extension quite soon, so it's not >>> really another format, but another way of storing metadata in NIfTI. >>> Then the question is - should we also store DICOM metadata there? >> Yes we should store the Dicom metadata, this is the less effort, and it >> fulfills the needs ... May be I miss the point. What would be the >> alternative ? (to define a new ontologie for the metadata ?) >> >> I am using (since a couple a years) the dcmstack that convert dicom to nifti >> + a json file (with all dicom meta data AND more importantly all private >> siemens fields). The nice feature of this conversion is that it aggregates >> field that are identical in all split dicom file (and keep array only when >> it is necessary). >> >> Why not use this solution ? > Actually, the reason I'm interested in this now is because I am > thinking about how to integrate dcmstack into nibabel. So I wanted to > fuse the dcmstack metadata analysis into the NIfTI header. > >> I do not see any clear advantage to have this meta data information directly >> in the nifti file (a naming convention make it easy to keep a link) > Well - let's say there are two options: > > * A NIfTI file with a JSON header, where the JSON header contains the > DICOM metadata; > * A NIfTI file with a JSON header, where the the DICOM metadata is in > a separate JSON file. > > To me the first seems more obvious than the second. Surely it also > makes things like provenance just a little bit easier - because it is > just a little bit harder to lose the relationship between the image > and the metadata. Well may be it is not a big deal to make both possible ... ? It looks like nifti files extension img+hdf or .nii well I agree with you: all in once is more obvious. ( like for nifti file I prefer the .nii files). The only disadvantage I see is that you may loose some nifti compatibility with other software that expect only a fix header. (345 byte). So depending on what you plan to do, both may be chosen. Romain From matthew.brett at gmail.com Mon Jul 3 08:13:57 2017 From: matthew.brett at gmail.com (Matthew Brett) Date: Mon, 3 Jul 2017 13:13:57 +0100 Subject: [Neuroimaging] JSON-LD and DICOM? In-Reply-To: <90ff7947-0803-8724-a9b3-3bc0631a134c@upmc.fr> References: <2085d0ba-e774-1637-617d-be7cf9b2884a@upmc.fr> <90ff7947-0803-8724-a9b3-3bc0631a134c@upmc.fr> Message-ID: On Mon, Jul 3, 2017 at 1:00 PM, valabregue wrote: > > > On 07/03/2017 11:54 AM, Matthew Brett wrote: >> >> Hi, >> >> On Mon, Jul 3, 2017 at 9:21 AM, valabregue >> wrote: >>> >>> Hi all, >>> >>> >>> >>> On 06/30/2017 09:57 PM, Matthew Brett wrote: >>>> >>>> Hi, >>>> >>>> On Fri, Jun 30, 2017 at 5:35 PM, Jasper van den Bosch >>>> wrote: >>>>> >>>>> Hi all, >>>>> I have to agree with Andrey on the yet another format argument. Also, >>>>> tools >>>>> will have to convert it to other formats anyway, so if you do end up >>>>> storing >>>>> something in the header, as long as you document it, just like you >>>>> would >>>>> other nibabel properties, I'd go for the simplest solution. >>>> >>>> There is going to be a JSON header extension quite soon, so it's not >>>> really another format, but another way of storing metadata in NIfTI. >>>> Then the question is - should we also store DICOM metadata there? >>> >>> Yes we should store the Dicom metadata, this is the less effort, and it >>> fulfills the needs ... May be I miss the point. What would be the >>> alternative ? (to define a new ontologie for the metadata ?) >>> >>> I am using (since a couple a years) the dcmstack that convert dicom to >>> nifti >>> + a json file (with all dicom meta data AND more importantly all private >>> siemens fields). The nice feature of this conversion is that it >>> aggregates >>> field that are identical in all split dicom file (and keep array only >>> when >>> it is necessary). >>> >>> Why not use this solution ? >> >> Actually, the reason I'm interested in this now is because I am >> thinking about how to integrate dcmstack into nibabel. So I wanted to >> fuse the dcmstack metadata analysis into the NIfTI header. >> >>> I do not see any clear advantage to have this meta data information >>> directly >>> in the nifti file (a naming convention make it easy to keep a link) >> >> Well - let's say there are two options: >> >> * A NIfTI file with a JSON header, where the JSON header contains the >> DICOM metadata; >> * A NIfTI file with a JSON header, where the the DICOM metadata is in >> a separate JSON file. >> >> To me the first seems more obvious than the second. Surely it also >> makes things like provenance just a little bit easier - because it is >> just a little bit harder to lose the relationship between the image >> and the metadata. > > Well may be it is not a big deal to make both possible ... ? > > It looks like nifti files extension img+hdf or .nii > well I agree with you: all in once is more obvious. ( like for nifti file I > prefer the .nii files). The only disadvantage I see is that you may loose > some nifti compatibility with other software that expect only a fix header. > (345 byte). So depending on what you plan to do, both may be chosen. I think most if not all software allows there to be header extensions after the header and before the data, so I think that will be OK... Cheers, Matthew From bennet at umich.edu Mon Jul 3 08:19:25 2017 From: bennet at umich.edu (Bennet Fauber) Date: Mon, 3 Jul 2017 08:19:25 -0400 Subject: [Neuroimaging] JSON-LD and DICOM? In-Reply-To: <90ff7947-0803-8724-a9b3-3bc0631a134c@upmc.fr> References: <2085d0ba-e774-1637-617d-be7cf9b2884a@upmc.fr> <90ff7947-0803-8724-a9b3-3bc0631a134c@upmc.fr> Message-ID: With respect to Romain's comment, yes, backward compatibility is important. How will this affect NIfTI compatibility with other software? Is this proposed change to the NIfTI format going to be NIfTI-2? Is there some sort of review process that this is going through like NIfTI-1? On Mon, Jul 3, 2017 at 8:00 AM, valabregue wrote: > > > On 07/03/2017 11:54 AM, Matthew Brett wrote: >> >> Hi, >> >> On Mon, Jul 3, 2017 at 9:21 AM, valabregue >> wrote: >>> >>> Hi all, >>> >>> >>> >>> On 06/30/2017 09:57 PM, Matthew Brett wrote: >>>> >>>> Hi, >>>> >>>> On Fri, Jun 30, 2017 at 5:35 PM, Jasper van den Bosch >>>> wrote: >>>>> >>>>> Hi all, >>>>> I have to agree with Andrey on the yet another format argument. Also, >>>>> tools >>>>> will have to convert it to other formats anyway, so if you do end up >>>>> storing >>>>> something in the header, as long as you document it, just like you >>>>> would >>>>> other nibabel properties, I'd go for the simplest solution. >>>> >>>> There is going to be a JSON header extension quite soon, so it's not >>>> really another format, but another way of storing metadata in NIfTI. >>>> Then the question is - should we also store DICOM metadata there? >>> >>> Yes we should store the Dicom metadata, this is the less effort, and it >>> fulfills the needs ... May be I miss the point. What would be the >>> alternative ? (to define a new ontologie for the metadata ?) >>> >>> I am using (since a couple a years) the dcmstack that convert dicom to >>> nifti >>> + a json file (with all dicom meta data AND more importantly all private >>> siemens fields). The nice feature of this conversion is that it >>> aggregates >>> field that are identical in all split dicom file (and keep array only >>> when >>> it is necessary). >>> >>> Why not use this solution ? >> >> Actually, the reason I'm interested in this now is because I am >> thinking about how to integrate dcmstack into nibabel. So I wanted to >> fuse the dcmstack metadata analysis into the NIfTI header. >> >>> I do not see any clear advantage to have this meta data information >>> directly >>> in the nifti file (a naming convention make it easy to keep a link) >> >> Well - let's say there are two options: >> >> * A NIfTI file with a JSON header, where the JSON header contains the >> DICOM metadata; >> * A NIfTI file with a JSON header, where the the DICOM metadata is in >> a separate JSON file. >> >> To me the first seems more obvious than the second. Surely it also >> makes things like provenance just a little bit easier - because it is >> just a little bit harder to lose the relationship between the image >> and the metadata. > > Well may be it is not a big deal to make both possible ... ? > > It looks like nifti files extension img+hdf or .nii > well I agree with you: all in once is more obvious. ( like for nifti file I > prefer the .nii files). The only disadvantage I see is that you may loose > some nifti compatibility with other software that expect only a fix header. > (345 byte). So depending on what you plan to do, both may be chosen. > > > Romain > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging From matthew.brett at gmail.com Mon Jul 3 08:29:32 2017 From: matthew.brett at gmail.com (Matthew Brett) Date: Mon, 3 Jul 2017 13:29:32 +0100 Subject: [Neuroimaging] JSON-LD and DICOM? In-Reply-To: References: <2085d0ba-e774-1637-617d-be7cf9b2884a@upmc.fr> <90ff7947-0803-8724-a9b3-3bc0631a134c@upmc.fr> Message-ID: Hi, On Mon, Jul 3, 2017 at 1:19 PM, Bennet Fauber wrote: > With respect to Romain's comment, yes, backward compatibility is > important. How will this affect NIfTI compatibility with other > software? Is this proposed change to the NIfTI format going to be > NIfTI-2? Is there some sort of review process that this is going > through like NIfTI-1? I think we're OK with backwards compatibility, because the JSON header extension would be a "header extension" in this sense: https://nifti.nimh.nih.gov/nifti-1/documentation/faq#Q21 Any compatible NIfTI1 reader should happily skip over the header extension data it does not recognize - and I think that's true of the major packages. As for the review process, that's what we're doing in these discussions - I drafted up a spec a while ago, that is here: https://github.com/nipy/nibabel/wiki/json-header-extension That was the first pass. See this thread for the initial discussion: https://mail.scipy.org/pipermail/nipy-devel/2014-July/010087.html I'm just in the process of finishing up a second pass. When I've done that, and we've done another pass at discussion here, I'll email out to the AFNI / SPM / FSL mailing lists to see if they've got any thoughts. Can you think of anywhere else the discussion should go? Cheers, Matthew From bennet at umich.edu Mon Jul 3 08:40:44 2017 From: bennet at umich.edu (Bennet Fauber) Date: Mon, 3 Jul 2017 08:40:44 -0400 Subject: [Neuroimaging] JSON-LD and DICOM? In-Reply-To: References: <2085d0ba-e774-1637-617d-be7cf9b2884a@upmc.fr> <90ff7947-0803-8724-a9b3-3bc0631a134c@upmc.fr> Message-ID: So, presumably, compatibility will be maintained if other software reads and uses vox_offset. It looks, from a brief scan, that the size of the JSON extension is not fixed, as it can accommodate multiple scanner vendors' versions of DICOM? Sorry for the naive questions. On Mon, Jul 3, 2017 at 8:29 AM, Matthew Brett wrote: > Hi, > > On Mon, Jul 3, 2017 at 1:19 PM, Bennet Fauber wrote: >> With respect to Romain's comment, yes, backward compatibility is >> important. How will this affect NIfTI compatibility with other >> software? Is this proposed change to the NIfTI format going to be >> NIfTI-2? Is there some sort of review process that this is going >> through like NIfTI-1? > > I think we're OK with backwards compatibility, because the JSON header > extension would be a "header extension" in this sense: > > https://nifti.nimh.nih.gov/nifti-1/documentation/faq#Q21 > > Any compatible NIfTI1 reader should happily skip over the header > extension data it does not recognize - and I think that's true of the > major packages. > > As for the review process, that's what we're doing in these > discussions - I drafted up a spec a while ago, that is here: > > https://github.com/nipy/nibabel/wiki/json-header-extension > > That was the first pass. See this thread for the initial discussion: > > https://mail.scipy.org/pipermail/nipy-devel/2014-July/010087.html > > I'm just in the process of finishing up a second pass. When I've done > that, and we've done another pass at discussion here, I'll email out > to the AFNI / SPM / FSL mailing lists to see if they've got any > thoughts. Can you think of anywhere else the discussion should go? > > Cheers, > > Matthew > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging From pieper at isomics.com Mon Jul 3 09:03:21 2017 From: pieper at isomics.com (Steve Pieper) Date: Mon, 3 Jul 2017 09:03:21 -0400 Subject: [Neuroimaging] JSON-LD and DICOM? In-Reply-To: References: <2085d0ba-e774-1637-617d-be7cf9b2884a@upmc.fr> <90ff7947-0803-8724-a9b3-3bc0631a134c@upmc.fr> Message-ID: To avoid repetition, I'll just point to my comments 3 years ago on this topic [1]. Since then we've continued to work on DICOM in research contexts [2] and we still think it's a neat idea. The software is coming along nicely too [3]. Cheers, -Steve [1] https://mail.scipy.org/pipermail/nipy-devel/2014-July/010143.html [2] https://peerj.com/articles/2057/ [3] https://github.com/QIICR/dcmqi On Mon, Jul 3, 2017 at 8:40 AM, Bennet Fauber wrote: > So, presumably, compatibility will be maintained if other software > reads and uses vox_offset. > > It looks, from a brief scan, that the size of the JSON extension is > not fixed, as it can accommodate multiple scanner vendors' versions of > DICOM? > > Sorry for the naive questions. > > On Mon, Jul 3, 2017 at 8:29 AM, Matthew Brett > wrote: > > Hi, > > > > On Mon, Jul 3, 2017 at 1:19 PM, Bennet Fauber wrote: > >> With respect to Romain's comment, yes, backward compatibility is > >> important. How will this affect NIfTI compatibility with other > >> software? Is this proposed change to the NIfTI format going to be > >> NIfTI-2? Is there some sort of review process that this is going > >> through like NIfTI-1? > > > > I think we're OK with backwards compatibility, because the JSON header > > extension would be a "header extension" in this sense: > > > > https://nifti.nimh.nih.gov/nifti-1/documentation/faq#Q21 > > > > Any compatible NIfTI1 reader should happily skip over the header > > extension data it does not recognize - and I think that's true of the > > major packages. > > > > As for the review process, that's what we're doing in these > > discussions - I drafted up a spec a while ago, that is here: > > > > https://github.com/nipy/nibabel/wiki/json-header-extension > > > > That was the first pass. See this thread for the initial discussion: > > > > https://mail.scipy.org/pipermail/nipy-devel/2014-July/010087.html > > > > I'm just in the process of finishing up a second pass. When I've done > > that, and we've done another pass at discussion here, I'll email out > > to the AFNI / SPM / FSL mailing lists to see if they've got any > > thoughts. Can you think of anywhere else the discussion should go? > > > > 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 matthew.brett at gmail.com Mon Jul 3 10:08:33 2017 From: matthew.brett at gmail.com (Matthew Brett) Date: Mon, 3 Jul 2017 15:08:33 +0100 Subject: [Neuroimaging] JSON-LD and DICOM? In-Reply-To: References: <2085d0ba-e774-1637-617d-be7cf9b2884a@upmc.fr> <90ff7947-0803-8724-a9b3-3bc0631a134c@upmc.fr> Message-ID: Hi, On Mon, Jul 3, 2017 at 1:40 PM, Bennet Fauber wrote: > So, presumably, compatibility will be maintained if other software > reads and uses vox_offset. Right - and they will be doing that if they followed the spec correctly, or if the software has come across any images with other types of header extensions, and had to fix crashes resulting. > It looks, from a brief scan, that the size of the JSON extension is > not fixed, as it can accommodate multiple scanner vendors' versions of > DICOM? Right - the extension can be of variable size. > Sorry for the naive questions. No problem, Cheers, Matthew From matthew.brett at gmail.com Mon Jul 3 10:15:33 2017 From: matthew.brett at gmail.com (Matthew Brett) Date: Mon, 3 Jul 2017 15:15:33 +0100 Subject: [Neuroimaging] JSON-LD and DICOM? In-Reply-To: References: <2085d0ba-e774-1637-617d-be7cf9b2884a@upmc.fr> <90ff7947-0803-8724-a9b3-3bc0631a134c@upmc.fr> Message-ID: Hi Steve, On Mon, Jul 3, 2017 at 2:03 PM, Steve Pieper wrote: > To avoid repetition, I'll just point to my comments 3 years ago on this > topic [1]. Since then we've continued to work on DICOM in research contexts > [2] and we still think it's a neat idea. The software is coming along > nicely too [3]. I am sure there's a place for sticking entirely to DICOM, but, as you know, nearly all standard imaging software reads and writes NIfTI, for preference, and often only writes NIfTI. So, a solution that works with NIfTI is a lot closer to hand than switching to using DICOM at all stages of processing. Cheers, Matthew From alexsavio at gmail.com Mon Jul 3 13:54:09 2017 From: alexsavio at gmail.com (alexsavio at gmail.com) Date: Mon, 03 Jul 2017 17:54:09 +0000 Subject: [Neuroimaging] JSON-LD and DICOM? In-Reply-To: References: <2085d0ba-e774-1637-617d-be7cf9b2884a@upmc.fr> <90ff7947-0803-8724-a9b3-3bc0631a134c@upmc.fr> Message-ID: This improvement of NifTI metadata for neuroimaging is a nice idea. I wonder why this has not happened before. When I was working with PET images from Siemens I had to hack into this CSA headers to obtain some parameters which then had to go together with the NifTI files everywhere. Working with DICOM is the clinical way to go and report, but for research it's a pain in the ass, also when working with different vendors. On Mon, 3 Jul 2017, 16:16 Matthew Brett, wrote: > Hi Steve, > > On Mon, Jul 3, 2017 at 2:03 PM, Steve Pieper wrote: > > To avoid repetition, I'll just point to my comments 3 years ago on this > > topic [1]. Since then we've continued to work on DICOM in research > contexts > > [2] and we still think it's a neat idea. The software is coming along > > nicely too [3]. > > I am sure there's a place for sticking entirely to DICOM, but, as you > know, nearly all standard imaging software reads and writes NIfTI, for > preference, and often only writes NIfTI. So, a solution that works > with NIfTI is a lot closer to hand than switching to using DICOM at > all stages of processing. > > Cheers, > > Matthew > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > -- Sent from my phone, sorry for brevity or typos. -------------- next part -------------- An HTML attachment was scrubbed... URL: From satra at mit.edu Mon Jul 3 13:58:03 2017 From: satra at mit.edu (Satrajit Ghosh) Date: Mon, 3 Jul 2017 10:58:03 -0700 Subject: [Neuroimaging] JSON-LD and DICOM? In-Reply-To: References: <2085d0ba-e774-1637-617d-be7cf9b2884a@upmc.fr> <90ff7947-0803-8724-a9b3-3bc0631a134c@upmc.fr> Message-ID: hi all, sorry, ohbm was busy, just catching up with this! it seems there are a few threads in here that i will attempt to summarize and comment. *1. the original question: is there a json-ld context that can be used or included in a nifti-header extension. * this can be easily created based on both the work done by david clunie to expose each dicom term but also the extensive curation by karl helmer. we can create a simple json-ld context definition that behaves as a lexicon. there are pieces of dicom where this will get complicated, but for our needs a vocabulary may be a good starting point. here are the terms in neurolex: http://neurolex.org/wiki/Category:DICOM_term they are being transitioned off to scicrunch/interlex and i'm sure karl and i can put together a basic context for us. *2. nibabel addons and the metadata extension in nifti. * for those who are unfamiliar, we have been using a non-standardized extension based on dcmstack in nifti for several years now in the heudiconv tool. there is an opportunity to make this part of nibabel and create a standard extension. as with many extensions, most software tools may choose to ignore an extension, but the value of this extension to keep dicom metadata around with the raw converted nifti file is immense. currently, we simply discard this information (wait till point 3 for the dicom-nifti dimension). as we create this standard, it would be good to leverage json-ld to simply point to a context file such as this: "@context": "http://nipy.org/nibabel/dicom-context.jsonld" we don't have to expand this out in each embedded header. *3. the dicom-nifti dimension:* *a. state of the field.* this dicom-nifti dimension reflects the reality of our field in many ways. most of us neuroimagers live in a research/exploratory space and mostly do not have any clinical applications that need to be embedded into hospital systems. the clinical imaging community is trying to make their algorithms work for clinical decision systems in the clinical enterprise, hence their need for dicom operators. much of cognitive neuroscience is not applicable to the clinic hence very little incentive for people to think about dicoms. *b. the variations in dicom and nifti* as nate noted there are some big differences in scanners as they apply to research institutions. trying to standardize dicom output across scanners is itself a big undertaking and not in the interest of many centers. i'm not even talking about metadata standardization here, i'm simply saying let all dicom scanners output multi-frame dicom. if this is something the community can achieve it would be a big step towards a common framework. however, if it requires every center to change their mode of operation, it's a huge barrier at present. nifti on the other hand is a compact format and fits easily into current filesystem views. *c. software support * as has been well noted in this thread, the brain imaging community for most relies on a set of software packages that support nifti extensively. updating these tools to support dicom i/o is a resource intensive undertaking. if magically, through a week long hackathon, every software supported dicom objects, i don't think we would be having this conversation. in addition better dicom support in nibabel could be very useful to a subset of the community developing tools in python. for example, from a memory representation perspective, it doesn't matter what the disk file format is as long as there is a nice api to read it. we view dicom in the same lens that we saw it through in the nineties. perhaps we can be educated on the diffs in the last 20 years. *d. metadata maintenance* as an algorithm developer, one would have to decide what metadata to keep and what new pieces of metadata to add to the dicom object. i know andrey, steve, and others have done this for segmentation objects and structured reports, but the field would have to do this for connectomes, surfaces, and others. blindly copying dicom metadata is analogous to blindly copying nifti header extensions. so in both spaces, one has to decide what to keep and what to modify. while we can be careful about this for new algorithms, doing so for the existing ones is a lot of work. *e. a view of information that reduces cognitive load* as algorithm developers we care about the view, the minimal set of information that is needed to write a function/solve a problem. nifti-1 was an agglomeration of those views when it was created, together with some backward compatibility decisions with analyze. people were not thinking of large databases, diffusion imaging, and other areas that we now consider important. and hence nifti is a view of the underlying information that is already out of date. yes the extensions were part of the solution, but how many people use the diffusion extension over bvecs and bval files (a la FSL)? the dicom object stores much more information, but it is also a view. it does not store the raw sensor data (think nikon RAW vs JPEG) in most cases, because people thought it was excessive. as we now seem to find with simultaneous multislice seqeunces in fMRI and dMRI, the reconstruction algorithm has a huge impact on the SNR of the combined channel data. hence more people are preserving k-space data in projects that use such sequences. ------ at some point neither dicom nor nifti will be the appropriate format. we are not there yet but there are many pointers in that direction as connected information aggregates (genetics, imaging, behavior, ehr, etc). at present, in our resource constrained development environments, perhaps we can preserve information and make it useful when we can. cheers, satra On Mon, Jul 3, 2017 at 7:15 AM, Matthew Brett wrote: > Hi Steve, > > On Mon, Jul 3, 2017 at 2:03 PM, Steve Pieper wrote: > > To avoid repetition, I'll just point to my comments 3 years ago on this > > topic [1]. Since then we've continued to work on DICOM in research > contexts > > [2] and we still think it's a neat idea. The software is coming along > > nicely too [3]. > > I am sure there's a place for sticking entirely to DICOM, but, as you > know, nearly all standard imaging software reads and writes NIfTI, for > preference, and often only writes NIfTI. So, a solution that works > with NIfTI is a lot closer to hand than switching to using DICOM at > all stages of processing. > > 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 Reid.Robert at mayo.edu Mon Jul 3 14:54:39 2017 From: Reid.Robert at mayo.edu (Reid, Robert I. (Rob)) Date: Mon, 03 Jul 2017 18:54:39 +0000 Subject: [Neuroimaging] JSON-LD and DICOM? In-Reply-To: References: <2085d0ba-e774-1637-617d-be7cf9b2884a@upmc.fr> <90ff7947-0803-8724-a9b3-3bc0631a134c@upmc.fr> Message-ID: <9153c6$7ae8hs@ironport10.mayo.edu> Hi, Satrajit Ghosh wrote: > as an algorithm developer, one would have to decide what metadata to keep and what new pieces of metadata to add to the dicom object. I would really rather have it *all* kept, and think a better question is to decide what metadata to parse and what to store ?raw?, to parse when modern medical science catches up to old obfuscated scans. Our lab has been adding the dicom metadata of the first slice to our .niis for a long time, using dcmtk?s dcmdump. Understandably, dcmdump needs a ?DICOM dictionary? to translate between tag numbers and basic tag meaning, and many private tags end up as the dreaded ?Unknown Tag & Data?, including, unfortunately, the Siemens CSA headers. Later we figured out how to parse the CSA headers, and wish we had made them more conveniently accessible in our old .niis. We keep the DICOM files of course, but we hate it when we have to go back to them. As long as the metadata is kept, parsing is good, but a line will have to be drawn somewhere for how far parsing is supportable. Keeping only one value for tags that are the same for all slices, but lists for ones that vary, is good and fairly straightforward. Beyond that, there are many basic things, like diffusion gradients, whether fat saturation was used, and the Siemens CSA headers, that users want which are not stored the same way or in the same place between scanner software releases, let alone across manufacturers. Having that info parsed would be very useful, but also difficult to maintain. > but how many people use the diffusion extension over bvecs and bval files (a la FSL)? Probably a rhetorical question, but actually I tend to use a header extension if it?s present, and do a glob for *bval* and *bvec* if I have to. But it?s an in house extension made from the .bval and .bvec files from dcm2nii ? I?m not aware of ?the? diffusion extension. Rob -- Robert I. Reid, Ph.D. | Sr. Analyst/Programmer, Information Technology Aging and Dementia Imaging Research | Opus Center for Advanced Imaging Research Mayo Clinic | 200 First Street SW | Rochester, MN 55905 | mayoclinic.org From: Neuroimaging [mailto:neuroimaging-bounces+reid.robert=mayo.edu at python.org] On Behalf Of Satrajit Ghosh Sent: Monday, July 03, 2017 12:58 PM To: Neuroimaging analysis in Python Subject: Re: [Neuroimaging] JSON-LD and DICOM? hi all, sorry, ohbm was busy, just catching up with this! it seems there are a few threads in here that i will attempt to summarize and comment. 1. the original question: is there a json-ld context that can be used or included in a nifti-header extension. this can be easily created based on both the work done by david clunie to expose each dicom term but also the extensive curation by karl helmer. we can create a simple json-ld context definition that behaves as a lexicon. there are pieces of dicom where this will get complicated, but for our needs a vocabulary may be a good starting point. here are the terms in neurolex: http://neurolex.org/wiki/Category:DICOM_term they are being transitioned off to scicrunch/interlex and i'm sure karl and i can put together a basic context for us. 2. nibabel addons and the metadata extension in nifti. for those who are unfamiliar, we have been using a non-standardized extension based on dcmstack in nifti for several years now in the heudiconv tool. there is an opportunity to make this part of nibabel and create a standard extension. as with many extensions, most software tools may choose to ignore an extension, but the value of this extension to keep dicom metadata around with the raw converted nifti file is immense. currently, we simply discard this information (wait till point 3 for the dicom-nifti dimension). as we create this standard, it would be good to leverage json-ld to simply point to a context file such as this: "@context": "http://nipy.org/nibabel/dicom-context.jsonld" we don't have to expand this out in each embedded header. 3. the dicom-nifti dimension: a. state of the field. this dicom-nifti dimension reflects the reality of our field in many ways. most of us neuroimagers live in a research/exploratory space and mostly do not have any clinical applications that need to be embedded into hospital systems. the clinical imaging community is trying to make their algorithms work for clinical decision systems in the clinical enterprise, hence their need for dicom operators. much of cognitive neuroscience is not applicable to the clinic hence very little incentive for people to think about dicoms. b. the variations in dicom and nifti as nate noted there are some big differences in scanners as they apply to research institutions. trying to standardize dicom output across scanners is itself a big undertaking and not in the interest of many centers. i'm not even talking about metadata standardization here, i'm simply saying let all dicom scanners output multi-frame dicom. if this is something the community can achieve it would be a big step towards a common framework. however, if it requires every center to change their mode of operation, it's a huge barrier at present. nifti on the other hand is a compact format and fits easily into current filesystem views. c. software support as has been well noted in this thread, the brain imaging community for most relies on a set of software packages that support nifti extensively. updating these tools to support dicom i/o is a resource intensive undertaking. if magically, through a week long hackathon, every software supported dicom objects, i don't think we would be having this conversation. in addition better dicom support in nibabel could be very useful to a subset of the community developing tools in python. for example, from a memory representation perspective, it doesn't matter what the disk file format is as long as there is a nice api to read it. we view dicom in the same lens that we saw it through in the nineties. perhaps we can be educated on the diffs in the last 20 years. d. metadata maintenance as an algorithm developer, one would have to decide what metadata to keep and what new pieces of metadata to add to the dicom object. i know andrey, steve, and others have done this for segmentation objects and structured reports, but the field would have to do this for connectomes, surfaces, and others. blindly copying dicom metadata is analogous to blindly copying nifti header extensions. so in both spaces, one has to decide what to keep and what to modify. while we can be careful about this for new algorithms, doing so for the existing ones is a lot of work. e. a view of information that reduces cognitive load as algorithm developers we care about the view, the minimal set of information that is needed to write a function/solve a problem. nifti-1 was an agglomeration of those views when it was created, together with some backward compatibility decisions with analyze. people were not thinking of large databases, diffusion imaging, and other areas that we now consider important. and hence nifti is a view of the underlying information that is already out of date. yes the extensions were part of the solution, but how many people use the diffusion extension over bvecs and bval files (a la FSL)? the dicom object stores much more information, but it is also a view. it does not store the raw sensor data (think nikon RAW vs JPEG) in most cases, because people thought it was excessive. as we now seem to find with simultaneous multislice seqeunces in fMRI and dMRI, the reconstruction algorithm has a huge impact on the SNR of the combined channel data. hence more people are preserving k-space data in projects that use such sequences. ------ at some point neither dicom nor nifti will be the appropriate format. we are not there yet but there are many pointers in that direction as connected information aggregates (genetics, imaging, behavior, ehr, etc). at present, in our resource constrained development environments, perhaps we can preserve information and make it useful when we can. cheers, satra On Mon, Jul 3, 2017 at 7:15 AM, Matthew Brett > wrote: Hi Steve, On Mon, Jul 3, 2017 at 2:03 PM, Steve Pieper > wrote: > To avoid repetition, I'll just point to my comments 3 years ago on this > topic [1]. Since then we've continued to work on DICOM in research contexts > [2] and we still think it's a neat idea. The software is coming along > nicely too [3]. I am sure there's a place for sticking entirely to DICOM, but, as you know, nearly all standard imaging software reads and writes NIfTI, for preference, and often only writes NIfTI. So, a solution that works with NIfTI is a lot closer to hand than switching to using DICOM at all stages of processing. 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 elef at indiana.edu Mon Jul 3 15:04:50 2017 From: elef at indiana.edu (Eleftherios Garyfallidis) Date: Mon, 03 Jul 2017 19:04:50 +0000 Subject: [Neuroimaging] ANN: DIPY 0.12.0 release In-Reply-To: References: <643286048.12646179.1499018124690.JavaMail.zimbra@inria.fr> Message-ID: Thank you Gael, Bertrand and Chris. And thanks all who contributed to the release. On Sun, Jul 2, 2017 at 2:13 PM Chris Gorgolewski < krzysztof.gorgolewski at gmail.com> wrote: > Congrats! > > On Jul 2, 2017 10:55 AM, "Bertrand Thirion" > wrote: > >> Congratulations for the release ! >> Best, >> >> Bertrand >> >> ------------------------------ >> >> *De: *"Eleftherios Garyfallidis" >> *?: *"Neuroimaging analysis in Python" >> *Envoy?: *Dimanche 2 Juillet 2017 03:33:31 >> *Objet: *[Neuroimaging] ANN: DIPY 0.12.0 release >> >> We are excited to announce a new public release of Diffusion Imaging in >> Python (DIPY). >> >> >> DIPY 0.12 (Tuesday, 26 June 2017) >> >> This release received contributions from 48 developers (the full release >> notes are at: http://nipy.org/dipy/release0.12.html) >> >> Highlights of this release include: >> >> >> - IVIM Simultaneous modeling of perfusion and diffusion. >> - MAPL, tissue microstructure estimation using Laplacian-regularized >> MAP-MRI. >> - DKI-based microstructural modelling. >> - Free water diffusion tensor imaging. >> - Denoising using Local PCA. >> - Streamline-based registration (SLR). >> - Fiber to bundle coherence (FBC) measures. >> - Bayesian MRF-based tissue classification. >> - New API for integrated user interfaces. >> - New hdf5 file (.pam5) for saving reconstruction results. >> - Interactive slicing of images, ODFs and peaks. >> - Updated API to support latest numpy versions. >> - New system for automatically generating command line interfaces. >> - Faster computation of cross correlation for image registration. >> >> To upgrade, run the following command in your terminal: >> >> >> >> pip install --upgrade dipy >> >> or >> >> conda install -c conda-forge dipy >> >> This version of DIPY depends on the latest version of nibabel (2.1.0). >> >> For any questions go to http://dipy.org, or send an e-mail to >> neuroimaging at python.org >> >> We also have an instant messaging service and chat room available at >> https://gitter.im/nipy/dipy >> >> On behalf of the DIPY developers, >> >> Eleftherios Garyfallidis, Ariel Rokem, Serge Koudoro >> >> http://dipy.org/developers.html >> >> >> _______________________________________________ >> 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 matthew.brett at gmail.com Mon Jul 3 15:58:34 2017 From: matthew.brett at gmail.com (Matthew Brett) Date: Mon, 3 Jul 2017 20:58:34 +0100 Subject: [Neuroimaging] JSON-LD and DICOM? In-Reply-To: References: <2085d0ba-e774-1637-617d-be7cf9b2884a@upmc.fr> <90ff7947-0803-8724-a9b3-3bc0631a134c@upmc.fr> Message-ID: Hi, On Mon, Jul 3, 2017 at 6:58 PM, Satrajit Ghosh wrote: > hi all, > > sorry, ohbm was busy, just catching up with this! it seems there are a few > threads in here that i will attempt to summarize and comment. > > 1. the original question: is there a json-ld context that can be used or > included in a nifti-header extension. > > this can be easily created based on both the work done by david clunie to > expose each dicom term but also the extensive curation by karl helmer. we > can create a simple json-ld context definition that behaves as a lexicon. > there are pieces of dicom where this will get complicated, but for our needs > a vocabulary may be a good starting point. > > here are the terms in neurolex: http://neurolex.org/wiki/Category:DICOM_term > > they are being transitioned off to scicrunch/interlex and i'm sure karl and > i can put together a basic context for us. That would be very useful indeed. Any idea of a time scale for that? > 2. nibabel addons and the metadata extension in nifti. > > for those who are unfamiliar, we have been using a non-standardized > extension based on dcmstack in nifti for several years now in the heudiconv > tool. there is an opportunity to make this part of nibabel and create a > standard extension. as with many extensions, most software tools may choose > to ignore an extension, but the value of this extension to keep dicom > metadata around with the raw converted nifti file is immense. currently, we > simply discard this information (wait till point 3 for the dicom-nifti > dimension). as we create this standard, it would be good to leverage json-ld > to simply point to a context file such as this: > > "@context": "http://nipy.org/nibabel/dicom-context.jsonld" > > we don't have to expand this out in each embedded header. Right - or, as you noted in the current JSON header draft, we can make ``dcm`` a prefix with its own context, within the context for the JSON header extension: "@context": "http://nipy.org/nibabel/jhe-context.jsonld" where jhe-context.jsonld contains: "@context": { "dcm": "http://nipy.org/nibabel/dicom-context.jsonld" }, and the JSON header goes something like: "@context": "http://nipy.org/nibabel/jhe-context.jsonld", "nipy_header_version": "1.0", "dcm:Echo_Time": 45, etc. > 3. the dicom-nifti dimension: > > a. state of the field. > > this dicom-nifti dimension reflects the reality of our field in many ways. > most of us neuroimagers live in a research/exploratory space and mostly do > not have any clinical applications that need to be embedded into hospital > systems. the clinical imaging community is trying to make their algorithms > work for clinical decision systems in the clinical enterprise, hence their > need for dicom operators. much of cognitive neuroscience is not applicable > to the clinic hence very little incentive for people to think about dicoms. > > b. the variations in dicom and nifti > > as nate noted there are some big differences in scanners as they apply to > research institutions. trying to standardize dicom output across scanners is > itself a big undertaking and not in the interest of many centers. i'm not > even talking about metadata standardization here, i'm simply saying let all > dicom scanners output multi-frame dicom. if this is something the community > can achieve it would be a big step towards a common framework. however, if > it requires every center to change their mode of operation, it's a huge > barrier at present. nifti on the other hand is a compact format and fits > easily into current filesystem views. > > c. software support > > as has been well noted in this thread, the brain imaging community for most > relies on a set of software packages that support nifti extensively. > updating these tools to support dicom i/o is a resource intensive > undertaking. if magically, through a week long hackathon, every software > supported dicom objects, i don't think we would be having this conversation. > > in addition better dicom support in nibabel could be very useful to a subset > of the community developing tools in python. for example, from a memory > representation perspective, it doesn't matter what the disk file format is > as long as there is a nice api to read it. > > we view dicom in the same lens that we saw it through in the nineties. > perhaps we can be educated on the diffs in the last 20 years. > > d. metadata maintenance > > as an algorithm developer, one would have to decide what metadata to keep > and what new pieces of metadata to add to the dicom object. i know andrey, > steve, and others have done this for segmentation objects and structured > reports, but the field would have to do this for connectomes, surfaces, and > others. > > blindly copying dicom metadata is analogous to blindly copying nifti header > extensions. so in both spaces, one has to decide what to keep and what to > modify. while we can be careful about this for new algorithms, doing so for > the existing ones is a lot of work. > > e. a view of information that reduces cognitive load > > as algorithm developers we care about the view, the minimal set of > information that is needed to write a function/solve a problem. nifti-1 was > an agglomeration of those views when it was created, together with some > backward compatibility decisions with analyze. people were not thinking of > large databases, diffusion imaging, and other areas that we now consider > important. and hence nifti is a view of the underlying information that is > already out of date. yes the extensions were part of the solution, but how > many people use the diffusion extension over bvecs and bval files (a la > FSL)? I think that is partly because of the relative opacity of the extension formats. Even a small binary format needs some software in your language to unpack it in a reliable way. Because it takes this work to look at the information, people often don't bother to check if the information is what they want, and just throw it away. That's the big advantage of text files and text formats - they can just open the file in text editor to have a look if the information is useful. > the dicom object stores much more information, but it is also a view. it > does not store the raw sensor data (think nikon RAW vs JPEG) in most cases, > because people thought it was excessive. as we now seem to find with > simultaneous multislice seqeunces in fMRI and dMRI, the reconstruction > algorithm has a huge impact on the SNR of the combined channel data. hence > more people are preserving k-space data in projects that use such sequences. > > ------ > > at some point neither dicom nor nifti will be the appropriate format. we are > not there yet but there are many pointers in that direction as connected > information aggregates (genetics, imaging, behavior, ehr, etc). at present, > in our resource constrained development environments, perhaps we can > preserve information and make it useful when we can. Thanks for the useful summary, Cheers2, Matthew From satra at mit.edu Mon Jul 3 19:02:29 2017 From: satra at mit.edu (Satrajit Ghosh) Date: Mon, 3 Jul 2017 16:02:29 -0700 Subject: [Neuroimaging] ANN: DIPY 0.12.0 release In-Reply-To: References: Message-ID: congrats! great to see this rolling along. cheers, satra On Sat, Jul 1, 2017 at 6:33 PM, Eleftherios Garyfallidis wrote: > We are excited to announce a new public release of Diffusion Imaging in > Python (DIPY). > > > DIPY 0.12 (Tuesday, 26 June 2017) > > This release received contributions from 48 developers (the full release > notes are at: http://nipy.org/dipy/release0.12.html) > > Highlights of this release include: > > > - IVIM Simultaneous modeling of perfusion and diffusion. > - MAPL, tissue microstructure estimation using Laplacian-regularized > MAP-MRI. > - DKI-based microstructural modelling. > - Free water diffusion tensor imaging. > - Denoising using Local PCA. > - Streamline-based registration (SLR). > - Fiber to bundle coherence (FBC) measures. > - Bayesian MRF-based tissue classification. > - New API for integrated user interfaces. > - New hdf5 file (.pam5) for saving reconstruction results. > - Interactive slicing of images, ODFs and peaks. > - Updated API to support latest numpy versions. > - New system for automatically generating command line interfaces. > - Faster computation of cross correlation for image registration. > > To upgrade, run the following command in your terminal: > > > > pip install --upgrade dipy > > or > > conda install -c conda-forge dipy > > This version of DIPY depends on the latest version of nibabel (2.1.0). > > For any questions go to http://dipy.org, or send an e-mail to > neuroimaging at python.org > > We also have an instant messaging service and chat room available at > https://gitter.im/nipy/dipy > > On behalf of the DIPY developers, > > Eleftherios Garyfallidis, Ariel Rokem, Serge Koudoro > > http://dipy.org/developers.html > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at onerussian.com Mon Jul 3 23:30:05 2017 From: lists at onerussian.com (Yaroslav Halchenko) Date: Mon, 3 Jul 2017 23:30:05 -0400 Subject: [Neuroimaging] ANN: DIPY 0.12.0 release In-Reply-To: References: Message-ID: <20170704033005.i5c3oyk2dxbemlap@hopa.kiewit.dartmouth.edu> Congrats! could those example docs be autogenerated for each release? wget -O ../tarballs/dipy_0.12.0.orig-doc-examples.tar.gz \ http://nipy.sourceforge.net/dipy/dipy-0.12.0-doc-examples.tar.gz --2017-07-03 23:29:09-- http://nipy.sourceforge.net/dipy/dipy-0.12.0-doc-examples.tar.gz Resolving nipy.sourceforge.net (nipy.sourceforge.net)... 216.34.181.96 Connecting to nipy.sourceforge.net (nipy.sourceforge.net)|216.34.181.96|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2017-07-03 23:29:09 ERROR 404: Not Found. On Sun, 02 Jul 2017, Eleftherios Garyfallidis wrote: > We are excited to announce a new public release of Diffusion Imaging in > Python (DIPY). > DIPY 0.12 (Tuesday, 26 June 2017) > This release received contributions from 48 developers (the full release > notes are at: http://nipy.org/dipy/release0.12.html) > Highlights of this release include: > - IVIM Simultaneous modeling of perfusion and diffusion. > - MAPL, tissue microstructure estimation using Laplacian-regularized > MAP-MRI. > - DKI-based microstructural modelling. > - Free water diffusion tensor imaging. > - Denoising using Local PCA. > - Streamline-based registration (SLR). > - Fiber to bundle coherence (FBC) measures. > - Bayesian MRF-based tissue classification. > - New API for integrated user interfaces. > - New hdf5 file (.pam5) for saving reconstruction results. > - Interactive slicing of images, ODFs and peaks. > - Updated API to support latest numpy versions. > - New system for automatically generating command line interfaces. > - Faster computation of cross correlation for image registration. > To upgrade, run the following command in your terminal: > pip install --upgrade dipy > or > conda install -c conda-forge dipy > This version of DIPY depends on the latest version of nibabel (2.1.0). > For any questions go to http://dipy.org, or send an e-mail to > neuroimaging at python.org ?? > We also have an instant messaging service and chat room available at > https://gitter.im/nipy/dipy > On behalf of the DIPY developers, > Eleftherios Garyfallidis, Ariel Rokem, Serge Koudoro > http://dipy.org/developers.html > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging -- 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 satra at mit.edu Tue Jul 4 11:49:08 2017 From: satra at mit.edu (Satrajit Ghosh) Date: Tue, 4 Jul 2017 11:49:08 -0400 Subject: [Neuroimaging] JSON-LD and DICOM? In-Reply-To: References: <2085d0ba-e774-1637-617d-be7cf9b2884a@upmc.fr> <90ff7947-0803-8724-a9b3-3bc0631a134c@upmc.fr> Message-ID: hi matthew, > > they are being transitioned off to scicrunch/interlex and i'm sure karl > and > > i can put together a basic context for us. > > That would be very useful indeed. Any idea of a time scale for that? > let me talk to karl. this should be doable by middle of next week if not earlier. > Right - or, as you noted in the current JSON header draft, we can make > ``dcm`` a prefix with its own context, within the context for the JSON > header extension: > > "@context": "http://nipy.org/nibabel/jhe-context.jsonld" > > where jhe-context.jsonld contains: > > "@context": { > "dcm": "http://nipy.org/nibabel/dicom-context.jsonld" > }, > > and the JSON header goes something like: > > "@context": "http://nipy.org/nibabel/jhe-context.jsonld", > "nipy_header_version": "1.0", > "dcm:Echo_Time": 45, > > etc. > sounds good to me. for the non dicom terms we should describe them in a context with descriptions and data types as well. > > e. a view of information that reduces cognitive load > > > > as algorithm developers we care about the view, the minimal set of > > information that is needed to write a function/solve a problem. nifti-1 > was > > an agglomeration of those views when it was created, together with some > > backward compatibility decisions with analyze. people were not thinking > of > > large databases, diffusion imaging, and other areas that we now consider > > important. and hence nifti is a view of the underlying information that > is > > already out of date. yes the extensions were part of the solution, but > how > > many people use the diffusion extension over bvecs and bval files (a la > > FSL)? > > I think that is partly because of the relative opacity of the > extension formats. Even a small binary format needs some software in > your language to unpack it in a reliable way. Because it takes this > work to look at the information, people often don't bother to check if > the information is what they want, and just throw it away. That's the > big advantage of text files and text formats - they can just open the > file in text editor to have a look if the information is useful. > aren't all data binary on a computer :) ? less/more/cat are programs as well. it's just that there are many text readers/writers available on most platforms. i particularly like the following paragraph from this site ( https://www.cs.umd.edu/class/sum2003/cmsc311/Notes/BitOp/asciiBin.html) "Computer science is all about creating good abstractions. Sometimes it succeeds and sometimes it doesn't. Good abstractions are all about presenting a view of the world that the user can use. One of the most successful abstractions is the text editor." if something like nib-ls was readily available and parsed these data and perhaps allowed editing it easily, i think most people would be happy with it. --- will point you to the context as soon as karl and i have had a chance to chat and create a version. cheers, satra -------------- next part -------------- An HTML attachment was scrubbed... URL: From krzysztof.gorgolewski at gmail.com Tue Jul 4 12:00:14 2017 From: krzysztof.gorgolewski at gmail.com (Chris Gorgolewski) Date: Tue, 4 Jul 2017 12:00:14 -0400 Subject: [Neuroimaging] JSON-LD and DICOM? In-Reply-To: References: <2085d0ba-e774-1637-617d-be7cf9b2884a@upmc.fr> <90ff7947-0803-8724-a9b3-3bc0631a134c@upmc.fr> Message-ID: On Mon, Jul 3, 2017 at 3:58 PM, Matthew Brett wrote: > I think that is partly because of the relative opacity of the > extension formats. Even a small binary format needs some software in > your language to unpack it in a reliable way. Because it takes this > work to look at the information, people often don't bother to check if > the information is what they want, and just throw it away. That's the > big advantage of text files and text formats - they can just open the > file in text editor to have a look if the information is useful. > This point of view is was also brought up when discussing storing metadata in a sidecar file vs. the header in context of BIDS. With a plain text file the barriers to viewing and editing metadata are lower (there are more editors that can do it), but having linked files means that you cannot copy them individually. Would love to hear more opinions on the topic. Best, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Tue Jul 4 12:27:16 2017 From: matthew.brett at gmail.com (Matthew Brett) Date: Tue, 4 Jul 2017 17:27:16 +0100 Subject: [Neuroimaging] JSON-LD and DICOM? In-Reply-To: References: <2085d0ba-e774-1637-617d-be7cf9b2884a@upmc.fr> <90ff7947-0803-8724-a9b3-3bc0631a134c@upmc.fr> Message-ID: Hi Chris, On Tue, Jul 4, 2017 at 5:00 PM, Chris Gorgolewski wrote: > > On Mon, Jul 3, 2017 at 3:58 PM, Matthew Brett > wrote: >> >> I think that is partly because of the relative opacity of the >> extension formats. Even a small binary format needs some software in >> your language to unpack it in a reliable way. Because it takes this >> work to look at the information, people often don't bother to check if >> the information is what they want, and just throw it away. That's the >> big advantage of text files and text formats - they can just open the >> file in text editor to have a look if the information is useful. > > > This point of view is was also brought up when discussing storing metadata > in a sidecar file vs. the header in context of BIDS. With a plain text file > the barriers to viewing and editing metadata are lower (there are more > editors that can do it), but having linked files means that you cannot copy > them individually. Would love to hear more opinions on the topic. Doesn't the NIfTI JSON extension give you both, more or less? You can view with a text editor, and it keeps the data and metadata together. See you, Matthew From krzysztof.gorgolewski at gmail.com Tue Jul 4 12:31:01 2017 From: krzysztof.gorgolewski at gmail.com (Chris Gorgolewski) Date: Tue, 4 Jul 2017 12:31:01 -0400 Subject: [Neuroimaging] JSON-LD and DICOM? In-Reply-To: References: <2085d0ba-e774-1637-617d-be7cf9b2884a@upmc.fr> <90ff7947-0803-8724-a9b3-3bc0631a134c@upmc.fr> Message-ID: On Tue, Jul 4, 2017 at 12:27 PM, Matthew Brett wrote: > Doesn't the NIfTI JSON extension give you both, more or less? You can > view with a text editor, and it keeps the data and metadata together. > Maybe! Can I open a nifti file with notepad, atom, vim and see the header info? Is it at the beginning of the file or at the end (after the binary part)? -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Tue Jul 4 12:36:12 2017 From: matthew.brett at gmail.com (Matthew Brett) Date: Tue, 4 Jul 2017 17:36:12 +0100 Subject: [Neuroimaging] JSON-LD and DICOM? In-Reply-To: References: <2085d0ba-e774-1637-617d-be7cf9b2884a@upmc.fr> <90ff7947-0803-8724-a9b3-3bc0631a134c@upmc.fr> Message-ID: On Tue, Jul 4, 2017 at 5:31 PM, Chris Gorgolewski wrote: > > On Tue, Jul 4, 2017 at 12:27 PM, Matthew Brett > wrote: >> >> Doesn't the NIfTI JSON extension give you both, more or less? You can >> view with a text editor, and it keeps the data and metadata together. > > > Maybe! Can I open a nifti file with notepad, atom, vim and see the header > info? Is it at the beginning of the file or at the end (after the binary > part)? It's near the beginning - specifically, if it's the only extension (which will usually be true), then it will start at byte 352 of the file. So yes, if you open the nifti file with a standard text editor, as long as it doesn't try and force you into using a hex display or something, you should see the header extension text on the first screen. Cheers, Matthew From matthew.brett at gmail.com Tue Jul 4 12:37:21 2017 From: matthew.brett at gmail.com (Matthew Brett) Date: Tue, 4 Jul 2017 17:37:21 +0100 Subject: [Neuroimaging] JSON-LD and DICOM? In-Reply-To: References: <2085d0ba-e774-1637-617d-be7cf9b2884a@upmc.fr> <90ff7947-0803-8724-a9b3-3bc0631a134c@upmc.fr> Message-ID: Hi Satra, On Tue, Jul 4, 2017 at 4:49 PM, Satrajit Ghosh wrote: > hi matthew, > >> >> > they are being transitioned off to scicrunch/interlex and i'm sure karl >> > and >> > i can put together a basic context for us. >> >> That would be very useful indeed. Any idea of a time scale for that? > > > let me talk to karl. this should be doable by middle of next week if not > earlier. Excellent - that would be very helpful. Will y'all be able to define the @types as well as the @ids ? I guess that would be a lot more work. >> Right - or, as you noted in the current JSON header draft, we can make >> ``dcm`` a prefix with its own context, within the context for the JSON >> header extension: >> >> "@context": "http://nipy.org/nibabel/jhe-context.jsonld" >> >> where jhe-context.jsonld contains: >> >> "@context": { >> "dcm": "http://nipy.org/nibabel/dicom-context.jsonld" >> }, >> >> and the JSON header goes something like: >> >> "@context": "http://nipy.org/nibabel/jhe-context.jsonld", >> "nipy_header_version": "1.0", >> "dcm:Echo_Time": 45, >> >> etc. > > > sounds good to me. for the non dicom terms we should describe them in a > context with descriptions and data types as well. Right - yes, the rest of the context would describe the terms native to the header extension. Cheers, Matthew From satra at mit.edu Tue Jul 4 12:47:42 2017 From: satra at mit.edu (Satrajit Ghosh) Date: Tue, 4 Jul 2017 12:47:42 -0400 Subject: [Neuroimaging] JSON-LD and DICOM? In-Reply-To: References: <2085d0ba-e774-1637-617d-be7cf9b2884a@upmc.fr> <90ff7947-0803-8724-a9b3-3bc0631a134c@upmc.fr> Message-ID: > > Excellent - that would be very helpful. Will y'all be able to define > the @types as well as the @ids ? I guess that would be a lot more > work. > it shouldn't be too hard to combine it with this: https://github.com/pydicom/pydicom/blob/master/pydicom/_dicom_dict.py which itself is generated from the dicom standard and private dictionaries (these are not in karl's curation though and likely varies by sequence and scanner software versions). https://github.com/pydicom/pydicom/tree/master/source/generate_dict cheers, satra -------------- next part -------------- An HTML attachment was scrubbed... URL: From krzysztof.gorgolewski at gmail.com Tue Jul 4 12:55:26 2017 From: krzysztof.gorgolewski at gmail.com (Chris Gorgolewski) Date: Tue, 4 Jul 2017 12:55:26 -0400 Subject: [Neuroimaging] JSON-LD and DICOM? In-Reply-To: References: <2085d0ba-e774-1637-617d-be7cf9b2884a@upmc.fr> <90ff7947-0803-8724-a9b3-3bc0631a134c@upmc.fr> Message-ID: On Tue, Jul 4, 2017 at 12:36 PM, Matthew Brett wrote: > It's near the beginning - specifically, if it's the only extension > (which will usually be true), then it will start at byte 352 of the > file. So yes, if you open the nifti file with a standard text > editor, as long as it doesn't try and force you into using a hex > display or something, you should see the header extension text on the > first screen. > Interesting! This would not work for nii.gz right? Also I'm afraid that editors like atom would choke on files larger than 20mb... Best, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From krzysztof.gorgolewski at gmail.com Tue Jul 4 13:00:45 2017 From: krzysztof.gorgolewski at gmail.com (Chris Gorgolewski) Date: Tue, 4 Jul 2017 13:00:45 -0400 Subject: [Neuroimaging] JSON-LD and DICOM? In-Reply-To: References: <2085d0ba-e774-1637-617d-be7cf9b2884a@upmc.fr> <90ff7947-0803-8724-a9b3-3bc0631a134c@upmc.fr> Message-ID: I wonder if in the future it would also make sense to: 1) add option of creating sidecar BIDS compatible JSON files into nibabel (similar to what dcm2niix, dicm2nii, and mcverter are doing). This makes some sense since nibabel will become a dicom to nifti converter after dcmstack is merged. 2) store the same content in the header (for "future" compatibility) under a different namespace than "dcm" (would that work Satra? How would an example JSON-LD with both "dcm" and "bids" look like?) Not a huge priority, but something to think about. I am very glad that dcmstack is getting merged into nibabel. Best, Chris On Tue, Jul 4, 2017 at 12:47 PM, Satrajit Ghosh wrote: > Excellent - that would be very helpful. Will y'all be able to define >> the @types as well as the @ids ? I guess that would be a lot more >> work. >> > > it shouldn't be too hard to combine it with this: > > https://github.com/pydicom/pydicom/blob/master/pydicom/_dicom_dict.py > > which itself is generated from the dicom standard and private dictionaries > (these are not in karl's curation though and likely varies by sequence and > scanner software versions). > > https://github.com/pydicom/pydicom/tree/master/source/generate_dict > > cheers, > > satra > > _______________________________________________ > 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 Jul 4 13:04:37 2017 From: matthew.brett at gmail.com (Matthew Brett) Date: Tue, 4 Jul 2017 18:04:37 +0100 Subject: [Neuroimaging] JSON-LD and DICOM? In-Reply-To: References: <2085d0ba-e774-1637-617d-be7cf9b2884a@upmc.fr> <90ff7947-0803-8724-a9b3-3bc0631a134c@upmc.fr> Message-ID: On Tue, Jul 4, 2017 at 5:55 PM, Chris Gorgolewski wrote: > > On Tue, Jul 4, 2017 at 12:36 PM, Matthew Brett > wrote: >> >> It's near the beginning - specifically, if it's the only extension >> (which will usually be true), then it will start at byte 352 of the >> file. So yes, if you open the nifti file with a standard text >> editor, as long as it doesn't try and force you into using a hex >> display or something, you should see the header extension text on the >> first screen. > > > Interesting! This would not work for nii.gz right? Also I'm afraid that > editors like atom would choke on files larger than 20mb... No, wouldn't work on big .gz files without unpacking, unless you did something like: gunzip -c ~/tmp/my_mri.nii.gz | head -c 2000 | cat -v Cheers, Matthew From dagutman at gmail.com Tue Jul 4 13:05:24 2017 From: dagutman at gmail.com (David Gutman) Date: Tue, 04 Jul 2017 17:05:24 +0000 Subject: [Neuroimaging] JSON-LD and DICOM? In-Reply-To: References: <2085d0ba-e774-1637-617d-be7cf9b2884a@upmc.fr> <90ff7947-0803-8724-a9b3-3bc0631a134c@upmc.fr> Message-ID: Just to chime in briefly.. one thing that wasn't mentioned re: DICOM is the fact of potential PHI leaks. Ensuring any and all DICOM tags have no PHI in it is an incredibly tedious/expensive undertaking, and at least for those of us who use clinical scans for some of our work, the overhead of trying to make sure we truly anonymized everything in the DICOM header is significant. Whereas in the case of NIFTI, as long as the filename doesn't contain the embedded patient name , I can be pretty sure the files are "clean". This is particularly important when grad students are working on their own laptops which are... not particularly secure. On Tue, Jul 4, 2017 at 1:01 PM Chris Gorgolewski < krzysztof.gorgolewski at gmail.com> wrote: > I wonder if in the future it would also make sense to: > > 1) add option of creating sidecar BIDS compatible JSON files into nibabel > (similar to what dcm2niix, dicm2nii, and mcverter are doing). This makes > some sense since nibabel will become a dicom to nifti converter after > dcmstack is merged. > > 2) store the same content in the header (for "future" compatibility) under > a different namespace than "dcm" (would that work Satra? How would an > example JSON-LD with both "dcm" and "bids" look like?) > > Not a huge priority, but something to think about. I am very glad that > dcmstack is getting merged into nibabel. > > Best, > Chris > > On Tue, Jul 4, 2017 at 12:47 PM, Satrajit Ghosh wrote: > >> Excellent - that would be very helpful. Will y'all be able to define >>> the @types as well as the @ids ? I guess that would be a lot more >>> work. >>> >> >> it shouldn't be too hard to combine it with this: >> >> https://github.com/pydicom/pydicom/blob/master/pydicom/_dicom_dict.py >> >> which itself is generated from the dicom standard and private >> dictionaries (these are not in karl's curation though and likely varies by >> sequence and scanner software versions). >> >> https://github.com/pydicom/pydicom/tree/master/source/generate_dict >> >> cheers, >> >> satra >> >> _______________________________________________ >> 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 > -- David A Gutman MD PhD Assistant Professor of Neurology, Psychiatry & Biomedical Informatics Emory University School of Medicine Staff Physician, Mental Health Service Line Atlanta VA Medical Center -------------- next part -------------- An HTML attachment was scrubbed... URL: From bennet at umich.edu Tue Jul 4 13:16:34 2017 From: bennet at umich.edu (Bennet Fauber) Date: Tue, 4 Jul 2017 13:16:34 -0400 Subject: [Neuroimaging] JSON-LD and DICOM? In-Reply-To: References: <2085d0ba-e774-1637-617d-be7cf9b2884a@upmc.fr> <90ff7947-0803-8724-a9b3-3bc0631a134c@upmc.fr> Message-ID: Oh, yes. That is very important. Converting to .nii is one of our main ways of insuring no leakage of any subject information -- not just PHI, but potentially names and other information about research subject that, while not regulated, would discourteous to expose. On Tue, Jul 4, 2017 at 1:05 PM, David Gutman wrote: > Just to chime in briefly.. one thing that wasn't mentioned re: DICOM is the > fact of potential PHI leaks. Ensuring any and all DICOM tags have no PHI > in it is an incredibly tedious/expensive undertaking, and at least for those > of us who use clinical scans for some of our work, the overhead of trying to > make sure we truly anonymized everything in the DICOM header is significant. > > Whereas in the case of NIFTI, as long as the filename doesn't contain the > embedded patient name , I can be pretty sure the files are "clean". > > This is particularly important when grad students are working on their own > laptops which are... not particularly secure. > > > > > On Tue, Jul 4, 2017 at 1:01 PM Chris Gorgolewski > wrote: >> >> I wonder if in the future it would also make sense to: >> >> 1) add option of creating sidecar BIDS compatible JSON files into nibabel >> (similar to what dcm2niix, dicm2nii, and mcverter are doing). This makes >> some sense since nibabel will become a dicom to nifti converter after >> dcmstack is merged. >> >> 2) store the same content in the header (for "future" compatibility) under >> a different namespace than "dcm" (would that work Satra? How would an >> example JSON-LD with both "dcm" and "bids" look like?) >> >> Not a huge priority, but something to think about. I am very glad that >> dcmstack is getting merged into nibabel. >> >> Best, >> Chris >> >> On Tue, Jul 4, 2017 at 12:47 PM, Satrajit Ghosh wrote: >>>> >>>> Excellent - that would be very helpful. Will y'all be able to define >>>> the @types as well as the @ids ? I guess that would be a lot more >>>> work. >>> >>> >>> it shouldn't be too hard to combine it with this: >>> >>> https://github.com/pydicom/pydicom/blob/master/pydicom/_dicom_dict.py >>> >>> which itself is generated from the dicom standard and private >>> dictionaries (these are not in karl's curation though and likely varies by >>> sequence and scanner software versions). >>> >>> https://github.com/pydicom/pydicom/tree/master/source/generate_dict >>> >>> cheers, >>> >>> satra >>> >>> _______________________________________________ >>> 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 > > -- > David A Gutman MD PhD > Assistant Professor of Neurology, Psychiatry & Biomedical Informatics > Emory University School of Medicine > Staff Physician, Mental Health Service Line > Atlanta VA Medical Center > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > From Reid.Robert at mayo.edu Wed Jul 5 09:27:46 2017 From: Reid.Robert at mayo.edu (Reid, Robert I. (Rob)) Date: Wed, 05 Jul 2017 13:27:46 +0000 Subject: [Neuroimaging] JSON-LD and DICOM? In-Reply-To: References: <2085d0ba-e774-1637-617d-be7cf9b2884a@upmc.fr> <90ff7947-0803-8724-a9b3-3bc0631a134c@upmc.fr> Message-ID: <9153c6$7atcum@ironport10.mayo.edu> Fortunately nifti header extensions are very easy to remove, either explicitly with nibabel or nifti_tool, or accidentally with FSL. Rob -- Robert I. Reid, Ph.D. | Sr. Analyst/Programmer, Information Technology Aging and Dementia Imaging Research | Opus Center for Advanced Imaging Research Mayo Clinic | 200 First Street SW | Rochester, MN 55905 | mayoclinic.org -----Original Message----- From: Neuroimaging [mailto:neuroimaging-bounces+reid.robert=mayo.edu at python.org] On Behalf Of Bennet Fauber Sent: Tuesday, July 04, 2017 12:17 PM To: Neuroimaging analysis in Python Subject: Re: [Neuroimaging] JSON-LD and DICOM? Oh, yes. That is very important. Converting to .nii is one of our main ways of insuring no leakage of any subject information -- not just PHI, but potentially names and other information about research subject that, while not regulated, would discourteous to expose. On Tue, Jul 4, 2017 at 1:05 PM, David Gutman wrote: > Just to chime in briefly.. one thing that wasn't mentioned re: DICOM is the > fact of potential PHI leaks. Ensuring any and all DICOM tags have no PHI > in it is an incredibly tedious/expensive undertaking, and at least for > those of us who use clinical scans for some of our work, the overhead > of trying to make sure we truly anonymized everything in the DICOM header is significant. > > Whereas in the case of NIFTI, as long as the filename doesn't contain > the embedded patient name , I can be pretty sure the files are "clean". > > This is particularly important when grad students are working on their > own laptops which are... not particularly secure. > > > > > On Tue, Jul 4, 2017 at 1:01 PM Chris Gorgolewski > wrote: >> >> I wonder if in the future it would also make sense to: >> >> 1) add option of creating sidecar BIDS compatible JSON files into >> nibabel (similar to what dcm2niix, dicm2nii, and mcverter are doing). >> This makes some sense since nibabel will become a dicom to nifti >> converter after dcmstack is merged. >> >> 2) store the same content in the header (for "future" compatibility) >> under a different namespace than "dcm" (would that work Satra? How >> would an example JSON-LD with both "dcm" and "bids" look like?) >> >> Not a huge priority, but something to think about. I am very glad >> that dcmstack is getting merged into nibabel. >> >> Best, >> Chris >> >> On Tue, Jul 4, 2017 at 12:47 PM, Satrajit Ghosh wrote: >>>> >>>> Excellent - that would be very helpful. Will y'all be able to >>>> define the @types as well as the @ids ? I guess that would be a >>>> lot more work. >>> >>> >>> it shouldn't be too hard to combine it with this: >>> >>> https://github.com/pydicom/pydicom/blob/master/pydicom/_dicom_dict.p >>> y >>> >>> which itself is generated from the dicom standard and private >>> dictionaries (these are not in karl's curation though and likely >>> varies by sequence and scanner software versions). >>> >>> https://github.com/pydicom/pydicom/tree/master/source/generate_dict >>> >>> cheers, >>> >>> satra >>> >>> _______________________________________________ >>> 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 > > -- > David A Gutman MD PhD > Assistant Professor of Neurology, Psychiatry & Biomedical Informatics > Emory University School of Medicine Staff Physician, Mental Health > Service Line Atlanta VA Medical Center > > _______________________________________________ > 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 From njvack at wisc.edu Wed Jul 5 11:38:33 2017 From: njvack at wisc.edu (Nate Vack) Date: Wed, 05 Jul 2017 15:38:33 +0000 Subject: [Neuroimaging] JSON-LD and DICOM? In-Reply-To: References: <2085d0ba-e774-1637-617d-be7cf9b2884a@upmc.fr> <90ff7947-0803-8724-a9b3-3bc0631a134c@upmc.fr> Message-ID: On Tue, Jul 4, 2017 at 12:13 PM David Gutman wrote: > Just to chime in briefly.. one thing that wasn't mentioned re: DICOM is > the fact of potential PHI leaks. Ensuring any and all DICOM tags have no > PHI in it is an incredibly tedious/expensive undertaking, and at least for > those of us who use clinical scans for some of our work, the overhead of > trying to make sure we truly anonymized everything in the DICOM header is > significant. > Indeed! I'd advocate for whatever tool transfers data from the DICOM headers to JSON to use, by default, a whitelisted set of tags to extract. Being able to supply a set of tags to anonymize at conversion time would also be excellent. Anyhow, big +1 to storing the metadata in a header in the file, plus good tooling for importing and exporting the data as text. Sidecars are easy to lose and make file handling code a lot more complicated. Overall, though: provenance data stored in headers is one of my favorite things about AFNI's toolchain. Best, -Nate -------------- next part -------------- An HTML attachment was scrubbed... URL: From dagutman at gmail.com Tue Jul 11 13:09:15 2017 From: dagutman at gmail.com (David Gutman) Date: Tue, 11 Jul 2017 17:09:15 +0000 Subject: [Neuroimaging] Catching up In-Reply-To: References: Message-ID: Thanks! I'll try it out.. I think we are about ready to gear this up.. Thanks.. Oh yeah.. also how do I load an image as a URL instead of a filename? I didn't know the syntax.. On Tue, Jul 11, 2017, 12:51 PM Ihar Halchuk wrote: > Hi David, > > nice to have news from you! Let's schedule a meeting on Thursday - July > 13, 2017 at 10.00 your time (17.00 my time)? > > Regarding the cache, you can manage it in the following way (Chrome): > 1) delete cache - use this way: from the ?Menu? (button in the > upper-right corner of the Chrome window), choose ?More Tools? > ?Clear > browsing data?? and clean cache there. > 2) disable cache - from the ?Menu? (button in the upper-right corner of > the Chrome window), choose ?More Tools? > ?Developer tools?. In openned > window under tab "Network" in upper part mark checkbox "Disable cache". > > Hope it will help. > > Waiting for your reply. > > > > 2017-07-11 3:09 GMT+03:00 David Gutman : > >> Ihar--- finally catching up on things, and wanted to schedule a meeting >> sometime this week to catch up. >> >> Also have a couple of questions for the "new" version of the faceted >> search tool---- so I realized that during debugging it must cache most of >> the database locally.. which made testing difficult. Do you know how I can >> "flush" whatever it's saving in the browser cache? I haven't used that >> before.. >> >> >> -- >> David A Gutman MD PhD >> Assistant Professor of Neurology, Psychiatry & Biomedical Informatics >> Emory University School of Medicine >> Staff Physician, Mental Health Service Line >> Atlanta VA Medical Center >> > > > > -- > Best regards, > Halchuk Ihar > Business analyst, > XB Software Ltd. > 3A, ?ollektornaya Street > 220030 Minsk, Belarus > Skype: ihar.halc > -- David A Gutman MD PhD Assistant Professor of Neurology, Psychiatry & Biomedical Informatics Emory University School of Medicine Staff Physician, Mental Health Service Line Atlanta VA Medical Center -------------- next part -------------- An HTML attachment was scrubbed... URL: From simone.poli.01 at gmail.com Tue Jul 11 14:47:45 2017 From: simone.poli.01 at gmail.com (Simone Poli) Date: Tue, 11 Jul 2017 20:47:45 +0200 Subject: [Neuroimaging] (no subject) Message-ID: I would like to subscribe to the mailing list -------------- next part -------------- An HTML attachment was scrubbed... URL: From arokem at gmail.com Tue Jul 11 18:31:54 2017 From: arokem at gmail.com (Ariel Rokem) Date: Tue, 11 Jul 2017 15:31:54 -0700 Subject: [Neuroimaging] (no subject) In-Reply-To: References: Message-ID: Welcome! You can sign up on this web-page: https://mail.python.org/mailman/listinfo/neuroimaging On Tue, Jul 11, 2017 at 11:47 AM, Simone Poli wrote: > I would like to subscribe to the mailing list > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christophe at pallier.org Thu Jul 13 09:40:19 2017 From: christophe at pallier.org (Christophe Pallier) Date: Thu, 13 Jul 2017 15:40:19 +0200 Subject: [Neuroimaging] affine issue (?) Message-ID: Hello, I have an nii image (a contrast computed by SPM, in the MNI space), which, according to SPM, has the following affine: >> V.mat 2 0 0 -74 0 2 0 -108 0 0 2 -66 0 0 0 1 However, the same image loaded with nibabel yields a different affine: [[ 2. 0. 0. -72.00000763] [ 0. 2. 0. -106. ] [ 0. 0. 2. -64. ] [ 0. 0. 0. 1. ]] Any hint? -- Christophe Pallier Personal web site: http://www.pallier.org Lab web site: http://www.unicog.org Email: christophe at pallier.org Tel: +33 (0) 1 69 08 79 34 Address: INSERM-CEA Cognitive Neuroimaging Lab, Neurospin, bat 145, 91191 Gif-sur-Yvette Cedex, FRANCE From jbpoline at gmail.com Thu Jul 13 09:50:16 2017 From: jbpoline at gmail.com (JB Poline) Date: Thu, 13 Jul 2017 06:50:16 -0700 Subject: [Neuroimaging] affine issue (?) In-Reply-To: References: Message-ID: Hey Sounds like a 0 (python) 1 (matlab) issue (with 1 giving a 2mm difference in the origin) ? Would be useful to have the image somewhere cheers JB On 13 July 2017 at 06:40, Christophe Pallier wrote: > Hello, > > I have an nii image (a contrast computed by SPM, in the MNI space), > which, according to SPM, has the following affine: > > >>> V.mat > 2 0 0 -74 > 0 2 0 -108 > 0 0 2 -66 > 0 0 0 1 > > > However, the same image loaded with nibabel yields a different affine: > [[ 2. 0. 0. -72.00000763] > [ 0. 2. 0. -106. ] > [ 0. 0. 2. -64. ] > [ 0. 0. 0. 1. ]] > > Any hint? > > -- > Christophe Pallier > > Personal web site: http://www.pallier.org > Lab web site: http://www.unicog.org > Email: christophe at pallier.org > Tel: +33 (0) 1 69 08 79 34 > > Address: > INSERM-CEA Cognitive Neuroimaging Lab, Neurospin, bat 145, > 91191 Gif-sur-Yvette Cedex, FRANCE > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging From matthew.brett at gmail.com Thu Jul 13 09:59:05 2017 From: matthew.brett at gmail.com (Matthew Brett) Date: Thu, 13 Jul 2017 14:59:05 +0100 Subject: [Neuroimaging] affine issue (?) In-Reply-To: References: Message-ID: Hi, On Thu, Jul 13, 2017 at 2:40 PM, Christophe Pallier wrote: > Hello, > > I have an nii image (a contrast computed by SPM, in the MNI space), > which, according to SPM, has the following affine: > > >>> V.mat > 2 0 0 -74 > 0 2 0 -108 > 0 0 2 -66 > 0 0 0 1 > > > However, the same image loaded with nibabel yields a different affine: > [[ 2. 0. 0. -72.00000763] > [ 0. 2. 0. -106. ] > [ 0. 0. 2. -64. ] > [ 0. 0. 0. 1. ]] Right - what JB said - the affine is the mapping from voxel coordinate to mm coordinate. For Matlab, the voxel coordinates are 1-based, so the first voxel is coordinate (1, 1, 1) whereas for Python (or C) the first coordinate is (0, 0, 0). For example, you can think of the Matlab affine as the composition of the translation taking the first coordinate to 0, 0, 0, followed by the Python affine: import numpy as np py_affine = np.array([[ 2., 0., 0., -72.00000763], [ 0., 2., 0., -106. ], [ 0., 0., 2., -64. ], [ 0., 0., 0., 1. ]]) from_111 = np.array([[1, 0, 0, -1], [0, 1, 0, -1], [0, 0, 1, -1], [0, 0, 0, 1]]) print(py_affine.dot(from_111)) This gives: [[ 2. 0. 0. -74.00000763] [ 0. 2. 0. -108. ] [ 0. 0. 2. -66. ] [ 0. 0. 0. 1. ]] Cheers, Matthew From christophe at pallier.org Thu Jul 13 10:00:48 2017 From: christophe at pallier.org (Christophe Pallier) Date: Thu, 13 Jul 2017 16:00:48 +0200 Subject: [Neuroimaging] affine issue (?) In-Reply-To: References: Message-ID: Thanks JB & Matthew !!! I should have thought about it... Chris -- Christophe Pallier Personal web site: http://www.pallier.org Lab web site: http://www.unicog.org Email: christophe at pallier.org Tel: +33 (0) 1 69 08 79 34 Address: INSERM-CEA Cognitive Neuroimaging Lab, Neurospin, bat 145, 91191 Gif-sur-Yvette Cedex, FRANCE On Thu, Jul 13, 2017 at 3:59 PM, Matthew Brett wrote: > Hi, > > On Thu, Jul 13, 2017 at 2:40 PM, Christophe Pallier > wrote: >> Hello, >> >> I have an nii image (a contrast computed by SPM, in the MNI space), >> which, according to SPM, has the following affine: >> >> >>>> V.mat >> 2 0 0 -74 >> 0 2 0 -108 >> 0 0 2 -66 >> 0 0 0 1 >> >> >> However, the same image loaded with nibabel yields a different affine: >> [[ 2. 0. 0. -72.00000763] >> [ 0. 2. 0. -106. ] >> [ 0. 0. 2. -64. ] >> [ 0. 0. 0. 1. ]] > > Right - what JB said - the affine is the mapping from voxel coordinate > to mm coordinate. For Matlab, the voxel coordinates are 1-based, so > the first voxel is coordinate (1, 1, 1) whereas for Python (or C) the > first coordinate is (0, 0, 0). > > For example, you can think of the Matlab affine as the composition of > the translation taking the first coordinate to 0, 0, 0, followed by > the Python affine: > > import numpy as np > py_affine = np.array([[ 2., 0., 0., -72.00000763], > [ 0., 2., 0., -106. ], > [ 0., 0., 2., -64. ], > [ 0., 0., 0., 1. ]]) > > from_111 = np.array([[1, 0, 0, -1], > [0, 1, 0, -1], > [0, 0, 1, -1], > [0, 0, 0, 1]]) > > print(py_affine.dot(from_111)) > > This gives: > > [[ 2. 0. 0. -74.00000763] > [ 0. 2. 0. -108. ] > [ 0. 0. 2. -66. ] > [ 0. 0. 0. 1. ]] > > Cheers, > > Matthew > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging From greynell at gmail.com Sat Jul 22 13:30:48 2017 From: greynell at gmail.com (=?UTF-8?Q?Gabriel_Reyn=C3=A9s?=) Date: Sat, 22 Jul 2017 19:30:48 +0200 Subject: [Neuroimaging] nibabel: probelm reading a nii.gz Message-ID: Hello, I have some troubles reading a nii.gz with nibabel. I get the error: "nibabel.filebasedimages.ImageFileError: Cannot work out file type of" So far I tried to unzip the file to a nii, but I did not achieve anything. The image is not corrupt as I can see it using ImageJ. It only contains a mask, so maybe is lacking some field nibabel is searching for? I just need the mask to post-process the image, so I don't need any other field. Any idea how to solve this problem? Thank you for your time, Gabriel -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Sat Jul 22 18:16:24 2017 From: matthew.brett at gmail.com (Matthew Brett) Date: Sat, 22 Jul 2017 23:16:24 +0100 Subject: [Neuroimaging] nibabel: probelm reading a nii.gz In-Reply-To: References: Message-ID: Hi, Can you put the image somewhere where we/I can get it? Cheers, Matthew On 22 Jul 2017 18:31, "Gabriel Reyn?s" wrote: Hello, I have some troubles reading a nii.gz with nibabel. I get the error: "nibabel.filebasedimages.ImageFileError: Cannot work out file type of" So far I tried to unzip the file to a nii, but I did not achieve anything. The image is not corrupt as I can see it using ImageJ. It only contains a mask, so maybe is lacking some field nibabel is searching for? I just need the mask to post-process the image, so I don't need any other field. Any idea how to solve this problem? Thank you for your time, Gabriel _______________________________________________ Neuroimaging mailing list Neuroimaging at python.org https://mail.python.org/mailman/listinfo/neuroimaging -------------- next part -------------- An HTML attachment was scrubbed... URL: From greynell at gmail.com Sun Jul 23 06:49:05 2017 From: greynell at gmail.com (=?UTF-8?Q?Gabriel_Reyn=C3=A9s?=) Date: Sun, 23 Jul 2017 12:49:05 +0200 Subject: [Neuroimaging] nibabel: probelm reading a nii.gz In-Reply-To: References: Message-ID: Hi, I uploaded to drive the nii.gz and the unziped .nii. Here is the link to download: https://drive.google.com/file/d/0B1t55gf3wT7fSURVemRaYVl2S0k/view?usp=sharing Thanks for helping. Bests, Gabriel On Sun, Jul 23, 2017 at 12:16 AM, Matthew Brett wrote: > Hi, > > Can you put the image somewhere where we/I can get it? > > Cheers, > > Matthew > > On 22 Jul 2017 18:31, "Gabriel Reyn?s" wrote: > > Hello, > > I have some troubles reading a nii.gz with nibabel. I get the error: > "nibabel.filebasedimages.ImageFileError: Cannot work out file type of" > > So far I tried to unzip the file to a nii, but I did not achieve anything. > The image is not corrupt as I can see it using ImageJ. > It only contains a mask, so maybe is lacking some field nibabel is > searching for? I just need the mask to post-process the image, so I don't > need any other field. > > Any idea how to solve this problem? > > > Thank you for your time, > > Gabriel > > _______________________________________________ > 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 reynoldr at mail.nih.gov Mon Jul 24 08:50:33 2017 From: reynoldr at mail.nih.gov (Reynolds, Richard C. (NIH/NIMH) [E]) Date: Mon, 24 Jul 2017 12:50:33 +0000 Subject: [Neuroimaging] nibabel: probelm reading a nii.gz In-Reply-To: References: , Message-ID: Hi Gabriel, The magic string in the header is stored as "\0n+1", rather than "n+1\0". - rick ________________________________ From: Gabriel Reyn?s Sent: Sunday, July 23, 2017 6:49:05 AM To: Neuroimaging analysis in Python Subject: Re: [Neuroimaging] nibabel: probelm reading a nii.gz Hi, I uploaded to drive the nii.gz and the unziped .nii. Here is the link to download: https://drive.google.com/file/d/0B1t55gf3wT7fSURVemRaYVl2S0k/view?usp=sharing Thanks for helping. Bests, Gabriel On Sun, Jul 23, 2017 at 12:16 AM, Matthew Brett > wrote: Hi, Can you put the image somewhere where we/I can get it? Cheers, Matthew On 22 Jul 2017 18:31, "Gabriel Reyn?s" > wrote: Hello, I have some troubles reading a nii.gz with nibabel. I get the error: "nibabel.filebasedimages.ImageFileError: Cannot work out file type of" So far I tried to unzip the file to a nii, but I did not achieve anything. The image is not corrupt as I can see it using ImageJ. It only contains a mask, so maybe is lacking some field nibabel is searching for? I just need the mask to post-process the image, so I don't need any other field. Any idea how to solve this problem? Thank you for your time, Gabriel _______________________________________________ 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 greynell at gmail.com Mon Jul 24 09:43:26 2017 From: greynell at gmail.com (=?UTF-8?Q?Gabriel_Reyn=C3=A9s?=) Date: Mon, 24 Jul 2017 15:43:26 +0200 Subject: [Neuroimaging] nibabel: probelm reading a nii.gz In-Reply-To: References: Message-ID: Thank Richard, Is there any way to modify this? The nii file would be better, but if not the code. I tried to follow the code of nibabel load function but I am geting lost. Thanks Bests, Gabriel On Mon, Jul 24, 2017 at 2:50 PM, Reynolds, Richard C. (NIH/NIMH) [E] < reynoldr at mail.nih.gov> wrote: > Hi Gabriel, > > > The magic string in the header is stored as > > "\0n+1", rather than "n+1\0". > > > - rick > > > ------------------------------ > *From:* Gabriel Reyn?s > *Sent:* Sunday, July 23, 2017 6:49:05 AM > *To:* Neuroimaging analysis in Python > *Subject:* Re: [Neuroimaging] nibabel: probelm reading a nii.gz > > Hi, > > I uploaded to drive the nii.gz and the unziped .nii. Here is the link to > download: https://drive.google.com/file/d/0B1t55gf3wT7fSURVemRaYVl2S0k/ > view?usp=sharing > > Thanks for helping. > > Bests, > > > Gabriel > > On Sun, Jul 23, 2017 at 12:16 AM, Matthew Brett > wrote: > >> Hi, >> >> Can you put the image somewhere where we/I can get it? >> >> Cheers, >> >> Matthew >> >> On 22 Jul 2017 18:31, "Gabriel Reyn?s" wrote: >> >> Hello, >> >> I have some troubles reading a nii.gz with nibabel. I get the error: >> "nibabel.filebasedimages.ImageFileError: Cannot work out file type of" >> >> So far I tried to unzip the file to a nii, but I did not achieve >> anything. The image is not corrupt as I can see it using ImageJ. >> It only contains a mask, so maybe is lacking some field nibabel is >> searching for? I just need the mask to post-process the image, so I don't >> need any other field. >> >> Any idea how to solve this problem? >> >> >> Thank you for your time, >> >> Gabriel >> >> _______________________________________________ >> 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 reynoldr at mail.nih.gov Mon Jul 24 13:39:39 2017 From: reynoldr at mail.nih.gov (Reynolds, Richard C. (NIH/NIMH) [E]) Date: Mon, 24 Jul 2017 17:39:39 +0000 Subject: [Neuroimaging] nibabel: probelm reading a nii.gz In-Reply-To: References: , Message-ID: Hi Gabriel, It is simple to modify with the nifti_tool program (from the nifticlib library), but I don't know whether you have that, e.g. nifti_tool -mod_hdr -mod_field magic 'n+1' \ -infiles C1_Rel_thres40.0.nii -prefix NEW.nii I don't actually use these python tools, but just thought to report on the NIFTI problem, expecting that the software that generated your dataset might need a little fix. - rick ________________________________ From: Gabriel Reyn?s Sent: Monday, July 24, 2017 9:43 AM To: Neuroimaging analysis in Python Subject: Re: [Neuroimaging] nibabel: probelm reading a nii.gz Thank Richard, Is there any way to modify this? The nii file would be better, but if not the code. I tried to follow the code of nibabel load function but I am geting lost. Thanks Bests, Gabriel On Mon, Jul 24, 2017 at 2:50 PM, Reynolds, Richard C. (NIH/NIMH) [E] > wrote: Hi Gabriel, The magic string in the header is stored as "\0n+1", rather than "n+1\0". - rick ________________________________ From: Gabriel Reyn?s > Sent: Sunday, July 23, 2017 6:49:05 AM To: Neuroimaging analysis in Python Subject: Re: [Neuroimaging] nibabel: probelm reading a nii.gz Hi, I uploaded to drive the nii.gz and the unziped .nii. Here is the link to download: https://drive.google.com/file/d/0B1t55gf3wT7fSURVemRaYVl2S0k/view?usp=sharing Thanks for helping. Bests, Gabriel On Sun, Jul 23, 2017 at 12:16 AM, Matthew Brett > wrote: Hi, Can you put the image somewhere where we/I can get it? Cheers, Matthew On 22 Jul 2017 18:31, "Gabriel Reyn?s" > wrote: Hello, I have some troubles reading a nii.gz with nibabel. I get the error: "nibabel.filebasedimages.ImageFileError: Cannot work out file type of" So far I tried to unzip the file to a nii, but I did not achieve anything. The image is not corrupt as I can see it using ImageJ. It only contains a mask, so maybe is lacking some field nibabel is searching for? I just need the mask to post-process the image, so I don't need any other field. Any idea how to solve this problem? Thank you for your time, Gabriel _______________________________________________ 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 matthew.brett at gmail.com Mon Jul 24 14:19:23 2017 From: matthew.brett at gmail.com (Matthew Brett) Date: Mon, 24 Jul 2017 19:19:23 +0100 Subject: [Neuroimaging] nibabel: probelm reading a nii.gz In-Reply-To: References: Message-ID: Hi, On Mon, Jul 24, 2017 at 6:39 PM, Reynolds, Richard C. (NIH/NIMH) [E] wrote: > Hi Gabriel, > > > It is simple to modify with the nifti_tool program (from > > the nifticlib library), but I don't know whether you have > > that, e.g. > > > nifti_tool -mod_hdr -mod_field magic 'n+1' \ > > -infiles C1_Rel_thres40.0.nii -prefix NEW.nii Thanks - that's one easy way to do the fix. If you wanted to use nibabel, you could also do the following: """ import nibabel as nib fname = 'C1_Rel_thres40.0.nii.gz' # The following just selects the right object to open the file - in # this case zipfile.ZipFile with nib.openers.Opener(fname) as fobj: hdr = nib.Nifti1Header.from_fileobj(fobj, check=False) # don't raise error data = hdr.data_from_fileobj(fobj) hdr['magic'] = b'n+1\x00' img = nib.Nifti1Image(data, None, hdr) nib.save(img, 'fixed.nii.gz') """ Cheers, Matthew From greynell at gmail.com Wed Jul 26 07:08:04 2017 From: greynell at gmail.com (=?UTF-8?Q?Gabriel_Reyn=C3=A9s?=) Date: Wed, 26 Jul 2017 13:08:04 +0200 Subject: [Neuroimaging] nibabel: probelm reading a nii.gz In-Reply-To: References: Message-ID: Problem solved, worked wonderfully, thanks! Cheers, Gabriel On Mon, Jul 24, 2017 at 8:19 PM, Matthew Brett wrote: > Hi, > > On Mon, Jul 24, 2017 at 6:39 PM, Reynolds, Richard C. (NIH/NIMH) [E] > wrote: > > Hi Gabriel, > > > > > > It is simple to modify with the nifti_tool program (from > > > > the nifticlib library), but I don't know whether you have > > > > that, e.g. > > > > > > nifti_tool -mod_hdr -mod_field magic 'n+1' \ > > > > -infiles C1_Rel_thres40.0.nii -prefix NEW.nii > > Thanks - that's one easy way to do the fix. > > If you wanted to use nibabel, you could also do the following: > > """ > import nibabel as nib > > fname = 'C1_Rel_thres40.0.nii.gz' > > # The following just selects the right object to open the file - in > # this case zipfile.ZipFile > with nib.openers.Opener(fname) as fobj: > hdr = nib.Nifti1Header.from_fileobj(fobj, check=False) # don't raise > error > data = hdr.data_from_fileobj(fobj) > hdr['magic'] = b'n+1\x00' > img = nib.Nifti1Image(data, None, hdr) > nib.save(img, 'fixed.nii.gz') > """ > > 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 jbpoline at gmail.com Wed Jul 26 09:45:56 2017 From: jbpoline at gmail.com (JB Poline) Date: Wed, 26 Jul 2017 09:45:56 -0400 Subject: [Neuroimaging] Fwd: [bids-discussion] Make DelayTime compulsory for all sparse acquisitions In-Reply-To: <2017072521355953127853@osu.edu> References: <2017072521355953127853@osu.edu> Message-ID: Hey Forwarding this or the relevance with nibabel and others - I remember a similar-ish discussion Cheers JB ---------- Forwarded message ---------- From: Xiangrui Li Date: 25 July 2017 at 22:35 Subject: Re: [bids-discussion] Make DelayTime compulsory for all sparse acquisitions To: "bids-discussion at googlegroups.com" Talking about sparse acquisition, I would like to mention my recent experience related to multiband sparse-like sequence. If this has not been brought up before, I would like to propose an optional field to encode the timing of NIfTI's 4th dimension. We use the CMRR multiband sequence, which allows to set several TRs as "quiet" period without image acquisition, so one can play sound during this period. For example, we use TR of 1 second, and acquire 10 volumes continuously, then have 4-TR quiet period. This results in 14-second cycles with only 10-second of image data in each cycle. The dicom files have discontinuity in InstanceNumber, like 1 to 10, then jump to 15 to 24 etc. Most NIfTI converters quietly convert these files. The result NIfTI is actually not strictly NIfTI compliant, since its 4th dim (timing) has variable intervals. My matlab-based converter (dicm2nii.m) would have failed to convert, complaining missing files. I just updated it, allowing missing files with regular spacing (missing 4 in every 14 files in above example), while it gives a warning for the InstanceNumber discontinuity, and stores the InstanceNumber in a field in NIfTI extension. I was thinking to pad zeros for those missing volumes to make it NIfTI compliant, but it seems dumb to increase the file size. After asking opinion from some auditory people, I think it is better to make it consistent with other NIfTI converters, so everyone is violating the NIfTI rule :) The field I am proposing can be called something like "TimeIndices". It has the same length as the 4th dim of NIfTI image. For the above example, it can be those InstanceNumber minus 1 (0-based), or we call it a different name and store the time in seconds: (InstanceNumber-1) * TR. Any thoughts, comments? Thanks. _____________ Xiangrui Li, Ph.D. Center for Cognitive and Behavioral Brain Imaging The Ohio State University Phone: 614-292-1847 From: Satrajit Ghosh Date: 2017-07-25 18:15 To: bids-discussion at googlegroups.com Subject: [bids-discussion] Make DelayTime compulsory for all sparse acquisitions hi folks, chris and i were chatting about a dataset with a sparse acquisition protocol: collect n-slices wait m seconds, collect again. on siemens scanners this is implemented using TR and delay, with TA (time of acquisition) = TR - delay. the current bids specification says if slice timing is provided, DelayTime is not required. i would like to propose that DelayTime is provided for all sparse acquisitions independent of slice timing. here is the reasoning. as it stands i have to write code that kind of looks like this: if multiband_sparse: good_luck_figuring_out_slice_timing is correct or not. (on our scanner siemens generated incorrect slice timing numbers). else: TA = max(slice_times) + np.average(np.diff(sort(slice_times))) with DelayTime, it would always be: RepetitionTime - DelayTime. let any discussions ensue. cheers, satra -- You received this message because you are subscribed to the Google Groups "bids-discussion" group. To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe at googlegroups.com. To post to this group, send email to bids-discussion at googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/bids-discussion/CA%2BA4wOnk%3DJvddeWSmZL1puexaCMA-Y_YyQbKjYTtPJ1kS_YcZg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "bids-discussion" group. To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe at googlegroups.com. To post to this group, send email to bids-discussion at googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/bids-discussion/2017072521355953127853%40osu.edu. For more options, visit https://groups.google.com/d/optout. From jarblank1200 at gmail.com Thu Jul 27 09:41:13 2017 From: jarblank1200 at gmail.com (Bai Haohao) Date: Thu, 27 Jul 2017 21:41:13 +0800 Subject: [Neuroimaging] Fwd: [Freesurfer] negative header after preproc-sess In-Reply-To: References: Message-ID: Dear nibabel experts, I forward this email to nibabel mailing list because I think it is related to nibabel, even this problem is caused by nifti standard and freesurfer. I am using nibabel to load data after freesurfer "*preproc-sess -suface self" *and I get negative dim(-1 1 1, see origin email for detail), which makes nibabel.get_data() failed, but freesurfer first level analysis can be done successfully, in my view it means freesurfer can get data from this bad header. I find a way to solve it is by using "mri_convert *.nii.gz *.mgz", then nibabel could get data from *.mgz. But I think if nibabel could support getting data from negative header file would be more helpful. Just some undevelopped thoughts, I hope I express it clearly. Best, Bai Haohao ---------- Forwarded message ---------- From: Douglas Greve Date: Thu, Jul 6, 2017 at 7:07 AM Subject: Re: [Freesurfer] negative header after preproc-sess To: freesurfer at nmr.mgh.harvard.edu When the nifti standard was adopted, they used a short int to represent the dimensions. Unfortunately, this only allows for a maximum dimension of 32k, which is not big enough for surfaces. So I hacked the FS nifti format to put a -1 as the first dim at which point the FS code will go to another place in the header to get the spatial dimensions. It is possible to reshape the spatial dimensions as long as the largest prime factor is less than 32k (see mri_surf2surf with --reshape option). Other than that, you might ask the nibabel people to program the same hack. On 6/25/17 6:48 AM, Bai Haohao wrote: Hello Freesurfer experts, I am running my data with preproc-sess to project my func data to individual anatomy file, and the command shows as below: preproc-sess -sf ${Sesslist} -fsd "bold" -surface self lhrh -fwhm 0 -per-run -force And the subjectname point to the subject dir that created after recon-all. After the running completed, I try to load data from fmcpr.sm0.self.lh.nii.gz with nibabel, and I get this error info: >>> f.get_data() Traceback (most recent call last): File "", line 1, in File "/usr/lib/pymodules/python2.7/nibabel/spatialimages.py", line 341, in get_data return np.asanyarray(self._data) File "/usr/lib/python2.7/dist-packages/numpy/core/numeric.py", line 512, in asanyarray return array(a, dtype, copy=False, order=order, subok=True) File "/usr/lib/pymodules/python2.7/nibabel/arrayproxy.py", line 55, in __array__ self._data = self._read_data() File "/usr/lib/pymodules/python2.7/nibabel/arrayproxy.py", line 60, in _read_data data = self.header.data_from_fileobj(fileobj) File "/usr/lib/pymodules/python2.7/nibabel/analyze.py", line 486, in data_from_fileobj data = self.raw_data_from_fileobj(fileobj) File "/usr/lib/pymodules/python2.7/nibabel/analyze.py", line 458, in raw_data_from_fileobj return array_from_file(shape, dtype, fileobj, offset) File "/usr/lib/pymodules/python2.7/nibabel/volumeutils.py", line 493, in array_from_file raise IOError(msg) IOError: Expected -1804 bytes, got 264809160 bytes from file "fmcpr.vol2surf.lh.nii.gz" - could the file be damaged? Then I check the file header by nibabel, and I get this: >>> print(f.get_header()) object, endian='<' sizeof_hdr : 348 data_type : db_name : extents : 0 session_error : 0 regular : dim_info : 0 dim : [ 4 -1 1 1 451 1 1 1] intent_p1 : 0.0 intent_p2 : 0.0 intent_p3 : 0.0 intent_code : none datatype : float32 bitpix : 32 slice_start : 0 pixdim : [-1. 1. 1. 1. 2.00000072 1. 1. 1. ] vox_offset : 352.0 scl_slope : 0.0 scl_inter : 0.0 slice_end : 0 slice_code : unknown xyzt_units : 10 cal_max : 0.0 cal_min : 0.0 slice_duration : 0.0 toffset : 0.0 glmax : 0 glmin : 146790 descrip : FreeSurfer May 13 2013 aux_file : qform_code : scanner sform_code : scanner quatern_b : -0.0115927606821 quatern_c : -0.996071338654 quatern_d : -0.0864994972944 qoffset_x : 73344.5546875 qoffset_y : -1492.14978027 qoffset_z : -2311.28955078 srow_x : [ -9.99280393e-01 2.56918129e-02 2.79041883e-02 7.33445547e+04] srow_y : [ 2.04970520e-02 9.84766901e-01 -1.72667429e-01 -1.49214978e+03] srow_z : [ 3.19152586e-02 1.71971247e-01 9.84584868e-01 -2.31128955e+03] intent_name : magic : n+1 Note that the dim has value -1, but when I use -surface fsaverage, the dim is correct(show as below): dim : [ 4 27307 1 6 451 1 1 1] And I read the source code, the difference between self and fsaverage is appeared when running rawfunc2surf-sess, and log files are attached. I have tried many commands to load data from fmcpr.sm0.self.lh.nii.gz, such as fslview, freeview, mri_convert, mri_surf2surf, ... and only tksurfer could read this file by -timecourse fmcpr.sm0.self.lh.nii.gz. I want to figure out how could I fix it, and any suggestion would be helpful. Thanks in advance, Bai Haohao Version info: System: ubuntu-16.04.1-server-amd64 Freesurfer: freesurfer-Linux-centos4_x86_64-stable-pub-v5.3.0-HCP nibabel: python-nibabel 1.2.2-1 _______________________________________________ Freesurfer mailing listFreesurfer at nmr.mgh.harvard.eduhttps://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer _______________________________________________ Freesurfer mailing list Freesurfer at nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From effigies at bu.edu Thu Jul 27 10:20:03 2017 From: effigies at bu.edu (Christopher Markiewicz) Date: Thu, 27 Jul 2017 10:20:03 -0400 Subject: [Neuroimaging] Fwd: [Freesurfer] negative header after preproc-sess In-Reply-To: References: Message-ID: Looks like the FreeSurfer hack needs to be expanded to more cases. Could you go ahead and open an issue on https://github.com/nipy/nibabel/issues? On Thu, Jul 27, 2017 at 9:41 AM, Bai Haohao wrote: > Dear nibabel experts, > > I forward this email to nibabel mailing list because I think it is related > to nibabel, even this problem is caused by nifti standard and freesurfer. > > I am using nibabel to load data after freesurfer "*preproc-sess -suface > self" *and I get negative dim(-1 1 1, see origin email for detail), which > makes nibabel.get_data() failed, but freesurfer first level analysis can be > done successfully, in my view it means freesurfer can get data from this > bad header. > > I find a way to solve it is by using "mri_convert *.nii.gz *.mgz", then > nibabel could get data from *.mgz. But I think if nibabel could support > getting data from negative header file would be more helpful. > > Just some undevelopped thoughts, I hope I express it clearly. > > Best, > > Bai Haohao > > > > ---------- Forwarded message ---------- > From: Douglas Greve > Date: Thu, Jul 6, 2017 at 7:07 AM > Subject: Re: [Freesurfer] negative header after preproc-sess > To: freesurfer at nmr.mgh.harvard.edu > > > When the nifti standard was adopted, they used a short int to represent > the dimensions. Unfortunately, this only allows for a maximum dimension of > 32k, which is not big enough for surfaces. So I hacked the FS nifti format > to put a -1 as the first dim at which point the FS code will go to another > place in the header to get the spatial dimensions. It is possible to > reshape the spatial dimensions as long as the largest prime factor is less > than 32k (see mri_surf2surf with --reshape option). Other than that, you > might ask the nibabel people to program the same hack. > > On 6/25/17 6:48 AM, Bai Haohao wrote: > > Hello Freesurfer experts, > > I am running my data with preproc-sess to project my func data to > individual anatomy file, and the command shows as below: > > preproc-sess -sf ${Sesslist} -fsd "bold" -surface self lhrh -fwhm 0 > -per-run -force > > > And the subjectname point to the subject dir that created after recon-all. > > After the running completed, I try to load data from > fmcpr.sm0.self.lh.nii.gz with nibabel, and I get this error info: > > >>> f.get_data() > Traceback (most recent call last): > File "", line 1, in > File "/usr/lib/pymodules/python2.7/nibabel/spatialimages.py", line 341, > in get_data > return np.asanyarray(self._data) > File "/usr/lib/python2.7/dist-packages/numpy/core/numeric.py", line > 512, in asanyarray > return array(a, dtype, copy=False, order=order, subok=True) > File "/usr/lib/pymodules/python2.7/nibabel/arrayproxy.py", line 55, in > __array__ > self._data = self._read_data() > File "/usr/lib/pymodules/python2.7/nibabel/arrayproxy.py", line 60, in > _read_data > data = self.header.data_from_fileobj(fileobj) > File "/usr/lib/pymodules/python2.7/nibabel/analyze.py", line 486, in > data_from_fileobj > data = self.raw_data_from_fileobj(fileobj) > File "/usr/lib/pymodules/python2.7/nibabel/analyze.py", line 458, in > raw_data_from_fileobj > return array_from_file(shape, dtype, fileobj, offset) > File "/usr/lib/pymodules/python2.7/nibabel/volumeutils.py", line 493, > in array_from_file > raise IOError(msg) > IOError: Expected -1804 bytes, got 264809160 bytes from file > "fmcpr.vol2surf.lh.nii.gz" > - could the file be damaged? > > > Then I check the file header by nibabel, and I get this: > > > >>> print(f.get_header()) > object, endian='<' > sizeof_hdr : 348 > data_type : > db_name : > extents : 0 > session_error : 0 > regular : > dim_info : 0 > dim : [ 4 -1 1 1 451 1 1 1] > intent_p1 : 0.0 > intent_p2 : 0.0 > intent_p3 : 0.0 > intent_code : none > datatype : float32 > bitpix : 32 > slice_start : 0 > pixdim : [-1. 1. 1. 1. > 2.00000072 1. 1. > 1. ] > vox_offset : 352.0 > scl_slope : 0.0 > scl_inter : 0.0 > slice_end : 0 > slice_code : unknown > xyzt_units : 10 > cal_max : 0.0 > cal_min : 0.0 > slice_duration : 0.0 > toffset : 0.0 > glmax : 0 > glmin : 146790 > descrip : FreeSurfer May 13 2013 > aux_file : > qform_code : scanner > sform_code : scanner > quatern_b : -0.0115927606821 > quatern_c : -0.996071338654 > quatern_d : -0.0864994972944 > qoffset_x : 73344.5546875 > qoffset_y : -1492.14978027 > qoffset_z : -2311.28955078 > srow_x : [ -9.99280393e-01 2.56918129e-02 2.79041883e-02 > 7.33445547e+04] > srow_y : [ 2.04970520e-02 9.84766901e-01 -1.72667429e-01 > -1.49214978e+03] > srow_z : [ 3.19152586e-02 1.71971247e-01 9.84584868e-01 > -2.31128955e+03] > intent_name : > magic : n+1 > > > > > Note that the dim has value -1, but when I use -surface fsaverage, the dim > is correct(show as below): > > dim : [ 4 27307 1 6 451 1 1 1] > > > And I read the source code, the difference between self and fsaverage is > appeared when running rawfunc2surf-sess, and log files are attached. > > I have tried many commands to load data from fmcpr.sm0.self.lh.nii.gz, > such as fslview, freeview, mri_convert, mri_surf2surf, ... > > and only tksurfer could read this file by -timecourse > fmcpr.sm0.self.lh.nii.gz. > > I want to figure out how could I fix it, and any suggestion would be > helpful. > > Thanks in advance, > > Bai Haohao > > > Version info: > System: ubuntu-16.04.1-server-amd64 > Freesurfer: freesurfer-Linux-centos4_x86_64-stable-pub-v5.3.0-HCP > nibabel: python-nibabel 1.2.2-1 > > > > _______________________________________________ > Freesurfer mailing listFreesurfer at nmr.mgh.harvard.eduhttps://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer > > > > _______________________________________________ > Freesurfer mailing list > Freesurfer at nmr.mgh.harvard.edu > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer > > > 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. > > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From reynoldr at mail.nih.gov Thu Jul 27 10:18:06 2017 From: reynoldr at mail.nih.gov (Reynolds, Richard C. (NIH/NIMH) [E]) Date: Thu, 27 Jul 2017 14:18:06 +0000 Subject: [Neuroimaging] Fwd: [Freesurfer] negative header after preproc-sess In-Reply-To: References: , Message-ID: This seems like an appropriate case to be using the NIFTI-2 standard, which uses 64-bit values rather than the 16-bits for NIFTI-1 (which was done just to keep it similar to ANALYZE). For that matter, GIFTI was made to be the surface alternative to NIFTI, and FreeSurfer supports it, as does nibabel, it seems. Even without those options, it seems like FreeSurfer can still output what you want in a useful format. Breaking the NIFTI-1 standard is causing you trouble. Maybe propagating that is not necessary. - rick ________________________________ From: Bai Haohao Sent: Thursday, July 27, 2017 9:41:13 AM To: neuroimaging at python.org Subject: [Neuroimaging] Fwd: [Freesurfer] negative header after preproc-sess Dear nibabel experts, I forward this email to nibabel mailing list because I think it is related to nibabel, even this problem is caused by nifti standard and freesurfer. I am using nibabel to load data after freesurfer "preproc-sess -suface self" and I get negative dim(-1 1 1, see origin email for detail), which makes nibabel.get_data() failed, but freesurfer first level analysis can be done successfully, in my view it means freesurfer can get data from this bad header. I find a way to solve it is by using "mri_convert *.nii.gz *.mgz", then nibabel could get data from *.mgz. But I think if nibabel could support getting data from negative header file would be more helpful. Just some undevelopped thoughts, I hope I express it clearly. Best, Bai Haohao ---------- Forwarded message ---------- From: Douglas Greve > Date: Thu, Jul 6, 2017 at 7:07 AM Subject: Re: [Freesurfer] negative header after preproc-sess To: freesurfer at nmr.mgh.harvard.edu When the nifti standard was adopted, they used a short int to represent the dimensions. Unfortunately, this only allows for a maximum dimension of 32k, which is not big enough for surfaces. So I hacked the FS nifti format to put a -1 as the first dim at which point the FS code will go to another place in the header to get the spatial dimensions. It is possible to reshape the spatial dimensions as long as the largest prime factor is less than 32k (see mri_surf2surf with --reshape option). Other than that, you might ask the nibabel people to program the same hack. On 6/25/17 6:48 AM, Bai Haohao wrote: Hello Freesurfer experts, I am running my data with preproc-sess to project my func data to individual anatomy file, and the command shows as below: preproc-sess -sf ${Sesslist} -fsd "bold" -surface self lhrh -fwhm 0 -per-run -force And the subjectname point to the subject dir that created after recon-all. After the running completed, I try to load data from fmcpr.sm0.self.lh.nii.gz with nibabel, and I get this error info: >>> f.get_data() Traceback (most recent call last): File "", line 1, in File "/usr/lib/pymodules/python2.7/nibabel/spatialimages.py", line 341, in get_data return np.asanyarray(self._data) File "/usr/lib/python2.7/dist-packages/numpy/core/numeric.py", line 512, in asanyarray return array(a, dtype, copy=False, order=order, subok=True) File "/usr/lib/pymodules/python2.7/nibabel/arrayproxy.py", line 55, in __array__ self._data = self._read_data() File "/usr/lib/pymodules/python2.7/nibabel/arrayproxy.py", line 60, in _read_data data = self.header.data_from_fileobj(fileobj) File "/usr/lib/pymodules/python2.7/nibabel/analyze.py", line 486, in data_from_fileobj data = self.raw_data_from_fileobj(fileobj) File "/usr/lib/pymodules/python2.7/nibabel/analyze.py", line 458, in raw_data_from_fileobj return array_from_file(shape, dtype, fileobj, offset) File "/usr/lib/pymodules/python2.7/nibabel/volumeutils.py", line 493, in array_from_file raise IOError(msg) IOError: Expected -1804 bytes, got 264809160 bytes from file "fmcpr.vol2surf.lh.nii.gz" - could the file be damaged? Then I check the file header by nibabel, and I get this: >>> print(f.get_header()) object, endian='<' sizeof_hdr : 348 data_type : db_name : extents : 0 session_error : 0 regular : dim_info : 0 dim : [ 4 -1 1 1 451 1 1 1] intent_p1 : 0.0 intent_p2 : 0.0 intent_p3 : 0.0 intent_code : none datatype : float32 bitpix : 32 slice_start : 0 pixdim : [-1. 1. 1. 1. 2.00000072 1. 1. 1. ] vox_offset : 352.0 scl_slope : 0.0 scl_inter : 0.0 slice_end : 0 slice_code : unknown xyzt_units : 10 cal_max : 0.0 cal_min : 0.0 slice_duration : 0.0 toffset : 0.0 glmax : 0 glmin : 146790 descrip : FreeSurfer May 13 2013 aux_file : qform_code : scanner sform_code : scanner quatern_b : -0.0115927606821 quatern_c : -0.996071338654 quatern_d : -0.0864994972944 qoffset_x : 73344.5546875 qoffset_y : -1492.14978027 qoffset_z : -2311.28955078 srow_x : [ -9.99280393e-01 2.56918129e-02 2.79041883e-02 7.33445547e+04] srow_y : [ 2.04970520e-02 9.84766901e-01 -1.72667429e-01 -1.49214978e+03] srow_z : [ 3.19152586e-02 1.71971247e-01 9.84584868e-01 -2.31128955e+03] intent_name : magic : n+1 Note that the dim has value -1, but when I use -surface fsaverage, the dim is correct(show as below): dim : [ 4 27307 1 6 451 1 1 1] And I read the source code, the difference between self and fsaverage is appeared when running rawfunc2surf-sess, and log files are attached. I have tried many commands to load data from fmcpr.sm0.self.lh.nii.gz, such as fslview, freeview, mri_convert, mri_surf2surf, ... and only tksurfer could read this file by -timecourse fmcpr.sm0.self.lh.nii.gz. I want to figure out how could I fix it, and any suggestion would be helpful. Thanks in advance, Bai Haohao Version info: System: ubuntu-16.04.1-server-amd64 Freesurfer: freesurfer-Linux-centos4_x86_64-stable-pub-v5.3.0-HCP nibabel: python-nibabel 1.2.2-1 _______________________________________________ Freesurfer mailing list Freesurfer at nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer _______________________________________________ Freesurfer mailing list Freesurfer at nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From reynoldr at mail.nih.gov Thu Jul 27 10:40:49 2017 From: reynoldr at mail.nih.gov (Reynolds, Richard C. (NIH/NIMH) [E]) Date: Thu, 27 Jul 2017 14:40:49 +0000 Subject: [Neuroimaging] Fwd: [bids-discussion] Make DelayTime compulsory for all sparse acquisitions In-Reply-To: References: <2017072521355953127853@osu.edu>, Message-ID: Hello, The NIFTI (1 and 2) standards are meant to be of fixed size, easily read into a header. And being based on the ANALYZE format (to promote adoption), they are fairly limited in terms of what fields are included. However adding this as an extension would be easy, and would not require changes to the standards. It would just require reserving a new NIFTI_ECODE_* value, and defining the format of the extension. Of course, the hard part would be in getting software packages to do something useful with the information, or to even add such an extension in the first place. - rick ________________________________ From: JB Poline Sent: Wednesday, July 26, 2017 9:45:56 AM To: Neuroimaging analysis in Python Subject: [Neuroimaging] Fwd: [bids-discussion] Make DelayTime compulsory for all sparse acquisitions Hey Forwarding this or the relevance with nibabel and others - I remember a similar-ish discussion Cheers JB ---------- Forwarded message ---------- From: Xiangrui Li Date: 25 July 2017 at 22:35 Subject: Re: [bids-discussion] Make DelayTime compulsory for all sparse acquisitions To: "bids-discussion at googlegroups.com" Talking about sparse acquisition, I would like to mention my recent experience related to multiband sparse-like sequence. If this has not been brought up before, I would like to propose an optional field to encode the timing of NIfTI's 4th dimension. We use the CMRR multiband sequence, which allows to set several TRs as "quiet" period without image acquisition, so one can play sound during this period. For example, we use TR of 1 second, and acquire 10 volumes continuously, then have 4-TR quiet period. This results in 14-second cycles with only 10-second of image data in each cycle. The dicom files have discontinuity in InstanceNumber, like 1 to 10, then jump to 15 to 24 etc. Most NIfTI converters quietly convert these files. The result NIfTI is actually not strictly NIfTI compliant, since its 4th dim (timing) has variable intervals. My matlab-based converter (dicm2nii.m) would have failed to convert, complaining missing files. I just updated it, allowing missing files with regular spacing (missing 4 in every 14 files in above example), while it gives a warning for the InstanceNumber discontinuity, and stores the InstanceNumber in a field in NIfTI extension. I was thinking to pad zeros for those missing volumes to make it NIfTI compliant, but it seems dumb to increase the file size. After asking opinion from some auditory people, I think it is better to make it consistent with other NIfTI converters, so everyone is violating the NIfTI rule :) The field I am proposing can be called something like "TimeIndices". It has the same length as the 4th dim of NIfTI image. For the above example, it can be those InstanceNumber minus 1 (0-based), or we call it a different name and store the time in seconds: (InstanceNumber-1) * TR. Any thoughts, comments? Thanks. _____________ Xiangrui Li, Ph.D. Center for Cognitive and Behavioral Brain Imaging The Ohio State University Phone: 614-292-1847 From: Satrajit Ghosh Date: 2017-07-25 18:15 To: bids-discussion at googlegroups.com Subject: [bids-discussion] Make DelayTime compulsory for all sparse acquisitions hi folks, chris and i were chatting about a dataset with a sparse acquisition protocol: collect n-slices wait m seconds, collect again. on siemens scanners this is implemented using TR and delay, with TA (time of acquisition) = TR - delay. the current bids specification says if slice timing is provided, DelayTime is not required. i would like to propose that DelayTime is provided for all sparse acquisitions independent of slice timing. here is the reasoning. as it stands i have to write code that kind of looks like this: if multiband_sparse: good_luck_figuring_out_slice_timing is correct or not. (on our scanner siemens generated incorrect slice timing numbers). else: TA = max(slice_times) + np.average(np.diff(sort(slice_times))) with DelayTime, it would always be: RepetitionTime - DelayTime. let any discussions ensue. cheers, satra -- You received this message because you are subscribed to the Google Groups "bids-discussion" group. To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe at googlegroups.com. To post to this group, send email to bids-discussion at googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/bids-discussion/CA%2BA4wOnk%3DJvddeWSmZL1puexaCMA-Y_YyQbKjYTtPJ1kS_YcZg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "bids-discussion" group. To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe at googlegroups.com. To post to this group, send email to bids-discussion at googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/bids-discussion/2017072521355953127853%40osu.edu. For more options, visit https://groups.google.com/d/optout. _______________________________________________ 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 Thu Jul 27 11:59:41 2017 From: effigies at bu.edu (Christopher Markiewicz) Date: Thu, 27 Jul 2017 11:59:41 -0400 Subject: [Neuroimaging] Fwd: [Freesurfer] negative header after preproc-sess In-Reply-To: References: Message-ID: I agree with this viewpoint from a user/standards perspective. AFAIK only FreeSurfer and nibabel support the surface hacks, and both also support the .mgh format, so there's no real advantage to using NIfTI here. For interoperability, other formats are more appropriate. I also think it's reasonable to encourage FreeSurfer to move toward writing NIfTI-2 when hacks are necessary to generate NIfTI-1 files. >From a nibabel-as-multitool perspective, while I understand the concern about propagating broken formats, I also think we should be able to read images as created by existing packages, as long as doing so doesn't harm our ability to read standard-conforming files. Chris On Thu, Jul 27, 2017 at 10:18 AM, Reynolds, Richard C. (NIH/NIMH) [E] < reynoldr at mail.nih.gov> wrote: > This seems like an appropriate case to be using the > > NIFTI-2 standard, which uses 64-bit values rather than > > the 16-bits for NIFTI-1 (which was done just to keep it > > similar to ANALYZE). > > > For that matter, GIFTI was made to be the surface > > alternative to NIFTI, and FreeSurfer supports it, as does > > nibabel, it seems. > > > Even without those options, it seems like FreeSurfer > > can still output what you want in a useful format. > > > Breaking the NIFTI-1 standard is causing you trouble. > > Maybe propagating that is not necessary. > > - rick > > > ------------------------------ > *From:* Bai Haohao > *Sent:* Thursday, July 27, 2017 9:41:13 AM > *To:* neuroimaging at python.org > *Subject:* [Neuroimaging] Fwd: [Freesurfer] negative header after > preproc-sess > > Dear nibabel experts, > > I forward this email to nibabel mailing list because I think it is related > to nibabel, even this problem is caused by nifti standard and freesurfer. > > I am using nibabel to load data after freesurfer "*preproc-sess -suface > self" *and I get negative dim(-1 1 1, see origin email for detail), which > makes nibabel.get_data() failed, but freesurfer first level analysis can be > done successfully, in my view it means freesurfer can get data from this > bad header. > > I find a way to solve it is by using "mri_convert *.nii.gz *.mgz", then > nibabel could get data from *.mgz. But I think if nibabel could support > getting data from negative header file would be more helpful. > > Just some undevelopped thoughts, I hope I express it clearly. > > Best, > > Bai Haohao > > > > ---------- Forwarded message ---------- > From: Douglas Greve > Date: Thu, Jul 6, 2017 at 7:07 AM > Subject: Re: [Freesurfer] negative header after preproc-sess > To: freesurfer at nmr.mgh.harvard.edu > > > When the nifti standard was adopted, they used a short int to represent > the dimensions. Unfortunately, this only allows for a maximum dimension of > 32k, which is not big enough for surfaces. So I hacked the FS nifti format > to put a -1 as the first dim at which point the FS code will go to another > place in the header to get the spatial dimensions. It is possible to > reshape the spatial dimensions as long as the largest prime factor is less > than 32k (see mri_surf2surf with --reshape option). Other than that, you > might ask the nibabel people to program the same hack. > > On 6/25/17 6:48 AM, Bai Haohao wrote: > > Hello Freesurfer experts, > > I am running my data with preproc-sess to project my func data to > individual anatomy file, and the command shows as below: > > preproc-sess -sf ${Sesslist} -fsd "bold" -surface self lhrh -fwhm 0 > -per-run -force > > > And the subjectname point to the subject dir that created after recon-all. > > After the running completed, I try to load data from > fmcpr.sm0.self.lh.nii.gz with nibabel, and I get this error info: > > >>> f.get_data() > Traceback (most recent call last): > File "", line 1, in > File "/usr/lib/pymodules/python2.7/nibabel/spatialimages.py", line 341, > in get_data > return np.asanyarray(self._data) > File "/usr/lib/python2.7/dist-packages/numpy/core/numeric.py", line > 512, in asanyarray > return array(a, dtype, copy=False, order=order, subok=True) > File "/usr/lib/pymodules/python2.7/nibabel/arrayproxy.py", line 55, in > __array__ > self._data = self._read_data() > File "/usr/lib/pymodules/python2.7/nibabel/arrayproxy.py", line 60, in > _read_data > data = self.header.data_from_fileobj(fileobj) > File "/usr/lib/pymodules/python2.7/nibabel/analyze.py", line 486, in > data_from_fileobj > data = self.raw_data_from_fileobj(fileobj) > File "/usr/lib/pymodules/python2.7/nibabel/analyze.py", line 458, in > raw_data_from_fileobj > return array_from_file(shape, dtype, fileobj, offset) > File "/usr/lib/pymodules/python2.7/nibabel/volumeutils.py", line 493, > in array_from_file > raise IOError(msg) > IOError: Expected -1804 bytes, got 264809160 bytes from file > "fmcpr.vol2surf.lh.nii.gz" > - could the file be damaged? > > > Then I check the file header by nibabel, and I get this: > > > >>> print(f.get_header()) > object, endian='<' > sizeof_hdr : 348 > data_type : > db_name : > extents : 0 > session_error : 0 > regular : > dim_info : 0 > dim : [ 4 -1 1 1 451 1 1 1] > intent_p1 : 0.0 > intent_p2 : 0.0 > intent_p3 : 0.0 > intent_code : none > datatype : float32 > bitpix : 32 > slice_start : 0 > pixdim : [-1. 1. 1. 1. > 2.00000072 1. 1. > 1. ] > vox_offset : 352.0 > scl_slope : 0.0 > scl_inter : 0.0 > slice_end : 0 > slice_code : unknown > xyzt_units : 10 > cal_max : 0.0 > cal_min : 0.0 > slice_duration : 0.0 > toffset : 0.0 > glmax : 0 > glmin : 146790 > descrip : FreeSurfer May 13 2013 > aux_file : > qform_code : scanner > sform_code : scanner > quatern_b : -0.0115927606821 > quatern_c : -0.996071338654 > quatern_d : -0.0864994972944 > qoffset_x : 73344.5546875 > qoffset_y : -1492.14978027 > qoffset_z : -2311.28955078 > srow_x : [ -9.99280393e-01 2.56918129e-02 2.79041883e-02 > 7.33445547e+04] > srow_y : [ 2.04970520e-02 9.84766901e-01 -1.72667429e-01 > -1.49214978e+03] > srow_z : [ 3.19152586e-02 1.71971247e-01 9.84584868e-01 > -2.31128955e+03] > intent_name : > magic : n+1 > > > > > Note that the dim has value -1, but when I use -surface fsaverage, the dim > is correct(show as below): > > dim : [ 4 27307 1 6 451 1 1 1] > > > And I read the source code, the difference between self and fsaverage is > appeared when running rawfunc2surf-sess, and log files are attached. > > I have tried many commands to load data from fmcpr.sm0.self.lh.nii.gz, > such as fslview, freeview, mri_convert, mri_surf2surf, ... > > and only tksurfer could read this file by -timecourse > fmcpr.sm0.self.lh.nii.gz. > > I want to figure out how could I fix it, and any suggestion would be > helpful. > > Thanks in advance, > > Bai Haohao > > > Version info: > System: ubuntu-16.04.1-server-amd64 > Freesurfer: freesurfer-Linux-centos4_x86_64-stable-pub-v5.3.0-HCP > nibabel: python-nibabel 1.2.2-1 > > > > _______________________________________________ > Freesurfer mailing listFreesurfer at nmr.mgh.harvard.eduhttps://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer > > > > _______________________________________________ > Freesurfer mailing list > Freesurfer at nmr.mgh.harvard.edu > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer > > > 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. > > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarblank1200 at gmail.com Fri Jul 28 10:42:31 2017 From: jarblank1200 at gmail.com (Bai Haohao) Date: Fri, 28 Jul 2017 22:42:31 +0800 Subject: [Neuroimaging] Fwd: [Freesurfer] negative header after preproc-sess In-Reply-To: References: Message-ID: Hi, Thanks for your advice, I open an issue on github, and I wish it could help. Best. Bai Haohao On Thu, Jul 27, 2017 at 10:20 PM, Christopher Markiewicz wrote: > Looks like the FreeSurfer hack needs to be expanded to more cases. Could > you go ahead and open an issue on https://github.com/nipy/nibabel/issues? > > On Thu, Jul 27, 2017 at 9:41 AM, Bai Haohao > wrote: > >> Dear nibabel experts, >> >> I forward this email to nibabel mailing list because I think it is >> related to nibabel, even this problem is caused by nifti standard and >> freesurfer. >> >> I am using nibabel to load data after freesurfer "*preproc-sess -suface >> self" *and I get negative dim(-1 1 1, see origin email for detail), >> which makes nibabel.get_data() failed, but freesurfer first level analysis >> can be done successfully, in my view it means freesurfer can get data from >> this bad header. >> >> I find a way to solve it is by using "mri_convert *.nii.gz *.mgz", then >> nibabel could get data from *.mgz. But I think if nibabel could support >> getting data from negative header file would be more helpful. >> >> Just some undevelopped thoughts, I hope I express it clearly. >> >> Best, >> >> Bai Haohao >> >> >> >> ---------- Forwarded message ---------- >> From: Douglas Greve >> Date: Thu, Jul 6, 2017 at 7:07 AM >> Subject: Re: [Freesurfer] negative header after preproc-sess >> To: freesurfer at nmr.mgh.harvard.edu >> >> >> When the nifti standard was adopted, they used a short int to represent >> the dimensions. Unfortunately, this only allows for a maximum dimension of >> 32k, which is not big enough for surfaces. So I hacked the FS nifti format >> to put a -1 as the first dim at which point the FS code will go to another >> place in the header to get the spatial dimensions. It is possible to >> reshape the spatial dimensions as long as the largest prime factor is less >> than 32k (see mri_surf2surf with --reshape option). Other than that, you >> might ask the nibabel people to program the same hack. >> >> On 6/25/17 6:48 AM, Bai Haohao wrote: >> >> Hello Freesurfer experts, >> >> I am running my data with preproc-sess to project my func data to >> individual anatomy file, and the command shows as below: >> >> preproc-sess -sf ${Sesslist} -fsd "bold" -surface self lhrh -fwhm 0 >> -per-run -force >> >> >> And the subjectname point to the subject dir that created after recon-all. >> >> After the running completed, I try to load data from >> fmcpr.sm0.self.lh.nii.gz with nibabel, and I get this error info: >> >> >>> f.get_data() >> Traceback (most recent call last): >> File "", line 1, in >> File "/usr/lib/pymodules/python2.7/nibabel/spatialimages.py", line >> 341, in get_data >> return np.asanyarray(self._data) >> File "/usr/lib/python2.7/dist-packages/numpy/core/numeric.py", line >> 512, in asanyarray >> return array(a, dtype, copy=False, order=order, subok=True) >> File "/usr/lib/pymodules/python2.7/nibabel/arrayproxy.py", line 55, in >> __array__ >> self._data = self._read_data() >> File "/usr/lib/pymodules/python2.7/nibabel/arrayproxy.py", line 60, in >> _read_data >> data = self.header.data_from_fileobj(fileobj) >> File "/usr/lib/pymodules/python2.7/nibabel/analyze.py", line 486, in >> data_from_fileobj >> data = self.raw_data_from_fileobj(fileobj) >> File "/usr/lib/pymodules/python2.7/nibabel/analyze.py", line 458, in >> raw_data_from_fileobj >> return array_from_file(shape, dtype, fileobj, offset) >> File "/usr/lib/pymodules/python2.7/nibabel/volumeutils.py", line 493, >> in array_from_file >> raise IOError(msg) >> IOError: Expected -1804 bytes, got 264809160 bytes from file >> "fmcpr.vol2surf.lh.nii.gz" >> - could the file be damaged? >> >> >> Then I check the file header by nibabel, and I get this: >> >> >> >>> print(f.get_header()) >> object, endian='<' >> sizeof_hdr : 348 >> data_type : >> db_name : >> extents : 0 >> session_error : 0 >> regular : >> dim_info : 0 >> dim : [ 4 -1 1 1 451 1 1 1] >> intent_p1 : 0.0 >> intent_p2 : 0.0 >> intent_p3 : 0.0 >> intent_code : none >> datatype : float32 >> bitpix : 32 >> slice_start : 0 >> pixdim : [-1. 1. 1. 1. >> 2.00000072 1. 1. >> 1. ] >> vox_offset : 352.0 >> scl_slope : 0.0 >> scl_inter : 0.0 >> slice_end : 0 >> slice_code : unknown >> xyzt_units : 10 >> cal_max : 0.0 >> cal_min : 0.0 >> slice_duration : 0.0 >> toffset : 0.0 >> glmax : 0 >> glmin : 146790 >> descrip : FreeSurfer May 13 2013 >> aux_file : >> qform_code : scanner >> sform_code : scanner >> quatern_b : -0.0115927606821 >> quatern_c : -0.996071338654 >> quatern_d : -0.0864994972944 >> qoffset_x : 73344.5546875 >> qoffset_y : -1492.14978027 >> qoffset_z : -2311.28955078 >> srow_x : [ -9.99280393e-01 2.56918129e-02 2.79041883e-02 >> 7.33445547e+04] >> srow_y : [ 2.04970520e-02 9.84766901e-01 -1.72667429e-01 >> -1.49214978e+03] >> srow_z : [ 3.19152586e-02 1.71971247e-01 9.84584868e-01 >> -2.31128955e+03] >> intent_name : >> magic : n+1 >> >> >> >> >> Note that the dim has value -1, but when I use -surface fsaverage, the >> dim is correct(show as below): >> >> dim : [ 4 27307 1 6 451 1 1 1] >> >> >> And I read the source code, the difference between self and fsaverage is >> appeared when running rawfunc2surf-sess, and log files are attached. >> >> I have tried many commands to load data from fmcpr.sm0.self.lh.nii.gz, >> such as fslview, freeview, mri_convert, mri_surf2surf, ... >> >> and only tksurfer could read this file by -timecourse >> fmcpr.sm0.self.lh.nii.gz. >> >> I want to figure out how could I fix it, and any suggestion would be >> helpful. >> >> Thanks in advance, >> >> Bai Haohao >> >> >> Version info: >> System: ubuntu-16.04.1-server-amd64 >> Freesurfer: freesurfer-Linux-centos4_x86_64-stable-pub-v5.3.0-HCP >> nibabel: python-nibabel 1.2.2-1 >> >> >> >> _______________________________________________ >> Freesurfer mailing listFreesurfer at nmr.mgh.harvard.eduhttps://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >> >> >> >> _______________________________________________ >> Freesurfer mailing list >> Freesurfer at nmr.mgh.harvard.edu >> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >> >> >> 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. >> >> >> >> _______________________________________________ >> 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 jarblank1200 at gmail.com Fri Jul 28 10:59:38 2017 From: jarblank1200 at gmail.com (Bai Haohao) Date: Fri, 28 Jul 2017 22:59:38 +0800 Subject: [Neuroimaging] Fwd: [Freesurfer] negative header after preproc-sess In-Reply-To: References: Message-ID: Hello, Thanks for your replies, and I agree with your idea that Nifti1 standard should be replaced by Nifti2, or do not save file into Nifti1 format. However, I have tried convert input data format from "*.nii.gz" to "*.mgz", and delete origin *.nii.gz file, then running "preproc-sess", and I found freesurfer would detect the format of the input, and convert "*.mgz" to "*.nii.gz", finally I got Nifti1 data, with negative dim. Maybe there has an argument that could specify output format and convert output file format manually could solve it, but I think it would be helpful for other people who meet the same situation as me if nibabel could support reading these kind of data. Thanks for your opinions again, and I believe we hold the same view:) Best, Bai Haohao On Thu, Jul 27, 2017 at 11:59 PM, Christopher Markiewicz wrote: > I agree with this viewpoint from a user/standards perspective. AFAIK only > FreeSurfer and nibabel support the surface hacks, and both also support the > .mgh format, so there's no real advantage to using NIfTI here. For > interoperability, other formats are more appropriate. I also think it's > reasonable to encourage FreeSurfer to move toward writing NIfTI-2 when > hacks are necessary to generate NIfTI-1 files. > > From a nibabel-as-multitool perspective, while I understand the concern > about propagating broken formats, I also think we should be able to read > images as created by existing packages, as long as doing so doesn't harm > our ability to read standard-conforming files. > > Chris > > On Thu, Jul 27, 2017 at 10:18 AM, Reynolds, Richard C. (NIH/NIMH) [E] < > reynoldr at mail.nih.gov> wrote: > >> This seems like an appropriate case to be using the >> >> NIFTI-2 standard, which uses 64-bit values rather than >> >> the 16-bits for NIFTI-1 (which was done just to keep it >> >> similar to ANALYZE). >> >> >> For that matter, GIFTI was made to be the surface >> >> alternative to NIFTI, and FreeSurfer supports it, as does >> >> nibabel, it seems. >> >> >> Even without those options, it seems like FreeSurfer >> >> can still output what you want in a useful format. >> >> >> Breaking the NIFTI-1 standard is causing you trouble. >> >> Maybe propagating that is not necessary. >> >> - rick >> >> >> ------------------------------ >> *From:* Bai Haohao >> *Sent:* Thursday, July 27, 2017 9:41:13 AM >> *To:* neuroimaging at python.org >> *Subject:* [Neuroimaging] Fwd: [Freesurfer] negative header after >> preproc-sess >> >> Dear nibabel experts, >> >> I forward this email to nibabel mailing list because I think it is >> related to nibabel, even this problem is caused by nifti standard and >> freesurfer. >> >> I am using nibabel to load data after freesurfer "*preproc-sess -suface >> self" *and I get negative dim(-1 1 1, see origin email for detail), >> which makes nibabel.get_data() failed, but freesurfer first level analysis >> can be done successfully, in my view it means freesurfer can get data from >> this bad header. >> >> I find a way to solve it is by using "mri_convert *.nii.gz *.mgz", then >> nibabel could get data from *.mgz. But I think if nibabel could support >> getting data from negative header file would be more helpful. >> >> Just some undevelopped thoughts, I hope I express it clearly. >> >> Best, >> >> Bai Haohao >> >> >> >> ---------- Forwarded message ---------- >> From: Douglas Greve >> Date: Thu, Jul 6, 2017 at 7:07 AM >> Subject: Re: [Freesurfer] negative header after preproc-sess >> To: freesurfer at nmr.mgh.harvard.edu >> >> >> When the nifti standard was adopted, they used a short int to represent >> the dimensions. Unfortunately, this only allows for a maximum dimension of >> 32k, which is not big enough for surfaces. So I hacked the FS nifti format >> to put a -1 as the first dim at which point the FS code will go to another >> place in the header to get the spatial dimensions. It is possible to >> reshape the spatial dimensions as long as the largest prime factor is less >> than 32k (see mri_surf2surf with --reshape option). Other than that, you >> might ask the nibabel people to program the same hack. >> >> On 6/25/17 6:48 AM, Bai Haohao wrote: >> >> Hello Freesurfer experts, >> >> I am running my data with preproc-sess to project my func data to >> individual anatomy file, and the command shows as below: >> >> preproc-sess -sf ${Sesslist} -fsd "bold" -surface self lhrh -fwhm 0 >> -per-run -force >> >> >> And the subjectname point to the subject dir that created after recon-all. >> >> After the running completed, I try to load data from >> fmcpr.sm0.self.lh.nii.gz with nibabel, and I get this error info: >> >> >>> f.get_data() >> Traceback (most recent call last): >> File "", line 1, in >> File "/usr/lib/pymodules/python2.7/nibabel/spatialimages.py", line >> 341, in get_data >> return np.asanyarray(self._data) >> File "/usr/lib/python2.7/dist-packages/numpy/core/numeric.py", line >> 512, in asanyarray >> return array(a, dtype, copy=False, order=order, subok=True) >> File "/usr/lib/pymodules/python2.7/nibabel/arrayproxy.py", line 55, in >> __array__ >> self._data = self._read_data() >> File "/usr/lib/pymodules/python2.7/nibabel/arrayproxy.py", line 60, in >> _read_data >> data = self.header.data_from_fileobj(fileobj) >> File "/usr/lib/pymodules/python2.7/nibabel/analyze.py", line 486, in >> data_from_fileobj >> data = self.raw_data_from_fileobj(fileobj) >> File "/usr/lib/pymodules/python2.7/nibabel/analyze.py", line 458, in >> raw_data_from_fileobj >> return array_from_file(shape, dtype, fileobj, offset) >> File "/usr/lib/pymodules/python2.7/nibabel/volumeutils.py", line 493, >> in array_from_file >> raise IOError(msg) >> IOError: Expected -1804 bytes, got 264809160 bytes from file >> "fmcpr.vol2surf.lh.nii.gz" >> - could the file be damaged? >> >> >> Then I check the file header by nibabel, and I get this: >> >> >> >>> print(f.get_header()) >> object, endian='<' >> sizeof_hdr : 348 >> data_type : >> db_name : >> extents : 0 >> session_error : 0 >> regular : >> dim_info : 0 >> dim : [ 4 -1 1 1 451 1 1 1] >> intent_p1 : 0.0 >> intent_p2 : 0.0 >> intent_p3 : 0.0 >> intent_code : none >> datatype : float32 >> bitpix : 32 >> slice_start : 0 >> pixdim : [-1. 1. 1. 1. >> 2.00000072 1. 1. >> 1. ] >> vox_offset : 352.0 >> scl_slope : 0.0 >> scl_inter : 0.0 >> slice_end : 0 >> slice_code : unknown >> xyzt_units : 10 >> cal_max : 0.0 >> cal_min : 0.0 >> slice_duration : 0.0 >> toffset : 0.0 >> glmax : 0 >> glmin : 146790 >> descrip : FreeSurfer May 13 2013 >> aux_file : >> qform_code : scanner >> sform_code : scanner >> quatern_b : -0.0115927606821 >> quatern_c : -0.996071338654 >> quatern_d : -0.0864994972944 >> qoffset_x : 73344.5546875 >> qoffset_y : -1492.14978027 >> qoffset_z : -2311.28955078 >> srow_x : [ -9.99280393e-01 2.56918129e-02 2.79041883e-02 >> 7.33445547e+04] >> srow_y : [ 2.04970520e-02 9.84766901e-01 -1.72667429e-01 >> -1.49214978e+03] >> srow_z : [ 3.19152586e-02 1.71971247e-01 9.84584868e-01 >> -2.31128955e+03] >> intent_name : >> magic : n+1 >> >> >> >> >> Note that the dim has value -1, but when I use -surface fsaverage, the >> dim is correct(show as below): >> >> dim : [ 4 27307 1 6 451 1 1 1] >> >> >> And I read the source code, the difference between self and fsaverage is >> appeared when running rawfunc2surf-sess, and log files are attached. >> >> I have tried many commands to load data from fmcpr.sm0.self.lh.nii.gz, >> such as fslview, freeview, mri_convert, mri_surf2surf, ... >> >> and only tksurfer could read this file by -timecourse >> fmcpr.sm0.self.lh.nii.gz. >> >> I want to figure out how could I fix it, and any suggestion would be >> helpful. >> >> Thanks in advance, >> >> Bai Haohao >> >> >> Version info: >> System: ubuntu-16.04.1-server-amd64 >> Freesurfer: freesurfer-Linux-centos4_x86_64-stable-pub-v5.3.0-HCP >> nibabel: python-nibabel 1.2.2-1 >> >> >> >> _______________________________________________ >> Freesurfer mailing listFreesurfer at nmr.mgh.harvard.eduhttps://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >> >> >> >> _______________________________________________ >> Freesurfer mailing list >> Freesurfer at nmr.mgh.harvard.edu >> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >> >> >> 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. >> >> >> >> _______________________________________________ >> 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 Fri Jul 28 11:18:13 2017 From: effigies at bu.edu (Christopher Markiewicz) Date: Fri, 28 Jul 2017 11:18:13 -0400 Subject: [Neuroimaging] Fwd: [Freesurfer] negative header after preproc-sess In-Reply-To: References: Message-ID: Hi Bai, You can try setting the FSF_OUTPUT_FORMAT environment variable to 'mgz' (in $FREESURFER_HOME/FreeSurferEnv.sh). I haven't tried this, and there may be code that presumes NIfTI inputs, but I would assume it would be fine with MGH/MGZ formats. Chris On Fri, Jul 28, 2017 at 10:59 AM, Bai Haohao wrote: > Hello, > > Thanks for your replies, and I agree with your idea that Nifti1 standard > should be replaced by Nifti2, or do not save file into Nifti1 format. > > However, I have tried convert input data format from "*.nii.gz" to > "*.mgz", and delete origin *.nii.gz file, then running "preproc-sess", and > I found freesurfer would detect the format of the input, and convert > "*.mgz" to "*.nii.gz", finally I got Nifti1 data, with negative dim. > > Maybe there has an argument that could specify output format and convert > output file format manually could solve it, but I think it would be helpful > for other people who meet the same situation as me if nibabel could support > reading these kind of data. > > Thanks for your opinions again, and I believe we hold the same view:) > > Best, > > Bai Haohao > > On Thu, Jul 27, 2017 at 11:59 PM, Christopher Markiewicz > wrote: > >> I agree with this viewpoint from a user/standards perspective. AFAIK only >> FreeSurfer and nibabel support the surface hacks, and both also support the >> .mgh format, so there's no real advantage to using NIfTI here. For >> interoperability, other formats are more appropriate. I also think it's >> reasonable to encourage FreeSurfer to move toward writing NIfTI-2 when >> hacks are necessary to generate NIfTI-1 files. >> >> From a nibabel-as-multitool perspective, while I understand the concern >> about propagating broken formats, I also think we should be able to read >> images as created by existing packages, as long as doing so doesn't harm >> our ability to read standard-conforming files. >> >> Chris >> >> On Thu, Jul 27, 2017 at 10:18 AM, Reynolds, Richard C. (NIH/NIMH) [E] < >> reynoldr at mail.nih.gov> wrote: >> >>> This seems like an appropriate case to be using the >>> >>> NIFTI-2 standard, which uses 64-bit values rather than >>> >>> the 16-bits for NIFTI-1 (which was done just to keep it >>> >>> similar to ANALYZE). >>> >>> >>> For that matter, GIFTI was made to be the surface >>> >>> alternative to NIFTI, and FreeSurfer supports it, as does >>> >>> nibabel, it seems. >>> >>> >>> Even without those options, it seems like FreeSurfer >>> >>> can still output what you want in a useful format. >>> >>> >>> Breaking the NIFTI-1 standard is causing you trouble. >>> >>> Maybe propagating that is not necessary. >>> >>> - rick >>> >>> >>> ------------------------------ >>> *From:* Bai Haohao >>> *Sent:* Thursday, July 27, 2017 9:41:13 AM >>> *To:* neuroimaging at python.org >>> *Subject:* [Neuroimaging] Fwd: [Freesurfer] negative header after >>> preproc-sess >>> >>> Dear nibabel experts, >>> >>> I forward this email to nibabel mailing list because I think it is >>> related to nibabel, even this problem is caused by nifti standard and >>> freesurfer. >>> >>> I am using nibabel to load data after freesurfer "*preproc-sess -suface >>> self" *and I get negative dim(-1 1 1, see origin email for detail), >>> which makes nibabel.get_data() failed, but freesurfer first level analysis >>> can be done successfully, in my view it means freesurfer can get data from >>> this bad header. >>> >>> I find a way to solve it is by using "mri_convert *.nii.gz *.mgz", then >>> nibabel could get data from *.mgz. But I think if nibabel could support >>> getting data from negative header file would be more helpful. >>> >>> Just some undevelopped thoughts, I hope I express it clearly. >>> >>> Best, >>> >>> Bai Haohao >>> >>> >>> >>> ---------- Forwarded message ---------- >>> From: Douglas Greve >>> Date: Thu, Jul 6, 2017 at 7:07 AM >>> Subject: Re: [Freesurfer] negative header after preproc-sess >>> To: freesurfer at nmr.mgh.harvard.edu >>> >>> >>> When the nifti standard was adopted, they used a short int to represent >>> the dimensions. Unfortunately, this only allows for a maximum dimension of >>> 32k, which is not big enough for surfaces. So I hacked the FS nifti format >>> to put a -1 as the first dim at which point the FS code will go to another >>> place in the header to get the spatial dimensions. It is possible to >>> reshape the spatial dimensions as long as the largest prime factor is less >>> than 32k (see mri_surf2surf with --reshape option). Other than that, you >>> might ask the nibabel people to program the same hack. >>> >>> On 6/25/17 6:48 AM, Bai Haohao wrote: >>> >>> Hello Freesurfer experts, >>> >>> I am running my data with preproc-sess to project my func data to >>> individual anatomy file, and the command shows as below: >>> >>> preproc-sess -sf ${Sesslist} -fsd "bold" -surface self lhrh -fwhm 0 >>> -per-run -force >>> >>> >>> And the subjectname point to the subject dir that created after >>> recon-all. >>> >>> After the running completed, I try to load data from >>> fmcpr.sm0.self.lh.nii.gz with nibabel, and I get this error info: >>> >>> >>> f.get_data() >>> Traceback (most recent call last): >>> File "", line 1, in >>> File "/usr/lib/pymodules/python2.7/nibabel/spatialimages.py", line >>> 341, in get_data >>> return np.asanyarray(self._data) >>> File "/usr/lib/python2.7/dist-packages/numpy/core/numeric.py", line >>> 512, in asanyarray >>> return array(a, dtype, copy=False, order=order, subok=True) >>> File "/usr/lib/pymodules/python2.7/nibabel/arrayproxy.py", line 55, >>> in __array__ >>> self._data = self._read_data() >>> File "/usr/lib/pymodules/python2.7/nibabel/arrayproxy.py", line 60, >>> in _read_data >>> data = self.header.data_from_fileobj(fileobj) >>> File "/usr/lib/pymodules/python2.7/nibabel/analyze.py", line 486, in >>> data_from_fileobj >>> data = self.raw_data_from_fileobj(fileobj) >>> File "/usr/lib/pymodules/python2.7/nibabel/analyze.py", line 458, in >>> raw_data_from_fileobj >>> return array_from_file(shape, dtype, fileobj, offset) >>> File "/usr/lib/pymodules/python2.7/nibabel/volumeutils.py", line 493, >>> in array_from_file >>> raise IOError(msg) >>> IOError: Expected -1804 bytes, got 264809160 bytes from file >>> "fmcpr.vol2surf.lh.nii.gz" >>> - could the file be damaged? >>> >>> >>> Then I check the file header by nibabel, and I get this: >>> >>> >>> >>> print(f.get_header()) >>> object, endian='<' >>> sizeof_hdr : 348 >>> data_type : >>> db_name : >>> extents : 0 >>> session_error : 0 >>> regular : >>> dim_info : 0 >>> dim : [ 4 -1 1 1 451 1 1 1] >>> intent_p1 : 0.0 >>> intent_p2 : 0.0 >>> intent_p3 : 0.0 >>> intent_code : none >>> datatype : float32 >>> bitpix : 32 >>> slice_start : 0 >>> pixdim : [-1. 1. 1. 1. >>> 2.00000072 1. 1. >>> 1. ] >>> vox_offset : 352.0 >>> scl_slope : 0.0 >>> scl_inter : 0.0 >>> slice_end : 0 >>> slice_code : unknown >>> xyzt_units : 10 >>> cal_max : 0.0 >>> cal_min : 0.0 >>> slice_duration : 0.0 >>> toffset : 0.0 >>> glmax : 0 >>> glmin : 146790 >>> descrip : FreeSurfer May 13 2013 >>> aux_file : >>> qform_code : scanner >>> sform_code : scanner >>> quatern_b : -0.0115927606821 >>> quatern_c : -0.996071338654 >>> quatern_d : -0.0864994972944 >>> qoffset_x : 73344.5546875 >>> qoffset_y : -1492.14978027 >>> qoffset_z : -2311.28955078 >>> srow_x : [ -9.99280393e-01 2.56918129e-02 2.79041883e-02 >>> 7.33445547e+04] >>> srow_y : [ 2.04970520e-02 9.84766901e-01 -1.72667429e-01 >>> -1.49214978e+03] >>> srow_z : [ 3.19152586e-02 1.71971247e-01 9.84584868e-01 >>> -2.31128955e+03] >>> intent_name : >>> magic : n+1 >>> >>> >>> >>> >>> Note that the dim has value -1, but when I use -surface fsaverage, the >>> dim is correct(show as below): >>> >>> dim : [ 4 27307 1 6 451 1 1 1] >>> >>> >>> And I read the source code, the difference between self and fsaverage is >>> appeared when running rawfunc2surf-sess, and log files are attached. >>> >>> I have tried many commands to load data from fmcpr.sm0.self.lh.nii.gz, >>> such as fslview, freeview, mri_convert, mri_surf2surf, ... >>> >>> and only tksurfer could read this file by -timecourse >>> fmcpr.sm0.self.lh.nii.gz. >>> >>> I want to figure out how could I fix it, and any suggestion would be >>> helpful. >>> >>> Thanks in advance, >>> >>> Bai Haohao >>> >>> >>> Version info: >>> System: ubuntu-16.04.1-server-amd64 >>> Freesurfer: freesurfer-Linux-centos4_x86_64-stable-pub-v5.3.0-HCP >>> nibabel: python-nibabel 1.2.2-1 >>> >>> >>> >>> _______________________________________________ >>> Freesurfer mailing listFreesurfer at nmr.mgh.harvard.eduhttps://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >>> >>> >>> >>> _______________________________________________ >>> Freesurfer mailing list >>> Freesurfer at nmr.mgh.harvard.edu >>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >>> >>> >>> 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. >>> >>> >>> >>> _______________________________________________ >>> 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 744652457 at qq.com Fri Jul 28 12:55:42 2017 From: 744652457 at qq.com (=?gb18030?B?QmFpIEhhb2hhbw==?=) Date: Sat, 29 Jul 2017 00:55:42 +0800 Subject: [Neuroimaging] =?gb18030?b?u9i4tKO6ICBGd2Q6IFtGcmVlc3VyZmVyXSBu?= =?gb18030?q?egative_header_afterpreproc-sess?= In-Reply-To: References: Message-ID: Hi, Thank you for your reply in email and github, I will try the newest version of nibabel to see if this problem can be fixed. It really helps me a lot, thank you:) Best, Bai Haohao ------------------ ???? ------------------ ???: "Christopher Markiewicz";; ????: 2017?7?28?(???) ??11:18 ???: "Neuroimaging analysis in Python"; ??: Re: [Neuroimaging] Fwd: [Freesurfer] negative header afterpreproc-sess Hi Bai, You can try setting the FSF_OUTPUT_FORMAT environment variable to 'mgz' (in $FREESURFER_HOME/FreeSurferEnv.sh). I haven't tried this, and there may be code that presumes NIfTI inputs, but I would assume it would be fine with MGH/MGZ formats. Chris On Fri, Jul 28, 2017 at 10:59 AM, Bai Haohao wrote: Hello, Thanks for your replies, and I agree with your idea that Nifti1 standard should be replaced by Nifti2, or do not save file into Nifti1 format. However, I have tried convert input data format from "*.nii.gz" to "*.mgz", and delete origin *.nii.gz file, then running "preproc-sess", and I found freesurfer would detect the format of the input, and convert "*.mgz" to "*.nii.gz", finally I got Nifti1 data, with negative dim. Maybe there has an argument that could specify output format and convert output file format manually could solve it, but I think it would be helpful for other people who meet the same situation as me if nibabel could support reading these kind of data. Thanks for your opinions again, and I believe we hold the same view:) Best, Bai Haohao On Thu, Jul 27, 2017 at 11:59 PM, Christopher Markiewicz wrote: I agree with this viewpoint from a user/standards perspective. AFAIK only FreeSurfer and nibabel support the surface hacks, and both also support the .mgh format, so there's no real advantage to using NIfTI here. For interoperability, other formats are more appropriate. I also think it's reasonable to encourage FreeSurfer to move toward writing NIfTI-2 when hacks are necessary to generate NIfTI-1 files. From a nibabel-as-multitool perspective, while I understand the concern about propagating broken formats, I also think we should be able to read images as created by existing packages, as long as doing so doesn't harm our ability to read standard-conforming files. Chris On Thu, Jul 27, 2017 at 10:18 AM, Reynolds, Richard C. (NIH/NIMH) [E] wrote: This seems like an appropriate case to be using the NIFTI-2 standard, which uses 64-bit values rather than the 16-bits for NIFTI-1 (which was done just to keep it similar to ANALYZE). For that matter, GIFTI was made to be the surface alternative to NIFTI, and FreeSurfer supports it, as does nibabel, it seems. Even without those options, it seems like FreeSurfer can still output what you want in a useful format. Breaking the NIFTI-1 standard is causing you trouble. Maybe propagating that is not necessary. - rick From: Bai Haohao Sent: Thursday, July 27, 2017 9:41:13 AM To: neuroimaging at python.org Subject: [Neuroimaging] Fwd: [Freesurfer] negative header after preproc-sess Dear nibabel experts, I forward this email to nibabel mailing list because I think it is related to nibabel, even this problem is caused by nifti standard and freesurfer. I am using nibabel to load data after freesurfer "preproc-sess -suface self" and I get negative dim(-1 1 1, see origin email for detail), which makes nibabel.get_data() failed, but freesurfer first level analysis can be done successfully, in my view it means freesurfer can get data from this bad header. I find a way to solve it is by using "mri_convert *.nii.gz *.mgz", then nibabel could get data from *.mgz. But I think if nibabel could support getting data from negative header file would be more helpful. Just some undevelopped thoughts, I hope I express it clearly. Best, Bai Haohao ---------- Forwarded message ---------- From: Douglas Greve Date: Thu, Jul 6, 2017 at 7:07 AM Subject: Re: [Freesurfer] negative header after preproc-sess To: freesurfer at nmr.mgh.harvard.edu When the nifti standard was adopted, they used a short int to represent the dimensions. Unfortunately, this only allows for a maximum dimension of 32k, which is not big enough for surfaces. So I hacked the FS nifti format to put a -1 as the first dim at which point the FS code will go to another place in the header to get the spatial dimensions. It is possible to reshape the spatial dimensions as long as the largest prime factor is less than 32k (see mri_surf2surf with --reshape option). Other than that, you might ask the nibabel people to program the same hack. On 6/25/17 6:48 AM, Bai Haohao wrote: Hello Freesurfer experts, I am running my data with preproc-sess to project my func data to individual anatomy file, and the command shows as below: preproc-sess -sf ${Sesslist} -fsd "bold" -surface self lhrh -fwhm 0 -per-run -force And the subjectname point to the subject dir that created after recon-all. After the running completed, I try to load data from fmcpr.sm0.self.lh.nii.gz with nibabel, and I get this error info: >>> f.get_data() Traceback (most recent call last): File "", line 1, in File "/usr/lib/pymodules/python2.7/nibabel/spatialimages.py", line 341, in get_data return np.asanyarray(self._data) File "/usr/lib/python2.7/dist-packages/numpy/core/numeric.py", line 512, in asanyarray return array(a, dtype, copy=False, order=order, subok=True) File "/usr/lib/pymodules/python2.7/nibabel/arrayproxy.py", line 55, in __array__ self._data = self._read_data() File "/usr/lib/pymodules/python2.7/nibabel/arrayproxy.py", line 60, in _read_data data = self.header.data_from_fileobj(fileobj) File "/usr/lib/pymodules/python2.7/nibabel/analyze.py", line 486, in data_from_fileobj data = self.raw_data_from_fileobj(fileobj) File "/usr/lib/pymodules/python2.7/nibabel/analyze.py", line 458, in raw_data_from_fileobj return array_from_file(shape, dtype, fileobj, offset) File "/usr/lib/pymodules/python2.7/nibabel/volumeutils.py", line 493, in array_from_file raise IOError(msg) IOError: Expected -1804 bytes, got 264809160 bytes from file "fmcpr.vol2surf.lh.nii.gz" - could the file be damaged? Then I check the file header by nibabel, and I get this: >>> print(f.get_header()) object, endian='<' sizeof_hdr : 348 data_type : db_name : extents : 0 session_error : 0 regular : dim_info : 0 dim : [ 4 -1 1 1 451 1 1 1] intent_p1 : 0.0 intent_p2 : 0.0 intent_p3 : 0.0 intent_code : none datatype : float32 bitpix : 32 slice_start : 0 pixdim : [-1. 1. 1. 1. 2.00000072 1. 1. 1. ] vox_offset : 352.0 scl_slope : 0.0 scl_inter : 0.0 slice_end : 0 slice_code : unknown xyzt_units : 10 cal_max : 0.0 cal_min : 0.0 slice_duration : 0.0 toffset : 0.0 glmax : 0 glmin : 146790 descrip : FreeSurfer May 13 2013 aux_file : qform_code : scanner sform_code : scanner quatern_b : -0.0115927606821 quatern_c : -0.996071338654 quatern_d : -0.0864994972944 qoffset_x : 73344.5546875 qoffset_y : -1492.14978027 qoffset_z : -2311.28955078 srow_x : [ -9.99280393e-01 2.56918129e-02 2.79041883e-02 7.33445547e+04] srow_y : [ 2.04970520e-02 9.84766901e-01 -1.72667429e-01 -1.49214978e+03] srow_z : [ 3.19152586e-02 1.71971247e-01 9.84584868e-01 -2.31128955e+03] intent_name : magic : n+1 Note that the dim has value -1, but when I use -surface fsaverage, the dim is correct(show as below): dim : [ 4 27307 1 6 451 1 1 1] And I read the source code, the difference between self and fsaverage is appeared when running rawfunc2surf-sess, and log files are attached. I have tried many commands to load data from fmcpr.sm0.self.lh.nii.gz, such as fslview, freeview, mri_convert, mri_surf2surf, ... and only tksurfer could read this file by -timecourse fmcpr.sm0.self.lh.nii.gz. I want to figure out how could I fix it, and any suggestion would be helpful. Thanks in advance, Bai Haohao Version info: System: ubuntu-16.04.1-server-amd64 Freesurfer: freesurfer-Linux-centos4_x86_64-stable-pub-v5.3.0-HCP nibabel: python-nibabel 1.2.2-1 _______________________________________________ Freesurfer mailing list Freesurfer at nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer _______________________________________________ Freesurfer mailing list Freesurfer at nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer 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. _______________________________________________ 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 stjeansam at gmail.com Sun Jul 30 01:10:45 2017 From: stjeansam at gmail.com (Samuel St-Jean) Date: Sun, 30 Jul 2017 07:10:45 +0200 Subject: [Neuroimaging] noise estimation in non diffusion datasets Message-ID: <370a450e-b55c-faad-6156-df6231452cab@gmail.com> Hello, I've been trying out some stuff recently with another guy on 'legacy' datasets, which comprise CT scans and stuff like T1w which are 0.8x0.8x8 mm. Unsurprisingly, they also have huge gradient intensity since these things dates back from when I started high school. Anyway, they also have diffusion data and noise estimation stuff works kind of ok, but the other weighting and modality are mostly a no go or perhaps could be done way better) using the diffusion tools we have now. So far I've also tried an aonlm-like noise estimator, but I was wondering if people working with all types of datasets (I am mostly a diffusion mri person in the first place) had suggestions about good or commonly used noise estimator and where to find them? Most likely candidate for that would be the fmri guys I'd guess, and of course those scans did not have a/some noise maps back in the days. Thanks for the help and pointers, Samuel From arokem at gmail.com Mon Jul 31 07:39:51 2017 From: arokem at gmail.com (Ariel Rokem) Date: Mon, 31 Jul 2017 04:39:51 -0700 Subject: [Neuroimaging] noise estimation in non diffusion datasets In-Reply-To: <370a450e-b55c-faad-6156-df6231452cab@gmail.com> References: <370a450e-b55c-faad-6156-df6231452cab@gmail.com> Message-ID: Hi Samuel, On Sat, Jul 29, 2017 at 10:10 PM, Samuel St-Jean wrote: > Hello, > > I've been trying out some stuff recently with another guy on 'legacy' > datasets, which comprise CT scans and stuff like T1w which are 0.8x0.8x8 > mm. Unsurprisingly, they also have huge gradient intensity since these > things dates back from when I started high school. Anyway, they also have > diffusion data and noise estimation stuff works kind of ok, but the other > weighting and modality are mostly a no go or perhaps could be done way > better) using the diffusion tools we have now. > > So far I've also tried an aonlm-like noise estimator, but I was wondering > if people working with all types of datasets (I am mostly a diffusion mri > person in the first place) had suggestions about good or commonly used > noise estimator and where to find them? Most likely candidate for that > would be the fmri guys I'd guess, and of course those scans did not have > a/some noise maps back in the days. > > You may be interested in this model-based approach: http://journal.frontiersin.org/article/10.3389/fnins.2013.00247/full It's somewhat related to this DWI method: https://pdfs.semanticscholar.org/8e89/03f8092c27d159879a3a2429a771d21b7be8.pdf Cheers, Ariel > Thanks for the help and pointers, > > Samuel > > > _______________________________________________ > Neuroimaging mailing list > Neuroimaging at python.org > https://mail.python.org/mailman/listinfo/neuroimaging > -------------- next part -------------- An HTML attachment was scrubbed... URL: