From hendr522 at umn.edu  Thu Jun  1 11:58:22 2017
From: hendr522 at umn.edu (Timothy Hendrickson)
Date: Thu, 1 Jun 2017 10:58:22 -0500
Subject: [Neuroimaging] Changing overlay colors
Message-ID: <CACSGCcjoeB6W6H0XpdQ0THha2uAZTc7UZaN1Ljm+h3Cozc1_aw@mail.gmail.com>

Hello,

What I would like to do is create a split brain display, place up to four
overlays on the split brain underlay, and colorize each of the four
overlays appropriately. I've looked at the example code and was able to
display my overlays on the brain underlay, however when I try to colorize
the overlays with the Brain.overlays object as is shown in
fmri_conjunction.py I get the following error: *ValueError: Cannot access
brain.overlays when more than one view is plotted. Use brain.brain_matrix
or brain.brains*. I've tried tinkering with  the brain_matrix and brains
objects, however I am only a sporadic python user and I am having trouble
finding documentation about these objects.

Any help would be much appreciated!

-Tim

Timothy Hendrickson
Department of Psychiatry
University of Minnesota
Bioinformatics and Computational Biology M.S. Candidate
Office: 612-624-6441
Mobile: 507-259-3434 (texts okay)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20170601/543f1062/attachment.html>

From 744652457 at qq.com  Sun Jun  4 10:42:28 2017
From: 744652457 at qq.com (=?ISO-8859-1?B?LS0=?=)
Date: Sun, 4 Jun 2017 22:42:28 +0800
Subject: [Neuroimaging] load data and get negative dim in header
Message-ID: <tencent_4B931E1C66EDD5A66F5400F3@qq.com>

Hello,


I use "preproc-sess" command of Freesurfer to to project my func data to individual anatomy space,


preproc-sess -sf ${Sesslist} -fsd "bold" -surface self lhrh -fwhm 0 -per-run -force


and I try to load nifti data with "get_data()" of nibabel, but it could not work, error info is here:


>>> f.get_data()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  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 header, and I mark the negative value in "dim" of the header:

>>> print(f.get_header())

<class 'nibabel.nifti1.Nifti1Header'> 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



Well, I have tried to connect Freesurfer mailing list, but there may be something wrong with my e-mail address,


and it would be helpful to me if you tell me why there is an negative value in the header or how can I fix it.


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20170604/1156ad9c/attachment.html>

From satra at mit.edu  Sun Jun  4 11:54:47 2017
From: satra at mit.edu (Satrajit Ghosh)
Date: Sun, 4 Jun 2017 11:54:47 -0400
Subject: [Neuroimaging] load data and get negative dim in header
In-Reply-To: <tencent_4B931E1C66EDD5A66F5400F3@qq.com>
References: <tencent_4B931E1C66EDD5A66F5400F3@qq.com>
Message-ID: <CA+A4wOm_Qu4c9Z9=BOcF=Qk7Mmw0swTMObsoKpQ6kj21C6SbUg@mail.gmail.com>

hi,

these are "freesurfer" nifti files that stores the values across the
vertices in a nifti format file. as such, they are not valid files with
respect to the nifti standard. essentially the data is a single array of
values corresponding to the surface indices.

cheers,

satra

On Sun, Jun 4, 2017 at 10:42 AM, -- <744652457 at qq.com> wrote:

> Hello,
>
> I use "preproc-sess" command of Freesurfer to to project my func data to
> individual anatomy space,
>
> preproc-sess -sf ${Sesslist} -fsd "bold" -surface self lhrh -fwhm 0
> -per-run -force
>
>
> and I try to load nifti data with "get_data()" of nibabel, but it could
> not work, error info is here:
>
>
> >>> f.get_data()
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   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 header, and I mark the negative value in "dim" of the
> header:
>
> >>> print(f.get_header())
> <class 'nibabel.nifti1.Nifti1Header'> 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
>
>
> Well, I have tried to connect Freesurfer mailing list, but there may be
> something wrong with my e-mail address,
>
> and it would be helpful to me if you tell me why there is an negative
> value in the header or how can I fix it.
>
> 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
>
> _______________________________________________
> Neuroimaging mailing list
> Neuroimaging at python.org
> https://mail.python.org/mailman/listinfo/neuroimaging
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20170604/ccd82b21/attachment.html>

From jasmine.s.patil at gmail.com  Tue Jun  6 13:35:28 2017
From: jasmine.s.patil at gmail.com (Jasmine Patil)
Date: Tue, 6 Jun 2017 10:35:28 -0700
Subject: [Neuroimaging] Visualization of nifti image
Message-ID: <CA+13O01Q4EdGPe6bDJnTWvACc__W-6KXc5dWdxSJgqHVBkOAYQ@mail.gmail.com>

Hello,

I am trying to visualize a nifti file using plotting.plot_anat. There are
no errors in the execution but I cannot see any image after running the
code. Please help. I am new to python.

Thank you,
Jasmine Patil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20170606/25d6f462/attachment.html>

From anoopjt at iitrpr.ac.in  Wed Jun  7 08:10:43 2017
From: anoopjt at iitrpr.ac.in (Anoop Jacob Thomas)
Date: Wed, 7 Jun 2017 17:40:43 +0530
Subject: [Neuroimaging] Visualization of nifti image
In-Reply-To: <CA+13O01Q4EdGPe6bDJnTWvACc__W-6KXc5dWdxSJgqHVBkOAYQ@mail.gmail.com>
References: <CA+13O01Q4EdGPe6bDJnTWvACc__W-6KXc5dWdxSJgqHVBkOAYQ@mail.gmail.com>
Message-ID: <CAHR+ZkxDdhtv-Y0ySH1KT6+u3c3Zje6yEoj0T=ES906cAPmW5Q@mail.gmail.com>

Try plotting.show() after your plot_anat  function call

On Jun 7, 2017 5:37 PM, "Jasmine Patil" <jasmine.s.patil at gmail.com> wrote:

> Hello,
>
> I am trying to visualize a nifti file using plotting.plot_anat. There are
> no errors in the execution but I cannot see any image after running the
> code. Please help. I am new to python.
>
> Thank you,
> Jasmine Patil
>
> _______________________________________________
> Neuroimaging mailing list
> Neuroimaging at python.org
> https://mail.python.org/mailman/listinfo/neuroimaging
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20170607/7fdeac45/attachment.html>

From jaime.arias at inria.fr  Wed Jun  7 08:11:06 2017
From: jaime.arias at inria.fr (Jaime Arias)
Date: Wed, 7 Jun 2017 14:11:06 +0200
Subject: [Neuroimaging] Visualization of nifti image
In-Reply-To: <CA+13O01Q4EdGPe6bDJnTWvACc__W-6KXc5dWdxSJgqHVBkOAYQ@mail.gmail.com>
References: <CA+13O01Q4EdGPe6bDJnTWvACc__W-6KXc5dWdxSJgqHVBkOAYQ@mail.gmail.com>
Message-ID: <e8d3f500-8858-e141-69b6-01b0806f1a0b@inria.fr>

Hi,

please share the code that you're executing.

Jaime.


On 06/06/2017 07:35 PM, Jasmine Patil wrote:
> Hello,
>
> I am trying to visualize a nifti file using plotting.plot_anat. There
> are no errors in the execution but I cannot see any image after
> running the code. Please help. I am new to python.
>
> Thank you,
> Jasmine Patil
>
>
> _______________________________________________
> Neuroimaging mailing list
> Neuroimaging at python.org
> https://mail.python.org/mailman/listinfo/neuroimaging

-- 
Jaime Arias, Ph.D
Research Engineer, Mistis team
Inria Grenoble Rh?ne-Alpes
url: https://himito.github.io

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20170607/0865f6c7/attachment.html>

From jdgispert at fpmaragall.org  Fri Jun  9 06:36:31 2017
From: jdgispert at fpmaragall.org (=?UTF-8?Q?Juan_Domingo_Gispert_L=C3=B3pez?=)
Date: Fri, 9 Jun 2017 12:36:31 +0200
Subject: [Neuroimaging] Official Freesurfer Course in Barcelona
Message-ID: <CACaDTpv8OFFKrutf31AD3CVChmubMW2B40XNsS03-ZqQgQoHhw@mail.gmail.com>

Dear colleagues,


An official FreeSurfer Course will be held September 5th through September
8th, 2017 in Barcelona, Spain. This course is organized by BarcelonaBeta
Brain Research Center and Universidad Carlos III de Madrid with the support
of Universitat Pompeu Fabra. The schedule for this course will be similar
in content to the Boston courses. Please visit the following link for more
information: https://surfer.nmr.mgh.harvard.edu/fswiki/CourseDescription


Online registration for the course is open and can be completed here
<https://docs.google.com/a/fpmaragall.org/forms/d/e/1FAIpQLSfRU0RZW512UYwag4Vf8KGUwd7qNqz-nYOcz3GVcl-SIt22AQ/viewform>
.


If you have further questions, please visit the registration website or
contact Julieta Pereda (jpereda at red-innova.es) for payments or Emma Boyd (
eboyd2 at mgh.harvard.edu) for registration and course content.


Best regards,


Juan Domingo
-- 

*Juan D Gispert*
Head Neuroimaging Research
*Barcelona**?**eta **Brain Research Center - Fundaci? Pasqual Maragall*
T. (+34) 93 326 31 90
C/ Wellington, 30
08005 Barcelona
*www.fpmaragall.org <http://www.fpmaragall.org/>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20170609/5f438f58/attachment.html>

From tom at maladmin.com  Wed Jun 14 14:49:01 2017
From: tom at maladmin.com (Tom Wright)
Date: Wed, 14 Jun 2017 18:49:01 +0000
Subject: [Neuroimaging] [nipype] Problems with SGEGraph plugin
Message-ID: <CAKmUXV8LFPkpYO6KgA7=+2LsOPGP_c-phm_QVyqd3xJYPa3J3g@mail.gmail.com>

Hi All,
I hope someone has seen this before. I have a workflow that works fine on a
single computer. However when I submit to the cluster all jobs fail:

$ cat
working_dir_sge/2tensor/batch/batchscript_pyscript_20170614_144402_2tensor_selectFiles.sh.e
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Fatal Python error: Py_Initialize: Unable to get the locale encoding
ModuleNotFoundError: No module named 'encodings'

Current thread 0x00002b91eeea9400 (most recent call first):
/var/spool/gridengine/execd/mansfield/job_scripts/944321: line 6: 19024
Aborted                 (core dumped)
/mnt/tigrlab/projects/twright/Projects/tractmap_singularity/venv/bin/python
working_dir_sge/2tensor/batch/pyscript_20170614_144402_2tensor_selectFiles.py

python / nipype etc. is setup in a virtualenv which has been made
relocatable.

Thanks for any advice.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20170614/f0ac486c/attachment.html>

From mailsik at gmail.com  Thu Jun 15 11:22:14 2017
From: mailsik at gmail.com (Sik)
Date: Thu, 15 Jun 2017 15:22:14 +0000
Subject: [Neuroimaging] nibabel discussions
Message-ID: <CA+7QG_P4f2m0=XU+bzv5w-odyCfbN34+CJ=B3ZTu6aw+gVF1vQ@mail.gmail.com>

I was looking for a nibabel channel in gitter, but there's none. Is there a
preferred manner to discuss punctual topics related to nibabel rather than
github's issue tracker?

thanks, Sik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20170615/62889161/attachment.html>

From matthew.brett at gmail.com  Thu Jun 15 11:27:49 2017
From: matthew.brett at gmail.com (Matthew Brett)
Date: Thu, 15 Jun 2017 16:27:49 +0100
Subject: [Neuroimaging] nibabel discussions
In-Reply-To: <CA+7QG_P4f2m0=XU+bzv5w-odyCfbN34+CJ=B3ZTu6aw+gVF1vQ@mail.gmail.com>
References: <CA+7QG_P4f2m0=XU+bzv5w-odyCfbN34+CJ=B3ZTu6aw+gVF1vQ@mail.gmail.com>
Message-ID: <CAH6Pt5rT8L2_OrQ5p67BnqqCALFz55pOBFFHuEE-RCUeufEuuA@mail.gmail.com>

Hi,

On Thu, Jun 15, 2017 at 4:22 PM, Sik <mailsik at gmail.com> wrote:
> I was looking for a nibabel channel in gitter, but there's none. Is there a
> preferred manner to discuss punctual topics related to nibabel rather than
> github's issue tracker?

I personally like to use the mailing list for that - partly because
I'm already overwhelmed by internet communication, so adding another
forum that I have to monitor doesn't seem like much fun.

That said - we do try and answer quickly on the mailing list - if we
don't, please feel free to pester.

Cheers,

Matthew

From effigies at bu.edu  Thu Jun 15 11:27:20 2017
From: effigies at bu.edu (Christopher Markiewicz)
Date: Thu, 15 Jun 2017 11:27:20 -0400
Subject: [Neuroimaging] nibabel discussions
In-Reply-To: <CA+7QG_P4f2m0=XU+bzv5w-odyCfbN34+CJ=B3ZTu6aw+gVF1vQ@mail.gmail.com>
References: <CA+7QG_P4f2m0=XU+bzv5w-odyCfbN34+CJ=B3ZTu6aw+gVF1vQ@mail.gmail.com>
Message-ID: <CAHE-diNVMDanKRBmxK7iUqWKEYdvyb7uDWVpDBLctN3FuD4ncA@mail.gmail.com>

Hi Sik,

As far as I know, this mailing list and the issue tracker are the main
forums for discussing nibabel.

Chris

On Thu, Jun 15, 2017 at 11:22 AM, Sik <mailsik at gmail.com> wrote:

> I was looking for a nibabel channel in gitter, but there's none. Is there
> a preferred manner to discuss punctual topics related to nibabel rather
> than github's issue tracker?
>
> thanks, Sik
>
> _______________________________________________
> Neuroimaging mailing list
> Neuroimaging at python.org
> https://mail.python.org/mailman/listinfo/neuroimaging
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20170615/3a462a7f/attachment.html>

From contact at dictaconference.org  Thu Jun 15 04:46:29 2017
From: contact at dictaconference.org (contact at dictaconference.org)
Date: Thu, 15 Jun 2017 01:46:29 -0700
Subject: [Neuroimaging] [Reminder: Deadline in One Month] DICTA 2017,
 29 Nov - 1 Dec 2017, Sydney, Australia - Call for Papers
Message-ID: <20170615014629.Horde.zNdpkjPKtwER-mFvVClBD9T@p3plcpnl0984.prod.phx3.secureserver.net>

[Please accept our apologies if you receive multiple copies of this]

2017 International Conference on Digital Image Computing: Techniques  
and Applications (DICTA 2017) 29th Nov - 1st Dec, 2017, Sydney,  
Australia

Website: http://dicta2017.dictaconference.org/
Contact: contact at dictaconference.org

Special session proposal submission deadline: 9th Jun, 2017.
Paper Submission Deadline: 9th July, 2017.
Tutorial proposal submission deadline: 25th July, 2017.

Call for Papers
================
The International Conference on Digital Image Computing: Techniques  
and Applications (DICTA) is the main Australian Conference on computer  
vision, image processing, pattern recognition, and related areas.  
DICTA was established in 1991 as the premier conference of the  
Australian Pattern Recognition Society (APRS).

DICTA 2017 is co-sponsored by the Institute of Electrical and  
Electronics Engineers (IEEE) and the International Association for  
Pattern Recognition (IAPR). All papers presented at the conference  
will be included in IEEE Xplore. The conference will feature various  
prizes (e.g., best paper prizes), keynote talks, and tutorials. The  
conference venue is Novotel Sydney Manly Pacific at the iconic Manly  
Beach, Sydney, Australia.

Topics include, but are not limited to:
* Image/video acquisition, coding, processing, and analysis
* Shape and texture analysis
* Surveillance, defence and industrial applications
* Remote sensing and spectral imaging
* Astronomical image analysis
* Statistical and structural pattern recognition
* Computer vision
* Machine learning
* Human-computer interaction
* Biomedical and eHealth applications
* Content-based image/video retrieval and image/video databases

Paper Submission Deadline: 9th July 2017
Notice of Acceptance: 25th August 2017

Authors are invited to submit papers of up to 8 pages according to the  
guidelines on the conference website. The peer-reviewed conference  
content will be submitted for inclusion in IEEE Xplore.? It is a  
condition of publication that accepted papers are presented by one of  
the authors. Presenters of accepted papers must register before the  
camera-ready deadline to avoid withdrawal from the conference  
proceedings and technical programme.

Call for Special Sessions, Tutorials, and Sponsorship
================
Special session organizers are invited to submit a proposal to the  
conference no later than 9th June 2017.
A tutorial session will be organized on 28th Nov 2017 (the day before  
the conference). Tutorial speakers are invited to submit tutorial  
proposals on interesting and relevant topics to the conference by 25th  
July 2017.
Sponsors are invited to contact the conference for the details of the  
sponsorship arrangement.

For any questions on DICTA 2017, please contact the conference by  
email at contact at dictaconference.org.

Organizing Committee

General Chairs
? ?A/Prof Zhiyong Wang (The University of Sydney, Australia)
? ?Prof Junbin Gao (The University of Sydney, Australia)
? ?Prof David Feng (The University of Sydney, Australia)

Technical Program Chairs
? ?Dr Yi Guo (The Western Sydney University, Australia)
? ?A/Prof Hongdong Li (Australia National University, Australia)
? ?A/Prof Tom Cai (The University of Sydney, Australia)
? ?Prof Manzur Murshed (Federation University Australia)

Local Arrangement Chairs
? ?Dr Xiuying Wang (The University of Sydney, Australia)
? ?Dr Tongliang Liu (The University of Sydney, Australia)
? ?Prof Dong Xu (The University of Sydney, Australia)

Publicity Chair
? ?A/Prof Markus Hagenbuchner (The University of Wollongong, Australia)
? ?A/Prof Shan Zeng (Wuhan Polytechnic University, China)
? ?A/Prof Jinman Kim (The University of Sydney, Australia)

Sponsorship Chairs
? ?Prof Massimo Piccardi (University of Technology, Sydney, Australia)
? ?Dr Chang Xu (The University of Sydney, Australia)

Treasurer
? ?Mr Tony Adriaansen (Australian Pattern Recognition Society, Australia)

Web Chair
? ?A/Prof Wenxiong Kang (South China University of China, China)
? ?Mr Boyan Zhang (The University of Sydney, Australia)

Advisory Committee
? ?Prof Anton van den Hengel (University of Adelaide, Australia)
? ?Dr Antonio Robles-Kelly (Data61, Australia)
? ?Prof Brian Lovell (University of Queensland, Australia)
? ?Prof Dacheng Tao (The University of Sydney, Australia)
? ?Dr David Tien (IEEE Computer Chapter NSW, Australia)
? ?Dr Jun Zhou (Griffith University, Australia)
? ?Prof Michael Blumenstein (University of Technology, Sydney, Australia)
? ?Prof Mohammed Bennamoun (The University of Western Australia, Australia)
? ?A/Prof Murk Bottema (Flinders University, Australia)
? ?Prof Nick Redding (Defence Science and Technology Group, Australia)
? ?Prof Yongsheng Gao (Griffith University, Australia)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20170615/76cb6fd9/attachment.html>

From matthew.brett at gmail.com  Thu Jun 29 13:50:44 2017
From: matthew.brett at gmail.com (Matthew Brett)
Date: Thu, 29 Jun 2017 18:50:44 +0100
Subject: [Neuroimaging] JSON-LD and DICOM?
Message-ID: <CAH6Pt5qs81BKff=Kq7rfBfpLd1UUYO8gnMgDm2FL8BcXjB4D+A@mail.gmail.com>

Hi,

I'm just in the middle of reviewing the JSON header proposal, we
discussed a while ago:

https://mail.scipy.org/pipermail/nipy-devel/2014-July/010087.html

https://github.com/nipy/nibabel/wiki/json-header-extension

In particular, I'm returning to the problem of storing DICOM
information in the NIfTI header.

Satra - at the time, you proposed using JSON-LD, which does sound like
a good idea, but I was looking for a JSON-LD context for DICOM, and I
couldn't find one.  Does anyone know of any JSON-LD contexts for
DICOM?

Cheers,

Matthew

From satra at mit.edu  Fri Jun 30 03:31:04 2017
From: satra at mit.edu (Satrajit Ghosh)
Date: Fri, 30 Jun 2017 00:31:04 -0700
Subject: [Neuroimaging] JSON-LD and DICOM?
In-Reply-To: <CAH6Pt5qs81BKff=Kq7rfBfpLd1UUYO8gnMgDm2FL8BcXjB4D+A@mail.gmail.com>
References: <CAH6Pt5qs81BKff=Kq7rfBfpLd1UUYO8gnMgDm2FL8BcXjB4D+A@mail.gmail.com>
Message-ID: <CA+A4wOne9it5D4DC5jR3xF6suRabpY1fYhedGqdejX0Mf1+L_Q@mail.gmail.com>

hi matthew,

i'm cc:ing andrey to check if he has one. her wrote a very brief one here:

https://github.com/QIICR/dcmqi/blob/master/doc/definitions/dcmqi.jsonld

cheers,

satra

On Thu, Jun 29, 2017 at 10:50 AM, Matthew Brett <matthew.brett at gmail.com>
wrote:

> Hi,
>
> I'm just in the middle of reviewing the JSON header proposal, we
> discussed a while ago:
>
> https://mail.scipy.org/pipermail/nipy-devel/2014-July/010087.html
>
> https://github.com/nipy/nibabel/wiki/json-header-extension
>
> In particular, I'm returning to the problem of storing DICOM
> information in the NIfTI header.
>
> Satra - at the time, you proposed using JSON-LD, which does sound like
> a good idea, but I was looking for a JSON-LD context for DICOM, and I
> couldn't find one.  Does anyone know of any JSON-LD contexts for
> DICOM?
>
> Cheers,
>
> Matthew
> _______________________________________________
> Neuroimaging mailing list
> Neuroimaging at python.org
> https://mail.python.org/mailman/listinfo/neuroimaging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20170630/cba79717/attachment.html>

From andrey.fedorov at gmail.com  Fri Jun 30 09:25:02 2017
From: andrey.fedorov at gmail.com (Andrey Fedorov)
Date: Fri, 30 Jun 2017 09:25:02 -0400
Subject: [Neuroimaging] JSON-LD and DICOM?
In-Reply-To: <CA+A4wOne9it5D4DC5jR3xF6suRabpY1fYhedGqdejX0Mf1+L_Q@mail.gmail.com>
References: <CAH6Pt5qs81BKff=Kq7rfBfpLd1UUYO8gnMgDm2FL8BcXjB4D+A@mail.gmail.com>
 <CA+A4wOne9it5D4DC5jR3xF6suRabpY1fYhedGqdejX0Mf1+L_Q@mail.gmail.com>
Message-ID: <CAMw6MkdDD=X=ynvSW-=2h-4oXLGXYAE0TrMBr02Ua9Ez_XQNSw@mail.gmail.com>

Hi guys,

no, I don't think that file will be useful to you.

For us, the plan was to utilize that file as a central location to
link to the DICOM standard text and attribute definitions, but it has
not yet become a priority to organize this. We are focused on the
functionality and bug fixes for the library.

If you come up with something, I would be curious to see, although I
don't think that copying DICOM attributes to a NIfTI header is a good
idea.

AF

On Fri, Jun 30, 2017 at 3:31 AM, Satrajit Ghosh <satra at mit.edu> wrote:
> hi matthew,
>
> i'm cc:ing andrey to check if he has one. her wrote a very brief one here:
>
> https://github.com/QIICR/dcmqi/blob/master/doc/definitions/dcmqi.jsonld
>
> cheers,
>
> satra
>
> On Thu, Jun 29, 2017 at 10:50 AM, Matthew Brett <matthew.brett at gmail.com>
> wrote:
>>
>> Hi,
>>
>> I'm just in the middle of reviewing the JSON header proposal, we
>> discussed a while ago:
>>
>> https://mail.scipy.org/pipermail/nipy-devel/2014-July/010087.html
>>
>> https://github.com/nipy/nibabel/wiki/json-header-extension
>>
>> In particular, I'm returning to the problem of storing DICOM
>> information in the NIfTI header.
>>
>> Satra - at the time, you proposed using JSON-LD, which does sound like
>> a good idea, but I was looking for a JSON-LD context for DICOM, and I
>> couldn't find one.  Does anyone know of any JSON-LD contexts for
>> DICOM?
>>
>> Cheers,
>>
>> Matthew
>> _______________________________________________
>> Neuroimaging mailing list
>> Neuroimaging at python.org
>> https://mail.python.org/mailman/listinfo/neuroimaging
>
>

From matthew.brett at gmail.com  Fri Jun 30 09:32:14 2017
From: matthew.brett at gmail.com (Matthew Brett)
Date: Fri, 30 Jun 2017 14:32:14 +0100
Subject: [Neuroimaging] JSON-LD and DICOM?
In-Reply-To: <CAMw6MkdDD=X=ynvSW-=2h-4oXLGXYAE0TrMBr02Ua9Ez_XQNSw@mail.gmail.com>
References: <CAH6Pt5qs81BKff=Kq7rfBfpLd1UUYO8gnMgDm2FL8BcXjB4D+A@mail.gmail.com>
 <CA+A4wOne9it5D4DC5jR3xF6suRabpY1fYhedGqdejX0Mf1+L_Q@mail.gmail.com>
 <CAMw6MkdDD=X=ynvSW-=2h-4oXLGXYAE0TrMBr02Ua9Ez_XQNSw@mail.gmail.com>
Message-ID: <CAH6Pt5pawt1f93=+SZkEXp0g4KQdTfO832r3QBY5PKo1PbcAMw@mail.gmail.com>

Hi,

On Fri, Jun 30, 2017 at 2:25 PM, Andrey Fedorov
<andrey.fedorov at gmail.com> wrote:
> Hi guys,
>
> no, I don't think that file will be useful to you.
>
> For us, the plan was to utilize that file as a central location to
> link to the DICOM standard text and attribute definitions, but it has
> not yet become a priority to organize this. We are focused on the
> functionality and bug fixes for the library.
>
> If you come up with something, I would be curious to see, although I
> don't think that copying DICOM attributes to a NIfTI header is a good
> idea.

That's interesting - why do you not think it's a good idea?

Best,

Matthew

From ibmalone at gmail.com  Fri Jun 30 11:41:40 2017
From: ibmalone at gmail.com (Ian Malone)
Date: Fri, 30 Jun 2017 16:41:40 +0100
Subject: [Neuroimaging] JSON-LD and DICOM?
In-Reply-To: <CAH6Pt5pawt1f93=+SZkEXp0g4KQdTfO832r3QBY5PKo1PbcAMw@mail.gmail.com>
References: <CAH6Pt5qs81BKff=Kq7rfBfpLd1UUYO8gnMgDm2FL8BcXjB4D+A@mail.gmail.com>
 <CA+A4wOne9it5D4DC5jR3xF6suRabpY1fYhedGqdejX0Mf1+L_Q@mail.gmail.com>
 <CAMw6MkdDD=X=ynvSW-=2h-4oXLGXYAE0TrMBr02Ua9Ez_XQNSw@mail.gmail.com>
 <CAH6Pt5pawt1f93=+SZkEXp0g4KQdTfO832r3QBY5PKo1PbcAMw@mail.gmail.com>
Message-ID: <CAL3-7MrYC4RCZCZOh1jfHU4GM8dy8qO-xc=_zDotWzBLUbG0WQ@mail.gmail.com>

On 30 June 2017 at 14:32, Matthew Brett <matthew.brett at gmail.com> wrote:
> Hi,
>
> On Fri, Jun 30, 2017 at 2:25 PM, Andrey Fedorov
> <andrey.fedorov at gmail.com> wrote:
>> Hi guys,
>>
>> no, I don't think that file will be useful to you.
>>
>> For us, the plan was to utilize that file as a central location to
>> link to the DICOM standard text and attribute definitions, but it has
>> not yet become a priority to organize this. We are focused on the
>> functionality and bug fixes for the library.
>>
>> If you come up with something, I would be curious to see, although I
>> don't think that copying DICOM attributes to a NIfTI header is a good
>> idea.
>
> That's interesting - why do you not think it's a good idea?
>

I'd be quite interested to see something like this, it would be useful
for processing pipelines where information that is present in the
DICOM files is required that currently needs to be supplied
out-of-band. The bandwidth per pixel attribute for example is needed
when applying susceptibility correction to EPI images from Siemens MRI
data, or even just the field strength attribute for MRI can be useful.
On the downside, DICOM is quite complex and used differently by
different vendors and modalities, so there can be multiple values of
attributes for series, study and patient levels, and different fields
that can be used - not all vendors use that bandwidth per pixel
attribute for EPI MRI data. Then you've got private blocks (can be
useful information, but very vendor idiosyncratic and another layer of
structure) and anonymisation to worry about. (Converting to NIfTI is a
good way to start cleaning identifiable information, since it leaves
you only a couple of fields that could contain anything identifiable
and almost certainly just contain the conversion software label.)
So... problems, but could be cool.

-- 
imalone

From andrey.fedorov at gmail.com  Fri Jun 30 11:53:52 2017
From: andrey.fedorov at gmail.com (Andrey Fedorov)
Date: Fri, 30 Jun 2017 11:53:52 -0400
Subject: [Neuroimaging] JSON-LD and DICOM?
In-Reply-To: <CAH6Pt5pawt1f93=+SZkEXp0g4KQdTfO832r3QBY5PKo1PbcAMw@mail.gmail.com>
References: <CAH6Pt5qs81BKff=Kq7rfBfpLd1UUYO8gnMgDm2FL8BcXjB4D+A@mail.gmail.com>
 <CA+A4wOne9it5D4DC5jR3xF6suRabpY1fYhedGqdejX0Mf1+L_Q@mail.gmail.com>
 <CAMw6MkdDD=X=ynvSW-=2h-4oXLGXYAE0TrMBr02Ua9Ez_XQNSw@mail.gmail.com>
 <CAH6Pt5pawt1f93=+SZkEXp0g4KQdTfO832r3QBY5PKo1PbcAMw@mail.gmail.com>
Message-ID: <CAMw6MkeRmvOowmELzBO0=AxzxHoXnYj41j0DicXdTMS+=EuL9Q@mail.gmail.com>

Matthew,

I believe that image data and derived data belongs to DICOM, and DICOM
is the format that should be used directly.

We applied these ideas and demonstrated some capabilities here
https://peerj.com/articles/2057/, and we continue the development of
supporting tools in DCMTK and in https://github.com/qiicr/dcmqi.

Perhaps if you give me some specifics about "why not DICOM", we could
have a bit more focused conversation.

I do realize and anticipate that you will take this as a complete heresy.

AF



On Fri, Jun 30, 2017 at 9:32 AM, Matthew Brett <matthew.brett at gmail.com> wrote:
> Hi,
>
> On Fri, Jun 30, 2017 at 2:25 PM, Andrey Fedorov
> <andrey.fedorov at gmail.com> wrote:
>> Hi guys,
>>
>> no, I don't think that file will be useful to you.
>>
>> For us, the plan was to utilize that file as a central location to
>> link to the DICOM standard text and attribute definitions, but it has
>> not yet become a priority to organize this. We are focused on the
>> functionality and bug fixes for the library.
>>
>> If you come up with something, I would be curious to see, although I
>> don't think that copying DICOM attributes to a NIfTI header is a good
>> idea.
>
> That's interesting - why do you not think it's a good idea?
>
> Best,
>
> Matthew

From matthew.brett at gmail.com  Fri Jun 30 12:06:14 2017
From: matthew.brett at gmail.com (Matthew Brett)
Date: Fri, 30 Jun 2017 17:06:14 +0100
Subject: [Neuroimaging] JSON-LD and DICOM?
In-Reply-To: <CAMw6MkeRmvOowmELzBO0=AxzxHoXnYj41j0DicXdTMS+=EuL9Q@mail.gmail.com>
References: <CAH6Pt5qs81BKff=Kq7rfBfpLd1UUYO8gnMgDm2FL8BcXjB4D+A@mail.gmail.com>
 <CA+A4wOne9it5D4DC5jR3xF6suRabpY1fYhedGqdejX0Mf1+L_Q@mail.gmail.com>
 <CAMw6MkdDD=X=ynvSW-=2h-4oXLGXYAE0TrMBr02Ua9Ez_XQNSw@mail.gmail.com>
 <CAH6Pt5pawt1f93=+SZkEXp0g4KQdTfO832r3QBY5PKo1PbcAMw@mail.gmail.com>
 <CAMw6MkeRmvOowmELzBO0=AxzxHoXnYj41j0DicXdTMS+=EuL9Q@mail.gmail.com>
Message-ID: <CAH6Pt5qpLOSJUd9nUJWYMVOgzYKQU5cWW8vxLgu60pmQsrU-ow@mail.gmail.com>

Hi,

On Fri, Jun 30, 2017 at 4:53 PM, Andrey Fedorov
<andrey.fedorov at gmail.com> wrote:
> Matthew,
>
> I believe that image data and derived data belongs to DICOM, and DICOM
> is the format that should be used directly.
>
> We applied these ideas and demonstrated some capabilities here
> https://peerj.com/articles/2057/, and we continue the development of
> supporting tools in DCMTK and in https://github.com/qiicr/dcmqi.
>
> Perhaps if you give me some specifics about "why not DICOM", we could
> have a bit more focused conversation.
>
> I do realize and anticipate that you will take this as a complete heresy.

Well - not heresy.  I understand what you mean, but there's a reason
that most brain imaging software doesn't use DICOMs as the native
format, so, if we don't import the information from the DICOMs, then
the user has to keep track of the relationship of the DICOMs and
NIfTIs, which seems like a high price to pay.

Cheers,

Matthew

From andrey.fedorov at gmail.com  Fri Jun 30 12:18:44 2017
From: andrey.fedorov at gmail.com (Andrey Fedorov)
Date: Fri, 30 Jun 2017 12:18:44 -0400
Subject: [Neuroimaging] JSON-LD and DICOM?
In-Reply-To: <CAH6Pt5qpLOSJUd9nUJWYMVOgzYKQU5cWW8vxLgu60pmQsrU-ow@mail.gmail.com>
References: <CAH6Pt5qs81BKff=Kq7rfBfpLd1UUYO8gnMgDm2FL8BcXjB4D+A@mail.gmail.com>
 <CA+A4wOne9it5D4DC5jR3xF6suRabpY1fYhedGqdejX0Mf1+L_Q@mail.gmail.com>
 <CAMw6MkdDD=X=ynvSW-=2h-4oXLGXYAE0TrMBr02Ua9Ez_XQNSw@mail.gmail.com>
 <CAH6Pt5pawt1f93=+SZkEXp0g4KQdTfO832r3QBY5PKo1PbcAMw@mail.gmail.com>
 <CAMw6MkeRmvOowmELzBO0=AxzxHoXnYj41j0DicXdTMS+=EuL9Q@mail.gmail.com>
 <CAH6Pt5qpLOSJUd9nUJWYMVOgzYKQU5cWW8vxLgu60pmQsrU-ow@mail.gmail.com>
Message-ID: <CAMw6Mke3BpiFF-nST1xXCYA7m-=4d06negViQe02M-PjZK=d2Q@mail.gmail.com>

It is always puzzling to me why neuro people are so eager to discard
the original data.

Yes, non-DICOM is expected by most image analysis software. Fine -
give that representation to those tools, but always keep the original
DICOM. Instead, you guys are coming up with "yet another" format...

I think coming up with a new format, developing supporting tools and
toolkits, propagating it through the community, debugging etc - that
is indeed a high price to pay, with benefits to be seen.

For what it's worth, keeping track of a relationship seems like a lot
more natural solution to me!

My 2c!


On Fri, Jun 30, 2017 at 12:06 PM, Matthew Brett <matthew.brett at gmail.com> wrote:
>
> Hi,
>
> On Fri, Jun 30, 2017 at 4:53 PM, Andrey Fedorov
> <andrey.fedorov at gmail.com> wrote:
> > Matthew,
> >
> > I believe that image data and derived data belongs to DICOM, and DICOM
> > is the format that should be used directly.
> >
> > We applied these ideas and demonstrated some capabilities here
> > https://peerj.com/articles/2057/, and we continue the development of
> > supporting tools in DCMTK and in https://github.com/qiicr/dcmqi.
> >
> > Perhaps if you give me some specifics about "why not DICOM", we could
> > have a bit more focused conversation.
> >
> > I do realize and anticipate that you will take this as a complete heresy.
>
> Well - not heresy.  I understand what you mean, but there's a reason
> that most brain imaging software doesn't use DICOMs as the native
> format, so, if we don't import the information from the DICOMs, then
> the user has to keep track of the relationship of the DICOMs and
> NIfTIs, which seems like a high price to pay.
>
> Cheers,
>
> Matthew

From effigies at bu.edu  Fri Jun 30 12:18:19 2017
From: effigies at bu.edu (Christopher Markiewicz)
Date: Fri, 30 Jun 2017 12:18:19 -0400
Subject: [Neuroimaging] JSON-LD and DICOM?
In-Reply-To: <CAMw6MkeRmvOowmELzBO0=AxzxHoXnYj41j0DicXdTMS+=EuL9Q@mail.gmail.com>
References: <CAH6Pt5qs81BKff=Kq7rfBfpLd1UUYO8gnMgDm2FL8BcXjB4D+A@mail.gmail.com>
 <CA+A4wOne9it5D4DC5jR3xF6suRabpY1fYhedGqdejX0Mf1+L_Q@mail.gmail.com>
 <CAMw6MkdDD=X=ynvSW-=2h-4oXLGXYAE0TrMBr02Ua9Ez_XQNSw@mail.gmail.com>
 <CAH6Pt5pawt1f93=+SZkEXp0g4KQdTfO832r3QBY5PKo1PbcAMw@mail.gmail.com>
 <CAMw6MkeRmvOowmELzBO0=AxzxHoXnYj41j0DicXdTMS+=EuL9Q@mail.gmail.com>
Message-ID: <CAHE-diNDaBRwQiu5HBEQD9komEDvHCUK2hY3CfECwmNM2PH5Jw@mail.gmail.com>

Andrey,

The ascription of metadata as "belonging to DICOM" seems restrictive to no
particular purpose but to promote the adoption of the DICOM format. Given
that people *do* convert DICOM to NIfTI, and want to keep the metadata
around, is there a technical reason that DICOM attributes shouldn't be used?

To be clear, I have nothing against DICOM, but the *vast* majority of data
I see is NIfTI, and NIfTI is probably the most consistently supported
format in the software packages I've seen. And preserving metadata through
analysis steps is a problem. Storing DICOM attributes in the NIfTI header
seems like a reasonable way to both preserve metadata in-band and avoid
inventing a new ontology that then needs to have a mapping to DICOM's.

As an aside, the aim of dcmqi seems to be to encourage people to convert
their results to DICOM, and a feature that allows DICOM attributes to be
maintained during analyses that expect data in NIfTI strikes me as, if
anything, supportive of that goal.

Chris


On Fri, Jun 30, 2017 at 11:53 AM, Andrey Fedorov <andrey.fedorov at gmail.com>
wrote:

> Matthew,
>
> I believe that image data and derived data belongs to DICOM, and DICOM
> is the format that should be used directly.
>
> We applied these ideas and demonstrated some capabilities here
> https://peerj.com/articles/2057/, and we continue the development of
> supporting tools in DCMTK and in https://github.com/qiicr/dcmqi.
>
> Perhaps if you give me some specifics about "why not DICOM", we could
> have a bit more focused conversation.
>
> I do realize and anticipate that you will take this as a complete heresy.
>
> AF
>
>
>
> On Fri, Jun 30, 2017 at 9:32 AM, Matthew Brett <matthew.brett at gmail.com>
> wrote:
> > Hi,
> >
> > On Fri, Jun 30, 2017 at 2:25 PM, Andrey Fedorov
> > <andrey.fedorov at gmail.com> wrote:
> >> Hi guys,
> >>
> >> no, I don't think that file will be useful to you.
> >>
> >> For us, the plan was to utilize that file as a central location to
> >> link to the DICOM standard text and attribute definitions, but it has
> >> not yet become a priority to organize this. We are focused on the
> >> functionality and bug fixes for the library.
> >>
> >> If you come up with something, I would be curious to see, although I
> >> don't think that copying DICOM attributes to a NIfTI header is a good
> >> idea.
> >
> > That's interesting - why do you not think it's a good idea?
> >
> > Best,
> >
> > Matthew
> _______________________________________________
> Neuroimaging mailing list
> Neuroimaging at python.org
> https://mail.python.org/mailman/listinfo/neuroimaging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20170630/7ef55bb0/attachment.html>

From japsai at gmail.com  Fri Jun 30 12:35:51 2017
From: japsai at gmail.com (Jasper van den Bosch)
Date: Fri, 30 Jun 2017 17:35:51 +0100
Subject: [Neuroimaging] JSON-LD and DICOM?
In-Reply-To: <CAMw6Mke3BpiFF-nST1xXCYA7m-=4d06negViQe02M-PjZK=d2Q@mail.gmail.com>
References: <CAH6Pt5qs81BKff=Kq7rfBfpLd1UUYO8gnMgDm2FL8BcXjB4D+A@mail.gmail.com>
 <CA+A4wOne9it5D4DC5jR3xF6suRabpY1fYhedGqdejX0Mf1+L_Q@mail.gmail.com>
 <CAMw6MkdDD=X=ynvSW-=2h-4oXLGXYAE0TrMBr02Ua9Ez_XQNSw@mail.gmail.com>
 <CAH6Pt5pawt1f93=+SZkEXp0g4KQdTfO832r3QBY5PKo1PbcAMw@mail.gmail.com>
 <CAMw6MkeRmvOowmELzBO0=AxzxHoXnYj41j0DicXdTMS+=EuL9Q@mail.gmail.com>
 <CAH6Pt5qpLOSJUd9nUJWYMVOgzYKQU5cWW8vxLgu60pmQsrU-ow@mail.gmail.com>
 <CAMw6Mke3BpiFF-nST1xXCYA7m-=4d06negViQe02M-PjZK=d2Q@mail.gmail.com>
Message-ID: <CAGjxhso0tD7LQ4CZHfg0TZMfEYvtNk29d=WKXY7gXOsKFDipkQ@mail.gmail.com>

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.

I did a little survey among niprov users and it turns out they usually
don't end up using the header to store the metadata, because the "central"
storage can more easily keep track of the relationships between files.
And if the file is overwritten, or moved, the metadata remains.

Jasper

On 30 June 2017 at 17:18, Andrey Fedorov <andrey.fedorov at gmail.com> wrote:

> It is always puzzling to me why neuro people are so eager to discard
> the original data.
>
> Yes, non-DICOM is expected by most image analysis software. Fine -
> give that representation to those tools, but always keep the original
> DICOM. Instead, you guys are coming up with "yet another" format...
>
> I think coming up with a new format, developing supporting tools and
> toolkits, propagating it through the community, debugging etc - that
> is indeed a high price to pay, with benefits to be seen.
>
> For what it's worth, keeping track of a relationship seems like a lot
> more natural solution to me!
>
> My 2c!
>
>
> On Fri, Jun 30, 2017 at 12:06 PM, Matthew Brett <matthew.brett at gmail.com>
> wrote:
> >
> > Hi,
> >
> > On Fri, Jun 30, 2017 at 4:53 PM, Andrey Fedorov
> > <andrey.fedorov at gmail.com> wrote:
> > > Matthew,
> > >
> > > I believe that image data and derived data belongs to DICOM, and DICOM
> > > is the format that should be used directly.
> > >
> > > We applied these ideas and demonstrated some capabilities here
> > > https://peerj.com/articles/2057/, and we continue the development of
> > > supporting tools in DCMTK and in https://github.com/qiicr/dcmqi.
> > >
> > > Perhaps if you give me some specifics about "why not DICOM", we could
> > > have a bit more focused conversation.
> > >
> > > I do realize and anticipate that you will take this as a complete
> heresy.
> >
> > Well - not heresy.  I understand what you mean, but there's a reason
> > that most brain imaging software doesn't use DICOMs as the native
> > format, so, if we don't import the information from the DICOMs, then
> > the user has to keep track of the relationship of the DICOMs and
> > NIfTIs, which seems like a high price to pay.
> >
> > Cheers,
> >
> > Matthew
> _______________________________________________
> Neuroimaging mailing list
> Neuroimaging at python.org
> https://mail.python.org/mailman/listinfo/neuroimaging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20170630/7b77a199/attachment.html>

From njvack at wisc.edu  Fri Jun 30 12:02:16 2017
From: njvack at wisc.edu (Nate Vack)
Date: Fri, 30 Jun 2017 16:02:16 +0000
Subject: [Neuroimaging] JSON-LD and DICOM?
In-Reply-To: <CAMw6MkeRmvOowmELzBO0=AxzxHoXnYj41j0DicXdTMS+=EuL9Q@mail.gmail.com>
References: <CAH6Pt5qs81BKff=Kq7rfBfpLd1UUYO8gnMgDm2FL8BcXjB4D+A@mail.gmail.com>
 <CA+A4wOne9it5D4DC5jR3xF6suRabpY1fYhedGqdejX0Mf1+L_Q@mail.gmail.com>
 <CAMw6MkdDD=X=ynvSW-=2h-4oXLGXYAE0TrMBr02Ua9Ez_XQNSw@mail.gmail.com>
 <CAH6Pt5pawt1f93=+SZkEXp0g4KQdTfO832r3QBY5PKo1PbcAMw@mail.gmail.com>
 <CAMw6MkeRmvOowmELzBO0=AxzxHoXnYj41j0DicXdTMS+=EuL9Q@mail.gmail.com>
Message-ID: <CA+1BpOvLqY47_miHRWOwnVHjdQpGUR1nEh+N9DOELTGy-Spz=w@mail.gmail.com>

On Fri, Jun 30, 2017 at 10:54 AM Andrey Fedorov <andrey.fedorov at gmail.com>
wrote:


> Perhaps if you give me some specifics about "why not DICOM", we could
> have a bit more focused conversation.
>

Our GE scanner records one dicom per slice, so a ten-minute fMRI session
yields something like 12,000 DICOMs. Working with 12k files is way more
irritating than working with one file.

DICOM isn't a bad format, but it adds logistical complications for our
applications.

-n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20170630/a2208c52/attachment.html>

From matthew.brett at gmail.com  Fri Jun 30 15:57:20 2017
From: matthew.brett at gmail.com (Matthew Brett)
Date: Fri, 30 Jun 2017 20:57:20 +0100
Subject: [Neuroimaging] JSON-LD and DICOM?
In-Reply-To: <CAGjxhso0tD7LQ4CZHfg0TZMfEYvtNk29d=WKXY7gXOsKFDipkQ@mail.gmail.com>
References: <CAH6Pt5qs81BKff=Kq7rfBfpLd1UUYO8gnMgDm2FL8BcXjB4D+A@mail.gmail.com>
 <CA+A4wOne9it5D4DC5jR3xF6suRabpY1fYhedGqdejX0Mf1+L_Q@mail.gmail.com>
 <CAMw6MkdDD=X=ynvSW-=2h-4oXLGXYAE0TrMBr02Ua9Ez_XQNSw@mail.gmail.com>
 <CAH6Pt5pawt1f93=+SZkEXp0g4KQdTfO832r3QBY5PKo1PbcAMw@mail.gmail.com>
 <CAMw6MkeRmvOowmELzBO0=AxzxHoXnYj41j0DicXdTMS+=EuL9Q@mail.gmail.com>
 <CAH6Pt5qpLOSJUd9nUJWYMVOgzYKQU5cWW8vxLgu60pmQsrU-ow@mail.gmail.com>
 <CAMw6Mke3BpiFF-nST1xXCYA7m-=4d06negViQe02M-PjZK=d2Q@mail.gmail.com>
 <CAGjxhso0tD7LQ4CZHfg0TZMfEYvtNk29d=WKXY7gXOsKFDipkQ@mail.gmail.com>
Message-ID: <CAH6Pt5q3NqBy3ge0k3bE14TaYH1B_DkGMw1kytufaKtB48Ww-Q@mail.gmail.com>

Hi,

On Fri, Jun 30, 2017 at 5:35 PM, Jasper van den Bosch <japsai at gmail.com> 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?

> I did a little survey among niprov users and it turns out they usually don't
> end up using the header to store the metadata, because the "central" storage
> can more easily keep track of the relationships between files.
> And if the file is overwritten, or moved, the metadata remains.

I think the DICOM / NIfTI thing is partly cultural.  If you're a C++ /
cluster sort of person, you tend to prefer DICOM, because there are
C(++) libraries to read the DICOMs, and setting up the libraries /
compiling isn't much of an issue, because everything you need can
easily be set up on the cluster.  If you're a Python / laptop sort of
person, then you tend to prefer NIfTI because it's such a simple
format that it's easy to write your own code to manipulate it, and the
code remains fairly readable, and no extra setup is needed other than
a `pip install pydicom`.

The JSON header extension is also an extremely obvious idea, that we
need to store just a little bit more metadata than we have now.  So -
why not store a lot more metadata than we have now?

Cheers,

Matthew

From bennet at umich.edu  Fri Jun 30 16:07:07 2017
From: bennet at umich.edu (Bennet Fauber)
Date: Fri, 30 Jun 2017 16:07:07 -0400
Subject: [Neuroimaging] JSON-LD and DICOM?
In-Reply-To: <CAH6Pt5q3NqBy3ge0k3bE14TaYH1B_DkGMw1kytufaKtB48Ww-Q@mail.gmail.com>
References: <CAH6Pt5qs81BKff=Kq7rfBfpLd1UUYO8gnMgDm2FL8BcXjB4D+A@mail.gmail.com>
 <CA+A4wOne9it5D4DC5jR3xF6suRabpY1fYhedGqdejX0Mf1+L_Q@mail.gmail.com>
 <CAMw6MkdDD=X=ynvSW-=2h-4oXLGXYAE0TrMBr02Ua9Ez_XQNSw@mail.gmail.com>
 <CAH6Pt5pawt1f93=+SZkEXp0g4KQdTfO832r3QBY5PKo1PbcAMw@mail.gmail.com>
 <CAMw6MkeRmvOowmELzBO0=AxzxHoXnYj41j0DicXdTMS+=EuL9Q@mail.gmail.com>
 <CAH6Pt5qpLOSJUd9nUJWYMVOgzYKQU5cWW8vxLgu60pmQsrU-ow@mail.gmail.com>
 <CAMw6Mke3BpiFF-nST1xXCYA7m-=4d06negViQe02M-PjZK=d2Q@mail.gmail.com>
 <CAGjxhso0tD7LQ4CZHfg0TZMfEYvtNk29d=WKXY7gXOsKFDipkQ@mail.gmail.com>
 <CAH6Pt5q3NqBy3ge0k3bE14TaYH1B_DkGMw1kytufaKtB48Ww-Q@mail.gmail.com>
Message-ID: <CAB2ovouFEmqiHubGaVjXrdHnNfXZ-fdW7mk237KzSHEqLiJfRA@mail.gmail.com>

Pardon my ignorance, but what is the relationship between the proposed
extension to the NIfTI and proposed data storage/metadata standards
like BIDS?

I am not intimately familiar with the BIDS format, but that specifies
metadata in files external to the images.  Is the intent of the JSON
extension to the NIfTI format going to replace, supplement, or
replicate information that might be stored elsewhere?




On Fri, Jun 30, 2017 at 3:57 PM, Matthew Brett <matthew.brett at gmail.com> wrote:
> Hi,
>
> On Fri, Jun 30, 2017 at 5:35 PM, Jasper van den Bosch <japsai at gmail.com> 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?
>
>> I did a little survey among niprov users and it turns out they usually don't
>> end up using the header to store the metadata, because the "central" storage
>> can more easily keep track of the relationships between files.
>> And if the file is overwritten, or moved, the metadata remains.
>
> I think the DICOM / NIfTI thing is partly cultural.  If you're a C++ /
> cluster sort of person, you tend to prefer DICOM, because there are
> C(++) libraries to read the DICOMs, and setting up the libraries /
> compiling isn't much of an issue, because everything you need can
> easily be set up on the cluster.  If you're a Python / laptop sort of
> person, then you tend to prefer NIfTI because it's such a simple
> format that it's easy to write your own code to manipulate it, and the
> code remains fairly readable, and no extra setup is needed other than
> a `pip install pydicom`.
>
> The JSON header extension is also an extremely obvious idea, that we
> need to store just a little bit more metadata than we have now.  So -
> why not store a lot more metadata than we have now?
>
> Cheers,
>
> Matthew
> _______________________________________________
> Neuroimaging mailing list
> Neuroimaging at python.org
> https://mail.python.org/mailman/listinfo/neuroimaging

From krzysztof.gorgolewski at gmail.com  Fri Jun 30 19:23:12 2017
From: krzysztof.gorgolewski at gmail.com (Chris Gorgolewski)
Date: Fri, 30 Jun 2017 16:23:12 -0700
Subject: [Neuroimaging] JSON-LD and DICOM?
In-Reply-To: <CAB2ovouFEmqiHubGaVjXrdHnNfXZ-fdW7mk237KzSHEqLiJfRA@mail.gmail.com>
References: <CAH6Pt5qs81BKff=Kq7rfBfpLd1UUYO8gnMgDm2FL8BcXjB4D+A@mail.gmail.com>
 <CA+A4wOne9it5D4DC5jR3xF6suRabpY1fYhedGqdejX0Mf1+L_Q@mail.gmail.com>
 <CAMw6MkdDD=X=ynvSW-=2h-4oXLGXYAE0TrMBr02Ua9Ez_XQNSw@mail.gmail.com>
 <CAH6Pt5pawt1f93=+SZkEXp0g4KQdTfO832r3QBY5PKo1PbcAMw@mail.gmail.com>
 <CAMw6MkeRmvOowmELzBO0=AxzxHoXnYj41j0DicXdTMS+=EuL9Q@mail.gmail.com>
 <CAH6Pt5qpLOSJUd9nUJWYMVOgzYKQU5cWW8vxLgu60pmQsrU-ow@mail.gmail.com>
 <CAMw6Mke3BpiFF-nST1xXCYA7m-=4d06negViQe02M-PjZK=d2Q@mail.gmail.com>
 <CAGjxhso0tD7LQ4CZHfg0TZMfEYvtNk29d=WKXY7gXOsKFDipkQ@mail.gmail.com>
 <CAH6Pt5q3NqBy3ge0k3bE14TaYH1B_DkGMw1kytufaKtB48Ww-Q@mail.gmail.com>
 <CAB2ovouFEmqiHubGaVjXrdHnNfXZ-fdW7mk237KzSHEqLiJfRA@mail.gmail.com>
Message-ID: <CAAQzouOgpphmo2-R0Vz8So0FdxQRs_Jb9cjkDmjiVUVBAM6GNQ@mail.gmail.com>

Hi,

I don't think that nibabel should impose any schema on the JSON data stored
in the header extension, but for what it's worth most fields in BIDS JSON
sidecars have one to one correspondence to DICOM tags (and even use the
same names). There are some exceptions - for example SliceTiming or
PhaseEncodingDirection.

There are some ongoing conversation about dropping the sidecar JSON files
in BIDS 2.0 and storing all metadata in a header of the binary image file
(which could be NIFTI, DICOM, MINC... time will tell!)

Best,
Chris

On Fri, Jun 30, 2017 at 1:07 PM, Bennet Fauber <bennet at umich.edu> wrote:

> Pardon my ignorance, but what is the relationship between the proposed
> extension to the NIfTI and proposed data storage/metadata standards
> like BIDS?
>
> I am not intimately familiar with the BIDS format, but that specifies
> metadata in files external to the images.  Is the intent of the JSON
> extension to the NIfTI format going to replace, supplement, or
> replicate information that might be stored elsewhere?
>
>
>
>
> On Fri, Jun 30, 2017 at 3:57 PM, Matthew Brett <matthew.brett at gmail.com>
> wrote:
> > Hi,
> >
> > On Fri, Jun 30, 2017 at 5:35 PM, Jasper van den Bosch <japsai at gmail.com>
> 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?
> >
> >> I did a little survey among niprov users and it turns out they usually
> don't
> >> end up using the header to store the metadata, because the "central"
> storage
> >> can more easily keep track of the relationships between files.
> >> And if the file is overwritten, or moved, the metadata remains.
> >
> > I think the DICOM / NIfTI thing is partly cultural.  If you're a C++ /
> > cluster sort of person, you tend to prefer DICOM, because there are
> > C(++) libraries to read the DICOMs, and setting up the libraries /
> > compiling isn't much of an issue, because everything you need can
> > easily be set up on the cluster.  If you're a Python / laptop sort of
> > person, then you tend to prefer NIfTI because it's such a simple
> > format that it's easy to write your own code to manipulate it, and the
> > code remains fairly readable, and no extra setup is needed other than
> > a `pip install pydicom`.
> >
> > The JSON header extension is also an extremely obvious idea, that we
> > need to store just a little bit more metadata than we have now.  So -
> > why not store a lot more metadata than we have now?
> >
> > 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: <http://mail.python.org/pipermail/neuroimaging/attachments/20170630/716fa9e1/attachment.html>