From jrudascas at gmail.com  Wed Jul  1 01:22:03 2015
From: jrudascas at gmail.com (Jorge Rudas)
Date: Tue, 30 Jun 2015 18:22:03 -0500
Subject: [Neuroimaging] Dipy - Problem creating the fiber trackting of
	my data
Message-ID: <CAOXSzBBCfBY-O57UGf_ZHKkYHtXBBeKvt1nb9x6B42kryCCrHg@mail.gmail.com>

Hi again,

I thought it would be more useful to give you more information about what
we are trying to do:

   - We have information of multiples subjects from 1.5T GE Health
   Care resonator and 24 diffusion directions.

   - This data have been converted from DICOM to .nii 4D by using dcm2nii
   (the .bvec and .bval are generated automatically during the conversion).

   - When in doubt of the quality of conversion, we reconstruct the model
   tensor and tractography of the data after conversion, with MedINRIA and
   tractography produced is very good.

   - With DIPY, we basically tried to replicate the example *Deterministic
   tracking with EuDX on Tensor Fields *(
   http://nipy.org/dipy/examples_built/tracking_eudx_tensor.html#example-tracking-eudx-tensor)
   using our data.

   - For that purpose, we have only made a task of preprocessing
   (segmentation of the brain using median_otsu of DIPY). We have no other
   activity preprocessing.

   - The rest of the implementation is exactly like the example.

Regard





Dear Dipy Team
>>
>
>
>> I have data from GE Medical Systems resonator, with 24 directions and
>> only axial view.
>>
>> I using the examples for your documentation, specificaly
>> http://nipy.org/dipy/examples_built/tracking_eudx_tensor.html#example-tracking-eudx-tensor
>> .
>>
>> But, i get the fiber tracking bad. The data was convert using dcm2nii
>> from DICOMs.
>>
>> Below, you find two link at my images of fiber tracking.
>>
>> https://www.dropbox.com/s/lc3wmv2yb1nz7uf/image%20%281%29.png?dl=0
>>
>
>
>> https://www.dropbox.com/s/gaguehp73qqgo0h/image%20%282%29.png?dl=0
>>
>
>
>>
>> Any suggestions to improve the fiber tracking with my data?
>>
>> *Jorge Rudas*
>> *National University of Colombia*
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150630/b95ab3ca/attachment.html>

From garyfallidis at gmail.com  Wed Jul  1 01:43:15 2015
From: garyfallidis at gmail.com (Eleftherios Garyfallidis)
Date: Tue, 30 Jun 2015 19:43:15 -0400
Subject: [Neuroimaging] Dipy - Problem creating the fiber trackting of
	my data
In-Reply-To: <CAOXSzBBCfBY-O57UGf_ZHKkYHtXBBeKvt1nb9x6B42kryCCrHg@mail.gmail.com>
References: <CAOXSzBBCfBY-O57UGf_ZHKkYHtXBBeKvt1nb9x6B42kryCCrHg@mail.gmail.com>
Message-ID: <CAN6JmWM9hJKNG9VZ6i7q7DB+vrz1MLcwXvVqiUQ3rJSf_Wn_zg@mail.gmail.com>

Hi Jorge,

I am not sure what is the problem.

Do you calculate the tensors (fa, evecs) with Dipy too? Or loading them
from somewhere else?
I would suggest to do all the processing with Dipy if you can.

In the meantime can you share one of your datasets ? So, I can have a look ?

Best regards,
Eleftherios


On Tue, Jun 30, 2015 at 7:22 PM, Jorge Rudas <jrudascas at gmail.com> wrote:

> Hi again,
>
> I thought it would be more useful to give you more information about what
> we are trying to do:
>
>    - We have information of multiples subjects from 1.5T GE Health
>    Care resonator and 24 diffusion directions.
>
>    - This data have been converted from DICOM to .nii 4D by using dcm2nii
>    (the .bvec and .bval are generated automatically during the conversion).
>
>    - When in doubt of the quality of conversion, we reconstruct the model
>    tensor and tractography of the data after conversion, with MedINRIA and
>    tractography produced is very good.
>
>    - With DIPY, we basically tried to replicate the example *Deterministic
>    tracking with EuDX on Tensor Fields *(
>    http://nipy.org/dipy/examples_built/tracking_eudx_tensor.html#example-tracking-eudx-tensor)
>    using our data.
>
>    - For that purpose, we have only made a task of preprocessing
>    (segmentation of the brain using median_otsu of DIPY). We have no other
>    activity preprocessing.
>
>    - The rest of the implementation is exactly like the example.
>
> Regard
>
>
>
>
>
> Dear Dipy Team
>>>
>>
>>
>>> I have data from GE Medical Systems resonator, with 24 directions and
>>> only axial view.
>>>
>>> I using the examples for your documentation, specificaly
>>> http://nipy.org/dipy/examples_built/tracking_eudx_tensor.html#example-tracking-eudx-tensor
>>> .
>>>
>>> But, i get the fiber tracking bad. The data was convert using dcm2nii
>>> from DICOMs.
>>>
>>> Below, you find two link at my images of fiber tracking.
>>>
>>> https://www.dropbox.com/s/lc3wmv2yb1nz7uf/image%20%281%29.png?dl=0
>>>
>>
>>
>>> https://www.dropbox.com/s/gaguehp73qqgo0h/image%20%282%29.png?dl=0
>>>
>>
>>
>>>
>>> Any suggestions to improve the fiber tracking with my data?
>>>
>>> *Jorge Rudas*
>>> *National University of Colombia*
>>>
>>>
>>
>
> _______________________________________________
> 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/20150630/ab8866cf/attachment.html>

From jrudascas at gmail.com  Wed Jul  1 04:56:07 2015
From: jrudascas at gmail.com (Jorge Rudas)
Date: Tue, 30 Jun 2015 21:56:07 -0500
Subject: [Neuroimaging] Dipy - Problem creating the fiber trackting of
	my data
Message-ID: <CAOXSzBBs0aXJtHHGRuroLqe7M7hKKwCvpMzEo-1dyY0B7pB8nQ@mail.gmail.com>

Hi Eleftherios, thanks you for your answer.

I share you the raw data in this link:

https://www.dropbox.com/s/good87rel35ay8n/dicom.tar?dl=0

And, in this link you get the dicoms converted to nii 4D with dcm2nii:

https://www.dropbox.com/sh/acikf8r7j86ljnk/AACE5oYf9htbKLr370OcStTLa?dl=0

Additionally, attached to mail you can find the my implementation

Best regards,

*Jorge Rudas*





2015-06-30 18:43 GMT-05:00 Eleftherios Garyfallidis <garyfallidis at gmail.com>
:

> Hi Jorge,
>
> I am not sure what is the problem.
>
> Do you calculate the tensors (fa, evecs) with Dipy too? Or loading them
> from somewhere else?
> I would suggest to do all the processing with Dipy if you can.
>
> In the meantime can you share one of your datasets ? So, I can have a look
> ?
>
> Best regards,
> Eleftherios
>
>
> On Tue, Jun 30, 2015 at 7:22 PM, Jorge Rudas <jrudascas at gmail.com> wrote:
>
>> Hi again,
>>
>> I thought it would be more useful to give you more information about what
>> we are trying to do:
>>
>>    - We have information of multiples subjects from 1.5T GE Health
>>    Care resonator and 24 diffusion directions.
>>
>>    - This data have been converted from DICOM to .nii 4D by using
>>    dcm2nii (the .bvec and .bval are generated automatically during the
>>    conversion).
>>
>>    - When in doubt of the quality of conversion, we reconstruct the
>>    model tensor and tractography of the data after conversion, with MedINRIA
>>    and tractography produced is very good.
>>
>>    - With DIPY, we basically tried to replicate the example *Deterministic
>>    tracking with EuDX on Tensor Fields *(
>>    http://nipy.org/dipy/examples_built/tracking_eudx_tensor.html#example-tracking-eudx-tensor)
>>    using our data.
>>
>>    - For that purpose, we have only made a task of preprocessing
>>    (segmentation of the brain using median_otsu of DIPY). We have no other
>>    activity preprocessing.
>>
>>    - The rest of the implementation is exactly like the example.
>>
>> Regard
>>
>>
>>
>>
>>
>> Dear Dipy Team
>>>>
>>>
>>>
>>>> I have data from GE Medical Systems resonator, with 24 directions and
>>>> only axial view.
>>>>
>>>> I using the examples for your documentation, specificaly
>>>> http://nipy.org/dipy/examples_built/tracking_eudx_tensor.html#example-tracking-eudx-tensor
>>>> .
>>>>
>>>> But, i get the fiber tracking bad. The data was convert using dcm2nii
>>>> from DICOMs.
>>>>
>>>> Below, you find two link at my images of fiber tracking.
>>>>
>>>> https://www.dropbox.com/s/lc3wmv2yb1nz7uf/image%20%281%29.png?dl=0
>>>>
>>>
>>>
>>>> https://www.dropbox.com/s/gaguehp73qqgo0h/image%20%282%29.png?dl=0
>>>>
>>>
>>>
>>>>
>>>> Any suggestions to improve the fiber tracking with my data?
>>>>
>>>> *Jorge Rudas*
>>>> *National University of Colombia*
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> 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/20150630/aa1b313e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: EuDXTensorField.py
Type: text/x-python
Size: 3125 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150630/aa1b313e/attachment-0001.py>

From garyfallidis at gmail.com  Fri Jul  3 17:17:21 2015
From: garyfallidis at gmail.com (Eleftherios Garyfallidis)
Date: Fri, 3 Jul 2015 11:17:21 -0400
Subject: [Neuroimaging] Dipy - Problem creating the fiber trackting of
	my data
In-Reply-To: <CAOXSzBBs0aXJtHHGRuroLqe7M7hKKwCvpMzEo-1dyY0B7pB8nQ@mail.gmail.com>
References: <CAOXSzBBs0aXJtHHGRuroLqe7M7hKKwCvpMzEo-1dyY0B7pB8nQ@mail.gmail.com>
Message-ID: <CAN6JmWPQ+zc=Y_ZskYu-U87HLRLBkA9oDKMTevCGs3CaqnMHhA@mail.gmail.com>

Hi Jorge,

Found the problem! :)

The problem you had was that your datasets did not have isotropic voxel
size. Your voxel size was (0.9375, 0.9375, 5.0).
Tracking is not recommended when you have such difference in the voxel
sizes across the different slices. That is why
we don't support tracking in EuDX from non-isotropic voxel sizes.

But anyway you can still use these datasets if you use the reslice function
from Dipy. Then you can  reslice your datasets
to have isotropic size. I went to (2.0, 2.0, 2.0) for example.

Have a look in your updated script in the attachment.

Happy hacking!

Best regards,
Eleftherios


On Tue, Jun 30, 2015 at 10:56 PM, Jorge Rudas <jrudascas at gmail.com> wrote:

> Hi Eleftherios, thanks you for your answer.
>
> I share you the raw data in this link:
>
> https://www.dropbox.com/s/good87rel35ay8n/dicom.tar?dl=0
>
> And, in this link you get the dicoms converted to nii 4D with dcm2nii:
>
> https://www.dropbox.com/sh/acikf8r7j86ljnk/AACE5oYf9htbKLr370OcStTLa?dl=0
>
> Additionally, attached to mail you can find the my implementation
>
> Best regards,
>
> *Jorge Rudas*
>
>
>
>
>
> 2015-06-30 18:43 GMT-05:00 Eleftherios Garyfallidis <
> garyfallidis at gmail.com>:
>
>> Hi Jorge,
>>
>> I am not sure what is the problem.
>>
>> Do you calculate the tensors (fa, evecs) with Dipy too? Or loading them
>> from somewhere else?
>> I would suggest to do all the processing with Dipy if you can.
>>
>> In the meantime can you share one of your datasets ? So, I can have a
>> look ?
>>
>> Best regards,
>> Eleftherios
>>
>>
>> On Tue, Jun 30, 2015 at 7:22 PM, Jorge Rudas <jrudascas at gmail.com> wrote:
>>
>>> Hi again,
>>>
>>> I thought it would be more useful to give you more information about
>>> what we are trying to do:
>>>
>>>    - We have information of multiples subjects from 1.5T GE Health
>>>    Care resonator and 24 diffusion directions.
>>>
>>>    - This data have been converted from DICOM to .nii 4D by using
>>>    dcm2nii (the .bvec and .bval are generated automatically during the
>>>    conversion).
>>>
>>>    - When in doubt of the quality of conversion, we reconstruct the
>>>    model tensor and tractography of the data after conversion, with MedINRIA
>>>    and tractography produced is very good.
>>>
>>>    - With DIPY, we basically tried to replicate the example *Deterministic
>>>    tracking with EuDX on Tensor Fields *(
>>>    http://nipy.org/dipy/examples_built/tracking_eudx_tensor.html#example-tracking-eudx-tensor)
>>>    using our data.
>>>
>>>    - For that purpose, we have only made a task of preprocessing
>>>    (segmentation of the brain using median_otsu of DIPY). We have no other
>>>    activity preprocessing.
>>>
>>>    - The rest of the implementation is exactly like the example.
>>>
>>> Regard
>>>
>>>
>>>
>>>
>>>
>>> Dear Dipy Team
>>>>>
>>>>
>>>>
>>>>> I have data from GE Medical Systems resonator, with 24 directions and
>>>>> only axial view.
>>>>>
>>>>> I using the examples for your documentation, specificaly
>>>>> http://nipy.org/dipy/examples_built/tracking_eudx_tensor.html#example-tracking-eudx-tensor
>>>>> .
>>>>>
>>>>> But, i get the fiber tracking bad. The data was convert using dcm2nii
>>>>> from DICOMs.
>>>>>
>>>>> Below, you find two link at my images of fiber tracking.
>>>>>
>>>>> https://www.dropbox.com/s/lc3wmv2yb1nz7uf/image%20%281%29.png?dl=0
>>>>>
>>>>
>>>>
>>>>> https://www.dropbox.com/s/gaguehp73qqgo0h/image%20%282%29.png?dl=0
>>>>>
>>>>
>>>>
>>>>>
>>>>> Any suggestions to improve the fiber tracking with my data?
>>>>>
>>>>> *Jorge Rudas*
>>>>> *National University of Colombia*
>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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/20150703/ea529c7e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: EuDXTensorField.py
Type: text/x-python
Size: 3661 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150703/ea529c7e/attachment.py>

From matthew.brett at gmail.com  Sun Jul  5 00:59:07 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Sat, 4 Jul 2015 23:59:07 +0100
Subject: [Neuroimaging] [Nipy-devel] reading embedded PAR header in nii
In-Reply-To: <CAH6Pt5oEBASCm8obeoNFgTghejkpMZR-S=gBzjfJpc_UTs_7Hg@mail.gmail.com>
References: <4B4F5D26-D783-47C8-A6CC-1BA07677C721@uw.edu>
 <CAH6Pt5oEBASCm8obeoNFgTghejkpMZR-S=gBzjfJpc_UTs_7Hg@mail.gmail.com>
Message-ID: <CAH6Pt5rRiewKiQMO8z043hJ-12V8TLLp6eUgzasHqvyAoPbyTA@mail.gmail.com>

Hi,

On Tue, May 26, 2015 at 6:03 PM, Matthew Brett <matthew.brett at gmail.com> wrote:
> Hi,
>
> On Tue, May 19, 2015 at 4:18 PM, Jeff Stevenson <mrjeffs at uw.edu> wrote:
>> hi matthew, i was fooling around with embedding the PAR header into nii files converted with parrec2nii using the --store-header flag in nibabel. later on we would need to retrieve that data from the extended
>> portion of the header in a structured way to get params not currently stored in the std nii header like flip angle etc.
>>
>
> At the moment, the `store-header` option dumps the PAR header into the
> Nifti as a nifti 'comment' extension.  I believe we can just
> reconstruct the header from this info, to generate a PARRECHeader
> object that can be queried for stuff.
>
> I suppose we have two options:
>
> * Do something to automatically recognize the PAR header as a comment,
> and convert to something specific for PAR, when we load the nifti
> image with the PAR header in the extension.
> * Have our own specific nifti header extension, with its own code, to
> contain the PAR information (in the same format).
>
> Either way we need a new NiftiExtension type to deal with the PAR
> header, but that should be pretty easy...

Following up on this one - I thought of another way, which is just to
make a helper function that collects PAR headers from the nifti image
header extensions, and creates PARHeader objects from them:

https://github.com/nipy/nibabel/pull/322

Any chance you could look over that PR to see if it would help?

Cheers,

Matthew

From carolyn.parkinson at gmail.com  Sun Jul  5 06:04:04 2015
From: carolyn.parkinson at gmail.com (Carolyn Parkinson)
Date: Sun, 5 Jul 2015 00:04:04 -0400
Subject: [Neuroimaging] [PySurfer] When displaying ROI values on the surface,
 undefined regions are assigned values corresponding to another ROI
Message-ID: <CAOhRLuC1D7fz-YXGr_MZ_CC8jUCe2QiSPPk+9QgFLZwzSRiC-Q@mail.gmail.com>

Hello,

I hope this is the right place for this question! The PySurfer site directs
questions to the NiPy mailing list, which this list appears to have
replaced.

I'm using PySurfer to display results from an analysis performed within
each region of Freesurfer's Desikan-Killiany atlas on the surface.

However, I've noticed that whatever value is assigned to the ROI
'caudalmiddlefrontal' in my results also appears to get mapped to the
undefined regions of the surface model in the medial view. I've included
some code below to show what I mean.

Is there anything that I should be doing differently in order to avoid this?

Thanks very much,
Carolyn


import os
import numpy as np
import nibabel as nib
from surfer import Brain

# Set parameters
subject_id = "fsaverage"
hemi = "lh"

# Read in the Desikan-Killiany atlas annotation
aparc_file = os.path.join(os.environ["SUBJECTS_DIR"], subject_id, "label",
hemi + ".aparc.annot")
labels, ctab, names = nib.freesurfer.read_annot(aparc_file)

# Make a list of values to display in each ROI
# All ROIs but 'caudalmiddlefrontal' are assigned 0
roi_data_list = []
for roi in names:
    if roi == 'caudalmiddlefrontal':
        roi_data_list.append(1)
    else:
        roi_data_list.append(0)
roi_data = np.array(roi_data_list)

# Make a vector of values corresponding to each vertex
vtx_data = roi_data[labels]

# Bring up the visualization
brain = Brain(subject_id, hemi, "inflated", config_opts = dict(background =
"white", cortex = 'bone'))
brain.add_data(vtx_data, -1, 1,colormap = "coolwarm", alpha = .75)
brain.add_annotation('aparc', borders = 4)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150705/4bac067e/attachment.html>

From rlaplant at nmr.mgh.harvard.edu  Sun Jul  5 14:48:07 2015
From: rlaplant at nmr.mgh.harvard.edu (Roan LaPlante)
Date: Sun, 5 Jul 2015 08:48:07 -0400
Subject: [Neuroimaging] [PySurfer] When displaying ROI values on the
 surface, undefined regions are assigned values corresponding to another ROI
In-Reply-To: <CAOhRLuC1D7fz-YXGr_MZ_CC8jUCe2QiSPPk+9QgFLZwzSRiC-Q@mail.gmail.com>
References: <CAOhRLuC1D7fz-YXGr_MZ_CC8jUCe2QiSPPk+9QgFLZwzSRiC-Q@mail.gmail.com>
Message-ID: <CANXJ4aqVt7YRQv8hDnjyBxm4LFCf7XxGESxb3m-kF46OoCG8KA@mail.gmail.com>

Hi Carolyn,

I ran your example code but was not able to reproduce the behavior you
describe. Only the frontal region is colored in the output and not the
medial wall. What version of pysurfer are you using?

best,

On Sun, Jul 5, 2015 at 12:04 AM, Carolyn Parkinson <
carolyn.parkinson at gmail.com> wrote:

> Hello,
>
> I hope this is the right place for this question! The PySurfer site
> directs questions to the NiPy mailing list, which this list appears to have
> replaced.
>
> I'm using PySurfer to display results from an analysis performed within
> each region of Freesurfer's Desikan-Killiany atlas on the surface.
>
> However, I've noticed that whatever value is assigned to the ROI
> 'caudalmiddlefrontal' in my results also appears to get mapped to the
> undefined regions of the surface model in the medial view. I've included
> some code below to show what I mean.
>
> Is there anything that I should be doing differently in order to avoid
> this?
>
> Thanks very much,
> Carolyn
>
>
> import os
> import numpy as np
> import nibabel as nib
> from surfer import Brain
>
> # Set parameters
> subject_id = "fsaverage"
> hemi = "lh"
>
> # Read in the Desikan-Killiany atlas annotation
> aparc_file = os.path.join(os.environ["SUBJECTS_DIR"], subject_id, "label",
> hemi + ".aparc.annot")
> labels, ctab, names = nib.freesurfer.read_annot(aparc_file)
>
> # Make a list of values to display in each ROI
> # All ROIs but 'caudalmiddlefrontal' are assigned 0
> roi_data_list = []
> for roi in names:
>     if roi == 'caudalmiddlefrontal':
>         roi_data_list.append(1)
>     else:
>         roi_data_list.append(0)
> roi_data = np.array(roi_data_list)
>
> # Make a vector of values corresponding to each vertex
> vtx_data = roi_data[labels]
>
> # Bring up the visualization
> brain = Brain(subject_id, hemi, "inflated", config_opts = dict(background
> = "white", cortex = 'bone'))
> brain.add_data(vtx_data, -1, 1,colormap = "coolwarm", alpha = .75)
> brain.add_annotation('aparc', borders = 4)
>
> _______________________________________________
> Neuroimaging mailing list
> Neuroimaging at python.org
> https://mail.python.org/mailman/listinfo/neuroimaging
>
>
> 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.
>
>


-- 
Roan LaPlante
Athinoula A. Martinos Center for Biomedical Imaging
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150705/f848bbdf/attachment.html>

From mwaskom at stanford.edu  Sun Jul  5 17:17:20 2015
From: mwaskom at stanford.edu (Michael Waskom)
Date: Sun, 5 Jul 2015 08:17:20 -0700
Subject: [Neuroimaging] [PySurfer] When displaying ROI values on the
 surface, undefined regions are assigned values corresponding to another ROI
In-Reply-To: <CAOhRLuC1D7fz-YXGr_MZ_CC8jUCe2QiSPPk+9QgFLZwzSRiC-Q@mail.gmail.com>
References: <CAOhRLuC1D7fz-YXGr_MZ_CC8jUCe2QiSPPk+9QgFLZwzSRiC-Q@mail.gmail.com>
Message-ID: <CAKZ-Uq3FFAhQ7nuqqDqiBvQLPidAs8MRVpxCP0YPy-9DBTGChg@mail.gmail.com>

Hi Carolyn,

Like Roan I couldn't reproduce your issue. However, from what you
described, it sounds like what happens when the left hemisphere version of
a map is plotted on the right hemisphere, or vice versa. Maybe an earlier
version of the code had hemisphere hard-coded somewhere?

For what it's worth, you could trim down the middle portion of your script
to:

vtx_data = labels == names.index("caudalmiddlefrontal")

which might streamline the code and make it easier to debug.
HTH,
Michael

On Sat, Jul 4, 2015 at 9:04 PM, Carolyn Parkinson <
carolyn.parkinson at gmail.com> wrote:

> Hello,
>
> I hope this is the right place for this question! The PySurfer site
> directs questions to the NiPy mailing list, which this list appears to have
> replaced.
>
> I'm using PySurfer to display results from an analysis performed within
> each region of Freesurfer's Desikan-Killiany atlas on the surface.
>
> However, I've noticed that whatever value is assigned to the ROI
> 'caudalmiddlefrontal' in my results also appears to get mapped to the
> undefined regions of the surface model in the medial view. I've included
> some code below to show what I mean.
>
> Is there anything that I should be doing differently in order to avoid
> this?
>
> Thanks very much,
> Carolyn
>
>
> import os
> import numpy as np
> import nibabel as nib
> from surfer import Brain
>
> # Set parameters
> subject_id = "fsaverage"
> hemi = "lh"
>
> # Read in the Desikan-Killiany atlas annotation
> aparc_file = os.path.join(os.environ["SUBJECTS_DIR"], subject_id, "label",
> hemi + ".aparc.annot")
> labels, ctab, names = nib.freesurfer.read_annot(aparc_file)
>
> # Make a list of values to display in each ROI
> # All ROIs but 'caudalmiddlefrontal' are assigned 0
> roi_data_list = []
> for roi in names:
>     if roi == 'caudalmiddlefrontal':
>         roi_data_list.append(1)
>     else:
>         roi_data_list.append(0)
> roi_data = np.array(roi_data_list)
>
> # Make a vector of values corresponding to each vertex
> vtx_data = roi_data[labels]
>
> # Bring up the visualization
> brain = Brain(subject_id, hemi, "inflated", config_opts = dict(background
> = "white", cortex = 'bone'))
> brain.add_data(vtx_data, -1, 1,colormap = "coolwarm", alpha = .75)
> brain.add_annotation('aparc', borders = 4)
>
> _______________________________________________
> 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/20150705/b8dd4a57/attachment.html>

From carolyn.parkinson at gmail.com  Sun Jul  5 23:02:55 2015
From: carolyn.parkinson at gmail.com (Carolyn Parkinson)
Date: Sun, 5 Jul 2015 17:02:55 -0400
Subject: [Neuroimaging] [PySurfer] When displaying ROI values on the
 surface, undefined regions are assigned values corresponding to another ROI
Message-ID: <CAOhRLuDfeM5LnhRC2_K7Q0a11ThtTcNUhw5_J_8mvLXPtC8Ysw@mail.gmail.com>

Thank you both very much for your help and quick responses.

I haven't hard-coded the hemisphere elsewhere in the code and am using
version 0.5 of PySurfer on a Linux server running CentOS 6.6.

I've uploaded an html version of an ipython notebook with a very stripped
down version of my code and embedded images of the medial and lateral views
that result to show you what I mean and in case there is anything obviously
wrong with my code: http://dbic.dartmouth.edu/~carolyn/test.html

Do you have any thoughts on what might be causing this issue?

Thank you again for your help and I'm sorry if I'm missing something
obvious!

Carolyn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150705/38c783e4/attachment.html>

From mwaskom at stanford.edu  Sun Jul  5 23:59:51 2015
From: mwaskom at stanford.edu (Michael Waskom)
Date: Sun, 5 Jul 2015 14:59:51 -0700
Subject: [Neuroimaging] [PySurfer] When displaying ROI values on the
 surface, undefined regions are assigned values corresponding to another ROI
In-Reply-To: <CAKZ-Uq2b3NVmgHmQwbuOkz+hkFJZ=ji1mPkhZvE7aH0ZmQ8=xg@mail.gmail.com>
References: <CAOhRLuDfeM5LnhRC2_K7Q0a11ThtTcNUhw5_J_8mvLXPtC8Ysw@mail.gmail.com>
 <CAKZ-Uq2b3NVmgHmQwbuOkz+hkFJZ=ji1mPkhZvE7aH0ZmQ8=xg@mail.gmail.com>
Message-ID: <CAKZ-Uq1dNqC+iLJLrAyUmmMBK9LRvR8D6eNyAno6hC2cvTi7Lg@mail.gmail.com>

Oh might also check the nibabel version...this commit looks like it might
be relevant:
https://github.com/nipy/nibabel/commit/13b17afcff255adc2990c4fc24b8b7094fce4250
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150705/bbdcbdbc/attachment-0001.html>

From mwaskom at stanford.edu  Sun Jul  5 23:57:32 2015
From: mwaskom at stanford.edu (Michael Waskom)
Date: Sun, 5 Jul 2015 14:57:32 -0700
Subject: [Neuroimaging] [PySurfer] When displaying ROI values on the
 surface, undefined regions are assigned values corresponding to another ROI
In-Reply-To: <CAOhRLuDfeM5LnhRC2_K7Q0a11ThtTcNUhw5_J_8mvLXPtC8Ysw@mail.gmail.com>
References: <CAOhRLuDfeM5LnhRC2_K7Q0a11ThtTcNUhw5_J_8mvLXPtC8Ysw@mail.gmail.com>
Message-ID: <CAKZ-Uq2b3NVmgHmQwbuOkz+hkFJZ=ji1mPkhZvE7aH0ZmQ8=xg@mail.gmail.com>

Hmm, still not seeing the issue on my end.

Perhaps you're using an older version of Freesurfer that has a weirdly
formatted aparc file for fsaverage?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150705/76804c89/attachment.html>

From carolyn.parkinson at gmail.com  Mon Jul  6 00:21:31 2015
From: carolyn.parkinson at gmail.com (Carolyn Parkinson)
Date: Sun, 5 Jul 2015 18:21:31 -0400
Subject: [Neuroimaging] [PySurfer] When displaying ROI values on the surface,
 undefined regions are assigned values corresponding to another ROI
Message-ID: <CAOhRLuBP7q+zZMjZu3U5cDRQWpTGLqi5Jq3DM-vAddosEDGAcw@mail.gmail.com>

That must have been it - updating nibabel fixed the issue.

Thanks so much for your help!

Carolyn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150705/06297ed2/attachment.html>

From matthew.brett at gmail.com  Mon Jul  6 17:32:00 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Mon, 6 Jul 2015 16:32:00 +0100
Subject: [Neuroimaging] Nibabel API change - always read as float
Message-ID: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>

Hi,

I wanted to ask y'all about an API change that I want to make to nibabel.

In summary, I want to default to returning floating point arrays from
nibabel images.

Problem - different returned data types from img.get_data()
-------------------------------------------------------------------------------

At the moment, if you do this:

img = nib.load('my_image.nii')
data = img.get_data()

Then the data type (dtype) of the returned data array depends on the
values in the header of `my_image.nii`.   Specifically, if the raw
on-disk data type is 'np.int16' (it is often is) and the header
scalefactor values are default (1 for slope, 0 for intercept) then you
will get back an array of the on disk data type - here - np.int16.

This is very efficient on memory, but it it's a real trap unless you careful.

For example, let's say you had a pipeline where you did this:

sum = img.get_data().sum()

That would work fine most of the time, when the data on disk is
floating point, or the scalefactors are not default (1, 0).   Then one
day, you get an image with int16 data type on disk and 1, 0
scalefactors, and your `sum` calculation silently overflows.    I ran
into this when teaching - I had to cast some image arrays to floating
point to get sensible answers.

Solution
-----------

I think that the default behavior of nibabel should be to do the thing
least likely to trip you up by accident, so - I think in due course,
nibabel should always return a floating point array from `get_data()`
by default.

I propose to add a keyword-only argument to `get_data()` - `to_float`, as in:

data = img.get_data(to_float=False)  # The current default behavior
data = img.get_data(to_float=True)  # Integer arrays automatically
cast to float64

For this cycle (the nibabel 2.0 series), I propose to raise a warning
if you don't pass in an explicit True or False, warning that the
default behavior for nibabel 3.0 will change from `to_float=False` to
`to_float=True`.

The other, more fancy ways of getting the image data would continue as
they are, such as:

data = np.array(img.dataobj)
data = img.dataobj[:]

These will both return ints or floats depending on the raw data dtype
and the scalefactors.  This is on the basis that people using these
will be more advanced and so therefore more likely to want memory
efficiency at the expense of having to be careful about the returned
data dtype.

Does this seem reasonable to y'all?    Thoughts, suggestions?

Cheers,

Matthew

From blaise.frederick at gmail.com  Mon Jul  6 17:46:54 2015
From: blaise.frederick at gmail.com (Blaise Frederick)
Date: Mon, 6 Jul 2015 11:46:54 -0400
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
Message-ID: <64EE1BDA-D6C5-49C7-A9A5-A4B4F6B16A05@gmail.com>

That seems reasonable.  It might also add clarity to define:

img.get_native_data()

which was just an alias of

img.get_data(to_float=False)

That would have the advantage of making it immediately obvious what the code was doing (not that the other way doesn?t).

Blaise

> On Jul 6, 2015, at 11:32 AM, Matthew Brett <matthew.brett at gmail.com> wrote:
> 
> Hi,
> 
> I wanted to ask y'all about an API change that I want to make to nibabel.
> 
> In summary, I want to default to returning floating point arrays from
> nibabel images.
> 
> Problem - different returned data types from img.get_data()
> -------------------------------------------------------------------------------
> 
> At the moment, if you do this:
> 
> img = nib.load('my_image.nii')
> data = img.get_data()
> 
> Then the data type (dtype) of the returned data array depends on the
> values in the header of `my_image.nii`.   Specifically, if the raw
> on-disk data type is 'np.int16' (it is often is) and the header
> scalefactor values are default (1 for slope, 0 for intercept) then you
> will get back an array of the on disk data type - here - np.int16.
> 
> This is very efficient on memory, but it it's a real trap unless you careful.
> 
> For example, let's say you had a pipeline where you did this:
> 
> sum = img.get_data().sum()
> 
> That would work fine most of the time, when the data on disk is
> floating point, or the scalefactors are not default (1, 0).   Then one
> day, you get an image with int16 data type on disk and 1, 0
> scalefactors, and your `sum` calculation silently overflows.    I ran
> into this when teaching - I had to cast some image arrays to floating
> point to get sensible answers.
> 
> Solution
> -----------
> 
> I think that the default behavior of nibabel should be to do the thing
> least likely to trip you up by accident, so - I think in due course,
> nibabel should always return a floating point array from `get_data()`
> by default.
> 
> I propose to add a keyword-only argument to `get_data()` - `to_float`, as in:
> 
> data = img.get_data(to_float=False)  # The current default behavior
> data = img.get_data(to_float=True)  # Integer arrays automatically
> cast to float64
> 
> For this cycle (the nibabel 2.0 series), I propose to raise a warning
> if you don't pass in an explicit True or False, warning that the
> default behavior for nibabel 3.0 will change from `to_float=False` to
> `to_float=True`.
> 
> The other, more fancy ways of getting the image data would continue as
> they are, such as:
> 
> data = np.array(img.dataobj)
> data = img.dataobj[:]
> 
> These will both return ints or floats depending on the raw data dtype
> and the scalefactors.  This is on the basis that people using these
> will be more advanced and so therefore more likely to want memory
> efficiency at the expense of having to be careful about the returned
> data dtype.
> 
> Does this seem reasonable to y'all?    Thoughts, suggestions?
> 
> Cheers,
> 
> Matthew
> _______________________________________________
> Neuroimaging mailing list
> Neuroimaging at python.org
> https://mail.python.org/mailman/listinfo/neuroimaging


From matthew.brett at gmail.com  Mon Jul  6 17:53:03 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Mon, 6 Jul 2015 16:53:03 +0100
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <64EE1BDA-D6C5-49C7-A9A5-A4B4F6B16A05@gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <64EE1BDA-D6C5-49C7-A9A5-A4B4F6B16A05@gmail.com>
Message-ID: <CAH6Pt5ohA2YGArnMHaV9hnYXJPL-pBeQusHCOjeEvRM57WnLRg@mail.gmail.com>

Hi,

On Mon, Jul 6, 2015 at 4:46 PM, Blaise Frederick
<blaise.frederick at gmail.com> wrote:
> That seems reasonable.  It might also add clarity to define:
>
> img.get_native_data()
>
> which was just an alias of
>
> img.get_data(to_float=False)
>
> That would have the advantage of making it immediately obvious what the code was doing (not that the other way doesn?t).

The problem there is that the user might expect `get_native_data()` to
always return the raw data on disk, but in fact it will only return
the raw data on disk if the scalefactors are also default values (1,
0).   You can currently get the raw data on disk with:

data = img.dataobj.get_unscaled()

- but only if `dataobj` is a data object, rather than an array (it is
a data object if you load an image from disk).

Cheers,

Matthew

From lists at onerussian.com  Mon Jul  6 17:55:16 2015
From: lists at onerussian.com (Yaroslav Halchenko)
Date: Mon, 6 Jul 2015 11:55:16 -0400
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
Message-ID: <20150706155516.GA28964@onerussian.com>


On Mon, 06 Jul 2015, Matthew Brett wrote:

> Hi,

> I wanted to ask y'all about an API change that I want to make to nibabel.

> In summary, I want to default to returning floating point arrays from
> nibabel images.

> Problem - different returned data types from img.get_data()
> -------------------------------------------------------------------------------

> At the moment, if you do this:

> img = nib.load('my_image.nii')
> data = img.get_data()

> Then the data type (dtype) of the returned data array depends on the
> values in the header of `my_image.nii`.   Specifically, if the raw
> on-disk data type is 'np.int16' (it is often is) and the header
> scalefactor values are default (1 for slope, 0 for intercept) then you
> will get back an array of the on disk data type - here - np.int16.

> This is very efficient on memory, but it it's a real trap unless you careful.

> For example, let's say you had a pipeline where you did this:

> sum = img.get_data().sum()

> That would work fine most of the time, when the data on disk is
> floating point, or the scalefactors are not default (1, 0).   Then one
> day, you get an image with int16 data type on disk and 1, 0
> scalefactors, and your `sum` calculation silently overflows.    I ran
> into this when teaching - I had to cast some image arrays to floating
> point to get sensible answers.

> Solution
> -----------

> I think that the default behavior of nibabel should be to do the thing
> least likely to trip you up by accident, so - I think in due course,
> nibabel should always return a floating point array from `get_data()`
> by default.

> I propose to add a keyword-only argument to `get_data()` - `to_float`, as in:

> data = img.get_data(to_float=False)  # The current default behavior
> data = img.get_data(to_float=True)  # Integer arrays automatically
> cast to float64

> For this cycle (the nibabel 2.0 series), I propose to raise a warning
> if you don't pass in an explicit True or False, warning that the
> default behavior for nibabel 3.0 will change from `to_float=False` to
> `to_float=True`.

> The other, more fancy ways of getting the image data would continue as
> they are, such as:

> data = np.array(img.dataobj)
> data = img.dataobj[:]

> These will both return ints or floats depending on the raw data dtype
> and the scalefactors.  This is on the basis that people using these
> will be more advanced and so therefore more likely to want memory
> efficiency at the expense of having to be careful about the returned
> data dtype.

> Does this seem reasonable to y'all?    Thoughts, suggestions?

Overall I am all for reducing a possibility for users shotting
themselves in a foot.  But this API change would still conflate two
(related) issues here:  memory mapping and casting.  May be there is a
way to clear it up?  Sorry for not providing an answer but at
least let me share the use case(s):

with to_float=True it would then keep memory mapping float .nii
while int .nii would get casted.  So it would remain somewhat obfuscated
when data gets memmapped and when not.  In our (PyMVPA) case we don't
really care about correct offset/scale in many cases (data gets zscored
anyways per each voxel later on with appropriate casting if necessary).  

Now, even with "explicit" to_float=False I would then get a warning.  I
guess we would just need to switch to your explicit img.dataobj  way to
access the data?

-- 
Yaroslav O. Halchenko, Ph.D.
http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
Research Scientist,            Psychological and Brain Sciences Dept.
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 gael.varoquaux at normalesup.org  Mon Jul  6 17:55:16 2015
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Mon, 06 Jul 2015 17:55:16 +0200
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
Message-ID: <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>

I think that this is a very bad idea. First because it's "magic": changing things behind the back of the user. People will be surprised and it will lead to bugs in their code.? Second because it is a loss of semantics. Something like a mask or a label image is stored as integers for a good reason.

The right solution to the problem is to teach people to use float data when relevant, but not to force this decision in them. 

Ga?l

Sent from my phone. Please forgive brevity and mis spelling



On Jul 6, 2015, 17:33, at 17:33, Matthew Brett <matthew.brett at gmail.com> wrote:
>Hi,
>
>I wanted to ask y'all about an API change that I want to make to
>nibabel.
>
>In summary, I want to default to returning floating point arrays from
>nibabel images.
>
>Problem - different returned data types from img.get_data()
>-------------------------------------------------------------------------------
>
>At the moment, if you do this:
>
>img = nib.load('my_image.nii')
>data = img.get_data()
>
>Then the data type (dtype) of the returned data array depends on the
>values in the header of `my_image.nii`.   Specifically, if the raw
>on-disk data type is 'np.int16' (it is often is) and the header
>scalefactor values are default (1 for slope, 0 for intercept) then you
>will get back an array of the on disk data type - here - np.int16.
>
>This is very efficient on memory, but it it's a real trap unless you
>careful.
>
>For example, let's say you had a pipeline where you did this:
>
>sum = img.get_data().sum()
>
>That would work fine most of the time, when the data on disk is
>floating point, or the scalefactors are not default (1, 0).   Then one
>day, you get an image with int16 data type on disk and 1, 0
>scalefactors, and your `sum` calculation silently overflows.    I ran
>into this when teaching - I had to cast some image arrays to floating
>point to get sensible answers.
>
>Solution
>-----------
>
>I think that the default behavior of nibabel should be to do the thing
>least likely to trip you up by accident, so - I think in due course,
>nibabel should always return a floating point array from `get_data()`
>by default.
>
>I propose to add a keyword-only argument to `get_data()` - `to_float`,
>as in:
>
>data = img.get_data(to_float=False)  # The current default behavior
>data = img.get_data(to_float=True)  # Integer arrays automatically
>cast to float64
>
>For this cycle (the nibabel 2.0 series), I propose to raise a warning
>if you don't pass in an explicit True or False, warning that the
>default behavior for nibabel 3.0 will change from `to_float=False` to
>`to_float=True`.
>
>The other, more fancy ways of getting the image data would continue as
>they are, such as:
>
>data = np.array(img.dataobj)
>data = img.dataobj[:]
>
>These will both return ints or floats depending on the raw data dtype
>and the scalefactors.  This is on the basis that people using these
>will be more advanced and so therefore more likely to want memory
>efficiency at the expense of having to be careful about the returned
>data dtype.
>
>Does this seem reasonable to y'all?    Thoughts, suggestions?
>
>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/20150706/4e0c5170/attachment-0001.html>

From mwaskom at stanford.edu  Mon Jul  6 17:55:08 2015
From: mwaskom at stanford.edu (Michael Waskom)
Date: Mon, 6 Jul 2015 08:55:08 -0700
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <64EE1BDA-D6C5-49C7-A9A5-A4B4F6B16A05@gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <64EE1BDA-D6C5-49C7-A9A5-A4B4F6B16A05@gmail.com>
Message-ID: <CAKZ-Uq0sTEJV56dC0mXtJnvCKhkpbmUKB=F6U2r7O511Mox91w@mail.gmail.com>

I agree, this sounds like good thinking. I might suggest that the parameter
be named "as_float" which is more congruent with "astype(float)", an
operation many will be familiar with.

On Mon, Jul 6, 2015 at 8:46 AM, Blaise Frederick <blaise.frederick at gmail.com
> wrote:

> That seems reasonable.  It might also add clarity to define:
>
> img.get_native_data()
>
> which was just an alias of
>
> img.get_data(to_float=False)
>
> That would have the advantage of making it immediately obvious what the
> code was doing (not that the other way doesn?t).
>
> Blaise
>
> > On Jul 6, 2015, at 11:32 AM, Matthew Brett <matthew.brett at gmail.com>
> wrote:
> >
> > Hi,
> >
> > I wanted to ask y'all about an API change that I want to make to nibabel.
> >
> > In summary, I want to default to returning floating point arrays from
> > nibabel images.
> >
> > Problem - different returned data types from img.get_data()
> >
> -------------------------------------------------------------------------------
> >
> > At the moment, if you do this:
> >
> > img = nib.load('my_image.nii')
> > data = img.get_data()
> >
> > Then the data type (dtype) of the returned data array depends on the
> > values in the header of `my_image.nii`.   Specifically, if the raw
> > on-disk data type is 'np.int16' (it is often is) and the header
> > scalefactor values are default (1 for slope, 0 for intercept) then you
> > will get back an array of the on disk data type - here - np.int16.
> >
> > This is very efficient on memory, but it it's a real trap unless you
> careful.
> >
> > For example, let's say you had a pipeline where you did this:
> >
> > sum = img.get_data().sum()
> >
> > That would work fine most of the time, when the data on disk is
> > floating point, or the scalefactors are not default (1, 0).   Then one
> > day, you get an image with int16 data type on disk and 1, 0
> > scalefactors, and your `sum` calculation silently overflows.    I ran
> > into this when teaching - I had to cast some image arrays to floating
> > point to get sensible answers.
> >
> > Solution
> > -----------
> >
> > I think that the default behavior of nibabel should be to do the thing
> > least likely to trip you up by accident, so - I think in due course,
> > nibabel should always return a floating point array from `get_data()`
> > by default.
> >
> > I propose to add a keyword-only argument to `get_data()` - `to_float`,
> as in:
> >
> > data = img.get_data(to_float=False)  # The current default behavior
> > data = img.get_data(to_float=True)  # Integer arrays automatically
> > cast to float64
> >
> > For this cycle (the nibabel 2.0 series), I propose to raise a warning
> > if you don't pass in an explicit True or False, warning that the
> > default behavior for nibabel 3.0 will change from `to_float=False` to
> > `to_float=True`.
> >
> > The other, more fancy ways of getting the image data would continue as
> > they are, such as:
> >
> > data = np.array(img.dataobj)
> > data = img.dataobj[:]
> >
> > These will both return ints or floats depending on the raw data dtype
> > and the scalefactors.  This is on the basis that people using these
> > will be more advanced and so therefore more likely to want memory
> > efficiency at the expense of having to be careful about the returned
> > data dtype.
> >
> > Does this seem reasonable to y'all?    Thoughts, suggestions?
> >
> > 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/20150706/463f5e7c/attachment.html>

From bcipolli at ucsd.edu  Mon Jul  6 18:03:24 2015
From: bcipolli at ucsd.edu (Ben Cipollini)
Date: Mon, 6 Jul 2015 09:03:24 -0700
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
Message-ID: <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>

I agree with Gael.

I would also add, it also seems to be solving a problem that doesn't seem
to exist in the wild. There's never a report of hitting this issue, right?
Users using sum() or other raw operations are likely familiar with numpy,
and more ready/capable to debug their error.

Adding complexity can potentially introduce confusion for all users,
including relatively numpy-naive ones. Then we potentially have to support
new questions, and I'm not sure there's any practical benefit.

Ben

On Mon, Jul 6, 2015 at 8:55 AM, Gael Varoquaux <
gael.varoquaux at normalesup.org> wrote:

> I think that this is a very bad idea. First because it's "magic": changing
> things behind the back of the user. People will be surprised and it will
> lead to bugs in their code.  Second because it is a loss of semantics.
> Something like a mask or a label image is stored as integers for a good
> reason.
>
> The right solution to the problem is to teach people to use float data
> when relevant, but not to force this decision in them.
>
> Ga?l
>
> Sent from my phone. Please forgive brevity and mis spelling
> On Jul 6, 2015, at 17:33, Matthew Brett <matthew.brett at gmail.com> wrote:
>>
>> Hi,
>>
>> I wanted to ask y'all about an API change that I want to make to nibabel.
>>
>> In summary, I want to default to returning floating point arrays from
>> nibabel images.
>>
>> Problem - different returned data types from img.get_data()
>> ------------------------------
>>
>>
>> At the moment, if you do this:
>>
>> img = nib.load('my_image.nii')
>> data = img.get_data()
>>
>> Then the data type (dtype) of the returned data array depends on the
>> values in the header of `my_image.nii`.   Specifically, if the raw
>> on-disk data type is 'np.int16' (it is often is) and the header
>> scalefactor values are default (1 for slope, 0 for intercept) then you
>> will get back an array of the on disk data type - here - np.int16.
>>
>> This is very efficient on memory, but it it's a real trap unless you careful.
>>
>> For example, let's say you had a pipeline where you did this:
>>
>> sum = img.get_data().sum()
>>
>> That would work fine most of the time, when the data on disk
>> is
>> floating point, or the scalefactors are not default (1, 0).   Then one
>> day, you get an image with int16 data type on disk and 1, 0
>> scalefactors, and your `sum` calculation silently overflows.    I ran
>> into this when teaching - I had to cast some image arrays to floating
>> point to get sensible answers.
>>
>> Solution
>> -----------
>>
>> I think that the default behavior of nibabel should be to do the thing
>> least likely to trip you up by accident, so - I think in due course,
>> nibabel should always return a floating point array from `get_data()`
>> by default.
>>
>> I propose to add a keyword-only argument to `get_data()` - `to_float`, as in:
>>
>> data = img.get_data(to_float=False)  # The current default behavior
>> data = img.get_data(to_float=True)  # Integer arrays automatically
>> cast to float64
>>
>> For this cycle (the nibabel 2.0 series), I propose to raise a warning
>> if you don't pass in an explicit True or False, warning that the
>> def!
>>  ault
>> behavior for nibabel 3.0 will change from `to_float=False` to
>> `to_float=True`.
>>
>> The other, more fancy ways of getting the image data would continue as
>> they are, such as:
>>
>> data = np.array(img.dataobj)
>> data = img.dataobj[:]
>>
>> These will both return ints or floats depending on the raw data dtype
>> and the scalefactors.  This is on the basis that people using these
>> will be more advanced and so therefore more likely to want memory
>> efficiency at the expense of having to be careful about the returned
>> data dtype.
>>
>> Does this seem reasonable to y'all?    Thoughts, suggestions?
>>
>> 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/20150706/908b7f78/attachment-0001.html>

From matthew.brett at gmail.com  Mon Jul  6 18:05:53 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Mon, 6 Jul 2015 17:05:53 +0100
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
Message-ID: <CAH6Pt5oVO3cRc5XFuaB5BJ+xdVMQYFDg2umH6c4gfnewe24==g@mail.gmail.com>

Hi,

On Mon, Jul 6, 2015 at 4:55 PM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> I think that this is a very bad idea. First because it's "magic": changing
> things behind the back of the user. People will be surprised and it will
> lead to bugs in their code.  Second because it is a loss of semantics.
> Something like a mask or a label image is stored as integers for a good
> reason.

Sure - but if the mask or label image is stored in anything less than
(u)int64, then float64 can encode the values exactly (float64 encodes
integers up to 2 ** 53 exactly).  So it will be less efficient, but
unless the user was relying on integer overflow, I think bugs will be
unusual.

At the moment the user is in a bad situation, because the output data
type can be arbitrary, depending on whether the author of the image
felt like writing the scalefactors in or not.   If they did, then you
get a float image, if they didn't you get an integer image, and
usually, an int16 image for which it is very easy to hit integer
overflow.

> The right solution to the problem is to teach people to use float data when
> relevant, but not to force this decision in them.

I don't think this is magic - it's just a sensible default.  So, the
users who don't want the decision forced on them can very easily opt
out.

Cheers,

Matthew

From matthew.brett at gmail.com  Mon Jul  6 18:13:00 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Mon, 6 Jul 2015 17:13:00 +0100
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
Message-ID: <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>

Hi,

On Mon, Jul 6, 2015 at 5:03 PM, Ben Cipollini <bcipolli at ucsd.edu> wrote:
> I agree with Gael.
>
> I would also add, it also seems to be solving a problem that doesn't seem to
> exist in the wild. There's never a report of hitting this issue, right?
> Users using sum() or other raw operations are likely familiar with numpy,
> and more ready/capable to debug their error.

Basically any numpy operation on the returned array can give you weird errors.

I did precisely run into this when teaching the students.  I was
teaching them to run diagnostics, and the script I wrote used the sum.
This worked fine on one set of functional images, but gave a
completely wrong answer on another set of images, and it took me a
little while to work out what had gone wrong.  Part of the problem is
that nifti images are often int16, so it's easy to run into silent
horrors just by adding or subtracting.  My feeling is that dealing
with any operations on int16 arrays is for advanced users.  Advanced
users will know to do `to_float=False`.

> Adding complexity can potentially introduce confusion for all users,
> including relatively numpy-naive ones. Then we potentially have to support
> new questions, and I'm not sure there's any practical benefit.

I think this is reducing complexity for basic use (you don't have to
think about your data types, until you want to think about your data
types).  At the moment, when you see this:

data = img.get_data()

you have to think 'oh wait, at the moment I can't easily predict what
data type this is.  If I want to do stuff with this array, I will
probably have to cast to float for safety'.

Cheers,

Matthew

From effigies at bu.edu  Mon Jul  6 18:07:23 2015
From: effigies at bu.edu (Christopher J Markiewicz)
Date: Mon, 06 Jul 2015 12:07:23 -0400
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
Message-ID: <559AA7BB.2000500@bu.edu>

On 07/06/2015 11:55 AM, Gael Varoquaux wrote:
> I think that this is a very bad idea. First because it's "magic":
> changing things behind the back of the user. People will be surprised
> and it will lead to bugs in their code.  Second because it is a loss of
> semantics. Something like a mask or a label image is stored as integers
> for a good reason.
> 
> The right solution to the problem is to teach people to use float data
> when relevant, but not to force this decision in them.
> 
> Ga?l

I agree with Ga?l's reasoning here.

I'm okay with adding a to_float parameter to get_data, but would prefer
to leave its default value as False, even in nibabel 3+.

-- 
Christopher J Markiewicz
Ph.D. Candidate, Quantitative Neuroscience Laboratory
Boston University

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150706/4f4493a0/attachment.sig>

From mwaskom at stanford.edu  Mon Jul  6 18:23:54 2015
From: mwaskom at stanford.edu (Michael Waskom)
Date: Mon, 6 Jul 2015 09:23:54 -0700
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <559AA7BB.2000500@bu.edu>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com> <559AA7BB.2000500@bu.edu>
Message-ID: <CAKZ-Uq2fs0r6mQTfpy=1Uk92U=cm8BL-g22-XjMkqC_uxYcp6g@mail.gmail.com>

It's not really clear to me why this would introduce "magic" behavior. It's
behavior that has a clear relationship with the parameter of a function.
Maybe you don't think the choice for the default is optimal, but it doesn't
feel very productive to dismiss it as "magic".

On Mon, Jul 6, 2015 at 9:07 AM, Christopher J Markiewicz <effigies at bu.edu>
wrote:

> On 07/06/2015 11:55 AM, Gael Varoquaux wrote:
> > I think that this is a very bad idea. First because it's "magic":
> > changing things behind the back of the user. People will be surprised
> > and it will lead to bugs in their code.  Second because it is a loss of
> > semantics. Something like a mask or a label image is stored as integers
> > for a good reason.
> >
> > The right solution to the problem is to teach people to use float data
> > when relevant, but not to force this decision in them.
> >
> > Ga?l
>
> I agree with Ga?l's reasoning here.
>
> I'm okay with adding a to_float parameter to get_data, but would prefer
> to leave its default value as False, even in nibabel 3+.
>
> --
> Christopher J Markiewicz
> Ph.D. Candidate, Quantitative Neuroscience Laboratory
> Boston University
>
>
> _______________________________________________
> 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/20150706/e04c4f8d/attachment.html>

From vsochat at stanford.edu  Mon Jul  6 18:24:46 2015
From: vsochat at stanford.edu (vanessa sochat)
Date: Mon, 6 Jul 2015 09:24:46 -0700
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
Message-ID: <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>

I don't like the modification, because there are plenty of images that
should be returned as int16. It's much more reasonable to have a workflow
like:

data = img.get_data()

*look at, think about, your data*
*make decisions* (cast as float, don't, etc)

Possibly we can have an intermediate solution of leaving the default
behavior and adding a to_float parameter, as Christopher suggested. But I'm
not sure how that is any better or different than float(data).


On Mon, Jul 6, 2015 at 9:13 AM, Matthew Brett <matthew.brett at gmail.com>
wrote:

> Hi,
>
> On Mon, Jul 6, 2015 at 5:03 PM, Ben Cipollini <bcipolli at ucsd.edu> wrote:
> > I agree with Gael.
> >
> > I would also add, it also seems to be solving a problem that doesn't
> seem to
> > exist in the wild. There's never a report of hitting this issue, right?
> > Users using sum() or other raw operations are likely familiar with numpy,
> > and more ready/capable to debug their error.
>
> Basically any numpy operation on the returned array can give you weird
> errors.
>
> I did precisely run into this when teaching the students.  I was
> teaching them to run diagnostics, and the script I wrote used the sum.
> This worked fine on one set of functional images, but gave a
> completely wrong answer on another set of images, and it took me a
> little while to work out what had gone wrong.  Part of the problem is
> that nifti images are often int16, so it's easy to run into silent
> horrors just by adding or subtracting.  My feeling is that dealing
> with any operations on int16 arrays is for advanced users.  Advanced
> users will know to do `to_float=False`.
>
> > Adding complexity can potentially introduce confusion for all users,
> > including relatively numpy-naive ones. Then we potentially have to
> support
> > new questions, and I'm not sure there's any practical benefit.
>
> I think this is reducing complexity for basic use (you don't have to
> think about your data types, until you want to think about your data
> types).  At the moment, when you see this:
>
> data = img.get_data()
>
> you have to think 'oh wait, at the moment I can't easily predict what
> data type this is.  If I want to do stuff with this array, I will
> probably have to cast to float for safety'.
>
> Cheers,
>
> Matthew
> _______________________________________________
> Neuroimaging mailing list
> Neuroimaging at python.org
> https://mail.python.org/mailman/listinfo/neuroimaging
>



-- 
Vanessa Villamia Sochat
Stanford University
(603) 321-0676
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150706/c20f70f6/attachment-0001.html>

From matthew.brett at gmail.com  Mon Jul  6 18:30:34 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Mon, 6 Jul 2015 17:30:34 +0100
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
Message-ID: <CAH6Pt5rALqhFYFooiYyY+PDU0083vCnXk2ouFP_rMyHqyakXaQ@mail.gmail.com>

Hi,

On Mon, Jul 6, 2015 at 5:24 PM, vanessa sochat <vsochat at stanford.edu> wrote:
> I don't like the modification, because there are plenty of images that
> should be returned as int16. b

There are certainly some images like that, but in my experience a
large majority of images stored on disk as int16 are stored that way
to conserve disk space.    For example, structural or functional
images are usually stored as int16, but we will nearly always want to
use floating point on them.

To help, can anyone come up with a realistic case where casting to
float64 will in fact case a bug, even for mask or label images?

> It's much more reasonable to have a workflow
> like:
>
> data = img.get_data()
>
> *look at, think about, your data*
> *make decisions* (cast as float, don't, etc)

I guess I'm repeating myself, but I don't want to force that need on
beginning users, as we do now.

> Possibly we can have an intermediate solution of leaving the default
> behavior and adding a to_float parameter, as Christopher suggested. But I'm
> not sure how that is any better or different than float(data).

Yes, there's no point in the parameter if it is not going to be the default.

Cheers,

Matthew

From bertrand.thirion at inria.fr  Mon Jul  6 18:32:10 2015
From: bertrand.thirion at inria.fr (Bertrand Thirion)
Date: Mon, 6 Jul 2015 18:32:10 +0200 (CEST)
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
Message-ID: <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>

+1 we (and more importantly, our students) should rely as much as possible on the standard behavior of numpy arrays and make adequate decisions, rather than having to figure out the details of the API of neuroimaging libraries. So the defaut should be unchanged. 

Bertrand 

----- Mail original -----

> De: "vanessa sochat" <vsochat at stanford.edu>
> ?: "Neuroimaging analysis in Python" <neuroimaging at python.org>
> Envoy?: Lundi 6 Juillet 2015 18:24:46
> Objet: Re: [Neuroimaging] Nibabel API change - always read as float

> I don't like the modification, because there are plenty of images that should
> be returned as int16. It's much more reasonable to have a workflow like:

> data = img.get_data()

> *look at, think about, your data*
> *make decisions* (cast as float, don't, etc)

> Possibly we can have an intermediate solution of leaving the default behavior
> and adding a to_float parameter, as Christopher suggested. But I'm not sure
> how that is any better or different than float(data).

> On Mon, Jul 6, 2015 at 9:13 AM, Matthew Brett < matthew.brett at gmail.com >
> wrote:

> > Hi,
> 

> > On Mon, Jul 6, 2015 at 5:03 PM, Ben Cipollini < bcipolli at ucsd.edu > wrote:
> 
> > > I agree with Gael.
> 
> > >
> 
> > > I would also add, it also seems to be solving a problem that doesn't seem
> > > to
> 
> > > exist in the wild. There's never a report of hitting this issue, right?
> 
> > > Users using sum() or other raw operations are likely familiar with numpy,
> 
> > > and more ready/capable to debug their error.
> 

> > Basically any numpy operation on the returned array can give you weird
> > errors.
> 

> > I did precisely run into this when teaching the students. I was
> 
> > teaching them to run diagnostics, and the script I wrote used the sum.
> 
> > This worked fine on one set of functional images, but gave a
> 
> > completely wrong answer on another set of images, and it took me a
> 
> > little while to work out what had gone wrong. Part of the problem is
> 
> > that nifti images are often int16, so it's easy to run into silent
> 
> > horrors just by adding or subtracting. My feeling is that dealing
> 
> > with any operations on int16 arrays is for advanced users. Advanced
> 
> > users will know to do `to_float=False`.
> 

> > > Adding complexity can potentially introduce confusion for all users,
> 
> > > including relatively numpy-naive ones. Then we potentially have to
> > > support
> 
> > > new questions, and I'm not sure there's any practical benefit.
> 

> > I think this is reducing complexity for basic use (you don't have to
> 
> > think about your data types, until you want to think about your data
> 
> > types). At the moment, when you see this:
> 

> > data = img.get_data()
> 

> > you have to think 'oh wait, at the moment I can't easily predict what
> 
> > data type this is. If I want to do stuff with this array, I will
> 
> > probably have to cast to float for safety'.
> 

> > Cheers,
> 

> > Matthew
> 
> > _______________________________________________
> 
> > Neuroimaging mailing list
> 
> > Neuroimaging at python.org
> 
> > https://mail.python.org/mailman/listinfo/neuroimaging
> 

> --
> Vanessa Villamia Sochat
> Stanford University
> (603) 321-0676

> _______________________________________________
> 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/20150706/b0b494d3/attachment.html>

From mwaskom at stanford.edu  Mon Jul  6 18:33:42 2015
From: mwaskom at stanford.edu (Michael Waskom)
Date: Mon, 6 Jul 2015 09:33:42 -0700
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
Message-ID: <CAKZ-Uq0RJv66_DuApKp_kw-MQ85G+dSJQdCy8G0X4zO-M4yyJQ@mail.gmail.com>

But that logic equally applies when the default behavior of get_data() is
to cast the data to float. You should still look at your data and then
decide what the right way to handle it is (with one option being "read
again with as_float=False). But I think Matthew's point is that the
possible risks of getting int data and treating it like float are greater
and less obvious than the possible risks of getting float data and treating
it like int. Do you disagree with that?

On Mon, Jul 6, 2015 at 9:24 AM, vanessa sochat <vsochat at stanford.edu> wrote:

> I don't like the modification, because there are plenty of images that
> should be returned as int16. It's much more reasonable to have a workflow
> like:
>
> data = img.get_data()
>
> *look at, think about, your data*
> *make decisions* (cast as float, don't, etc)
>
> Possibly we can have an intermediate solution of leaving the default
> behavior and adding a to_float parameter, as Christopher suggested. But I'm
> not sure how that is any better or different than float(data).
>
>
> On Mon, Jul 6, 2015 at 9:13 AM, Matthew Brett <matthew.brett at gmail.com>
> wrote:
>
>> Hi,
>>
>> On Mon, Jul 6, 2015 at 5:03 PM, Ben Cipollini <bcipolli at ucsd.edu> wrote:
>> > I agree with Gael.
>> >
>> > I would also add, it also seems to be solving a problem that doesn't
>> seem to
>> > exist in the wild. There's never a report of hitting this issue, right?
>> > Users using sum() or other raw operations are likely familiar with
>> numpy,
>> > and more ready/capable to debug their error.
>>
>> Basically any numpy operation on the returned array can give you weird
>> errors.
>>
>> I did precisely run into this when teaching the students.  I was
>> teaching them to run diagnostics, and the script I wrote used the sum.
>> This worked fine on one set of functional images, but gave a
>> completely wrong answer on another set of images, and it took me a
>> little while to work out what had gone wrong.  Part of the problem is
>> that nifti images are often int16, so it's easy to run into silent
>> horrors just by adding or subtracting.  My feeling is that dealing
>> with any operations on int16 arrays is for advanced users.  Advanced
>> users will know to do `to_float=False`.
>>
>> > Adding complexity can potentially introduce confusion for all users,
>> > including relatively numpy-naive ones. Then we potentially have to
>> support
>> > new questions, and I'm not sure there's any practical benefit.
>>
>> I think this is reducing complexity for basic use (you don't have to
>> think about your data types, until you want to think about your data
>> types).  At the moment, when you see this:
>>
>> data = img.get_data()
>>
>> you have to think 'oh wait, at the moment I can't easily predict what
>> data type this is.  If I want to do stuff with this array, I will
>> probably have to cast to float for safety'.
>>
>> Cheers,
>>
>> Matthew
>> _______________________________________________
>> Neuroimaging mailing list
>> Neuroimaging at python.org
>> https://mail.python.org/mailman/listinfo/neuroimaging
>>
>
>
>
> --
> Vanessa Villamia Sochat
> Stanford University
> (603) 321-0676
>
> _______________________________________________
> 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/20150706/05b2e781/attachment-0001.html>

From abraham.alexandre at gmail.com  Mon Jul  6 18:38:27 2015
From: abraham.alexandre at gmail.com (Alexandre ABRAHAM)
Date: Mon, 6 Jul 2015 18:38:27 +0200
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
Message-ID: <CAE_wbFvg3n8jsr_cR25gcxz7NQV2zg_iscBS17XZHkfzTuWJYw@mail.gmail.com>

Hi list,

For all the reasons mentioned above, I also think that it's a bad idea. As
a regular user of nibabel for big data, this would be a burden for me
espacially because, when we cast to float, we chose float32 to save as
memory as possible (most of the time, float64 precision is not needed and
it costs a lot).

Speaking of beginners, I think that it is better to warn them, rather to
set up guards everywhere. This problem is not nibabel specific: it is numpy
(and even python) specific. I think that teaching them to _always_ cast
their data to float unless they know what they're doing is a good idea.
Better, np.seterr() is here to help you set overflow as errors.

Alex.


On Mon, Jul 6, 2015 at 6:24 PM, vanessa sochat <vsochat at stanford.edu> wrote:

> I don't like the modification, because there are plenty of images that
> should be returned as int16. It's much more reasonable to have a workflow
> like:
>
> data = img.get_data()
>
> *look at, think about, your data*
> *make decisions* (cast as float, don't, etc)
>
> Possibly we can have an intermediate solution of leaving the default
> behavior and adding a to_float parameter, as Christopher suggested. But I'm
> not sure how that is any better or different than float(data).
>
>
> On Mon, Jul 6, 2015 at 9:13 AM, Matthew Brett <matthew.brett at gmail.com>
> wrote:
>
>> Hi,
>>
>> On Mon, Jul 6, 2015 at 5:03 PM, Ben Cipollini <bcipolli at ucsd.edu> wrote:
>> > I agree with Gael.
>> >
>> > I would also add, it also seems to be solving a problem that doesn't
>> seem to
>> > exist in the wild. There's never a report of hitting this issue, right?
>> > Users using sum() or other raw operations are likely familiar with
>> numpy,
>> > and more ready/capable to debug their error.
>>
>> Basically any numpy operation on the returned array can give you weird
>> errors.
>>
>> I did precisely run into this when teaching the students.  I was
>> teaching them to run diagnostics, and the script I wrote used the sum.
>> This worked fine on one set of functional images, but gave a
>> completely wrong answer on another set of images, and it took me a
>> little while to work out what had gone wrong.  Part of the problem is
>> that nifti images are often int16, so it's easy to run into silent
>> horrors just by adding or subtracting.  My feeling is that dealing
>> with any operations on int16 arrays is for advanced users.  Advanced
>> users will know to do `to_float=False`.
>>
>> > Adding complexity can potentially introduce confusion for all users,
>> > including relatively numpy-naive ones. Then we potentially have to
>> support
>> > new questions, and I'm not sure there's any practical benefit.
>>
>> I think this is reducing complexity for basic use (you don't have to
>> think about your data types, until you want to think about your data
>> types).  At the moment, when you see this:
>>
>> data = img.get_data()
>>
>> you have to think 'oh wait, at the moment I can't easily predict what
>> data type this is.  If I want to do stuff with this array, I will
>> probably have to cast to float for safety'.
>>
>> Cheers,
>>
>> Matthew
>> _______________________________________________
>> Neuroimaging mailing list
>> Neuroimaging at python.org
>> https://mail.python.org/mailman/listinfo/neuroimaging
>>
>
>
>
> --
> Vanessa Villamia Sochat
> Stanford University
> (603) 321-0676
>
> _______________________________________________
> 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/20150706/1f747aa9/attachment.html>

From matthew.brett at gmail.com  Mon Jul  6 18:37:37 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Mon, 6 Jul 2015 17:37:37 +0100
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
Message-ID: <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>

On Mon, Jul 6, 2015 at 5:32 PM, Bertrand Thirion
<bertrand.thirion at inria.fr> wrote:
> +1 we (and more importantly, our students)  should rely as much as possible
> on the standard behavior of numpy arrays and make adequate decisions, rather
> than having to figure out the details of the API of neuroimaging libraries.
> So the defaut should be unchanged.

Your reasoning implies the opposite.   Numpy tries very hard not to
return arrays of unknown or unpredictable data types, and that is the
situation we have here.   The returned datatype from a nibabel image
is essentially arbitrary, in that very few sources of nifti files
place any weight on whether there are non-default scalefactors or not.
At the moment, we do, depend on this, silently, and that is extremely
confusing, and quite contrary to the standard numpy way,

Cheers,

Matthew

From bcipolli at ucsd.edu  Mon Jul  6 18:56:35 2015
From: bcipolli at ucsd.edu (Ben Cipollini)
Date: Mon, 6 Jul 2015 09:56:35 -0700
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
Message-ID: <CANgTvZjxsEVrpqC-ioPBHJiVCZkh1VRutpXwS9zFAy4Q4M31xA@mail.gmail.com>

How about accepting a dtype parameter, with None meaning using the type
determined from load (i.e. current behavior)? This makes it easy to
document the 'arbitrary' behavior for the user (in explaining the
parameter), to convert to whatever datatype you want (if you know your data
or have particular needs like Alex). I also believe this is closer to a
numpy semantic, to_float is a new semantic (even if relatively simple).

As for what the default should be (None or float32 or float64)... I would
not touch that conversation quite yet :)

On Mon, Jul 6, 2015 at 9:37 AM, Matthew Brett <matthew.brett at gmail.com>
wrote:

> On Mon, Jul 6, 2015 at 5:32 PM, Bertrand Thirion
> <bertrand.thirion at inria.fr> wrote:
> > +1 we (and more importantly, our students)  should rely as much as
> possible
> > on the standard behavior of numpy arrays and make adequate decisions,
> rather
> > than having to figure out the details of the API of neuroimaging
> libraries.
> > So the defaut should be unchanged.
>
> Your reasoning implies the opposite.   Numpy tries very hard not to
> return arrays of unknown or unpredictable data types, and that is the
> situation we have here.   The returned datatype from a nibabel image
> is essentially arbitrary, in that very few sources of nifti files
> place any weight on whether there are non-default scalefactors or not.
> At the moment, we do, depend on this, silently, and that is extremely
> confusing, and quite contrary to the standard numpy way,
>
> 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/20150706/c801176d/attachment.html>

From arokem at gmail.com  Mon Jul  6 19:53:10 2015
From: arokem at gmail.com (Ariel Rokem)
Date: Mon, 6 Jul 2015 10:53:10 -0700
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CANgTvZjxsEVrpqC-ioPBHJiVCZkh1VRutpXwS9zFAy4Q4M31xA@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
 <CANgTvZjxsEVrpqC-ioPBHJiVCZkh1VRutpXwS9zFAy4Q4M31xA@mail.gmail.com>
Message-ID: <CA+X4w0yGTf9jtsnKKE-MD+UHc24yKhNFaO8Kdii828syU47MOQ@mail.gmail.com>

On Mon, Jul 6, 2015 at 9:56 AM, Ben Cipollini <bcipolli at ucsd.edu> wrote:

> How about accepting a dtype parameter, with None meaning using the type
> determined from load (i.e. current behavior)? This makes it easy to
> document the 'arbitrary' behavior for the user (in explaining the
> parameter), to convert to whatever datatype you want (if you know your data
> or have particular needs like Alex). I also believe this is closer to a
> numpy semantic, to_float is a new semantic (even if relatively simple).
>
>
+1 for a `dtype` kwarg, rather than `as_float`, with the input being a
numpy dtype to which things get cast. That will give Alex the flexibility
to choose float32, rather than float64, if he doesn't need all that extra
precision.


> As for what the default should be (None or float32 or float64)... I would
> not touch that conversation quite yet :)
>
>
I think the default here should be whatever your system does when you
allocate an empty/zeros numpy array (that's float64 for me). Seems only
slightly less arbitrary than the current behavior (I think). As I
understand it, to mask with an array, you need to go to bool anyway, so
this could be nice for the masking use-case:

    data[nib.load('mask.nii.gz').get_data(dtype=bool)]

If the implementation can avoid going to a memory-consuming dtype along the
way, that would have a small advantage relative to a call to `as_type`
after loading into memory.

Cheers,

Ariel







> On Mon, Jul 6, 2015 at 9:37 AM, Matthew Brett <matthew.brett at gmail.com>
> wrote:
>
>> On Mon, Jul 6, 2015 at 5:32 PM, Bertrand Thirion
>> <bertrand.thirion at inria.fr> wrote:
>> > +1 we (and more importantly, our students)  should rely as much as
>> possible
>> > on the standard behavior of numpy arrays and make adequate decisions,
>> rather
>> > than having to figure out the details of the API of neuroimaging
>> libraries.
>> > So the defaut should be unchanged.
>>
>> Your reasoning implies the opposite.   Numpy tries very hard not to
>> return arrays of unknown or unpredictable data types, and that is the
>> situation we have here.   The returned datatype from a nibabel image
>> is essentially arbitrary, in that very few sources of nifti files
>> place any weight on whether there are non-default scalefactors or not.
>> At the moment, we do, depend on this, silently, and that is extremely
>> confusing, and quite contrary to the standard numpy way,
>>
>> 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/20150706/dc7262ed/attachment-0001.html>

From njvack at wisc.edu  Mon Jul  6 19:03:38 2015
From: njvack at wisc.edu (Nate Vack)
Date: Mon, 06 Jul 2015 17:03:38 +0000
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
Message-ID: <CA+1BpOsyJohLmWu5uzV+6QNWDqryMXi-hTZeFKpGSq+=ApUEqA@mail.gmail.com>

FWIW, I'd prefer nibabel not do automatic type casting, but this is an
emotional response, rather than one backed up by "hey this will break my
code!"

But! If we're to do it, I don't like the approach of an as_float parameter.
Passing dtype (probably defaulting to np.float64) would be much better, or
it might make more sense to add a new method, say,
get_data_without_type_cast().

-n



On Mon, Jul 6, 2015 at 11:45 AM Matthew Brett <matthew.brett at gmail.com>
wrote:

> On Mon, Jul 6, 2015 at 5:32 PM, Bertrand Thirion
> <bertrand.thirion at inria.fr> wrote:
> > +1 we (and more importantly, our students)  should rely as much as
> possible
> > on the standard behavior of numpy arrays and make adequate decisions,
> rather
> > than having to figure out the details of the API of neuroimaging
> libraries.
> > So the defaut should be unchanged.
>
> Your reasoning implies the opposite.   Numpy tries very hard not to
> return arrays of unknown or unpredictable data types, and that is the
> situation we have here.   The returned datatype from a nibabel image
> is essentially arbitrary, in that very few sources of nifti files
> place any weight on whether there are non-default scalefactors or not.
> At the moment, we do, depend on this, silently, and that is extremely
> confusing, and quite contrary to the standard numpy way,
>
> 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/20150706/2272037f/attachment.html>

From moloney at ohsu.edu  Mon Jul  6 20:12:27 2015
From: moloney at ohsu.edu (Brendan Moloney)
Date: Mon, 6 Jul 2015 18:12:27 +0000
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CA+X4w0yGTf9jtsnKKE-MD+UHc24yKhNFaO8Kdii828syU47MOQ@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
 <CANgTvZjxsEVrpqC-ioPBHJiVCZkh1VRutpXwS9zFAy4Q4M31xA@mail.gmail.com>,
 <CA+X4w0yGTf9jtsnKKE-MD+UHc24yKhNFaO8Kdii828syU47MOQ@mail.gmail.com>
Message-ID: <5F6A858FD00E5F4A82E3206D2D854EF87F741D35@EXMB10.ohsu.edu>

I agree that the 'dtype' keyword is the better option. It gives more flexibility and better aligns with numpy.

I am on the fence for what the default should be, but I do lean towards Matthew's argument that avoiding (or not promoting) subtle bugs is more important than efficiency for novice users.

-Brendan

________________________________
From: Neuroimaging [neuroimaging-bounces+moloney=ohsu.edu at python.org] on behalf of Ariel Rokem [arokem at gmail.com]
Sent: Monday, July 06, 2015 10:53 AM
To: Neuroimaging analysis in Python
Subject: Re: [Neuroimaging] Nibabel API change - always read as float


On Mon, Jul 6, 2015 at 9:56 AM, Ben Cipollini <bcipolli at ucsd.edu<mailto:bcipolli at ucsd.edu>> wrote:
How about accepting a dtype parameter, with None meaning using the type determined from load (i.e. current behavior)? This makes it easy to document the 'arbitrary' behavior for the user (in explaining the parameter), to convert to whatever datatype you want (if you know your data or have particular needs like Alex). I also believe this is closer to a numpy semantic, to_float is a new semantic (even if relatively simple).


+1 for a `dtype` kwarg, rather than `as_float`, with the input being a numpy dtype to which things get cast. That will give Alex the flexibility to choose float32, rather than float64, if he doesn't need all that extra precision.

As for what the default should be (None or float32 or float64)... I would not touch that conversation quite yet :)


I think the default here should be whatever your system does when you allocate an empty/zeros numpy array (that's float64 for me). Seems only slightly less arbitrary than the current behavior (I think). As I understand it, to mask with an array, you need to go to bool anyway, so this could be nice for the masking use-case:

    data[nib.load('mask.nii.gz').get_data(dtype=bool)]

If the implementation can avoid going to a memory-consuming dtype along the way, that would have a small advantage relative to a call to `as_type` after loading into memory.

Cheers,

Ariel






On Mon, Jul 6, 2015 at 9:37 AM, Matthew Brett <matthew.brett at gmail.com<mailto:matthew.brett at gmail.com>> wrote:
On Mon, Jul 6, 2015 at 5:32 PM, Bertrand Thirion
<bertrand.thirion at inria.fr<mailto:bertrand.thirion at inria.fr>> wrote:
> +1 we (and more importantly, our students)  should rely as much as possible
> on the standard behavior of numpy arrays and make adequate decisions, rather
> than having to figure out the details of the API of neuroimaging libraries.
> So the defaut should be unchanged.

Your reasoning implies the opposite.   Numpy tries very hard not to
return arrays of unknown or unpredictable data types, and that is the
situation we have here.   The returned datatype from a nibabel image
is essentially arbitrary, in that very few sources of nifti files
place any weight on whether there are non-default scalefactors or not.
At the moment, we do, depend on this, silently, and that is extremely
confusing, and quite contrary to the standard numpy way,

Cheers,

Matthew
_______________________________________________
Neuroimaging mailing list
Neuroimaging at python.org<mailto:Neuroimaging at python.org>
https://mail.python.org/mailman/listinfo/neuroimaging


_______________________________________________
Neuroimaging mailing list
Neuroimaging at python.org<mailto: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/20150706/ca55240c/attachment.html>

From bertrand.thirion at inria.fr  Mon Jul  6 21:15:20 2015
From: bertrand.thirion at inria.fr (bthirion)
Date: Mon, 06 Jul 2015 21:15:20 +0200
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
Message-ID: <559AD3C8.8020202@inria.fr>



On 06/07/2015 18:37, Matthew Brett wrote:
> On Mon, Jul 6, 2015 at 5:32 PM, Bertrand Thirion
> <bertrand.thirion at inria.fr> wrote:
>> +1 we (and more importantly, our students)  should rely as much as possible
>> on the standard behavior of numpy arrays and make adequate decisions, rather
>> than having to figure out the details of the API of neuroimaging libraries.
>> So the defaut should be unchanged.
> Your reasoning implies the opposite.   Numpy tries very hard not to
> return arrays of unknown or unpredictable data types, and that is the
> situation we have here.   The returned datatype from a nibabel image
> is essentially arbitrary, in that very few sources of nifti files
> place any weight on whether there are non-default scalefactors or not.
> At the moment, we do, depend on this, silently, and that is extremely
> confusing, and quite contrary to the standard numpy way,
Sorry for being unclear, but Numpy would never force casting when 
loading data.

When you get some array, you need to be aware of what it is in order to 
work with it. A mask or label image is not meant to be something on 
which you perform algebraic manipulations. Sure, you can get it wrong if 
you don't know what you're doing, but either this user has to learn it 
or he/she should consider using higher level interfaces to work with images.

B

From moloney at ohsu.edu  Mon Jul  6 21:49:21 2015
From: moloney at ohsu.edu (Brendan Moloney)
Date: Mon, 6 Jul 2015 19:49:21 +0000
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <559AD3C8.8020202@inria.fr>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>,
 <559AD3C8.8020202@inria.fr>
Message-ID: <5F6A858FD00E5F4A82E3206D2D854EF87F741DC0@EXMB10.ohsu.edu>

> Sorry for being unclear, but Numpy would never force casting when
> loading data.

Numpy does "force" casting when the original data type is not completely 
clear. For example point the 'loadtxt' function at a text file containing all 
integers. Also, numpy does not have to deal with the weirdness of using 
integers plus scale factors to represent floating point data.

> When you get some array, you need to be aware of what it is in order to
> work with it. A mask or label image is not meant to be something on
> which you perform algebraic manipulations. Sure, you can get it wrong if
> you don't know what you're doing, but either this user has to learn it
> or he/she should consider using higher level interfaces to work with images.

It really isn't as simple as knowing if your image is a mask or label image.  
Most regular images will load as int16 unless the scale factors are used, 
and it isn't always obvious. Even without scale factors the data in an 
MRI isn't inherently integer data, it was just quantized that way for 
efficiency. 

In the obvious case of loading a mask or label image, it isn't too hard to 
pass the correct 'dtype' to the load function. Just like you would do if your 
mask was stored in a text file and you used numpy 'loadtxt' function.

-Brendan


From abraham.alexandre at gmail.com  Mon Jul  6 22:13:30 2015
From: abraham.alexandre at gmail.com (Alexandre ABRAHAM)
Date: Mon, 6 Jul 2015 22:13:30 +0200
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <5F6A858FD00E5F4A82E3206D2D854EF87F741DC0@EXMB10.ohsu.edu>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
 <559AD3C8.8020202@inria.fr>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741DC0@EXMB10.ohsu.edu>
Message-ID: <CAE_wbFvfHYgFvCV_1-K6uG8KL0RHgDjhD6kixqObd7DiAtQvrw@mail.gmail.com>

> Numpy does "force" casting when the original data type is not completely
> clear. For example point the 'loadtxt' function at a text file containing
> all
> integers.


Well, unless I am mistaken, there is no ambiguity in the datatype of a
binary file. Plus,  numpy does not enforce anything, it is just a default
value. Using np.genfromtxt(dtype=None), and you get a more logical behavior.
Whatever you do, if you load a npy file using np.load, it will always be of
the type saved in the first place.

Also, numpy does not have to deal with the weirdness of using
> integers plus scale factors to represent floating point data.
>

Well, in that case, why not adding a dtype value in the header ?

Even without scale factors the data in an
> MRI isn't inherently integer data, it was just quantized that way for
> efficiency.
>

Except that Nifti can store other things than MRI data (such as masks,
labels, or any voxel-related value).

Alex.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150706/2b2c3959/attachment.html>

From moloney at ohsu.edu  Mon Jul  6 22:50:30 2015
From: moloney at ohsu.edu (Brendan Moloney)
Date: Mon, 6 Jul 2015 20:50:30 +0000
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAE_wbFvfHYgFvCV_1-K6uG8KL0RHgDjhD6kixqObd7DiAtQvrw@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
 <559AD3C8.8020202@inria.fr>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741DC0@EXMB10.ohsu.edu>,
 <CAE_wbFvfHYgFvCV_1-K6uG8KL0RHgDjhD6kixqObd7DiAtQvrw@mail.gmail.com>
Message-ID: <5F6A858FD00E5F4A82E3206D2D854EF87F741E3E@EXMB10.ohsu.edu>

> Well, unless I am mistaken, there is no ambiguity in the
> datatype of a binary file.

I guess you mean a .npy file?  A plain binary file is nothing
but ambiguity.

> Plus,  numpy does not enforce anything, it is just a
> default value.

The latest proposition that I am running with is to include
a 'dtype' keyword for nibabel.load. I guess Matthew would
argue the default value should be float, and I am really
starting to agree with that point of view.

> Using np.genfromtxt(dtype=None), and you get a more
> logical behavior.

$ cat testfile
1 2 3 4 5
1 2.2 3 4 5

$ python -c 'from numpy import genfromtxt ; print genfromtxt("testfile", dtype=None)'
[(1, 2.0, 3, 4, 5) (1, 2.2000000000000002, 3, 4, 5)]

I don't find this behavior to be particularly logical. I guess
there is a reason the default is 'float'.

> Whatever you do, if you load a npy file using np.load,
> it will always be of the type saved in the first place.

Because it is a nice clean file format they control entirely.

> Also, numpy does not have to deal with the weirdness of using
> integers plus scale factors to represent floating point data.

> Well, in that case, why not adding a dtype value in the header ?

Because nibabel tries to load a bunch of formats that we have little
to no control over. Even in Nifti files where there is an "intent code"
that could be set to NIFTI_INTENT_LABEL for label files, I don't
think any software actually does this. Even if some software does,
we can't rely on it.

> Even without scale factors the data in an
> MRI isn't inherently integer data, it was just quantized that way for
> efficiency.

> Except that Nifti can store other things than MRI data (such as masks,
> labels, or any voxel-related value).

I clearly acknowledged that in the next paragraph (which you trimmed),
and you don't address the fact that is almost always obvious from
context if the file is a mask/label. It isn't always obvious if an image
file is going to be float or not.

-Brendan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150706/5479dcca/attachment.html>

From matthew.brett at gmail.com  Mon Jul  6 23:19:07 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Mon, 6 Jul 2015 22:19:07 +0100
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <559AD3C8.8020202@inria.fr>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
 <559AD3C8.8020202@inria.fr>
Message-ID: <CAH6Pt5qU7E+vNzTdmUROD9-N6h7kPuYdC_uMMiU_SF3=CyHupg@mail.gmail.com>

On Mon, Jul 6, 2015 at 8:15 PM, bthirion <bertrand.thirion at inria.fr> wrote:
>
>
> On 06/07/2015 18:37, Matthew Brett wrote:
>>
>> On Mon, Jul 6, 2015 at 5:32 PM, Bertrand Thirion
>> <bertrand.thirion at inria.fr> wrote:
>>>
>>> +1 we (and more importantly, our students)  should rely as much as
>>> possible
>>> on the standard behavior of numpy arrays and make adequate decisions,
>>> rather
>>> than having to figure out the details of the API of neuroimaging
>>> libraries.
>>> So the defaut should be unchanged.
>>
>> Your reasoning implies the opposite.   Numpy tries very hard not to
>> return arrays of unknown or unpredictable data types, and that is the
>> situation we have here.   The returned datatype from a nibabel image
>> is essentially arbitrary, in that very few sources of nifti files
>> place any weight on whether there are non-default scalefactors or not.
>> At the moment, we do, depend on this, silently, and that is extremely
>> confusing, and quite contrary to the standard numpy way,
>
> Sorry for being unclear, but Numpy would never force casting when loading
> data.
>
> When you get some array, you need to be aware of what it is in order to work
> with it. A mask or label image is not meant to be something on which you
> perform algebraic manipulations. Sure, you can get it wrong if you don't
> know what you're doing, but either this user has to learn it or he/she
> should consider using higher level interfaces to work with images.

`get_data()` was meant to be the higher level interface.

This argument would be a different one if it were always or even
usually true that an integer stored data type and slope of 1 and
intercept of 0 in a NIfTI signaled the intention that the data should
be treated as integers when loaded.  However, that isn't even close to
true.   Just for example, the large majority of functional images from
the scanner are int datatype with slope, intercept of 1, 0, and we
very rarely mean these to be treated as integers.

I don't think it's sensible to try and educate the users out of this
one, because I made this mistake, and I know numpy very well and wrote
the relevant code in nibabel.

I think the dtype argument is OK, it may be better than `asfloat`. It
starts becoming a little complicated having to deal with all possible
output types - for example rounding float to ints is not as
straightforward as it may seem (for example you have to clip the
output so as not to overflow the ints).

Cheers,

Matthew

From bcipolli at ucsd.edu  Mon Jul  6 23:17:32 2015
From: bcipolli at ucsd.edu (Ben Cipollini)
Date: Mon, 6 Jul 2015 14:17:32 -0700
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <5F6A858FD00E5F4A82E3206D2D854EF87F741E3E@EXMB10.ohsu.edu>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
 <559AD3C8.8020202@inria.fr>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741DC0@EXMB10.ohsu.edu>
 <CAE_wbFvfHYgFvCV_1-K6uG8KL0RHgDjhD6kixqObd7DiAtQvrw@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741E3E@EXMB10.ohsu.edu>
Message-ID: <CANgTvZjqTX2oqt3EZ98Z=CrA7mXF=PWtKbT=Rz6gdvV8D9-0zw@mail.gmail.com>

I think it's clear that to an end-user, what data you get out of an image
file may be unclear. Sounds like there's support for enabling a dtype
argument, which allows explicit casting (and pointed documentation to tell
users that you may not know what data type that comes out of load with
dtype=None).

The discussion seems to be about what the best default behavior would be.
Right now, seems to me that dtype=None would be the best default. Here's
why:

   - If users are very unaware of numpy, they're unlikely to be doing the
   types of numeric operations on raw data that @matthewbrett hit--which is
   the only real error we've come across.
   - If users are aware of numpy, then they should be familiar with the
   need to type-cast loaded data. Plus, the documentation will tell them that
   when documenting the dtype arg. Now, they'll have an easy way to be
   safe--pass an explicit type.

The advantages of this approach are:

   - No warnings! Warnings are confusing for new users.
   - Full backwards compatibility--no migrations.
   - Everybody can do everything they need to do.
   - Users will be clearly notified in the documentation about how loading
   data may return any data type, and that they should pass dtype if they need
   a specific type.

I still don't see a strong case for confusions and errors. I'm usually the
advocate for naive users--since I've been one most of my time here :) But
in this case, I feel we'd be playing to a crowd (naive users who haven't
read the documentation and are trying to do things over their heads) that I
don't want to code for, and there are other ways to deal with the one error
we've actually seen (numpy.seterr()).


On Mon, Jul 6, 2015 at 1:50 PM, Brendan Moloney <moloney at ohsu.edu> wrote:

>  > Well, unless I am mistaken, there is no ambiguity in the
> > datatype of a binary file.
>
> I guess you mean a .npy file?  A plain binary file is nothing
> but ambiguity.
>
> > Plus,  numpy does not enforce anything, it is just a
> > default value.
>
> The latest proposition that I am running with is to include
> a 'dtype' keyword for nibabel.load. I guess Matthew would
> argue the default value should be float, and I am really
> starting to agree with that point of view.
>
> > Using np.genfromtxt(dtype=None), and you get a more
> > logical behavior.
>
> $ cat testfile
> 1 2 3 4 5
> 1 2.2 3 4 5
>
> $ python -c 'from numpy import genfromtxt ; print genfromtxt("testfile",
> dtype=None)'
> [(1, 2.0, 3, 4, 5) (1, 2.2000000000000002, 3, 4, 5)]
>
> I don't find this behavior to be particularly logical. I guess
> there is a reason the default is 'float'.
>
> > Whatever you do, if you load a npy file using np.load,
> > it will always be of the type saved in the first place.
>
> Because it is a nice clean file format they control entirely.
>
>  > Also, numpy does not have to deal with the weirdness of using
>> > integers plus scale factors to represent floating point data.
>>
>
>  > Well, in that case, why not adding a dtype value in the header ?
>
> Because nibabel tries to load a bunch of formats that we have little
> to no control over. Even in Nifti files where there is an "intent code"
> that could be set to NIFTI_INTENT_LABEL for label files, I don't
> think any software actually does this. Even if some software does,
> we can't rely on it.
>
>  > Even without scale factors the data in an
>> > MRI isn't inherently integer data, it was just quantized that way for
>> > efficiency.
>>
>
>  > Except that Nifti can store other things than MRI data (such as masks,
> > labels, or any voxel-related value).
>
> I clearly acknowledged that in the next paragraph (which you trimmed),
> and you don't address the fact that is almost always obvious from
> context if the file is a mask/label. It isn't always obvious if an image
> file is going to be float or not.
>
> -Brendan
>
>
> _______________________________________________
> 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/20150706/7f4955e8/attachment-0001.html>

From abraham.alexandre at gmail.com  Mon Jul  6 23:25:22 2015
From: abraham.alexandre at gmail.com (Alexandre ABRAHAM)
Date: Mon, 6 Jul 2015 23:25:22 +0200
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <5F6A858FD00E5F4A82E3206D2D854EF87F741E3E@EXMB10.ohsu.edu>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
 <559AD3C8.8020202@inria.fr>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741DC0@EXMB10.ohsu.edu>
 <CAE_wbFvfHYgFvCV_1-K6uG8KL0RHgDjhD6kixqObd7DiAtQvrw@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741E3E@EXMB10.ohsu.edu>
Message-ID: <CAE_wbFukWyB2T-yR8jnyzRoiXEO6ojKwbE3vZXGuAYw2BDZz6A@mail.gmail.com>

> I don't find this behavior to be particularly logical. I guess
> there is a reason the default is 'float'.
>

For example, if the first column is an index, casting it to float makes no
sense.


> Because it is a nice clean file format they control entirely.
>

Yes. So they could have casted all data to float if they wanted to, but
they didn't.


>   I clearly acknowledged that in the next paragraph (which you trimmed),
> and you don't address the fact that is almost always obvious from
> context if the file is a mask/label. It isn't always obvious if an image
> file is going to be float or not.
>

Well the context is also obvious when you load MRI data, just cast it to
float in all cases. And no, it's not simple to pass a dtype when loading a
mask. If an image is contains float values between 0 and 2, casting it to
int will round the values to 0 and 1, ie a valid mask. But clearly, the
file loaded was not meant to be used as a mask in the first place.

Alex.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150706/e9935d1a/attachment.html>

From matthew.brett at gmail.com  Mon Jul  6 23:29:09 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Mon, 6 Jul 2015 22:29:09 +0100
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CANgTvZjqTX2oqt3EZ98Z=CrA7mXF=PWtKbT=Rz6gdvV8D9-0zw@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
 <559AD3C8.8020202@inria.fr>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741DC0@EXMB10.ohsu.edu>
 <CAE_wbFvfHYgFvCV_1-K6uG8KL0RHgDjhD6kixqObd7DiAtQvrw@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741E3E@EXMB10.ohsu.edu>
 <CANgTvZjqTX2oqt3EZ98Z=CrA7mXF=PWtKbT=Rz6gdvV8D9-0zw@mail.gmail.com>
Message-ID: <CAH6Pt5qStwrbQhLLzRysPsVzRfo7Wm1HCBJJL1r8DSK713nZSg@mail.gmail.com>

Hi,

On Mon, Jul 6, 2015 at 10:17 PM, Ben Cipollini <bcipolli at ucsd.edu> wrote:
> I think it's clear that to an end-user, what data you get out of an image
> file may be unclear. Sounds like there's support for enabling a dtype
> argument, which allows explicit casting (and pointed documentation to tell
> users that you may not know what data type that comes out of load with
> dtype=None).
>
> The discussion seems to be about what the best default behavior would be.

Yes, that is the main issue.

> Right now, seems to me that dtype=None would be the best default. Here's
> why:
>
> If users are very unaware of numpy, they're unlikely to be doing the types
> of numeric operations on raw data that @matthewbrett hit--which is the only
> real error we've come across.

I don't think we think things like sum or plus are advanced numpy
operations.  There's a reason this was in the first or second class in
our course.

> If users are aware of numpy, then they should be familiar with the need to
> type-cast loaded data.

I think - as Brendan implied - they would expect the data to be in a
reasonable form unless there was a good reason for it not to be.  At
the moment, there really isn't a good reason for it not to be float,
by default - whether it's int or float is usually an accident of the
way the file was written.

>  Plus, the documentation will tell them that when
> documenting the dtype arg. Now, they'll have an easy way to be safe--pass an
> explicit type.

But that is the kind of thing I'd expect an advanced user to pick up.

> I still don't see a strong case for confusions and errors.

I can only repeat - I made this error myself - in a very early and
introductory class.

Cheers,

Matthew

From bobd at stanford.edu  Mon Jul  6 23:46:06 2015
From: bobd at stanford.edu (Bob Dougherty)
Date: Mon, 06 Jul 2015 14:46:06 -0700
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <5F6A858FD00E5F4A82E3206D2D854EF87F741E3E@EXMB10.ohsu.edu>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
 <559AD3C8.8020202@inria.fr>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741DC0@EXMB10.ohsu.edu>,
 <CAE_wbFvfHYgFvCV_1-K6uG8KL0RHgDjhD6kixqObd7DiAtQvrw@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741E3E@EXMB10.ohsu.edu>
Message-ID: <559AF71E.4060502@stanford.edu>

Hi All,

I've been silently enjoying this thread, and now that the dust appears 
to be settling I'll offer my humble opinion:

1. I definitely like the dtype option over the other alternatives proposed

2. I agree that the choice of default behavior is challenging, and want 
to reinforce what Brendan says here-- nifti is a bit messy and there is 
very often no clear answer as to what the returned type should be. I 
guess I am also slowly coming around to float64 as the default, and if 
you need something else you can use the dtype option.

3. and just to be nit-picky... the raw MR k-space data are actually 
16-bit integers (that's what the ADCs return). So there is some logic 
behind keeping MR data represented with 16-bit integers, even after the 
image reconstruction (which is indeed a floating-point computation).

cheers,
bob

On 07/06/2015 01:50 PM, Brendan Moloney wrote:
> > Well, unless I am mistaken, there is no ambiguity in the
> > datatype of a binary file.
>
> I guess you mean a .npy file?  A plain binary file is nothing
> but ambiguity.
>
> > Plus,  numpy does not enforce anything, it is just a
> > default value.
>
> The latest proposition that I am running with is to include
> a 'dtype' keyword for nibabel.load. I guess Matthew would
> argue the default value should be float, and I am really
> starting to agree with that point of view.
>
> > Using np.genfromtxt(dtype=None), and you get a more
> > logical behavior.
>
> $ cat testfile
> 1 2 3 4 5
> 1 2.2 3 4 5
>
> $ python -c 'from numpy import genfromtxt ; print 
> genfromtxt("testfile", dtype=None)'
> [(1, 2.0, 3, 4, 5) (1, 2.2000000000000002, 3, 4, 5)]
>
> I don't find this behavior to be particularly logical. I guess
> there is a reason the default is 'float'.
>
> > Whatever you do, if you load a npy file using np.load,
> > it will always be of the type saved in the first place.
>
> Because it is a nice clean file format they control entirely.
>
>     > Also, numpy does not have to deal with the weirdness of using
>     > integers plus scale factors to represent floating point data.
>
>
> > Well, in that case, why not adding a dtype value in the header ?
>
> Because nibabel tries to load a bunch of formats that we have little
> to no control over. Even in Nifti files where there is an "intent code"
> that could be set to NIFTI_INTENT_LABEL for label files, I don't
> think any software actually does this. Even if some software does,
> we can't rely on it.
>
>     > Even without scale factors the data in an
>     > MRI isn't inherently integer data, it was just quantized that
>     way for
>     > efficiency.
>
>
> > Except that Nifti can store other things than MRI data (such as masks,
> > labels, or any voxel-related value).
>
> I clearly acknowledged that in the next paragraph (which you trimmed),
> and you don't address the fact that is almost always obvious from
> context if the file is a mask/label. It isn't always obvious if an image
> file is going to be float or not.
>
> -Brendan
>
>
>
> _______________________________________________
> Neuroimaging mailing list
> Neuroimaging at python.org
> https://mail.python.org/mailman/listinfo/neuroimaging

-- 
Robert F. Dougherty, PhD
Research Director
Stanford Center for Cognitive and Neurobiological Imaging
70 Jordan Hall  *  Stanford CA 94305  *  650-725-0051
http://www.stanford.edu/~bobd

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150706/acbeb126/attachment-0001.html>

From moloney at ohsu.edu  Mon Jul  6 23:33:54 2015
From: moloney at ohsu.edu (Brendan Moloney)
Date: Mon, 6 Jul 2015 21:33:54 +0000
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAH6Pt5qU7E+vNzTdmUROD9-N6h7kPuYdC_uMMiU_SF3=CyHupg@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
 <559AD3C8.8020202@inria.fr>,
 <CAH6Pt5qU7E+vNzTdmUROD9-N6h7kPuYdC_uMMiU_SF3=CyHupg@mail.gmail.com>
Message-ID: <5F6A858FD00E5F4A82E3206D2D854EF87F741E91@EXMB10.ohsu.edu>

> I think the dtype argument is OK, it may be better than `asfloat`. It
> starts becoming a little complicated having to deal with all possible
> output types - for example rounding float to ints is not as
> straightforward as it may seem (for example you have to clip the
> output so as not to overflow the ints).

I think it is fine, maybe even preferable, to raise an exception is these
situations. Even then I agree that it complicates things.

-Brendan

From matthew.brett at gmail.com  Mon Jul  6 23:54:28 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Mon, 6 Jul 2015 22:54:28 +0100
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <5F6A858FD00E5F4A82E3206D2D854EF87F741E91@EXMB10.ohsu.edu>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
 <559AD3C8.8020202@inria.fr>
 <CAH6Pt5qU7E+vNzTdmUROD9-N6h7kPuYdC_uMMiU_SF3=CyHupg@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741E91@EXMB10.ohsu.edu>
Message-ID: <CAH6Pt5p=qGuJ7m0d5bd3rAv92FqZgLSeuDhK7e1--PWLtXBa4w@mail.gmail.com>

On Mon, Jul 6, 2015 at 10:33 PM, Brendan Moloney <moloney at ohsu.edu> wrote:
>> I think the dtype argument is OK, it may be better than `asfloat`. It
>> starts becoming a little complicated having to deal with all possible
>> output types - for example rounding float to ints is not as
>> straightforward as it may seem (for example you have to clip the
>> output so as not to overflow the ints).
>
> I think it is fine, maybe even preferable, to raise an exception is these
> situations. Even then I agree that it complicates things.

I suppose it is possible to argue that

data = img.get_data(asfloat=False).astype(np.float32)

or

data = np.array(img.dataobj).astype(np.float32)

is not too bad for the float32 case, given that it is a little specialized.

Matthew

From moloney at ohsu.edu  Tue Jul  7 00:04:28 2015
From: moloney at ohsu.edu (Brendan Moloney)
Date: Mon, 6 Jul 2015 22:04:28 +0000
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAE_wbFukWyB2T-yR8jnyzRoiXEO6ojKwbE3vZXGuAYw2BDZz6A@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
 <559AD3C8.8020202@inria.fr>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741DC0@EXMB10.ohsu.edu>
 <CAE_wbFvfHYgFvCV_1-K6uG8KL0RHgDjhD6kixqObd7DiAtQvrw@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741E3E@EXMB10.ohsu.edu>,
 <CAE_wbFukWyB2T-yR8jnyzRoiXEO6ojKwbE3vZXGuAYw2BDZz6A@mail.gmail.com>
Message-ID: <5F6A858FD00E5F4A82E3206D2D854EF87F741EB3@EXMB10.ohsu.edu>


> For example, if the first column is an index, casting it to float makes no sense.

And if the first row provides indices the given result makes no sense. If you are
going to appeal to the authority of numpy you should recognize that their
default policy appears to be "when in doubt use floats".

> Yes. So they could have casted all data to float if they wanted to, but they didn't.

This is not analogous at all.

> Well the context is also obvious when you load MRI data, just cast it to float in
> all cases. And no, it's not simple to pass a dtype when loading a mask. If an
> image is contains float values between 0 and 2, casting it to int will round the
> values to 0 and 1, ie a valid mask. But clearly, the file loaded was not meant to
> be used as a mask in the first place.

So every time you load a mask you check if the values are strictly zeros and ones?
I don't. I find it useful to allow a label image to be used as a mask. What if
someone passes in the image and it is just zeros and ones?  Do you raise an
exception because you are guessing they accidentally passed in a mask instead
of the image?

If you passed an integer dtype to 'nibabel.load' and the file has scaling factors, we
could raise an exception. So your use case might actually be an argument for this
proposal rather than against it.

If this proposal goes through, and the default for 'dtype' becomes float, the only
time you will need to pass the 'dtype' will be:

1) You know the image is providing a mask or labels from context

2) You want to save memory and know what you are doing

Without this proposal you need to cast everything to float except for the above
cases, which seems worse to me (ignoring the argument for novices).


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

From moloney at ohsu.edu  Tue Jul  7 00:11:40 2015
From: moloney at ohsu.edu (Brendan Moloney)
Date: Mon, 6 Jul 2015 22:11:40 +0000
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <5F6A858FD00E5F4A82E3206D2D854EF87F741EB3@EXMB10.ohsu.edu>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
 <559AD3C8.8020202@inria.fr>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741DC0@EXMB10.ohsu.edu>
 <CAE_wbFvfHYgFvCV_1-K6uG8KL0RHgDjhD6kixqObd7DiAtQvrw@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741E3E@EXMB10.ohsu.edu>,
 <CAE_wbFukWyB2T-yR8jnyzRoiXEO6ojKwbE3vZXGuAYw2BDZz6A@mail.gmail.com>,
 <5F6A858FD00E5F4A82E3206D2D854EF87F741EB3@EXMB10.ohsu.edu>
Message-ID: <5F6A858FD00E5F4A82E3206D2D854EF87F741EC7@EXMB10.ohsu.edu>

Argh, replace 'nibabel.load' with 'img.get_data'.

________________________________
From: Neuroimaging [neuroimaging-bounces+moloney=ohsu.edu at python.org] on behalf of Brendan Moloney [moloney at ohsu.edu]
Sent: Monday, July 06, 2015 3:04 PM
To: Neuroimaging analysis in Python
Subject: Re: [Neuroimaging] Nibabel API change - always read as float


> For example, if the first column is an index, casting it to float makes no sense.

And if the first row provides indices the given result makes no sense. If you are
going to appeal to the authority of numpy you should recognize that their
default policy appears to be "when in doubt use floats".

> Yes. So they could have casted all data to float if they wanted to, but they didn't.

This is not analogous at all.

> Well the context is also obvious when you load MRI data, just cast it to float in
> all cases. And no, it's not simple to pass a dtype when loading a mask. If an
> image is contains float values between 0 and 2, casting it to int will round the
> values to 0 and 1, ie a valid mask. But clearly, the file loaded was not meant to
> be used as a mask in the first place.

So every time you load a mask you check if the values are strictly zeros and ones?
I don't. I find it useful to allow a label image to be used as a mask. What if
someone passes in the image and it is just zeros and ones?  Do you raise an
exception because you are guessing they accidentally passed in a mask instead
of the image?

If you passed an integer dtype to 'nibabel.load' and the file has scaling factors, we
could raise an exception. So your use case might actually be an argument for this
proposal rather than against it.

If this proposal goes through, and the default for 'dtype' becomes float, the only
time you will need to pass the 'dtype' will be:

1) You know the image is providing a mask or labels from context

2) You want to save memory and know what you are doing

Without this proposal you need to cast everything to float except for the above
cases, which seems worse to me (ignoring the argument for novices).


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150706/05cb263e/attachment-0001.html>

From gael.varoquaux at normalesup.org  Tue Jul  7 00:12:53 2015
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Tue, 7 Jul 2015 00:12:53 +0200
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
Message-ID: <20150706221253.GA2951906@phare.normalesup.org>

On Mon, Jul 06, 2015 at 05:13:00PM +0100, Matthew Brett wrote:
> I did precisely run into this when teaching the students.  I was
> teaching them to run diagnostics, and the script I wrote used the sum.
> This worked fine on one set of functional images, but gave a
> completely wrong answer on another set of images, and it took me a
> little while to work out what had gone wrong.  Part of the problem is
> that nifti images are often int16, so it's easy to run into silent
> horrors just by adding or subtracting. 

But that's standard: operating on data requires to be aware of this.
Converting to float just moves the goal post.

> My feeling is that dealing with any operations on int16 arrays is for
> advanced users. 

My feeling is that doing such numerical operations on data is for
advanced users. Basic users should just be using libraries that operate
on images, and not implement the operations themselves. By converting
everything to float, you are making the job of these libraries harder. If
these libraries are doing numerical operations that might overflow (any
kind of numerical calculs, actually), they need to convert to float. If
they are using the data to do masking, or for ROIs defined by integer
values, they should.

I have the impression that we are regressing to matlab world, where
everything can only be floats, or you will get weird bugs/

From abraham.alexandre at gmail.com  Tue Jul  7 00:22:47 2015
From: abraham.alexandre at gmail.com (Alexandre ABRAHAM)
Date: Tue, 7 Jul 2015 00:22:47 +0200
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <5F6A858FD00E5F4A82E3206D2D854EF87F741EB3@EXMB10.ohsu.edu>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
 <559AD3C8.8020202@inria.fr>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741DC0@EXMB10.ohsu.edu>
 <CAE_wbFvfHYgFvCV_1-K6uG8KL0RHgDjhD6kixqObd7DiAtQvrw@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741E3E@EXMB10.ohsu.edu>
 <CAE_wbFukWyB2T-yR8jnyzRoiXEO6ojKwbE3vZXGuAYw2BDZz6A@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741EB3@EXMB10.ohsu.edu>
Message-ID: <CAE_wbFtYKANTM5CedoEYQoqQU-GmoiSGfCBkceX=qnp3MivvDA@mail.gmail.com>

> > Yes. So they could have casted all data to float if they wanted to, but
> they didn't.
>
> This is not analogous at all.
>

You just compared loading of Nifti files, which are binary, to loading of
text files. So I consider my comparison of npy binary files to Nifti files
as analagous.



> So every time you load a mask you check if the values are strictly zeros
> and ones?
>

Yes, this is basic error handling for non-technical users.

I don't. I find it useful to allow a label image to be used as a mask. What
> if
> someone passes in the image and it is just zeros and ones?  Do you raise
> an
> exception because you are guessing they accidentally passed in a mask
> instead
> of the image?
>

In our lib, mask images must have 2 values, one of them being 0. The MRI
images live in a wider space, but they can be binary. Actually, a value may
be raised because we work with function MRI that must be 4D in most cases.


> If you passed an integer dtype to 'nibabel.load' and the file has scaling
> factors, we
> could raise an exception. So your use case might actually be an argument
> for this
> proposal rather than against it.
>

I don't see your point here.


> 1) You know the image is providing a mask or labels from context
>

As said before, implicit cast won't work in that case.


> 2) You want to save memory and know what you are doing
>

Agreed.


> Without this proposal you need to cast everything to float except for the
> above
> cases, which seems worse to me (ignoring the argument for novices).
>

No, I don't have to cast everything to float. I only cast MRI images to
float when it is needed.

Honestly, I don't see the point in convincing people that your choice is
the good one. In my usecases, it is clearly not. Whatever choice is made, I
will just deal with it.

Alex.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150707/a8641307/attachment.html>

From moloney at ohsu.edu  Tue Jul  7 01:08:30 2015
From: moloney at ohsu.edu (Brendan Moloney)
Date: Mon, 6 Jul 2015 23:08:30 +0000
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAE_wbFtYKANTM5CedoEYQoqQU-GmoiSGfCBkceX=qnp3MivvDA@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
 <559AD3C8.8020202@inria.fr>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741DC0@EXMB10.ohsu.edu>
 <CAE_wbFvfHYgFvCV_1-K6uG8KL0RHgDjhD6kixqObd7DiAtQvrw@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741E3E@EXMB10.ohsu.edu>
 <CAE_wbFukWyB2T-yR8jnyzRoiXEO6ojKwbE3vZXGuAYw2BDZz6A@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741EB3@EXMB10.ohsu.edu>,
 <CAE_wbFtYKANTM5CedoEYQoqQU-GmoiSGfCBkceX=qnp3MivvDA@mail.gmail.com>
Message-ID: <5F6A858FD00E5F4A82E3206D2D854EF87F741EEC@EXMB10.ohsu.edu>


> You just compared loading of Nifti files, which are binary, to loading
> of text files. So I consider my comparison of npy binary files to Nifti
> files as analagous.

I was comparing two situations where the intended data type is unclear.
The only time this comes up for data loading in numpy is text files. But
you could also look at all the numpy array creation routines which
default to float64 (at least for most people). Clearly the numpy
developers prefer to avoid overflow issues rather than improve
efficiency by default.

> Yes, this is basic error handling for non-technical users.

So I guess you have some function like 'check_mask' that enforces this
check? You could add a check for the scale factors in there too.

> If you passed an integer dtype to 'nibabel.load' and the file has scaling factors, we
> could raise an exception. So your use case might actually be an argument for this
> proposal rather than against it.

> I don't see your point here.

I am not 100% sure it is the right thing to do, but we could raise an
exception when someone asks for integer output and the file is clearly
meant to contain floating point data (i.e. the intercept/scale factors are
not 0/1). After all, they could still access the raw values through the
'dataobj'. This avoids the issue you mentioned, although you could
easily add some extra checks yourself (as mentioned above).

> 1) You know the image is providing a mask or labels from context

> As said before, implicit cast won't work in that case.

It would be an explicit cast and I am not convinced there is any issue
here. Again, see above.

> 2) You want to save memory and know what you are doing

> Agreed.

To be even more specific: You want to save memory, you know what
you are doing, and you know the operations you are going to perform
will not overflow the requested dtype.

> Without this proposal you need to cast everything to float except for the above
> cases, which seems worse to me (ignoring the argument for novices).

> No, I don't have to cast everything to float. I only cast MRI images
> to float when it is needed.

I think people need float data more often than not, but obviously that
depends on what you do with nibabel. Any default will be annoying to
some users. I tend to pass 'dtype=np.float32' into a lot of numpy routines
because I don't need the extra precision but do need to speed up
calculations and save RAM. This might even be the case for the majority
of numpy users, but I recognize that it is still a good default (premature
optimization and all that...).

> Honestly, I don't see the point in convincing people that your choice is
> the good one. In my usecases, it is clearly not. Whatever choice is made,
> I will just deal with it.

Sorry, I could be a bit more diplomatic some times. I don't mean to
discourage anyone from participating in the conversation.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150706/29163ae5/attachment-0001.html>

From gael.varoquaux at normalesup.org  Tue Jul  7 01:14:59 2015
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Tue, 7 Jul 2015 01:14:59 +0200
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CANgTvZjxsEVrpqC-ioPBHJiVCZkh1VRutpXwS9zFAy4Q4M31xA@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
 <CANgTvZjxsEVrpqC-ioPBHJiVCZkh1VRutpXwS9zFAy4Q4M31xA@mail.gmail.com>
Message-ID: <20150706231459.GA2967360@phare.normalesup.org>

On Mon, Jul 06, 2015 at 09:56:35AM -0700, Ben Cipollini wrote:
> How about accepting a dtype parameter, with None meaning using the type
> determined from load (i.e. current behavior)?

+1. Sounds about right.

G

From abraham.alexandre at gmail.com  Tue Jul  7 01:19:52 2015
From: abraham.alexandre at gmail.com (Alexandre ABRAHAM)
Date: Tue, 7 Jul 2015 01:19:52 +0200
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <5F6A858FD00E5F4A82E3206D2D854EF87F741EEC@EXMB10.ohsu.edu>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
 <559AD3C8.8020202@inria.fr>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741DC0@EXMB10.ohsu.edu>
 <CAE_wbFvfHYgFvCV_1-K6uG8KL0RHgDjhD6kixqObd7DiAtQvrw@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741E3E@EXMB10.ohsu.edu>
 <CAE_wbFukWyB2T-yR8jnyzRoiXEO6ojKwbE3vZXGuAYw2BDZz6A@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741EB3@EXMB10.ohsu.edu>
 <CAE_wbFtYKANTM5CedoEYQoqQU-GmoiSGfCBkceX=qnp3MivvDA@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741EEC@EXMB10.ohsu.edu>
Message-ID: <CAE_wbFucDuSjpuMYRPAFxqYXKgWv_cNgWwjKAMcbHVu_+KNrHQ@mail.gmail.com>

On Tue, Jul 7, 2015 at 1:08 AM, Brendan Moloney <moloney at ohsu.edu> wrote:

>    Sorry, I could be a bit more diplomatic some times. I don't mean to
> discourage anyone from participating in the conversation.
>

Don't worry, you were diplomatic enough ;). What I meant is that we clearly
have two sides here: people who consider nifti data as intrinsically float,
and people who think that the type is actually meaningful. There is no
chance that one side changes the other side's view. I rested my case and I
think that I have nothing more to add to the conversation.

dtype is fine for me, and I'd like to be None by default.

Alex.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150707/10e5cf9a/attachment.html>

From gael.varoquaux at normalesup.org  Tue Jul  7 01:22:29 2015
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Tue, 7 Jul 2015 01:22:29 +0200
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAH6Pt5qU7E+vNzTdmUROD9-N6h7kPuYdC_uMMiU_SF3=CyHupg@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
 <559AD3C8.8020202@inria.fr>
 <CAH6Pt5qU7E+vNzTdmUROD9-N6h7kPuYdC_uMMiU_SF3=CyHupg@mail.gmail.com>
Message-ID: <20150706232229.GB2967360@phare.normalesup.org>

On Mon, Jul 06, 2015 at 10:19:07PM +0100, Matthew Brett wrote:
> > When you get some array, you need to be aware of what it is in order to work
> > with it. A mask or label image is not meant to be something on which you
> > perform algebraic manipulations. Sure, you can get it wrong if you don't
> > know what you're doing, but either this user has to learn it or he/she
> > should consider using higher level interfaces to work with images.

> `get_data()` was meant to be the higher level interface.

It's not: it's comming down to the numbers behind the data. When you go
down that far, you need to know what they mean.

Tools in dipy / nistats / nilearn that have a context of what is the
semantic meaning of the data are the higher-level building blocks.

> This argument would be a different one if it were always or even
> usually true that an integer stored data type and slope of 1 and
> intercept of 0 in a NIfTI signaled the intention that the data should
> be treated as integers when loaded.  However, that isn't even close to
> true.   Just for example, the large majority of functional images from
> the scanner are int datatype with slope, intercept of 1, 0, and we
> very rarely mean these to be treated as integers.

And we always convert data to float in functions that obviously work on
continous-valued data. But in a masking function, we would have to do
convert data the opposite way.

Where it get nasty is: what if the data has undergone a spatial
transformation? The original integer values are then interpolated to
intermediate values. What is then the right thing to do?

> I don't think it's sensible to try and educate the users out of this
> one, because I made this mistake, and I know numpy very well and wrote
> the relevant code in nibabel.

The way I avoid such errors is that I use higher-level abstraction.
That's something where we can win a battle. Any battle on low-level code
will be lost.

Ga?l

From njvack at wisc.edu  Tue Jul  7 01:24:51 2015
From: njvack at wisc.edu (Nate Vack)
Date: Mon, 06 Jul 2015 23:24:51 +0000
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAH6Pt5qStwrbQhLLzRysPsVzRfo7Wm1HCBJJL1r8DSK713nZSg@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
 <559AD3C8.8020202@inria.fr>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741DC0@EXMB10.ohsu.edu>
 <CAE_wbFvfHYgFvCV_1-K6uG8KL0RHgDjhD6kixqObd7DiAtQvrw@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741E3E@EXMB10.ohsu.edu>
 <CANgTvZjqTX2oqt3EZ98Z=CrA7mXF=PWtKbT=Rz6gdvV8D9-0zw@mail.gmail.com>
 <CAH6Pt5qStwrbQhLLzRysPsVzRfo7Wm1HCBJJL1r8DSK713nZSg@mail.gmail.com>
Message-ID: <CA+1BpOsHYEidXn7BEQWsVBb=CvXy3s-b0fqH6fJ2jPz00QZm0A@mail.gmail.com>

On Mon, Jul 6, 2015 at 4:30 PM Matthew Brett <matthew.brett at gmail.com>
wrote:


> I don't think we think things like sum or plus are advanced numpy
> operations.  There's a reason this was in the first or second class in
> our course.


This is the argument that brings me around. Loading images and doing sums
and averages (or running a linear model) should not be "advanced"
operations -- they're actually very simple and should be introductory
operations. One of the things nibabel can really help with is demystifying
imaging processing and analysis.

Anyhow, *I've* been bitten by integer overflow and clamping problems in
nifti processing. It's super easy to forget about for a second.

In a lot of ways, casting nifti images to float by default is analogous to
python changing / to floating-point division in py3.

+1 on adding dtype to get_data(), defaulting it to np.float64, and raising
an exception if you do something that will hork up the data conversion.

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

From mwaskom at stanford.edu  Tue Jul  7 01:24:33 2015
From: mwaskom at stanford.edu (Michael Waskom)
Date: Mon, 6 Jul 2015 16:24:33 -0700
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAE_wbFucDuSjpuMYRPAFxqYXKgWv_cNgWwjKAMcbHVu_+KNrHQ@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
 <559AD3C8.8020202@inria.fr>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741DC0@EXMB10.ohsu.edu>
 <CAE_wbFvfHYgFvCV_1-K6uG8KL0RHgDjhD6kixqObd7DiAtQvrw@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741E3E@EXMB10.ohsu.edu>
 <CAE_wbFukWyB2T-yR8jnyzRoiXEO6ojKwbE3vZXGuAYw2BDZz6A@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741EB3@EXMB10.ohsu.edu>
 <CAE_wbFtYKANTM5CedoEYQoqQU-GmoiSGfCBkceX=qnp3MivvDA@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741EEC@EXMB10.ohsu.edu>
 <CAE_wbFucDuSjpuMYRPAFxqYXKgWv_cNgWwjKAMcbHVu_+KNrHQ@mail.gmail.com>
Message-ID: <CAKZ-Uq2_06y0sLHA+sPBrXVTuoDSpt=Aiz1BLHNaPuny4L_3SA@mail.gmail.com>

On Mon, Jul 6, 2015 at 4:19 PM, Alexandre ABRAHAM <
abraham.alexandre at gmail.com> wrote:

>
> Don't worry, you were diplomatic enough ;). What I meant is that we
> clearly have two sides here: people who consider nifti data as
> intrinsically float, and people who think that the type is actually
> meaningful. There is no chance that one side changes the other side's view.
>

I don't think the people in favor of Matthew's proposal are saying this. I
think they are saying that the negatives of `dtype=None` (serious, silent
failures) outweigh the negatives of `dtype=float` (people who want to do
something specific have to pass an explicit parameter in their code).

Perhaps you would frame that different, but I'm confused at the extent to
which people seem to be talking past each other.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150706/eec0a489/attachment-0001.html>

From gael.varoquaux at normalesup.org  Tue Jul  7 01:27:44 2015
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Tue, 7 Jul 2015 01:27:44 +0200
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CA+1BpOsHYEidXn7BEQWsVBb=CvXy3s-b0fqH6fJ2jPz00QZm0A@mail.gmail.com>
References: <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
 <559AD3C8.8020202@inria.fr>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741DC0@EXMB10.ohsu.edu>
 <CAE_wbFvfHYgFvCV_1-K6uG8KL0RHgDjhD6kixqObd7DiAtQvrw@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741E3E@EXMB10.ohsu.edu>
 <CANgTvZjqTX2oqt3EZ98Z=CrA7mXF=PWtKbT=Rz6gdvV8D9-0zw@mail.gmail.com>
 <CAH6Pt5qStwrbQhLLzRysPsVzRfo7Wm1HCBJJL1r8DSK713nZSg@mail.gmail.com>
 <CA+1BpOsHYEidXn7BEQWsVBb=CvXy3s-b0fqH6fJ2jPz00QZm0A@mail.gmail.com>
Message-ID: <20150706232744.GD2967360@phare.normalesup.org>

On Mon, Jul 06, 2015 at 11:24:51PM +0000, Nate Vack wrote:
> Anyhow, *I've* been bitten by integer overflow and clamping problems in nifti
> processing. It's super easy to forget about for a second.

You cannot do numerics without being aware of dtype and overflow.
Seriously.

G

From matthew.brett at gmail.com  Tue Jul  7 01:27:35 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Tue, 7 Jul 2015 00:27:35 +0100
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAE_wbFucDuSjpuMYRPAFxqYXKgWv_cNgWwjKAMcbHVu_+KNrHQ@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
 <559AD3C8.8020202@inria.fr>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741DC0@EXMB10.ohsu.edu>
 <CAE_wbFvfHYgFvCV_1-K6uG8KL0RHgDjhD6kixqObd7DiAtQvrw@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741E3E@EXMB10.ohsu.edu>
 <CAE_wbFukWyB2T-yR8jnyzRoiXEO6ojKwbE3vZXGuAYw2BDZz6A@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741EB3@EXMB10.ohsu.edu>
 <CAE_wbFtYKANTM5CedoEYQoqQU-GmoiSGfCBkceX=qnp3MivvDA@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741EEC@EXMB10.ohsu.edu>
 <CAE_wbFucDuSjpuMYRPAFxqYXKgWv_cNgWwjKAMcbHVu_+KNrHQ@mail.gmail.com>
Message-ID: <CAH6Pt5oZmnK2mvSUzSq_hfts5D0NfNEXdQuEoHsKzSjbH6p8fg@mail.gmail.com>

On Tue, Jul 7, 2015 at 12:19 AM, Alexandre ABRAHAM
<abraham.alexandre at gmail.com> wrote:
> On Tue, Jul 7, 2015 at 1:08 AM, Brendan Moloney <moloney at ohsu.edu> wrote:
>>
>> Sorry, I could be a bit more diplomatic some times. I don't mean to
>> discourage anyone from participating in the conversation.
>
>
> Don't worry, you were diplomatic enough ;). What I meant is that we clearly
> have two sides here: people who consider nifti data as intrinsically float,
> and people who think that the type is actually meaningful.

I think I missed the argument for this.

Don't forget the the output dtype is not the dtype as specified in the
header, but the dtype as specified in the header then cast to float if
the slope == 1 and offset == 0.

Sometimes I suppose this might be the algorithm intended by the author
of the image, but most of the time the author had no such intention.
They usually just meant to find a good datatype to keep a smaller data
size on disk.  Do you disagree?    I can show you lots of OpenFMRI
images where I think that is clearly the case.

Cheers,

Matthew

From mwaskom at stanford.edu  Tue Jul  7 01:28:02 2015
From: mwaskom at stanford.edu (Michael Waskom)
Date: Mon, 6 Jul 2015 16:28:02 -0700
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CA+1BpOsHYEidXn7BEQWsVBb=CvXy3s-b0fqH6fJ2jPz00QZm0A@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
 <559AD3C8.8020202@inria.fr>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741DC0@EXMB10.ohsu.edu>
 <CAE_wbFvfHYgFvCV_1-K6uG8KL0RHgDjhD6kixqObd7DiAtQvrw@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741E3E@EXMB10.ohsu.edu>
 <CANgTvZjqTX2oqt3EZ98Z=CrA7mXF=PWtKbT=Rz6gdvV8D9-0zw@mail.gmail.com>
 <CAH6Pt5qStwrbQhLLzRysPsVzRfo7Wm1HCBJJL1r8DSK713nZSg@mail.gmail.com>
 <CA+1BpOsHYEidXn7BEQWsVBb=CvXy3s-b0fqH6fJ2jPz00QZm0A@mail.gmail.com>
Message-ID: <CAKZ-Uq2dSrPK5JuNQz8tp+3kt36Y7S-neLaWadrkJJFhA2aq5g@mail.gmail.com>

Also, I feel like if I were writing Python code to operate on a label
image, or when I really wanted integer typed data for efficiency reasons, I
would write `data = img.get_data(dtype=int16)` even if the default were
None, because it would make my intentions/expectations clear. But maybe
others feel differently.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150706/b2bb46a1/attachment.html>

From gael.varoquaux at normalesup.org  Tue Jul  7 01:37:05 2015
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Tue, 7 Jul 2015 01:37:05 +0200
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAKZ-Uq2dSrPK5JuNQz8tp+3kt36Y7S-neLaWadrkJJFhA2aq5g@mail.gmail.com>
References: <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
 <559AD3C8.8020202@inria.fr>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741DC0@EXMB10.ohsu.edu>
 <CAE_wbFvfHYgFvCV_1-K6uG8KL0RHgDjhD6kixqObd7DiAtQvrw@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741E3E@EXMB10.ohsu.edu>
 <CANgTvZjqTX2oqt3EZ98Z=CrA7mXF=PWtKbT=Rz6gdvV8D9-0zw@mail.gmail.com>
 <CAH6Pt5qStwrbQhLLzRysPsVzRfo7Wm1HCBJJL1r8DSK713nZSg@mail.gmail.com>
 <CA+1BpOsHYEidXn7BEQWsVBb=CvXy3s-b0fqH6fJ2jPz00QZm0A@mail.gmail.com>
 <CAKZ-Uq2dSrPK5JuNQz8tp+3kt36Y7S-neLaWadrkJJFhA2aq5g@mail.gmail.com>
Message-ID: <20150706233705.GA2986567@phare.normalesup.org>

On Mon, Jul 06, 2015 at 04:28:02PM -0700, Michael Waskom wrote:
> Also, I feel like if I were writing Python code to operate on a label image, or
> when I really wanted integer typed data for efficiency reasons, I would write
> `data = img.get_data(dtype=int16)` even if the default were None, because it
> would make my intentions/expectations clear.

The question is the following: you've written code that deal with a label
image. Some one gives you an image as an input. It's a float dtype. How
do you know whether the user loaded the wrong image, or it's just right
and the loading library did the conversion? The loss of semantics implied
by the casting makes it harder to have a good behavior / error message.

Ga?l

From gael.varoquaux at normalesup.org  Tue Jul  7 01:40:27 2015
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Tue, 7 Jul 2015 01:40:27 +0200
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAKZ-Uq2_06y0sLHA+sPBrXVTuoDSpt=Aiz1BLHNaPuny4L_3SA@mail.gmail.com>
References: <559AD3C8.8020202@inria.fr>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741DC0@EXMB10.ohsu.edu>
 <CAE_wbFvfHYgFvCV_1-K6uG8KL0RHgDjhD6kixqObd7DiAtQvrw@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741E3E@EXMB10.ohsu.edu>
 <CAE_wbFukWyB2T-yR8jnyzRoiXEO6ojKwbE3vZXGuAYw2BDZz6A@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741EB3@EXMB10.ohsu.edu>
 <CAE_wbFtYKANTM5CedoEYQoqQU-GmoiSGfCBkceX=qnp3MivvDA@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741EEC@EXMB10.ohsu.edu>
 <CAE_wbFucDuSjpuMYRPAFxqYXKgWv_cNgWwjKAMcbHVu_+KNrHQ@mail.gmail.com>
 <CAKZ-Uq2_06y0sLHA+sPBrXVTuoDSpt=Aiz1BLHNaPuny4L_3SA@mail.gmail.com>
Message-ID: <20150706234027.GE2967360@phare.normalesup.org>

On Mon, Jul 06, 2015 at 04:24:33PM -0700, Michael Waskom wrote:
> I don't think the people in favor of Matthew's proposal are saying this. I
> think they are saying that the negatives of `dtype=None` (serious, silent
> failures) outweigh the negatives of `dtype=float` (people who want to do
> something specific have to pass an explicit parameter in their code).

No: dtype=float by default will create other serious silent failures,
like the fact that round-trip save/load will change the data. This is
pretty bad behavior. Certainly not one that I would expect.

This has implication on data processing: density estimation should be
done differently on a set of continuous values than on a set of integers
(histogram vs kernel smoothing). 

Nibabel is a low-level I/O library. It has no notion of how the data is
going to be used, and should therefore do as little as possible to the
data. There are other libraries to do the rest. People using nibabel and
get_data should be aware of these things. Just like they should be aware
of floating point errors:

    In [1]: .1 + 1 - 1
    Out[1]: 0.10000000000000009

    In [2]: 1 - 1 + .1
    Out[2]: 0.1

Trying to find rules to mitigate problems of arithmetics on computers is
bound to fail: the problems are not solvable, unless with know something
about of the numbers are going to be used.

Ga?l

From mwaskom at stanford.edu  Tue Jul  7 01:30:47 2015
From: mwaskom at stanford.edu (Michael Waskom)
Date: Mon, 6 Jul 2015 16:30:47 -0700
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <20150706232744.GD2967360@phare.normalesup.org>
References: <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
 <559AD3C8.8020202@inria.fr>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741DC0@EXMB10.ohsu.edu>
 <CAE_wbFvfHYgFvCV_1-K6uG8KL0RHgDjhD6kixqObd7DiAtQvrw@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741E3E@EXMB10.ohsu.edu>
 <CANgTvZjqTX2oqt3EZ98Z=CrA7mXF=PWtKbT=Rz6gdvV8D9-0zw@mail.gmail.com>
 <CAH6Pt5qStwrbQhLLzRysPsVzRfo7Wm1HCBJJL1r8DSK713nZSg@mail.gmail.com>
 <CA+1BpOsHYEidXn7BEQWsVBb=CvXy3s-b0fqH6fJ2jPz00QZm0A@mail.gmail.com>
 <20150706232744.GD2967360@phare.normalesup.org>
Message-ID: <CAKZ-Uq1vkp4yJLXt=j8f+y_AxP_KiP7BnhcwM7Dq6GF00xDYBw@mail.gmail.com>

On Mon, Jul 6, 2015 at 4:27 PM, Gael Varoquaux <
gael.varoquaux at normalesup.org> wrote:

> You cannot do numerics without being aware of dtype and overflow.
> Seriously.
>

Humans have limited working memory capacities. This doesn't really seem
compelling or constructive.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150706/45b291a7/attachment-0001.html>

From effigies at bu.edu  Tue Jul  7 01:45:19 2015
From: effigies at bu.edu (Christopher J Markiewicz)
Date: Mon, 06 Jul 2015 19:45:19 -0400
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAH6Pt5oZmnK2mvSUzSq_hfts5D0NfNEXdQuEoHsKzSjbH6p8fg@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
 <559AD3C8.8020202@inria.fr>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741DC0@EXMB10.ohsu.edu>
 <CAE_wbFvfHYgFvCV_1-K6uG8KL0RHgDjhD6kixqObd7DiAtQvrw@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741E3E@EXMB10.ohsu.edu>
 <CAE_wbFukWyB2T-yR8jnyzRoiXEO6ojKwbE3vZXGuAYw2BDZz6A@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741EB3@EXMB10.ohsu.edu>
 <CAE_wbFtYKANTM5CedoEYQoqQU-GmoiSGfCBkceX=qnp3MivvDA@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741EEC@EXMB10.ohsu.edu>
 <CAE_wbFucDuSjpuMYRPAFxqYXKgWv_cNgWwjKAMcbHVu_+KNrHQ@mail.gmail.com>
 <CAH6Pt5oZmnK2mvSUzSq_hfts5D0NfNEXdQuEoHsKzSjbH6p8fg@mail.gmail.com>
Message-ID: <559B130F.9000107@bu.edu>

On 07/06/2015 07:27 PM, Matthew Brett wrote:
> On Tue, Jul 7, 2015 at 12:19 AM, Alexandre ABRAHAM
> <abraham.alexandre at gmail.com> wrote:
>> On Tue, Jul 7, 2015 at 1:08 AM, Brendan Moloney <moloney at ohsu.edu> wrote:
>>>
>>> Sorry, I could be a bit more diplomatic some times. I don't mean to
>>> discourage anyone from participating in the conversation.
>>
>>
>> Don't worry, you were diplomatic enough ;). What I meant is that we clearly
>> have two sides here: people who consider nifti data as intrinsically float,
>> and people who think that the type is actually meaningful.
> 
> I think I missed the argument for this.
> 
> Don't forget the the output dtype is not the dtype as specified in the
> header, but the dtype as specified in the header then cast to float if
> the slope == 1 and offset == 0.
> 
> Sometimes I suppose this might be the algorithm intended by the author
> of the image, but most of the time the author had no such intention.
> They usually just meant to find a good datatype to keep a smaller data
> size on disk.  Do you disagree?    I can show you lots of OpenFMRI
> images where I think that is clearly the case.

It sounds like consensus is rolling around to a dtype parameter, but I'm
not entirely clear on what the semantics should be. The least surprising
interpretation would be this:

    if dtype is not None:
        np.array_equal(dtype(img.get_data()), img.get_data(dtype=dtype))

However, if the type is clearly specified in the headers and not
(uint16, m=1, b=0), would the dtype be ignored, or would we get
dtype(img.get_data())? As noted, the former would be surprising, but the
latter makes anything other than setting the default parameter to None
impossible without making the default behavior even more surprising.
Perhaps a dtype that conflicts with the header-specified type should
cause an exception?

Further, is the goal here to make this arbitrarily castable, or limited
to float64 or the header-specified datatype, as in the original proposal
of as_float?

-- 
Christopher J Markiewicz
Ph.D. Candidate, Quantitative Neuroscience Laboratory
Boston University

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150706/995751ac/attachment.sig>

From gael.varoquaux at normalesup.org  Tue Jul  7 01:56:53 2015
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Tue, 7 Jul 2015 01:56:53 +0200
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAKZ-Uq1vkp4yJLXt=j8f+y_AxP_KiP7BnhcwM7Dq6GF00xDYBw@mail.gmail.com>
References: <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
 <559AD3C8.8020202@inria.fr>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741DC0@EXMB10.ohsu.edu>
 <CAE_wbFvfHYgFvCV_1-K6uG8KL0RHgDjhD6kixqObd7DiAtQvrw@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741E3E@EXMB10.ohsu.edu>
 <CANgTvZjqTX2oqt3EZ98Z=CrA7mXF=PWtKbT=Rz6gdvV8D9-0zw@mail.gmail.com>
 <CAH6Pt5qStwrbQhLLzRysPsVzRfo7Wm1HCBJJL1r8DSK713nZSg@mail.gmail.com>
 <CA+1BpOsHYEidXn7BEQWsVBb=CvXy3s-b0fqH6fJ2jPz00QZm0A@mail.gmail.com>
 <20150706232744.GD2967360@phare.normalesup.org>
 <CAKZ-Uq1vkp4yJLXt=j8f+y_AxP_KiP7BnhcwM7Dq6GF00xDYBw@mail.gmail.com>
Message-ID: <20150706235653.GF2967360@phare.normalesup.org>

On Mon, Jul 06, 2015 at 04:30:47PM -0700, Michael Waskom wrote:
>     You cannot do numerics without being aware of dtype and overflow.
>     Seriously.

> Humans have limited working memory capacities. This doesn't really seem
> compelling or constructive.

I am just saying that it's going to fail. It is a battle that cannot be
won. I tried giving examples (round-trip saving, density estimation,
errors in floating points) of why it would fail.

Casting to floats just changes the problem, but does not solve it. And it
creates a very unusual behavior for an I/O library, which means the users
who know what they are doing will get it wrong.

G

From mwaskom at stanford.edu  Tue Jul  7 01:52:37 2015
From: mwaskom at stanford.edu (Michael Waskom)
Date: Mon, 6 Jul 2015 16:52:37 -0700
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <20150706234027.GE2967360@phare.normalesup.org>
References: <559AD3C8.8020202@inria.fr>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741DC0@EXMB10.ohsu.edu>
 <CAE_wbFvfHYgFvCV_1-K6uG8KL0RHgDjhD6kixqObd7DiAtQvrw@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741E3E@EXMB10.ohsu.edu>
 <CAE_wbFukWyB2T-yR8jnyzRoiXEO6ojKwbE3vZXGuAYw2BDZz6A@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741EB3@EXMB10.ohsu.edu>
 <CAE_wbFtYKANTM5CedoEYQoqQU-GmoiSGfCBkceX=qnp3MivvDA@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741EEC@EXMB10.ohsu.edu>
 <CAE_wbFucDuSjpuMYRPAFxqYXKgWv_cNgWwjKAMcbHVu_+KNrHQ@mail.gmail.com>
 <CAKZ-Uq2_06y0sLHA+sPBrXVTuoDSpt=Aiz1BLHNaPuny4L_3SA@mail.gmail.com>
 <20150706234027.GE2967360@phare.normalesup.org>
Message-ID: <CAKZ-Uq125RDWP6ge3Kf7bQROX79MZRHuBLUQ6Oo1J7xuPT52Kw@mail.gmail.com>

On Mon, Jul 6, 2015 at 4:40 PM, Gael Varoquaux <
gael.varoquaux at normalesup.org> wrote:

>
> No: dtype=float by default will create other serious silent failures,
> like the fact that round-trip save/load will change the data. This is
> pretty bad behavior. Certainly not one that I would expect.
>

I think this is a good point.

Nibabel is a low-level I/O library. It has no notion of how the data is
> going to be used, and should therefore do as little as possible to the
> data. There are other libraries to do the rest.


This is less compelling, because the current high-level analysis ecosystem
is pretty spotty. Perhaps in an ideal world nibabel would be a tool that is
only used by library developers, but that's not the current state of Nipy,
in my estimation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150706/946666f4/attachment.html>

From gael.varoquaux at normalesup.org  Tue Jul  7 01:26:57 2015
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Tue, 7 Jul 2015 01:26:57 +0200
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAH6Pt5qStwrbQhLLzRysPsVzRfo7Wm1HCBJJL1r8DSK713nZSg@mail.gmail.com>
References: <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
 <559AD3C8.8020202@inria.fr>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741DC0@EXMB10.ohsu.edu>
 <CAE_wbFvfHYgFvCV_1-K6uG8KL0RHgDjhD6kixqObd7DiAtQvrw@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741E3E@EXMB10.ohsu.edu>
 <CANgTvZjqTX2oqt3EZ98Z=CrA7mXF=PWtKbT=Rz6gdvV8D9-0zw@mail.gmail.com>
 <CAH6Pt5qStwrbQhLLzRysPsVzRfo7Wm1HCBJJL1r8DSK713nZSg@mail.gmail.com>
Message-ID: <20150706232657.GC2967360@phare.normalesup.org>

On Mon, Jul 06, 2015 at 10:29:09PM +0100, Matthew Brett wrote:
> > I still don't see a strong case for confusions and errors.

> I can only repeat - I made this error myself - in a very early and
> introductory class.

Good. If you're teaching numerics, you've taught the students a useful
lesson: don't do numerics on ints. I made this error (in C, but the idea
is the same) in the project of my masters internship. It taught me a good
lesson.

If you're not teaching numerics but neuroimaging, I am not sure why an
intro class is covering sums or numerical arrays.

Ga?l

From moloney at ohsu.edu  Tue Jul  7 03:03:25 2015
From: moloney at ohsu.edu (Brendan Moloney)
Date: Tue, 7 Jul 2015 01:03:25 +0000
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <20150706232229.GB2967360@phare.normalesup.org>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
 <559AD3C8.8020202@inria.fr>
 <CAH6Pt5qU7E+vNzTdmUROD9-N6h7kPuYdC_uMMiU_SF3=CyHupg@mail.gmail.com>,
 <20150706232229.GB2967360@phare.normalesup.org>
Message-ID: <5F6A858FD00E5F4A82E3206D2D854EF87F741F52@EXMB10.ohsu.edu>



> And we always convert data to float in functions that obviously work on
> continous-valued data. But in a masking function, we would have to do
> convert data the opposite way.
> 
> Where it get nasty is: what if the data has undergone a spatial
> transformation? The original integer values are then interpolated to
> intermediate values. What is then the right thing to do?

So it sounds like you might need to handle non-integer masks, even 
without this proposal? At least I don't see how this is an argument 
against the proposal.

-Brendan

From moloney at ohsu.edu  Tue Jul  7 03:13:36 2015
From: moloney at ohsu.edu (Brendan Moloney)
Date: Tue, 7 Jul 2015 01:13:36 +0000
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <20150706233705.GA2986567@phare.normalesup.org>
References: <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
 <559AD3C8.8020202@inria.fr>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741DC0@EXMB10.ohsu.edu>
 <CAE_wbFvfHYgFvCV_1-K6uG8KL0RHgDjhD6kixqObd7DiAtQvrw@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741E3E@EXMB10.ohsu.edu>
 <CANgTvZjqTX2oqt3EZ98Z=CrA7mXF=PWtKbT=Rz6gdvV8D9-0zw@mail.gmail.com>
 <CAH6Pt5qStwrbQhLLzRysPsVzRfo7Wm1HCBJJL1r8DSK713nZSg@mail.gmail.com>
 <CA+1BpOsHYEidXn7BEQWsVBb=CvXy3s-b0fqH6fJ2jPz00QZm0A@mail.gmail.com>
 <CAKZ-Uq2dSrPK5JuNQz8tp+3kt36Y7S-neLaWadrkJJFhA2aq5g@mail.gmail.com>,
 <20150706233705.GA2986567@phare.normalesup.org>
Message-ID: <5F6A858FD00E5F4A82E3206D2D854EF87F741F61@EXMB10.ohsu.edu>



> The question is the following: you've written code that deal with a label
> image. Some one gives you an image as an input. It's a float dtype. How
> do you know whether the user loaded the wrong image, or it's just right
> and the loading library did the conversion? The loss of semantics implied
> by the casting makes it harder to have a good behavior / error message.

What is so bad about raising an exception saying masks/labels must have an 
integer dtype? You could even include a helpful hint about explicitly requesting
the correct dtype from nibabel's 'get_data' method or from numpy's array 
creation functions.

From moloney at ohsu.edu  Tue Jul  7 03:23:06 2015
From: moloney at ohsu.edu (Brendan Moloney)
Date: Tue, 7 Jul 2015 01:23:06 +0000
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <20150706234027.GE2967360@phare.normalesup.org>
References: <559AD3C8.8020202@inria.fr>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741DC0@EXMB10.ohsu.edu>
 <CAE_wbFvfHYgFvCV_1-K6uG8KL0RHgDjhD6kixqObd7DiAtQvrw@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741E3E@EXMB10.ohsu.edu>
 <CAE_wbFukWyB2T-yR8jnyzRoiXEO6ojKwbE3vZXGuAYw2BDZz6A@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741EB3@EXMB10.ohsu.edu>
 <CAE_wbFtYKANTM5CedoEYQoqQU-GmoiSGfCBkceX=qnp3MivvDA@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741EEC@EXMB10.ohsu.edu>
 <CAE_wbFucDuSjpuMYRPAFxqYXKgWv_cNgWwjKAMcbHVu_+KNrHQ@mail.gmail.com>
 <CAKZ-Uq2_06y0sLHA+sPBrXVTuoDSpt=Aiz1BLHNaPuny4L_3SA@mail.gmail.com>,
 <20150706234027.GE2967360@phare.normalesup.org>
Message-ID: <5F6A858FD00E5F4A82E3206D2D854EF87F741F70@EXMB10.ohsu.edu>


> No: dtype=float by default will create other serious silent failures,
> like the fact that round-trip save/load will change the data. This is
> pretty bad behavior. Certainly not one that I would expect.

I don't think this is true, provided you use the same Nifti header or 
create an appropriate new header. The situation is the same now if the 
scale factors are set.

> This has implication on data processing: density estimation should be
> done differently on a set of continuous values than on a set of integers
> (histogram vs kernel smoothing).

This goes both ways. If you wrote some code like this that assumes you 
have integer values it will fail mysteriously when the file has the scale 
factors set.  

From moloney at ohsu.edu  Tue Jul  7 04:57:23 2015
From: moloney at ohsu.edu (Brendan Moloney)
Date: Tue, 7 Jul 2015 02:57:23 +0000
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <559B130F.9000107@bu.edu>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
 <559AD3C8.8020202@inria.fr>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741DC0@EXMB10.ohsu.edu>
 <CAE_wbFvfHYgFvCV_1-K6uG8KL0RHgDjhD6kixqObd7DiAtQvrw@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741E3E@EXMB10.ohsu.edu>
 <CAE_wbFukWyB2T-yR8jnyzRoiXEO6ojKwbE3vZXGuAYw2BDZz6A@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741EB3@EXMB10.ohsu.edu>
 <CAE_wbFtYKANTM5CedoEYQoqQU-GmoiSGfCBkceX=qnp3MivvDA@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741EEC@EXMB10.ohsu.edu>
 <CAE_wbFucDuSjpuMYRPAFxqYXKgWv_cNgWwjKAMcbHVu_+KNrHQ@mail.gmail.com>
 <CAH6Pt5oZmnK2mvSUzSq_hfts5D0NfNEXdQuEoHsKzSjbH6p8fg@mail.gmail.com>,
 <559B130F.9000107@bu.edu>
Message-ID: <5F6A858FD00E5F4A82E3206D2D854EF87F741F91@EXMB10.ohsu.edu>


> It sounds like consensus is rolling around to a dtype parameter, but I'm
> not entirely clear on what the semantics should be. The least surprising
> interpretation would be this:
>
>    if dtype is not None:
>        np.array_equal(dtype(img.get_data()), img.get_data(dtype=dtype))

I think it would be okay to raise an exception in 'get_data' where it may not 
get raised in the 'dtype' function, but otherwise I agree the results should 
match.

> However, if the type is clearly specified in the headers and not
> (uint16, m=1, b=0), would the dtype be ignored, or would we get
> dtype(img.get_data())? As noted, the former would be surprising, but the
> latter makes anything other than setting the default parameter to None
> impossible without making the default behavior even more surprising.
> Perhaps a dtype that conflicts with the header-specified type should
> cause an exception?
>
> Further, is the goal here to make this arbitrarily castable, or limited
> to float64 or the header-specified datatype, as in the original proposal
> of as_float?

These are good questions. My gut instinct is that we should raise an 
exception on anything that would "hork up the data" as Nate put it.
So if you ask for int data when it should be a float (either due to the 
storage dtype or due to the scale factors) that would cause an exception.

The grey areas I am less sure about. It is tempting to say float64 to 
float32 casting should be allowed. I guess we could be clever about 
things like int32 -> int16 (i.e. check the range).

One other thought. If you do want the native integer data (and it won't 
raise an exception) you shouldn't have to know the number of bits.
Using 'np.int' and 'np.uint' for this purpose would cause the results to 
differ from the 'dtype' function.

From matthew.brett at gmail.com  Tue Jul  7 07:54:57 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Tue, 7 Jul 2015 06:54:57 +0100
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <5F6A858FD00E5F4A82E3206D2D854EF87F741F70@EXMB10.ohsu.edu>
References: <559AD3C8.8020202@inria.fr>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741DC0@EXMB10.ohsu.edu>
 <CAE_wbFvfHYgFvCV_1-K6uG8KL0RHgDjhD6kixqObd7DiAtQvrw@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741E3E@EXMB10.ohsu.edu>
 <CAE_wbFukWyB2T-yR8jnyzRoiXEO6ojKwbE3vZXGuAYw2BDZz6A@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741EB3@EXMB10.ohsu.edu>
 <CAE_wbFtYKANTM5CedoEYQoqQU-GmoiSGfCBkceX=qnp3MivvDA@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741EEC@EXMB10.ohsu.edu>
 <CAE_wbFucDuSjpuMYRPAFxqYXKgWv_cNgWwjKAMcbHVu_+KNrHQ@mail.gmail.com>
 <CAKZ-Uq2_06y0sLHA+sPBrXVTuoDSpt=Aiz1BLHNaPuny4L_3SA@mail.gmail.com>
 <20150706234027.GE2967360@phare.normalesup.org>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741F70@EXMB10.ohsu.edu>
Message-ID: <CAH6Pt5oh+br01u7vLP32QaqDRZZGKvtYDVHbuchJaMuZ=0CXFw@mail.gmail.com>

On Tue, Jul 7, 2015 at 2:23 AM, Brendan Moloney <moloney at ohsu.edu> wrote:
>
>> No: dtype=float by default will create other serious silent failures,
>> like the fact that round-trip save/load will change the data. This is
>> pretty bad behavior. Certainly not one that I would expect.
>
> I don't think this is true, provided you use the same Nifti header or
> create an appropriate new header. The situation is the same now if the
> scale factors are set.

Right - same argument as above.   Currently, anytime there are
not-default slope and offset, nibabel will load as float, and
recalculate slope, offset on save.   Again, whether this will happen
depends on the usually-arbitrary choice that the image author made of
dtype and slope and intercept.  So the change would have the benefit
of making this predictable rather than unpredictable.

>> This has implication on data processing: density estimation should be
>> done differently on a set of continuous values than on a set of integers
>> (histogram vs kernel smoothing).
>
> This goes both ways. If you wrote some code like this that assumes you
> have integer values it will fail mysteriously when the file has the scale
> factors set.

Right.  Of course there is a difference between the processing of ints
and floats, and that's exactly why we should not - by default - inject
that difference on the basis of settings in the header that are not
designed or (usually) used to make that distinction.  The distinction
should be make consciously by the user.   Explicit is better than
implicit, where the current algorithm (that I chose a long time ago
without much thought) is dangerously implicit.

Cheers,

Matthew

From rafaelnh21 at gmail.com  Tue Jul  7 16:35:09 2015
From: rafaelnh21 at gmail.com (Rafael Henriques)
Date: Tue, 7 Jul 2015 15:35:09 +0100
Subject: [Neuroimaging] Dipy - Minimum diffusivity defined in DTI fit
	reconstruction
Message-ID: <CALQBObKxeNmMGKvU-HM0vhR7Y_t=SYqzg+=hvFpnhVsOG0Dfng@mail.gmail.com>

Hi all,

I understand that the minimum diffusivity in Dipy's dti module is defined
to avoid problematic causes of zero division. In functions *ols_fit_tensor*
and *wls_fit_tensor* the minimum diffusivity is automatically defined as
function of the inverse of the maximum b-value. What is the mathematical
basis of these lines of code? And why tol variable is set to 1e-6?

Thanks,
Rafael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150707/ecc0a44c/attachment.html>

From satra at mit.edu  Tue Jul  7 18:10:34 2015
From: satra at mit.edu (Satrajit Ghosh)
Date: Tue, 7 Jul 2015 12:10:34 -0400
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <559AF71E.4060502@stanford.edu>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
 <559AD3C8.8020202@inria.fr>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741DC0@EXMB10.ohsu.edu>
 <CAE_wbFvfHYgFvCV_1-K6uG8KL0RHgDjhD6kixqObd7DiAtQvrw@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741E3E@EXMB10.ohsu.edu>
 <559AF71E.4060502@stanford.edu>
Message-ID: <CA+A4wOmGKLgWGh7M4X6AEjRu35rhQYS5GE07F2ZQ79Voc1M_Ng@mail.gmail.com>

hi folks,

an interim summary and a few thoughts:

the nifti-1 standard (
http://nifti.nimh.nih.gov/pub/dist/src/niftilib/nifti1.h) has a datatype
field. there are two scenarios with scaling:

1. scl_slope == 0:

2. scl_slope != 0:
   data should be converted to IEEE-754  floats as per the nifti standard.
given nifti was around 2001 this probably did not reflect the updated
IEE754-2008 standard, but relied on the 1985 standard. i don't think the
nifti-1 standard makes it clear what this float should correspond to, i.e.,
16/32/64/128 bit floats.

round trip:
 to ensure that round trip to an identical binary file is possible, we need
the original data type as well scl_slope and scl_offset values retained in
the metadata of the header.


benefits of not touching the data type (when scl_slope == 0):
- memory mapping is possible when large datasets are used (without
compression and stored in a native dtype) and these datasets are growing.
- GPU and other operations relying on integer arithmetic will not have to
convert back from floats
- let developers decide what to do - reduce magic in code

cons of not touching the data type:
- users who are and are not used to numerics may get bitten
- implicit errors are really bad


proposed solution to use dtype argument:

i do agree with having a dtype keyword. i also think that:
- nibabel should default to the rules laid out by the standard above.
nibabel image dtype should correspond to the nifti datatype unless the
scl_slope parameter is non-zero or user requested dtype is different (see
next). one can then apply any of the numpy astype calls as necessary with
all its usual caveats of converting between datatypes.
- default dtype should be None to reduce backward incompatibility
- in teaching make users aware of setting this dtype to float or other,
instead of making float the default. letting people know that if they are
going to be programming numerics (even if it is a sum) they need to be
aware of details is not a bad thing.
- converting everything to float can have a significant impact on memory
requirements and many of our users don't understand why their job crashed
on the cluster (often the job simply runs out of the default memory that we
allow for each job).
- one would still want to maintain the round trip ability through this api
change.

sum as a simple operation:
reminds me of issues we ran into with optimizing compilers and floats - see
 https://en.wikipedia.org/wiki/Kahan_summation_algorithm .

cheers,

satra

On Mon, Jul 6, 2015 at 5:46 PM, Bob Dougherty <bobd at stanford.edu> wrote:

>  Hi All,
>
> I've been silently enjoying this thread, and now that the dust appears to
> be settling I'll offer my humble opinion:
>
> 1. I definitely like the dtype option over the other alternatives proposed
>
> 2. I agree that the choice of default behavior is challenging, and want to
> reinforce what Brendan says here-- nifti is a bit messy and there is very
> often no clear answer as to what the returned type should be. I guess I am
> also slowly coming around to float64 as the default, and if you need
> something else you can use the dtype option.
>
> 3. and just to be nit-picky... the raw MR k-space data are actually 16-bit
> integers (that's what the ADCs return). So there is some logic behind
> keeping MR data represented with 16-bit integers, even after the image
> reconstruction (which is indeed a floating-point computation).
>
> cheers,
> bob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150707/50f6ed6c/attachment.html>

From mrbago at gmail.com  Tue Jul  7 19:07:09 2015
From: mrbago at gmail.com (Bago)
Date: Tue, 7 Jul 2015 10:07:09 -0700
Subject: [Neuroimaging] Dipy - Minimum diffusivity defined in DTI fit
	reconstruction
In-Reply-To: <CALQBObKxeNmMGKvU-HM0vhR7Y_t=SYqzg+=hvFpnhVsOG0Dfng@mail.gmail.com>
References: <CALQBObKxeNmMGKvU-HM0vhR7Y_t=SYqzg+=hvFpnhVsOG0Dfng@mail.gmail.com>
Message-ID: <CAHHh6CY9x288mW1BjWveOBBLcO8OiiYsxkL1Qeg=gvBPHU7r9A@mail.gmail.com>

The minimum diffusivity values are defined with respect to the maximum
b-values so that dipy will work with b-values inputs in different units.
For example, a data set with 2 diffusion weighted shells might have
b-values of 1000 and 2000 mm^2/s. These b-values can also be expressed as
1e-3 and 2e-3 cm^2/s. The diffusivity values are computed in inverse units
of the b-values, (s/mm^2 and s/cm^2 respectively for the example above) so
we need to define the minimum diffusivity in the appropriate units.

1e-6 is simply an empirical value that worked well, but I guess you could
justify it by saying that it is close to 1 / (2^16) which is the level of
precision in most MRI data sets (raw MRI data most often uses an int16
representation).

Bago

On Tue, Jul 7, 2015 at 7:35 AM, Rafael Henriques <rafaelnh21 at gmail.com>
wrote:

> Hi all,
>
> I understand that the minimum diffusivity in Dipy's dti module is defined
> to avoid problematic causes of zero division. In functions
> *ols_fit_tensor* and *wls_fit_tensor* the minimum diffusivity is
> automatically defined as function of the inverse of the maximum b-value.
> What is the mathematical basis of these lines of code? And why tol variable
> is set to 1e-6?
>
> Thanks,
> Rafael
>
> _______________________________________________
> 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/20150707/c837e8be/attachment.html>

From matthew.brett at gmail.com  Tue Jul  7 19:54:53 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Tue, 7 Jul 2015 18:54:53 +0100
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CA+A4wOmGKLgWGh7M4X6AEjRu35rhQYS5GE07F2ZQ79Voc1M_Ng@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
 <559AD3C8.8020202@inria.fr>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741DC0@EXMB10.ohsu.edu>
 <CAE_wbFvfHYgFvCV_1-K6uG8KL0RHgDjhD6kixqObd7DiAtQvrw@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741E3E@EXMB10.ohsu.edu>
 <559AF71E.4060502@stanford.edu>
 <CA+A4wOmGKLgWGh7M4X6AEjRu35rhQYS5GE07F2ZQ79Voc1M_Ng@mail.gmail.com>
Message-ID: <CAH6Pt5oe9r_593CerzDFFnJTLP7dp6jxzN5ZijzRfKztZtJKAQ@mail.gmail.com>

Hi,

On Tue, Jul 7, 2015 at 5:10 PM, Satrajit Ghosh <satra at mit.edu> wrote:
> hi folks,
>
> an interim summary and a few thoughts:
>
> the nifti-1 standard
> (http://nifti.nimh.nih.gov/pub/dist/src/niftilib/nifti1.h) has a datatype
> field. there are two scenarios with scaling:
>
> 1. scl_slope == 0:
>
> 2. scl_slope != 0:
>    data should be converted to IEEE-754  floats as per the nifti standard.
> given nifti was around 2001 this probably did not reflect the updated
> IEE754-2008 standard, but relied on the 1985 standard. i don't think the
> nifti-1 standard makes it clear what this float should correspond to, i.e.,
> 16/32/64/128 bit floats.
>
> round trip:
>  to ensure that round trip to an identical binary file is possible, we need
> the original data type as well scl_slope and scl_offset values retained in
> the metadata of the header.
>
>
> benefits of not touching the data type (when scl_slope == 0):
> - memory mapping is possible when large datasets are used (without
> compression and stored in a native dtype) and these datasets are growing.
> - GPU and other operations relying on integer arithmetic will not have to
> convert back from floats
> - let developers decide what to do - reduce magic in code
>
> cons of not touching the data type:
> - users who are and are not used to numerics may get bitten
> - implicit errors are really bad
>
>
> proposed solution to use dtype argument:
>
> i do agree with having a dtype keyword. i also think that:
> - nibabel should default to the rules laid out by the standard above.
> nibabel image dtype should correspond to the nifti datatype unless the
> scl_slope parameter is non-zero or user requested dtype is different (see
> next). one can then apply any of the numpy astype calls as necessary with
> all its usual caveats of converting between datatypes.
> - default dtype should be None to reduce backward incompatibility
> - in teaching make users aware of setting this dtype to float or other,
> instead of making float the default. letting people know that if they are
> going to be programming numerics (even if it is a sum) they need to be aware
> of details is not a bad thing.
> - converting everything to float can have a significant impact on memory
> requirements and many of our users don't understand why their job crashed on
> the cluster (often the job simply runs out of the default memory that we
> allow for each job).
> - one would still want to maintain the round trip ability through this api
> change.

We have to address ourselves to the standard as it is actually used.
As the standard is used, there is almost never a reason to assume that
an image with slope = 1, intercept = 0 is really intended to be used
as integers in memory.

To emphasize, there is currently no guarantee that an image will be
identical if round tripped, and in general, it will not be identical
now, if slope != 1 and intercept != 0.

I realize that the default change will use more memory, but I don't
think we should be increasing the risk of silent generation of
entirely wrong results in order to optimize memory, in the default
case.   The user who needs to optimize memory, is the advanced user.

Specifically, a user getting a memory error loading an image, and
having to look up the docs to solve it, is a whole lot better than a
user writing a script to do something basic to images, which works
fine on the images they test with, but later silently gives a
non-sensical result for other valid nifti images.

To improve the quality of the discussion - has anyone got an example
of a real script that will give the wrong answer with the proposed
change?

Cheers,

Matthew

From moloney at ohsu.edu  Tue Jul  7 20:16:15 2015
From: moloney at ohsu.edu (Brendan Moloney)
Date: Tue, 7 Jul 2015 18:16:15 +0000
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CA+A4wOmGKLgWGh7M4X6AEjRu35rhQYS5GE07F2ZQ79Voc1M_Ng@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
 <559AD3C8.8020202@inria.fr>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741DC0@EXMB10.ohsu.edu>
 <CAE_wbFvfHYgFvCV_1-K6uG8KL0RHgDjhD6kixqObd7DiAtQvrw@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741E3E@EXMB10.ohsu.edu>
 <559AF71E.4060502@stanford.edu>,
 <CA+A4wOmGKLgWGh7M4X6AEjRu35rhQYS5GE07F2ZQ79Voc1M_Ng@mail.gmail.com>
Message-ID: <5F6A858FD00E5F4A82E3206D2D854EF87F7420A5@EXMB10.ohsu.edu>

> the nifti-1 standard (http://nifti.nimh.nih.gov/pub/dist/src/niftilib/nifti1.h)
> has a datatype field. there are two scenarios with scaling:
>
> 1. scl_slope == 0:
>
> 2. scl_slope != 0:
>    data should be converted to IEEE-754  floats as per the nifti standard.
> given nifti was around 2001 this probably did not reflect the updated
> IEE754-2008 standard, but > relied on the 1985 standard. i don't think the
> nifti-1 standard makes it clear what this float should correspond to, i.e.,
> 16/32/64/128 bit floats.

I don't see that in the standard.  All I see is:


   If the scl_slope field is nonzero, then each voxel value in the dataset
   should be scaled as
      y = scl_slope * x + scl_inter
   where x = voxel value stored
         y = "true" voxel value
   Normally, we would expect this scaling to be used to store "true" floating
   values in a smaller integer datatype, but that is not required.  That is,
   it is legal to use scaling even if the datatype is a float type (crazy,
   perhaps, but legal).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150707/0fde7aba/attachment.html>

From njvack at wisc.edu  Tue Jul  7 18:30:36 2015
From: njvack at wisc.edu (Nate Vack)
Date: Tue, 07 Jul 2015 16:30:36 +0000
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <20150706232744.GD2967360@phare.normalesup.org>
References: <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
 <559AD3C8.8020202@inria.fr>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741DC0@EXMB10.ohsu.edu>
 <CAE_wbFvfHYgFvCV_1-K6uG8KL0RHgDjhD6kixqObd7DiAtQvrw@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741E3E@EXMB10.ohsu.edu>
 <CANgTvZjqTX2oqt3EZ98Z=CrA7mXF=PWtKbT=Rz6gdvV8D9-0zw@mail.gmail.com>
 <CAH6Pt5qStwrbQhLLzRysPsVzRfo7Wm1HCBJJL1r8DSK713nZSg@mail.gmail.com>
 <CA+1BpOsHYEidXn7BEQWsVBb=CvXy3s-b0fqH6fJ2jPz00QZm0A@mail.gmail.com>
 <20150706232744.GD2967360@phare.normalesup.org>
Message-ID: <CA+1BpOvS0H4ChgCzUy4+cXF+9cj0WXPPq=d0W0F0GrA9TVZrjg@mail.gmail.com>

On Mon, Jul 6, 2015 at 6:28 PM Gael Varoquaux <gael.varoquaux at normalesup.org>
wrote:

You cannot do numerics without being aware of dtype and overflow.
> Seriously.
>

When 75% of your files are natively stored as floats, but for some reason
the 25% of them are shorts, it's remarkably easy to not notice that
Something Bad has quietly happened, until you go and look at all the output
files and say "wait, what?"

Yes, I know that situation is not supposed to happen (and I could have
avoided it by running a data type report before doing computation), but
there are delightful surprises in datasets. Even when you're aware of these
things, they're still lurking with their sharp pointy teeth.

The ultimate answer to "what is the least surprising behavior?" is
complicated and probably depends on your normal use cases. For me, it's
default conversion to float.

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

From satra at mit.edu  Wed Jul  8 04:29:36 2015
From: satra at mit.edu (Satrajit Ghosh)
Date: Tue, 7 Jul 2015 22:29:36 -0400
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAH6Pt5oe9r_593CerzDFFnJTLP7dp6jxzN5ZijzRfKztZtJKAQ@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
 <559AD3C8.8020202@inria.fr>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741DC0@EXMB10.ohsu.edu>
 <CAE_wbFvfHYgFvCV_1-K6uG8KL0RHgDjhD6kixqObd7DiAtQvrw@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741E3E@EXMB10.ohsu.edu>
 <559AF71E.4060502@stanford.edu>
 <CA+A4wOmGKLgWGh7M4X6AEjRu35rhQYS5GE07F2ZQ79Voc1M_Ng@mail.gmail.com>
 <CAH6Pt5oe9r_593CerzDFFnJTLP7dp6jxzN5ZijzRfKztZtJKAQ@mail.gmail.com>
Message-ID: <CA+A4wOmN73-5SmLivpgcGq-8RfDFEmRhqzU6Xxs_ZbAyO9gH2w@mail.gmail.com>

hi matthew,


> We have to address ourselves to the standard as it is actually used.
> As the standard is used, there is almost never a reason to assume that
> an image with slope = 1, intercept = 0 is really intended to be used
> as integers in memory.
>

to me this would always be float in memory. since slope == 1 and != 0.


> To emphasize, there is currently no guarantee that an image will be
> identical if round tripped, and in general, it will not be identical
> now, if slope != 1 and intercept != 0.
>

what if scl_slope == 0, shouldn't we expect roundtrip identity?

I realize that the default change will use more memory, but I don't
> think we should be increasing the risk of silent generation of
> entirely wrong results in order to optimize memory, in the default
> case.


i agree, but is there a way to allow for keeping the datatype intact? are
we agreeing that a keyword is necessary, and dtype=None will keep the
original datatype.


> To improve the quality of the discussion - has anyone got an example
> of a real script that will give the wrong answer with the proposed
> change?
>

at least the common scripts we use won't give a wrong answer. but many of
our workflows will now crash because they would require additional memory
for specific pieces. now that's several layers embedded from a user point
of view.

is the proposed change the augmented proposal to include a dtype keyword?

cheers,

satra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150707/f652e273/attachment.html>

From satra at mit.edu  Wed Jul  8 04:35:17 2015
From: satra at mit.edu (Satrajit Ghosh)
Date: Tue, 7 Jul 2015 22:35:17 -0400
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <5F6A858FD00E5F4A82E3206D2D854EF87F7420A5@EXMB10.ohsu.edu>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
 <559AD3C8.8020202@inria.fr>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741DC0@EXMB10.ohsu.edu>
 <CAE_wbFvfHYgFvCV_1-K6uG8KL0RHgDjhD6kixqObd7DiAtQvrw@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741E3E@EXMB10.ohsu.edu>
 <559AF71E.4060502@stanford.edu>
 <CA+A4wOmGKLgWGh7M4X6AEjRu35rhQYS5GE07F2ZQ79Voc1M_Ng@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F7420A5@EXMB10.ohsu.edu>
Message-ID: <CA+A4wOm7mFnUAar19cRLTPitisf+FQJbTAAo2eYPA8M57=Dt9Q@mail.gmail.com>

hi brendan,

here is the line:

Floating point types are presumed to be stored in IEEE-754 format.

this is about how data are stored on disk. nifti-1 does not say
anything about what a user does with data. i only intended to say that
data stored back should conform to ieee-754 when stored as dt_float.

cheers,

satra

On Tue, Jul 7, 2015 at 2:16 PM, Brendan Moloney <moloney at ohsu.edu> wrote:

>   > the nifti-1 standard (
> http://nifti.nimh.nih.gov/pub/dist/src/niftilib/nifti1.h)
> > has a datatype field. there are two scenarios with scaling:
> >
>  > 1. scl_slope == 0:
> >
>  > 2. scl_slope != 0:
> >    data should be converted to IEEE-754  floats as per the nifti
> standard.
> > given nifti was around 2001 this probably did not reflect the updated
> > IEE754-2008 standard, but > relied on the 1985 standard. i don't think
> the
> > nifti-1 standard makes it clear what this float should correspond to,
> i.e.,
> > 16/32/64/128 bit floats.
>
> I don't see that in the standard.  All I see is:
>
>    If the scl_slope field is nonzero, then each voxel value in the dataset
>    should be scaled as
>       y = scl_slope * x + scl_inter
>    where x = voxel value stored
>          y = "true" voxel value
>    Normally, we would expect this scaling to be used to store "true" floating
>    values in a smaller integer datatype, but that is not required.  That is,
>    it is legal to use scaling even if the datatype is a float type (crazy,
>    perhaps, but legal).
>
>
>
> _______________________________________________
> 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/20150707/09dbdb64/attachment.html>

From satra at mit.edu  Wed Jul  8 04:36:39 2015
From: satra at mit.edu (Satrajit Ghosh)
Date: Tue, 7 Jul 2015 22:36:39 -0400
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CA+A4wOmN73-5SmLivpgcGq-8RfDFEmRhqzU6Xxs_ZbAyO9gH2w@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
 <559AD3C8.8020202@inria.fr>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741DC0@EXMB10.ohsu.edu>
 <CAE_wbFvfHYgFvCV_1-K6uG8KL0RHgDjhD6kixqObd7DiAtQvrw@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741E3E@EXMB10.ohsu.edu>
 <559AF71E.4060502@stanford.edu>
 <CA+A4wOmGKLgWGh7M4X6AEjRu35rhQYS5GE07F2ZQ79Voc1M_Ng@mail.gmail.com>
 <CAH6Pt5oe9r_593CerzDFFnJTLP7dp6jxzN5ZijzRfKztZtJKAQ@mail.gmail.com>
 <CA+A4wOmN73-5SmLivpgcGq-8RfDFEmRhqzU6Xxs_ZbAyO9gH2w@mail.gmail.com>
Message-ID: <CA+A4wO=1aGtEV45gyAr7c7XgzKc0bGVztYT_jit71zgcd-BEog@mail.gmail.com>

hi matthew,

quick follow up question on proposed change. would saving the image back to
disk restore the original datatype? i.e. i read a uint8 image and save it
to another location, would that new file by 8 times the size of the
original file?

cheers,

satra

On Tue, Jul 7, 2015 at 10:29 PM, Satrajit Ghosh <satra at mit.edu> wrote:

> hi matthew,
>
>
>> We have to address ourselves to the standard as it is actually used.
>> As the standard is used, there is almost never a reason to assume that
>> an image with slope = 1, intercept = 0 is really intended to be used
>> as integers in memory.
>>
>
> to me this would always be float in memory. since slope == 1 and != 0.
>
>
>> To emphasize, there is currently no guarantee that an image will be
>> identical if round tripped, and in general, it will not be identical
>> now, if slope != 1 and intercept != 0.
>>
>
> what if scl_slope == 0, shouldn't we expect roundtrip identity?
>
> I realize that the default change will use more memory, but I don't
>> think we should be increasing the risk of silent generation of
>> entirely wrong results in order to optimize memory, in the default
>> case.
>
>
> i agree, but is there a way to allow for keeping the datatype intact? are
> we agreeing that a keyword is necessary, and dtype=None will keep the
> original datatype.
>
>
>> To improve the quality of the discussion - has anyone got an example
>> of a real script that will give the wrong answer with the proposed
>> change?
>>
>
> at least the common scripts we use won't give a wrong answer. but many of
> our workflows will now crash because they would require additional memory
> for specific pieces. now that's several layers embedded from a user point
> of view.
>
> is the proposed change the augmented proposal to include a dtype keyword?
>
> cheers,
>
> satra
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150707/e7cfd28c/attachment.html>

From rafaelnh21 at gmail.com  Wed Jul  8 09:46:33 2015
From: rafaelnh21 at gmail.com (Rafael Henriques)
Date: Wed, 8 Jul 2015 08:46:33 +0100
Subject: [Neuroimaging] [Dipy] Scanning parameters of Dipy's sample data
	Sherbrooke's 3 shells
Message-ID: <CALQBObJzjWMwECfqQF72E5uCLBO+-p4Np+VJBjaB8tzhd0N7LA@mail.gmail.com>

Hi all,

I am currently participating in Google Summer of Code and I am implementing
on Dipy a module for diffusion kurtosis imaging, a technique useful to
probe in vivo tissue heterogeneity and complexity.

Our first results are looking very good (you can see them here:
http://gsoc2015dipydki.blogspot.co.uk/2015/07/rnh-post-6-mid-term-summary.html),
however when I try to process the Dipy's multi-shell dataset example Sherbrooke
3 shells, kurtosis measures seem to be widely corrupted by implausible high
negative values (black regions on the images of the following link:
 http://gsoc2015dipydki.blogspot.co.uk/2015/07/rnh-post-7-artifacts-in-dipys-sample.html
<http://gsoc2015dipydki.blogspot.co.uk/2015/07/rnh-post-7-artifacts-in-dipys-sample.html>
).

Implausible high negative values of kurtosis are a common artifact on DKI,
however, given the data?s b-value and number of gradient directions, I was
not expecting having implausible negative values in almost all brain image
voxels. To try understanding why diffusion kurtosis is not working on this
dataset, I was wondering if anyone knows the full scanning parameters of
this dataset?

Many thanks in advance,

Rafael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150708/721e1454/attachment.html>

From moloney at ohsu.edu  Wed Jul  8 10:22:04 2015
From: moloney at ohsu.edu (Brendan Moloney)
Date: Wed, 8 Jul 2015 08:22:04 +0000
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CA+A4wOm7mFnUAar19cRLTPitisf+FQJbTAAo2eYPA8M57=Dt9Q@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
 <559AD3C8.8020202@inria.fr>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741DC0@EXMB10.ohsu.edu>
 <CAE_wbFvfHYgFvCV_1-K6uG8KL0RHgDjhD6kixqObd7DiAtQvrw@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741E3E@EXMB10.ohsu.edu>
 <559AF71E.4060502@stanford.edu>
 <CA+A4wOmGKLgWGh7M4X6AEjRu35rhQYS5GE07F2ZQ79Voc1M_Ng@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F7420A5@EXMB10.ohsu.edu>,
 <CA+A4wOm7mFnUAar19cRLTPitisf+FQJbTAAo2eYPA8M57=Dt9Q@mail.gmail.com>
Message-ID: <5F6A858FD00E5F4A82E3206D2D854EF87F74234D@EXMB10.ohsu.edu>

I meant that the Nifti standard doesn't give much guidance on the interaction 
between scl_slope and the storage datatype.
________________________________________
From: Neuroimaging [neuroimaging-bounces+moloney=ohsu.edu at python.org] on behalf of Satrajit Ghosh [satra at mit.edu]
Sent: Tuesday, July 07, 2015 7:35 PM
To: Neuroimaging analysis in Python
Subject: Re: [Neuroimaging] Nibabel API change - always read as float

hi brendan,

here is the line:

Floating point types are presumed to be stored in IEEE-754 format.

this is about how data are stored on disk. nifti-1 does not say anything about what a user does with data. i only intended to say that data stored back should conform to ieee-754 when stored as dt_float.

cheers,

satra

On Tue, Jul 7, 2015 at 2:16 PM, Brendan Moloney <moloney at ohsu.edu<mailto:moloney at ohsu.edu>> wrote:
> the nifti-1 standard (http://nifti.nimh.nih.gov/pub/dist/src/niftilib/nifti1.h)
> has a datatype field. there are two scenarios with scaling:
>
> 1. scl_slope == 0:
>
> 2. scl_slope != 0:
>    data should be converted to IEEE-754  floats as per the nifti standard.
> given nifti was around 2001 this probably did not reflect the updated
> IEE754-2008 standard, but > relied on the 1985 standard. i don't think the
> nifti-1 standard makes it clear what this float should correspond to, i.e.,
> 16/32/64/128 bit floats.

I don't see that in the standard.  All I see is:


   If the scl_slope field is nonzero, then each voxel value in the dataset
   should be scaled as
      y = scl_slope * x + scl_inter
   where x = voxel value stored
         y = "true" voxel value
   Normally, we would expect this scaling to be used to store "true" floating
   values in a smaller integer datatype, but that is not required.  That is,
   it is legal to use scaling even if the datatype is a float type (crazy,
   perhaps, but legal).


_______________________________________________
Neuroimaging mailing list
Neuroimaging at python.org<mailto:Neuroimaging at python.org>
https://mail.python.org/mailman/listinfo/neuroimaging



From maxime.descoteaux at gmail.com  Wed Jul  8 13:04:56 2015
From: maxime.descoteaux at gmail.com (Maxime Descoteaux)
Date: Wed, 8 Jul 2015 07:04:56 -0400
Subject: [Neuroimaging] [Dipy] Scanning parameters of Dipy's sample data
 Sherbrooke's 3 shells
In-Reply-To: <CALQBObJzjWMwECfqQF72E5uCLBO+-p4Np+VJBjaB8tzhd0N7LA@mail.gmail.com>
References: <CALQBObJzjWMwECfqQF72E5uCLBO+-p4Np+VJBjaB8tzhd0N7LA@mail.gmail.com>
Message-ID: <CAChMOMfjbt-dWOVJ_UdbO9th4Rh7z5fvMqvHa7fNG8P8ba_E=A@mail.gmail.com>

Hi Rafael,

I will try to find the information for you but I fear it will be difficult
as these datasets are at least 4 years old and from an old 1.5T Siemens
scanner.

You would want TE/TR, delta, Delta, etc? I know that I will not have delta,
Delta. I might be able to find TR, TE and other basic parameters.

Best

Max

On Wed, Jul 8, 2015 at 3:46 AM, Rafael Henriques <rafaelnh21 at gmail.com>
wrote:

> Hi all,
>
> I am currently participating in Google Summer of Code and I am
> implementing on Dipy a module for diffusion kurtosis imaging, a technique
> useful to probe in vivo tissue heterogeneity and complexity.
>
> Our first results are looking very good (you can see them here:
> http://gsoc2015dipydki.blogspot.co.uk/2015/07/rnh-post-6-mid-term-summary.html),
> however when I try to process the Dipy's multi-shell dataset example Sherbrooke
> 3 shells, kurtosis measures seem to be widely corrupted by implausible high
> negative values (black regions on the images of the following link:
>  http://gsoc2015dipydki.blogspot.co.uk/2015/07/rnh-post-7-artifacts-in-dipys-sample.html
> <http://gsoc2015dipydki.blogspot.co.uk/2015/07/rnh-post-7-artifacts-in-dipys-sample.html>
> ).
>
> Implausible high negative values of kurtosis are a common artifact on DKI,
> however, given the data?s b-value and number of gradient directions, I was
> not expecting having implausible negative values in almost all brain image
> voxels. To try understanding why diffusion kurtosis is not working on
> this dataset, I was wondering if anyone knows the full scanning
> parameters of this dataset?
>
> Many thanks in advance,
>
> Rafael
>
> _______________________________________________
> 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/20150708/7f21abe2/attachment.html>

From matthew.brett at gmail.com  Wed Jul  8 16:05:06 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Wed, 8 Jul 2015 15:05:06 +0100
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CA+A4wOmN73-5SmLivpgcGq-8RfDFEmRhqzU6Xxs_ZbAyO9gH2w@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
 <559AD3C8.8020202@inria.fr>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741DC0@EXMB10.ohsu.edu>
 <CAE_wbFvfHYgFvCV_1-K6uG8KL0RHgDjhD6kixqObd7DiAtQvrw@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741E3E@EXMB10.ohsu.edu>
 <559AF71E.4060502@stanford.edu>
 <CA+A4wOmGKLgWGh7M4X6AEjRu35rhQYS5GE07F2ZQ79Voc1M_Ng@mail.gmail.com>
 <CAH6Pt5oe9r_593CerzDFFnJTLP7dp6jxzN5ZijzRfKztZtJKAQ@mail.gmail.com>
 <CA+A4wOmN73-5SmLivpgcGq-8RfDFEmRhqzU6Xxs_ZbAyO9gH2w@mail.gmail.com>
Message-ID: <CAH6Pt5q6HTeGgJMn0cAY9bA6Xe60g2sfCqPjttWF+SL-D7k7Og@mail.gmail.com>

Hi,

On Wed, Jul 8, 2015 at 3:29 AM, Satrajit Ghosh <satra at mit.edu> wrote:
> hi matthew,
>
>>
>> We have to address ourselves to the standard as it is actually used.
>> As the standard is used, there is almost never a reason to assume that
>> an image with slope = 1, intercept = 0 is really intended to be used
>> as integers in memory.
>
>
> to me this would always be float in memory. since slope == 1 and != 0.

Sorry - I should have been more specific.  Nibabel treats NaN or 0
slope as being equivalent to slope == 1, and intercept = NaN is
equivalent to intercept = 0. For slope equivalent to 1, intercept
equivalent to 0, nibabel currently returns the data as on-disk data
type, whatever that is.

I think Brendan quoted the only part of the NIfTI standard that is
relevant, and I don't think that has any bearing on the in-memory data
type, so even if people were using the standard exactly as written, I
don't think that would help us.

>> To emphasize, there is currently no guarantee that an image will be
>> identical if round tripped, and in general, it will not be identical
>> now, if slope != 1 and intercept != 0.
>
>
> what if scl_slope == 0, shouldn't we expect roundtrip identity?

You will get roundtrip identity for slope, intercept equivalent to 1,
0, but the fact that we are having this discussion means that it
hasn't thus far been obvious when or whether to expect round-trip
identity.

>> I realize that the default change will use more memory, but I don't
>> think we should be increasing the risk of silent generation of
>> entirely wrong results in order to optimize memory, in the default
>> case.
>
>
> i agree, but is there a way to allow for keeping the datatype intact? are we
> agreeing that a keyword is necessary, and dtype=None will keep the original
> datatype.

There is no current way of returning data with the on-disk datatype
when then slope, intercept are not equivalent to (1, 0).

I don't much like the dtype keyword, because it involves deciding how
to cast the data to all possible numpy types, which I think the user
should do explicitly if they want something other than the proposed
default float, or the int-if-on-disk-dtype-is-int-and-scaling-allows
default that we have now.

> at least the common scripts we use won't give a wrong answer. but many of
> our workflows will now crash because they would require additional memory
> for specific pieces. now that's several layers embedded from a user point of
> view.

Don't forget that, at the moment, your workflows will work sometimes
(when your data sources have null scaling in the headers) and crash at
other times (when your data sources use slope, inter).

With the proposed change, if you want the current default behavior,
you can either use whatever keyword we agree on, or `data =
np.array(img.dataobj)` for full-backwards compatibility.

> is the proposed change the augmented proposal to include a dtype keyword?

The options in my list of preference so far are:

* as_float={True, False}, where False results in the current
memory-saving algorithm;
* dtype={None or dtype specifier} with None giving the current
memory-saving algorithm;

I don't think there's any benefit for an extra keyword argument if we
aren't changing the default.

Cheers,

Matthew

From matthew.brett at gmail.com  Wed Jul  8 16:10:06 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Wed, 8 Jul 2015 15:10:06 +0100
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAH6Pt5q6HTeGgJMn0cAY9bA6Xe60g2sfCqPjttWF+SL-D7k7Og@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
 <559AD3C8.8020202@inria.fr>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741DC0@EXMB10.ohsu.edu>
 <CAE_wbFvfHYgFvCV_1-K6uG8KL0RHgDjhD6kixqObd7DiAtQvrw@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741E3E@EXMB10.ohsu.edu>
 <559AF71E.4060502@stanford.edu>
 <CA+A4wOmGKLgWGh7M4X6AEjRu35rhQYS5GE07F2ZQ79Voc1M_Ng@mail.gmail.com>
 <CAH6Pt5oe9r_593CerzDFFnJTLP7dp6jxzN5ZijzRfKztZtJKAQ@mail.gmail.com>
 <CA+A4wOmN73-5SmLivpgcGq-8RfDFEmRhqzU6Xxs_ZbAyO9gH2w@mail.gmail.com>
 <CAH6Pt5q6HTeGgJMn0cAY9bA6Xe60g2sfCqPjttWF+SL-D7k7Og@mail.gmail.com>
Message-ID: <CAH6Pt5oWRXGESjW70mihDhiQ+UBr0g=V2P2W0tHfU7-fWGDkUA@mail.gmail.com>

Sorry, I should clarify:

On Wed, Jul 8, 2015 at 3:05 PM, Matthew Brett <matthew.brett at gmail.com> wrote:
> Hi,
>
> On Wed, Jul 8, 2015 at 3:29 AM, Satrajit Ghosh <satra at mit.edu> wrote:
>> hi matthew,
[snip]
>> i agree, but is there a way to allow for keeping the datatype intact? are we
>> agreeing that a keyword is necessary, and dtype=None will keep the original
>> datatype.
>
> There is no current way of returning data with the on-disk datatype
> when then slope, intercept are not equivalent to (1, 0).

I mean - there is no current way do to that from `img.get_data()`, and
I we haven't thus far proposed that you should be able to do that.
You can get the unscaled data by using `img.dataobj.get_unscaled()`.

See you,

Matthew

From matthew.brett at gmail.com  Wed Jul  8 16:18:47 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Wed, 8 Jul 2015 15:18:47 +0100
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CA+A4wO=1aGtEV45gyAr7c7XgzKc0bGVztYT_jit71zgcd-BEog@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
 <559AD3C8.8020202@inria.fr>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741DC0@EXMB10.ohsu.edu>
 <CAE_wbFvfHYgFvCV_1-K6uG8KL0RHgDjhD6kixqObd7DiAtQvrw@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741E3E@EXMB10.ohsu.edu>
 <559AF71E.4060502@stanford.edu>
 <CA+A4wOmGKLgWGh7M4X6AEjRu35rhQYS5GE07F2ZQ79Voc1M_Ng@mail.gmail.com>
 <CAH6Pt5oe9r_593CerzDFFnJTLP7dp6jxzN5ZijzRfKztZtJKAQ@mail.gmail.com>
 <CA+A4wOmN73-5SmLivpgcGq-8RfDFEmRhqzU6Xxs_ZbAyO9gH2w@mail.gmail.com>
 <CA+A4wO=1aGtEV45gyAr7c7XgzKc0bGVztYT_jit71zgcd-BEog@mail.gmail.com>
Message-ID: <CAH6Pt5oOf=Rm4is5ryNdXZ=D73B7-sJdvS3pw9K7Zgh-WvRZCA@mail.gmail.com>

On Wed, Jul 8, 2015 at 3:36 AM, Satrajit Ghosh <satra at mit.edu> wrote:
> hi matthew,
>
> quick follow up question on proposed change. would saving the image back to
> disk restore the original datatype? i.e. i read a uint8 image and save it to
> another location, would that new file by 8 times the size of the original
> file?

If the image to be saved was created with a header, then save uses the
defined dtype in the header.  If it was defined without a header, then
save uses the array dtype to save the data.

If you load and the save an int8 image with not-default scaling, the
image has a defined header with dtype int8, but the in-memory dtype
will be float, because of the scaling.   When saving, nibabel
calculates the optimal scalefactors for the floating point array,
where optimal means using all of the output data range from -128 to
127.   This might well be different from the scaling in the loaded
image.   Nibabel does this because you might have changed the
in-memory array so we can't depend on the previous scaling being
valid.

See you,

Matthew

From satra at mit.edu  Wed Jul  8 17:27:55 2015
From: satra at mit.edu (Satrajit Ghosh)
Date: Wed, 8 Jul 2015 11:27:55 -0400
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAH6Pt5oOf=Rm4is5ryNdXZ=D73B7-sJdvS3pw9K7Zgh-WvRZCA@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
 <559AD3C8.8020202@inria.fr>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741DC0@EXMB10.ohsu.edu>
 <CAE_wbFvfHYgFvCV_1-K6uG8KL0RHgDjhD6kixqObd7DiAtQvrw@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741E3E@EXMB10.ohsu.edu>
 <559AF71E.4060502@stanford.edu>
 <CA+A4wOmGKLgWGh7M4X6AEjRu35rhQYS5GE07F2ZQ79Voc1M_Ng@mail.gmail.com>
 <CAH6Pt5oe9r_593CerzDFFnJTLP7dp6jxzN5ZijzRfKztZtJKAQ@mail.gmail.com>
 <CA+A4wOmN73-5SmLivpgcGq-8RfDFEmRhqzU6Xxs_ZbAyO9gH2w@mail.gmail.com>
 <CA+A4wO=1aGtEV45gyAr7c7XgzKc0bGVztYT_jit71zgcd-BEog@mail.gmail.com>
 <CAH6Pt5oOf=Rm4is5ryNdXZ=D73B7-sJdvS3pw9K7Zgh-WvRZCA@mail.gmail.com>
Message-ID: <CA+A4wOnvzfZjngi7djCJVdDZn8qFJsKk3neCXZgzgH8U4aJ1Pw@mail.gmail.com>

hi matthew,

thanks for all the responses.

i liked nibabel's simple heuristics for reading data with scl_slope, but
thinking back over those discussions, i'm now thinking of the following
implementation level details for the load/save api for nifti:

- raise errors for non-valid Nifti's (scl_slope != 0  and scl_intercept ==
nan, scl_slope == nan), perhaps this already happens, but sounds like we
change scl_slope to 1, for scl_slope == nan

- scl_slope == 0 should always have a way of returning the default
data_type. while there is return unscaled data, it would be nice if there
was a function to return scaled or unscaled data depending on scl_slope.

----
if scl_slope == nan or (fabs(scl_slope) > 0 and scl_intercept == nan) :
    raise ValueError(' improperly defined scl_slope/intercept in nifti
header')

if scl_slope == 0:
    return unscaled_memory_mapped_data_in_native_datatype # assuming non gz

return scaled_data_as_float
----

i can write this function in my code, but it would be nice if this helper
function existed in nibabel

- saving - if we can put a dirty bit on memory mapped objects (i have a
faint recollection that this already exists), then:

----
if not dirty:
    save with original dtype
else:
    save_with_heuristic_or_user_specified_dtype # as currently done
----

a few more questions:

1. since get_data is part of a more generic api in nibabel, do we expect
every format to return data as float?

2. how would you deal with RGB data in a nifti file or the many other
intent codes that are rarely used? however, with cifti being nifti2 many of
those codes are in fact used.

cheers,

satra

On Wed, Jul 8, 2015 at 10:18 AM, Matthew Brett <matthew.brett at gmail.com>
wrote:

> On Wed, Jul 8, 2015 at 3:36 AM, Satrajit Ghosh <satra at mit.edu> wrote:
> > hi matthew,
> >
> > quick follow up question on proposed change. would saving the image back
> to
> > disk restore the original datatype? i.e. i read a uint8 image and save
> it to
> > another location, would that new file by 8 times the size of the original
> > file?
>
> If the image to be saved was created with a header, then save uses the
> defined dtype in the header.  If it was defined without a header, then
> save uses the array dtype to save the data.
>
> If you load and the save an int8 image with not-default scaling, the
> image has a defined header with dtype int8, but the in-memory dtype
> will be float, because of the scaling.   When saving, nibabel
> calculates the optimal scalefactors for the floating point array,
> where optimal means using all of the output data range from -128 to
> 127.   This might well be different from the scaling in the loaded
> image.   Nibabel does this because you might have changed the
> in-memory array so we can't depend on the previous scaling being
> valid.
>
> See you,
>
> 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/20150708/86db1c51/attachment.html>

From matthew.brett at gmail.com  Wed Jul  8 17:46:54 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Wed, 8 Jul 2015 16:46:54 +0100
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CA+A4wOnvzfZjngi7djCJVdDZn8qFJsKk3neCXZgzgH8U4aJ1Pw@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <15173e6e-0fd8-4e8a-8021-5bfaac090d09@typeapp.com>
 <CANgTvZgMZJkkqatN6eoq--uWepW50e_86x-BWKD7cJFc-BRu9w@mail.gmail.com>
 <CAH6Pt5pk4SNLKcP_WDuFX2KNQ3G0yQQs6qqjcihmF1ON4ioEWA@mail.gmail.com>
 <CAM=pu+Lfb+LjCwObMfSJyn2sF2QehHERdNhkHDvseGQdcLnung@mail.gmail.com>
 <1098529858.1656268.1436200330354.JavaMail.zimbra@inria.fr>
 <CAH6Pt5qLuNCsWuHtH7RecHXGYyim8HBL0Lj9dY_zYshVw1ZCDQ@mail.gmail.com>
 <559AD3C8.8020202@inria.fr>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741DC0@EXMB10.ohsu.edu>
 <CAE_wbFvfHYgFvCV_1-K6uG8KL0RHgDjhD6kixqObd7DiAtQvrw@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F741E3E@EXMB10.ohsu.edu>
 <559AF71E.4060502@stanford.edu>
 <CA+A4wOmGKLgWGh7M4X6AEjRu35rhQYS5GE07F2ZQ79Voc1M_Ng@mail.gmail.com>
 <CAH6Pt5oe9r_593CerzDFFnJTLP7dp6jxzN5ZijzRfKztZtJKAQ@mail.gmail.com>
 <CA+A4wOmN73-5SmLivpgcGq-8RfDFEmRhqzU6Xxs_ZbAyO9gH2w@mail.gmail.com>
 <CA+A4wO=1aGtEV45gyAr7c7XgzKc0bGVztYT_jit71zgcd-BEog@mail.gmail.com>
 <CAH6Pt5oOf=Rm4is5ryNdXZ=D73B7-sJdvS3pw9K7Zgh-WvRZCA@mail.gmail.com>
 <CA+A4wOnvzfZjngi7djCJVdDZn8qFJsKk3neCXZgzgH8U4aJ1Pw@mail.gmail.com>
Message-ID: <CAH6Pt5rhCmnb2+5d0Use9mohpLsm3fDB4qBOmJMi+T2z6GXKrQ@mail.gmail.com>

Hi,

On Wed, Jul 8, 2015 at 4:27 PM, Satrajit Ghosh <satra at mit.edu> wrote:
> hi matthew,
>
> thanks for all the responses.
>
> i liked nibabel's simple heuristics for reading data with scl_slope, but
> thinking back over those discussions, i'm now thinking of the following
> implementation level details for the load/save api for nifti:
>
> - raise errors for non-valid Nifti's (scl_slope != 0  and scl_intercept ==
> nan, scl_slope == nan), perhaps this already happens, but sounds like we
> change scl_slope to 1, for scl_slope == nan

I don't think we do do this, we just fix it.   I'd rather not change
the current API unless there's a good reason to raise an error.  There
are a lot of messy niftis out there.

> - scl_slope == 0 should always have a way of returning the default
> data_type. while there is return unscaled data, it would be nice if there
> was a function to return scaled or unscaled data depending on scl_slope.

You want a new separate path for the case where the slope == 0?   It's
possible, but I really don't want that as a default, because I don't
think nifti image authors in general intend slope == 0 to have that
meaning.

> - saving - if we can put a dirty bit on memory mapped objects (i have a
> faint recollection that this already exists), then:
>
> ----
> if not dirty:
>     save with original dtype
> else:
>     save_with_heuristic_or_user_specified_dtype # as currently done

We don't have a marker for whether the array is modified.   We could
develop a heuristic if you like, maybe open another thread for that
discussion?

> a few more questions:
>
> 1. since get_data is part of a more generic api in nibabel, do we expect
> every format to return data as float?

Yes, I guess that would be the logic.

> 2. how would you deal with RGB data in a nifti file or the many other intent
> codes that are rarely used? however, with cifti being nifti2 many of those
> codes are in fact used.

If there is a mechanism for float-scaling the data, and this mechanism
is not in near-universal practice used to identify in-memory ints /
floats then we would default to floats even if the scaling is default.

Cheers,

Matthew

From jomaroceguedag at gmail.com  Wed Jul  8 22:38:24 2015
From: jomaroceguedag at gmail.com (Jesus-Omar Ocegueda-Gonzalez)
Date: Wed, 8 Jul 2015 15:38:24 -0500
Subject: [Neuroimaging] Nibabel. Loading HCP data.
Message-ID: <CAON14K2PcFkrk3ACUeDwOD4DB3eAROy0pc6RO1F2DEF7Ype_DA@mail.gmail.com>

Hello,
I am trying to load one of the dwMRI volumes from HCP (mgh_1010:
http://www.humanconnectome.org/data/), which is large: (140, 140, 96,
552).  This causes an overflow when computing the size in bytes (this
happens when calling get_data()):

volumeutils.py:507: RuntimeWarning: overflow encountered in long_scalars

is this a known limitation of nibabel when loading large volumes?

Thanks!
-Omar.
-- 
"Cada quien es due?o de lo que calla y esclavo de lo que dice"
-Proverbio chino.
"We all are owners of what we keep silent and slaves of what we say"
-Chinese proverb.

http://www.cimat.mx/~omar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150708/583ed73b/attachment.html>

From matthew.brett at gmail.com  Wed Jul  8 23:41:15 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Wed, 8 Jul 2015 22:41:15 +0100
Subject: [Neuroimaging] Nibabel. Loading HCP data.
In-Reply-To: <CAON14K2PcFkrk3ACUeDwOD4DB3eAROy0pc6RO1F2DEF7Ype_DA@mail.gmail.com>
References: <CAON14K2PcFkrk3ACUeDwOD4DB3eAROy0pc6RO1F2DEF7Ype_DA@mail.gmail.com>
Message-ID: <CAH6Pt5r+C5A1W8rj1nQeZ_hyDQxsEg9NeCaodedAVAP9vRwKpw@mail.gmail.com>

On Wed, Jul 8, 2015 at 9:38 PM, Jesus-Omar Ocegueda-Gonzalez
<jomaroceguedag at gmail.com> wrote:
> Hello,
> I am trying to load one of the dwMRI volumes from HCP (mgh_1010:
> http://www.humanconnectome.org/data/), which is large: (140, 140, 96, 552).
> This causes an overflow when computing the size in bytes (this happens when
> calling get_data()):
>
> volumeutils.py:507: RuntimeWarning: overflow encountered in long_scalars
>
> is this a known limitation of nibabel when loading large volumes?

That is odd - what do you get for:

img.shape
img.get_data_dtype()

Cheers,

Matthew

From jomaroceguedag at gmail.com  Wed Jul  8 23:45:50 2015
From: jomaroceguedag at gmail.com (Jesus-Omar Ocegueda-Gonzalez)
Date: Wed, 8 Jul 2015 16:45:50 -0500
Subject: [Neuroimaging] Nibabel. Loading HCP data.
In-Reply-To: <CAH6Pt5r+C5A1W8rj1nQeZ_hyDQxsEg9NeCaodedAVAP9vRwKpw@mail.gmail.com>
References: <CAON14K2PcFkrk3ACUeDwOD4DB3eAROy0pc6RO1F2DEF7Ype_DA@mail.gmail.com>
 <CAH6Pt5r+C5A1W8rj1nQeZ_hyDQxsEg9NeCaodedAVAP9vRwKpw@mail.gmail.com>
Message-ID: <CAON14K1S_U=jEV9bJJFOG-DS4YPWAP90S95xOT-oA3uM68T5zA@mail.gmail.com>

I get the following:
In [17]: dwi_nib.shape
Out[17]: (140, 140, 96, 552)
In [18]: dwi_nib.get_data_dtype()
Out[18]: dtype('<f4')
In [19]: np.prod(dwi_nib.shape) * 4
Out[19]: -140394496
In [20]: np.int64(np.prod(dwi_nib.shape)) * 4
Out[20]: 4154572800

On Wed, Jul 8, 2015 at 4:41 PM, Matthew Brett <matthew.brett at gmail.com>
wrote:

> On Wed, Jul 8, 2015 at 9:38 PM, Jesus-Omar Ocegueda-Gonzalez
> <jomaroceguedag at gmail.com> wrote:
> > Hello,
> > I am trying to load one of the dwMRI volumes from HCP (mgh_1010:
> > http://www.humanconnectome.org/data/), which is large: (140, 140, 96,
> 552).
> > This causes an overflow when computing the size in bytes (this happens
> when
> > calling get_data()):
> >
> > volumeutils.py:507: RuntimeWarning: overflow encountered in long_scalars
> >
> > is this a known limitation of nibabel when loading large volumes?
>
> That is odd - what do you get for:
>
> img.shape
> img.get_data_dtype()
>
> Cheers,
>
> Matthew
> _______________________________________________
> Neuroimaging mailing list
> Neuroimaging at python.org
> https://mail.python.org/mailman/listinfo/neuroimaging
>



-- 
"Cada quien es due?o de lo que calla y esclavo de lo que dice"
-Proverbio chino.
"We all are owners of what we keep silent and slaves of what we say"
-Chinese proverb.

http://www.cimat.mx/~omar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150708/d77f1b1b/attachment.html>

From matthew.brett at gmail.com  Thu Jul  9 00:03:43 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Wed, 8 Jul 2015 23:03:43 +0100
Subject: [Neuroimaging] Nibabel. Loading HCP data.
In-Reply-To: <CAON14K1S_U=jEV9bJJFOG-DS4YPWAP90S95xOT-oA3uM68T5zA@mail.gmail.com>
References: <CAON14K2PcFkrk3ACUeDwOD4DB3eAROy0pc6RO1F2DEF7Ype_DA@mail.gmail.com>
 <CAH6Pt5r+C5A1W8rj1nQeZ_hyDQxsEg9NeCaodedAVAP9vRwKpw@mail.gmail.com>
 <CAON14K1S_U=jEV9bJJFOG-DS4YPWAP90S95xOT-oA3uM68T5zA@mail.gmail.com>
Message-ID: <CAH6Pt5oCz2uNoYuDU7weU9jJPG+fyBxi1xT4Ky5ce2rtwYUyew@mail.gmail.com>

On Wed, Jul 8, 2015 at 10:45 PM, Jesus-Omar Ocegueda-Gonzalez
<jomaroceguedag at gmail.com> wrote:
> I get the following:
> In [17]: dwi_nib.shape
> Out[17]: (140, 140, 96, 552)
> In [18]: dwi_nib.get_data_dtype()
> Out[18]: dtype('<f4')
> In [19]: np.prod(dwi_nib.shape) * 4
> Out[19]: -140394496
> In [20]: np.int64(np.prod(dwi_nib.shape)) * 4
> Out[20]: 4154572800

Most unfortunately, it looks as though numpy casts to int32 by default
on 32-bit platforms, which is what is causing this problem.

Your fix is fine, I'll submit another in a little while.

Cheers,

Matthew

From matthew.brett at gmail.com  Thu Jul  9 00:47:28 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Wed, 8 Jul 2015 23:47:28 +0100
Subject: [Neuroimaging] Nibabel. Loading HCP data.
In-Reply-To: <CAH6Pt5oCz2uNoYuDU7weU9jJPG+fyBxi1xT4Ky5ce2rtwYUyew@mail.gmail.com>
References: <CAON14K2PcFkrk3ACUeDwOD4DB3eAROy0pc6RO1F2DEF7Ype_DA@mail.gmail.com>
 <CAH6Pt5r+C5A1W8rj1nQeZ_hyDQxsEg9NeCaodedAVAP9vRwKpw@mail.gmail.com>
 <CAON14K1S_U=jEV9bJJFOG-DS4YPWAP90S95xOT-oA3uM68T5zA@mail.gmail.com>
 <CAH6Pt5oCz2uNoYuDU7weU9jJPG+fyBxi1xT4Ky5ce2rtwYUyew@mail.gmail.com>
Message-ID: <CAH6Pt5oZ2-P32yTo+c81=_Lzkj4WFPh9zGgOURkTtK01BZoMtg@mail.gmail.com>

On Wed, Jul 8, 2015 at 11:03 PM, Matthew Brett <matthew.brett at gmail.com> wrote:
> On Wed, Jul 8, 2015 at 10:45 PM, Jesus-Omar Ocegueda-Gonzalez
> <jomaroceguedag at gmail.com> wrote:
>> I get the following:
>> In [17]: dwi_nib.shape
>> Out[17]: (140, 140, 96, 552)
>> In [18]: dwi_nib.get_data_dtype()
>> Out[18]: dtype('<f4')
>> In [19]: np.prod(dwi_nib.shape) * 4
>> Out[19]: -140394496
>> In [20]: np.int64(np.prod(dwi_nib.shape)) * 4
>> Out[20]: 4154572800
>
> Most unfortunately, it looks as though numpy casts to int32 by default
> on 32-bit platforms, which is what is causing this problem.
>
> Your fix is fine, I'll submit another in a little while.

https://github.com/numpy/numpy/issues/6056

https://github.com/nipy/nibabel/pull/325

Having said that, I don't think your 32-bit platform can handle an
array of that size anyway...

Cheers,

Matthew

From jomaroceguedag at gmail.com  Thu Jul  9 06:19:36 2015
From: jomaroceguedag at gmail.com (Jesus-Omar Ocegueda-Gonzalez)
Date: Wed, 8 Jul 2015 23:19:36 -0500
Subject: [Neuroimaging] Nibabel. Loading HCP data.
In-Reply-To: <CAH6Pt5oZ2-P32yTo+c81=_Lzkj4WFPh9zGgOURkTtK01BZoMtg@mail.gmail.com>
References: <CAON14K2PcFkrk3ACUeDwOD4DB3eAROy0pc6RO1F2DEF7Ype_DA@mail.gmail.com>
 <CAH6Pt5r+C5A1W8rj1nQeZ_hyDQxsEg9NeCaodedAVAP9vRwKpw@mail.gmail.com>
 <CAON14K1S_U=jEV9bJJFOG-DS4YPWAP90S95xOT-oA3uM68T5zA@mail.gmail.com>
 <CAH6Pt5oCz2uNoYuDU7weU9jJPG+fyBxi1xT4Ky5ce2rtwYUyew@mail.gmail.com>
 <CAH6Pt5oZ2-P32yTo+c81=_Lzkj4WFPh9zGgOURkTtK01BZoMtg@mail.gmail.com>
Message-ID: <CAON14K06KygyDOM9aZM5wiJq_OuNbKLgFzZQvH=5=7D3aHtHJg@mail.gmail.com>

Thanks Matthew!,
regarding my platform, it's 64 bits, but as @seberg just mentioned here
https://github.com/numpy/numpy/issues/6056, in windows it defaults to
 int32 even on a 64-bit platform.

On Wed, Jul 8, 2015 at 5:47 PM, Matthew Brett <matthew.brett at gmail.com>
wrote:

> On Wed, Jul 8, 2015 at 11:03 PM, Matthew Brett <matthew.brett at gmail.com>
> wrote:
> > On Wed, Jul 8, 2015 at 10:45 PM, Jesus-Omar Ocegueda-Gonzalez
> > <jomaroceguedag at gmail.com> wrote:
> >> I get the following:
> >> In [17]: dwi_nib.shape
> >> Out[17]: (140, 140, 96, 552)
> >> In [18]: dwi_nib.get_data_dtype()
> >> Out[18]: dtype('<f4')
> >> In [19]: np.prod(dwi_nib.shape) * 4
> >> Out[19]: -140394496
> >> In [20]: np.int64(np.prod(dwi_nib.shape)) * 4
> >> Out[20]: 4154572800
> >
> > Most unfortunately, it looks as though numpy casts to int32 by default
> > on 32-bit platforms, which is what is causing this problem.
> >
> > Your fix is fine, I'll submit another in a little while.
>
> https://github.com/numpy/numpy/issues/6056
>
> https://github.com/nipy/nibabel/pull/325
>
> Having said that, I don't think your 32-bit platform can handle an
> array of that size anyway...
>
> Cheers,
>
> Matthew
> _______________________________________________
> Neuroimaging mailing list
> Neuroimaging at python.org
> https://mail.python.org/mailman/listinfo/neuroimaging
>



-- 
"Cada quien es due?o de lo que calla y esclavo de lo que dice"
-Proverbio chino.
"We all are owners of what we keep silent and slaves of what we say"
-Chinese proverb.

http://www.cimat.mx/~omar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150708/48b692ad/attachment.html>

From rafaelnh21 at gmail.com  Thu Jul  9 19:57:01 2015
From: rafaelnh21 at gmail.com (Rafael Henriques)
Date: Thu, 9 Jul 2015 18:57:01 +0100
Subject: [Neuroimaging] [Dipy] Scanning parameters of Dipy's sample data
 Sherbrooke's 3 shells
Message-ID: <CALQBObLp2Y_k+DNhMUytvhS3Z4gzce2DKshxz_sHc2xQXibxXw@mail.gmail.com>

Hi Max,

Thanks for your fast reply.

Indeed kurtosis values depend on Delta/delta (e.g.
http://www.ncbi.nlm.nih.gov/pubmed/23536232), however knowing only the
basic parameters as TE/TR and voxel resolution should be enough to
understand what is going wrong with this dataset.

I think that the problem here might be an insufficient SNR for fitting the
diffusion kurtosis model. From previous datasets that I analysed, I was
able to obtain decent DKI reconstructions using similar gradient directions
and b-values, however this was done on a 3T Siemens using a 32 coil head
channel.

I will give a look to the datasets SNR estimates.

Thanks for your help =),

Rafael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150709/5a34daa3/attachment.html>

From iosorio at udec.cl  Tue Jul 14 00:00:14 2015
From: iosorio at udec.cl (Ignacio Javier Osorio Wallace)
Date: Mon, 13 Jul 2015 19:00:14 -0300
Subject: [Neuroimaging] [Dipy] Problem with QuickBundle
Message-ID: <7e828d2d20e54fac340af91bd7e8204f@udec.cl>

Hello there, my name is Ignacio Osorio Wallace, I'm an electronic 
engineer student at Concepcion University (Chile). I'm currently working 
on the creating of a software that could use your library to reconstruct 
and segment brain fiber from the NIfTI1Image objects.

I followed your examples to get a hint of how to work with Dipy. And I'm 
having some problems with the QuickBundle. The specific problem is shown 
here:

"""
Traceback (most recent call last):
   File "/home/cocobio/MEGA/2015/Python/Project/segment_quickbundles.py", 
line 43, in <module>
     clusters = qb.cluster(streamlines)
   File 
"/usr/local/lib/python2.7/dist-packages/dipy/segment/clustering.py", 
line 459, in cluster
     ordering=ordering)
   File "dipy/segment/clustering_algorithms.pyx", line 111, in 
dipy.segment.clustering_algorithms.quickbundles 
(dipy/segment/clustering_algorithms.c:3179)
   File "dipy/segment/clusteringspeed.pyx", line 273, in 
dipy.segment.clusteringspeed.QuickBundles.assignment_step 
(dipy/segment/clusteringspeed.c:3840)
ValueError: Data features' shapes must be compatible according to the 
metric used!
"""

I think I'm not doing anything wrong, since this is the example code 
provided by the Dipy web-page. The reconstruction and tracking using ODF 
is working perfectly.

If you could help in any way, I will greatly appreciate.

Thanks for your time. And I hope my English didn't sound to casual.

Ignacio Osorio Wallace.

From garyfallidis at gmail.com  Tue Jul 14 00:15:00 2015
From: garyfallidis at gmail.com (Eleftherios Garyfallidis)
Date: Mon, 13 Jul 2015 18:15:00 -0400
Subject: [Neuroimaging] [Dipy] Problem with QuickBundle
In-Reply-To: <7e828d2d20e54fac340af91bd7e8204f@udec.cl>
References: <7e828d2d20e54fac340af91bd7e8204f@udec.cl>
Message-ID: <CAN6JmWNc3gF=unGHYd-v5Fxujt78GvQy-KaA8BkwuSOeoVopAA@mail.gmail.com>

Hi Ignacio,

Thank you for your question. We are currently changing the API of
QuickBundles. Most likely you are using the documentation from the
development version but running code from a released version?

Can you try

import dipy
dipy.get_info()

and tell me here what you are getting?

Many thanks,
Eleftherios


On Mon, Jul 13, 2015 at 6:00 PM, Ignacio Javier Osorio Wallace <
iosorio at udec.cl> wrote:

> Hello there, my name is Ignacio Osorio Wallace, I'm an electronic engineer
> student at Concepcion University (Chile). I'm currently working on the
> creating of a software that could use your library to reconstruct and
> segment brain fiber from the NIfTI1Image objects.
>
> I followed your examples to get a hint of how to work with Dipy. And I'm
> having some problems with the QuickBundle. The specific problem is shown
> here:
>
> """
> Traceback (most recent call last):
>   File "/home/cocobio/MEGA/2015/Python/Project/segment_quickbundles.py",
> line 43, in <module>
>     clusters = qb.cluster(streamlines)
>   File
> "/usr/local/lib/python2.7/dist-packages/dipy/segment/clustering.py", line
> 459, in cluster
>     ordering=ordering)
>   File "dipy/segment/clustering_algorithms.pyx", line 111, in
> dipy.segment.clustering_algorithms.quickbundles
> (dipy/segment/clustering_algorithms.c:3179)
>   File "dipy/segment/clusteringspeed.pyx", line 273, in
> dipy.segment.clusteringspeed.QuickBundles.assignment_step
> (dipy/segment/clusteringspeed.c:3840)
> ValueError: Data features' shapes must be compatible according to the
> metric used!
> """
>
> I think I'm not doing anything wrong, since this is the example code
> provided by the Dipy web-page. The reconstruction and tracking using ODF is
> working perfectly.
>
> If you could help in any way, I will greatly appreciate.
>
> Thanks for your time. And I hope my English didn't sound to casual.
>
> Ignacio Osorio Wallace.
> _______________________________________________
> 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/20150713/5dd57fac/attachment.html>

From iosorio at udec.cl  Tue Jul 14 21:47:41 2015
From: iosorio at udec.cl (Ignacio Javier Osorio Wallace)
Date: Tue, 14 Jul 2015 16:47:41 -0300
Subject: [Neuroimaging] [Dipy] Problem with QuickBundle
In-Reply-To: <CAN6JmWNc3gF=unGHYd-v5Fxujt78GvQy-KaA8BkwuSOeoVopAA@mail.gmail.com>
References: <7e828d2d20e54fac340af91bd7e8204f@udec.cl>
 <CAN6JmWNc3gF=unGHYd-v5Fxujt78GvQy-KaA8BkwuSOeoVopAA@mail.gmail.com>
Message-ID: <9957c8a9d128950ffeb39f58c47be74f@udec.cl>

Hi Eleftherios,

Thanks for replying so soon.

What i got from dipy.get_info() was:

{'sys_version': '2.7.9 (default, Dec 10 2014, 12:24:55) [MSC v.1500 32 
bit (Intel)]', 'commit_source': '(none found)', 'np_version': '1.9.2', 
'commit_hash': '<not found>', 'pkg_path': 
'C:\\Python27\\lib\\site-packages\\dipy', 'sys_executable': 
'C:\\Python27\\python.exe', 'sys_platform': 'win32'}

I hope this will help.

Many thanks,
Ignacio.

El 2015-07-13 19:15, Eleftherios Garyfallidis escribi?:
> Hi Ignacio,
> 
> Thank you for your question. We are currently changing the API of
> QuickBundles. Most likely you are using the documentation from the
> development version but running code from a released version?
> 
> Can you try
> 
> import dipy
> dipy.get_info()
> 
> and tell me here what you are getting?
> 
> Many thanks,
> Eleftherios
> 
> On Mon, Jul 13, 2015 at 6:00 PM, Ignacio Javier Osorio Wallace
> <iosorio at udec.cl> wrote:
> 
>> Hello there, my name is Ignacio Osorio Wallace, I'm an electronic
>> engineer student at Concepcion University (Chile). I'm currently
>> working on the creating of a software that could use your library to
>> reconstruct and segment brain fiber from the NIfTI1Image objects.
>> 
>> I followed your examples to get a hint of how to work with Dipy.
>> And I'm having some problems with the QuickBundle. The specific
>> problem is shown here:
>> 
>> """
>> Traceback (most recent call last):
>> ? File
>> "/home/cocobio/MEGA/2015/Python/Project/segment_quickbundles.py",
>> line 43, in <module>
>> ? ? clusters = qb.cluster(streamlines)
>> ? File
>> "/usr/local/lib/python2.7/dist-packages/dipy/segment/clustering.py",
>> line 459, in cluster
>> ? ? ordering=ordering)
>> ? File "dipy/segment/clustering_algorithms.pyx", line 111, in
>> dipy.segment.clustering_algorithms.quickbundles
>> (dipy/segment/clustering_algorithms.c:3179)
>> ? File "dipy/segment/clusteringspeed.pyx", line 273, in
>> dipy.segment.clusteringspeed.QuickBundles.assignment_step
>> (dipy/segment/clusteringspeed.c:3840)
>> ValueError: Data features' shapes must be compatible according to
>> the metric used!
>> """
>> 
>> I think I'm not doing anything wrong, since this is the example
>> code provided by the Dipy web-page. The reconstruction and tracking
>> using ODF is working perfectly.
>> 
>> If you could help in any way, I will greatly appreciate.
>> 
>> Thanks for your time. And I hope my English didn't sound to casual.
>> 
>> Ignacio Osorio Wallace.
>> _______________________________________________
>> Neuroimaging mailing list
>> Neuroimaging at python.org
>> https://mail.python.org/mailman/listinfo/neuroimaging [1]
> 
> 
> 
> Links:
> ------
> [1] https://mail.python.org/mailman/listinfo/neuroimaging
> 
> _______________________________________________
> Neuroimaging mailing list
> Neuroimaging at python.org
> https://mail.python.org/mailman/listinfo/neuroimaging

From garyfallidis at gmail.com  Tue Jul 14 21:57:16 2015
From: garyfallidis at gmail.com (Eleftherios Garyfallidis)
Date: Tue, 14 Jul 2015 15:57:16 -0400
Subject: [Neuroimaging] [Dipy] Problem with QuickBundle
In-Reply-To: <9957c8a9d128950ffeb39f58c47be74f@udec.cl>
References: <7e828d2d20e54fac340af91bd7e8204f@udec.cl>
 <CAN6JmWNc3gF=unGHYd-v5Fxujt78GvQy-KaA8BkwuSOeoVopAA@mail.gmail.com>
 <9957c8a9d128950ffeb39f58c47be74f@udec.cl>
Message-ID: <CAN6JmWP5EdHuC2-HrMPFDdHHxyQC0UahBT6ufkkR+V_nP8f_+Q@mail.gmail.com>

And what

dipy.__version__

is giving you?

On Tue, Jul 14, 2015 at 3:47 PM, Ignacio Javier Osorio Wallace <
iosorio at udec.cl> wrote:

> Hi Eleftherios,
>
> Thanks for replying so soon.
>
> What i got from dipy.get_info() was:
>
> {'sys_version': '2.7.9 (default, Dec 10 2014, 12:24:55) [MSC v.1500 32 bit
> (Intel)]', 'commit_source': '(none found)', 'np_version': '1.9.2',
> 'commit_hash': '<not found>', 'pkg_path':
> 'C:\\Python27\\lib\\site-packages\\dipy', 'sys_executable':
> 'C:\\Python27\\python.exe', 'sys_platform': 'win32'}
>
> I hope this will help.
>
> Many thanks,
> Ignacio.
>
>
> El 2015-07-13 19:15, Eleftherios Garyfallidis escribi?:
>
>> Hi Ignacio,
>>
>> Thank you for your question. We are currently changing the API of
>> QuickBundles. Most likely you are using the documentation from the
>> development version but running code from a released version?
>>
>> Can you try
>>
>> import dipy
>> dipy.get_info()
>>
>> and tell me here what you are getting?
>>
>> Many thanks,
>> Eleftherios
>>
>> On Mon, Jul 13, 2015 at 6:00 PM, Ignacio Javier Osorio Wallace
>> <iosorio at udec.cl> wrote:
>>
>>  Hello there, my name is Ignacio Osorio Wallace, I'm an electronic
>>> engineer student at Concepcion University (Chile). I'm currently
>>> working on the creating of a software that could use your library to
>>> reconstruct and segment brain fiber from the NIfTI1Image objects.
>>>
>>> I followed your examples to get a hint of how to work with Dipy.
>>> And I'm having some problems with the QuickBundle. The specific
>>> problem is shown here:
>>>
>>> """
>>> Traceback (most recent call last):
>>>   File
>>> "/home/cocobio/MEGA/2015/Python/Project/segment_quickbundles.py",
>>> line 43, in <module>
>>>     clusters = qb.cluster(streamlines)
>>>   File
>>> "/usr/local/lib/python2.7/dist-packages/dipy/segment/clustering.py",
>>> line 459, in cluster
>>>     ordering=ordering)
>>>   File "dipy/segment/clustering_algorithms.pyx", line 111, in
>>> dipy.segment.clustering_algorithms.quickbundles
>>> (dipy/segment/clustering_algorithms.c:3179)
>>>   File "dipy/segment/clusteringspeed.pyx", line 273, in
>>> dipy.segment.clusteringspeed.QuickBundles.assignment_step
>>> (dipy/segment/clusteringspeed.c:3840)
>>> ValueError: Data features' shapes must be compatible according to
>>> the metric used!
>>> """
>>>
>>> I think I'm not doing anything wrong, since this is the example
>>> code provided by the Dipy web-page. The reconstruction and tracking
>>> using ODF is working perfectly.
>>>
>>> If you could help in any way, I will greatly appreciate.
>>>
>>> Thanks for your time. And I hope my English didn't sound to casual.
>>>
>>> Ignacio Osorio Wallace.
>>> _______________________________________________
>>> Neuroimaging mailing list
>>> Neuroimaging at python.org
>>> https://mail.python.org/mailman/listinfo/neuroimaging [1]
>>>
>>
>>
>>
>> Links:
>> ------
>> [1] 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: <http://mail.python.org/pipermail/neuroimaging/attachments/20150714/80816b83/attachment.html>

From iosorio at udec.cl  Tue Jul 14 22:30:26 2015
From: iosorio at udec.cl (Ignacio Javier Osorio Wallace)
Date: Tue, 14 Jul 2015 17:30:26 -0300
Subject: [Neuroimaging] [Dipy] Problem with QuickBundle
In-Reply-To: <CAN6JmWP5EdHuC2-HrMPFDdHHxyQC0UahBT6ufkkR+V_nP8f_+Q@mail.gmail.com>
References: <7e828d2d20e54fac340af91bd7e8204f@udec.cl>
 <CAN6JmWNc3gF=unGHYd-v5Fxujt78GvQy-KaA8BkwuSOeoVopAA@mail.gmail.com>
 <9957c8a9d128950ffeb39f58c47be74f@udec.cl>
 <CAN6JmWP5EdHuC2-HrMPFDdHHxyQC0UahBT6ufkkR+V_nP8f_+Q@mail.gmail.com>
Message-ID: <27effc852e04e216612d65cd0207e168@udec.cl>

it prints: 0.9.2

El 2015-07-14 16:57, Eleftherios Garyfallidis escribi?:
> And what?
> 
> dipy.__version__
> 
> is giving you?
> 
> On Tue, Jul 14, 2015 at 3:47 PM, Ignacio Javier Osorio Wallace
> <iosorio at udec.cl> wrote:
> 
>> Hi Eleftherios,
>> 
>> Thanks for replying so soon.
>> 
>> What i got from dipy.get_info() was:
>> 
>> {'sys_version': '2.7.9 (default, Dec 10 2014, 12:24:55) [MSC v.1500
>> 32 bit (Intel)]', 'commit_source': '(none found)', 'np_version':
>> '1.9.2', 'commit_hash': '<not found>', 'pkg_path':
>> 'C:\Python27\lib\site-packages\dipy', 'sys_executable':
>> 'C:\Python27\python.exe', 'sys_platform': 'win32'}
>> 
>> I hope this will help.
>> 
>> Many thanks,
>> Ignacio.
>> 
>> El 2015-07-13 19:15, Eleftherios Garyfallidis escribi?:
>> 
>> Hi Ignacio,
>> 
>> Thank you for your question. We are currently changing the API of
>> QuickBundles. Most likely you are using the documentation from the
>> development version but running code from a released version?
>> 
>> Can you try
>> 
>> import dipy
>> dipy.get_info()
>> 
>> and tell me here what you are getting?
>> 
>> Many thanks,
>> Eleftherios
>> 
>> On Mon, Jul 13, 2015 at 6:00 PM, Ignacio Javier Osorio Wallace
>> <iosorio at udec.cl> wrote:
>> 
>> Hello there, my name is Ignacio Osorio Wallace, I'm an electronic
>> engineer student at Concepcion University (Chile). I'm currently
>> working on the creating of a software that could use your library
>> to
>> reconstruct and segment brain fiber from the NIfTI1Image objects.
>> 
>> I followed your examples to get a hint of how to work with Dipy.
>> And I'm having some problems with the QuickBundle. The specific
>> problem is shown here:
>> 
>> """
>> Traceback (most recent call last):
>> ? File
>> "/home/cocobio/MEGA/2015/Python/Project/segment_quickbundles.py",
>> line 43, in <module>
>> ? ? clusters = qb.cluster(streamlines)
>> ? File
>> "/usr/local/lib/python2.7/dist-packages/dipy/segment/clustering.py",
>> line 459, in cluster
>> ? ? ordering=ordering)
>> ? File "dipy/segment/clustering_algorithms.pyx", line 111, in
>> dipy.segment.clustering_algorithms.quickbundles
>> (dipy/segment/clustering_algorithms.c:3179)
>> ? File "dipy/segment/clusteringspeed.pyx", line 273, in
>> dipy.segment.clusteringspeed.QuickBundles.assignment_step
>> (dipy/segment/clusteringspeed.c:3840)
>> ValueError: Data features' shapes must be compatible according to
>> the metric used!
>> """
>> 
>> I think I'm not doing anything wrong, since this is the example
>> code provided by the Dipy web-page. The reconstruction and tracking
>> using ODF is working perfectly.
>> 
>> If you could help in any way, I will greatly appreciate.
>> 
>> Thanks for your time. And I hope my English didn't sound to casual.
>> 
>> Ignacio Osorio Wallace.
>> _______________________________________________
>> Neuroimaging mailing list
>> Neuroimaging at python.org
>> https://mail.python.org/mailman/listinfo/neuroimaging [1] [1]
>> 
>> Links:
>> ------
>> [1] https://mail.python.org/mailman/listinfo/neuroimaging [1]
>> 
>> _______________________________________________
>> Neuroimaging mailing list
>> Neuroimaging at python.org
>> https://mail.python.org/mailman/listinfo/neuroimaging [1]
> 
>  _______________________________________________
>  Neuroimaging mailing list
>  Neuroimaging at python.org
>  https://mail.python.org/mailman/listinfo/neuroimaging [1]
> 
> 
> 
> Links:
> ------
> [1] https://mail.python.org/mailman/listinfo/neuroimaging
> 
> _______________________________________________
> Neuroimaging mailing list
> Neuroimaging at python.org
> https://mail.python.org/mailman/listinfo/neuroimaging

From garyfallidis at gmail.com  Tue Jul 14 22:34:29 2015
From: garyfallidis at gmail.com (Eleftherios Garyfallidis)
Date: Tue, 14 Jul 2015 16:34:29 -0400
Subject: [Neuroimaging] [Dipy] Problem with QuickBundle
In-Reply-To: <27effc852e04e216612d65cd0207e168@udec.cl>
References: <7e828d2d20e54fac340af91bd7e8204f@udec.cl>
 <CAN6JmWNc3gF=unGHYd-v5Fxujt78GvQy-KaA8BkwuSOeoVopAA@mail.gmail.com>
 <9957c8a9d128950ffeb39f58c47be74f@udec.cl>
 <CAN6JmWP5EdHuC2-HrMPFDdHHxyQC0UahBT6ufkkR+V_nP8f_+Q@mail.gmail.com>
 <27effc852e04e216612d65cd0207e168@udec.cl>
Message-ID: <CAN6JmWPoJ_VAUYuTwQyXQT4TCWh=ooTZuL0YX9U5-TVPgGXi1A@mail.gmail.com>

Okay you are using the released version of Dipy.

Can you try to run this tutorial in your computer and tell me if it works
for you?

https://github.com/nipy/dipy/blob/maint/0.9.x/doc/examples/segment_quickbundles.py


On Tue, Jul 14, 2015 at 4:30 PM, Ignacio Javier Osorio Wallace <
iosorio at udec.cl> wrote:

> it prints: 0.9.2
>
>
> El 2015-07-14 16:57, Eleftherios Garyfallidis escribi?:
>
>> And what
>>
>> dipy.__version__
>>
>> is giving you?
>>
>> On Tue, Jul 14, 2015 at 3:47 PM, Ignacio Javier Osorio Wallace
>> <iosorio at udec.cl> wrote:
>>
>>  Hi Eleftherios,
>>>
>>> Thanks for replying so soon.
>>>
>>> What i got from dipy.get_info() was:
>>>
>>> {'sys_version': '2.7.9 (default, Dec 10 2014, 12:24:55) [MSC v.1500
>>> 32 bit (Intel)]', 'commit_source': '(none found)', 'np_version':
>>> '1.9.2', 'commit_hash': '<not found>', 'pkg_path':
>>> 'C:\Python27\lib\site-packages\dipy', 'sys_executable':
>>> 'C:\Python27\python.exe', 'sys_platform': 'win32'}
>>>
>>> I hope this will help.
>>>
>>> Many thanks,
>>> Ignacio.
>>>
>>> El 2015-07-13 19:15, Eleftherios Garyfallidis escribi?:
>>>
>>> Hi Ignacio,
>>>
>>> Thank you for your question. We are currently changing the API of
>>> QuickBundles. Most likely you are using the documentation from the
>>> development version but running code from a released version?
>>>
>>> Can you try
>>>
>>> import dipy
>>> dipy.get_info()
>>>
>>> and tell me here what you are getting?
>>>
>>> Many thanks,
>>> Eleftherios
>>>
>>> On Mon, Jul 13, 2015 at 6:00 PM, Ignacio Javier Osorio Wallace
>>> <iosorio at udec.cl> wrote:
>>>
>>> Hello there, my name is Ignacio Osorio Wallace, I'm an electronic
>>> engineer student at Concepcion University (Chile). I'm currently
>>> working on the creating of a software that could use your library
>>> to
>>> reconstruct and segment brain fiber from the NIfTI1Image objects.
>>>
>>> I followed your examples to get a hint of how to work with Dipy.
>>> And I'm having some problems with the QuickBundle. The specific
>>> problem is shown here:
>>>
>>> """
>>> Traceback (most recent call last):
>>>   File
>>> "/home/cocobio/MEGA/2015/Python/Project/segment_quickbundles.py",
>>> line 43, in <module>
>>>     clusters = qb.cluster(streamlines)
>>>   File
>>> "/usr/local/lib/python2.7/dist-packages/dipy/segment/clustering.py",
>>> line 459, in cluster
>>>     ordering=ordering)
>>>   File "dipy/segment/clustering_algorithms.pyx", line 111, in
>>> dipy.segment.clustering_algorithms.quickbundles
>>> (dipy/segment/clustering_algorithms.c:3179)
>>>   File "dipy/segment/clusteringspeed.pyx", line 273, in
>>> dipy.segment.clusteringspeed.QuickBundles.assignment_step
>>> (dipy/segment/clusteringspeed.c:3840)
>>> ValueError: Data features' shapes must be compatible according to
>>> the metric used!
>>> """
>>>
>>> I think I'm not doing anything wrong, since this is the example
>>> code provided by the Dipy web-page. The reconstruction and tracking
>>> using ODF is working perfectly.
>>>
>>> If you could help in any way, I will greatly appreciate.
>>>
>>> Thanks for your time. And I hope my English didn't sound to casual.
>>>
>>> Ignacio Osorio Wallace.
>>> _______________________________________________
>>> Neuroimaging mailing list
>>> Neuroimaging at python.org
>>> https://mail.python.org/mailman/listinfo/neuroimaging [1] [1]
>>>
>>> Links:
>>> ------
>>> [1] https://mail.python.org/mailman/listinfo/neuroimaging [1]
>>>
>>> _______________________________________________
>>> Neuroimaging mailing list
>>> Neuroimaging at python.org
>>> https://mail.python.org/mailman/listinfo/neuroimaging [1]
>>>
>>
>>  _______________________________________________
>>  Neuroimaging mailing list
>>  Neuroimaging at python.org
>>  https://mail.python.org/mailman/listinfo/neuroimaging [1]
>>
>>
>>
>> Links:
>> ------
>> [1] 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: <http://mail.python.org/pipermail/neuroimaging/attachments/20150714/c0ba9964/attachment.html>

From iosorio at udec.cl  Tue Jul 14 22:44:00 2015
From: iosorio at udec.cl (Ignacio Javier Osorio Wallace)
Date: Tue, 14 Jul 2015 17:44:00 -0300
Subject: [Neuroimaging] [Dipy] Problem with QuickBundle
In-Reply-To: <CAN6JmWPoJ_VAUYuTwQyXQT4TCWh=ooTZuL0YX9U5-TVPgGXi1A@mail.gmail.com>
References: <7e828d2d20e54fac340af91bd7e8204f@udec.cl>
 <CAN6JmWNc3gF=unGHYd-v5Fxujt78GvQy-KaA8BkwuSOeoVopAA@mail.gmail.com>
 <9957c8a9d128950ffeb39f58c47be74f@udec.cl>
 <CAN6JmWP5EdHuC2-HrMPFDdHHxyQC0UahBT6ufkkR+V_nP8f_+Q@mail.gmail.com>
 <27effc852e04e216612d65cd0207e168@udec.cl>
 <CAN6JmWPoJ_VAUYuTwQyXQT4TCWh=ooTZuL0YX9U5-TVPgGXi1A@mail.gmail.com>
Message-ID: <27132afc56a771dd73da43b561819188@udec.cl>

It work! Thanks for everything, now I'm going to try use it with my own 
data sets.

Thanks for your time Eleftherious.

El 2015-07-14 17:34, Eleftherios Garyfallidis escribi?:
> Okay you are using the released version of Dipy.
> 
> Can you try to run this tutorial in your computer and tell me if it
> works for you?
> 
> https://github.com/nipy/dipy/blob/maint/0.9.x/doc/examples/segment_quickbundles.py
> [2]
> 
> On Tue, Jul 14, 2015 at 4:30 PM, Ignacio Javier Osorio Wallace
> <iosorio at udec.cl> wrote:
> 
>> it prints: 0.9.2
>> 
>> El 2015-07-14 16:57, Eleftherios Garyfallidis escribi?:
>> 
>> And what?
>> 
>> dipy.__version__
>> 
>> is giving you?
>> 
>> On Tue, Jul 14, 2015 at 3:47 PM, Ignacio Javier Osorio Wallace
>> <iosorio at udec.cl> wrote:
>> 
>> Hi Eleftherios,
>> 
>> Thanks for replying so soon.
>> 
>> What i got from dipy.get_info() was:
>> 
>> {'sys_version': '2.7.9 (default, Dec 10 2014, 12:24:55) [MSC v.1500
>> 32 bit (Intel)]', 'commit_source': '(none found)', 'np_version':
>> '1.9.2', 'commit_hash': '<not found>', 'pkg_path':
>> 'C:Python27libsite-packagesdipy', 'sys_executable':
>> 'C:Python27python.exe', 'sys_platform': 'win32'}
>> 
>> I hope this will help.
>> 
>> Many thanks,
>> Ignacio.
>> 
>> El 2015-07-13 19:15, Eleftherios Garyfallidis escribi?:
>> 
>> Hi Ignacio,
>> 
>> Thank you for your question. We are currently changing the API of
>> QuickBundles. Most likely you are using the documentation from the
>> development version but running code from a released version?
>> 
>> Can you try
>> 
>> import dipy
>> dipy.get_info()
>> 
>> and tell me here what you are getting?
>> 
>> Many thanks,
>> Eleftherios
>> 
>> On Mon, Jul 13, 2015 at 6:00 PM, Ignacio Javier Osorio Wallace
>> <iosorio at udec.cl> wrote:
>> 
>> Hello there, my name is Ignacio Osorio Wallace, I'm an electronic
>> engineer student at Concepcion University (Chile). I'm currently
>> working on the creating of a software that could use your library
>> to
>> reconstruct and segment brain fiber from the NIfTI1Image objects.
>> 
>> I followed your examples to get a hint of how to work with Dipy.
>> And I'm having some problems with the QuickBundle. The specific
>> problem is shown here:
>> 
>> """
>> Traceback (most recent call last):
>> ? File
>> "/home/cocobio/MEGA/2015/Python/Project/segment_quickbundles.py",
>> line 43, in <module>
>> ? ? clusters = qb.cluster(streamlines)
>> ? File
>> "/usr/local/lib/python2.7/dist-packages/dipy/segment/clustering.py",
>> line 459, in cluster
>> ? ? ordering=ordering)
>> ? File "dipy/segment/clustering_algorithms.pyx", line 111, in
>> dipy.segment.clustering_algorithms.quickbundles
>> (dipy/segment/clustering_algorithms.c:3179)
>> ? File "dipy/segment/clusteringspeed.pyx", line 273, in
>> dipy.segment.clusteringspeed.QuickBundles.assignment_step
>> (dipy/segment/clusteringspeed.c:3840)
>> ValueError: Data features' shapes must be compatible according to
>> the metric used!
>> """
>> 
>> I think I'm not doing anything wrong, since this is the example
>> code provided by the Dipy web-page. The reconstruction and tracking
>> using ODF is working perfectly.
>> 
>> If you could help in any way, I will greatly appreciate.
>> 
>> Thanks for your time. And I hope my English didn't sound to casual.
>> 
>> Ignacio Osorio Wallace.
>> _______________________________________________
>> Neuroimaging mailing list
>> Neuroimaging at python.org
>> https://mail.python.org/mailman/listinfo/neuroimaging [1] [1] [1]
>> 
>> Links:
>> ------
>> [1] https://mail.python.org/mailman/listinfo/neuroimaging [1] [1]
>> 
>> _______________________________________________
>> Neuroimaging mailing list
>> Neuroimaging at python.org
>> https://mail.python.org/mailman/listinfo/neuroimaging [1] [1]
>> 
>> ?_______________________________________________
>> ?Neuroimaging mailing list
>> ?Neuroimaging at python.org
>> ?https://mail.python.org/mailman/listinfo/neuroimaging [1] [1]
>> 
>> Links:
>> ------
>> [1] https://mail.python.org/mailman/listinfo/neuroimaging [1]
>> 
>> _______________________________________________
>> Neuroimaging mailing list
>> Neuroimaging at python.org
>> https://mail.python.org/mailman/listinfo/neuroimaging [1]
> 
>  _______________________________________________
>  Neuroimaging mailing list
>  Neuroimaging at python.org
>  https://mail.python.org/mailman/listinfo/neuroimaging [1]
> 
> 
> 
> Links:
> ------
> [1] https://mail.python.org/mailman/listinfo/neuroimaging
> [2]
> https://github.com/nipy/dipy/blob/maint/0.9.x/doc/examples/segment_quickbundles.py
> 
> _______________________________________________
> Neuroimaging mailing list
> Neuroimaging at python.org
> https://mail.python.org/mailman/listinfo/neuroimaging

From garyfallidis at gmail.com  Tue Jul 14 22:59:20 2015
From: garyfallidis at gmail.com (Eleftherios Garyfallidis)
Date: Tue, 14 Jul 2015 16:59:20 -0400
Subject: [Neuroimaging] [Dipy] Problem with QuickBundle
In-Reply-To: <27132afc56a771dd73da43b561819188@udec.cl>
References: <7e828d2d20e54fac340af91bd7e8204f@udec.cl>
 <CAN6JmWNc3gF=unGHYd-v5Fxujt78GvQy-KaA8BkwuSOeoVopAA@mail.gmail.com>
 <9957c8a9d128950ffeb39f58c47be74f@udec.cl>
 <CAN6JmWP5EdHuC2-HrMPFDdHHxyQC0UahBT6ufkkR+V_nP8f_+Q@mail.gmail.com>
 <27effc852e04e216612d65cd0207e168@udec.cl>
 <CAN6JmWPoJ_VAUYuTwQyXQT4TCWh=ooTZuL0YX9U5-TVPgGXi1A@mail.gmail.com>
 <27132afc56a771dd73da43b561819188@udec.cl>
Message-ID: <CAN6JmWMS=k8FvRY2MpRij-jL6gfqCSq-h9OPpOvvs0UM=VgEAA@mail.gmail.com>

You are welcome Ignacio. Happy hacking!

On Tue, Jul 14, 2015 at 4:44 PM, Ignacio Javier Osorio Wallace <
iosorio at udec.cl> wrote:

> It work! Thanks for everything, now I'm going to try use it with my own
> data sets.
>
> Thanks for your time Eleftherious.
>
> El 2015-07-14 17:34, Eleftherios Garyfallidis escribi?:
>
>> Okay you are using the released version of Dipy.
>>
>> Can you try to run this tutorial in your computer and tell me if it
>> works for you?
>>
>>
>> https://github.com/nipy/dipy/blob/maint/0.9.x/doc/examples/segment_quickbundles.py
>> [2]
>>
>> On Tue, Jul 14, 2015 at 4:30 PM, Ignacio Javier Osorio Wallace
>> <iosorio at udec.cl> wrote:
>>
>>  it prints: 0.9.2
>>>
>>> El 2015-07-14 16:57, Eleftherios Garyfallidis escribi?:
>>>
>>> And what
>>>
>>> dipy.__version__
>>>
>>> is giving you?
>>>
>>> On Tue, Jul 14, 2015 at 3:47 PM, Ignacio Javier Osorio Wallace
>>> <iosorio at udec.cl> wrote:
>>>
>>> Hi Eleftherios,
>>>
>>> Thanks for replying so soon.
>>>
>>> What i got from dipy.get_info() was:
>>>
>>> {'sys_version': '2.7.9 (default, Dec 10 2014, 12:24:55) [MSC v.1500
>>> 32 bit (Intel)]', 'commit_source': '(none found)', 'np_version':
>>> '1.9.2', 'commit_hash': '<not found>', 'pkg_path':
>>> 'C:Python27libsite-packagesdipy', 'sys_executable':
>>> 'C:Python27python.exe', 'sys_platform': 'win32'}
>>>
>>>
>>> I hope this will help.
>>>
>>> Many thanks,
>>> Ignacio.
>>>
>>> El 2015-07-13 19:15, Eleftherios Garyfallidis escribi?:
>>>
>>> Hi Ignacio,
>>>
>>> Thank you for your question. We are currently changing the API of
>>> QuickBundles. Most likely you are using the documentation from the
>>> development version but running code from a released version?
>>>
>>> Can you try
>>>
>>> import dipy
>>> dipy.get_info()
>>>
>>> and tell me here what you are getting?
>>>
>>> Many thanks,
>>> Eleftherios
>>>
>>> On Mon, Jul 13, 2015 at 6:00 PM, Ignacio Javier Osorio Wallace
>>> <iosorio at udec.cl> wrote:
>>>
>>> Hello there, my name is Ignacio Osorio Wallace, I'm an electronic
>>> engineer student at Concepcion University (Chile). I'm currently
>>> working on the creating of a software that could use your library
>>> to
>>> reconstruct and segment brain fiber from the NIfTI1Image objects.
>>>
>>> I followed your examples to get a hint of how to work with Dipy.
>>> And I'm having some problems with the QuickBundle. The specific
>>> problem is shown here:
>>>
>>> """
>>> Traceback (most recent call last):
>>>   File
>>> "/home/cocobio/MEGA/2015/Python/Project/segment_quickbundles.py",
>>> line 43, in <module>
>>>     clusters = qb.cluster(streamlines)
>>>   File
>>> "/usr/local/lib/python2.7/dist-packages/dipy/segment/clustering.py",
>>> line 459, in cluster
>>>     ordering=ordering)
>>>   File "dipy/segment/clustering_algorithms.pyx", line 111, in
>>> dipy.segment.clustering_algorithms.quickbundles
>>> (dipy/segment/clustering_algorithms.c:3179)
>>>   File "dipy/segment/clusteringspeed.pyx", line 273, in
>>> dipy.segment.clusteringspeed.QuickBundles.assignment_step
>>> (dipy/segment/clusteringspeed.c:3840)
>>> ValueError: Data features' shapes must be compatible according to
>>> the metric used!
>>> """
>>>
>>> I think I'm not doing anything wrong, since this is the example
>>> code provided by the Dipy web-page. The reconstruction and tracking
>>> using ODF is working perfectly.
>>>
>>> If you could help in any way, I will greatly appreciate.
>>>
>>> Thanks for your time. And I hope my English didn't sound to casual.
>>>
>>> Ignacio Osorio Wallace.
>>> _______________________________________________
>>> Neuroimaging mailing list
>>> Neuroimaging at python.org
>>> https://mail.python.org/mailman/listinfo/neuroimaging [1] [1] [1]
>>>
>>> Links:
>>> ------
>>> [1] https://mail.python.org/mailman/listinfo/neuroimaging [1] [1]
>>>
>>> _______________________________________________
>>> Neuroimaging mailing list
>>> Neuroimaging at python.org
>>> https://mail.python.org/mailman/listinfo/neuroimaging [1] [1]
>>>
>>>  _______________________________________________
>>>  Neuroimaging mailing list
>>>  Neuroimaging at python.org
>>>  https://mail.python.org/mailman/listinfo/neuroimaging [1] [1]
>>>
>>> Links:
>>> ------
>>> [1] https://mail.python.org/mailman/listinfo/neuroimaging [1]
>>>
>>> _______________________________________________
>>> Neuroimaging mailing list
>>> Neuroimaging at python.org
>>> https://mail.python.org/mailman/listinfo/neuroimaging [1]
>>>
>>
>>  _______________________________________________
>>  Neuroimaging mailing list
>>  Neuroimaging at python.org
>>  https://mail.python.org/mailman/listinfo/neuroimaging [1]
>>
>>
>>
>> Links:
>> ------
>> [1] https://mail.python.org/mailman/listinfo/neuroimaging
>> [2]
>>
>> https://github.com/nipy/dipy/blob/maint/0.9.x/doc/examples/segment_quickbundles.py
>>
>> _______________________________________________
>> 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/20150714/0874ad14/attachment.html>

From matthew.brett at gmail.com  Sat Jul 18 15:43:35 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Sat, 18 Jul 2015 14:43:35 +0100
Subject: [Neuroimaging] Nibabel developer hangout early
Message-ID: <CAH6Pt5pCNWuvRjb+CFAYTj3oSBTyD_8-st7GA5FT8-ujYHbqdw@mail.gmail.com>

Hi,

It seems to be time for another nibabel developer hangout.

We need to discuss:

* the `as_float` keyword to the `get_data()` method;
* using the `load` function or a new `load_multi` function to load
file formats that can have more than one image in the same file;
* whether to standardize to having time / volume as the fourth axis on
all image formats (not currently the case for MINC);
* (related) plan for adding names / labels for image axes;
* BrainVoyager format support : https://github.com/nipy/nibabel/pull/216

I'll put up some text on the wiki today, and send the links for y'all
to read if you are interested.

Please fill out the doodle to choose a time on Monday, Tuesday,
Wednesday next week:  http://doodle.com/tmhhwf39gi5k4rp2

Cheers,

Matthew

From matthew.brett at gmail.com  Sat Jul 18 15:45:31 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Sat, 18 Jul 2015 14:45:31 +0100
Subject: [Neuroimaging] Nibabel developer hangout early
In-Reply-To: <CAH6Pt5pCNWuvRjb+CFAYTj3oSBTyD_8-st7GA5FT8-ujYHbqdw@mail.gmail.com>
References: <CAH6Pt5pCNWuvRjb+CFAYTj3oSBTyD_8-st7GA5FT8-ujYHbqdw@mail.gmail.com>
Message-ID: <CAH6Pt5qmjDV-6WF03vgThT_LPGkEMs0zQVjaLTCUhUCM5w3HXQ@mail.gmail.com>

Hi,

On Sat, Jul 18, 2015 at 2:43 PM, Matthew Brett <matthew.brett at gmail.com> wrote:
> Hi,
>
> It seems to be time for another nibabel developer hangout.

Sorry - the email title should read 'Nibabel hangout early next week".

See youse,

Matthew

From matthew.brett at gmail.com  Sat Jul 18 18:10:15 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Sat, 18 Jul 2015 17:10:15 +0100
Subject: [Neuroimaging] Nibabel developer hangout early
In-Reply-To: <CAH6Pt5pCNWuvRjb+CFAYTj3oSBTyD_8-st7GA5FT8-ujYHbqdw@mail.gmail.com>
References: <CAH6Pt5pCNWuvRjb+CFAYTj3oSBTyD_8-st7GA5FT8-ujYHbqdw@mail.gmail.com>
Message-ID: <CAH6Pt5pgLOJMQOV4a__QgYv1FQEkE0t+vauHwR4btF3W1ipjKw@mail.gmail.com>

Hi,

As promised, here is the reading for the topics of the hangout:

On Sat, Jul 18, 2015 at 2:43 PM, Matthew Brett <matthew.brett at gmail.com> wrote:
> Hi,
>
> It seems to be time for another nibabel developer hangout.
>
> We need to discuss:
>
> * the `as_float` keyword to the `get_data()` method;

https://mail.python.org/pipermail/neuroimaging/2015-July/000021.html
and following.

> * using the `load` function or a new `load_multi` function to load
> file formats that can have more than one image in the same file;

https://github.com/nipy/nibabel/wiki/BIAP7

> * whether to standardize to having time / volume as the fourth axis on
> all image formats (not currently the case for MINC);

https://github.com/nipy/nibabel/wiki/BIAP6

> * (related) plan for adding names / labels for image axes;

Also in https://github.com/nipy/nibabel/wiki/BIAP6

> * BrainVoyager format support : https://github.com/nipy/nibabel/pull/216

See also : https://github.com/nipy/nibabel/blob/master/doc/source/devel/bv_formats.rst

Please feel free to edit and expand the stuff on the nibabel wiki.

Cheers,

Matthew

From matthew.brett at gmail.com  Sat Jul 18 18:25:03 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Sat, 18 Jul 2015 17:25:03 +0100
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <20150706155516.GA28964@onerussian.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <20150706155516.GA28964@onerussian.com>
Message-ID: <CAH6Pt5q8q+9Jomxy62PLKBRub7OYzVr+fQ_di+yjaa-vON=6VA@mail.gmail.com>

Hi,

Sorry to be late to reply to this one.

On Mon, Jul 6, 2015 at 4:55 PM, Yaroslav Halchenko <lists at onerussian.com> wrote:
>
> On Mon, 06 Jul 2015, Matthew Brett wrote:
>
>> Hi,
>
>> I wanted to ask y'all about an API change that I want to make to nibabel.
>
>> In summary, I want to default to returning floating point arrays from
>> nibabel images.
>
>> Problem - different returned data types from img.get_data()
>> -------------------------------------------------------------------------------
>
>> At the moment, if you do this:
>
>> img = nib.load('my_image.nii')
>> data = img.get_data()
>
>> Then the data type (dtype) of the returned data array depends on the
>> values in the header of `my_image.nii`.   Specifically, if the raw
>> on-disk data type is 'np.int16' (it is often is) and the header
>> scalefactor values are default (1 for slope, 0 for intercept) then you
>> will get back an array of the on disk data type - here - np.int16.
>
>> This is very efficient on memory, but it it's a real trap unless you careful.
>
>> For example, let's say you had a pipeline where you did this:
>
>> sum = img.get_data().sum()
>
>> That would work fine most of the time, when the data on disk is
>> floating point, or the scalefactors are not default (1, 0).   Then one
>> day, you get an image with int16 data type on disk and 1, 0
>> scalefactors, and your `sum` calculation silently overflows.    I ran
>> into this when teaching - I had to cast some image arrays to floating
>> point to get sensible answers.
>
>> Solution
>> -----------
>
>> I think that the default behavior of nibabel should be to do the thing
>> least likely to trip you up by accident, so - I think in due course,
>> nibabel should always return a floating point array from `get_data()`
>> by default.
>
>> I propose to add a keyword-only argument to `get_data()` - `to_float`, as in:
>
>> data = img.get_data(to_float=False)  # The current default behavior
>> data = img.get_data(to_float=True)  # Integer arrays automatically
>> cast to float64
>
>> For this cycle (the nibabel 2.0 series), I propose to raise a warning
>> if you don't pass in an explicit True or False, warning that the
>> default behavior for nibabel 3.0 will change from `to_float=False` to
>> `to_float=True`.
>
>> The other, more fancy ways of getting the image data would continue as
>> they are, such as:
>
>> data = np.array(img.dataobj)
>> data = img.dataobj[:]
>
>> These will both return ints or floats depending on the raw data dtype
>> and the scalefactors.  This is on the basis that people using these
>> will be more advanced and so therefore more likely to want memory
>> efficiency at the expense of having to be careful about the returned
>> data dtype.
>
>> Does this seem reasonable to y'all?    Thoughts, suggestions?
>
> Overall I am all for reducing a possibility for users shotting
> themselves in a foot.  But this API change would still conflate two
> (related) issues here:  memory mapping and casting.  May be there is a
> way to clear it up?  Sorry for not providing an answer but at
> least let me share the use case(s):
>
> with to_float=True it would then keep memory mapping float .nii
> while int .nii would get casted.  So it would remain somewhat obfuscated
> when data gets memmapped and when not.  In our (PyMVPA) case we don't
> really care about correct offset/scale in many cases (data gets zscored
> anyways per each voxel later on with appropriate casting if necessary).

Yes, that's true, you would have to know the algorithm to know whether
nibabel was going to memmap or not.   That's true now though - for
example, it never memory maps compressed files.  The difference for
memory mapping is that, the memory mapping no longer depends on the
scalefactors for the int case.

You can always specify no memory mapping with ``mmap=False``, if you
need it to be predictable.

> Now, even with "explicit" to_float=False I would then get a warning.

No, my idea was that you only get a warning if you do not give a value
for "to_float".   It will be a bit annoying though, because you either
have to live with the warning, or depend on nibabel > 2.1 .

> I
> guess we would just need to switch to your explicit img.dataobj  way to
> access the data?

If you like the current behavior and you don't want a warning, that's
the best way, I think.

Cheers,

Matthew

From alexis.roche at gmail.com  Sun Jul 19 17:02:21 2015
From: alexis.roche at gmail.com (Alexis Roche)
Date: Sun, 19 Jul 2015 17:02:21 +0200
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAH6Pt5q8q+9Jomxy62PLKBRub7OYzVr+fQ_di+yjaa-vON=6VA@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <20150706155516.GA28964@onerussian.com>
 <CAH6Pt5q8q+9Jomxy62PLKBRub7OYzVr+fQ_di+yjaa-vON=6VA@mail.gmail.com>
Message-ID: <CAD4j9Gsse73vO8WO93HzLLsuvMWO6VYvg+1DC9GjdaS46iMUYg@mail.gmail.com>

Hi,

Sorry for jumping late into this discussion.

A case where I believe it would be confusing to have a float array by
default is resampling an image according to a spatial transform using cubic
spline or sinc interpolation (or any order>1 spline interpolation). While
such interpolation methods are arguably more accurate than trilinear
interpolation, they have the potential to produce negative intensities even
though the input image intensities are all positive and are expected to
remain positive after resampling. In such case, standard practice is to low
threshold interpolated values at zero, however that's something the user
would have to bear in mind (and be enforce himself) if dealing with a float
array as opposed to unsigned int.

In that case, using the native image dtype would only help if it's unsigned
(which is not necessarily the case), but the point is: the user always has
to think about his/her dtype, there is no "universal" confusion-free dtype.

When people ask me if there are drawbacks switching from matlab to python
to do image processing, I usually say that the only drawback I see is that
you have to be aware of your array type in python (as a consequence of
using numpy), which also has great advantages...

Hence I am not very keen to get float arrays by default.

Alexis


Le 18 juil. 2015 17:25, "Matthew Brett" <matthew.brett at gmail.com> a ?crit :

> Hi,
>
> Sorry to be late to reply to this one.
>
> On Mon, Jul 6, 2015 at 4:55 PM, Yaroslav Halchenko <lists at onerussian.com>
> wrote:
> >
> > On Mon, 06 Jul 2015, Matthew Brett wrote:
> >
> >> Hi,
> >
> >> I wanted to ask y'all about an API change that I want to make to
> nibabel.
> >
> >> In summary, I want to default to returning floating point arrays from
> >> nibabel images.
> >
> >> Problem - different returned data types from img.get_data()
> >>
> -------------------------------------------------------------------------------
> >
> >> At the moment, if you do this:
> >
> >> img = nib.load('my_image.nii')
> >> data = img.get_data()
> >
> >> Then the data type (dtype) of the returned data array depends on the
> >> values in the header of `my_image.nii`.   Specifically, if the raw
> >> on-disk data type is 'np.int16' (it is often is) and the header
> >> scalefactor values are default (1 for slope, 0 for intercept) then you
> >> will get back an array of the on disk data type - here - np.int16.
> >
> >> This is very efficient on memory, but it it's a real trap unless you
> careful.
> >
> >> For example, let's say you had a pipeline where you did this:
> >
> >> sum = img.get_data().sum()
> >
> >> That would work fine most of the time, when the data on disk is
> >> floating point, or the scalefactors are not default (1, 0).   Then one
> >> day, you get an image with int16 data type on disk and 1, 0
> >> scalefactors, and your `sum` calculation silently overflows.    I ran
> >> into this when teaching - I had to cast some image arrays to floating
> >> point to get sensible answers.
> >
> >> Solution
> >> -----------
> >
> >> I think that the default behavior of nibabel should be to do the thing
> >> least likely to trip you up by accident, so - I think in due course,
> >> nibabel should always return a floating point array from `get_data()`
> >> by default.
> >
> >> I propose to add a keyword-only argument to `get_data()` - `to_float`,
> as in:
> >
> >> data = img.get_data(to_float=False)  # The current default behavior
> >> data = img.get_data(to_float=True)  # Integer arrays automatically
> >> cast to float64
> >
> >> For this cycle (the nibabel 2.0 series), I propose to raise a warning
> >> if you don't pass in an explicit True or False, warning that the
> >> default behavior for nibabel 3.0 will change from `to_float=False` to
> >> `to_float=True`.
> >
> >> The other, more fancy ways of getting the image data would continue as
> >> they are, such as:
> >
> >> data = np.array(img.dataobj)
> >> data = img.dataobj[:]
> >
> >> These will both return ints or floats depending on the raw data dtype
> >> and the scalefactors.  This is on the basis that people using these
> >> will be more advanced and so therefore more likely to want memory
> >> efficiency at the expense of having to be careful about the returned
> >> data dtype.
> >
> >> Does this seem reasonable to y'all?    Thoughts, suggestions?
> >
> > Overall I am all for reducing a possibility for users shotting
> > themselves in a foot.  But this API change would still conflate two
> > (related) issues here:  memory mapping and casting.  May be there is a
> > way to clear it up?  Sorry for not providing an answer but at
> > least let me share the use case(s):
> >
> > with to_float=True it would then keep memory mapping float .nii
> > while int .nii would get casted.  So it would remain somewhat obfuscated
> > when data gets memmapped and when not.  In our (PyMVPA) case we don't
> > really care about correct offset/scale in many cases (data gets zscored
> > anyways per each voxel later on with appropriate casting if necessary).
>
> Yes, that's true, you would have to know the algorithm to know whether
> nibabel was going to memmap or not.   That's true now though - for
> example, it never memory maps compressed files.  The difference for
> memory mapping is that, the memory mapping no longer depends on the
> scalefactors for the int case.
>
> You can always specify no memory mapping with ``mmap=False``, if you
> need it to be predictable.
>
> > Now, even with "explicit" to_float=False I would then get a warning.
>
> No, my idea was that you only get a warning if you do not give a value
> for "to_float".   It will be a bit annoying though, because you either
> have to live with the warning, or depend on nibabel > 2.1 .
>
> > I
> > guess we would just need to switch to your explicit img.dataobj  way to
> > access the data?
>
> If you like the current behavior and you don't want a warning, that's
> the best way, I think.
>
> 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/20150719/a312a3be/attachment.html>

From matthew.brett at gmail.com  Mon Jul 20 07:59:33 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Mon, 20 Jul 2015 06:59:33 +0100
Subject: [Neuroimaging] Nibabel developer hangout early
In-Reply-To: <CAH6Pt5pgLOJMQOV4a__QgYv1FQEkE0t+vauHwR4btF3W1ipjKw@mail.gmail.com>
References: <CAH6Pt5pCNWuvRjb+CFAYTj3oSBTyD_8-st7GA5FT8-ujYHbqdw@mail.gmail.com>
 <CAH6Pt5pgLOJMQOV4a__QgYv1FQEkE0t+vauHwR4btF3W1ipjKw@mail.gmail.com>
Message-ID: <CAH6Pt5r8Ekr4tXrnW1b460fgMYWeXpGvvVHASu+NqS8TLpM7=Q@mail.gmail.com>

Hi,

On Sat, Jul 18, 2015 at 5:10 PM, Matthew Brett <matthew.brett at gmail.com> wrote:
> Hi,
>
> As promised, here is the reading for the topics of the hangout:
>
> On Sat, Jul 18, 2015 at 2:43 PM, Matthew Brett <matthew.brett at gmail.com> wrote:
>> Hi,
>>
>> It seems to be time for another nibabel developer hangout.
>>
>> We need to discuss:
>>
>> * the `as_float` keyword to the `get_data()` method;
>
> https://mail.python.org/pipermail/neuroimaging/2015-July/000021.html
> and following.
>
>> * using the `load` function or a new `load_multi` function to load
>> file formats that can have more than one image in the same file;
>
> https://github.com/nipy/nibabel/wiki/BIAP7
>
>> * whether to standardize to having time / volume as the fourth axis on
>> all image formats (not currently the case for MINC);
>
> https://github.com/nipy/nibabel/wiki/BIAP6
>
>> * (related) plan for adding names / labels for image axes;
>
> Also in https://github.com/nipy/nibabel/wiki/BIAP6
>
>> * BrainVoyager format support : https://github.com/nipy/nibabel/pull/216
>
> See also : https://github.com/nipy/nibabel/blob/master/doc/source/devel/bv_formats.rst

Clear winner for hangout time is today:

18:00 UK time.
10:00 California time

I'll post the list to the hangout then.

See y'all soon.

Matthew

From matthew.brett at gmail.com  Mon Jul 20 12:30:56 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Mon, 20 Jul 2015 11:30:56 +0100
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAD4j9Gsse73vO8WO93HzLLsuvMWO6VYvg+1DC9GjdaS46iMUYg@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <20150706155516.GA28964@onerussian.com>
 <CAH6Pt5q8q+9Jomxy62PLKBRub7OYzVr+fQ_di+yjaa-vON=6VA@mail.gmail.com>
 <CAD4j9Gsse73vO8WO93HzLLsuvMWO6VYvg+1DC9GjdaS46iMUYg@mail.gmail.com>
Message-ID: <CAH6Pt5pMgWVMSLCyo2qwy6+59CVqKL6NrgHi_Bhog2byWnKv8g@mail.gmail.com>

Hi,

On Sun, Jul 19, 2015 at 4:02 PM, Alexis Roche <alexis.roche at gmail.com> wrote:
> Hi,
>
> Sorry for jumping late into this discussion.
>
> A case where I believe it would be confusing to have a float array by
> default is resampling an image according to a spatial transform using cubic
> spline or sinc interpolation (or any order>1 spline interpolation). While
> such interpolation methods are arguably more accurate than trilinear
> interpolation, they have the potential to produce negative intensities even
> though the input image intensities are all positive and are expected to
> remain positive after resampling. In such case, standard practice is to low
> threshold interpolated values at zero, however that's something the user
> would have to bear in mind (and be enforce himself) if dealing with a float
> array as opposed to unsigned int.
>
> In that case, using the native image dtype would only help if it's unsigned
> (which is not necessarily the case), but the point is: the user always has
> to think about his/her dtype, there is no "universal" confusion-free dtype.
>
> When people ask me if there are drawbacks switching from matlab to python to
> do image processing, I usually say that the only drawback I see is that you
> have to be aware of your array type in python (as a consequence of using
> numpy), which also has great advantages...
>
> Hence I am not very keen to get float arrays by default.

Sorry to keep returning to this, but I feel the need to clarify.

We all agree that it is good to give the user as much choice as
possible about how the data gets loaded, whether scaled or unscaled,
int or float.

I think we all agree that, if there is an obvious intended in-memory
dtype for the data, then nibabel should respect that.

Unfortunately, neither the standard, nor standard practice, specifies
what the *in-memory* dtype should be.

We have the unfortunate current situation where the in-memory dtype
depends on two details of the implementation, which are:

* the convenient dtype to store the data on disk;
*  whether the scalefactors are default or not.

I think you could make the argument that the on-disk dtype is some
indicator of the intended in-memory type, but I don't think you can
make that argument for the scalefactors.

If you agree with me, that the authors of NIfTI images do not
generally intend the scalefactors to indicate the in-memory dtype,
then my guess is you would probably agree that choosing a predictable
default is better than the current situation - but please tell me if I
am wrong about that.

Cheers,

Matthew

From alexis.roche at gmail.com  Mon Jul 20 12:46:30 2015
From: alexis.roche at gmail.com (Alexis Roche)
Date: Mon, 20 Jul 2015 12:46:30 +0200
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAH6Pt5pMgWVMSLCyo2qwy6+59CVqKL6NrgHi_Bhog2byWnKv8g@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <20150706155516.GA28964@onerussian.com>
 <CAH6Pt5q8q+9Jomxy62PLKBRub7OYzVr+fQ_di+yjaa-vON=6VA@mail.gmail.com>
 <CAD4j9Gsse73vO8WO93HzLLsuvMWO6VYvg+1DC9GjdaS46iMUYg@mail.gmail.com>
 <CAH6Pt5pMgWVMSLCyo2qwy6+59CVqKL6NrgHi_Bhog2byWnKv8g@mail.gmail.com>
Message-ID: <CAD4j9GtYcsk1A0uHoHZG1gXqzRBgfKsYON8gT8ZYUJ4EwnBMRQ@mail.gmail.com>

Hi Matthew,

I think that, if the data is int on disk with scale factors are (0,1), then
the intended dtype is more likely to be int than float - in the sense that
there is no obvious reason for casting the data to float, but it's more
efficient to keep it as int.

Alexis

On Mon, Jul 20, 2015 at 12:30 PM, Matthew Brett <matthew.brett at gmail.com>
wrote:

> Hi,
>
> On Sun, Jul 19, 2015 at 4:02 PM, Alexis Roche <alexis.roche at gmail.com>
> wrote:
> > Hi,
> >
> > Sorry for jumping late into this discussion.
> >
> > A case where I believe it would be confusing to have a float array by
> > default is resampling an image according to a spatial transform using
> cubic
> > spline or sinc interpolation (or any order>1 spline interpolation). While
> > such interpolation methods are arguably more accurate than trilinear
> > interpolation, they have the potential to produce negative intensities
> even
> > though the input image intensities are all positive and are expected to
> > remain positive after resampling. In such case, standard practice is to
> low
> > threshold interpolated values at zero, however that's something the user
> > would have to bear in mind (and be enforce himself) if dealing with a
> float
> > array as opposed to unsigned int.
> >
> > In that case, using the native image dtype would only help if it's
> unsigned
> > (which is not necessarily the case), but the point is: the user always
> has
> > to think about his/her dtype, there is no "universal" confusion-free
> dtype.
> >
> > When people ask me if there are drawbacks switching from matlab to
> python to
> > do image processing, I usually say that the only drawback I see is that
> you
> > have to be aware of your array type in python (as a consequence of using
> > numpy), which also has great advantages...
> >
> > Hence I am not very keen to get float arrays by default.
>
> Sorry to keep returning to this, but I feel the need to clarify.
>
> We all agree that it is good to give the user as much choice as
> possible about how the data gets loaded, whether scaled or unscaled,
> int or float.
>
> I think we all agree that, if there is an obvious intended in-memory
> dtype for the data, then nibabel should respect that.
>
> Unfortunately, neither the standard, nor standard practice, specifies
> what the *in-memory* dtype should be.
>
> We have the unfortunate current situation where the in-memory dtype
> depends on two details of the implementation, which are:
>
> * the convenient dtype to store the data on disk;
> *  whether the scalefactors are default or not.
>
> I think you could make the argument that the on-disk dtype is some
> indicator of the intended in-memory type, but I don't think you can
> make that argument for the scalefactors.
>
> If you agree with me, that the authors of NIfTI images do not
> generally intend the scalefactors to indicate the in-memory dtype,
> then my guess is you would probably agree that choosing a predictable
> default is better than the current situation - but please tell me if I
> am wrong about that.
>
> Cheers,
>
> Matthew
> _______________________________________________
> Neuroimaging mailing list
> Neuroimaging at python.org
> https://mail.python.org/mailman/listinfo/neuroimaging
>



-- 
Lead Clinical Research
Advanced Clinical Imaging Technology
Siemens/CHUV/EPFL
1015 Lausanne, Switzerland
Phone: +41 21 545 9972
https://sites.google.com/site/alexisroche
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150720/eb8ad1b7/attachment.html>

From matthew.brett at gmail.com  Mon Jul 20 12:59:09 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Mon, 20 Jul 2015 11:59:09 +0100
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAD4j9GtYcsk1A0uHoHZG1gXqzRBgfKsYON8gT8ZYUJ4EwnBMRQ@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <20150706155516.GA28964@onerussian.com>
 <CAH6Pt5q8q+9Jomxy62PLKBRub7OYzVr+fQ_di+yjaa-vON=6VA@mail.gmail.com>
 <CAD4j9Gsse73vO8WO93HzLLsuvMWO6VYvg+1DC9GjdaS46iMUYg@mail.gmail.com>
 <CAH6Pt5pMgWVMSLCyo2qwy6+59CVqKL6NrgHi_Bhog2byWnKv8g@mail.gmail.com>
 <CAD4j9GtYcsk1A0uHoHZG1gXqzRBgfKsYON8gT8ZYUJ4EwnBMRQ@mail.gmail.com>
Message-ID: <CAH6Pt5ojWg711CB1W6_amcy2Z1f7JKy7L5HKyunc-ptt3=2GBg@mail.gmail.com>

On Mon, Jul 20, 2015 at 11:46 AM, Alexis Roche <alexis.roche at gmail.com> wrote:
> Hi Matthew,
>
> I think that, if the data is int on disk with scale factors are (0,1), then
> the intended dtype is more likely to be int than float - in the sense that
> there is no obvious reason for casting the data to float, but it's more
> efficient to keep it as int.

It's possible that is more likely, but I doubt that people or software
have that intention when setting default scalefactors.  For example,
SPM always loads the data as float.

But - even if it is more likely, that would not be enough to make this
a common source of error.  It would have to be overwhelmingly the
case, such that it should be considered a bug if software writes an
image with default scalefactors, when they intend the image to be
loaded as float.  Given that is not in the standard, or standard
practice, I don't think we can (any longer) rely on that.

Cheers,

Matthew

From matthew.brett at gmail.com  Mon Jul 20 13:07:46 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Mon, 20 Jul 2015 12:07:46 +0100
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAH6Pt5ojWg711CB1W6_amcy2Z1f7JKy7L5HKyunc-ptt3=2GBg@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <20150706155516.GA28964@onerussian.com>
 <CAH6Pt5q8q+9Jomxy62PLKBRub7OYzVr+fQ_di+yjaa-vON=6VA@mail.gmail.com>
 <CAD4j9Gsse73vO8WO93HzLLsuvMWO6VYvg+1DC9GjdaS46iMUYg@mail.gmail.com>
 <CAH6Pt5pMgWVMSLCyo2qwy6+59CVqKL6NrgHi_Bhog2byWnKv8g@mail.gmail.com>
 <CAD4j9GtYcsk1A0uHoHZG1gXqzRBgfKsYON8gT8ZYUJ4EwnBMRQ@mail.gmail.com>
 <CAH6Pt5ojWg711CB1W6_amcy2Z1f7JKy7L5HKyunc-ptt3=2GBg@mail.gmail.com>
Message-ID: <CAH6Pt5ot6VresdDj0j5H0CXmA0=vNj1Xi9OJ=U4eeOReGu9aXw@mail.gmail.com>

Oops.

On Mon, Jul 20, 2015 at 11:59 AM, Matthew Brett <matthew.brett at gmail.com> wrote:
> On Mon, Jul 20, 2015 at 11:46 AM, Alexis Roche <alexis.roche at gmail.com> wrote:
>> Hi Matthew,
>>
>> I think that, if the data is int on disk with scale factors are (0,1), then
>> the intended dtype is more likely to be int than float - in the sense that
>> there is no obvious reason for casting the data to float, but it's more
>> efficient to keep it as int.
>
> It's possible that is more likely, but I doubt that people or software
> have that intention when setting default scalefactors.  For example,
> SPM always loads the data as float.
>
> But - even if it is more likely, that would not be enough to make this
> a common source of error.

should be 'would not be enough to prevent this being a common source of error'.

> It would have to be overwhelmingly the
> case, such that it should be considered a bug if software writes an
> image with default scalefactors, when they intend the image to be
> loaded as float.  Given that is not in the standard, or standard
> practice, I don't think we can (any longer) rely on that.

Cheers,

Matthew

From angel.torrado at urjc.es  Mon Jul 20 13:20:20 2015
From: angel.torrado at urjc.es (=?UTF-8?Q?=C3=81ngel_Torrado_Carvajal?=)
Date: Mon, 20 Jul 2015 13:20:20 +0200
Subject: [Neuroimaging] Load, Modify and Save Nifti
Message-ID: <CAE7fCC8K-hHXZj2A6+2RGGVMjABsJq4FJqzcs8YDPBJfTTNp3w@mail.gmail.com>

Hi all,

I am a newby using nibabel and I am having some trouble.

I want to load a Nifti volume, modify its image, and save it. However, if I
do something like this:

img = nb.load("input.nii.gz")

matrix = img.get_data()
matrix = np.zeros(matrix.shape)
nb.save(img, "output.nii.gz")


and open the saved volume, I obtain the same input volume, not zeros...

Is there any step I am missing? Maybe an "update" or "set_data" method...

Thank you in advance!
*--*
*      ?ngel Torrado Carvajal*

*      Research Assistant*
      Medical Image Analysis Laboratory
      Universidad Rey Juan Carlos

      Despacho 155 - Departamental II
      Calle Tulip?n s/n
      28933 M?stoles - Madrid

*      Before printing this message, make sure it's necessary. Protecting
the environment is in your hand.*
*      Antes de imprimir este mensaje, aseg?rate de que es necesario.
Proteger el medio ambiente est? tambi?n en tu mano.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150720/e6f57284/attachment.html>

From pellman.john at gmail.com  Mon Jul 20 13:32:55 2015
From: pellman.john at gmail.com (John Pellman)
Date: Mon, 20 Jul 2015 07:32:55 -0400
Subject: [Neuroimaging] Load, Modify and Save Nifti
In-Reply-To: <CAE7fCC8K-hHXZj2A6+2RGGVMjABsJq4FJqzcs8YDPBJfTTNp3w@mail.gmail.com>
References: <CAE7fCC8K-hHXZj2A6+2RGGVMjABsJq4FJqzcs8YDPBJfTTNp3w@mail.gmail.com>
Message-ID: <CANtQzOG+M5Xjg2-z+8Y3Upc-6JAPAL1DbNDMT3JzW9JeUd+bGQ@mail.gmail.com>

Hi Angel,

You might also want to submit this question to neurostars.org, as the
format of that website is much more suited for Q&A.  I've noticed that this
mailing list tends to focus more on issues of software development.



2015-07-20 7:20 GMT-04:00 ?ngel Torrado Carvajal <angel.torrado at urjc.es>:

> Hi all,
>
> I am a newby using nibabel and I am having some trouble.
>
> I want to load a Nifti volume, modify its image, and save it. However, if
> I do something like this:
>
> img = nb.load("input.nii.gz")
>
> matrix = img.get_data()
> matrix = np.zeros(matrix.shape)
> nb.save(img, "output.nii.gz")
>
>
> and open the saved volume, I obtain the same input volume, not zeros...
>
> Is there any step I am missing? Maybe an "update" or "set_data" method...
>
> Thank you in advance!
> *--*
> *      ?ngel Torrado Carvajal*
>
> *      Research Assistant*
>       Medical Image Analysis Laboratory
>       Universidad Rey Juan Carlos
>
>       Despacho 155 - Departamental II
>       Calle Tulip?n s/n
>       28933 M?stoles - Madrid
>
> *      Before printing this message, make sure it's necessary. Protecting
> the environment is in your hand.*
> *      Antes de imprimir este mensaje, aseg?rate de que es necesario.
> Proteger el medio ambiente est? tambi?n en tu mano.*
>
> _______________________________________________
> 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/20150720/89c8bf63/attachment.html>

From matthew.brett at gmail.com  Mon Jul 20 13:33:26 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Mon, 20 Jul 2015 12:33:26 +0100
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAD4j9GtYcsk1A0uHoHZG1gXqzRBgfKsYON8gT8ZYUJ4EwnBMRQ@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <20150706155516.GA28964@onerussian.com>
 <CAH6Pt5q8q+9Jomxy62PLKBRub7OYzVr+fQ_di+yjaa-vON=6VA@mail.gmail.com>
 <CAD4j9Gsse73vO8WO93HzLLsuvMWO6VYvg+1DC9GjdaS46iMUYg@mail.gmail.com>
 <CAH6Pt5pMgWVMSLCyo2qwy6+59CVqKL6NrgHi_Bhog2byWnKv8g@mail.gmail.com>
 <CAD4j9GtYcsk1A0uHoHZG1gXqzRBgfKsYON8gT8ZYUJ4EwnBMRQ@mail.gmail.com>
Message-ID: <CAH6Pt5oo86oWqX00+A_DvdcS_nLLROJmoprmLHRw8DC89vzSmQ@mail.gmail.com>

On Mon, Jul 20, 2015 at 11:46 AM, Alexis Roche <alexis.roche at gmail.com> wrote:
> Hi Matthew,
>
> I think that, if the data is int on disk with scale factors are (0,1), then
> the intended dtype is more likely to be int than float - in the sense that
> there is no obvious reason for casting the data to float, but it's more
> efficient to keep it as int.

Put another way - I can see there is a argument that int is the
best-guess at the intended dtype here - although I don't think that
argument is correct.

However, to me it seems clear that this is a guess in the face of ambiguity and:

"In the face of ambiguity, refuse the temptation to guess."

Matthew

From matthew.brett at gmail.com  Mon Jul 20 13:38:38 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Mon, 20 Jul 2015 12:38:38 +0100
Subject: [Neuroimaging] Load, Modify and Save Nifti
In-Reply-To: <CAE7fCC8K-hHXZj2A6+2RGGVMjABsJq4FJqzcs8YDPBJfTTNp3w@mail.gmail.com>
References: <CAE7fCC8K-hHXZj2A6+2RGGVMjABsJq4FJqzcs8YDPBJfTTNp3w@mail.gmail.com>
Message-ID: <CAH6Pt5ppy8JXA5k9=2sLWXQCD5R8LwMs5C+E7BDy-BFv1gQvCw@mail.gmail.com>

Hi,

On Mon, Jul 20, 2015 at 12:20 PM, ?ngel Torrado Carvajal
<angel.torrado at urjc.es> wrote:
> Hi all,
>
> I am a newby using nibabel and I am having some trouble.
>
> I want to load a Nifti volume, modify its image, and save it. However, if I
> do something like this:
>
> img = nb.load("input.nii.gz")
>
> matrix = img.get_data()
> matrix = np.zeros(matrix.shape)
> nb.save(img, "output.nii.gz")

We should definitely make this into a FAQ entry.

The principle here is a Python principle, which is that everything is a pointer.

So

In [4]: A = 1
In [5]: B = A
In [6]: B = 2
In [7]: A
Out[7]: 1

Your array assignment is therefore just making `matrix` point to a
different array and `matrix` no longer points to anything to do with
the image.

You need to do something like this:

img = nb.load("input.nii.gz")
matrix = np.zeros(img.shape)
new_img = nb.Nifti1Image(matrix, img.affine, img.header)
nb.save(new_img, "output.nii.gz")

Cheers,

Matthew

From abraham.alexandre at gmail.com  Mon Jul 20 13:38:31 2015
From: abraham.alexandre at gmail.com (Alexandre ABRAHAM)
Date: Mon, 20 Jul 2015 13:38:31 +0200
Subject: [Neuroimaging] Load, Modify and Save Nifti
In-Reply-To: <CAE7fCC8K-hHXZj2A6+2RGGVMjABsJq4FJqzcs8YDPBJfTTNp3w@mail.gmail.com>
References: <CAE7fCC8K-hHXZj2A6+2RGGVMjABsJq4FJqzcs8YDPBJfTTNp3w@mail.gmail.com>
Message-ID: <CAE_wbFvOn3fWGtiSbCeZ-gV_bxV1SVocW497fCpr-+tddSepQQ@mail.gmail.com>

Hi Angel,

The solution is to create a new image from your data:

img = nb.load("input.nii.gz")

matrix = img.get_data()
matrix = np.zeros(matrix.shape)
img = nb.Nifti1Image(matrix, img.get_affine())
nb.save(img, "output.nii.gz")

The explanation is that matrix is a local variable. When you write "matrix
= img.get_data()", it points to the data contained in the image. When you
write "matrix = np.zeros(matrix.shape)", it points to a newly allocated
matrix of zeros.

Alex.


On Mon, Jul 20, 2015 at 1:20 PM, ?ngel Torrado Carvajal <
angel.torrado at urjc.es> wrote:

> Hi all,
>
> I am a newby using nibabel and I am having some trouble.
>
> I want to load a Nifti volume, modify its image, and save it. However, if
> I do something like this:
>
> img = nb.load("input.nii.gz")
>
> matrix = img.get_data()
> matrix = np.zeros(matrix.shape)
> nb.save(img, "output.nii.gz")
>
>
> and open the saved volume, I obtain the same input volume, not zeros...
>
> Is there any step I am missing? Maybe an "update" or "set_data" method...
>
> Thank you in advance!
> *--*
> *      ?ngel Torrado Carvajal*
>
> *      Research Assistant*
>       Medical Image Analysis Laboratory
>       Universidad Rey Juan Carlos
>
>       Despacho 155 - Departamental II
>       Calle Tulip?n s/n
>       28933 M?stoles - Madrid
>
> *      Before printing this message, make sure it's necessary. Protecting
> the environment is in your hand.*
> *      Antes de imprimir este mensaje, aseg?rate de que es necesario.
> Proteger el medio ambiente est? tambi?n en tu mano.*
>
> _______________________________________________
> 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/20150720/6b577538/attachment.html>

From matthew.brett at gmail.com  Mon Jul 20 18:58:24 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Mon, 20 Jul 2015 17:58:24 +0100
Subject: [Neuroimaging] Nibabel developer hangout early
In-Reply-To: <CAH6Pt5r8Ekr4tXrnW1b460fgMYWeXpGvvVHASu+NqS8TLpM7=Q@mail.gmail.com>
References: <CAH6Pt5pCNWuvRjb+CFAYTj3oSBTyD_8-st7GA5FT8-ujYHbqdw@mail.gmail.com>
 <CAH6Pt5pgLOJMQOV4a__QgYv1FQEkE0t+vauHwR4btF3W1ipjKw@mail.gmail.com>
 <CAH6Pt5r8Ekr4tXrnW1b460fgMYWeXpGvvVHASu+NqS8TLpM7=Q@mail.gmail.com>
Message-ID: <CAH6Pt5o9gevj+1DAVVJUXMPpB3HEw=b_7Z4QSwW0WA7NWBm=kA@mail.gmail.com>

Hi,

On Mon, Jul 20, 2015 at 6:59 AM, Matthew Brett <matthew.brett at gmail.com> wrote:
> Hi,
>
> On Sat, Jul 18, 2015 at 5:10 PM, Matthew Brett <matthew.brett at gmail.com> wrote:
>> Hi,
>>
>> As promised, here is the reading for the topics of the hangout:
>>
>> On Sat, Jul 18, 2015 at 2:43 PM, Matthew Brett <matthew.brett at gmail.com> wrote:
>>> Hi,
>>>
>>> It seems to be time for another nibabel developer hangout.
>>>
>>> We need to discuss:
>>>
>>> * the `as_float` keyword to the `get_data()` method;
>>
>> https://mail.python.org/pipermail/neuroimaging/2015-July/000021.html
>> and following.
>>
>>> * using the `load` function or a new `load_multi` function to load
>>> file formats that can have more than one image in the same file;
>>
>> https://github.com/nipy/nibabel/wiki/BIAP7
>>
>>> * whether to standardize to having time / volume as the fourth axis on
>>> all image formats (not currently the case for MINC);
>>
>> https://github.com/nipy/nibabel/wiki/BIAP6
>>
>>> * (related) plan for adding names / labels for image axes;
>>
>> Also in https://github.com/nipy/nibabel/wiki/BIAP6
>>
>>> * BrainVoyager format support : https://github.com/nipy/nibabel/pull/216
>>
>> See also : https://github.com/nipy/nibabel/blob/master/doc/source/devel/bv_formats.rst
>
> Clear winner for hangout time is today:
>
> 18:00 UK time.
> 10:00 California time
>
> I'll post the list to the hangout then.

Hangin' out at https://plus.google.com/hangouts/_/gsy6hs5mrl3gkcguux3wr7phgqa

See y'all there,

Matthew

From alexis.roche at gmail.com  Mon Jul 20 22:14:34 2015
From: alexis.roche at gmail.com (Alexis Roche)
Date: Mon, 20 Jul 2015 22:14:34 +0200
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAH6Pt5oo86oWqX00+A_DvdcS_nLLROJmoprmLHRw8DC89vzSmQ@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <20150706155516.GA28964@onerussian.com>
 <CAH6Pt5q8q+9Jomxy62PLKBRub7OYzVr+fQ_di+yjaa-vON=6VA@mail.gmail.com>
 <CAD4j9Gsse73vO8WO93HzLLsuvMWO6VYvg+1DC9GjdaS46iMUYg@mail.gmail.com>
 <CAH6Pt5pMgWVMSLCyo2qwy6+59CVqKL6NrgHi_Bhog2byWnKv8g@mail.gmail.com>
 <CAD4j9GtYcsk1A0uHoHZG1gXqzRBgfKsYON8gT8ZYUJ4EwnBMRQ@mail.gmail.com>
 <CAH6Pt5oo86oWqX00+A_DvdcS_nLLROJmoprmLHRw8DC89vzSmQ@mail.gmail.com>
Message-ID: <CAD4j9GusB7GyMog6j13+UGgrkGBiHc3v_ngdv_fZXLifqd9YMA@mail.gmail.com>

Exactly - but I think that what makes the situation ambiguous is to
consider the "intent" of whoever created the nifti file. It may not be
relevant because the nifti norm does not allow to make such intent explicit
anyway...

Having said that, I would be totally happy if the load function would take
a dtype keyword argument, which could default to float (fair enough), but
would leave me the possibility to load my data as unsingned int16 if I want
to (of course, without loading a float array first) and would issue a
warning if that entails information loss (e.g. because of a non-integer
slope). Even better, have the option to pass in `dtype='native'` or
something like that, and get the array in the same format as on disk if
slope and offset permit, an error otherwise.

I guess this whole discussion would then boil down to whether the default
dtype should be float or 'native'. But what really matters is the intent of
the user.

Alexis
 Le 20 juil. 2015 13:34, "Matthew Brett" <matthew.brett at gmail.com> a ?crit :

> On Mon, Jul 20, 2015 at 11:46 AM, Alexis Roche <alexis.roche at gmail.com>
> wrote:
> > Hi Matthew,
> >
> > I think that, if the data is int on disk with scale factors are (0,1),
> then
> > the intended dtype is more likely to be int than float - in the sense
> that
> > there is no obvious reason for casting the data to float, but it's more
> > efficient to keep it as int.
>
> Put another way - I can see there is a argument that int is the
> best-guess at the intended dtype here - although I don't think that
> argument is correct.
>
> However, to me it seems clear that this is a guess in the face of
> ambiguity and:
>
> "In the face of ambiguity, refuse the temptation to guess."
>
> 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/20150720/f5fc01b8/attachment.html>

From matthew.brett at gmail.com  Mon Jul 20 22:35:01 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Mon, 20 Jul 2015 21:35:01 +0100
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAD4j9GusB7GyMog6j13+UGgrkGBiHc3v_ngdv_fZXLifqd9YMA@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <20150706155516.GA28964@onerussian.com>
 <CAH6Pt5q8q+9Jomxy62PLKBRub7OYzVr+fQ_di+yjaa-vON=6VA@mail.gmail.com>
 <CAD4j9Gsse73vO8WO93HzLLsuvMWO6VYvg+1DC9GjdaS46iMUYg@mail.gmail.com>
 <CAH6Pt5pMgWVMSLCyo2qwy6+59CVqKL6NrgHi_Bhog2byWnKv8g@mail.gmail.com>
 <CAD4j9GtYcsk1A0uHoHZG1gXqzRBgfKsYON8gT8ZYUJ4EwnBMRQ@mail.gmail.com>
 <CAH6Pt5oo86oWqX00+A_DvdcS_nLLROJmoprmLHRw8DC89vzSmQ@mail.gmail.com>
 <CAD4j9GusB7GyMog6j13+UGgrkGBiHc3v_ngdv_fZXLifqd9YMA@mail.gmail.com>
Message-ID: <CAH6Pt5q53dGKjPaOBduYzjHXyWdibu0Yg5p2BVAPsbp7gRrKAg@mail.gmail.com>

Hi,

On Mon, Jul 20, 2015 at 9:14 PM, Alexis Roche <alexis.roche at gmail.com> wrote:
> Exactly - but I think that what makes the situation ambiguous is to consider
> the "intent" of whoever created the nifti file. It may not be relevant
> because the nifti norm does not allow to make such intent explicit anyway...

Right.

> Having said that, I would be totally happy if the load function would take a
> dtype keyword argument, which could default to float (fair enough), but
> would leave me the possibility to load my data as unsingned int16 if I want
> to (of course, without loading a float array first) and would issue a
> warning if that entails information loss (e.g. because of a non-integer
> slope).

At the moment, that would look like:

Loading in on-disk dtype

data = img.dataobj.get_unscaled()
if (img.dataobj.slope, img.dataobj.inter) != (1, 0):
     print('I did not use your scaling')
data = data.astype(np.int16)

That is as small as the image can go in memory, so `dtype=` couldn't
do better than that.

Can you think of a common use of an arbitrary dtype here?  I mean
dtype not equal to the on-disk dtype or the scaled dtype?   It seems
as if that use might be rather specialized - could it be done in the
user code that starts with the code above?

> Even better, have the option to pass in `dtype='native'` or
> something like that, and get the array in the same format as on disk if
> slope and offset permit, an error otherwise.

I guess that is the same as:

if (img.dataobj.slope, img.dataobj.inter) != (1, 0):
    raise RuntimeError('There is scaling')
data = img.dataobj.get_unscaled()

?

Cheers,

Matthew

From moloney at ohsu.edu  Mon Jul 20 22:53:46 2015
From: moloney at ohsu.edu (Brendan Moloney)
Date: Mon, 20 Jul 2015 20:53:46 +0000
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAH6Pt5q53dGKjPaOBduYzjHXyWdibu0Yg5p2BVAPsbp7gRrKAg@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <20150706155516.GA28964@onerussian.com>
 <CAH6Pt5q8q+9Jomxy62PLKBRub7OYzVr+fQ_di+yjaa-vON=6VA@mail.gmail.com>
 <CAD4j9Gsse73vO8WO93HzLLsuvMWO6VYvg+1DC9GjdaS46iMUYg@mail.gmail.com>
 <CAH6Pt5pMgWVMSLCyo2qwy6+59CVqKL6NrgHi_Bhog2byWnKv8g@mail.gmail.com>
 <CAD4j9GtYcsk1A0uHoHZG1gXqzRBgfKsYON8gT8ZYUJ4EwnBMRQ@mail.gmail.com>
 <CAH6Pt5oo86oWqX00+A_DvdcS_nLLROJmoprmLHRw8DC89vzSmQ@mail.gmail.com>
 <CAD4j9GusB7GyMog6j13+UGgrkGBiHc3v_ngdv_fZXLifqd9YMA@mail.gmail.com>,
 <CAH6Pt5q53dGKjPaOBduYzjHXyWdibu0Yg5p2BVAPsbp7gRrKAg@mail.gmail.com>
Message-ID: <5F6A858FD00E5F4A82E3206D2D854EF87F74B4AE@EXMB10.ohsu.edu>

Hi Matthew,

How about the case where you want float32 instead of float64 to save memory?  You would need to go through the dataobj and handle the scaling yourself (including all the special cases)?

-Brendan

From alexis.roche at gmail.com  Tue Jul 21 00:42:05 2015
From: alexis.roche at gmail.com (Alexis Roche)
Date: Tue, 21 Jul 2015 00:42:05 +0200
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAH6Pt5q53dGKjPaOBduYzjHXyWdibu0Yg5p2BVAPsbp7gRrKAg@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <20150706155516.GA28964@onerussian.com>
 <CAH6Pt5q8q+9Jomxy62PLKBRub7OYzVr+fQ_di+yjaa-vON=6VA@mail.gmail.com>
 <CAD4j9Gsse73vO8WO93HzLLsuvMWO6VYvg+1DC9GjdaS46iMUYg@mail.gmail.com>
 <CAH6Pt5pMgWVMSLCyo2qwy6+59CVqKL6NrgHi_Bhog2byWnKv8g@mail.gmail.com>
 <CAD4j9GtYcsk1A0uHoHZG1gXqzRBgfKsYON8gT8ZYUJ4EwnBMRQ@mail.gmail.com>
 <CAH6Pt5oo86oWqX00+A_DvdcS_nLLROJmoprmLHRw8DC89vzSmQ@mail.gmail.com>
 <CAD4j9GusB7GyMog6j13+UGgrkGBiHc3v_ngdv_fZXLifqd9YMA@mail.gmail.com>
 <CAH6Pt5q53dGKjPaOBduYzjHXyWdibu0Yg5p2BVAPsbp7gRrKAg@mail.gmail.com>
Message-ID: <CAD4j9GvJrdwODXyL+M4ZOQq8XM-e0ARGfpv5Ug5ZB6abM87JCw@mail.gmail.com>

> Can you think of a common use of an arbitrary dtype here?  I mean
> dtype not equal to the on-disk dtype or the scaled dtype?   It seems
> as if that use might be rather specialized - could it be done in the
> user code that starts with the code above?
>

Right. I can think of the following cases:
* a mask image encoded in int16 on disk, but you want an array of booleans
in memory (nifti does not support boolean format)
* an image of positive-valued MR parameters encoded in int, but you want
unsigned int in memory

Of course, that could be done via the 'dataobj' attribute, which requires
advanced knowledge of nibabel I think. I don't think this is very
specialized usage.

Alexis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150721/c53cb154/attachment.html>

From matthew.brett at gmail.com  Tue Jul 21 01:15:05 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Tue, 21 Jul 2015 00:15:05 +0100
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <5F6A858FD00E5F4A82E3206D2D854EF87F74B4AE@EXMB10.ohsu.edu>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <20150706155516.GA28964@onerussian.com>
 <CAH6Pt5q8q+9Jomxy62PLKBRub7OYzVr+fQ_di+yjaa-vON=6VA@mail.gmail.com>
 <CAD4j9Gsse73vO8WO93HzLLsuvMWO6VYvg+1DC9GjdaS46iMUYg@mail.gmail.com>
 <CAH6Pt5pMgWVMSLCyo2qwy6+59CVqKL6NrgHi_Bhog2byWnKv8g@mail.gmail.com>
 <CAD4j9GtYcsk1A0uHoHZG1gXqzRBgfKsYON8gT8ZYUJ4EwnBMRQ@mail.gmail.com>
 <CAH6Pt5oo86oWqX00+A_DvdcS_nLLROJmoprmLHRw8DC89vzSmQ@mail.gmail.com>
 <CAD4j9GusB7GyMog6j13+UGgrkGBiHc3v_ngdv_fZXLifqd9YMA@mail.gmail.com>
 <CAH6Pt5q53dGKjPaOBduYzjHXyWdibu0Yg5p2BVAPsbp7gRrKAg@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F74B4AE@EXMB10.ohsu.edu>
Message-ID: <CAH6Pt5o5CeERq_zbVYRv8A3en9ub2Za0JMjoFi-g-8h7B6p6mQ@mail.gmail.com>

Hi,

On Mon, Jul 20, 2015 at 9:53 PM, Brendan Moloney <moloney at ohsu.edu> wrote:
> Hi Matthew,
>
> How about the case where you want float32 instead of float64 to save memory?  You would need to go through the dataobj and handle the scaling yourself (including all the special cases)?

Yes, I guess you would have to either go through float64 or handle the
scaling yourself.  But isn't that just:

data = data.astype(np.float32) * scale + inter?

But I do see the point.  My only worry is that this involves handling
all possible type conversions inside the  get_data routine, when the
cases where you really need this are restricted to very tight memory
management, which seems like an expert use-case to me.

Thanks for the specifics though, I'm still thinking,

Cheers,

Matthew

From matthew.brett at gmail.com  Tue Jul 21 01:22:00 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Tue, 21 Jul 2015 00:22:00 +0100
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAD4j9GvJrdwODXyL+M4ZOQq8XM-e0ARGfpv5Ug5ZB6abM87JCw@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <20150706155516.GA28964@onerussian.com>
 <CAH6Pt5q8q+9Jomxy62PLKBRub7OYzVr+fQ_di+yjaa-vON=6VA@mail.gmail.com>
 <CAD4j9Gsse73vO8WO93HzLLsuvMWO6VYvg+1DC9GjdaS46iMUYg@mail.gmail.com>
 <CAH6Pt5pMgWVMSLCyo2qwy6+59CVqKL6NrgHi_Bhog2byWnKv8g@mail.gmail.com>
 <CAD4j9GtYcsk1A0uHoHZG1gXqzRBgfKsYON8gT8ZYUJ4EwnBMRQ@mail.gmail.com>
 <CAH6Pt5oo86oWqX00+A_DvdcS_nLLROJmoprmLHRw8DC89vzSmQ@mail.gmail.com>
 <CAD4j9GusB7GyMog6j13+UGgrkGBiHc3v_ngdv_fZXLifqd9YMA@mail.gmail.com>
 <CAH6Pt5q53dGKjPaOBduYzjHXyWdibu0Yg5p2BVAPsbp7gRrKAg@mail.gmail.com>
 <CAD4j9GvJrdwODXyL+M4ZOQq8XM-e0ARGfpv5Ug5ZB6abM87JCw@mail.gmail.com>
Message-ID: <CAH6Pt5om3W5m7BwqOdbi1PcE6vqiD0_jO4WfdE32meNLBpxEsg@mail.gmail.com>

Hi,

On Mon, Jul 20, 2015 at 11:42 PM, Alexis Roche <alexis.roche at gmail.com> wrote:
>
>> Can you think of a common use of an arbitrary dtype here?  I mean
>> dtype not equal to the on-disk dtype or the scaled dtype?   It seems
>> as if that use might be rather specialized - could it be done in the
>> user code that starts with the code above?
>
>
> Right. I can think of the following cases:
> * a mask image encoded in int16 on disk, but you want an array of booleans
> in memory (nifti does not support boolean format)

I guess you can assume no scalefactors?  Then:

data = img.get_data(as_float=False).astype(np.bool)

That is as memory-efficient as you can do that, I think.

> * an image of positive-valued MR parameters encoded in int, but you want
> unsigned int in memory

> Of course, that could be done via the 'dataobj' attribute, which requires
> advanced knowledge of nibabel I think. I don't think this is very
> specialized usage.

Same idea if no scalefactors.  If you do have scalefactors, and you
don't want them applied, yes, you'll have to use
`img.dataobj.get_unscaled()` for that, but it does seem pretty
specialized to throw away scalefactors in that situation.

Or did you mean that `get_data` also has to take care only to load
small parts of the image at a time, and apply scalefactors, and then
cast that part of the array?

Cheers,

Matthew

From peled.noam at gmail.com  Tue Jul 21 18:27:18 2015
From: peled.noam at gmail.com (Noam Peled)
Date: Tue, 21 Jul 2015 16:27:18 +0000
Subject: [Neuroimaging] Wrong fMRI sig.nii shape when loading with nibabel
Message-ID: <CAFtE382P6HPhGPG_AQEgiXeD+1WqbhUtBvc-+SfkVnveFgr88Q@mail.gmail.com>

Hello all,
I'm having an issue with loading fMRI sig.nii files.
I've created two overlays using selxavg3-sess, where the only difference
between them is the surface parameter in preproc-sess and mkanalysis-sess.
In the first I used fsaverage, and in the second the actual subject.
Both seems to be ok via fmri_info and tksurfer-sess.
The problem is when I'm trying to use nibabel to load them.
The fsaverage is getting loaded just fine, whether the other one gets a
(-1, 1, 1, 1) shape.
Here are the file:
sig_fsaverage.nii.gz
<https://www.dropbox.com/s/9ojymqrdd51cslh/sig_fsaverage.nii.gz?dl=0>
sig_subject.nii.gz
<https://www.dropbox.com/s/czysnf8jfsmz753/sig_subject.nii.gz?dl=0>
Any ideas?

Thanks!
Noam Peled
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150721/6c855806/attachment.html>

From effigies at bu.edu  Tue Jul 21 18:36:33 2015
From: effigies at bu.edu (Christopher J Markiewicz)
Date: Tue, 21 Jul 2015 12:36:33 -0400
Subject: [Neuroimaging] Wrong fMRI sig.nii shape when loading with
	nibabel
In-Reply-To: <CAFtE382P6HPhGPG_AQEgiXeD+1WqbhUtBvc-+SfkVnveFgr88Q@mail.gmail.com>
References: <CAFtE382P6HPhGPG_AQEgiXeD+1WqbhUtBvc-+SfkVnveFgr88Q@mail.gmail.com>
Message-ID: <55AE7511.9010108@bu.edu>

On 07/21/2015 12:27 PM, Noam Peled wrote:
> Hello all,
> I'm having an issue with loading fMRI sig.nii files.
> I've created two overlays using selxavg3-sess, where the only difference
> between them is the surface parameter in preproc-sess
> and mkanalysis-sess. In the first I used fsaverage, and in the second
> the actual subject. 
> Both seems to be ok via fmri_info and tksurfer-sess.
> The problem is when I'm trying to use nibabel to load them.
> The fsaverage is getting loaded just fine, whether the other one gets a
> (-1, 1, 1, 1) shape.
> Here are the file:
> sig_fsaverage.nii.gz
> <https://www.dropbox.com/s/9ojymqrdd51cslh/sig_fsaverage.nii.gz?dl=0>
> sig_subject.nii.gz
> <https://www.dropbox.com/s/czysnf8jfsmz753/sig_subject.nii.gz?dl=0>
> Any ideas?
> 
> Thanks!
> Noam Peled

These look to be FreeSurfer nifti surface hack problems. The easiest way
to get what you want in the short term would be:

    mri_convert sig_fsaverage.{nii.gz,mgz}
    mri_convert sig_subject.{nii.gz,mgz}

And load the .mgz files.

The problem here is that the Nifti code to deal with these surfaces is
expecting the shape to be 3 dimensional, not 4.

-- 
Christopher J Markiewicz
Ph.D. Candidate, Quantitative Neuroscience Laboratory
Boston University

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150721/5ae6110c/attachment.sig>

From alexis.roche at gmail.com  Tue Jul 21 19:41:39 2015
From: alexis.roche at gmail.com (Alexis Roche)
Date: Tue, 21 Jul 2015 19:41:39 +0200
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAH6Pt5om3W5m7BwqOdbi1PcE6vqiD0_jO4WfdE32meNLBpxEsg@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <20150706155516.GA28964@onerussian.com>
 <CAH6Pt5q8q+9Jomxy62PLKBRub7OYzVr+fQ_di+yjaa-vON=6VA@mail.gmail.com>
 <CAD4j9Gsse73vO8WO93HzLLsuvMWO6VYvg+1DC9GjdaS46iMUYg@mail.gmail.com>
 <CAH6Pt5pMgWVMSLCyo2qwy6+59CVqKL6NrgHi_Bhog2byWnKv8g@mail.gmail.com>
 <CAD4j9GtYcsk1A0uHoHZG1gXqzRBgfKsYON8gT8ZYUJ4EwnBMRQ@mail.gmail.com>
 <CAH6Pt5oo86oWqX00+A_DvdcS_nLLROJmoprmLHRw8DC89vzSmQ@mail.gmail.com>
 <CAD4j9GusB7GyMog6j13+UGgrkGBiHc3v_ngdv_fZXLifqd9YMA@mail.gmail.com>
 <CAH6Pt5q53dGKjPaOBduYzjHXyWdibu0Yg5p2BVAPsbp7gRrKAg@mail.gmail.com>
 <CAD4j9GvJrdwODXyL+M4ZOQq8XM-e0ARGfpv5Ug5ZB6abM87JCw@mail.gmail.com>
 <CAH6Pt5om3W5m7BwqOdbi1PcE6vqiD0_jO4WfdE32meNLBpxEsg@mail.gmail.com>
Message-ID: <CAD4j9Gta4w_nHzSv+KJEoKXNm-bs_M6jejf539stKkXV3z6pow@mail.gmail.com>

OK, that will do the trick with a fairly light syntax.

Looks like a reasonable change overall.

Alexis

On Tue, Jul 21, 2015 at 1:22 AM, Matthew Brett <matthew.brett at gmail.com>
wrote:

> Hi,
>
> On Mon, Jul 20, 2015 at 11:42 PM, Alexis Roche <alexis.roche at gmail.com>
> wrote:
> >
> >> Can you think of a common use of an arbitrary dtype here?  I mean
> >> dtype not equal to the on-disk dtype or the scaled dtype?   It seems
> >> as if that use might be rather specialized - could it be done in the
> >> user code that starts with the code above?
> >
> >
> > Right. I can think of the following cases:
> > * a mask image encoded in int16 on disk, but you want an array of
> booleans
> > in memory (nifti does not support boolean format)
>
> I guess you can assume no scalefactors?  Then:
>
> data = img.get_data(as_float=False).astype(np.bool)
>
> That is as memory-efficient as you can do that, I think.
>
> > * an image of positive-valued MR parameters encoded in int, but you want
> > unsigned int in memory
>
> > Of course, that could be done via the 'dataobj' attribute, which requires
> > advanced knowledge of nibabel I think. I don't think this is very
> > specialized usage.
>
> Same idea if no scalefactors.  If you do have scalefactors, and you
> don't want them applied, yes, you'll have to use
> `img.dataobj.get_unscaled()` for that, but it does seem pretty
> specialized to throw away scalefactors in that situation.
>
> Or did you mean that `get_data` also has to take care only to load
> small parts of the image at a time, and apply scalefactors, and then
> cast that part of the array?
>
> Cheers,
>
> Matthew
> _______________________________________________
> Neuroimaging mailing list
> Neuroimaging at python.org
> https://mail.python.org/mailman/listinfo/neuroimaging
>



-- 
Lead Clinical Research
Advanced Clinical Imaging Technology
Siemens/CHUV/EPFL
1015 Lausanne, Switzerland
Phone: +41 21 545 9972
https://sites.google.com/site/alexisroche
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150721/22868c39/attachment.html>

From moloney at ohsu.edu  Tue Jul 21 20:28:12 2015
From: moloney at ohsu.edu (Brendan Moloney)
Date: Tue, 21 Jul 2015 18:28:12 +0000
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAH6Pt5o5CeERq_zbVYRv8A3en9ub2Za0JMjoFi-g-8h7B6p6mQ@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <20150706155516.GA28964@onerussian.com>
 <CAH6Pt5q8q+9Jomxy62PLKBRub7OYzVr+fQ_di+yjaa-vON=6VA@mail.gmail.com>
 <CAD4j9Gsse73vO8WO93HzLLsuvMWO6VYvg+1DC9GjdaS46iMUYg@mail.gmail.com>
 <CAH6Pt5pMgWVMSLCyo2qwy6+59CVqKL6NrgHi_Bhog2byWnKv8g@mail.gmail.com>
 <CAD4j9GtYcsk1A0uHoHZG1gXqzRBgfKsYON8gT8ZYUJ4EwnBMRQ@mail.gmail.com>
 <CAH6Pt5oo86oWqX00+A_DvdcS_nLLROJmoprmLHRw8DC89vzSmQ@mail.gmail.com>
 <CAD4j9GusB7GyMog6j13+UGgrkGBiHc3v_ngdv_fZXLifqd9YMA@mail.gmail.com>
 <CAH6Pt5q53dGKjPaOBduYzjHXyWdibu0Yg5p2BVAPsbp7gRrKAg@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F74B4AE@EXMB10.ohsu.edu>,
 <CAH6Pt5o5CeERq_zbVYRv8A3en9ub2Za0JMjoFi-g-8h7B6p6mQ@mail.gmail.com>
Message-ID: <5F6A858FD00E5F4A82E3206D2D854EF87F74B622@EXMB10.ohsu.edu>


> Yes, I guess you would have to either go through float64 or handle the
> scaling yourself.  But isn't that just:
> 
> data = data.astype(np.float32) * scale + inter?

If you just want your code to work with Nifti then I think the full code would be something like:

data = img.get_data(as_float=False)
slope = img.dataobj.slope
if np.isnan(slope) or slope == 0:
    slope = 1.0
inter = img.dataobj.inter
if np.isnan(inter):
    inter = 0.0
data = data.astype(np.float32) * scale + inter

If you want your code to work with other image types besides Nifti I guess this gets slightly more complex.

From peled.noam at gmail.com  Tue Jul 21 21:01:09 2015
From: peled.noam at gmail.com (Noam Peled)
Date: Tue, 21 Jul 2015 19:01:09 +0000
Subject: [Neuroimaging] Wrong fMRI sig.nii shape when loading with
	nibabel
In-Reply-To: <55AE7511.9010108@bu.edu>
References: <CAFtE382P6HPhGPG_AQEgiXeD+1WqbhUtBvc-+SfkVnveFgr88Q@mail.gmail.com>
 <55AE7511.9010108@bu.edu>
Message-ID: <CAFtE380XeR9RfRgytuk9VN2=66RoKO-KBfzta3An=j-7bNFDjQ@mail.gmail.com>

Thanks, it worked!

On Tue, Jul 21, 2015 at 12:49 PM Christopher J Markiewicz <effigies at bu.edu>
wrote:

> On 07/21/2015 12:27 PM, Noam Peled wrote:
> > Hello all,
> > I'm having an issue with loading fMRI sig.nii files.
> > I've created two overlays using selxavg3-sess, where the only difference
> > between them is the surface parameter in preproc-sess
> > and mkanalysis-sess. In the first I used fsaverage, and in the second
> > the actual subject.
> > Both seems to be ok via fmri_info and tksurfer-sess.
> > The problem is when I'm trying to use nibabel to load them.
> > The fsaverage is getting loaded just fine, whether the other one gets a
> > (-1, 1, 1, 1) shape.
> > Here are the file:
> > sig_fsaverage.nii.gz
> > <https://www.dropbox.com/s/9ojymqrdd51cslh/sig_fsaverage.nii.gz?dl=0>
> > sig_subject.nii.gz
> > <https://www.dropbox.com/s/czysnf8jfsmz753/sig_subject.nii.gz?dl=0>
> > Any ideas?
> >
> > Thanks!
> > Noam Peled
>
> These look to be FreeSurfer nifti surface hack problems. The easiest way
> to get what you want in the short term would be:
>
>     mri_convert sig_fsaverage.{nii.gz,mgz}
>     mri_convert sig_subject.{nii.gz,mgz}
>
> And load the .mgz files.
>
> The problem here is that the Nifti code to deal with these surfaces is
> expecting the shape to be 3 dimensional, not 4.
>
> --
> Christopher J Markiewicz
> Ph.D. Candidate, Quantitative Neuroscience Laboratory
> Boston University
>
> _______________________________________________
> 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/20150721/14875c87/attachment.html>

From matthew.brett at gmail.com  Tue Jul 21 20:55:39 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Tue, 21 Jul 2015 19:55:39 +0100
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <5F6A858FD00E5F4A82E3206D2D854EF87F74B622@EXMB10.ohsu.edu>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <20150706155516.GA28964@onerussian.com>
 <CAH6Pt5q8q+9Jomxy62PLKBRub7OYzVr+fQ_di+yjaa-vON=6VA@mail.gmail.com>
 <CAD4j9Gsse73vO8WO93HzLLsuvMWO6VYvg+1DC9GjdaS46iMUYg@mail.gmail.com>
 <CAH6Pt5pMgWVMSLCyo2qwy6+59CVqKL6NrgHi_Bhog2byWnKv8g@mail.gmail.com>
 <CAD4j9GtYcsk1A0uHoHZG1gXqzRBgfKsYON8gT8ZYUJ4EwnBMRQ@mail.gmail.com>
 <CAH6Pt5oo86oWqX00+A_DvdcS_nLLROJmoprmLHRw8DC89vzSmQ@mail.gmail.com>
 <CAD4j9GusB7GyMog6j13+UGgrkGBiHc3v_ngdv_fZXLifqd9YMA@mail.gmail.com>
 <CAH6Pt5q53dGKjPaOBduYzjHXyWdibu0Yg5p2BVAPsbp7gRrKAg@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F74B4AE@EXMB10.ohsu.edu>
 <CAH6Pt5o5CeERq_zbVYRv8A3en9ub2Za0JMjoFi-g-8h7B6p6mQ@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F74B622@EXMB10.ohsu.edu>
Message-ID: <CAH6Pt5o-6priSgKc8eOVdHJ2wsFPXT3=-AGSV40qY9F3U2SnYg@mail.gmail.com>

On Tue, Jul 21, 2015 at 7:28 PM, Brendan Moloney <moloney at ohsu.edu> wrote:
>
>> Yes, I guess you would have to either go through float64 or handle the
>> scaling yourself.  But isn't that just:
>>
>> data = data.astype(np.float32) * scale + inter?
>
> If you just want your code to work with Nifti then I think the full code would be something like:
>
> data = img.get_data(as_float=False)
> slope = img.dataobj.slope
> if np.isnan(slope) or slope == 0:
>     slope = 1.0
> inter = img.dataobj.inter
> if np.isnan(inter):
>     inter = 0.0
> data = data.astype(np.float32) * scale + inter

Actually, because of the slope, inter processing in the dataobj, I
think you'll find you can do:

data = np.array(img.dataobj).astype(np.float32) * dataobj.slope + dataobj.inter

> If you want your code to work with other image types besides Nifti I guess this gets slightly more complex.
>

Yes, that's a reasonable point, it would be horrible with MINC for example.

Cheers,

Matthew

From moloney at ohsu.edu  Tue Jul 21 21:39:15 2015
From: moloney at ohsu.edu (Brendan Moloney)
Date: Tue, 21 Jul 2015 19:39:15 +0000
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAH6Pt5o-6priSgKc8eOVdHJ2wsFPXT3=-AGSV40qY9F3U2SnYg@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <20150706155516.GA28964@onerussian.com>
 <CAH6Pt5q8q+9Jomxy62PLKBRub7OYzVr+fQ_di+yjaa-vON=6VA@mail.gmail.com>
 <CAD4j9Gsse73vO8WO93HzLLsuvMWO6VYvg+1DC9GjdaS46iMUYg@mail.gmail.com>
 <CAH6Pt5pMgWVMSLCyo2qwy6+59CVqKL6NrgHi_Bhog2byWnKv8g@mail.gmail.com>
 <CAD4j9GtYcsk1A0uHoHZG1gXqzRBgfKsYON8gT8ZYUJ4EwnBMRQ@mail.gmail.com>
 <CAH6Pt5oo86oWqX00+A_DvdcS_nLLROJmoprmLHRw8DC89vzSmQ@mail.gmail.com>
 <CAD4j9GusB7GyMog6j13+UGgrkGBiHc3v_ngdv_fZXLifqd9YMA@mail.gmail.com>
 <CAH6Pt5q53dGKjPaOBduYzjHXyWdibu0Yg5p2BVAPsbp7gRrKAg@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F74B4AE@EXMB10.ohsu.edu>
 <CAH6Pt5o5CeERq_zbVYRv8A3en9ub2Za0JMjoFi-g-8h7B6p6mQ@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F74B622@EXMB10.ohsu.edu>,
 <CAH6Pt5o-6priSgKc8eOVdHJ2wsFPXT3=-AGSV40qY9F3U2SnYg@mail.gmail.com>
Message-ID: <5F6A858FD00E5F4A82E3206D2D854EF87F74B661@EXMB10.ohsu.edu>

> Actually, because of the slope, inter processing in the dataobj, I
> think you'll find you can do:
>
> data = np.array(img.dataobj).astype(np.float32) * dataobj.slope + dataobj.inter

Oops, I should have looked at the code...  Thanks for clarifying.

From satra at mit.edu  Wed Jul 22 00:38:27 2015
From: satra at mit.edu (Satrajit Ghosh)
Date: Tue, 21 Jul 2015 18:38:27 -0400
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAH6Pt5o-6priSgKc8eOVdHJ2wsFPXT3=-AGSV40qY9F3U2SnYg@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <20150706155516.GA28964@onerussian.com>
 <CAH6Pt5q8q+9Jomxy62PLKBRub7OYzVr+fQ_di+yjaa-vON=6VA@mail.gmail.com>
 <CAD4j9Gsse73vO8WO93HzLLsuvMWO6VYvg+1DC9GjdaS46iMUYg@mail.gmail.com>
 <CAH6Pt5pMgWVMSLCyo2qwy6+59CVqKL6NrgHi_Bhog2byWnKv8g@mail.gmail.com>
 <CAD4j9GtYcsk1A0uHoHZG1gXqzRBgfKsYON8gT8ZYUJ4EwnBMRQ@mail.gmail.com>
 <CAH6Pt5oo86oWqX00+A_DvdcS_nLLROJmoprmLHRw8DC89vzSmQ@mail.gmail.com>
 <CAD4j9GusB7GyMog6j13+UGgrkGBiHc3v_ngdv_fZXLifqd9YMA@mail.gmail.com>
 <CAH6Pt5q53dGKjPaOBduYzjHXyWdibu0Yg5p2BVAPsbp7gRrKAg@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F74B4AE@EXMB10.ohsu.edu>
 <CAH6Pt5o5CeERq_zbVYRv8A3en9ub2Za0JMjoFi-g-8h7B6p6mQ@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F74B622@EXMB10.ohsu.edu>
 <CAH6Pt5o-6priSgKc8eOVdHJ2wsFPXT3=-AGSV40qY9F3U2SnYg@mail.gmail.com>
Message-ID: <CA+A4wOmaPem2JnxTyt=cKGun6bwAAb+o1Cawy2Pipq5gKz2gPg@mail.gmail.com>

hi matthew,

does the image object (dataobj.slope) store the raw slope value from the
header, not the effective slope value? i.e. is there a way for me to detect
that the slope in the nifti file is 0.

conversely, when saving an image is there an explicit way of saving with
slope == 0, and keeping the dtype as the same as arr.dtype whenever that
dtype is allowed in nifti-1/2.

cheers,

satra

On Tue, Jul 21, 2015 at 2:55 PM, Matthew Brett <matthew.brett at gmail.com>
wrote:

> On Tue, Jul 21, 2015 at 7:28 PM, Brendan Moloney <moloney at ohsu.edu> wrote:
> >
> >> Yes, I guess you would have to either go through float64 or handle the
> >> scaling yourself.  But isn't that just:
> >>
> >> data = data.astype(np.float32) * scale + inter?
> >
> > If you just want your code to work with Nifti then I think the full code
> would be something like:
> >
> > data = img.get_data(as_float=False)
> > slope = img.dataobj.slope
> > if np.isnan(slope) or slope == 0:
> >     slope = 1.0
> > inter = img.dataobj.inter
> > if np.isnan(inter):
> >     inter = 0.0
> > data = data.astype(np.float32) * scale + inter
>
> Actually, because of the slope, inter processing in the dataobj, I
> think you'll find you can do:
>
> data = np.array(img.dataobj).astype(np.float32) * dataobj.slope +
> dataobj.inter
>
> > If you want your code to work with other image types besides Nifti I
> guess this gets slightly more complex.
> >
>
> Yes, that's a reasonable point, it would be horrible with MINC for example.
>
> 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/20150721/97e7f073/attachment.html>

From matthew.brett at gmail.com  Wed Jul 22 01:15:12 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Wed, 22 Jul 2015 00:15:12 +0100
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CA+A4wOmaPem2JnxTyt=cKGun6bwAAb+o1Cawy2Pipq5gKz2gPg@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <20150706155516.GA28964@onerussian.com>
 <CAH6Pt5q8q+9Jomxy62PLKBRub7OYzVr+fQ_di+yjaa-vON=6VA@mail.gmail.com>
 <CAD4j9Gsse73vO8WO93HzLLsuvMWO6VYvg+1DC9GjdaS46iMUYg@mail.gmail.com>
 <CAH6Pt5pMgWVMSLCyo2qwy6+59CVqKL6NrgHi_Bhog2byWnKv8g@mail.gmail.com>
 <CAD4j9GtYcsk1A0uHoHZG1gXqzRBgfKsYON8gT8ZYUJ4EwnBMRQ@mail.gmail.com>
 <CAH6Pt5oo86oWqX00+A_DvdcS_nLLROJmoprmLHRw8DC89vzSmQ@mail.gmail.com>
 <CAD4j9GusB7GyMog6j13+UGgrkGBiHc3v_ngdv_fZXLifqd9YMA@mail.gmail.com>
 <CAH6Pt5q53dGKjPaOBduYzjHXyWdibu0Yg5p2BVAPsbp7gRrKAg@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F74B4AE@EXMB10.ohsu.edu>
 <CAH6Pt5o5CeERq_zbVYRv8A3en9ub2Za0JMjoFi-g-8h7B6p6mQ@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F74B622@EXMB10.ohsu.edu>
 <CAH6Pt5o-6priSgKc8eOVdHJ2wsFPXT3=-AGSV40qY9F3U2SnYg@mail.gmail.com>
 <CA+A4wOmaPem2JnxTyt=cKGun6bwAAb+o1Cawy2Pipq5gKz2gPg@mail.gmail.com>
Message-ID: <CAH6Pt5ogBBO8u-i9mR7kzvNUFQ5aybvwLkNkqQ3WTyuosNfF_A@mail.gmail.com>

Hi,

On Tue, Jul 21, 2015 at 11:38 PM, Satrajit Ghosh <satra at mit.edu> wrote:
> hi matthew,
>
> does the image object (dataobj.slope) store the raw slope value from the
> header, not the effective slope value? i.e. is there a way for me to detect
> that the slope in the nifti file is 0.

It stores the effective slope value, so there's no current way to
detect a slope of 0.   You would have to read the header again, I'm
afraid.   SPM does the same thing, as far as I can see - it sets the
slope in the read image to 1 when it is 0 in the header.

In [1]: import nibabel as nib
In [2]: nib.Nifti1Header.from_fileobj(open('scale_zero.nii'))['scl_slope']
Out[2]: array(0.0, dtype=float32)
In [3]: nib.Nifti1Header.from_fileobj(open('scale_one.nii'))['scl_slope']
Out[3]: array(1.0, dtype=float32)

>> img = nifti('scale_zero.nii'); disp(img.dat)
        fname: 'scale_zero.nii'
          dim: [2 3 4]
        dtype: 'INT64-LE'
       offset: 352
    scl_slope: 1
    scl_inter: 0

>> img = nifti('scale_one.nii'); disp(img.dat)
        fname: 'scale_one.nii'
          dim: [2 3 4]
        dtype: 'INT64-LE'
       offset: 352
    scl_slope: 1
    scl_inter: 0

I don't know of any software that does behave differently for
scl_slope of 0 or 1 - but I'd certainly like to know if there is any.

> conversely, when saving an image is there an explicit way of saving with
> slope == 0, and keeping the dtype as the same as arr.dtype whenever that
> dtype is allowed in nifti-1/2.

You can set the slope manually to 0 if you like, and of course you can
set the dtype manually too.  The header dtype gets set to the dtype of
the array by default, if you do not create the image with a header.

Cheers,

Matthew

From satra at mit.edu  Wed Jul 22 03:56:30 2015
From: satra at mit.edu (Satrajit Ghosh)
Date: Tue, 21 Jul 2015 21:56:30 -0400
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAH6Pt5ogBBO8u-i9mR7kzvNUFQ5aybvwLkNkqQ3WTyuosNfF_A@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <20150706155516.GA28964@onerussian.com>
 <CAH6Pt5q8q+9Jomxy62PLKBRub7OYzVr+fQ_di+yjaa-vON=6VA@mail.gmail.com>
 <CAD4j9Gsse73vO8WO93HzLLsuvMWO6VYvg+1DC9GjdaS46iMUYg@mail.gmail.com>
 <CAH6Pt5pMgWVMSLCyo2qwy6+59CVqKL6NrgHi_Bhog2byWnKv8g@mail.gmail.com>
 <CAD4j9GtYcsk1A0uHoHZG1gXqzRBgfKsYON8gT8ZYUJ4EwnBMRQ@mail.gmail.com>
 <CAH6Pt5oo86oWqX00+A_DvdcS_nLLROJmoprmLHRw8DC89vzSmQ@mail.gmail.com>
 <CAD4j9GusB7GyMog6j13+UGgrkGBiHc3v_ngdv_fZXLifqd9YMA@mail.gmail.com>
 <CAH6Pt5q53dGKjPaOBduYzjHXyWdibu0Yg5p2BVAPsbp7gRrKAg@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F74B4AE@EXMB10.ohsu.edu>
 <CAH6Pt5o5CeERq_zbVYRv8A3en9ub2Za0JMjoFi-g-8h7B6p6mQ@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F74B622@EXMB10.ohsu.edu>
 <CAH6Pt5o-6priSgKc8eOVdHJ2wsFPXT3=-AGSV40qY9F3U2SnYg@mail.gmail.com>
 <CA+A4wOmaPem2JnxTyt=cKGun6bwAAb+o1Cawy2Pipq5gKz2gPg@mail.gmail.com>
 <CAH6Pt5ogBBO8u-i9mR7kzvNUFQ5aybvwLkNkqQ3WTyuosNfF_A@mail.gmail.com>
Message-ID: <CA+A4wO=qsR+AP+=gnQn5H0z5_GsQ7D4JDAzem8j1zF3su3Kizw@mail.gmail.com>

hi matthew,

I don't know of any software that does behave differently for
> scl_slope of 0 or 1 - but I'd certainly like to know if there is any.
>

ITK:

https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/IO/NIFTI/src/itkNiftiImageIO.cxx#L398

and in the read function:

https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/IO/NIFTI/src/itkNiftiImageIO.cxx#L523


CIFTI/NIFTI2 library:

https://github.com/Washington-University/CiftiLib/blob/master/Nifti/NiftiHeader.cxx#L115


niftilib:

http://anonscm.debian.org/cgit/pkg-exppsy/nifticlib.git/tree/niftilib/nifti1_io.c#n5438

cheers,

satra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150721/1a2f6fb8/attachment.html>

From matthew.brett at gmail.com  Wed Jul 22 08:20:08 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Wed, 22 Jul 2015 07:20:08 +0100
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CA+A4wO=qsR+AP+=gnQn5H0z5_GsQ7D4JDAzem8j1zF3su3Kizw@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <20150706155516.GA28964@onerussian.com>
 <CAH6Pt5q8q+9Jomxy62PLKBRub7OYzVr+fQ_di+yjaa-vON=6VA@mail.gmail.com>
 <CAD4j9Gsse73vO8WO93HzLLsuvMWO6VYvg+1DC9GjdaS46iMUYg@mail.gmail.com>
 <CAH6Pt5pMgWVMSLCyo2qwy6+59CVqKL6NrgHi_Bhog2byWnKv8g@mail.gmail.com>
 <CAD4j9GtYcsk1A0uHoHZG1gXqzRBgfKsYON8gT8ZYUJ4EwnBMRQ@mail.gmail.com>
 <CAH6Pt5oo86oWqX00+A_DvdcS_nLLROJmoprmLHRw8DC89vzSmQ@mail.gmail.com>
 <CAD4j9GusB7GyMog6j13+UGgrkGBiHc3v_ngdv_fZXLifqd9YMA@mail.gmail.com>
 <CAH6Pt5q53dGKjPaOBduYzjHXyWdibu0Yg5p2BVAPsbp7gRrKAg@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F74B4AE@EXMB10.ohsu.edu>
 <CAH6Pt5o5CeERq_zbVYRv8A3en9ub2Za0JMjoFi-g-8h7B6p6mQ@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F74B622@EXMB10.ohsu.edu>
 <CAH6Pt5o-6priSgKc8eOVdHJ2wsFPXT3=-AGSV40qY9F3U2SnYg@mail.gmail.com>
 <CA+A4wOmaPem2JnxTyt=cKGun6bwAAb+o1Cawy2Pipq5gKz2gPg@mail.gmail.com>
 <CAH6Pt5ogBBO8u-i9mR7kzvNUFQ5aybvwLkNkqQ3WTyuosNfF_A@mail.gmail.com>
 <CA+A4wO=qsR+AP+=gnQn5H0z5_GsQ7D4JDAzem8j1zF3su3Kizw@mail.gmail.com>
Message-ID: <CAH6Pt5omeJay6xM7LQga5yZJmfWeThQLiPChrCaE_mxWihC8=A@mail.gmail.com>

Hi,

On Wed, Jul 22, 2015 at 2:56 AM, Satrajit Ghosh <satra at mit.edu> wrote:
> hi matthew,
>
>> I don't know of any software that does behave differently for
>> scl_slope of 0 or 1 - but I'd certainly like to know if there is any.
>
>
> ITK:
>
> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/IO/NIFTI/src/itkNiftiImageIO.cxx#L398
>
> and in the read function:
>
> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/IO/NIFTI/src/itkNiftiImageIO.cxx#L523

Sorry, it's early here, but to me this looks as if ITK is explicitly
treating 0 and 1 as the same:

bool
NiftiImageIO::MustRescale()
{
return std::abs(this->m_RescaleSlope) > std::numeric_limits< double >::epsilon()
&& ( std::abs(this->m_RescaleSlope - 1.0) > std::numeric_limits<
double >::epsilon()
|| std::abs(this->m_RescaleIntercept) > std::numeric_limits< double
>::epsilon() );
}

>
> CIFTI/NIFTI2 library:
>
> https://github.com/Washington-University/CiftiLib/blob/master/Nifti/NiftiHeader.cxx#L115

Same here surely?  It looks like they are setting the scaling to 1 if
the slope is 0.

>
> niftilib:
>
> http://anonscm.debian.org/cgit/pkg-exppsy/nifticlib.git/tree/niftilib/nifti1_io.c#n5438

It does look like a different code path here, but do you know what
effect if any this has on the subsequent processing?

Again - sorry if I missed something obvious,

Cheers,

Matthew

From satra at mit.edu  Wed Jul 22 14:40:36 2015
From: satra at mit.edu (Satrajit Ghosh)
Date: Wed, 22 Jul 2015 08:40:36 -0400
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAH6Pt5omeJay6xM7LQga5yZJmfWeThQLiPChrCaE_mxWihC8=A@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <20150706155516.GA28964@onerussian.com>
 <CAH6Pt5q8q+9Jomxy62PLKBRub7OYzVr+fQ_di+yjaa-vON=6VA@mail.gmail.com>
 <CAD4j9Gsse73vO8WO93HzLLsuvMWO6VYvg+1DC9GjdaS46iMUYg@mail.gmail.com>
 <CAH6Pt5pMgWVMSLCyo2qwy6+59CVqKL6NrgHi_Bhog2byWnKv8g@mail.gmail.com>
 <CAD4j9GtYcsk1A0uHoHZG1gXqzRBgfKsYON8gT8ZYUJ4EwnBMRQ@mail.gmail.com>
 <CAH6Pt5oo86oWqX00+A_DvdcS_nLLROJmoprmLHRw8DC89vzSmQ@mail.gmail.com>
 <CAD4j9GusB7GyMog6j13+UGgrkGBiHc3v_ngdv_fZXLifqd9YMA@mail.gmail.com>
 <CAH6Pt5q53dGKjPaOBduYzjHXyWdibu0Yg5p2BVAPsbp7gRrKAg@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F74B4AE@EXMB10.ohsu.edu>
 <CAH6Pt5o5CeERq_zbVYRv8A3en9ub2Za0JMjoFi-g-8h7B6p6mQ@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F74B622@EXMB10.ohsu.edu>
 <CAH6Pt5o-6priSgKc8eOVdHJ2wsFPXT3=-AGSV40qY9F3U2SnYg@mail.gmail.com>
 <CA+A4wOmaPem2JnxTyt=cKGun6bwAAb+o1Cawy2Pipq5gKz2gPg@mail.gmail.com>
 <CAH6Pt5ogBBO8u-i9mR7kzvNUFQ5aybvwLkNkqQ3WTyuosNfF_A@mail.gmail.com>
 <CA+A4wO=qsR+AP+=gnQn5H0z5_GsQ7D4JDAzem8j1zF3su3Kizw@mail.gmail.com>
 <CAH6Pt5omeJay6xM7LQga5yZJmfWeThQLiPChrCaE_mxWihC8=A@mail.gmail.com>
Message-ID: <CA+A4wOnjDmyKcmZFrmkVShk_3sK3wxTgDAmZNNSSOzbvmkyv9w@mail.gmail.com>

hi matthew,

Sorry, it's early here, but to me this looks as if ITK is explicitly
> treating 0 and 1 as the same:
>
> bool
> NiftiImageIO::MustRescale()
> {
> return std::abs(this->m_RescaleSlope) > std::numeric_limits< double
> >::epsilon()
> && ( std::abs(this->m_RescaleSlope - 1.0) > std::numeric_limits<
> double >::epsilon()
> || std::abs(this->m_RescaleIntercept) > std::numeric_limits< double
> >::epsilon() );
> }
>

MustRescale returns False if  this->m_RescaleSlope == 0 or
(this->m_RescaleSlope == 1 && this->m_RescaleIntercept == 0).

this boolean then gets used in the read function. i.e. under these
conditions data does not get scaled.

>
> > CIFTI/NIFTI2 library:
> >
> >
> https://github.com/Washington-University/CiftiLib/blob/master/Nifti/NiftiHeader.cxx#L115
>
> Same here surely?  It looks like they are setting the scaling to 1 if
> the slope is 0.
>

also returns false here, even though it sets it to 1 and 0, outside this
check it returns true.


> >
> > niftilib:
> >
> >
> http://anonscm.debian.org/cgit/pkg-exppsy/nifticlib.git/tree/niftilib/nifti1_io.c#n5438
>
> It does look like a different code path here, but do you know what
> effect if any this has on the subsequent processing?
>

here it doesn't do anything with scale or slope. leaves it to the developer.

cheers,

satra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150722/c50ba044/attachment.html>

From matthew.brett at gmail.com  Wed Jul 22 14:54:20 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Wed, 22 Jul 2015 13:54:20 +0100
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CA+A4wOnjDmyKcmZFrmkVShk_3sK3wxTgDAmZNNSSOzbvmkyv9w@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <20150706155516.GA28964@onerussian.com>
 <CAH6Pt5q8q+9Jomxy62PLKBRub7OYzVr+fQ_di+yjaa-vON=6VA@mail.gmail.com>
 <CAD4j9Gsse73vO8WO93HzLLsuvMWO6VYvg+1DC9GjdaS46iMUYg@mail.gmail.com>
 <CAH6Pt5pMgWVMSLCyo2qwy6+59CVqKL6NrgHi_Bhog2byWnKv8g@mail.gmail.com>
 <CAD4j9GtYcsk1A0uHoHZG1gXqzRBgfKsYON8gT8ZYUJ4EwnBMRQ@mail.gmail.com>
 <CAH6Pt5oo86oWqX00+A_DvdcS_nLLROJmoprmLHRw8DC89vzSmQ@mail.gmail.com>
 <CAD4j9GusB7GyMog6j13+UGgrkGBiHc3v_ngdv_fZXLifqd9YMA@mail.gmail.com>
 <CAH6Pt5q53dGKjPaOBduYzjHXyWdibu0Yg5p2BVAPsbp7gRrKAg@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F74B4AE@EXMB10.ohsu.edu>
 <CAH6Pt5o5CeERq_zbVYRv8A3en9ub2Za0JMjoFi-g-8h7B6p6mQ@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F74B622@EXMB10.ohsu.edu>
 <CAH6Pt5o-6priSgKc8eOVdHJ2wsFPXT3=-AGSV40qY9F3U2SnYg@mail.gmail.com>
 <CA+A4wOmaPem2JnxTyt=cKGun6bwAAb+o1Cawy2Pipq5gKz2gPg@mail.gmail.com>
 <CAH6Pt5ogBBO8u-i9mR7kzvNUFQ5aybvwLkNkqQ3WTyuosNfF_A@mail.gmail.com>
 <CA+A4wO=qsR+AP+=gnQn5H0z5_GsQ7D4JDAzem8j1zF3su3Kizw@mail.gmail.com>
 <CAH6Pt5omeJay6xM7LQga5yZJmfWeThQLiPChrCaE_mxWihC8=A@mail.gmail.com>
 <CA+A4wOnjDmyKcmZFrmkVShk_3sK3wxTgDAmZNNSSOzbvmkyv9w@mail.gmail.com>
Message-ID: <CAH6Pt5rzaFM--t6QmACdQGROyt1zRw+VOHoCfDtYZ-cbhr0GaQ@mail.gmail.com>

Hi,

On Wed, Jul 22, 2015 at 1:40 PM, Satrajit Ghosh <satra at mit.edu> wrote:
> hi matthew,
>
>> Sorry, it's early here, but to me this looks as if ITK is explicitly
>> treating 0 and 1 as the same:
>>
>> bool
>> NiftiImageIO::MustRescale()
>> {
>> return std::abs(this->m_RescaleSlope) > std::numeric_limits< double
>> >::epsilon()
>> && ( std::abs(this->m_RescaleSlope - 1.0) > std::numeric_limits<
>> double >::epsilon()
>> || std::abs(this->m_RescaleIntercept) > std::numeric_limits< double
>> >::epsilon() );
>> }
>
>
> MustRescale returns False if  this->m_RescaleSlope == 0 or
> (this->m_RescaleSlope == 1 && this->m_RescaleIntercept == 0).
>
> this boolean then gets used in the read function. i.e. under these
> conditions data does not get scaled.

Oh - sorry - you were only trying to say that either 0 or scalefactors
(1, 0) mean that scaling does not get applied?  Yes, sure, it would be
inefficient to apply scaling where it has no effect.

I was only saying that scl_slope of 1 and 0 are treated the same
(apart from the fact that scl_slope of 0 results in scl_inter being
discarded).

>> > CIFTI/NIFTI2 library:
>> >
>> >
>> > https://github.com/Washington-University/CiftiLib/blob/master/Nifti/NiftiHeader.cxx#L115
>>
>> Same here surely?  It looks like they are setting the scaling to 1 if
>> the slope is 0.
>
>
> also returns false here, even though it sets it to 1 and 0, outside this
> check it returns true.

But you agree that scl_slope of 1 or 0 are treated the same (apart
from scl_inter being discarded for scl_slope == 0)?   In both cases
the check returns False.

>>
>> >
>> > niftilib:
>> >
>> >
>> > http://anonscm.debian.org/cgit/pkg-exppsy/nifticlib.git/tree/niftilib/nifti1_io.c#n5438
>>
>> It does look like a different code path here, but do you know what
>> effect if any this has on the subsequent processing?
>
>
> here it doesn't do anything with scale or slope. leaves it to the developer.

Right - that code path doesn't imply any difference in the behavior as
far as I can see.

Cheers,

Matthew

From francois.rousseau at telecom-bretagne.eu  Wed Jul 22 15:00:03 2015
From: francois.rousseau at telecom-bretagne.eu (=?utf-8?Q?Fran=C3=A7ois_Rousseau?=)
Date: Wed, 22 Jul 2015 15:00:03 +0200
Subject: [Neuroimaging] How to apply an affine transform estimated from ITK?
Message-ID: <8047D263-6E5F-4256-9178-0FD6ACD1BE76@telecom-bretagne.eu>

Hi everyone,

I?m trying to apply an affine transform estimated from an ITK-based program onto a nifti image using nibabel.

The transform has to be applied in the world coordinate space. The issue lies in the transition from index space to world space.

Using nibabel, I?ve to apply the affine matrix (Img.affine) to the index point.
With ITK, I use this : Img->TransformIndexToPhysicalPoint() which does the same job.

However, the results are not the same. There is a minus sign for x and y. I don?t understand where the issue comes from. Any help?

Thank you,
Fran?ois
PS : I?ve noticed something weird to me. When ITK indicates that the image is in RAS, nibabel says LPI !

From satra at mit.edu  Wed Jul 22 15:09:44 2015
From: satra at mit.edu (Satrajit Ghosh)
Date: Wed, 22 Jul 2015 09:09:44 -0400
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAH6Pt5rzaFM--t6QmACdQGROyt1zRw+VOHoCfDtYZ-cbhr0GaQ@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <20150706155516.GA28964@onerussian.com>
 <CAH6Pt5q8q+9Jomxy62PLKBRub7OYzVr+fQ_di+yjaa-vON=6VA@mail.gmail.com>
 <CAD4j9Gsse73vO8WO93HzLLsuvMWO6VYvg+1DC9GjdaS46iMUYg@mail.gmail.com>
 <CAH6Pt5pMgWVMSLCyo2qwy6+59CVqKL6NrgHi_Bhog2byWnKv8g@mail.gmail.com>
 <CAD4j9GtYcsk1A0uHoHZG1gXqzRBgfKsYON8gT8ZYUJ4EwnBMRQ@mail.gmail.com>
 <CAH6Pt5oo86oWqX00+A_DvdcS_nLLROJmoprmLHRw8DC89vzSmQ@mail.gmail.com>
 <CAD4j9GusB7GyMog6j13+UGgrkGBiHc3v_ngdv_fZXLifqd9YMA@mail.gmail.com>
 <CAH6Pt5q53dGKjPaOBduYzjHXyWdibu0Yg5p2BVAPsbp7gRrKAg@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F74B4AE@EXMB10.ohsu.edu>
 <CAH6Pt5o5CeERq_zbVYRv8A3en9ub2Za0JMjoFi-g-8h7B6p6mQ@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F74B622@EXMB10.ohsu.edu>
 <CAH6Pt5o-6priSgKc8eOVdHJ2wsFPXT3=-AGSV40qY9F3U2SnYg@mail.gmail.com>
 <CA+A4wOmaPem2JnxTyt=cKGun6bwAAb+o1Cawy2Pipq5gKz2gPg@mail.gmail.com>
 <CAH6Pt5ogBBO8u-i9mR7kzvNUFQ5aybvwLkNkqQ3WTyuosNfF_A@mail.gmail.com>
 <CA+A4wO=qsR+AP+=gnQn5H0z5_GsQ7D4JDAzem8j1zF3su3Kizw@mail.gmail.com>
 <CAH6Pt5omeJay6xM7LQga5yZJmfWeThQLiPChrCaE_mxWihC8=A@mail.gmail.com>
 <CA+A4wOnjDmyKcmZFrmkVShk_3sK3wxTgDAmZNNSSOzbvmkyv9w@mail.gmail.com>
 <CAH6Pt5rzaFM--t6QmACdQGROyt1zRw+VOHoCfDtYZ-cbhr0GaQ@mail.gmail.com>
Message-ID: <CA+A4wOmzGzcf7BPDszMhq_rhVGtfxxcMhWJTyWY5V+YqKv=t8g@mail.gmail.com>

hi matthew,


> Oh - sorry - you were only trying to say that either 0 or scalefactors
> (1, 0) mean that scaling does not get applied?  Yes, sure, it would be
> inefficient to apply scaling where it has no effect.
>
> I was only saying that scl_slope of 1 and 0 are treated the same
> (apart from the fact that scl_slope of 0 results in scl_inter being
> discarded).
>

> But you agree that scl_slope of 1 or 0 are treated the same (apart
> from scl_inter being discarded for scl_slope == 0)?   In both cases
> the check returns False.
>

i do agree that these are being treated similarly, but unlike the proposed
change in nibabel, the ITK library would return unscaled data in its native
datatype when scalefactors (0, X) or (1, 0).

with the proposed change to as_float, i was hoping that these instances
would allow for some flexibility in the nibabel api to at least get at the
raw header version of these values, or perhaps set a property based on the
raw values. if we read unscaled data and wanted to do something with it, we
could read the original intent of the writer of the file (whether rightly
or wrongly). currently, it appears that we cannot recover this information
without re-reading the binary header.

cheers,

satra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150722/9fbffb61/attachment.html>

From francois.rousseau at telecom-bretagne.eu  Wed Jul 22 15:36:02 2015
From: francois.rousseau at telecom-bretagne.eu (=?utf-8?Q?Fran=C3=A7ois_Rousseau?=)
Date: Wed, 22 Jul 2015 15:36:02 +0200
Subject: [Neuroimaging] How to apply an affine transform estimated from
	ITK?
In-Reply-To: <8047D263-6E5F-4256-9178-0FD6ACD1BE76@telecom-bretagne.eu>
References: <8047D263-6E5F-4256-9178-0FD6ACD1BE76@telecom-bretagne.eu>
Message-ID: <250126D5-43FB-4953-BFE6-A2CA8348DCD6@telecom-bretagne.eu>

> 
> However, the results are not the same. There is a minus sign for x and y. I don?t understand where the issue comes from. Any help?

As far I understand, it seems that it comes from that ITK uses LPS and nibabel uses RAS.

Is there any function in nibabel to handle such thing ?transparently? ?

Fran?ois


From matthew.brett at gmail.com  Wed Jul 22 15:37:08 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Wed, 22 Jul 2015 14:37:08 +0100
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CA+A4wOmzGzcf7BPDszMhq_rhVGtfxxcMhWJTyWY5V+YqKv=t8g@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <20150706155516.GA28964@onerussian.com>
 <CAH6Pt5q8q+9Jomxy62PLKBRub7OYzVr+fQ_di+yjaa-vON=6VA@mail.gmail.com>
 <CAD4j9Gsse73vO8WO93HzLLsuvMWO6VYvg+1DC9GjdaS46iMUYg@mail.gmail.com>
 <CAH6Pt5pMgWVMSLCyo2qwy6+59CVqKL6NrgHi_Bhog2byWnKv8g@mail.gmail.com>
 <CAD4j9GtYcsk1A0uHoHZG1gXqzRBgfKsYON8gT8ZYUJ4EwnBMRQ@mail.gmail.com>
 <CAH6Pt5oo86oWqX00+A_DvdcS_nLLROJmoprmLHRw8DC89vzSmQ@mail.gmail.com>
 <CAD4j9GusB7GyMog6j13+UGgrkGBiHc3v_ngdv_fZXLifqd9YMA@mail.gmail.com>
 <CAH6Pt5q53dGKjPaOBduYzjHXyWdibu0Yg5p2BVAPsbp7gRrKAg@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F74B4AE@EXMB10.ohsu.edu>
 <CAH6Pt5o5CeERq_zbVYRv8A3en9ub2Za0JMjoFi-g-8h7B6p6mQ@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F74B622@EXMB10.ohsu.edu>
 <CAH6Pt5o-6priSgKc8eOVdHJ2wsFPXT3=-AGSV40qY9F3U2SnYg@mail.gmail.com>
 <CA+A4wOmaPem2JnxTyt=cKGun6bwAAb+o1Cawy2Pipq5gKz2gPg@mail.gmail.com>
 <CAH6Pt5ogBBO8u-i9mR7kzvNUFQ5aybvwLkNkqQ3WTyuosNfF_A@mail.gmail.com>
 <CA+A4wO=qsR+AP+=gnQn5H0z5_GsQ7D4JDAzem8j1zF3su3Kizw@mail.gmail.com>
 <CAH6Pt5omeJay6xM7LQga5yZJmfWeThQLiPChrCaE_mxWihC8=A@mail.gmail.com>
 <CA+A4wOnjDmyKcmZFrmkVShk_3sK3wxTgDAmZNNSSOzbvmkyv9w@mail.gmail.com>
 <CAH6Pt5rzaFM--t6QmACdQGROyt1zRw+VOHoCfDtYZ-cbhr0GaQ@mail.gmail.com>
 <CA+A4wOmzGzcf7BPDszMhq_rhVGtfxxcMhWJTyWY5V+YqKv=t8g@mail.gmail.com>
Message-ID: <CAH6Pt5qRWJe9W+nQ7FxKVjisRXedmesPjvuC6OCF0b2MzGO_rA@mail.gmail.com>

On Wed, Jul 22, 2015 at 2:09 PM, Satrajit Ghosh <satra at mit.edu> wrote:
> hi matthew,
>
>>
>> Oh - sorry - you were only trying to say that either 0 or scalefactors
>> (1, 0) mean that scaling does not get applied?  Yes, sure, it would be
>> inefficient to apply scaling where it has no effect.
>>
>> I was only saying that scl_slope of 1 and 0 are treated the same
>> (apart from the fact that scl_slope of 0 results in scl_inter being
>> discarded).
>>
>>
>> But you agree that scl_slope of 1 or 0 are treated the same (apart
>> from scl_inter being discarded for scl_slope == 0)?   In both cases
>> the check returns False.
>
>
> i do agree that these are being treated similarly, but unlike the proposed
> change in nibabel, the ITK library would return unscaled data in its native
> datatype when scalefactors (0, X) or (1, 0).

I didn't look to see what data type ITK returns, but it's easy to
believe that they would do what we were doing before.

> with the proposed change to as_float, i was hoping that these instances
> would allow for some flexibility in the nibabel api to at least get at the
> raw header version of these values, or perhaps set a property based on the
> raw values. if we read unscaled data and wanted to do something with it, we
> could read the original intent of the writer of the file (whether rightly or
> wrongly). currently, it appears that we cannot recover this information
> without re-reading the binary header.

Just to check once more - you believe that 0 in scl_slope means that
the writer of the file intended for the data to be read into memory
with the on-disk datatype?  I don't think that's what the standard
means by:

"""
If the scl_slope field is nonzero, then each voxel value in the dataset
   should be scaled as
      y = scl_slope * x + scl_inter
"""

I think the standard is only saying that the scalefactors are for
scaling the data values.  For example. I really don't think the
standard is saying that scalefactors of (1, 0) should be interpreted
as meaning the data should be necessarily be float in memory, and the
code you've pointed to suggests to me these other libraries don't
think that either.

Cheers,

Matthew

From matthew.brett at gmail.com  Wed Jul 22 15:46:01 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Wed, 22 Jul 2015 14:46:01 +0100
Subject: [Neuroimaging] How to apply an affine transform estimated from
	ITK?
In-Reply-To: <250126D5-43FB-4953-BFE6-A2CA8348DCD6@telecom-bretagne.eu>
References: <8047D263-6E5F-4256-9178-0FD6ACD1BE76@telecom-bretagne.eu>
 <250126D5-43FB-4953-BFE6-A2CA8348DCD6@telecom-bretagne.eu>
Message-ID: <CAH6Pt5of6PKRpygXK_RQfF6VSYVBo8MAX=GDeBZ_usCHU0dZ=g@mail.gmail.com>

Hi,

On Wed, Jul 22, 2015 at 2:36 PM, Fran?ois Rousseau
<francois.rousseau at telecom-bretagne.eu> wrote:
>>
>> However, the results are not the same. There is a minus sign for x and y. I don?t understand where the issue comes from. Any help?
>
> As far I understand, it seems that it comes from that ITK uses LPS and nibabel uses RAS.
>
> Is there any function in nibabel to handle such thing ?transparently? ?

Not transparently, no.  I'm afraid you have do something like:

RAS2LPS = np.diag([-1, -1, 1, 1])
vox2itk_world = LPS2RAS.dot(img.affine)
lpi_world_pts = nib.affines.apply_affine(vox2itk_world, vox_pts)

Is that what you mean?

Cheers,

Matthew

From francois.rousseau at telecom-bretagne.eu  Wed Jul 22 15:55:10 2015
From: francois.rousseau at telecom-bretagne.eu (=?utf-8?Q?Fran=C3=A7ois_Rousseau?=)
Date: Wed, 22 Jul 2015 15:55:10 +0200
Subject: [Neuroimaging] How to apply an affine transform estimated from
	ITK?
In-Reply-To: <CAH6Pt5of6PKRpygXK_RQfF6VSYVBo8MAX=GDeBZ_usCHU0dZ=g@mail.gmail.com>
References: <8047D263-6E5F-4256-9178-0FD6ACD1BE76@telecom-bretagne.eu>
 <250126D5-43FB-4953-BFE6-A2CA8348DCD6@telecom-bretagne.eu>
 <CAH6Pt5of6PKRpygXK_RQfF6VSYVBo8MAX=GDeBZ_usCHU0dZ=g@mail.gmail.com>
Message-ID: <91E9ECAF-6237-4838-AFE8-029AFE17E05D@telecom-bretagne.eu>

> 
> Not transparently, no.  I'm afraid you have do something like:
> 
> RAS2LPS = np.diag([-1, -1, 1, 1])
> vox2itk_world = LPS2RAS.dot(img.affine)
> lpi_world_pts = nib.affines.apply_affine(vox2itk_world, vox_pts)
> 
> Is that what you mean?
> 


Yes, exactly. This is what I?m doing right now. Thank you Matthew.

However, I still do have another question.

In ITK, the index coordinates (say for instance (0,0,0) ) correspond to the center of a voxel.
It seems that in nibabel, it correspond to the corner of a voxel. Am I right? (I didn?t find that in the documentation)

Such difference can introduce a shift of half a voxel in registration / interpolation / reconstruction algorithms.

Fran?ois



From satra at mit.edu  Wed Jul 22 15:57:16 2015
From: satra at mit.edu (Satrajit Ghosh)
Date: Wed, 22 Jul 2015 09:57:16 -0400
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAH6Pt5qRWJe9W+nQ7FxKVjisRXedmesPjvuC6OCF0b2MzGO_rA@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <20150706155516.GA28964@onerussian.com>
 <CAH6Pt5q8q+9Jomxy62PLKBRub7OYzVr+fQ_di+yjaa-vON=6VA@mail.gmail.com>
 <CAD4j9Gsse73vO8WO93HzLLsuvMWO6VYvg+1DC9GjdaS46iMUYg@mail.gmail.com>
 <CAH6Pt5pMgWVMSLCyo2qwy6+59CVqKL6NrgHi_Bhog2byWnKv8g@mail.gmail.com>
 <CAD4j9GtYcsk1A0uHoHZG1gXqzRBgfKsYON8gT8ZYUJ4EwnBMRQ@mail.gmail.com>
 <CAH6Pt5oo86oWqX00+A_DvdcS_nLLROJmoprmLHRw8DC89vzSmQ@mail.gmail.com>
 <CAD4j9GusB7GyMog6j13+UGgrkGBiHc3v_ngdv_fZXLifqd9YMA@mail.gmail.com>
 <CAH6Pt5q53dGKjPaOBduYzjHXyWdibu0Yg5p2BVAPsbp7gRrKAg@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F74B4AE@EXMB10.ohsu.edu>
 <CAH6Pt5o5CeERq_zbVYRv8A3en9ub2Za0JMjoFi-g-8h7B6p6mQ@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F74B622@EXMB10.ohsu.edu>
 <CAH6Pt5o-6priSgKc8eOVdHJ2wsFPXT3=-AGSV40qY9F3U2SnYg@mail.gmail.com>
 <CA+A4wOmaPem2JnxTyt=cKGun6bwAAb+o1Cawy2Pipq5gKz2gPg@mail.gmail.com>
 <CAH6Pt5ogBBO8u-i9mR7kzvNUFQ5aybvwLkNkqQ3WTyuosNfF_A@mail.gmail.com>
 <CA+A4wO=qsR+AP+=gnQn5H0z5_GsQ7D4JDAzem8j1zF3su3Kizw@mail.gmail.com>
 <CAH6Pt5omeJay6xM7LQga5yZJmfWeThQLiPChrCaE_mxWihC8=A@mail.gmail.com>
 <CA+A4wOnjDmyKcmZFrmkVShk_3sK3wxTgDAmZNNSSOzbvmkyv9w@mail.gmail.com>
 <CAH6Pt5rzaFM--t6QmACdQGROyt1zRw+VOHoCfDtYZ-cbhr0GaQ@mail.gmail.com>
 <CA+A4wOmzGzcf7BPDszMhq_rhVGtfxxcMhWJTyWY5V+YqKv=t8g@mail.gmail.com>
 <CAH6Pt5qRWJe9W+nQ7FxKVjisRXedmesPjvuC6OCF0b2MzGO_rA@mail.gmail.com>
Message-ID: <CA+A4wOk5fPv01QeX-0CXSxoH1VTEn-9obN-eewAJ9LmAgxjxrQ@mail.gmail.com>

hi matthew,

Just to check once more - you believe that 0 in scl_slope means that
> the writer of the file intended for the data to be read into memory
> with the on-disk datatype?  I don't think that's what the standard
> means by:
>
> """
> If the scl_slope field is nonzero, then each voxel value in the dataset
>    should be scaled as
>       y = scl_slope * x + scl_inter
> """
>

i don't think the standard says anything about in-memory representation.
it's easy to see that subject to not scaling beyond limits and precision
capabilities of the native datatype, one can keep the data in native dtype.

i don't really know what the writers meant. what i do know is that the
reference niftiio library that was written by a subset of the same authors
did not interpret this and stored the data in native dtype and without
scaling. much in the sense that even after 14 years of nifti-1 we don't
know what all the use cases are, and for nifti2/cifti, which uses the same
logic, the use cases have definitely changed.

I think the standard is only saying that the scalefactors are for
> scaling the data values.  For example. I really don't think the
> standard is saying that scalefactors of (1, 0) should be interpreted
> as meaning the data should be necessarily be float in memory, and the
> code you've pointed to suggests to me these other libraries don't
> think that either.
>

i agree. which is why i am suggesting  that our new api have a pathway to
let the developer decide what to do with the data without having to re-read
binary headers. i.e. a developer should have access to raw scalefactors
(this is not there) and the raw data in native dtype (this is already
there).

cheers,

satra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150722/026fe10a/attachment.html>

From matthew.brett at gmail.com  Wed Jul 22 16:44:24 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Wed, 22 Jul 2015 15:44:24 +0100
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CA+A4wOk5fPv01QeX-0CXSxoH1VTEn-9obN-eewAJ9LmAgxjxrQ@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <20150706155516.GA28964@onerussian.com>
 <CAH6Pt5q8q+9Jomxy62PLKBRub7OYzVr+fQ_di+yjaa-vON=6VA@mail.gmail.com>
 <CAD4j9Gsse73vO8WO93HzLLsuvMWO6VYvg+1DC9GjdaS46iMUYg@mail.gmail.com>
 <CAH6Pt5pMgWVMSLCyo2qwy6+59CVqKL6NrgHi_Bhog2byWnKv8g@mail.gmail.com>
 <CAD4j9GtYcsk1A0uHoHZG1gXqzRBgfKsYON8gT8ZYUJ4EwnBMRQ@mail.gmail.com>
 <CAH6Pt5oo86oWqX00+A_DvdcS_nLLROJmoprmLHRw8DC89vzSmQ@mail.gmail.com>
 <CAD4j9GusB7GyMog6j13+UGgrkGBiHc3v_ngdv_fZXLifqd9YMA@mail.gmail.com>
 <CAH6Pt5q53dGKjPaOBduYzjHXyWdibu0Yg5p2BVAPsbp7gRrKAg@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F74B4AE@EXMB10.ohsu.edu>
 <CAH6Pt5o5CeERq_zbVYRv8A3en9ub2Za0JMjoFi-g-8h7B6p6mQ@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F74B622@EXMB10.ohsu.edu>
 <CAH6Pt5o-6priSgKc8eOVdHJ2wsFPXT3=-AGSV40qY9F3U2SnYg@mail.gmail.com>
 <CA+A4wOmaPem2JnxTyt=cKGun6bwAAb+o1Cawy2Pipq5gKz2gPg@mail.gmail.com>
 <CAH6Pt5ogBBO8u-i9mR7kzvNUFQ5aybvwLkNkqQ3WTyuosNfF_A@mail.gmail.com>
 <CA+A4wO=qsR+AP+=gnQn5H0z5_GsQ7D4JDAzem8j1zF3su3Kizw@mail.gmail.com>
 <CAH6Pt5omeJay6xM7LQga5yZJmfWeThQLiPChrCaE_mxWihC8=A@mail.gmail.com>
 <CA+A4wOnjDmyKcmZFrmkVShk_3sK3wxTgDAmZNNSSOzbvmkyv9w@mail.gmail.com>
 <CAH6Pt5rzaFM--t6QmACdQGROyt1zRw+VOHoCfDtYZ-cbhr0GaQ@mail.gmail.com>
 <CA+A4wOmzGzcf7BPDszMhq_rhVGtfxxcMhWJTyWY5V+YqKv=t8g@mail.gmail.com>
 <CAH6Pt5qRWJe9W+nQ7FxKVjisRXedmesPjvuC6OCF0b2MzGO_rA@mail.gmail.com>
 <CA+A4wOk5fPv01QeX-0CXSxoH1VTEn-9obN-eewAJ9LmAgxjxrQ@mail.gmail.com>
Message-ID: <CAH6Pt5pD=wJKA8Af4G1Sd6vDfq_YBTdP9_yGCtPNvAu0CC3_EQ@mail.gmail.com>

Hi,

On Wed, Jul 22, 2015 at 2:57 PM, Satrajit Ghosh <satra at mit.edu> wrote:
> hi matthew,
>
>> Just to check once more - you believe that 0 in scl_slope means that
>> the writer of the file intended for the data to be read into memory
>> with the on-disk datatype?  I don't think that's what the standard
>> means by:
>>
>> """
>> If the scl_slope field is nonzero, then each voxel value in the dataset
>>    should be scaled as
>>       y = scl_slope * x + scl_inter
>> """
>
>
> i don't think the standard says anything about in-memory representation.
> it's easy to see that subject to not scaling beyond limits and precision
> capabilities of the native datatype, one can keep the data in native dtype.
>
> i don't really know what the writers meant. what i do know is that the
> reference niftiio library that was written by a subset of the same authors
> did not interpret this and stored the data in native dtype and without
> scaling.

I'm not sure what you mean by 'did not interpret this' unless you are
agreeing with me that the niftiio library gives no clues as what the
intention for the in-memory type was.  If anything I think that
supports my reading that the authors had not considered the
interpretation of "scl_slope != 0 -> in-memory float".

>> I think the standard is only saying that the scalefactors are for
>> scaling the data values.  For example. I really don't think the
>> standard is saying that scalefactors of (1, 0) should be interpreted
>> as meaning the data should be necessarily be float in memory, and the
>> code you've pointed to suggests to me these other libraries don't
>> think that either.
>
>
> i agree. which is why i am suggesting  that our new api have a pathway to
> let the developer decide what to do with the data without having to re-read
> binary headers. i.e. a developer should have access to raw scalefactors
> (this is not there) and the raw data in native dtype (this is already
> there).

I can surely attach the raw scalefactors to the array proxy (dataobj),
but I think it's a terrible idea to use the scl_slope == 0 as an
indication for in-memory type, because it's not a convention that (as
far as I know) anyone else uses,

Cheers,

Matthew

From matthew.brett at gmail.com  Wed Jul 22 16:50:03 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Wed, 22 Jul 2015 15:50:03 +0100
Subject: [Neuroimaging] How to apply an affine transform estimated from
	ITK?
In-Reply-To: <91E9ECAF-6237-4838-AFE8-029AFE17E05D@telecom-bretagne.eu>
References: <8047D263-6E5F-4256-9178-0FD6ACD1BE76@telecom-bretagne.eu>
 <250126D5-43FB-4953-BFE6-A2CA8348DCD6@telecom-bretagne.eu>
 <CAH6Pt5of6PKRpygXK_RQfF6VSYVBo8MAX=GDeBZ_usCHU0dZ=g@mail.gmail.com>
 <91E9ECAF-6237-4838-AFE8-029AFE17E05D@telecom-bretagne.eu>
Message-ID: <CAH6Pt5oydGdJC27SBOQLym-Nb2qMwR1kdhc55upmtqch+wDqOQ@mail.gmail.com>

Hi,

On Wed, Jul 22, 2015 at 2:55 PM, Fran?ois Rousseau
<francois.rousseau at telecom-bretagne.eu> wrote:
>>
>> Not transparently, no.  I'm afraid you have do something like:
>>
>> RAS2LPS = np.diag([-1, -1, 1, 1])
>> vox2itk_world = LPS2RAS.dot(img.affine)
>> lpi_world_pts = nib.affines.apply_affine(vox2itk_world, vox_pts)
>>
>> Is that what you mean?
>>
>
>
> Yes, exactly. This is what I?m doing right now. Thank you Matthew.
>
> However, I still do have another question.
>
> In ITK, the index coordinates (say for instance (0,0,0) ) correspond to the center of a voxel.
> It seems that in nibabel, it correspond to the corner of a voxel. Am I right? (I didn?t find that in the documentation)
>
> Such difference can introduce a shift of half a voxel in registration / interpolation / reconstruction algorithms.

You're right to worry about this, of course.  The NIfTI standard says that:

"The (x,y,z) coordinates refer to the CENTER of a voxel"

http://nifti.nimh.nih.gov/pub/dist/src/niftilib/nifti1.h

That is also the convention that nibabel uses, in general, but it's
true that isn't documented properly:

https://github.com/nipy/nibabel/issues/333

Cheers,

Matthew

From satra at mit.edu  Wed Jul 22 16:53:17 2015
From: satra at mit.edu (Satrajit Ghosh)
Date: Wed, 22 Jul 2015 10:53:17 -0400
Subject: [Neuroimaging] Nibabel API change - always read as float
In-Reply-To: <CAH6Pt5pD=wJKA8Af4G1Sd6vDfq_YBTdP9_yGCtPNvAu0CC3_EQ@mail.gmail.com>
References: <CAH6Pt5rTZiZqaQ==APoyfMR7UZN+cTSLk3-fK3zVtLWAhycEhQ@mail.gmail.com>
 <20150706155516.GA28964@onerussian.com>
 <CAH6Pt5q8q+9Jomxy62PLKBRub7OYzVr+fQ_di+yjaa-vON=6VA@mail.gmail.com>
 <CAD4j9Gsse73vO8WO93HzLLsuvMWO6VYvg+1DC9GjdaS46iMUYg@mail.gmail.com>
 <CAH6Pt5pMgWVMSLCyo2qwy6+59CVqKL6NrgHi_Bhog2byWnKv8g@mail.gmail.com>
 <CAD4j9GtYcsk1A0uHoHZG1gXqzRBgfKsYON8gT8ZYUJ4EwnBMRQ@mail.gmail.com>
 <CAH6Pt5oo86oWqX00+A_DvdcS_nLLROJmoprmLHRw8DC89vzSmQ@mail.gmail.com>
 <CAD4j9GusB7GyMog6j13+UGgrkGBiHc3v_ngdv_fZXLifqd9YMA@mail.gmail.com>
 <CAH6Pt5q53dGKjPaOBduYzjHXyWdibu0Yg5p2BVAPsbp7gRrKAg@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F74B4AE@EXMB10.ohsu.edu>
 <CAH6Pt5o5CeERq_zbVYRv8A3en9ub2Za0JMjoFi-g-8h7B6p6mQ@mail.gmail.com>
 <5F6A858FD00E5F4A82E3206D2D854EF87F74B622@EXMB10.ohsu.edu>
 <CAH6Pt5o-6priSgKc8eOVdHJ2wsFPXT3=-AGSV40qY9F3U2SnYg@mail.gmail.com>
 <CA+A4wOmaPem2JnxTyt=cKGun6bwAAb+o1Cawy2Pipq5gKz2gPg@mail.gmail.com>
 <CAH6Pt5ogBBO8u-i9mR7kzvNUFQ5aybvwLkNkqQ3WTyuosNfF_A@mail.gmail.com>
 <CA+A4wO=qsR+AP+=gnQn5H0z5_GsQ7D4JDAzem8j1zF3su3Kizw@mail.gmail.com>
 <CAH6Pt5omeJay6xM7LQga5yZJmfWeThQLiPChrCaE_mxWihC8=A@mail.gmail.com>
 <CA+A4wOnjDmyKcmZFrmkVShk_3sK3wxTgDAmZNNSSOzbvmkyv9w@mail.gmail.com>
 <CAH6Pt5rzaFM--t6QmACdQGROyt1zRw+VOHoCfDtYZ-cbhr0GaQ@mail.gmail.com>
 <CA+A4wOmzGzcf7BPDszMhq_rhVGtfxxcMhWJTyWY5V+YqKv=t8g@mail.gmail.com>
 <CAH6Pt5qRWJe9W+nQ7FxKVjisRXedmesPjvuC6OCF0b2MzGO_rA@mail.gmail.com>
 <CA+A4wOk5fPv01QeX-0CXSxoH1VTEn-9obN-eewAJ9LmAgxjxrQ@mail.gmail.com>
 <CAH6Pt5pD=wJKA8Af4G1Sd6vDfq_YBTdP9_yGCtPNvAu0CC3_EQ@mail.gmail.com>
Message-ID: <CA+A4wOkUM+xEkC0atJpk6wQiC+wvAiuL+x-P-QPYU_t3o0Oiiw@mail.gmail.com>

hi matthew,

I'm not sure what you mean by 'did not interpret this' unless you are
> agreeing with me that the niftiio library gives no clues as what the
> intention for the in-memory type was.  If anything I think that
> supports my reading that the authors had not considered the
> interpretation of "scl_slope != 0 -> in-memory float".
>

i simply meant they left any interpretation of how to scale or change of
in-memory data type to the end developer.

I can surely attach the raw scalefactors to the array proxy (dataobj),
>

that would be great


> but I think it's a terrible idea to use the scl_slope == 0 as an
> indication for in-memory type, because it's not a convention that (as
> far as I know) anyone else uses,
>

all the examples of the code bases i provided in fact leave the in-memory
type to be the same as the native dtype for scalefactors (0, X) and (1, 0).
i agree, that this is an implementation of the standard as interpreted by
those developers, similar to present nibabel. i do agree that nifti authors
had nothing to say about such an interpretation.

cheers,

satra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150722/32bec1a8/attachment.html>

From maxime.descoteaux at gmail.com  Thu Jul 23 22:55:21 2015
From: maxime.descoteaux at gmail.com (Maxime Descoteaux)
Date: Thu, 23 Jul 2015 16:55:21 -0400
Subject: [Neuroimaging] [Dipy] Scanning parameters of Dipy's sample data
 Sherbrooke's 3 shells
In-Reply-To: <CALQBObLp2Y_k+DNhMUytvhS3Z4gzce2DKshxz_sHc2xQXibxXw@mail.gmail.com>
References: <CALQBObLp2Y_k+DNhMUytvhS3Z4gzce2DKshxz_sHc2xQXibxXw@mail.gmail.com>
Message-ID: <CAChMOMfNio_X161sOBWsO1W2EbARVNFfGqavNk23JjywH82Bzw@mail.gmail.com>

Hi Rafael,

I unfortunately have no trace of the DICOM data anymore.

All I can tell you is that it is 1.5T, Siemens Magnetom, 2mm isotropic. The
TR/TE must have been fixed for the maximal b-value, which explains a lower
SNR at smaller shells that you are probably used to see.

Also, all directions are the same at each shell.

It would be quite easy to share a new dataset from our Philips 3T if you
need.


Max

On Thu, Jul 9, 2015 at 1:57 PM, Rafael Henriques <rafaelnh21 at gmail.com>
wrote:

> Hi Max,
>
> Thanks for your fast reply.
>
> Indeed kurtosis values depend on Delta/delta (e.g.
> http://www.ncbi.nlm.nih.gov/pubmed/23536232), however knowing only the
> basic parameters as TE/TR and voxel resolution should be enough to
> understand what is going wrong with this dataset.
>
> I think that the problem here might be an insufficient SNR for fitting the
> diffusion kurtosis model. From previous datasets that I analysed, I was
> able to obtain decent DKI reconstructions using similar gradient directions
> and b-values, however this was done on a 3T Siemens using a 32 coil head
> channel.
>
> I will give a look to the datasets SNR estimates.
>
> Thanks for your help =),
>
> Rafael
>
>
> _______________________________________________
> 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/20150723/68f47a8c/attachment.html>

From arnaud.bore at gmail.com  Fri Jul 24 17:18:12 2015
From: arnaud.bore at gmail.com (=?UTF-8?B?QXJuYXVkIEJvcsOp?=)
Date: Fri, 24 Jul 2015 11:18:12 -0400
Subject: [Neuroimaging] [Nipy-devel] [dipy] PIESNO
Message-ID: <CAPA8YjZ-ZiZrRWr812v+xjJF8v8E-fRHU_p+tLDyaoin=0evKw@mail.gmail.com>

Dear dipy experts,

I try to figure out how to use PIESNO to estimate the noise. In the example
http://nipy.org/dipy/examples_built/piesno.html#example-piesno we don't
know about the grappa factor. Is it 3 so we have N = 12 (number of coils) /
3 (grappa factor) ?

Last question if we don't use grappa then N = 12 ?

Thank you

-- 
Arnaud BORE
Research assistant
Cellulaire : (001) 514-647-8649
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150724/25bb4b8a/attachment.html>

From stjeansam at gmail.com  Fri Jul 24 17:31:42 2015
From: stjeansam at gmail.com (Samuel St-Jean)
Date: Fri, 24 Jul 2015 11:31:42 -0400
Subject: [Neuroimaging] [Nipy-devel] [dipy] PIESNO
In-Reply-To: <CAPA8YjZ-ZiZrRWr812v+xjJF8v8E-fRHU_p+tLDyaoin=0evKw@mail.gmail.com>
References: <CAPA8YjZ-ZiZrRWr812v+xjJF8v8E-fRHU_p+tLDyaoin=0evKw@mail.gmail.com>
Message-ID: <55B25A5E.2060604@gmail.com>

Well, it actually depends on your own scanner. Actually, the Siemens 
scanner in Sherbrooke is using a 12 channel head coils array, but in the 
way is it operated, it is the same as a 4 channel head coils array, 
hence we use N=4.

This is because Siemens reconstruction algorithm (GRAPPA) yields a 
noncentral chi distribution of the noise due to the algorithm working in 
fourier space, as opposed to Philips and GE which are using a 
reconstruction in the image space (SENSE), which yields Rician 
distributed noise (and hence N=1 in this case).

The parameter N is really related to the algorithm used by the 
reconstruction (and it depends on the number of coils of the receptor 
antenna), less than the grappa/sense factor itself. Problems is, you 
kind of need to know your scanner to use it. Some people [1,2] are using 
maximum likelihood estimation form the background to get N, but I have 
not tried it myself. See [3] if you want to know more about the various 
reconstruction algorithm and the noise distribution they yield.

Samuel

-------------------------

[1] Varadarajan, D., Haldar, J., 2015. A Majorize-Minimize Framework for 
Rician and Non-Central Chi MR Images. IEEE Trans. Med. Imaging 0062, 
1?1. doi:10.1109/TMI.2015.2427157

[2] Aja-Fern?ndez, S., Vegas-S?nchez-Ferrero, G., Trist?n-Vega, A., 
2014. Noise estimation in parallel MRI: GRAPPA and SENSE. Magn. Reson. 
Imaging 32, 281?90. doi:10.1016/j.mri.2013.12.001

[3] Dietrich, O., Raya, J.G., Reeder, S.B., Ingrisch, M., Reiser, M.F., 
Schoenberg, S.O., 2008. Influence of multichannel combination, parallel 
imaging and other reconstruction techniques on MRI noise 
characteristics. Magn. Reson. Imaging 26, 754?62. 
doi:10.1016/j.mri.2008.02.001



Le 2015-07-24 11:18, Arnaud Bor? a ?crit :
> Dear dipy experts,
>
> I try to figure out how to use PIESNO to estimate the noise. In the 
> example 
> http://nipy.org/dipy/examples_built/piesno.html#example-piesno we 
> don't know about the grappa factor. Is it 3 so we have N = 12 (number 
> of coils) / 3 (grappa factor) ?
>
> Last question if we don't use grappa then N = 12 ?
>
> Thank you
>
> -- 
> Arnaud BORE
> Research assistant
> Cellulaire : (001) 514-647-8649
>
>
>
> _______________________________________________
> 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/20150724/5613c9ae/attachment.html>

From satra at mit.edu  Fri Jul 24 22:18:54 2015
From: satra at mit.edu (Satrajit Ghosh)
Date: Fri, 24 Jul 2015 16:18:54 -0400
Subject: [Neuroimaging] [nipy] HistogramRegistration verbosity
Message-ID: <CA+A4wOnmH7AsVR+9TG1y=QpEQb92BT-uMBSuRZaHK_DfR8gm1Q@mail.gmail.com>

hi,

is there a way to control verbosity of HistogramRegistration in nipy?

cheers,

satra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150724/e1a28153/attachment.html>

From alexis.roche at gmail.com  Fri Jul 24 23:37:03 2015
From: alexis.roche at gmail.com (Alexis Roche)
Date: Fri, 24 Jul 2015 23:37:03 +0200
Subject: [Neuroimaging] [nipy] HistogramRegistration verbosity
In-Reply-To: <CA+A4wOnmH7AsVR+9TG1y=QpEQb92BT-uMBSuRZaHK_DfR8gm1Q@mail.gmail.com>
References: <CA+A4wOnmH7AsVR+9TG1y=QpEQb92BT-uMBSuRZaHK_DfR8gm1Q@mail.gmail.com>
Message-ID: <CAD4j9Gt4Q4Yafgw4wopaGgXfK9LJtFRHpZLumvHhfA36twajHg@mail.gmail.com>

Hi Satra,

I think this should do the trick:

nipy.algorithms.registration.histogram_registration.VERBOSE = False

Alexis
Le 24 juil. 2015 22:19, "Satrajit Ghosh" <satra at mit.edu> a ?crit :

> hi,
>
> is there a way to control verbosity of HistogramRegistration in nipy?
>
> cheers,
>
> satra
>
>
> _______________________________________________
> 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/20150724/8eba55d2/attachment.html>

From satra at mit.edu  Fri Jul 24 23:49:55 2015
From: satra at mit.edu (Satrajit Ghosh)
Date: Fri, 24 Jul 2015 17:49:55 -0400
Subject: [Neuroimaging] [nipy] HistogramRegistration verbosity
In-Reply-To: <CAD4j9Gt4Q4Yafgw4wopaGgXfK9LJtFRHpZLumvHhfA36twajHg@mail.gmail.com>
References: <CA+A4wOnmH7AsVR+9TG1y=QpEQb92BT-uMBSuRZaHK_DfR8gm1Q@mail.gmail.com>
 <CAD4j9Gt4Q4Yafgw4wopaGgXfK9LJtFRHpZLumvHhfA36twajHg@mail.gmail.com>
Message-ID: <CA+A4wOmhuDjPyzW5R7pXUwk_styeAxSLRG6cBTXRopDWCzoaiw@mail.gmail.com>

thanks alexis.

that indeed worked for the histogram registration.

is there a similar trick for the optimizer?

Optimization terminated successfully.
         Current function value: -0.506414
         Iterations: 3
         Function evaluations: 106


i tried this: nipy.algorithms.registration.optimizer.VERBOSE = False

but that didn't work.

these are the two relevant lines:

    R = HistogramRegistration(source, target, similarity=similarity,
interp=interp,
                              renormalize=renormalize)
    T = R.optimize('rigid', optimizer=optimizer)


cheers,

satra

On Fri, Jul 24, 2015 at 5:37 PM, Alexis Roche <alexis.roche at gmail.com>
wrote:

> Hi Satra,
>
> I think this should do the trick:
>
> nipy.algorithms.registration.histogram_registration.VERBOSE = False
>
> Alexis
> Le 24 juil. 2015 22:19, "Satrajit Ghosh" <satra at mit.edu> a ?crit :
>
>> hi,
>>
>> is there a way to control verbosity of HistogramRegistration in nipy?
>>
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150724/2ac285f1/attachment.html>

From lists at onerussian.com  Fri Jul 24 22:50:06 2015
From: lists at onerussian.com (Yaroslav Halchenko)
Date: Fri, 24 Jul 2015 16:50:06 -0400
Subject: [Neuroimaging] What is current nipy logo?
Message-ID: <20150724205006.GG28964@onerussian.com>

Since the redesigned website doesn't carry it and original brain snake
is probably rightfully better get associated with Arno's own
http://www.mindboggle.info/ ...

-- 
Yaroslav O. Halchenko, Ph.D.
http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
Research Scientist,            Psychological and Brain Sciences Dept.
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 alexis.roche at gmail.com  Sat Jul 25 00:19:51 2015
From: alexis.roche at gmail.com (Alexis Roche)
Date: Sat, 25 Jul 2015 00:19:51 +0200
Subject: [Neuroimaging] [nipy] HistogramRegistration verbosity
In-Reply-To: <CA+A4wOmhuDjPyzW5R7pXUwk_styeAxSLRG6cBTXRopDWCzoaiw@mail.gmail.com>
References: <CA+A4wOnmH7AsVR+9TG1y=QpEQb92BT-uMBSuRZaHK_DfR8gm1Q@mail.gmail.com>
 <CAD4j9Gt4Q4Yafgw4wopaGgXfK9LJtFRHpZLumvHhfA36twajHg@mail.gmail.com>
 <CA+A4wOmhuDjPyzW5R7pXUwk_styeAxSLRG6cBTXRopDWCzoaiw@mail.gmail.com>
Message-ID: <CAD4j9Gu-LbP96rwT0aARBrv14SO4bE0Jd_M0QYSY1Rc77BNCRQ@mail.gmail.com>

This message is printed by scipy.optimize, don't know if there is a similar
way to disable it.
Le 24 juil. 2015 23:50, "Satrajit Ghosh" <satra at mit.edu> a ?crit :

> thanks alexis.
>
> that indeed worked for the histogram registration.
>
> is there a similar trick for the optimizer?
>
> Optimization terminated successfully.
>          Current function value: -0.506414
>          Iterations: 3
>          Function evaluations: 106
>
>
> i tried this: nipy.algorithms.registration.optimizer.VERBOSE = False
>
> but that didn't work.
>
> these are the two relevant lines:
>
>     R = HistogramRegistration(source, target, similarity=similarity,
> interp=interp,
>                               renormalize=renormalize)
>     T = R.optimize('rigid', optimizer=optimizer)
>
>
> cheers,
>
> satra
>
> On Fri, Jul 24, 2015 at 5:37 PM, Alexis Roche <alexis.roche at gmail.com>
> wrote:
>
>> Hi Satra,
>>
>> I think this should do the trick:
>>
>> nipy.algorithms.registration.histogram_registration.VERBOSE = False
>>
>> Alexis
>> Le 24 juil. 2015 22:19, "Satrajit Ghosh" <satra at mit.edu> a ?crit :
>>
>>> hi,
>>>
>>> is there a way to control verbosity of HistogramRegistration in nipy?
>>>
>>> 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
>>
>>
>
> _______________________________________________
> 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/20150725/c01383cd/attachment.html>

From arokem at gmail.com  Sat Jul 25 00:40:36 2015
From: arokem at gmail.com (Ariel Rokem)
Date: Fri, 24 Jul 2015 15:40:36 -0700
Subject: [Neuroimaging] What is current nipy logo?
In-Reply-To: <20150724205006.GG28964@onerussian.com>
References: <20150724205006.GG28964@onerussian.com>
Message-ID: <CA+X4w0yS-tJ+7=j_OrBK-+1=89Xfz3_qawMX7K6aMLdWULocew@mail.gmail.com>

I still love the brain snake, and I would love to keep using it as a logo,
assuming Arno doesn't object.

An alternative I have sometimes used is our mascot, Reggie. He's on this
page:

http://nipy.org/articles/new-site/

Another version of Reggie is also on this slide (and in the respective
github repo):

http://arokem.github.io/2015-scipy-dipy/#/13



On Fri, Jul 24, 2015 at 1:50 PM, Yaroslav Halchenko <lists at onerussian.com>
wrote:

> Since the redesigned website doesn't carry it and original brain snake
> is probably rightfully better get associated with Arno's own
> http://www.mindboggle.info/ ...
>
> --
> Yaroslav O. Halchenko, Ph.D.
> http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
> Research Scientist,            Psychological and Brain Sciences Dept.
> 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
> _______________________________________________
> 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/20150724/5c856b84/attachment.html>

From mwaskom at stanford.edu  Sat Jul 25 02:25:06 2015
From: mwaskom at stanford.edu (Michael Waskom)
Date: Fri, 24 Jul 2015 17:25:06 -0700
Subject: [Neuroimaging] [nipy] HistogramRegistration verbosity
In-Reply-To: <CAD4j9Gu-LbP96rwT0aARBrv14SO4bE0Jd_M0QYSY1Rc77BNCRQ@mail.gmail.com>
References: <CA+A4wOnmH7AsVR+9TG1y=QpEQb92BT-uMBSuRZaHK_DfR8gm1Q@mail.gmail.com>
 <CAD4j9Gt4Q4Yafgw4wopaGgXfK9LJtFRHpZLumvHhfA36twajHg@mail.gmail.com>
 <CA+A4wOmhuDjPyzW5R7pXUwk_styeAxSLRG6cBTXRopDWCzoaiw@mail.gmail.com>
 <CAD4j9Gu-LbP96rwT0aARBrv14SO4bE0Jd_M0QYSY1Rc77BNCRQ@mail.gmail.com>
Message-ID: <CAKZ-Uq3qoBFAPEmv_keAYk9PapyG85t5ML-Hz2rb3KnQNrh71A@mail.gmail.com>

Here's my approach:
https://github.com/cni/rtfmri/blob/master/rtfmri/analyzers.py#L215

On Fri, Jul 24, 2015 at 3:19 PM, Alexis Roche <alexis.roche at gmail.com>
wrote:

> This message is printed by scipy.optimize, don't know if there is a
> similar way to disable it.
> Le 24 juil. 2015 23:50, "Satrajit Ghosh" <satra at mit.edu> a ?crit :
>
>> thanks alexis.
>>
>> that indeed worked for the histogram registration.
>>
>> is there a similar trick for the optimizer?
>>
>> Optimization terminated successfully.
>>          Current function value: -0.506414
>>          Iterations: 3
>>          Function evaluations: 106
>>
>>
>> i tried this: nipy.algorithms.registration.optimizer.VERBOSE = False
>>
>> but that didn't work.
>>
>> these are the two relevant lines:
>>
>>     R = HistogramRegistration(source, target, similarity=similarity,
>> interp=interp,
>>                               renormalize=renormalize)
>>     T = R.optimize('rigid', optimizer=optimizer)
>>
>>
>> cheers,
>>
>> satra
>>
>> On Fri, Jul 24, 2015 at 5:37 PM, Alexis Roche <alexis.roche at gmail.com>
>> wrote:
>>
>>> Hi Satra,
>>>
>>> I think this should do the trick:
>>>
>>> nipy.algorithms.registration.histogram_registration.VERBOSE = False
>>>
>>> Alexis
>>> Le 24 juil. 2015 22:19, "Satrajit Ghosh" <satra at mit.edu> a ?crit :
>>>
>>>> hi,
>>>>
>>>> is there a way to control verbosity of HistogramRegistration in nipy?
>>>>
>>>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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/20150724/c658fe7d/attachment.html>

From garyfallidis at gmail.com  Sat Jul 25 02:57:48 2015
From: garyfallidis at gmail.com (Eleftherios Garyfallidis)
Date: Fri, 24 Jul 2015 20:57:48 -0400
Subject: [Neuroimaging]  Nipy.org new website needs a complete remake
Message-ID: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>

Hi guys,

It seems that nipy.org has recently changed. The previous page was much
better from what we have now. Is this hopefully under development and it
accidentally replaced the initial website? It definitely doesn't look
ready. Please update with the old website until this is ready.

Can I ask also that when we make such decisions that affect many projects
to get an e-mail to this list first? And we should also discuss about the
technology that the website should use so that we can use similar ideas in
the different projects? For example sphinx with bootstrap seems like a nice
direction to go as we will have more responsive websites and still have the
automatic documentation generated by sphinx etc. That could be used in all
projects and the nipy.org website. What are the main tools used now for
this "new" website?

Cheers,
Eleftherios
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150724/6f8e71f3/attachment.html>

From jbpoline at gmail.com  Sat Jul 25 03:07:48 2015
From: jbpoline at gmail.com (JB Poline)
Date: Fri, 24 Jul 2015 18:07:48 -0700
Subject: [Neuroimaging] [nipy] HistogramRegistration verbosity
In-Reply-To: <CAKZ-Uq3qoBFAPEmv_keAYk9PapyG85t5ML-Hz2rb3KnQNrh71A@mail.gmail.com>
References: <CA+A4wOnmH7AsVR+9TG1y=QpEQb92BT-uMBSuRZaHK_DfR8gm1Q@mail.gmail.com>
 <CAD4j9Gt4Q4Yafgw4wopaGgXfK9LJtFRHpZLumvHhfA36twajHg@mail.gmail.com>
 <CA+A4wOmhuDjPyzW5R7pXUwk_styeAxSLRG6cBTXRopDWCzoaiw@mail.gmail.com>
 <CAD4j9Gu-LbP96rwT0aARBrv14SO4bE0Jd_M0QYSY1Rc77BNCRQ@mail.gmail.com>
 <CAKZ-Uq3qoBFAPEmv_keAYk9PapyG85t5ML-Hz2rb3KnQNrh71A@mail.gmail.com>
Message-ID: <CALMaa81yDPjyYdr7nhAmSo=S2w9-3U+ieadvYuypQAy90Y+Phg@mail.gmail.com>

nice !
JB

On Fri, Jul 24, 2015 at 5:25 PM, Michael Waskom <mwaskom at stanford.edu>
wrote:

> Here's my approach:
> https://github.com/cni/rtfmri/blob/master/rtfmri/analyzers.py#L215
>
> On Fri, Jul 24, 2015 at 3:19 PM, Alexis Roche <alexis.roche at gmail.com>
> wrote:
>
>> This message is printed by scipy.optimize, don't know if there is a
>> similar way to disable it.
>> Le 24 juil. 2015 23:50, "Satrajit Ghosh" <satra at mit.edu> a ?crit :
>>
>>> thanks alexis.
>>>
>>> that indeed worked for the histogram registration.
>>>
>>> is there a similar trick for the optimizer?
>>>
>>> Optimization terminated successfully.
>>>          Current function value: -0.506414
>>>          Iterations: 3
>>>          Function evaluations: 106
>>>
>>>
>>> i tried this: nipy.algorithms.registration.optimizer.VERBOSE = False
>>>
>>> but that didn't work.
>>>
>>> these are the two relevant lines:
>>>
>>>     R = HistogramRegistration(source, target, similarity=similarity,
>>> interp=interp,
>>>                               renormalize=renormalize)
>>>     T = R.optimize('rigid', optimizer=optimizer)
>>>
>>>
>>> cheers,
>>>
>>> satra
>>>
>>> On Fri, Jul 24, 2015 at 5:37 PM, Alexis Roche <alexis.roche at gmail.com>
>>> wrote:
>>>
>>>> Hi Satra,
>>>>
>>>> I think this should do the trick:
>>>>
>>>> nipy.algorithms.registration.histogram_registration.VERBOSE = False
>>>>
>>>> Alexis
>>>> Le 24 juil. 2015 22:19, "Satrajit Ghosh" <satra at mit.edu> a ?crit :
>>>>
>>>>> hi,
>>>>>
>>>>> is there a way to control verbosity of HistogramRegistration in nipy?
>>>>>
>>>>> 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
>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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: <http://mail.python.org/pipermail/neuroimaging/attachments/20150724/7c86bbcb/attachment.html>

From satra at mit.edu  Sat Jul 25 04:15:28 2015
From: satra at mit.edu (Satrajit Ghosh)
Date: Fri, 24 Jul 2015 22:15:28 -0400
Subject: [Neuroimaging] [nipy] HistogramRegistration verbosity
In-Reply-To: <CAKZ-Uq3qoBFAPEmv_keAYk9PapyG85t5ML-Hz2rb3KnQNrh71A@mail.gmail.com>
References: <CA+A4wOnmH7AsVR+9TG1y=QpEQb92BT-uMBSuRZaHK_DfR8gm1Q@mail.gmail.com>
 <CAD4j9Gt4Q4Yafgw4wopaGgXfK9LJtFRHpZLumvHhfA36twajHg@mail.gmail.com>
 <CA+A4wOmhuDjPyzW5R7pXUwk_styeAxSLRG6cBTXRopDWCzoaiw@mail.gmail.com>
 <CAD4j9Gu-LbP96rwT0aARBrv14SO4bE0Jd_M0QYSY1Rc77BNCRQ@mail.gmail.com>
 <CAKZ-Uq3qoBFAPEmv_keAYk9PapyG85t5ML-Hz2rb3KnQNrh71A@mail.gmail.com>
Message-ID: <CA+A4wOmZLguVbQrv0XHH=3f9zT1k0EK2FtR=cooazptcSg157A@mail.gmail.com>

hi mike,

Here's my approach:
> https://github.com/cni/rtfmri/blob/master/rtfmri/analyzers.py#L215
>

i'm using this in the notebook interactively. is there a way to do this for
one cell and not others?

cheers,

satra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150724/5ce9ff6e/attachment.html>

From mwaskom at stanford.edu  Sat Jul 25 04:22:58 2015
From: mwaskom at stanford.edu (Michael Waskom)
Date: Fri, 24 Jul 2015 19:22:58 -0700
Subject: [Neuroimaging] [nipy] HistogramRegistration verbosity
In-Reply-To: <CA+A4wOmZLguVbQrv0XHH=3f9zT1k0EK2FtR=cooazptcSg157A@mail.gmail.com>
References: <CA+A4wOnmH7AsVR+9TG1y=QpEQb92BT-uMBSuRZaHK_DfR8gm1Q@mail.gmail.com>
 <CAD4j9Gt4Q4Yafgw4wopaGgXfK9LJtFRHpZLumvHhfA36twajHg@mail.gmail.com>
 <CA+A4wOmhuDjPyzW5R7pXUwk_styeAxSLRG6cBTXRopDWCzoaiw@mail.gmail.com>
 <CAD4j9Gu-LbP96rwT0aARBrv14SO4bE0Jd_M0QYSY1Rc77BNCRQ@mail.gmail.com>
 <CAKZ-Uq3qoBFAPEmv_keAYk9PapyG85t5ML-Hz2rb3KnQNrh71A@mail.gmail.com>
 <CA+A4wOmZLguVbQrv0XHH=3f9zT1k0EK2FtR=cooazptcSg157A@mail.gmail.com>
Message-ID: <CAKZ-Uq1p8YtcwTfcakza3vhLNt6rDsWRZEADZtTwfyyMDMP2-A@mail.gmail.com>

sorry if i wasn't clear, this lets you do

        reg = HistogramRegistration(moving, fixed, interp=interp)
        with silent():  # Mute stdout due to verbose optimization info
            T = reg.optimize(init)

so you can control what gets silenced pretty closely

On Fri, Jul 24, 2015 at 7:15 PM, Satrajit Ghosh <satra at mit.edu> wrote:

> hi mike,
>
> Here's my approach:
>> https://github.com/cni/rtfmri/blob/master/rtfmri/analyzers.py#L215
>>
>
> i'm using this in the notebook interactively. is there a way to do this
> for one cell and not others?
>
> cheers,
>
> satra
>
>
>
> _______________________________________________
> 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/20150724/d1498a67/attachment.html>

From satra at mit.edu  Sat Jul 25 04:36:34 2015
From: satra at mit.edu (Satrajit Ghosh)
Date: Fri, 24 Jul 2015 22:36:34 -0400
Subject: [Neuroimaging] [nipy] HistogramRegistration verbosity
In-Reply-To: <CAKZ-Uq1p8YtcwTfcakza3vhLNt6rDsWRZEADZtTwfyyMDMP2-A@mail.gmail.com>
References: <CA+A4wOnmH7AsVR+9TG1y=QpEQb92BT-uMBSuRZaHK_DfR8gm1Q@mail.gmail.com>
 <CAD4j9Gt4Q4Yafgw4wopaGgXfK9LJtFRHpZLumvHhfA36twajHg@mail.gmail.com>
 <CA+A4wOmhuDjPyzW5R7pXUwk_styeAxSLRG6cBTXRopDWCzoaiw@mail.gmail.com>
 <CAD4j9Gu-LbP96rwT0aARBrv14SO4bE0Jd_M0QYSY1Rc77BNCRQ@mail.gmail.com>
 <CAKZ-Uq3qoBFAPEmv_keAYk9PapyG85t5ML-Hz2rb3KnQNrh71A@mail.gmail.com>
 <CA+A4wOmZLguVbQrv0XHH=3f9zT1k0EK2FtR=cooazptcSg157A@mail.gmail.com>
 <CAKZ-Uq1p8YtcwTfcakza3vhLNt6rDsWRZEADZtTwfyyMDMP2-A@mail.gmail.com>
Message-ID: <CA+A4wOn9HxmVCOr6BdWujM4vYU3bJt9frCdwC07YR_yo6wcrzQ@mail.gmail.com>

ah thanks!

cheers,

satra

On Fri, Jul 24, 2015 at 10:22 PM, Michael Waskom <mwaskom at stanford.edu>
wrote:

> sorry if i wasn't clear, this lets you do
>
>         reg = HistogramRegistration(moving, fixed, interp=interp)
>         with silent():  # Mute stdout due to verbose optimization info
>             T = reg.optimize(init)
>
> so you can control what gets silenced pretty closely
>
> On Fri, Jul 24, 2015 at 7:15 PM, Satrajit Ghosh <satra at mit.edu> wrote:
>
>> hi mike,
>>
>> Here's my approach:
>>> https://github.com/cni/rtfmri/blob/master/rtfmri/analyzers.py#L215
>>>
>>
>> i'm using this in the notebook interactively. is there a way to do this
>> for one cell and not others?
>>
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150724/a33c0ff6/attachment-0001.html>

From vsochat at stanford.edu  Sat Jul 25 04:41:19 2015
From: vsochat at stanford.edu (vanessa sochat)
Date: Fri, 24 Jul 2015 19:41:19 -0700
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
Message-ID: <CAM=pu+Jf4m+yDjLs1pBZFGDgka3NmGzs5P7PMdhbKhE6Q6CCzA@mail.gmail.com>

I do think that there was some discussion, and there of course could
be further discussion if needed.  The concern was not having a
consolidated portal for all the tools out there, and Ariel worked
pretty hard to put this content together (and this should not be
lost!). It's a Jekyll site so that it can be hosted by github:

https://github.com/nipy/nipy.github.com

I'd be happy to help in some way, if we want to talk about what would
be best for the site.

On Fri, Jul 24, 2015 at 5:57 PM, Eleftherios Garyfallidis
<garyfallidis at gmail.com> wrote:
> Hi guys,
>
> It seems that nipy.org has recently changed. The previous page was much
> better from what we have now. Is this hopefully under development and it
> accidentally replaced the initial website? It definitely doesn't look ready.
> Please update with the old website until this is ready.
>
> Can I ask also that when we make such decisions that affect many projects to
> get an e-mail to this list first? And we should also discuss about the
> technology that the website should use so that we can use similar ideas in
> the different projects? For example sphinx with bootstrap seems like a nice
> direction to go as we will have more responsive websites and still have the
> automatic documentation generated by sphinx etc. That could be used in all
> projects and the nipy.org website. What are the main tools used now for this
> "new" website?
>
> Cheers,
> Eleftherios
>
>
>
>
>
>
> _______________________________________________
> Neuroimaging mailing list
> Neuroimaging at python.org
> https://mail.python.org/mailman/listinfo/neuroimaging
>



-- 
Vanessa Villamia Sochat
Stanford University
(603) 321-0676


From lists at onerussian.com  Sat Jul 25 06:26:07 2015
From: lists at onerussian.com (Yaroslav Halchenko)
Date: Sat, 25 Jul 2015 00:26:07 -0400
Subject: [Neuroimaging] What is current nipy logo?
In-Reply-To: <CA+X4w0yS-tJ+7=j_OrBK-+1=89Xfz3_qawMX7K6aMLdWULocew@mail.gmail.com>
References: <20150724205006.GG28964@onerussian.com>
 <CA+X4w0yS-tJ+7=j_OrBK-+1=89Xfz3_qawMX7K6aMLdWULocew@mail.gmail.com>
Message-ID: <20150725042607.GN28964@onerussian.com>


On Fri, 24 Jul 2015, Ariel Rokem wrote:

>    I still love the brain snake, and I would love to keep using it as a logo,
>    assuming Arno doesn't object.A 
>    An alternative I have sometimes used is our mascot, Reggie. He's on this
>    page:A 
>    http://nipy.org/articles/new-site/
>    Another version of Reggie is also on this slide (and in the respective
>    github repo):A 
>    http://arokem.github.io/2015-scipy-dipy/#/13

Why did I think that reggie is for nibabel??? hm...

-- 
Yaroslav O. Halchenko, Ph.D.
http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
Research Scientist,            Psychological and Brain Sciences Dept.
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 gael.varoquaux at normalesup.org  Sat Jul 25 10:41:55 2015
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Sat, 25 Jul 2015 10:41:55 +0200
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
Message-ID: <20150725084155.GB87662@phare.normalesup.org>

On Fri, Jul 24, 2015 at 08:57:48PM -0400, Eleftherios Garyfallidis wrote:
> It seems that nipy.org has recently changed. The previous page was much
> better from what we have now.

I agree with you that the previous page was much better in term of design
(more colors, a more structured layout, and an image that looked like a
brain clearly visible) and of content (clear list of main projects and
subprojects).

However, the change was advertised. I understand that you missed it: we
all have too much mails and too many things to do.

I think that you could make proposals and maybe pull requests to shape
the website toward something that you like better. It would be great.

Ga?l

From garyfallidis at gmail.com  Sat Jul 25 15:46:50 2015
From: garyfallidis at gmail.com (Eleftherios Garyfallidis)
Date: Sat, 25 Jul 2015 09:46:50 -0400
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <20150725084155.GB87662@phare.normalesup.org>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
Message-ID: <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>

Hi Gael, Vanessa and Ariel,

Gael I think the previous e-mail thread was about moving the pages into
github.io and not about the design, the technology or the content of
nipy.org. This being the portal of all projects needs to communicate the
ideas better and use libraries that can be used in other projects too.
Hopefully also be as Pythonic as possible and as useful and attractive as
possible.

So, my point is that the new portal, although it has some nice ideas, for
examle it is using bootstrap which allows for better and more responsive
viewing
from different devices, it is not ready for prime time. And it shouldn't be
online with the form that is now. So, I would recommend to use the previous
website with updated links to the new github pages until this one is in a
better form.

Now about the technology used for creating the website. From my
understanding Ariel is using the default engine promoted by github which is
jekyll which at the end is using bootstrap. But bootstrap can be used with
sphinx and with pelican too which are both Python projects.

So we could actually have two better options. For the portal we can use:

a) Pelican which is an alternative of Octpress/Jekyll in Python. I used it
to make my  own website and it is easy to use for creating static websites
(like the portal). Link here http://garyfallidis.github.io and here
https://github.com/Garyfallidis/website-dev . Pelican supports both
markdown and restructuredtext.

b) It is now possible to use Sphinx with bootstrap directly. See here
https://readthedocs.org/projects/sphinx-bootstrap-theme/ and here
https://pypi.python.org/pypi/sphinx-bootstrap-theme/
The option is possibly the best solution as we could just update our
template engine (to use bootstrap) and continue using sphinx as before. But
now we can use any template we want and have a much more responsive website.

Ideally the portal should have a main theme and then the different projects
would make some alterations to this theme to create their individual image.
For example in Dipy our main colors are black and orange so we will
alternate the theme so we can use mainly those colors is our website.

Vanessa of course I am writing this e-mail because I am willing up to my
capacity to help Ariel or anyone else who wants to improve the look and
feel of the organization.

Ariel in summary, I think the portal is not well designed right now and the
content needs some more work before it is presented. I am happy to help and
I think you will find it useful to have a look in the links that I have in
this e-mail before we meet. In the meantime, I would strongly suggest to
upload the old portal until we have something more solid. I hope this is
okay.

Cheers,
Eleftherios



On Sat, Jul 25, 2015 at 4:41 AM, Gael Varoquaux <
gael.varoquaux at normalesup.org> wrote:

> On Fri, Jul 24, 2015 at 08:57:48PM -0400, Eleftherios Garyfallidis wrote:
> > It seems that nipy.org has recently changed. The previous page was much
> > better from what we have now.
>
> I agree with you that the previous page was much better in term of design
> (more colors, a more structured layout, and an image that looked like a
> brain clearly visible) and of content (clear list of main projects and
> subprojects).
>
> However, the change was advertised. I understand that you missed it: we
> all have too much mails and too many things to do.
>
> I think that you could make proposals and maybe pull requests to shape
> the website toward something that you like better. It would be great.
>
> Ga?l
> _______________________________________________
> 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/20150725/eee7471f/attachment.html>

From arokem at gmail.com  Sun Jul 26 04:58:14 2015
From: arokem at gmail.com (Ariel Rokem)
Date: Sat, 25 Jul 2015 19:58:14 -0700
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
Message-ID: <CA+X4w0wWtzdCA_6cgRH91tZMWj-yw84tWUUt_6KPWChPzDO9wQ@mail.gmail.com>

Hi Eleftherios,

I am happy to have you finally chime in on the discussion surrounding the
webpage. The previous email thread was indeed supposed to spur this
discussion, but it did fairly quickly turn into a discussion of github
workflow and technical issues surrounding redirection instead. So - better
late than never!

As I mentioned in my first email in that previous thread (can't link to it,
because the archives on mail.scipy.org are down...), this redesign was the
result of conversations at the Berkeley coding sprint back in May. While
talking to some relative newcomers, we noticed that the content in the old
webpage was really confusing, and gave a somewhat misleading picture of the
current state of affairs in the nipy community. For example, I don't think
that anyone here really thinks that neuroimaging in Python is only 6
projects, or that one of the first projects people should try out is pbrain
(which was one of the six previously mentioned on the front page). So, I
don't think that going to the old version of the page is a good solution.

Like almost everything else around here, the webpage is of course work in
progress. For example, I can relate to the objections regarding the
background image on the front page. I had full intention of replacing the
background image with something (possibly several things rotating?) more
indicative of the subject matter. I just haven't had the time to do that
yet. If someone else wants to jump in and do that, this is the file that
would need to be replaced:

https://github.com/nipy/nipy.github.com/blob/master/images/rect1600x800.png

I am sure that a bit of logic could be used to put in several different
attractive images of brain data from which one would be chosen randomly
every time you land on the page.

Concerning choice of design/technology: as Vanessa pointed out, the
technology used for these pages is Jekyll <http://jekyllrb.com/>. It has
the following advantages:

1. It is the 'native' technology on Github's platform. That means that we
can version control on the markdown from which the site gets generated, and
the site itself gets built on Github, rather than needing to be built on
anyone's machine every time changes are made. This makes it relatively easy
to extend the website, work on it collaboratively using the standard github
workflow, and to add additional content. I've even put some instructions in
http://nipy.org/contribute/ on how to add such content, especially
articles/blog posts. Happy to have people write little articles in that
vein, and make things a little bit more lively. It really doesn't have to
be a dissertation - writing down a few lines reporting on some new cool
project you've seen, or reporting from a conference you've attended from
the nipy point of view would be wonderful.

2. Reasonably good-looking, with plenty of customization possible. This is,
of course, a matter of taste, so I don't expect anyone to agree with me.
Whether having more colors on a page or not is better is really not
something I expect anyone to agree with me on. I certainly would not object
to changes to the current design that wouldn't be too gaudy. Concerning a
comment Gael made: what does a "structured" layout mean? Is that a
web-design term? I am (surprise!) not a web designer ;-)

The only disadvantage of Jekyll I can see is that it is Ruby-based. I think
that point 1 above outweighs that disadvantage. Point 2 is really a matter
for some discussion, and additional work. By the way, whether to use Jekyll
is also a discussion that has come up in the context of Software Carpentry.
I think that no one in that community regrets choosing jekyll to manage a
much more complicated network of web sites, but we can ask them for more
advice, if someone thinks that would be useful.

Cheers,

Ariel


On Sat, Jul 25, 2015 at 6:46 AM, Eleftherios Garyfallidis <
garyfallidis at gmail.com> wrote:

> Hi Gael, Vanessa and Ariel,
>
> Gael I think the previous e-mail thread was about moving the pages into
> github.io and not about the design, the technology or the content of
> nipy.org. This being the portal of all projects needs to communicate the
> ideas better and use libraries that can be used in other projects too.
> Hopefully also be as Pythonic as possible and as useful and attractive as
> possible.
>
> So, my point is that the new portal, although it has some nice ideas, for
> examle it is using bootstrap which allows for better and more responsive
> viewing
> from different devices, it is not ready for prime time. And it shouldn't
> be online with the form that is now. So, I would recommend to use the
> previous website with updated links to the new github pages until this one
> is in a better form.
>
> Now about the technology used for creating the website. From my
> understanding Ariel is using the default engine promoted by github which is
> jekyll which at the end is using bootstrap. But bootstrap can be used with
> sphinx and with pelican too which are both Python projects.
>
> So we could actually have two better options. For the portal we can use:
>
> a) Pelican which is an alternative of Octpress/Jekyll in Python. I used it
> to make my  own website and it is easy to use for creating static websites
> (like the portal). Link here http://garyfallidis.github.io and here
> https://github.com/Garyfallidis/website-dev . Pelican supports both
> markdown and restructuredtext.
>
> b) It is now possible to use Sphinx with bootstrap directly. See here
> https://readthedocs.org/projects/sphinx-bootstrap-theme/ and here
> https://pypi.python.org/pypi/sphinx-bootstrap-theme/
> The option is possibly the best solution as we could just update our
> template engine (to use bootstrap) and continue using sphinx as before. But
> now we can use any template we want and have a much more responsive website.
>
> Ideally the portal should have a main theme and then the different
> projects would make some alterations to this theme to create their
> individual image. For example in Dipy our main colors are black and orange
> so we will alternate the theme so we can use mainly those colors is our
> website.
>
> Vanessa of course I am writing this e-mail because I am willing up to my
> capacity to help Ariel or anyone else who wants to improve the look and
> feel of the organization.
>
> Ariel in summary, I think the portal is not well designed right now and
> the content needs some more work before it is presented. I am happy to help
> and I think you will find it useful to have a look in the links that I have
> in this e-mail before we meet. In the meantime, I would strongly suggest to
> upload the old portal until we have something more solid. I hope this is
> okay.
>
> Cheers,
> Eleftherios
>
>
>
> On Sat, Jul 25, 2015 at 4:41 AM, Gael Varoquaux <
> gael.varoquaux at normalesup.org> wrote:
>
>> On Fri, Jul 24, 2015 at 08:57:48PM -0400, Eleftherios Garyfallidis wrote:
>> > It seems that nipy.org has recently changed. The previous page was much
>> > better from what we have now.
>>
>> I agree with you that the previous page was much better in term of design
>> (more colors, a more structured layout, and an image that looked like a
>> brain clearly visible) and of content (clear list of main projects and
>> subprojects).
>>
>> However, the change was advertised. I understand that you missed it: we
>> all have too much mails and too many things to do.
>>
>> I think that you could make proposals and maybe pull requests to shape
>> the website toward something that you like better. It would be great.
>>
>> Ga?l
>> _______________________________________________
>> 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/20150725/296e8389/attachment.html>

From arokem at gmail.com  Sun Jul 26 05:12:54 2015
From: arokem at gmail.com (Ariel Rokem)
Date: Sat, 25 Jul 2015 20:12:54 -0700
Subject: [Neuroimaging] What is current nipy logo?
In-Reply-To: <20150725042607.GN28964@onerussian.com>
References: <20150724205006.GG28964@onerussian.com>
 <CA+X4w0yS-tJ+7=j_OrBK-+1=89Xfz3_qawMX7K6aMLdWULocew@mail.gmail.com>
 <20150725042607.GN28964@onerussian.com>
Message-ID: <CA+X4w0wbFEgboAJoLBcPu5udTdLOR70E7EcAqwZeFwpZmfYh8Q@mail.gmail.com>

On Fri, Jul 24, 2015 at 9:26 PM, Yaroslav Halchenko <lists at onerussian.com>
wrote:

>
> On Fri, 24 Jul 2015, Ariel Rokem wrote:
>
> >    I still love the brain snake, and I would love to keep using it as a
> logo,
> >    assuming Arno doesn't object.A
> >    An alternative I have sometimes used is our mascot, Reggie. He's on
> this
> >    page:A
> >    http://nipy.org/articles/new-site/
> >    Another version of Reggie is also on this slide (and in the respective
> >    github repo):A
> >    http://arokem.github.io/2015-scipy-dipy/#/13
>
> Why did I think that reggie is for nibabel??? hm...


Hmm indeed - I have no idea. Since mail.scipy.org seems to have died, I
can't even trawl the archives for conversations about that (google's index
suggests there was a conversation about this in December 2009, but even the
way-back machine doesn't have the full record...)

At the very least the version I used in that scipy presentation definitely
has the letters "NIPY" on it, so maybe it has a similar status to the
snake-brain, where each project used a variation on the same theme?


> --
> Yaroslav O. Halchenko, Ph.D.
> http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
> Research Scientist,            Psychological and Brain Sciences Dept.
> 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
> _______________________________________________
> 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/20150725/27b152ed/attachment.html>

From garyfallidis at gmail.com  Sun Jul 26 18:53:50 2015
From: garyfallidis at gmail.com (Eleftherios Garyfallidis)
Date: Sun, 26 Jul 2015 12:53:50 -0400
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <CA+X4w0wWtzdCA_6cgRH91tZMWj-yw84tWUUt_6KPWChPzDO9wQ@mail.gmail.com>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CA+X4w0wWtzdCA_6cgRH91tZMWj-yw84tWUUt_6KPWChPzDO9wQ@mail.gmail.com>
Message-ID: <CAN6JmWMprY6WGxrWdk7VUyoMoMwtLpWo2PKVv70yFOVYdqb-6w@mail.gmail.com>

Hi Ariel,

On Sat, Jul 25, 2015 at 10:58 PM, Ariel Rokem <arokem at gmail.com> wrote:

> Hi Eleftherios,
>
> I am happy to have you finally chime in on the discussion surrounding the
> webpage. The previous email thread was indeed supposed to spur this
> discussion, but it did fairly quickly turn into a discussion of github
> workflow and technical issues surrounding redirection instead. So - better
> late than never!
>
>
Okay.


> As I mentioned in my first email in that previous thread (can't link to
> it, because the archives on mail.scipy.org are down...), this redesign
> was the result of conversations at the Berkeley coding sprint back in May.
> While talking to some relative newcomers, we noticed that the content in
> the old webpage was really confusing, and gave a somewhat misleading
> picture of the current state of affairs in the nipy community. For example,
> I don't think that anyone here really thinks that neuroimaging in Python is
> only 6 projects, or that one of the first projects people should try out is
> pbrain (which was one of the six previously mentioned on the front page).
> So, I don't think that going to the old version of the page is a good
> solution.
>

Okay but this new website as it is now is not ready to be online too. It is
still misleading and I find it difficult to understand what the portal is
about. It needs much more work to be useful.

>
> Like almost everything else around here, the webpage is of course work in
> progress. For example, I can relate to the objections regarding the
> background image on the front page. I had full intention of replacing the
> background image with something (possibly several things rotating?) more
> indicative of the subject matter. I just haven't had the time to do that
> yet. If someone else wants to jump in and do that, this is the file that
> would need to be replaced:
>

> https://github.com/nipy/nipy.github.com/blob/master/images/rect1600x800.png
>
> I think from now on when a new website like this is created which affects
other projects it shouldn't replace immediately the existing website but
have a link in the existing website saying that there is a new website
coming. In that way the transition is smoother and it gives you the
developer the time to make the website better and get more feedback.


> I am sure that a bit of logic could be used to put in several different
> attractive images of brain data from which one would be chosen randomly
> every time you land on the page.
>
> Yes, you can put a carousel in the website and remove that background with
many images. You should also remove the mission with the form it is now. It
doesn't communicate.


> Concerning choice of design/technology: as Vanessa pointed out, the
> technology used for these pages is Jekyll <http://jekyllrb.com/>. It has
> the following advantages:
>
> 1. It is the 'native' technology on Github's platform. That means that we
> can version control on the markdown from which the site gets generated, and
> the site itself gets built on Github, rather than needing to be built on
> anyone's machine every time changes are made. This makes it relatively easy
> to extend the website, work on it collaboratively using the standard github
> workflow, and to add additional content. I've even put some instructions in
> http://nipy.org/contribute/ on how to add such content, especially
> articles/blog posts. Happy to have people write little articles in that
> vein, and make things a little bit more lively. It really doesn't have to
> be a dissertation - writing down a few lines reporting on some new cool
> project you've seen, or reporting from a conference you've attended from
> the nipy point of view would be wonderful.
>
> 2. Reasonably good-looking, with plenty of customization possible. This
> is, of course, a matter of taste, so I don't expect anyone to agree with
> me. Whether having more colors on a page or not is better is really not
> something I expect anyone to agree with me on. I certainly would not object
> to changes to the current design that wouldn't be too gaudy. Concerning a
> comment Gael made: what does a "structured" layout mean? Is that a
> web-design term? I am (surprise!) not a web designer ;-)
>


> The only disadvantage of Jekyll I can see is that it is Ruby-based. I
> think that point 1 above outweighs that disadvantage. Point 2 is really a
> matter for some discussion, and additional work. By the way, whether to use
> Jekyll is also a discussion that has come up in the context of Software
> Carpentry. I think that no one in that community regrets choosing jekyll to
> manage a much more complicated network of web sites, but we can ask them
> for more advice, if someone thinks that would be useful.
>
>
As I said in my previous e-mail this website can be created using Pelican
too or with Sphinx and Bootstrap and it will be more pythonic. About option
2. Jetkyll can be good looking because of bootstrap. We have exactly the
same good looks with Sphinx or Pelican. By the way also Pelican supports
both markdown and rst.

What it seems as advantage is 1. but in practice it is not a big advantage
because even if people submit their markdown scripts the website will be
updated only when those are merged and still you will need someone checking
if they render correctly. I prefer if people who submit content check the
final website first in their machine before updating the final website.

We can still use Jekyll only for the portal but the websites of the rest of
the projects will have to use sphinx anyway. So, why bother introducing new
tech.

So, my final suggestion is to use Pelican for the portal which supports
everything that Jekyll supports and works in github fine. And for the other
websites e.g. dipy, nibabel etc. use sphinx with the same or similar theme
used in the portal but with some alternations to create a unique look for
each project.

Some immediate actions:
a) For now I think you should at least add this information
http://nipy.org/project-directory/ to the first page and explain what is
your vision of this portal.
b) Definitely change this background picture maybe add a neuro-related
picture. You don't need to wait for others to do that. You can do that by
yourself too. I am sure you have many cool pictures around.
c) Then let's set a meeting together and with other people who want to help
and I can show you how Pelican/Bootstrap work so you can then see the
benefits by yourself. Don't worry nothing from the content that you added
in nipy.org is going to be lost. All these markdowns can also be used with
Pelican.

I will be available after Wednesday to help you with this.

Cheers,
Eleftherios



> Cheers,
>
> Ariel
>
>
> On Sat, Jul 25, 2015 at 6:46 AM, Eleftherios Garyfallidis <
> garyfallidis at gmail.com> wrote:
>
>> Hi Gael, Vanessa and Ariel,
>>
>> Gael I think the previous e-mail thread was about moving the pages into
>> github.io and not about the design, the technology or the content of
>> nipy.org. This being the portal of all projects needs to communicate the
>> ideas better and use libraries that can be used in other projects too.
>> Hopefully also be as Pythonic as possible and as useful and attractive as
>> possible.
>>
>> So, my point is that the new portal, although it has some nice ideas, for
>> examle it is using bootstrap which allows for better and more responsive
>> viewing
>> from different devices, it is not ready for prime time. And it shouldn't
>> be online with the form that is now. So, I would recommend to use the
>> previous website with updated links to the new github pages until this one
>> is in a better form.
>>
>> Now about the technology used for creating the website. From my
>> understanding Ariel is using the default engine promoted by github which is
>> jekyll which at the end is using bootstrap. But bootstrap can be used with
>> sphinx and with pelican too which are both Python projects.
>>
>> So we could actually have two better options. For the portal we can use:
>>
>> a) Pelican which is an alternative of Octpress/Jekyll in Python. I used
>> it to make my  own website and it is easy to use for creating static
>> websites (like the portal). Link here http://garyfallidis.github.io and
>> here https://github.com/Garyfallidis/website-dev . Pelican supports both
>> markdown and restructuredtext.
>>
>> b) It is now possible to use Sphinx with bootstrap directly. See here
>> https://readthedocs.org/projects/sphinx-bootstrap-theme/ and here
>> https://pypi.python.org/pypi/sphinx-bootstrap-theme/
>> The option is possibly the best solution as we could just update our
>> template engine (to use bootstrap) and continue using sphinx as before. But
>> now we can use any template we want and have a much more responsive website.
>>
>> Ideally the portal should have a main theme and then the different
>> projects would make some alterations to this theme to create their
>> individual image. For example in Dipy our main colors are black and orange
>> so we will alternate the theme so we can use mainly those colors is our
>> website.
>>
>> Vanessa of course I am writing this e-mail because I am willing up to my
>> capacity to help Ariel or anyone else who wants to improve the look and
>> feel of the organization.
>>
>> Ariel in summary, I think the portal is not well designed right now and
>> the content needs some more work before it is presented. I am happy to help
>> and I think you will find it useful to have a look in the links that I have
>> in this e-mail before we meet. In the meantime, I would strongly suggest to
>> upload the old portal until we have something more solid. I hope this is
>> okay.
>>
>> Cheers,
>> Eleftherios
>>
>>
>>
>> On Sat, Jul 25, 2015 at 4:41 AM, Gael Varoquaux <
>> gael.varoquaux at normalesup.org> wrote:
>>
>>> On Fri, Jul 24, 2015 at 08:57:48PM -0400, Eleftherios Garyfallidis wrote:
>>> > It seems that nipy.org has recently changed. The previous page was
>>> much
>>> > better from what we have now.
>>>
>>> I agree with you that the previous page was much better in term of design
>>> (more colors, a more structured layout, and an image that looked like a
>>> brain clearly visible) and of content (clear list of main projects and
>>> subprojects).
>>>
>>> However, the change was advertised. I understand that you missed it: we
>>> all have too much mails and too many things to do.
>>>
>>> I think that you could make proposals and maybe pull requests to shape
>>> the website toward something that you like better. It would be great.
>>>
>>> Ga?l
>>> _______________________________________________
>>> 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: <http://mail.python.org/pipermail/neuroimaging/attachments/20150726/69eaf06d/attachment.html>

From arokem at gmail.com  Mon Jul 27 01:12:26 2015
From: arokem at gmail.com (Ariel Rokem)
Date: Sun, 26 Jul 2015 16:12:26 -0700
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <CAN6JmWMprY6WGxrWdk7VUyoMoMwtLpWo2PKVv70yFOVYdqb-6w@mail.gmail.com>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CA+X4w0wWtzdCA_6cgRH91tZMWj-yw84tWUUt_6KPWChPzDO9wQ@mail.gmail.com>
 <CAN6JmWMprY6WGxrWdk7VUyoMoMwtLpWo2PKVv70yFOVYdqb-6w@mail.gmail.com>
Message-ID: <CA+X4w0waGqcOVcQOBhczVQLmRqYuXeqBvXZS=UC_TcT1n8QVuw@mail.gmail.com>

Hi,

On Sun, Jul 26, 2015 at 9:53 AM, Eleftherios Garyfallidis <
garyfallidis at gmail.com> wrote:

> Hi Ariel,
>
> On Sat, Jul 25, 2015 at 10:58 PM, Ariel Rokem <arokem at gmail.com> wrote:
>
>> Hi Eleftherios,
>>
>> I am happy to have you finally chime in on the discussion surrounding the
>> webpage. The previous email thread was indeed supposed to spur this
>> discussion, but it did fairly quickly turn into a discussion of github
>> workflow and technical issues surrounding redirection instead. So - better
>> late than never!
>>
>>
> Okay.
>
>
>> As I mentioned in my first email in that previous thread (can't link to
>> it, because the archives on mail.scipy.org are down...), this redesign
>> was the result of conversations at the Berkeley coding sprint back in May.
>> While talking to some relative newcomers, we noticed that the content in
>> the old webpage was really confusing, and gave a somewhat misleading
>> picture of the current state of affairs in the nipy community. For example,
>> I don't think that anyone here really thinks that neuroimaging in Python is
>> only 6 projects, or that one of the first projects people should try out is
>> pbrain (which was one of the six previously mentioned on the front page).
>> So, I don't think that going to the old version of the page is a good
>> solution.
>>
>
> Okay but this new website as it is now is not ready to be online too. It
> is still misleading and I find it difficult to understand what the portal
> is about. It needs much more work to be useful.
>
>>
>> Like almost everything else around here, the webpage is of course work in
>> progress. For example, I can relate to the objections regarding the
>> background image on the front page. I had full intention of replacing the
>> background image with something (possibly several things rotating?) more
>> indicative of the subject matter. I just haven't had the time to do that
>> yet. If someone else wants to jump in and do that, this is the file that
>> would need to be replaced:
>>
>
>>
>> https://github.com/nipy/nipy.github.com/blob/master/images/rect1600x800.png
>>
>> I think from now on when a new website like this is created which affects
> other projects it shouldn't replace immediately the existing website but
> have a link in the existing website saying that there is a new website
> coming. In that way the transition is smoother and it gives you the
> developer the time to make the website better and get more feedback.
>

The message with the link to the new version of the website went to the
mailing list on May 18th. The redirection wasn't changed for another 3
weeks or so. There wasn't anything but positive indications from the list,
and no reason to think that anyone had any reservations about the new
format until 2 days ago.


>
>
>> I am sure that a bit of logic could be used to put in several different
>> attractive images of brain data from which one would be chosen randomly
>> every time you land on the page.
>>
>> Yes, you can put a carousel in the website and remove that background
> with many images. You should also remove the mission with the form it is
> now. It doesn't communicate.
>

I don't know what you are referring to. "Mission"? Are you talking about
https://github.com/nipy/nipy.github.com/pull/1? That was mentioned in a
message asking for feedback on the mailing list on May 22nd. Did you get
any of these messages? Is all this a misunderstanding because the mailing
list was starting to be a bit flaky at that point? I think that others got
these messages, considering that a few people did have comments on this PR,
before it was eventually merged a couple of weeks later.


>
>> Concerning choice of design/technology: as Vanessa pointed out, the
>> technology used for these pages is Jekyll <http://jekyllrb.com/>. It has
>> the following advantages:
>>
>> 1. It is the 'native' technology on Github's platform. That means that we
>> can version control on the markdown from which the site gets generated, and
>> the site itself gets built on Github, rather than needing to be built on
>> anyone's machine every time changes are made. This makes it relatively easy
>> to extend the website, work on it collaboratively using the standard github
>> workflow, and to add additional content. I've even put some instructions in
>> http://nipy.org/contribute/ on how to add such content, especially
>> articles/blog posts. Happy to have people write little articles in that
>> vein, and make things a little bit more lively. It really doesn't have to
>> be a dissertation - writing down a few lines reporting on some new cool
>> project you've seen, or reporting from a conference you've attended from
>> the nipy point of view would be wonderful.
>>
>> 2. Reasonably good-looking, with plenty of customization possible. This
>> is, of course, a matter of taste, so I don't expect anyone to agree with
>> me. Whether having more colors on a page or not is better is really not
>> something I expect anyone to agree with me on. I certainly would not object
>> to changes to the current design that wouldn't be too gaudy. Concerning a
>> comment Gael made: what does a "structured" layout mean? Is that a
>> web-design term? I am (surprise!) not a web designer ;-)
>>
>
>
>> The only disadvantage of Jekyll I can see is that it is Ruby-based. I
>> think that point 1 above outweighs that disadvantage. Point 2 is really a
>> matter for some discussion, and additional work. By the way, whether to use
>> Jekyll is also a discussion that has come up in the context of Software
>> Carpentry. I think that no one in that community regrets choosing jekyll to
>> manage a much more complicated network of web sites, but we can ask them
>> for more advice, if someone thinks that would be useful.
>>
>>
> As I said in my previous e-mail this website can be created using Pelican
> too or with Sphinx and Bootstrap and it will be more pythonic. About option
> 2. Jetkyll can be good looking because of bootstrap. We have exactly the
> same good looks with Sphinx or Pelican. By the way also Pelican supports
> both markdown and rst.
>
> What it seems as advantage is 1. but in practice it is not a big advantage
> because even if people submit their markdown scripts the website will be
> updated only when those are merged and still you will need someone checking
> if they render correctly. I prefer if people who submit content check the
> final website first in their machine before updating the final website.
>
We can still use Jekyll only for the portal but the websites of the rest of
> the projects will have to use sphinx anyway. So, why bother introducing new
> tech.
>

That's roughly analogous to comparing local test runs to Travis. Another
case in which additional technology is adopted because it removes barriers
to collaboration and productivity. Definitely worth it in the case of
testing/Travis. I think it's worth it here as well.


>
> So, my final suggestion is to use Pelican for the portal which supports
> everything that Jekyll supports and works in github fine. And for the other
> websites e.g. dipy, nibabel etc. use sphinx with the same or similar theme
> used in the portal but with some alternations to create a unique look for
> each project.
>
> Some immediate actions:
> a) For now I think you should at least add this information
> http://nipy.org/project-directory/ to the first page and explain what is
> your vision of this portal.
>

That's the link in the middle of the front page. Or am I missing something?
Do you want me to move the entire project directory to the front page? That
wouldn't look great, I think (but I think we've already established that I
am not a web designer...).


> b) Definitely change this background picture maybe add a neuro-related
> picture. You don't need to wait for others to do that. You can do that by
> yourself too. I am sure you have many cool pictures around.
>

Vanessa offered help earlier in this thread, so maybe she has an image she
likes? :-)


> c) Then let's set a meeting together and with other people who want to
> help and I can show you how Pelican/Bootstrap work so you can then see the
> benefits by yourself. Don't worry nothing from the content that you added
> in nipy.org is going to be lost. All these markdowns can also be used
> with Pelican.
>
> I will be available after Wednesday to help you with this.
>
> Cheers,
> Eleftherios
>
>
>
>> Cheers,
>>
>> Ariel
>>
>>
>> On Sat, Jul 25, 2015 at 6:46 AM, Eleftherios Garyfallidis <
>> garyfallidis at gmail.com> wrote:
>>
>>> Hi Gael, Vanessa and Ariel,
>>>
>>> Gael I think the previous e-mail thread was about moving the pages into
>>> github.io and not about the design, the technology or the content of
>>> nipy.org. This being the portal of all projects needs to communicate
>>> the ideas better and use libraries that can be used in other projects too.
>>> Hopefully also be as Pythonic as possible and as useful and attractive as
>>> possible.
>>>
>>> So, my point is that the new portal, although it has some nice ideas,
>>> for examle it is using bootstrap which allows for better and more
>>> responsive viewing
>>> from different devices, it is not ready for prime time. And it shouldn't
>>> be online with the form that is now. So, I would recommend to use the
>>> previous website with updated links to the new github pages until this one
>>> is in a better form.
>>>
>>> Now about the technology used for creating the website. From my
>>> understanding Ariel is using the default engine promoted by github which is
>>> jekyll which at the end is using bootstrap. But bootstrap can be used with
>>> sphinx and with pelican too which are both Python projects.
>>>
>>> So we could actually have two better options. For the portal we can use:
>>>
>>> a) Pelican which is an alternative of Octpress/Jekyll in Python. I used
>>> it to make my  own website and it is easy to use for creating static
>>> websites (like the portal). Link here http://garyfallidis.github.io and
>>> here https://github.com/Garyfallidis/website-dev . Pelican supports
>>> both markdown and restructuredtext.
>>>
>>> b) It is now possible to use Sphinx with bootstrap directly. See here
>>> https://readthedocs.org/projects/sphinx-bootstrap-theme/ and here
>>> https://pypi.python.org/pypi/sphinx-bootstrap-theme/
>>> The option is possibly the best solution as we could just update our
>>> template engine (to use bootstrap) and continue using sphinx as before. But
>>> now we can use any template we want and have a much more responsive website.
>>>
>>> Ideally the portal should have a main theme and then the different
>>> projects would make some alterations to this theme to create their
>>> individual image. For example in Dipy our main colors are black and orange
>>> so we will alternate the theme so we can use mainly those colors is our
>>> website.
>>>
>>> Vanessa of course I am writing this e-mail because I am willing up to my
>>> capacity to help Ariel or anyone else who wants to improve the look and
>>> feel of the organization.
>>>
>>> Ariel in summary, I think the portal is not well designed right now and
>>> the content needs some more work before it is presented. I am happy to help
>>> and I think you will find it useful to have a look in the links that I have
>>> in this e-mail before we meet. In the meantime, I would strongly suggest to
>>> upload the old portal until we have something more solid. I hope this is
>>> okay.
>>>
>>> Cheers,
>>> Eleftherios
>>>
>>>
>>>
>>> On Sat, Jul 25, 2015 at 4:41 AM, Gael Varoquaux <
>>> gael.varoquaux at normalesup.org> wrote:
>>>
>>>> On Fri, Jul 24, 2015 at 08:57:48PM -0400, Eleftherios Garyfallidis
>>>> wrote:
>>>> > It seems that nipy.org has recently changed. The previous page was
>>>> much
>>>> > better from what we have now.
>>>>
>>>> I agree with you that the previous page was much better in term of
>>>> design
>>>> (more colors, a more structured layout, and an image that looked like a
>>>> brain clearly visible) and of content (clear list of main projects and
>>>> subprojects).
>>>>
>>>> However, the change was advertised. I understand that you missed it: we
>>>> all have too much mails and too many things to do.
>>>>
>>>> I think that you could make proposals and maybe pull requests to shape
>>>> the website toward something that you like better. It would be great.
>>>>
>>>> Ga?l
>>>> _______________________________________________
>>>> Neuroimaging mailing list
>>>> Neuroimaging at python.org
>>>> https://mail.python.org/mailman/listinfo/neuroimaging
>>>>
>>>
>>>
>>> _______________________________________________
>>> Neuroimaging mailing list
>>> Neuroimaging at python.org
>>> https://mail.python.org/mailman/listinfo/neuroimaging
>>>
>>>
>>
>> _______________________________________________
>> Neuroimaging mailing list
>> Neuroimaging at python.org
>> https://mail.python.org/mailman/listinfo/neuroimaging
>>
>>
>
> _______________________________________________
> Neuroimaging mailing list
> Neuroimaging at python.org
> https://mail.python.org/mailman/listinfo/neuroimaging
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150726/9813848d/attachment.html>

From vsochat at stanford.edu  Mon Jul 27 01:23:57 2015
From: vsochat at stanford.edu (vanessa sochat)
Date: Sun, 26 Jul 2015 16:23:57 -0700
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <CA+X4w0waGqcOVcQOBhczVQLmRqYuXeqBvXZS=UC_TcT1n8QVuw@mail.gmail.com>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CA+X4w0wWtzdCA_6cgRH91tZMWj-yw84tWUUt_6KPWChPzDO9wQ@mail.gmail.com>
 <CAN6JmWMprY6WGxrWdk7VUyoMoMwtLpWo2PKVv70yFOVYdqb-6w@mail.gmail.com>
 <CA+X4w0waGqcOVcQOBhczVQLmRqYuXeqBvXZS=UC_TcT1n8QVuw@mail.gmail.com>
Message-ID: <CAM=pu+KbzKACZtzt_WNcSYRaMWTe+tALdWBixoN26Nh=v3vymA@mail.gmail.com>

Hi guys,

Just to poke in - I think I've gotten us started on this site business :)
More to come in the next few days!

Best,

Vanessa

On Sun, Jul 26, 2015 at 4:12 PM, Ariel Rokem <arokem at gmail.com> wrote:

> Hi,
>
> On Sun, Jul 26, 2015 at 9:53 AM, Eleftherios Garyfallidis <
> garyfallidis at gmail.com> wrote:
>
>> Hi Ariel,
>>
>> On Sat, Jul 25, 2015 at 10:58 PM, Ariel Rokem <arokem at gmail.com> wrote:
>>
>>> Hi Eleftherios,
>>>
>>> I am happy to have you finally chime in on the discussion surrounding
>>> the webpage. The previous email thread was indeed supposed to spur this
>>> discussion, but it did fairly quickly turn into a discussion of github
>>> workflow and technical issues surrounding redirection instead. So - better
>>> late than never!
>>>
>>>
>> Okay.
>>
>>
>>> As I mentioned in my first email in that previous thread (can't link to
>>> it, because the archives on mail.scipy.org are down...), this redesign
>>> was the result of conversations at the Berkeley coding sprint back in May.
>>> While talking to some relative newcomers, we noticed that the content in
>>> the old webpage was really confusing, and gave a somewhat misleading
>>> picture of the current state of affairs in the nipy community. For example,
>>> I don't think that anyone here really thinks that neuroimaging in Python is
>>> only 6 projects, or that one of the first projects people should try out is
>>> pbrain (which was one of the six previously mentioned on the front page).
>>> So, I don't think that going to the old version of the page is a good
>>> solution.
>>>
>>
>> Okay but this new website as it is now is not ready to be online too. It
>> is still misleading and I find it difficult to understand what the portal
>> is about. It needs much more work to be useful.
>>
>>>
>>> Like almost everything else around here, the webpage is of course work
>>> in progress. For example, I can relate to the objections regarding the
>>> background image on the front page. I had full intention of replacing the
>>> background image with something (possibly several things rotating?) more
>>> indicative of the subject matter. I just haven't had the time to do that
>>> yet. If someone else wants to jump in and do that, this is the file that
>>> would need to be replaced:
>>>
>>
>>>
>>> https://github.com/nipy/nipy.github.com/blob/master/images/rect1600x800.png
>>>
>>> I think from now on when a new website like this is created which
>> affects other projects it shouldn't replace immediately the existing
>> website but have a link in the existing website saying that there is a new
>> website coming. In that way the transition is smoother and it gives you the
>> developer the time to make the website better and get more feedback.
>>
>
> The message with the link to the new version of the website went to the
> mailing list on May 18th. The redirection wasn't changed for another 3
> weeks or so. There wasn't anything but positive indications from the list,
> and no reason to think that anyone had any reservations about the new
> format until 2 days ago.
>
>
>>
>>
>>> I am sure that a bit of logic could be used to put in several different
>>> attractive images of brain data from which one would be chosen randomly
>>> every time you land on the page.
>>>
>>> Yes, you can put a carousel in the website and remove that background
>> with many images. You should also remove the mission with the form it is
>> now. It doesn't communicate.
>>
>
> I don't know what you are referring to. "Mission"? Are you talking about
> https://github.com/nipy/nipy.github.com/pull/1? That was mentioned in a
> message asking for feedback on the mailing list on May 22nd. Did you get
> any of these messages? Is all this a misunderstanding because the mailing
> list was starting to be a bit flaky at that point? I think that others got
> these messages, considering that a few people did have comments on this PR,
> before it was eventually merged a couple of weeks later.
>
>
>>
>>> Concerning choice of design/technology: as Vanessa pointed out, the
>>> technology used for these pages is Jekyll <http://jekyllrb.com/>. It
>>> has the following advantages:
>>>
>>> 1. It is the 'native' technology on Github's platform. That means that
>>> we can version control on the markdown from which the site gets generated,
>>> and the site itself gets built on Github, rather than needing to be built
>>> on anyone's machine every time changes are made. This makes it relatively
>>> easy to extend the website, work on it collaboratively using the standard
>>> github workflow, and to add additional content. I've even put some
>>> instructions in http://nipy.org/contribute/ on how to add such content,
>>> especially articles/blog posts. Happy to have people write little articles
>>> in that vein, and make things a little bit more lively. It really doesn't
>>> have to be a dissertation - writing down a few lines reporting on some new
>>> cool project you've seen, or reporting from a conference you've attended
>>> from the nipy point of view would be wonderful.
>>>
>>> 2. Reasonably good-looking, with plenty of customization possible. This
>>> is, of course, a matter of taste, so I don't expect anyone to agree with
>>> me. Whether having more colors on a page or not is better is really not
>>> something I expect anyone to agree with me on. I certainly would not object
>>> to changes to the current design that wouldn't be too gaudy. Concerning a
>>> comment Gael made: what does a "structured" layout mean? Is that a
>>> web-design term? I am (surprise!) not a web designer ;-)
>>>
>>
>>
>>> The only disadvantage of Jekyll I can see is that it is Ruby-based. I
>>> think that point 1 above outweighs that disadvantage. Point 2 is really a
>>> matter for some discussion, and additional work. By the way, whether to use
>>> Jekyll is also a discussion that has come up in the context of Software
>>> Carpentry. I think that no one in that community regrets choosing jekyll to
>>> manage a much more complicated network of web sites, but we can ask them
>>> for more advice, if someone thinks that would be useful.
>>>
>>>
>> As I said in my previous e-mail this website can be created using Pelican
>> too or with Sphinx and Bootstrap and it will be more pythonic. About option
>> 2. Jetkyll can be good looking because of bootstrap. We have exactly the
>> same good looks with Sphinx or Pelican. By the way also Pelican supports
>> both markdown and rst.
>>
>> What it seems as advantage is 1. but in practice it is not a big
>> advantage because even if people submit their markdown scripts the website
>> will be updated only when those are merged and still you will need someone
>> checking if they render correctly. I prefer if people who submit content
>> check the final website first in their machine before updating the final
>> website.
>>
> We can still use Jekyll only for the portal but the websites of the rest
>> of the projects will have to use sphinx anyway. So, why bother introducing
>> new tech.
>>
>
> That's roughly analogous to comparing local test runs to Travis. Another
> case in which additional technology is adopted because it removes barriers
> to collaboration and productivity. Definitely worth it in the case of
> testing/Travis. I think it's worth it here as well.
>
>
>>
>> So, my final suggestion is to use Pelican for the portal which supports
>> everything that Jekyll supports and works in github fine. And for the other
>> websites e.g. dipy, nibabel etc. use sphinx with the same or similar theme
>> used in the portal but with some alternations to create a unique look for
>> each project.
>>
>> Some immediate actions:
>> a) For now I think you should at least add this information
>> http://nipy.org/project-directory/ to the first page and explain what is
>> your vision of this portal.
>>
>
> That's the link in the middle of the front page. Or am I missing
> something? Do you want me to move the entire project directory to the front
> page? That wouldn't look great, I think (but I think we've already
> established that I am not a web designer...).
>
>
>> b) Definitely change this background picture maybe add a neuro-related
>> picture. You don't need to wait for others to do that. You can do that by
>> yourself too. I am sure you have many cool pictures around.
>>
>
> Vanessa offered help earlier in this thread, so maybe she has an image she
> likes? :-)
>
>
>> c) Then let's set a meeting together and with other people who want to
>> help and I can show you how Pelican/Bootstrap work so you can then see the
>> benefits by yourself. Don't worry nothing from the content that you added
>> in nipy.org is going to be lost. All these markdowns can also be used
>> with Pelican.
>>
>> I will be available after Wednesday to help you with this.
>>
>> Cheers,
>> Eleftherios
>>
>>
>>
>>> Cheers,
>>>
>>> Ariel
>>>
>>>
>>> On Sat, Jul 25, 2015 at 6:46 AM, Eleftherios Garyfallidis <
>>> garyfallidis at gmail.com> wrote:
>>>
>>>> Hi Gael, Vanessa and Ariel,
>>>>
>>>> Gael I think the previous e-mail thread was about moving the pages into
>>>> github.io and not about the design, the technology or the content of
>>>> nipy.org. This being the portal of all projects needs to communicate
>>>> the ideas better and use libraries that can be used in other projects too.
>>>> Hopefully also be as Pythonic as possible and as useful and attractive as
>>>> possible.
>>>>
>>>> So, my point is that the new portal, although it has some nice ideas,
>>>> for examle it is using bootstrap which allows for better and more
>>>> responsive viewing
>>>> from different devices, it is not ready for prime time. And it
>>>> shouldn't be online with the form that is now. So, I would recommend to use
>>>> the previous website with updated links to the new github pages until this
>>>> one is in a better form.
>>>>
>>>> Now about the technology used for creating the website. From my
>>>> understanding Ariel is using the default engine promoted by github which is
>>>> jekyll which at the end is using bootstrap. But bootstrap can be used with
>>>> sphinx and with pelican too which are both Python projects.
>>>>
>>>> So we could actually have two better options. For the portal we can
>>>> use:
>>>>
>>>> a) Pelican which is an alternative of Octpress/Jekyll in Python. I used
>>>> it to make my  own website and it is easy to use for creating static
>>>> websites (like the portal). Link here http://garyfallidis.github.io
>>>> and here https://github.com/Garyfallidis/website-dev . Pelican
>>>> supports both markdown and restructuredtext.
>>>>
>>>> b) It is now possible to use Sphinx with bootstrap directly. See here
>>>> https://readthedocs.org/projects/sphinx-bootstrap-theme/ and here
>>>> https://pypi.python.org/pypi/sphinx-bootstrap-theme/
>>>> The option is possibly the best solution as we could just update our
>>>> template engine (to use bootstrap) and continue using sphinx as before. But
>>>> now we can use any template we want and have a much more responsive website.
>>>>
>>>> Ideally the portal should have a main theme and then the different
>>>> projects would make some alterations to this theme to create their
>>>> individual image. For example in Dipy our main colors are black and orange
>>>> so we will alternate the theme so we can use mainly those colors is our
>>>> website.
>>>>
>>>> Vanessa of course I am writing this e-mail because I am willing up to
>>>> my capacity to help Ariel or anyone else who wants to improve the look and
>>>> feel of the organization.
>>>>
>>>> Ariel in summary, I think the portal is not well designed right now and
>>>> the content needs some more work before it is presented. I am happy to help
>>>> and I think you will find it useful to have a look in the links that I have
>>>> in this e-mail before we meet. In the meantime, I would strongly suggest to
>>>> upload the old portal until we have something more solid. I hope this is
>>>> okay.
>>>>
>>>> Cheers,
>>>> Eleftherios
>>>>
>>>>
>>>>
>>>> On Sat, Jul 25, 2015 at 4:41 AM, Gael Varoquaux <
>>>> gael.varoquaux at normalesup.org> wrote:
>>>>
>>>>> On Fri, Jul 24, 2015 at 08:57:48PM -0400, Eleftherios Garyfallidis
>>>>> wrote:
>>>>> > It seems that nipy.org has recently changed. The previous page was
>>>>> much
>>>>> > better from what we have now.
>>>>>
>>>>> I agree with you that the previous page was much better in term of
>>>>> design
>>>>> (more colors, a more structured layout, and an image that looked like a
>>>>> brain clearly visible) and of content (clear list of main projects and
>>>>> subprojects).
>>>>>
>>>>> However, the change was advertised. I understand that you missed it: we
>>>>> all have too much mails and too many things to do.
>>>>>
>>>>> I think that you could make proposals and maybe pull requests to shape
>>>>> the website toward something that you like better. It would be great.
>>>>>
>>>>> Ga?l
>>>>> _______________________________________________
>>>>> Neuroimaging mailing list
>>>>> Neuroimaging at python.org
>>>>> https://mail.python.org/mailman/listinfo/neuroimaging
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Neuroimaging mailing list
>>>> Neuroimaging at python.org
>>>> https://mail.python.org/mailman/listinfo/neuroimaging
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Neuroimaging mailing list
>>> Neuroimaging at python.org
>>> https://mail.python.org/mailman/listinfo/neuroimaging
>>>
>>>
>>
>> _______________________________________________
>> Neuroimaging mailing list
>> Neuroimaging at python.org
>> https://mail.python.org/mailman/listinfo/neuroimaging
>>
>>
>
> _______________________________________________
> Neuroimaging mailing list
> Neuroimaging at python.org
> https://mail.python.org/mailman/listinfo/neuroimaging
>
>


-- 
Vanessa Villamia Sochat
Stanford University
(603) 321-0676
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150726/febe2c03/attachment-0001.html>

From garyfallidis at gmail.com  Mon Jul 27 03:57:57 2015
From: garyfallidis at gmail.com (Eleftherios Garyfallidis)
Date: Sun, 26 Jul 2015 21:57:57 -0400
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <CA+X4w0waGqcOVcQOBhczVQLmRqYuXeqBvXZS=UC_TcT1n8QVuw@mail.gmail.com>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CA+X4w0wWtzdCA_6cgRH91tZMWj-yw84tWUUt_6KPWChPzDO9wQ@mail.gmail.com>
 <CAN6JmWMprY6WGxrWdk7VUyoMoMwtLpWo2PKVv70yFOVYdqb-6w@mail.gmail.com>
 <CA+X4w0waGqcOVcQOBhczVQLmRqYuXeqBvXZS=UC_TcT1n8QVuw@mail.gmail.com>
Message-ID: <CAN6JmWOxujFf+2bUojRT6Qw4t8DL-jgvBYtEQCgjOg++Y9on5g@mail.gmail.com>

Hi,

On Sun, Jul 26, 2015 at 7:12 PM, Ariel Rokem <arokem at gmail.com> wrote:

> Hi,
>
> The message with the link to the new version of the website went to the
> mailing list on May 18th. The redirection wasn't changed for another 3
> weeks or so. There wasn't anything but positive indications from the list,
> and no reason to think that anyone had any reservations about the new
> format until 2 days ago.
>

Yeah, sorry for being late to look at this. But as you said "better late
than never".

>
>
>>
>>
>>> I am sure that a bit of logic could be used to put in several different
>>> attractive images of brain data from which one would be chosen randomly
>>> every time you land on the page.
>>>
>>> Yes, you can put a carousel in the website and remove that background
>> with many images. You should also remove the mission with the form it is
>> now. It doesn't communicate.
>>
>
> I don't know what you are referring to. "Mission"? Are you talking about
> https://github.com/nipy/nipy.github.com/pull/1? That was mentioned in a
> message asking for feedback on the mailing list on May 22nd. Did you get
> any of these messages? Is all this a misunderstanding because the mailing
> list was starting to be a bit flaky at that point? I think that others got
> these messages, considering that a few people did have comments on this PR,
> before it was eventually merged a couple of weeks later.
>
> No, I mean that in the main page (nipy.org) you have  4 columns under the
jumbotron that say "cleary written, clearly explained etc." which we use as
mission statements. I think as it is now it would be difficult for someone
to understand were those texts refer to.


>
>>> As I said in my previous e-mail this website can be created using
>> Pelican too or with Sphinx and Bootstrap and it will be more pythonic.
>> About option 2. Jetkyll can be good looking because of bootstrap. We have
>> exactly the same good looks with Sphinx or Pelican. By the way also Pelican
>> supports both markdown and rst.
>>
>> What it seems as advantage is 1. but in practice it is not a big
>> advantage because even if people submit their markdown scripts the website
>> will be updated only when those are merged and still you will need someone
>> checking if they render correctly. I prefer if people who submit content
>> check the final website first in their machine before updating the final
>> website.
>>
> We can still use Jekyll only for the portal but the websites of the rest
>> of the projects will have to use sphinx anyway. So, why bother introducing
>> new tech.
>>
>
> That's roughly analogous to comparing local test runs to Travis. Another
> case in which additional technology is adopted because it removes barriers
> to collaboration and productivity. Definitely worth it in the case of
> testing/Travis. I think it's worth it here as well.
>
>
No, I think this is very different. Except it is something that I don't
understand right now. If jekyll doesn't allow you to preview the markdown
before making a PR then you are still blind on knowing how well the
markdown will render. Why don't we spend some time to look at the
alternatives e.g. Pelican etc.? I am confident that it will not need much
time to make the switch and that they will not be any disadvantages. But
hey I may be wrong. At least this is my understanding.

>
>> So, my final suggestion is to use Pelican for the portal which supports
>> everything that Jekyll supports and works in github fine. And for the other
>> websites e.g. dipy, nibabel etc. use sphinx with the same or similar theme
>> used in the portal but with some alternations to create a unique look for
>> each project.
>>
>> Some immediate actions:
>> a) For now I think you should at least add this information
>> http://nipy.org/project-directory/ to the first page and explain what is
>> your vision of this portal.
>>
>
> That's the link in the middle of the front page. Or am I missing
> something? Do you want me to move the entire project directory to the front
> page? That wouldn't look great, I think (but I think we've already
> established that I am not a web designer...).
>

No but I think it is nice to have the links of the individual projects in
the front page so that it is easier to find them. And a message explaining
what is NIPY. I think NIPY from now on will be mostly a term used for the
organization as the library will not be further developed.

>
>
>> b) Definitely change this background picture maybe add a neuro-related
>> picture. You don't need to wait for others to do that. You can do that by
>> yourself too. I am sure you have many cool pictures around.
>>
>
> Vanessa offered help earlier in this thread, so maybe she has an image she
> likes? :-)
>

Thank you Vanessa :)

>
>
>> c) Then let's set a meeting together and with other people who want to
>> help and I can show you how Pelican/Bootstrap work so you can then see the
>> benefits by yourself. Don't worry nothing from the content that you added
>> in nipy.org is going to be lost. All these markdowns can also be used
>> with Pelican.
>>
>> I will be available after Wednesday to help you with this.
>>
>> Let me know if you and Vanessa are interested about this.

Keep it up!
Cheers,
Eleftherios

Cheers,
>> Eleftherios
>>
>>
>>
>>> Cheers,
>>>
>>> Ariel
>>>
>>>
>>> On Sat, Jul 25, 2015 at 6:46 AM, Eleftherios Garyfallidis <
>>> garyfallidis at gmail.com> wrote:
>>>
>>>> Hi Gael, Vanessa and Ariel,
>>>>
>>>> Gael I think the previous e-mail thread was about moving the pages into
>>>> github.io and not about the design, the technology or the content of
>>>> nipy.org. This being the portal of all projects needs to communicate
>>>> the ideas better and use libraries that can be used in other projects too.
>>>> Hopefully also be as Pythonic as possible and as useful and attractive as
>>>> possible.
>>>>
>>>> So, my point is that the new portal, although it has some nice ideas,
>>>> for examle it is using bootstrap which allows for better and more
>>>> responsive viewing
>>>> from different devices, it is not ready for prime time. And it
>>>> shouldn't be online with the form that is now. So, I would recommend to use
>>>> the previous website with updated links to the new github pages until this
>>>> one is in a better form.
>>>>
>>>> Now about the technology used for creating the website. From my
>>>> understanding Ariel is using the default engine promoted by github which is
>>>> jekyll which at the end is using bootstrap. But bootstrap can be used with
>>>> sphinx and with pelican too which are both Python projects.
>>>>
>>>> So we could actually have two better options. For the portal we can
>>>> use:
>>>>
>>>> a) Pelican which is an alternative of Octpress/Jekyll in Python. I used
>>>> it to make my  own website and it is easy to use for creating static
>>>> websites (like the portal). Link here http://garyfallidis.github.io
>>>> and here https://github.com/Garyfallidis/website-dev . Pelican
>>>> supports both markdown and restructuredtext.
>>>>
>>>> b) It is now possible to use Sphinx with bootstrap directly. See here
>>>> https://readthedocs.org/projects/sphinx-bootstrap-theme/ and here
>>>> https://pypi.python.org/pypi/sphinx-bootstrap-theme/
>>>> The option is possibly the best solution as we could just update our
>>>> template engine (to use bootstrap) and continue using sphinx as before. But
>>>> now we can use any template we want and have a much more responsive website.
>>>>
>>>> Ideally the portal should have a main theme and then the different
>>>> projects would make some alterations to this theme to create their
>>>> individual image. For example in Dipy our main colors are black and orange
>>>> so we will alternate the theme so we can use mainly those colors is our
>>>> website.
>>>>
>>>> Vanessa of course I am writing this e-mail because I am willing up to
>>>> my capacity to help Ariel or anyone else who wants to improve the look and
>>>> feel of the organization.
>>>>
>>>> Ariel in summary, I think the portal is not well designed right now and
>>>> the content needs some more work before it is presented. I am happy to help
>>>> and I think you will find it useful to have a look in the links that I have
>>>> in this e-mail before we meet. In the meantime, I would strongly suggest to
>>>> upload the old portal until we have something more solid. I hope this is
>>>> okay.
>>>>
>>>> Cheers,
>>>> Eleftherios
>>>>
>>>>
>>>>
>>>> On Sat, Jul 25, 2015 at 4:41 AM, Gael Varoquaux <
>>>> gael.varoquaux at normalesup.org> wrote:
>>>>
>>>>> On Fri, Jul 24, 2015 at 08:57:48PM -0400, Eleftherios Garyfallidis
>>>>> wrote:
>>>>> > It seems that nipy.org has recently changed. The previous page was
>>>>> much
>>>>> > better from what we have now.
>>>>>
>>>>> I agree with you that the previous page was much better in term of
>>>>> design
>>>>> (more colors, a more structured layout, and an image that looked like a
>>>>> brain clearly visible) and of content (clear list of main projects and
>>>>> subprojects).
>>>>>
>>>>> However, the change was advertised. I understand that you missed it: we
>>>>> all have too much mails and too many things to do.
>>>>>
>>>>> I think that you could make proposals and maybe pull requests to shape
>>>>> the website toward something that you like better. It would be great.
>>>>>
>>>>> Ga?l
>>>>> _______________________________________________
>>>>> Neuroimaging mailing list
>>>>> Neuroimaging at python.org
>>>>> https://mail.python.org/mailman/listinfo/neuroimaging
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Neuroimaging mailing list
>>>> Neuroimaging at python.org
>>>> https://mail.python.org/mailman/listinfo/neuroimaging
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Neuroimaging mailing list
>>> Neuroimaging at python.org
>>> https://mail.python.org/mailman/listinfo/neuroimaging
>>>
>>>
>>
>> _______________________________________________
>> Neuroimaging mailing list
>> Neuroimaging at python.org
>> https://mail.python.org/mailman/listinfo/neuroimaging
>>
>>
>
> _______________________________________________
> 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/20150726/220881eb/attachment.html>

From vsochat at stanford.edu  Mon Jul 27 04:03:55 2015
From: vsochat at stanford.edu (vanessa sochat)
Date: Sun, 26 Jul 2015 19:03:55 -0700
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
Message-ID: <CAM=pu+J6K7fe3aEs7RyZ9_ecNf=SJUTNNJzX2FzVq2HAd3ne7Q@mail.gmail.com>

Hi everyone,

I didn't get to finish this today and I need to bike home soon, but I
wanted to share with you what I'm working on (that I hope we can work on
together!) I wanted to make a design that was simple, but (will eventually)
have subtle details to make it really beautiful. Here are some notes:


   - I don't think a corporate design (with a banner) is appropriate for
   this, but rather a more "documentation-ish" style like read the docs.
   - I chose flask because (I think) we can freeze the content and then
   host on github pages, but I'm not sure. It worked for my initial try, but I
   didn't try re-freezing. I also chose it because it's in python, meaning you
   can do stuff with the packages as examples and render in the page.
   - Bootstrap
   - New blog posts are markdown, and are dropped in the blog folder
   - To add a new package, you just add it to the text file - it gets
   rendered automatically. If you want to add more detail, adding a page
   template with the name will over-ride this.
   - The logo snake has "snakey thoughts" that you can interact with :)

Here is a demo of the skeleton thus far (there is much to be done, but I
really need to go home and eat something)

http://www.vbmis.com/bmi/project/nipy/

and the code - please feel free to add notes / comments as issues, or
contribute!

https://github.com/vsoch/nipy

It's ok if you hate it, but I hope there is something here that we can work
with. If you do, no worries, I can use for something else (I dig making
these sort of things).

Best,

Vanessa

On Sat, Jul 25, 2015 at 6:46 AM, Eleftherios Garyfallidis <
garyfallidis at gmail.com> wrote:

> Hi Gael, Vanessa and Ariel,
>
> Gael I think the previous e-mail thread was about moving the pages into
> github.io and not about the design, the technology or the content of
> nipy.org. This being the portal of all projects needs to communicate the
> ideas better and use libraries that can be used in other projects too.
> Hopefully also be as Pythonic as possible and as useful and attractive as
> possible.
>
> So, my point is that the new portal, although it has some nice ideas, for
> examle it is using bootstrap which allows for better and more responsive
> viewing
> from different devices, it is not ready for prime time. And it shouldn't
> be online with the form that is now. So, I would recommend to use the
> previous website with updated links to the new github pages until this one
> is in a better form.
>
> Now about the technology used for creating the website. From my
> understanding Ariel is using the default engine promoted by github which is
> jekyll which at the end is using bootstrap. But bootstrap can be used with
> sphinx and with pelican too which are both Python projects.
>
> So we could actually have two better options. For the portal we can use:
>
> a) Pelican which is an alternative of Octpress/Jekyll in Python. I used it
> to make my  own website and it is easy to use for creating static websites
> (like the portal). Link here http://garyfallidis.github.io and here
> https://github.com/Garyfallidis/website-dev . Pelican supports both
> markdown and restructuredtext.
>
> b) It is now possible to use Sphinx with bootstrap directly. See here
> https://readthedocs.org/projects/sphinx-bootstrap-theme/ and here
> https://pypi.python.org/pypi/sphinx-bootstrap-theme/
> The option is possibly the best solution as we could just update our
> template engine (to use bootstrap) and continue using sphinx as before. But
> now we can use any template we want and have a much more responsive website.
>
> Ideally the portal should have a main theme and then the different
> projects would make some alterations to this theme to create their
> individual image. For example in Dipy our main colors are black and orange
> so we will alternate the theme so we can use mainly those colors is our
> website.
>
> Vanessa of course I am writing this e-mail because I am willing up to my
> capacity to help Ariel or anyone else who wants to improve the look and
> feel of the organization.
>
> Ariel in summary, I think the portal is not well designed right now and
> the content needs some more work before it is presented. I am happy to help
> and I think you will find it useful to have a look in the links that I have
> in this e-mail before we meet. In the meantime, I would strongly suggest to
> upload the old portal until we have something more solid. I hope this is
> okay.
>
> Cheers,
> Eleftherios
>
>
>
> On Sat, Jul 25, 2015 at 4:41 AM, Gael Varoquaux <
> gael.varoquaux at normalesup.org> wrote:
>
>> On Fri, Jul 24, 2015 at 08:57:48PM -0400, Eleftherios Garyfallidis wrote:
>> > It seems that nipy.org has recently changed. The previous page was much
>> > better from what we have now.
>>
>> I agree with you that the previous page was much better in term of design
>> (more colors, a more structured layout, and an image that looked like a
>> brain clearly visible) and of content (clear list of main projects and
>> subprojects).
>>
>> However, the change was advertised. I understand that you missed it: we
>> all have too much mails and too many things to do.
>>
>> I think that you could make proposals and maybe pull requests to shape
>> the website toward something that you like better. It would be great.
>>
>> Ga?l
>> _______________________________________________
>> 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
>
>


-- 
Vanessa Villamia Sochat
Stanford University
(603) 321-0676
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150726/8f839f24/attachment.html>

From gael.varoquaux at normalesup.org  Mon Jul 27 07:25:01 2015
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Mon, 27 Jul 2015 07:25:01 +0200
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <CAM=pu+J6K7fe3aEs7RyZ9_ecNf=SJUTNNJzX2FzVq2HAd3ne7Q@mail.gmail.com>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CAM=pu+J6K7fe3aEs7RyZ9_ecNf=SJUTNNJzX2FzVq2HAd3ne7Q@mail.gmail.com>
Message-ID: <20150727052501.GB550510@phare.normalesup.org>

Hi,

Since it is the time to gives one opinion

- I agree with Elefterios that I think it is a good thing to have a list
  of the projects on the front page. I liked how the old webpage did it

- The snake-brain logo is great. We should have it on the front page.

- Developper-oriented information should be less emphasized compared to
  user-oriented information: 'view on github', 'contribute', 'A natural
  home for collaboration' should be deemphasized compared to the project
  directory. The reason is that we are trying to convince people to use
  the nipy ecosystem, and for this, the highest priority is to orient
  end users.

My 2 cents,

Ga?l

PS: Vanessa: Nilearn is not only for fMRI. It's for statistical analysis
of images. It is also used for anatomical images:
http://nilearn.github.io/auto_examples/decoding/plot_oasis_vbm.html 
If we could get a preprocessed, openly downloadable set of images of eg
FA, we would do an example with diffusion too.

From matthew.brett at gmail.com  Mon Jul 27 11:13:27 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Mon, 27 Jul 2015 10:13:27 +0100
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <20150727052501.GB550510@phare.normalesup.org>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CAM=pu+J6K7fe3aEs7RyZ9_ecNf=SJUTNNJzX2FzVq2HAd3ne7Q@mail.gmail.com>
 <20150727052501.GB550510@phare.normalesup.org>
Message-ID: <CAH6Pt5qMOjwq39UvitoXjEA6LydxmVkbJQN=cwFBgMZct-7U0A@mail.gmail.com>

Hi,

On Mon, Jul 27, 2015 at 6:25 AM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> Hi,
>
> Since it is the time to gives one opinion

Sorry to be quiet.

I don't have strong feelings about whether the new or old website is
better, but Ariel saved us from a lot of frustration by moving us to
github pages before the recent Sourceforge meltdown [1].

Eleftherios - your main complaint against Jeykll is that it's hard to
render the pages before you submit a PR?   I don't think it's that
hard - see http://jekyllrb.com  . OK, it involves installing something
in Ruby via gem, but that's not a major burden, and pelican is not
trivial to set up either.

For the content - I don't think it's reasonable to ask Ariel to make
the changes, any more that it would be for code.  If you think it
could be done better, then please, make a PR, surely that will not be
much work, and will give the best possible idea of what you would
prefer.

Cheers,

Matthew

[1] http://sourceforge.net/blog/sourceforge-infrastructure-and-service-restoration-update-for-724/

From vsochat at stanford.edu  Mon Jul 27 14:54:10 2015
From: vsochat at stanford.edu (vanessa sochat)
Date: Mon, 27 Jul 2015 05:54:10 -0700
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <20150727052501.GB550510@phare.normalesup.org>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CAM=pu+J6K7fe3aEs7RyZ9_ecNf=SJUTNNJzX2FzVq2HAd3ne7Q@mail.gmail.com>
 <20150727052501.GB550510@phare.normalesup.org>
Message-ID: <CAM=pu+LhN0=gksP+72r4u7-MNrMMN144XbJiawYujE8hkJ5o+A@mail.gmail.com>

Having all packages nicely shown on the front page is a good idea - and I
was thinking of having a nice visualization that would quickly show some
stats next to each. I put the latest blob post mostly because I ran out of
work time for the day. Is the old site living somewhere so I can take a
look?

Ga?l - I completely agree about nilearn! I just copied the groups as is
from the current page, and had I thought about this, probably would have
questioned them.

On Sun, Jul 26, 2015 at 10:25 PM, Gael Varoquaux <
gael.varoquaux at normalesup.org> wrote:

> Hi,
>
> Since it is the time to gives one opinion
>
> - I agree with Elefterios that I think it is a good thing to have a list
>   of the projects on the front page. I liked how the old webpage did it
>
> - The snake-brain logo is great. We should have it on the front page.
>
> - Developper-oriented information should be less emphasized compared to
>   user-oriented information: 'view on github', 'contribute', 'A natural
>   home for collaboration' should be deemphasized compared to the project
>   directory. The reason is that we are trying to convince people to use
>   the nipy ecosystem, and for this, the highest priority is to orient
>   end users.
>
> My 2 cents,
>
> Ga?l
>
> PS: Vanessa: Nilearn is not only for fMRI. It's for statistical analysis
> of images. It is also used for anatomical images:
> http://nilearn.github.io/auto_examples/decoding/plot_oasis_vbm.html
> If we could get a preprocessed, openly downloadable set of images of eg
> FA, we would do an example with diffusion too.
> _______________________________________________
> Neuroimaging mailing list
> Neuroimaging at python.org
> https://mail.python.org/mailman/listinfo/neuroimaging
>



-- 
Vanessa Villamia Sochat
Stanford University
(603) 321-0676
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150727/72d6b604/attachment.html>

From matthew.brett at gmail.com  Mon Jul 27 15:00:48 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Mon, 27 Jul 2015 14:00:48 +0100
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <CAM=pu+LhN0=gksP+72r4u7-MNrMMN144XbJiawYujE8hkJ5o+A@mail.gmail.com>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CAM=pu+J6K7fe3aEs7RyZ9_ecNf=SJUTNNJzX2FzVq2HAd3ne7Q@mail.gmail.com>
 <20150727052501.GB550510@phare.normalesup.org>
 <CAM=pu+LhN0=gksP+72r4u7-MNrMMN144XbJiawYujE8hkJ5o+A@mail.gmail.com>
Message-ID: <CAH6Pt5rfPGe0dBKfoiXSxwQMj6SrBK=xDtB1FE6kGxXWE8UYKw@mail.gmail.com>

Hi,

On Mon, Jul 27, 2015 at 1:54 PM, vanessa sochat <vsochat at stanford.edu> wrote:
> Having all packages nicely shown on the front page is a good idea - and I
> was thinking of having a nice visualization that would quickly show some
> stats next to each. I put the latest blob post mostly because I ran out of
> work time for the day. Is the old site living somewhere so I can take a
> look?

The old website is at https://github.com/nipy/nipyco

Thanks for your help on this, it would be very good to get more
feedback on the web design.

Cheers,

Matthew

From arokem at gmail.com  Mon Jul 27 17:49:32 2015
From: arokem at gmail.com (Ariel Rokem)
Date: Mon, 27 Jul 2015 08:49:32 -0700
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <CAH6Pt5qMOjwq39UvitoXjEA6LydxmVkbJQN=cwFBgMZct-7U0A@mail.gmail.com>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CAM=pu+J6K7fe3aEs7RyZ9_ecNf=SJUTNNJzX2FzVq2HAd3ne7Q@mail.gmail.com>
 <20150727052501.GB550510@phare.normalesup.org>
 <CAH6Pt5qMOjwq39UvitoXjEA6LydxmVkbJQN=cwFBgMZct-7U0A@mail.gmail.com>
Message-ID: <CA+X4w0zvS-6TO7R=28Wj1VDN7w=v-jR+BW=8Br4A3hAxBTR-PA@mail.gmail.com>

On Mon, Jul 27, 2015 at 2:13 AM, Matthew Brett <matthew.brett at gmail.com>
wrote:

> Hi,
>
> On Mon, Jul 27, 2015 at 6:25 AM, Gael Varoquaux
> <gael.varoquaux at normalesup.org> wrote:
> > Hi,
> >
> > Since it is the time to gives one opinion
>
> Sorry to be quiet.
>
> I don't have strong feelings about whether the new or old website is
> better, but Ariel saved us from a lot of frustration by moving us to
> github pages before the recent Sourceforge meltdown [1].
>
> Eleftherios - your main complaint against Jeykll is that it's hard to
> render the pages before you submit a PR?   I don't think it's that
> hard - see http://jekyllrb.com  . OK, it involves installing something
> in Ruby via gem, but that's not a major burden, and pelican is not
> trivial to set up either.
>
>
There's no need to install Jekyll on your machine any more than you would
install the Travis infrastructure on your machine. If you push to your
fork's gh-pages branch, the content will get rendered *on your fork*:

http://arokem.github.io/nipy.github.com/

This means that you might need to make PRs from your gh-pages branch, or
update your gh-pages branch from your PR branch, especially if you made
some complicated formatting change that.



> For the content - I don't think it's reasonable to ask Ariel to make
> the changes, any more that it would be for code.  If you think it
> could be done better, then please, make a PR, surely that will not be
> much work, and will give the best possible idea of what you would
> prefer.
>
> Cheers,
>
> Matthew
>
> [1]
> http://sourceforge.net/blog/sourceforge-infrastructure-and-service-restoration-update-for-724/
> _______________________________________________
> 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/20150727/7ab0b1e4/attachment.html>

From arokem at gmail.com  Mon Jul 27 17:53:16 2015
From: arokem at gmail.com (Ariel Rokem)
Date: Mon, 27 Jul 2015 08:53:16 -0700
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <CAM=pu+LhN0=gksP+72r4u7-MNrMMN144XbJiawYujE8hkJ5o+A@mail.gmail.com>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CAM=pu+J6K7fe3aEs7RyZ9_ecNf=SJUTNNJzX2FzVq2HAd3ne7Q@mail.gmail.com>
 <20150727052501.GB550510@phare.normalesup.org>
 <CAM=pu+LhN0=gksP+72r4u7-MNrMMN144XbJiawYujE8hkJ5o+A@mail.gmail.com>
Message-ID: <CA+X4w0yr0kXgBL9JkZSPXzX7SZUf5OQwZksKMso-g04TgLSCMQ@mail.gmail.com>

On Mon, Jul 27, 2015 at 5:54 AM, vanessa sochat <vsochat at stanford.edu>
wrote:

> Having all packages nicely shown on the front page is a good idea - and I
> was thinking of having a nice visualization that would quickly show some
> stats next to each. I put the latest blob post mostly because I ran out of
> work time for the day. Is the old site living somewhere so I can take a
> look?
>
> Thanks so much for joining in the effort! For me, an important change
relative to the old page design is to allow the project list to change over
time and to allow people to easily advertise their neuroimaging-in-python
projects on this webpage. I would prefer not to have the list of projects
be statically enshrined into the design of the front page. If you can make
it organically change on the front page, that would be good.


> Ga?l - I completely agree about nilearn! I just copied the groups as is
> from the current page, and had I thought about this, probably would have
> questioned them.
>
> On Sun, Jul 26, 2015 at 10:25 PM, Gael Varoquaux <
> gael.varoquaux at normalesup.org> wrote:
>
>> Hi,
>>
>> Since it is the time to gives one opinion
>>
>> - I agree with Elefterios that I think it is a good thing to have a list
>>   of the projects on the front page. I liked how the old webpage did it
>>
>> - The snake-brain logo is great. We should have it on the front page.
>>
>> - Developper-oriented information should be less emphasized compared to
>>   user-oriented information: 'view on github', 'contribute', 'A natural
>>   home for collaboration' should be deemphasized compared to the project
>>   directory. The reason is that we are trying to convince people to use
>>   the nipy ecosystem, and for this, the highest priority is to orient
>>   end users.
>>
>> My 2 cents,
>>
>> Ga?l
>>
>> PS: Vanessa: Nilearn is not only for fMRI. It's for statistical analysis
>> of images. It is also used for anatomical images:
>> http://nilearn.github.io/auto_examples/decoding/plot_oasis_vbm.html
>> If we could get a preprocessed, openly downloadable set of images of eg
>> FA, we would do an example with diffusion too.
>> _______________________________________________
>> Neuroimaging mailing list
>> Neuroimaging at python.org
>> https://mail.python.org/mailman/listinfo/neuroimaging
>>
>
>
>
> --
> Vanessa Villamia Sochat
> Stanford University
> (603) 321-0676
>
> _______________________________________________
> 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/20150727/e1a31be1/attachment.html>

From arokem at gmail.com  Mon Jul 27 17:56:08 2015
From: arokem at gmail.com (Ariel Rokem)
Date: Mon, 27 Jul 2015 08:56:08 -0700
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <20150727052501.GB550510@phare.normalesup.org>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CAM=pu+J6K7fe3aEs7RyZ9_ecNf=SJUTNNJzX2FzVq2HAd3ne7Q@mail.gmail.com>
 <20150727052501.GB550510@phare.normalesup.org>
Message-ID: <CA+X4w0z-WpsKk0gBu9pmoaDVCDFZyHQfWLtNokFtJURWGFRCuQ@mail.gmail.com>

On Sun, Jul 26, 2015 at 10:25 PM, Gael Varoquaux <
gael.varoquaux at normalesup.org> wrote:

> Hi,
>
> Since it is the time to gives one opinion
>
> - I agree with Elefterios that I think it is a good thing to have a list
>   of the projects on the front page. I liked how the old webpage did it
>
> - The snake-brain logo is great. We should have it on the front page.
>
> - Developper-oriented information should be less emphasized compared to
>   user-oriented information: 'view on github', 'contribute', 'A natural
>   home for collaboration' should be deemphasized compared to the project
>   directory. The reason is that we are trying to convince people to use
>   the nipy ecosystem, and for this, the highest priority is to orient
>   end users.
>
> My 2 cents,
>
> Ga?l
>
> PS: Vanessa: Nilearn is not only for fMRI. It's for statistical analysis
> of images. It is also used for anatomical images:
> http://nilearn.github.io/auto_examples/decoding/plot_oasis_vbm.html
> If we could get a preprocessed, openly downloadable set of images of eg
> FA, we would do an example with diffusion too.
>

Completely off-topic, but I can't resist: if only there was an open-source
project that computed FA images from freely available diffusion MRI
data-sets!

:-)



> _______________________________________________
> 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/20150727/e3c95630/attachment.html>

From vsochat at stanford.edu  Mon Jul 27 17:57:30 2015
From: vsochat at stanford.edu (vanessa sochat)
Date: Mon, 27 Jul 2015 08:57:30 -0700
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <CA+X4w0yr0kXgBL9JkZSPXzX7SZUf5OQwZksKMso-g04TgLSCMQ@mail.gmail.com>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CAM=pu+J6K7fe3aEs7RyZ9_ecNf=SJUTNNJzX2FzVq2HAd3ne7Q@mail.gmail.com>
 <20150727052501.GB550510@phare.normalesup.org>
 <CAM=pu+LhN0=gksP+72r4u7-MNrMMN144XbJiawYujE8hkJ5o+A@mail.gmail.com>
 <CA+X4w0yr0kXgBL9JkZSPXzX7SZUf5OQwZksKMso-g04TgLSCMQ@mail.gmail.com>
Message-ID: <CAM=pu++DL13+mv8JuQDJeg-6Eszc4npXEmc4GxXcyF_LTJx=Xg@mail.gmail.com>

Yes, of course! The current design generates the navigation and pages
dynamically from this file:

https://github.com/vsoch/nipy/blob/master/code/static/projects.tsv

If there is nothing added beyond that, a standard template page is used for
the package's page:

https://github.com/vsoch/nipy/blob/master/code/templates/project.html

but for custom stuffs, the user can add a template page with the same name
as the markdown_tag variable, for example, here is nipype:

https://github.com/vsoch/nipy/blob/master/code/templates/nipype.html

And of course the front page content will be generated in this fashion as
well.



On Mon, Jul 27, 2015 at 8:53 AM, Ariel Rokem <arokem at gmail.com> wrote:

>
>
> On Mon, Jul 27, 2015 at 5:54 AM, vanessa sochat <vsochat at stanford.edu>
> wrote:
>
>> Having all packages nicely shown on the front page is a good idea - and I
>> was thinking of having a nice visualization that would quickly show some
>> stats next to each. I put the latest blob post mostly because I ran out of
>> work time for the day. Is the old site living somewhere so I can take a
>> look?
>>
>> Thanks so much for joining in the effort! For me, an important change
> relative to the old page design is to allow the project list to change over
> time and to allow people to easily advertise their neuroimaging-in-python
> projects on this webpage. I would prefer not to have the list of projects
> be statically enshrined into the design of the front page. If you can make
> it organically change on the front page, that would be good.
>
>
>> Ga?l - I completely agree about nilearn! I just copied the groups as is
>> from the current page, and had I thought about this, probably would have
>> questioned them.
>>
>> On Sun, Jul 26, 2015 at 10:25 PM, Gael Varoquaux <
>> gael.varoquaux at normalesup.org> wrote:
>>
>>> Hi,
>>>
>>> Since it is the time to gives one opinion
>>>
>>> - I agree with Elefterios that I think it is a good thing to have a list
>>>   of the projects on the front page. I liked how the old webpage did it
>>>
>>> - The snake-brain logo is great. We should have it on the front page.
>>>
>>> - Developper-oriented information should be less emphasized compared to
>>>   user-oriented information: 'view on github', 'contribute', 'A natural
>>>   home for collaboration' should be deemphasized compared to the project
>>>   directory. The reason is that we are trying to convince people to use
>>>   the nipy ecosystem, and for this, the highest priority is to orient
>>>   end users.
>>>
>>> My 2 cents,
>>>
>>> Ga?l
>>>
>>> PS: Vanessa: Nilearn is not only for fMRI. It's for statistical analysis
>>> of images. It is also used for anatomical images:
>>> http://nilearn.github.io/auto_examples/decoding/plot_oasis_vbm.html
>>> If we could get a preprocessed, openly downloadable set of images of eg
>>> FA, we would do an example with diffusion too.
>>> _______________________________________________
>>> Neuroimaging mailing list
>>> Neuroimaging at python.org
>>> https://mail.python.org/mailman/listinfo/neuroimaging
>>>
>>
>>
>>
>> --
>> Vanessa Villamia Sochat
>> Stanford University
>> (603) 321-0676
>>
>> _______________________________________________
>> 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
>
>


-- 
Vanessa Villamia Sochat
Stanford University
(603) 321-0676
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150727/dc169971/attachment.html>

From vsochat at stanford.edu  Mon Jul 27 17:59:47 2015
From: vsochat at stanford.edu (vanessa sochat)
Date: Mon, 27 Jul 2015 08:59:47 -0700
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <CAM=pu++DL13+mv8JuQDJeg-6Eszc4npXEmc4GxXcyF_LTJx=Xg@mail.gmail.com>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CAM=pu+J6K7fe3aEs7RyZ9_ecNf=SJUTNNJzX2FzVq2HAd3ne7Q@mail.gmail.com>
 <20150727052501.GB550510@phare.normalesup.org>
 <CAM=pu+LhN0=gksP+72r4u7-MNrMMN144XbJiawYujE8hkJ5o+A@mail.gmail.com>
 <CA+X4w0yr0kXgBL9JkZSPXzX7SZUf5OQwZksKMso-g04TgLSCMQ@mail.gmail.com>
 <CAM=pu++DL13+mv8JuQDJeg-6Eszc4npXEmc4GxXcyF_LTJx=Xg@mail.gmail.com>
Message-ID: <CAM=pu++d1KsdCZWsvM1bNqxfvFAL_W6V9EBc_BuHzfTWJuPGiQ@mail.gmail.com>

And please keep me in the loop re: your meeting on Wednesday! I'll likely
do another chunk of work after you guys have had a chance to chat.

On Mon, Jul 27, 2015 at 8:57 AM, vanessa sochat <vsochat at stanford.edu>
wrote:

> Yes, of course! The current design generates the navigation and pages
> dynamically from this file:
>
> https://github.com/vsoch/nipy/blob/master/code/static/projects.tsv
>
> If there is nothing added beyond that, a standard template page is used
> for the package's page:
>
> https://github.com/vsoch/nipy/blob/master/code/templates/project.html
>
> but for custom stuffs, the user can add a template page with the same name
> as the markdown_tag variable, for example, here is nipype:
>
> https://github.com/vsoch/nipy/blob/master/code/templates/nipype.html
>
> And of course the front page content will be generated in this fashion as
> well.
>
>
>
> On Mon, Jul 27, 2015 at 8:53 AM, Ariel Rokem <arokem at gmail.com> wrote:
>
>>
>>
>> On Mon, Jul 27, 2015 at 5:54 AM, vanessa sochat <vsochat at stanford.edu>
>> wrote:
>>
>>> Having all packages nicely shown on the front page is a good idea - and
>>> I was thinking of having a nice visualization that would quickly show some
>>> stats next to each. I put the latest blob post mostly because I ran out of
>>> work time for the day. Is the old site living somewhere so I can take a
>>> look?
>>>
>>> Thanks so much for joining in the effort! For me, an important change
>> relative to the old page design is to allow the project list to change over
>> time and to allow people to easily advertise their neuroimaging-in-python
>> projects on this webpage. I would prefer not to have the list of projects
>> be statically enshrined into the design of the front page. If you can make
>> it organically change on the front page, that would be good.
>>
>>
>>> Ga?l - I completely agree about nilearn! I just copied the groups as is
>>> from the current page, and had I thought about this, probably would have
>>> questioned them.
>>>
>>> On Sun, Jul 26, 2015 at 10:25 PM, Gael Varoquaux <
>>> gael.varoquaux at normalesup.org> wrote:
>>>
>>>> Hi,
>>>>
>>>> Since it is the time to gives one opinion
>>>>
>>>> - I agree with Elefterios that I think it is a good thing to have a list
>>>>   of the projects on the front page. I liked how the old webpage did it
>>>>
>>>> - The snake-brain logo is great. We should have it on the front page.
>>>>
>>>> - Developper-oriented information should be less emphasized compared to
>>>>   user-oriented information: 'view on github', 'contribute', 'A natural
>>>>   home for collaboration' should be deemphasized compared to the project
>>>>   directory. The reason is that we are trying to convince people to use
>>>>   the nipy ecosystem, and for this, the highest priority is to orient
>>>>   end users.
>>>>
>>>> My 2 cents,
>>>>
>>>> Ga?l
>>>>
>>>> PS: Vanessa: Nilearn is not only for fMRI. It's for statistical analysis
>>>> of images. It is also used for anatomical images:
>>>> http://nilearn.github.io/auto_examples/decoding/plot_oasis_vbm.html
>>>> If we could get a preprocessed, openly downloadable set of images of eg
>>>> FA, we would do an example with diffusion too.
>>>> _______________________________________________
>>>> Neuroimaging mailing list
>>>> Neuroimaging at python.org
>>>> https://mail.python.org/mailman/listinfo/neuroimaging
>>>>
>>>
>>>
>>>
>>> --
>>> Vanessa Villamia Sochat
>>> Stanford University
>>> (603) 321-0676
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
>
> --
> Vanessa Villamia Sochat
> Stanford University
> (603) 321-0676
>



-- 
Vanessa Villamia Sochat
Stanford University
(603) 321-0676
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150727/7790232e/attachment.html>

From arokem at gmail.com  Mon Jul 27 18:15:42 2015
From: arokem at gmail.com (Ariel Rokem)
Date: Mon, 27 Jul 2015 09:15:42 -0700
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <CAM=pu++d1KsdCZWsvM1bNqxfvFAL_W6V9EBc_BuHzfTWJuPGiQ@mail.gmail.com>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CAM=pu+J6K7fe3aEs7RyZ9_ecNf=SJUTNNJzX2FzVq2HAd3ne7Q@mail.gmail.com>
 <20150727052501.GB550510@phare.normalesup.org>
 <CAM=pu+LhN0=gksP+72r4u7-MNrMMN144XbJiawYujE8hkJ5o+A@mail.gmail.com>
 <CA+X4w0yr0kXgBL9JkZSPXzX7SZUf5OQwZksKMso-g04TgLSCMQ@mail.gmail.com>
 <CAM=pu++DL13+mv8JuQDJeg-6Eszc4npXEmc4GxXcyF_LTJx=Xg@mail.gmail.com>
 <CAM=pu++d1KsdCZWsvM1bNqxfvFAL_W6V9EBc_BuHzfTWJuPGiQ@mail.gmail.com>
Message-ID: <CA+X4w0zVBE-OxuijiU_DkkeMos7rNB7L+6CGfQAD_VCDAFuoxg@mail.gmail.com>

On Mon, Jul 27, 2015 at 8:59 AM, vanessa sochat <vsochat at stanford.edu>
wrote:

> And please keep me in the loop re: your meeting on Wednesday! I'll likely
> do another chunk of work after you guys have had a chance to chat.
>

That was just a suggestion Eleftherios made. I can't meet this Wednesday,
and I think that we are making better progress working on this together on
the mailing list. I don't think there's anything to meet about at this
point.


> On Mon, Jul 27, 2015 at 8:57 AM, vanessa sochat <vsochat at stanford.edu>
> wrote:
>
>> Yes, of course! The current design generates the navigation and pages
>> dynamically from this file:
>>
>> https://github.com/vsoch/nipy/blob/master/code/static/projects.tsv
>>
>> If there is nothing added beyond that, a standard template page is used
>> for the package's page:
>>
>> https://github.com/vsoch/nipy/blob/master/code/templates/project.html
>>
>> but for custom stuffs, the user can add a template page with the same
>> name as the markdown_tag variable, for example, here is nipype:
>>
>> https://github.com/vsoch/nipy/blob/master/code/templates/nipype.html
>>
>> And of course the front page content will be generated in this fashion as
>> well.
>>
>>
>>
>> On Mon, Jul 27, 2015 at 8:53 AM, Ariel Rokem <arokem at gmail.com> wrote:
>>
>>>
>>>
>>> On Mon, Jul 27, 2015 at 5:54 AM, vanessa sochat <vsochat at stanford.edu>
>>> wrote:
>>>
>>>> Having all packages nicely shown on the front page is a good idea - and
>>>> I was thinking of having a nice visualization that would quickly show some
>>>> stats next to each. I put the latest blob post mostly because I ran out of
>>>> work time for the day. Is the old site living somewhere so I can take a
>>>> look?
>>>>
>>>> Thanks so much for joining in the effort! For me, an important change
>>> relative to the old page design is to allow the project list to change over
>>> time and to allow people to easily advertise their neuroimaging-in-python
>>> projects on this webpage. I would prefer not to have the list of projects
>>> be statically enshrined into the design of the front page. If you can make
>>> it organically change on the front page, that would be good.
>>>
>>>
>>>> Ga?l - I completely agree about nilearn! I just copied the groups as is
>>>> from the current page, and had I thought about this, probably would have
>>>> questioned them.
>>>>
>>>> On Sun, Jul 26, 2015 at 10:25 PM, Gael Varoquaux <
>>>> gael.varoquaux at normalesup.org> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Since it is the time to gives one opinion
>>>>>
>>>>> - I agree with Elefterios that I think it is a good thing to have a
>>>>> list
>>>>>   of the projects on the front page. I liked how the old webpage did it
>>>>>
>>>>> - The snake-brain logo is great. We should have it on the front page.
>>>>>
>>>>> - Developper-oriented information should be less emphasized compared to
>>>>>   user-oriented information: 'view on github', 'contribute', 'A natural
>>>>>   home for collaboration' should be deemphasized compared to the
>>>>> project
>>>>>   directory. The reason is that we are trying to convince people to use
>>>>>   the nipy ecosystem, and for this, the highest priority is to orient
>>>>>   end users.
>>>>>
>>>>> My 2 cents,
>>>>>
>>>>> Ga?l
>>>>>
>>>>> PS: Vanessa: Nilearn is not only for fMRI. It's for statistical
>>>>> analysis
>>>>> of images. It is also used for anatomical images:
>>>>> http://nilearn.github.io/auto_examples/decoding/plot_oasis_vbm.html
>>>>> If we could get a preprocessed, openly downloadable set of images of eg
>>>>> FA, we would do an example with diffusion too.
>>>>> _______________________________________________
>>>>> Neuroimaging mailing list
>>>>> Neuroimaging at python.org
>>>>> https://mail.python.org/mailman/listinfo/neuroimaging
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Vanessa Villamia Sochat
>>>> Stanford University
>>>> (603) 321-0676
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>
>>
>> --
>> Vanessa Villamia Sochat
>> Stanford University
>> (603) 321-0676
>>
>
>
>
> --
> Vanessa Villamia Sochat
> Stanford University
> (603) 321-0676
>
> _______________________________________________
> 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/20150727/fb7bfb66/attachment.html>

From vsochat at stanford.edu  Mon Jul 27 18:23:56 2015
From: vsochat at stanford.edu (vanessa sochat)
Date: Mon, 27 Jul 2015 09:23:56 -0700
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <CA+X4w0zVBE-OxuijiU_DkkeMos7rNB7L+6CGfQAD_VCDAFuoxg@mail.gmail.com>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CAM=pu+J6K7fe3aEs7RyZ9_ecNf=SJUTNNJzX2FzVq2HAd3ne7Q@mail.gmail.com>
 <20150727052501.GB550510@phare.normalesup.org>
 <CAM=pu+LhN0=gksP+72r4u7-MNrMMN144XbJiawYujE8hkJ5o+A@mail.gmail.com>
 <CA+X4w0yr0kXgBL9JkZSPXzX7SZUf5OQwZksKMso-g04TgLSCMQ@mail.gmail.com>
 <CAM=pu++DL13+mv8JuQDJeg-6Eszc4npXEmc4GxXcyF_LTJx=Xg@mail.gmail.com>
 <CAM=pu++d1KsdCZWsvM1bNqxfvFAL_W6V9EBc_BuHzfTWJuPGiQ@mail.gmail.com>
 <CA+X4w0zVBE-OxuijiU_DkkeMos7rNB7L+6CGfQAD_VCDAFuoxg@mail.gmail.com>
Message-ID: <CAM=pu+L7mRDtZ1anyFBg-QzE7QZ_b9JYufP-Lfc31c7VTeizwQ@mail.gmail.com>

ok, werd! I'll just keep going at it then, I have a nice little list of
issues that I want to fix, and feel free to add anything you think of.

On Mon, Jul 27, 2015 at 9:15 AM, Ariel Rokem <arokem at gmail.com> wrote:

> On Mon, Jul 27, 2015 at 8:59 AM, vanessa sochat <vsochat at stanford.edu>
> wrote:
>
>> And please keep me in the loop re: your meeting on Wednesday! I'll likely
>> do another chunk of work after you guys have had a chance to chat.
>>
>
> That was just a suggestion Eleftherios made. I can't meet this Wednesday,
> and I think that we are making better progress working on this together on
> the mailing list. I don't think there's anything to meet about at this
> point.
>
>
>> On Mon, Jul 27, 2015 at 8:57 AM, vanessa sochat <vsochat at stanford.edu>
>> wrote:
>>
>>> Yes, of course! The current design generates the navigation and pages
>>> dynamically from this file:
>>>
>>> https://github.com/vsoch/nipy/blob/master/code/static/projects.tsv
>>>
>>> If there is nothing added beyond that, a standard template page is used
>>> for the package's page:
>>>
>>> https://github.com/vsoch/nipy/blob/master/code/templates/project.html
>>>
>>> but for custom stuffs, the user can add a template page with the same
>>> name as the markdown_tag variable, for example, here is nipype:
>>>
>>> https://github.com/vsoch/nipy/blob/master/code/templates/nipype.html
>>>
>>> And of course the front page content will be generated in this fashion
>>> as well.
>>>
>>>
>>>
>>> On Mon, Jul 27, 2015 at 8:53 AM, Ariel Rokem <arokem at gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Jul 27, 2015 at 5:54 AM, vanessa sochat <vsochat at stanford.edu>
>>>> wrote:
>>>>
>>>>> Having all packages nicely shown on the front page is a good idea -
>>>>> and I was thinking of having a nice visualization that would quickly show
>>>>> some stats next to each. I put the latest blob post mostly because I ran
>>>>> out of work time for the day. Is the old site living somewhere so I can
>>>>> take a look?
>>>>>
>>>>> Thanks so much for joining in the effort! For me, an important change
>>>> relative to the old page design is to allow the project list to change over
>>>> time and to allow people to easily advertise their neuroimaging-in-python
>>>> projects on this webpage. I would prefer not to have the list of projects
>>>> be statically enshrined into the design of the front page. If you can make
>>>> it organically change on the front page, that would be good.
>>>>
>>>>
>>>>> Ga?l - I completely agree about nilearn! I just copied the groups as
>>>>> is from the current page, and had I thought about this, probably would have
>>>>> questioned them.
>>>>>
>>>>> On Sun, Jul 26, 2015 at 10:25 PM, Gael Varoquaux <
>>>>> gael.varoquaux at normalesup.org> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Since it is the time to gives one opinion
>>>>>>
>>>>>> - I agree with Elefterios that I think it is a good thing to have a
>>>>>> list
>>>>>>   of the projects on the front page. I liked how the old webpage did
>>>>>> it
>>>>>>
>>>>>> - The snake-brain logo is great. We should have it on the front page.
>>>>>>
>>>>>> - Developper-oriented information should be less emphasized compared
>>>>>> to
>>>>>>   user-oriented information: 'view on github', 'contribute', 'A
>>>>>> natural
>>>>>>   home for collaboration' should be deemphasized compared to the
>>>>>> project
>>>>>>   directory. The reason is that we are trying to convince people to
>>>>>> use
>>>>>>   the nipy ecosystem, and for this, the highest priority is to orient
>>>>>>   end users.
>>>>>>
>>>>>> My 2 cents,
>>>>>>
>>>>>> Ga?l
>>>>>>
>>>>>> PS: Vanessa: Nilearn is not only for fMRI. It's for statistical
>>>>>> analysis
>>>>>> of images. It is also used for anatomical images:
>>>>>> http://nilearn.github.io/auto_examples/decoding/plot_oasis_vbm.html
>>>>>> If we could get a preprocessed, openly downloadable set of images of
>>>>>> eg
>>>>>> FA, we would do an example with diffusion too.
>>>>>> _______________________________________________
>>>>>> Neuroimaging mailing list
>>>>>> Neuroimaging at python.org
>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Vanessa Villamia Sochat
>>>>> Stanford University
>>>>> (603) 321-0676
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>>
>>>
>>>
>>> --
>>> Vanessa Villamia Sochat
>>> Stanford University
>>> (603) 321-0676
>>>
>>
>>
>>
>> --
>> Vanessa Villamia Sochat
>> Stanford University
>> (603) 321-0676
>>
>> _______________________________________________
>> 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
>
>


-- 
Vanessa Villamia Sochat
Stanford University
(603) 321-0676
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150727/2fdaa9eb/attachment-0001.html>

From arokem at gmail.com  Mon Jul 27 18:24:59 2015
From: arokem at gmail.com (Ariel Rokem)
Date: Mon, 27 Jul 2015 09:24:59 -0700
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <CAM=pu++DL13+mv8JuQDJeg-6Eszc4npXEmc4GxXcyF_LTJx=Xg@mail.gmail.com>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CAM=pu+J6K7fe3aEs7RyZ9_ecNf=SJUTNNJzX2FzVq2HAd3ne7Q@mail.gmail.com>
 <20150727052501.GB550510@phare.normalesup.org>
 <CAM=pu+LhN0=gksP+72r4u7-MNrMMN144XbJiawYujE8hkJ5o+A@mail.gmail.com>
 <CA+X4w0yr0kXgBL9JkZSPXzX7SZUf5OQwZksKMso-g04TgLSCMQ@mail.gmail.com>
 <CAM=pu++DL13+mv8JuQDJeg-6Eszc4npXEmc4GxXcyF_LTJx=Xg@mail.gmail.com>
Message-ID: <CA+X4w0yi7kKOxmSZSJTYD-5B8TL8EQE1mPH_mAJ=0eTFqSbeZQ@mail.gmail.com>

On Mon, Jul 27, 2015 at 8:57 AM, vanessa sochat <vsochat at stanford.edu>
wrote:

> Yes, of course! The current design generates the navigation and pages
> dynamically from this file:
>
> https://github.com/vsoch/nipy/blob/master/code/static/projects.tsv
>
> If there is nothing added beyond that, a standard template page is used
> for the package's page:
>
> https://github.com/vsoch/nipy/blob/master/code/templates/project.html
>
> but for custom stuffs, the user can add a template page with the same name
> as the markdown_tag variable, for example, here is nipype:
>
> https://github.com/vsoch/nipy/blob/master/code/templates/nipype.html
>
> And of course the front page content will be generated in this fashion as
> well.
>

That design is very elegant (in my opinion). Nice work! Even the
brain-snake is back, to everyone's relief.

How are you planning to serve this up? Is there a way to do this
automatically through github? Any way to review the rendered website on PRs
before they are merged upstream?


> On Mon, Jul 27, 2015 at 8:53 AM, Ariel Rokem <arokem at gmail.com> wrote:
>
>>
>>
>> On Mon, Jul 27, 2015 at 5:54 AM, vanessa sochat <vsochat at stanford.edu>
>> wrote:
>>
>>> Having all packages nicely shown on the front page is a good idea - and
>>> I was thinking of having a nice visualization that would quickly show some
>>> stats next to each. I put the latest blob post mostly because I ran out of
>>> work time for the day. Is the old site living somewhere so I can take a
>>> look?
>>>
>>> Thanks so much for joining in the effort! For me, an important change
>> relative to the old page design is to allow the project list to change over
>> time and to allow people to easily advertise their neuroimaging-in-python
>> projects on this webpage. I would prefer not to have the list of projects
>> be statically enshrined into the design of the front page. If you can make
>> it organically change on the front page, that would be good.
>>
>>
>>> Ga?l - I completely agree about nilearn! I just copied the groups as is
>>> from the current page, and had I thought about this, probably would have
>>> questioned them.
>>>
>>> On Sun, Jul 26, 2015 at 10:25 PM, Gael Varoquaux <
>>> gael.varoquaux at normalesup.org> wrote:
>>>
>>>> Hi,
>>>>
>>>> Since it is the time to gives one opinion
>>>>
>>>> - I agree with Elefterios that I think it is a good thing to have a list
>>>>   of the projects on the front page. I liked how the old webpage did it
>>>>
>>>> - The snake-brain logo is great. We should have it on the front page.
>>>>
>>>> - Developper-oriented information should be less emphasized compared to
>>>>   user-oriented information: 'view on github', 'contribute', 'A natural
>>>>   home for collaboration' should be deemphasized compared to the project
>>>>   directory. The reason is that we are trying to convince people to use
>>>>   the nipy ecosystem, and for this, the highest priority is to orient
>>>>   end users.
>>>>
>>>> My 2 cents,
>>>>
>>>> Ga?l
>>>>
>>>> PS: Vanessa: Nilearn is not only for fMRI. It's for statistical analysis
>>>> of images. It is also used for anatomical images:
>>>> http://nilearn.github.io/auto_examples/decoding/plot_oasis_vbm.html
>>>> If we could get a preprocessed, openly downloadable set of images of eg
>>>> FA, we would do an example with diffusion too.
>>>> _______________________________________________
>>>> Neuroimaging mailing list
>>>> Neuroimaging at python.org
>>>> https://mail.python.org/mailman/listinfo/neuroimaging
>>>>
>>>
>>>
>>>
>>> --
>>> Vanessa Villamia Sochat
>>> Stanford University
>>> (603) 321-0676
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
>
> --
> Vanessa Villamia Sochat
> Stanford University
> (603) 321-0676
>
> _______________________________________________
> 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/20150727/98fd5f6b/attachment.html>

From vsochat at stanford.edu  Mon Jul 27 18:31:43 2015
From: vsochat at stanford.edu (vanessa sochat)
Date: Mon, 27 Jul 2015 09:31:43 -0700
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <CA+X4w0yi7kKOxmSZSJTYD-5B8TL8EQE1mPH_mAJ=0eTFqSbeZQ@mail.gmail.com>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CAM=pu+J6K7fe3aEs7RyZ9_ecNf=SJUTNNJzX2FzVq2HAd3ne7Q@mail.gmail.com>
 <20150727052501.GB550510@phare.normalesup.org>
 <CAM=pu+LhN0=gksP+72r4u7-MNrMMN144XbJiawYujE8hkJ5o+A@mail.gmail.com>
 <CA+X4w0yr0kXgBL9JkZSPXzX7SZUf5OQwZksKMso-g04TgLSCMQ@mail.gmail.com>
 <CAM=pu++DL13+mv8JuQDJeg-6Eszc4npXEmc4GxXcyF_LTJx=Xg@mail.gmail.com>
 <CA+X4w0yi7kKOxmSZSJTYD-5B8TL8EQE1mPH_mAJ=0eTFqSbeZQ@mail.gmail.com>
Message-ID: <CAM=pu+Khcxp+1Kc_9J6-Ns3JL75qFQ07pVavfzBmZEXaMDPFVg@mail.gmail.com>

We can freeze the site into a static version for github pages:

https://pythonhosted.org/Frozen-Flask/

I have one function that takes the template name as a variable, so I'm
anticipating needing to write custom code to make sure those are generated
as well.

I'm sure there would be a way to review the rendered pages before
deploying. I don't know off the top of my head. I usually just try and
figure stuff out as I'm working on it!

On Mon, Jul 27, 2015 at 9:24 AM, Ariel Rokem <arokem at gmail.com> wrote:

>
>
> On Mon, Jul 27, 2015 at 8:57 AM, vanessa sochat <vsochat at stanford.edu>
> wrote:
>
>> Yes, of course! The current design generates the navigation and pages
>> dynamically from this file:
>>
>> https://github.com/vsoch/nipy/blob/master/code/static/projects.tsv
>>
>> If there is nothing added beyond that, a standard template page is used
>> for the package's page:
>>
>> https://github.com/vsoch/nipy/blob/master/code/templates/project.html
>>
>> but for custom stuffs, the user can add a template page with the same
>> name as the markdown_tag variable, for example, here is nipype:
>>
>> https://github.com/vsoch/nipy/blob/master/code/templates/nipype.html
>>
>> And of course the front page content will be generated in this fashion as
>> well.
>>
>
> That design is very elegant (in my opinion). Nice work! Even the
> brain-snake is back, to everyone's relief.
>
> How are you planning to serve this up? Is there a way to do this
> automatically through github? Any way to review the rendered website on PRs
> before they are merged upstream?
>
>
>> On Mon, Jul 27, 2015 at 8:53 AM, Ariel Rokem <arokem at gmail.com> wrote:
>>
>>>
>>>
>>> On Mon, Jul 27, 2015 at 5:54 AM, vanessa sochat <vsochat at stanford.edu>
>>> wrote:
>>>
>>>> Having all packages nicely shown on the front page is a good idea - and
>>>> I was thinking of having a nice visualization that would quickly show some
>>>> stats next to each. I put the latest blob post mostly because I ran out of
>>>> work time for the day. Is the old site living somewhere so I can take a
>>>> look?
>>>>
>>>> Thanks so much for joining in the effort! For me, an important change
>>> relative to the old page design is to allow the project list to change over
>>> time and to allow people to easily advertise their neuroimaging-in-python
>>> projects on this webpage. I would prefer not to have the list of projects
>>> be statically enshrined into the design of the front page. If you can make
>>> it organically change on the front page, that would be good.
>>>
>>>
>>>> Ga?l - I completely agree about nilearn! I just copied the groups as is
>>>> from the current page, and had I thought about this, probably would have
>>>> questioned them.
>>>>
>>>> On Sun, Jul 26, 2015 at 10:25 PM, Gael Varoquaux <
>>>> gael.varoquaux at normalesup.org> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Since it is the time to gives one opinion
>>>>>
>>>>> - I agree with Elefterios that I think it is a good thing to have a
>>>>> list
>>>>>   of the projects on the front page. I liked how the old webpage did it
>>>>>
>>>>> - The snake-brain logo is great. We should have it on the front page.
>>>>>
>>>>> - Developper-oriented information should be less emphasized compared to
>>>>>   user-oriented information: 'view on github', 'contribute', 'A natural
>>>>>   home for collaboration' should be deemphasized compared to the
>>>>> project
>>>>>   directory. The reason is that we are trying to convince people to use
>>>>>   the nipy ecosystem, and for this, the highest priority is to orient
>>>>>   end users.
>>>>>
>>>>> My 2 cents,
>>>>>
>>>>> Ga?l
>>>>>
>>>>> PS: Vanessa: Nilearn is not only for fMRI. It's for statistical
>>>>> analysis
>>>>> of images. It is also used for anatomical images:
>>>>> http://nilearn.github.io/auto_examples/decoding/plot_oasis_vbm.html
>>>>> If we could get a preprocessed, openly downloadable set of images of eg
>>>>> FA, we would do an example with diffusion too.
>>>>> _______________________________________________
>>>>> Neuroimaging mailing list
>>>>> Neuroimaging at python.org
>>>>> https://mail.python.org/mailman/listinfo/neuroimaging
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Vanessa Villamia Sochat
>>>> Stanford University
>>>> (603) 321-0676
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>
>>
>> --
>> Vanessa Villamia Sochat
>> Stanford University
>> (603) 321-0676
>>
>> _______________________________________________
>> 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
>
>


-- 
Vanessa Villamia Sochat
Stanford University
(603) 321-0676
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150727/60354b86/attachment.html>

From gael.varoquaux at normalesup.org  Mon Jul 27 19:44:26 2015
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Mon, 27 Jul 2015 19:44:26 +0200
Subject: [Neuroimaging] FA images Was: Nipy.org new website needs a complete
	remake
In-Reply-To: <CA+X4w0z-WpsKk0gBu9pmoaDVCDFZyHQfWLtNokFtJURWGFRCuQ@mail.gmail.com>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CAM=pu+J6K7fe3aEs7RyZ9_ecNf=SJUTNNJzX2FzVq2HAd3ne7Q@mail.gmail.com>
 <20150727052501.GB550510@phare.normalesup.org>
 <CA+X4w0z-WpsKk0gBu9pmoaDVCDFZyHQfWLtNokFtJURWGFRCuQ@mail.gmail.com>
Message-ID: <20150727174426.GW705713@phare.normalesup.org>

On Mon, Jul 27, 2015 at 08:56:08AM -0700, Ariel Rokem wrote:
>     PS: Vanessa: Nilearn is not only for fMRI. It's for statistical analysis
>     of images. It is also used for anatomical images:
>     http://nilearn.github.io/auto_examples/decoding/plot_oasis_vbm.html
>     If we could get a preprocessed, openly downloadable set of images of eg
>     FA, we would do an example with diffusion too.

> Completely off-topic, but I can't resist: if only there was an
> open-source project that computed FA images from freely available
> diffusion MRI data-sets!?

Well, you're welcome to help us with preprocessing and pitching a
relevant prediction problem from this data. I know nothing about
diffusion and nothing about the datasets you are talking about. In my
experience, writing a relevant example requires understanding the data
and the questions. If you, or someone else, gets us to the point where
there is a set of nifti images of FA with condition A and condition B,
and helps us write the story, than we have an example.

Ga?l

From vsochat at stanford.edu  Tue Jul 28 02:41:46 2015
From: vsochat at stanford.edu (vanessa sochat)
Date: Mon, 27 Jul 2015 17:41:46 -0700
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <CAM=pu+Khcxp+1Kc_9J6-Ns3JL75qFQ07pVavfzBmZEXaMDPFVg@mail.gmail.com>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CAM=pu+J6K7fe3aEs7RyZ9_ecNf=SJUTNNJzX2FzVq2HAd3ne7Q@mail.gmail.com>
 <20150727052501.GB550510@phare.normalesup.org>
 <CAM=pu+LhN0=gksP+72r4u7-MNrMMN144XbJiawYujE8hkJ5o+A@mail.gmail.com>
 <CA+X4w0yr0kXgBL9JkZSPXzX7SZUf5OQwZksKMso-g04TgLSCMQ@mail.gmail.com>
 <CAM=pu++DL13+mv8JuQDJeg-6Eszc4npXEmc4GxXcyF_LTJx=Xg@mail.gmail.com>
 <CA+X4w0yi7kKOxmSZSJTYD-5B8TL8EQE1mPH_mAJ=0eTFqSbeZQ@mail.gmail.com>
 <CAM=pu+Khcxp+1Kc_9J6-Ns3JL75qFQ07pVavfzBmZEXaMDPFVg@mail.gmail.com>
Message-ID: <CAM=pu+KSjO_iaW-MrMwM_o_6xgZrsg2eEo1L6fL8ZJqUTLmMYg@mail.gmail.com>

ok, simple addition of projects to the front page:

http://www.vbmis.com/bmi/project/nipy/

On Mon, Jul 27, 2015 at 9:31 AM, vanessa sochat <vsochat at stanford.edu>
wrote:

> We can freeze the site into a static version for github pages:
>
> https://pythonhosted.org/Frozen-Flask/
>
> I have one function that takes the template name as a variable, so I'm
> anticipating needing to write custom code to make sure those are generated
> as well.
>
> I'm sure there would be a way to review the rendered pages before
> deploying. I don't know off the top of my head. I usually just try and
> figure stuff out as I'm working on it!
>
> On Mon, Jul 27, 2015 at 9:24 AM, Ariel Rokem <arokem at gmail.com> wrote:
>
>>
>>
>> On Mon, Jul 27, 2015 at 8:57 AM, vanessa sochat <vsochat at stanford.edu>
>> wrote:
>>
>>> Yes, of course! The current design generates the navigation and pages
>>> dynamically from this file:
>>>
>>> https://github.com/vsoch/nipy/blob/master/code/static/projects.tsv
>>>
>>> If there is nothing added beyond that, a standard template page is used
>>> for the package's page:
>>>
>>> https://github.com/vsoch/nipy/blob/master/code/templates/project.html
>>>
>>> but for custom stuffs, the user can add a template page with the same
>>> name as the markdown_tag variable, for example, here is nipype:
>>>
>>> https://github.com/vsoch/nipy/blob/master/code/templates/nipype.html
>>>
>>> And of course the front page content will be generated in this fashion
>>> as well.
>>>
>>
>> That design is very elegant (in my opinion). Nice work! Even the
>> brain-snake is back, to everyone's relief.
>>
>> How are you planning to serve this up? Is there a way to do this
>> automatically through github? Any way to review the rendered website on PRs
>> before they are merged upstream?
>>
>>
>>> On Mon, Jul 27, 2015 at 8:53 AM, Ariel Rokem <arokem at gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Jul 27, 2015 at 5:54 AM, vanessa sochat <vsochat at stanford.edu>
>>>> wrote:
>>>>
>>>>> Having all packages nicely shown on the front page is a good idea -
>>>>> and I was thinking of having a nice visualization that would quickly show
>>>>> some stats next to each. I put the latest blob post mostly because I ran
>>>>> out of work time for the day. Is the old site living somewhere so I can
>>>>> take a look?
>>>>>
>>>>> Thanks so much for joining in the effort! For me, an important change
>>>> relative to the old page design is to allow the project list to change over
>>>> time and to allow people to easily advertise their neuroimaging-in-python
>>>> projects on this webpage. I would prefer not to have the list of projects
>>>> be statically enshrined into the design of the front page. If you can make
>>>> it organically change on the front page, that would be good.
>>>>
>>>>
>>>>> Ga?l - I completely agree about nilearn! I just copied the groups as
>>>>> is from the current page, and had I thought about this, probably would have
>>>>> questioned them.
>>>>>
>>>>> On Sun, Jul 26, 2015 at 10:25 PM, Gael Varoquaux <
>>>>> gael.varoquaux at normalesup.org> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Since it is the time to gives one opinion
>>>>>>
>>>>>> - I agree with Elefterios that I think it is a good thing to have a
>>>>>> list
>>>>>>   of the projects on the front page. I liked how the old webpage did
>>>>>> it
>>>>>>
>>>>>> - The snake-brain logo is great. We should have it on the front page.
>>>>>>
>>>>>> - Developper-oriented information should be less emphasized compared
>>>>>> to
>>>>>>   user-oriented information: 'view on github', 'contribute', 'A
>>>>>> natural
>>>>>>   home for collaboration' should be deemphasized compared to the
>>>>>> project
>>>>>>   directory. The reason is that we are trying to convince people to
>>>>>> use
>>>>>>   the nipy ecosystem, and for this, the highest priority is to orient
>>>>>>   end users.
>>>>>>
>>>>>> My 2 cents,
>>>>>>
>>>>>> Ga?l
>>>>>>
>>>>>> PS: Vanessa: Nilearn is not only for fMRI. It's for statistical
>>>>>> analysis
>>>>>> of images. It is also used for anatomical images:
>>>>>> http://nilearn.github.io/auto_examples/decoding/plot_oasis_vbm.html
>>>>>> If we could get a preprocessed, openly downloadable set of images of
>>>>>> eg
>>>>>> FA, we would do an example with diffusion too.
>>>>>> _______________________________________________
>>>>>> Neuroimaging mailing list
>>>>>> Neuroimaging at python.org
>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Vanessa Villamia Sochat
>>>>> Stanford University
>>>>> (603) 321-0676
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>>
>>>
>>>
>>> --
>>> Vanessa Villamia Sochat
>>> Stanford University
>>> (603) 321-0676
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
>
> --
> Vanessa Villamia Sochat
> Stanford University
> (603) 321-0676
>



-- 
Vanessa Villamia Sochat
Stanford University
(603) 321-0676
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150727/b27b00b5/attachment.html>

From garyfallidis at gmail.com  Tue Jul 28 05:58:18 2015
From: garyfallidis at gmail.com (Eleftherios Garyfallidis)
Date: Mon, 27 Jul 2015 23:58:18 -0400
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <CAH6Pt5qMOjwq39UvitoXjEA6LydxmVkbJQN=cwFBgMZct-7U0A@mail.gmail.com>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CAM=pu+J6K7fe3aEs7RyZ9_ecNf=SJUTNNJzX2FzVq2HAd3ne7Q@mail.gmail.com>
 <20150727052501.GB550510@phare.normalesup.org>
 <CAH6Pt5qMOjwq39UvitoXjEA6LydxmVkbJQN=cwFBgMZct-7U0A@mail.gmail.com>
Message-ID: <CAN6JmWPYdp-6vYSJz=hJo+4_fRi4X7S5Oqox523mUT+YxZqumA@mail.gmail.com>

Hi,

On Mon, Jul 27, 2015 at 5:13 AM, Matthew Brett <matthew.brett at gmail.com>
wrote:

> Hi,
>
> On Mon, Jul 27, 2015 at 6:25 AM, Gael Varoquaux
> <gael.varoquaux at normalesup.org> wrote:
> > Hi,
> >
> > Since it is the time to gives one opinion
>
> Sorry to be quiet.
>
> I don't have strong feelings about whether the new or old website is
> better, but Ariel saved us from a lot of frustration by moving us to
> github pages before the recent Sourceforge meltdown [1].
>
>
Nobody is saying something different about that. This is irrelevant to the
point of the thread.
I very much appreciate Ariel's push and work on the gh-pages.


> Eleftherios - your main complaint against Jeykll is that it's hard to
> render the pages before you submit a PR?


No, Jeykill is great but Pelican is as as great and in Python and supports
both md and rst.
So, as this being a Python project I would give it a chance.


> I don't think it's that
> hard - see http://jekyllrb.com  . OK, it involves installing something
> in Ruby via gem, but that's not a major burden, and pelican is not
> trivial to set up either.
>
> Pelican is easy to setup at least this is my experience from trying it on
my machine.
I haven't played with Jekyll to see if Jekyll is easier in some way.


> For the content - I don't think it's reasonable to ask Ariel to make
> the changes, any more that it would be for code.


I am happy to change the content my self and I will do. But are we getting
a bit too
formal in our discussions? Is it bad to disagree if I don't like something
or ask for
changes?

If you think it
> could be done better, then please, make a PR, surely that will not be
> much work, and will give the best possible idea of what you would
> prefer.


Matthew, my hope was that at least first people would agree to give Pelican
or Sphinx
a chance. If there is no agreement on that I cannot go and make a PR like
that.

I will make PRs on the content but first I need to see what is the
vision/goal of the portal.
Which is missing from the current version of the website. But I see that
Vanessa
is actually improving the initial design a lot. When that is done it will
be easier for
me to contribute.

Cheers,
Eleftherios

Cheers,
>
> Matthew
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150727/0edd72e0/attachment.html>

From garyfallidis at gmail.com  Tue Jul 28 06:41:00 2015
From: garyfallidis at gmail.com (Eleftherios Garyfallidis)
Date: Tue, 28 Jul 2015 00:41:00 -0400
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <CAM=pu+KSjO_iaW-MrMwM_o_6xgZrsg2eEo1L6fL8ZJqUTLmMYg@mail.gmail.com>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CAM=pu+J6K7fe3aEs7RyZ9_ecNf=SJUTNNJzX2FzVq2HAd3ne7Q@mail.gmail.com>
 <20150727052501.GB550510@phare.normalesup.org>
 <CAM=pu+LhN0=gksP+72r4u7-MNrMMN144XbJiawYujE8hkJ5o+A@mail.gmail.com>
 <CA+X4w0yr0kXgBL9JkZSPXzX7SZUf5OQwZksKMso-g04TgLSCMQ@mail.gmail.com>
 <CAM=pu++DL13+mv8JuQDJeg-6Eszc4npXEmc4GxXcyF_LTJx=Xg@mail.gmail.com>
 <CA+X4w0yi7kKOxmSZSJTYD-5B8TL8EQE1mPH_mAJ=0eTFqSbeZQ@mail.gmail.com>
 <CAM=pu+Khcxp+1Kc_9J6-Ns3JL75qFQ07pVavfzBmZEXaMDPFVg@mail.gmail.com>
 <CAM=pu+KSjO_iaW-MrMwM_o_6xgZrsg2eEo1L6fL8ZJqUTLmMYg@mail.gmail.com>
Message-ID: <CAN6JmWP9rox4Gwu-AJvHXJGsD4Y=AAJmG3FSB62cf7WyzMzh+g@mail.gmail.com>

Hi Vanessa,

The website starts looking *much* better. Thank you for pushing forward
with this. And I am very happy that
the website is built with Flask now a Python tool!!! :)

When you have some time I would like to know why you selected Flask from
the list of static page generators
and if you have actually played with Pelican. By the way I am perfectly
happy with Flask. I just wanted to know
if you have looked into the differences and if there are some clear
advantages which I am not aware of.

Also, If now if I want for example to add a text button under the
nipy.gihub.io logo I will need to change the template right?
Are these templates generated automatically by jinja or another engine? Is
this easy to change the template with the current
design?

Thanks again!
:) :) :)

Best regards,
Eleftherios






On Mon, Jul 27, 2015 at 8:41 PM, vanessa sochat <vsochat at stanford.edu>
wrote:

> ok, simple addition of projects to the front page:
>
> http://www.vbmis.com/bmi/project/nipy/
>
> On Mon, Jul 27, 2015 at 9:31 AM, vanessa sochat <vsochat at stanford.edu>
> wrote:
>
>> We can freeze the site into a static version for github pages:
>>
>> https://pythonhosted.org/Frozen-Flask/
>>
>> I have one function that takes the template name as a variable, so I'm
>> anticipating needing to write custom code to make sure those are generated
>> as well.
>>
>> I'm sure there would be a way to review the rendered pages before
>> deploying. I don't know off the top of my head. I usually just try and
>> figure stuff out as I'm working on it!
>>
>> On Mon, Jul 27, 2015 at 9:24 AM, Ariel Rokem <arokem at gmail.com> wrote:
>>
>>>
>>>
>>> On Mon, Jul 27, 2015 at 8:57 AM, vanessa sochat <vsochat at stanford.edu>
>>> wrote:
>>>
>>>> Yes, of course! The current design generates the navigation and pages
>>>> dynamically from this file:
>>>>
>>>> https://github.com/vsoch/nipy/blob/master/code/static/projects.tsv
>>>>
>>>> If there is nothing added beyond that, a standard template page is used
>>>> for the package's page:
>>>>
>>>> https://github.com/vsoch/nipy/blob/master/code/templates/project.html
>>>>
>>>> but for custom stuffs, the user can add a template page with the same
>>>> name as the markdown_tag variable, for example, here is nipype:
>>>>
>>>> https://github.com/vsoch/nipy/blob/master/code/templates/nipype.html
>>>>
>>>> And of course the front page content will be generated in this fashion
>>>> as well.
>>>>
>>>
>>> That design is very elegant (in my opinion). Nice work! Even the
>>> brain-snake is back, to everyone's relief.
>>>
>>> How are you planning to serve this up? Is there a way to do this
>>> automatically through github? Any way to review the rendered website on PRs
>>> before they are merged upstream?
>>>
>>>
>>>> On Mon, Jul 27, 2015 at 8:53 AM, Ariel Rokem <arokem at gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Mon, Jul 27, 2015 at 5:54 AM, vanessa sochat <vsochat at stanford.edu>
>>>>> wrote:
>>>>>
>>>>>> Having all packages nicely shown on the front page is a good idea -
>>>>>> and I was thinking of having a nice visualization that would quickly show
>>>>>> some stats next to each. I put the latest blob post mostly because I ran
>>>>>> out of work time for the day. Is the old site living somewhere so I can
>>>>>> take a look?
>>>>>>
>>>>>> Thanks so much for joining in the effort! For me, an important change
>>>>> relative to the old page design is to allow the project list to change over
>>>>> time and to allow people to easily advertise their neuroimaging-in-python
>>>>> projects on this webpage. I would prefer not to have the list of projects
>>>>> be statically enshrined into the design of the front page. If you can make
>>>>> it organically change on the front page, that would be good.
>>>>>
>>>>>
>>>>>> Ga?l - I completely agree about nilearn! I just copied the groups as
>>>>>> is from the current page, and had I thought about this, probably would have
>>>>>> questioned them.
>>>>>>
>>>>>> On Sun, Jul 26, 2015 at 10:25 PM, Gael Varoquaux <
>>>>>> gael.varoquaux at normalesup.org> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Since it is the time to gives one opinion
>>>>>>>
>>>>>>> - I agree with Elefterios that I think it is a good thing to have a
>>>>>>> list
>>>>>>>   of the projects on the front page. I liked how the old webpage did
>>>>>>> it
>>>>>>>
>>>>>>> - The snake-brain logo is great. We should have it on the front page.
>>>>>>>
>>>>>>> - Developper-oriented information should be less emphasized compared
>>>>>>> to
>>>>>>>   user-oriented information: 'view on github', 'contribute', 'A
>>>>>>> natural
>>>>>>>   home for collaboration' should be deemphasized compared to the
>>>>>>> project
>>>>>>>   directory. The reason is that we are trying to convince people to
>>>>>>> use
>>>>>>>   the nipy ecosystem, and for this, the highest priority is to orient
>>>>>>>   end users.
>>>>>>>
>>>>>>> My 2 cents,
>>>>>>>
>>>>>>> Ga?l
>>>>>>>
>>>>>>> PS: Vanessa: Nilearn is not only for fMRI. It's for statistical
>>>>>>> analysis
>>>>>>> of images. It is also used for anatomical images:
>>>>>>> http://nilearn.github.io/auto_examples/decoding/plot_oasis_vbm.html
>>>>>>> If we could get a preprocessed, openly downloadable set of images of
>>>>>>> eg
>>>>>>> FA, we would do an example with diffusion too.
>>>>>>> _______________________________________________
>>>>>>> Neuroimaging mailing list
>>>>>>> Neuroimaging at python.org
>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Vanessa Villamia Sochat
>>>>>> Stanford University
>>>>>> (603) 321-0676
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Vanessa Villamia Sochat
>>>> Stanford University
>>>> (603) 321-0676
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>
>>
>> --
>> Vanessa Villamia Sochat
>> Stanford University
>> (603) 321-0676
>>
>
>
>
> --
> Vanessa Villamia Sochat
> Stanford University
> (603) 321-0676
>
> _______________________________________________
> 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/20150728/14e73f4e/attachment-0001.html>

From vsochat at stanford.edu  Tue Jul 28 06:51:22 2015
From: vsochat at stanford.edu (vanessa sochat)
Date: Mon, 27 Jul 2015 21:51:22 -0700
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <CAN6JmWP9rox4Gwu-AJvHXJGsD4Y=AAJmG3FSB62cf7WyzMzh+g@mail.gmail.com>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CAM=pu+J6K7fe3aEs7RyZ9_ecNf=SJUTNNJzX2FzVq2HAd3ne7Q@mail.gmail.com>
 <20150727052501.GB550510@phare.normalesup.org>
 <CAM=pu+LhN0=gksP+72r4u7-MNrMMN144XbJiawYujE8hkJ5o+A@mail.gmail.com>
 <CA+X4w0yr0kXgBL9JkZSPXzX7SZUf5OQwZksKMso-g04TgLSCMQ@mail.gmail.com>
 <CAM=pu++DL13+mv8JuQDJeg-6Eszc4npXEmc4GxXcyF_LTJx=Xg@mail.gmail.com>
 <CA+X4w0yi7kKOxmSZSJTYD-5B8TL8EQE1mPH_mAJ=0eTFqSbeZQ@mail.gmail.com>
 <CAM=pu+Khcxp+1Kc_9J6-Ns3JL75qFQ07pVavfzBmZEXaMDPFVg@mail.gmail.com>
 <CAM=pu+KSjO_iaW-MrMwM_o_6xgZrsg2eEo1L6fL8ZJqUTLmMYg@mail.gmail.com>
 <CAN6JmWP9rox4Gwu-AJvHXJGsD4Y=AAJmG3FSB62cf7WyzMzh+g@mail.gmail.com>
Message-ID: <CAM=pu+JLntOr8Rwi5KwAKbCom9Agb8jEW4-Rkr6mS6X8J+J0eQ@mail.gmail.com>

Hi Eleftherios,

I chose flask because I love using it, and it made sense given that all
these packages are in python. I probably would enjoy some of the other
generators just as much, and in fact a backup plan is to port the entire
thing to a different one if the "freezing" process runs into trouble. To be
honest, I have tried jekyll and thought it was kind of annoying. I'd
probably still give it another go if someone really wanted it. I've never
looked at Pelican - I will check it out!

To answer your question - yes - any changes to the "main" pages that aren't
rendered dynamically (the projects) would be a change to the main template,
in this case index.html as it extends base.html (which has the navigation,
brain on the side, etc). It's all jinja templates, which is another reason
it would be easy to move the design around.

I'm likely going to do the freezing testing this weekend (it's hard to do
long work sessions during the week as I am still doing this graduate school
thing) and hopefully we will know for sure if this will be a good solution
early next week. I will keep you updated, of course.

Best,

Vanessa

On Mon, Jul 27, 2015 at 9:41 PM, Eleftherios Garyfallidis <
garyfallidis at gmail.com> wrote:

> Hi Vanessa,
>
> The website starts looking *much* better. Thank you for pushing forward
> with this. And I am very happy that
> the website is built with Flask now a Python tool!!! :)
>
> When you have some time I would like to know why you selected Flask from
> the list of static page generators
> and if you have actually played with Pelican. By the way I am perfectly
> happy with Flask. I just wanted to know
> if you have looked into the differences and if there are some clear
> advantages which I am not aware of.
>
> Also, If now if I want for example to add a text button under the
> nipy.gihub.io logo I will need to change the template right?
> Are these templates generated automatically by jinja or another engine? Is
> this easy to change the template with the current
> design?
>
> Thanks again!
> :) :) :)
>
> Best regards,
> Eleftherios
>
>
>
>
>
>
> On Mon, Jul 27, 2015 at 8:41 PM, vanessa sochat <vsochat at stanford.edu>
> wrote:
>
>> ok, simple addition of projects to the front page:
>>
>> http://www.vbmis.com/bmi/project/nipy/
>>
>> On Mon, Jul 27, 2015 at 9:31 AM, vanessa sochat <vsochat at stanford.edu>
>> wrote:
>>
>>> We can freeze the site into a static version for github pages:
>>>
>>> https://pythonhosted.org/Frozen-Flask/
>>>
>>> I have one function that takes the template name as a variable, so I'm
>>> anticipating needing to write custom code to make sure those are generated
>>> as well.
>>>
>>> I'm sure there would be a way to review the rendered pages before
>>> deploying. I don't know off the top of my head. I usually just try and
>>> figure stuff out as I'm working on it!
>>>
>>> On Mon, Jul 27, 2015 at 9:24 AM, Ariel Rokem <arokem at gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Jul 27, 2015 at 8:57 AM, vanessa sochat <vsochat at stanford.edu>
>>>> wrote:
>>>>
>>>>> Yes, of course! The current design generates the navigation and pages
>>>>> dynamically from this file:
>>>>>
>>>>> https://github.com/vsoch/nipy/blob/master/code/static/projects.tsv
>>>>>
>>>>> If there is nothing added beyond that, a standard template page is
>>>>> used for the package's page:
>>>>>
>>>>> https://github.com/vsoch/nipy/blob/master/code/templates/project.html
>>>>>
>>>>> but for custom stuffs, the user can add a template page with the same
>>>>> name as the markdown_tag variable, for example, here is nipype:
>>>>>
>>>>> https://github.com/vsoch/nipy/blob/master/code/templates/nipype.html
>>>>>
>>>>> And of course the front page content will be generated in this fashion
>>>>> as well.
>>>>>
>>>>
>>>> That design is very elegant (in my opinion). Nice work! Even the
>>>> brain-snake is back, to everyone's relief.
>>>>
>>>> How are you planning to serve this up? Is there a way to do this
>>>> automatically through github? Any way to review the rendered website on PRs
>>>> before they are merged upstream?
>>>>
>>>>
>>>>> On Mon, Jul 27, 2015 at 8:53 AM, Ariel Rokem <arokem at gmail.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Jul 27, 2015 at 5:54 AM, vanessa sochat <vsochat at stanford.edu
>>>>>> > wrote:
>>>>>>
>>>>>>> Having all packages nicely shown on the front page is a good idea -
>>>>>>> and I was thinking of having a nice visualization that would quickly show
>>>>>>> some stats next to each. I put the latest blob post mostly because I ran
>>>>>>> out of work time for the day. Is the old site living somewhere so I can
>>>>>>> take a look?
>>>>>>>
>>>>>>> Thanks so much for joining in the effort! For me, an important
>>>>>> change relative to the old page design is to allow the project list to
>>>>>> change over time and to allow people to easily advertise their
>>>>>> neuroimaging-in-python projects on this webpage. I would prefer not to have
>>>>>> the list of projects be statically enshrined into the design of the front
>>>>>> page. If you can make it organically change on the front page, that would
>>>>>> be good.
>>>>>>
>>>>>>
>>>>>>> Ga?l - I completely agree about nilearn! I just copied the groups as
>>>>>>> is from the current page, and had I thought about this, probably would have
>>>>>>> questioned them.
>>>>>>>
>>>>>>> On Sun, Jul 26, 2015 at 10:25 PM, Gael Varoquaux <
>>>>>>> gael.varoquaux at normalesup.org> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Since it is the time to gives one opinion
>>>>>>>>
>>>>>>>> - I agree with Elefterios that I think it is a good thing to have a
>>>>>>>> list
>>>>>>>>   of the projects on the front page. I liked how the old webpage
>>>>>>>> did it
>>>>>>>>
>>>>>>>> - The snake-brain logo is great. We should have it on the front
>>>>>>>> page.
>>>>>>>>
>>>>>>>> - Developper-oriented information should be less emphasized
>>>>>>>> compared to
>>>>>>>>   user-oriented information: 'view on github', 'contribute', 'A
>>>>>>>> natural
>>>>>>>>   home for collaboration' should be deemphasized compared to the
>>>>>>>> project
>>>>>>>>   directory. The reason is that we are trying to convince people to
>>>>>>>> use
>>>>>>>>   the nipy ecosystem, and for this, the highest priority is to
>>>>>>>> orient
>>>>>>>>   end users.
>>>>>>>>
>>>>>>>> My 2 cents,
>>>>>>>>
>>>>>>>> Ga?l
>>>>>>>>
>>>>>>>> PS: Vanessa: Nilearn is not only for fMRI. It's for statistical
>>>>>>>> analysis
>>>>>>>> of images. It is also used for anatomical images:
>>>>>>>> http://nilearn.github.io/auto_examples/decoding/plot_oasis_vbm.html
>>>>>>>> If we could get a preprocessed, openly downloadable set of images
>>>>>>>> of eg
>>>>>>>> FA, we would do an example with diffusion too.
>>>>>>>> _______________________________________________
>>>>>>>> Neuroimaging mailing list
>>>>>>>> Neuroimaging at python.org
>>>>>>>> https://mail.python.org/mailman/listinfo/neuroimaging
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Vanessa Villamia Sochat
>>>>>>> Stanford University
>>>>>>> (603) 321-0676
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Vanessa Villamia Sochat
>>>>> Stanford University
>>>>> (603) 321-0676
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>>
>>>
>>>
>>> --
>>> Vanessa Villamia Sochat
>>> Stanford University
>>> (603) 321-0676
>>>
>>
>>
>>
>> --
>> Vanessa Villamia Sochat
>> Stanford University
>> (603) 321-0676
>>
>> _______________________________________________
>> 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
>
>


-- 
Vanessa Villamia Sochat
Stanford University
(603) 321-0676
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150727/8243c78f/attachment.html>

From vsochat at gmail.com  Mon Jul 27 15:25:57 2015
From: vsochat at gmail.com (Vanessa)
Date: Mon, 27 Jul 2015 06:25:57 -0700
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <CAH6Pt5rfPGe0dBKfoiXSxwQMj6SrBK=xDtB1FE6kGxXWE8UYKw@mail.gmail.com>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CAM=pu+J6K7fe3aEs7RyZ9_ecNf=SJUTNNJzX2FzVq2HAd3ne7Q@mail.gmail.com>
 <20150727052501.GB550510@phare.normalesup.org>
 <CAM=pu+LhN0=gksP+72r4u7-MNrMMN144XbJiawYujE8hkJ5o+A@mail.gmail.com>
 <CAH6Pt5rfPGe0dBKfoiXSxwQMj6SrBK=xDtB1FE6kGxXWE8UYKw@mail.gmail.com>
Message-ID: <FDCD482B-C717-4ED3-BFE7-B8E0F7FED469@gmail.com>

Thanks :o)

Best,

Vanessa

> On Jul 27, 2015, at 6:00 AM, Matthew Brett <matthew.brett at gmail.com> wrote:
> 
> Hi,
> 
>> On Mon, Jul 27, 2015 at 1:54 PM, vanessa sochat <vsochat at stanford.edu> wrote:
>> Having all packages nicely shown on the front page is a good idea - and I
>> was thinking of having a nice visualization that would quickly show some
>> stats next to each. I put the latest blob post mostly because I ran out of
>> work time for the day. Is the old site living somewhere so I can take a
>> look?
> 
> The old website is at https://github.com/nipy/nipyco
> 
> Thanks for your help on this, it would be very good to get more
> feedback on the web design.
> 
> Cheers,
> 
> Matthew
> _______________________________________________
> Neuroimaging mailing list
> Neuroimaging at python.org
> https://mail.python.org/mailman/listinfo/neuroimaging

From arokem at gmail.com  Tue Jul 28 17:43:40 2015
From: arokem at gmail.com (Ariel Rokem)
Date: Tue, 28 Jul 2015 08:43:40 -0700
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <CAN6JmWPYdp-6vYSJz=hJo+4_fRi4X7S5Oqox523mUT+YxZqumA@mail.gmail.com>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CAM=pu+J6K7fe3aEs7RyZ9_ecNf=SJUTNNJzX2FzVq2HAd3ne7Q@mail.gmail.com>
 <20150727052501.GB550510@phare.normalesup.org>
 <CAH6Pt5qMOjwq39UvitoXjEA6LydxmVkbJQN=cwFBgMZct-7U0A@mail.gmail.com>
 <CAN6JmWPYdp-6vYSJz=hJo+4_fRi4X7S5Oqox523mUT+YxZqumA@mail.gmail.com>
Message-ID: <CA+X4w0xVvQ=yQHamjta8=EaGA+Dnts5oUBD+qMKvsdECWskbVQ@mail.gmail.com>

On Mon, Jul 27, 2015 at 8:58 PM, Eleftherios Garyfallidis <
garyfallidis at gmail.com> wrote:

> Hi,
>
> On Mon, Jul 27, 2015 at 5:13 AM, Matthew Brett <matthew.brett at gmail.com>
> wrote:
>
>> Hi,
>>
>> On Mon, Jul 27, 2015 at 6:25 AM, Gael Varoquaux
>> <gael.varoquaux at normalesup.org> wrote:
>> > Hi,
>> >
>> > Since it is the time to gives one opinion
>>
>> Sorry to be quiet.
>>
>> I don't have strong feelings about whether the new or old website is
>> better, but Ariel saved us from a lot of frustration by moving us to
>> github pages before the recent Sourceforge meltdown [1].
>>
>>
> Nobody is saying something different about that. This is irrelevant to the
> point of the thread.
> I very much appreciate Ariel's push and work on the gh-pages.
>
>
>> Eleftherios - your main complaint against Jeykll is that it's hard to
>> render the pages before you submit a PR?
>
>
> No, Jeykill is great but Pelican is as as great and in Python and supports
> both md and rst.
> So, as this being a Python project I would give it a chance.
>
>
>> I don't think it's that
>> hard - see http://jekyllrb.com  . OK, it involves installing something
>> in Ruby via gem, but that's not a major burden, and pelican is not
>> trivial to set up either.
>>
>> Pelican is easy to setup at least this is my experience from trying it on
> my machine.
> I haven't played with Jekyll to see if Jekyll is easier in some way.
>

The main advantage of Jekyll relative to all the other solutions is that no
one has to *ever* build the site on their machine, and that you really
didn't need to go through even the minor burden of installing Jekyll on
your machine. Everything is done on the Github side. You can review the
fully rendered site on a contributor's fork, before merging any changes.
For example, here is the website on the gh-pages branch of my fork of the
repo:

http://arokem.github.io/nipy.github.com/

Any less automated process poses a barrier to contribution and
collaboration, relative to this workflow. I too love the new design, but I
would like to see it implemented in an automated manner, and I don't see
how we do that with Flask (or with Pelican). Since the main difference is
really the design used, maybe there's some way to use that design on a
Jekyll-based infrastructure?




>
>> For the content - I don't think it's reasonable to ask Ariel to make
>> the changes, any more that it would be for code.
>
>
> I am happy to change the content my self and I will do. But are we getting
> a bit too
> formal in our discussions? Is it bad to disagree if I don't like something
> or ask for
> changes?
>
> If you think it
>> could be done better, then please, make a PR, surely that will not be
>> much work, and will give the best possible idea of what you would
>> prefer.
>
>
> Matthew, my hope was that at least first people would agree to give
> Pelican or Sphinx
> a chance. If there is no agreement on that I cannot go and make a PR like
> that.
>
> I will make PRs on the content but first I need to see what is the
> vision/goal of the portal.
> Which is missing from the current version of the website. But I see that
> Vanessa
> is actually improving the initial design a lot. When that is done it will
> be easier for
> me to contribute.
>
> Cheers,
> Eleftherios
>
> 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/20150728/96391e3d/attachment.html>

From matthew.brett at gmail.com  Tue Jul 28 17:53:21 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Tue, 28 Jul 2015 16:53:21 +0100
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <CA+X4w0xVvQ=yQHamjta8=EaGA+Dnts5oUBD+qMKvsdECWskbVQ@mail.gmail.com>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CAM=pu+J6K7fe3aEs7RyZ9_ecNf=SJUTNNJzX2FzVq2HAd3ne7Q@mail.gmail.com>
 <20150727052501.GB550510@phare.normalesup.org>
 <CAH6Pt5qMOjwq39UvitoXjEA6LydxmVkbJQN=cwFBgMZct-7U0A@mail.gmail.com>
 <CAN6JmWPYdp-6vYSJz=hJo+4_fRi4X7S5Oqox523mUT+YxZqumA@mail.gmail.com>
 <CA+X4w0xVvQ=yQHamjta8=EaGA+Dnts5oUBD+qMKvsdECWskbVQ@mail.gmail.com>
Message-ID: <CAH6Pt5rkGXkPoiWB4HX6eVsi1xS=ZKspe61azxTrmnRwnyy3ag@mail.gmail.com>

Hi,

On Tue, Jul 28, 2015 at 4:43 PM, Ariel Rokem <arokem at gmail.com> wrote:
>
>
> On Mon, Jul 27, 2015 at 8:58 PM, Eleftherios Garyfallidis
> <garyfallidis at gmail.com> wrote:
>>
>> Hi,
>>
>> On Mon, Jul 27, 2015 at 5:13 AM, Matthew Brett <matthew.brett at gmail.com>
>> wrote:
>>>
>>> Hi,
>>>
>>> On Mon, Jul 27, 2015 at 6:25 AM, Gael Varoquaux
>>> <gael.varoquaux at normalesup.org> wrote:
>>> > Hi,
>>> >
>>> > Since it is the time to gives one opinion
>>>
>>> Sorry to be quiet.
>>>
>>> I don't have strong feelings about whether the new or old website is
>>> better, but Ariel saved us from a lot of frustration by moving us to
>>> github pages before the recent Sourceforge meltdown [1].
>>>
>>
>> Nobody is saying something different about that. This is irrelevant to the
>> point of the thread.
>> I very much appreciate Ariel's push and work on the gh-pages.
>>
>>>
>>> Eleftherios - your main complaint against Jeykll is that it's hard to
>>> render the pages before you submit a PR?
>>
>>
>> No, Jeykill is great but Pelican is as as great and in Python and supports
>> both md and rst.
>> So, as this being a Python project I would give it a chance.
>>
>>>
>>> I don't think it's that
>>> hard - see http://jekyllrb.com  . OK, it involves installing something
>>> in Ruby via gem, but that's not a major burden, and pelican is not
>>> trivial to set up either.
>>>
>> Pelican is easy to setup at least this is my experience from trying it on
>> my machine.
>> I haven't played with Jekyll to see if Jekyll is easier in some way.
>
>
> The main advantage of Jekyll relative to all the other solutions is that no
> one has to *ever* build the site on their machine, and that you really
> didn't need to go through even the minor burden of installing Jekyll on your
> machine. Everything is done on the Github side. You can review the fully
> rendered site on a contributor's fork, before merging any changes. For
> example, here is the website on the gh-pages branch of my fork of the repo:
>
> http://arokem.github.io/nipy.github.com/
>
> Any less automated process poses a barrier to contribution and
> collaboration, relative to this workflow. I too love the new design, but I
> would like to see it implemented in an automated manner, and I don't see how
> we do that with Flask (or with Pelican). Since the main difference is really
> the design used, maybe there's some way to use that design on a Jekyll-based
> infrastructure?

I don't think it's absolutely necessary for there to be an automated
online build.   There are also advantages to website builders with
nice features, so we end up with a better-looking and more
configurable website.  I guess that most of the work here will be done
by people who aren't afraid to set up sphinx or pelican or flask on
their own machines.   It's easy to do minor edits on the page source
with the github interface, for rephrasings or typos.

Cheers,

Matthew

From arokem at gmail.com  Tue Jul 28 17:59:49 2015
From: arokem at gmail.com (Ariel Rokem)
Date: Tue, 28 Jul 2015 08:59:49 -0700
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <CAH6Pt5rkGXkPoiWB4HX6eVsi1xS=ZKspe61azxTrmnRwnyy3ag@mail.gmail.com>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CAM=pu+J6K7fe3aEs7RyZ9_ecNf=SJUTNNJzX2FzVq2HAd3ne7Q@mail.gmail.com>
 <20150727052501.GB550510@phare.normalesup.org>
 <CAH6Pt5qMOjwq39UvitoXjEA6LydxmVkbJQN=cwFBgMZct-7U0A@mail.gmail.com>
 <CAN6JmWPYdp-6vYSJz=hJo+4_fRi4X7S5Oqox523mUT+YxZqumA@mail.gmail.com>
 <CA+X4w0xVvQ=yQHamjta8=EaGA+Dnts5oUBD+qMKvsdECWskbVQ@mail.gmail.com>
 <CAH6Pt5rkGXkPoiWB4HX6eVsi1xS=ZKspe61azxTrmnRwnyy3ag@mail.gmail.com>
Message-ID: <CA+X4w0yQvYEpAb3202Uhyge_ARDQ4OoaH9cNJ-skCdEx8eORkw@mail.gmail.com>

On Tue, Jul 28, 2015 at 8:53 AM, Matthew Brett <matthew.brett at gmail.com>
wrote:

> Hi,
>
> On Tue, Jul 28, 2015 at 4:43 PM, Ariel Rokem <arokem at gmail.com> wrote:
> >
> >
> > On Mon, Jul 27, 2015 at 8:58 PM, Eleftherios Garyfallidis
> > <garyfallidis at gmail.com> wrote:
> >>
> >> Hi,
> >>
> >> On Mon, Jul 27, 2015 at 5:13 AM, Matthew Brett <matthew.brett at gmail.com
> >
> >> wrote:
> >>>
> >>> Hi,
> >>>
> >>> On Mon, Jul 27, 2015 at 6:25 AM, Gael Varoquaux
> >>> <gael.varoquaux at normalesup.org> wrote:
> >>> > Hi,
> >>> >
> >>> > Since it is the time to gives one opinion
> >>>
> >>> Sorry to be quiet.
> >>>
> >>> I don't have strong feelings about whether the new or old website is
> >>> better, but Ariel saved us from a lot of frustration by moving us to
> >>> github pages before the recent Sourceforge meltdown [1].
> >>>
> >>
> >> Nobody is saying something different about that. This is irrelevant to
> the
> >> point of the thread.
> >> I very much appreciate Ariel's push and work on the gh-pages.
> >>
> >>>
> >>> Eleftherios - your main complaint against Jeykll is that it's hard to
> >>> render the pages before you submit a PR?
> >>
> >>
> >> No, Jeykill is great but Pelican is as as great and in Python and
> supports
> >> both md and rst.
> >> So, as this being a Python project I would give it a chance.
> >>
> >>>
> >>> I don't think it's that
> >>> hard - see http://jekyllrb.com  . OK, it involves installing something
> >>> in Ruby via gem, but that's not a major burden, and pelican is not
> >>> trivial to set up either.
> >>>
> >> Pelican is easy to setup at least this is my experience from trying it
> on
> >> my machine.
> >> I haven't played with Jekyll to see if Jekyll is easier in some way.
> >
> >
> > The main advantage of Jekyll relative to all the other solutions is that
> no
> > one has to *ever* build the site on their machine, and that you really
> > didn't need to go through even the minor burden of installing Jekyll on
> your
> > machine. Everything is done on the Github side. You can review the fully
> > rendered site on a contributor's fork, before merging any changes. For
> > example, here is the website on the gh-pages branch of my fork of the
> repo:
> >
> > http://arokem.github.io/nipy.github.com/
> >
> > Any less automated process poses a barrier to contribution and
> > collaboration, relative to this workflow. I too love the new design, but
> I
> > would like to see it implemented in an automated manner, and I don't see
> how
> > we do that with Flask (or with Pelican). Since the main difference is
> really
> > the design used, maybe there's some way to use that design on a
> Jekyll-based
> > infrastructure?
>
> I don't think it's absolutely necessary for there to be an automated
> online build.   There are also advantages to website builders with
> nice features, so we end up with a better-looking and more
> configurable website.  I guess that most of the work here will be done
> by people who aren't afraid to set up sphinx or pelican or flask on
> their own machines.   It's easy to do minor edits on the page source
> with the github interface, for rephrasings or typos.
>
>
Our best data on the topic comes from the old nipy.org repo (
https://github.com/nipy/nipyco). There are 0 (zero) PRs on this repo, even
though the content was really running out of date. I would argue that at
least part of that is that no one wants to bother building this thing on
their machine. Recall also the difference in the experience of making and
merging PRs before and after Travis.


> 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/20150728/31b93878/attachment.html>

From matthew.brett at gmail.com  Tue Jul 28 18:08:15 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Tue, 28 Jul 2015 17:08:15 +0100
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <CA+X4w0yQvYEpAb3202Uhyge_ARDQ4OoaH9cNJ-skCdEx8eORkw@mail.gmail.com>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CAM=pu+J6K7fe3aEs7RyZ9_ecNf=SJUTNNJzX2FzVq2HAd3ne7Q@mail.gmail.com>
 <20150727052501.GB550510@phare.normalesup.org>
 <CAH6Pt5qMOjwq39UvitoXjEA6LydxmVkbJQN=cwFBgMZct-7U0A@mail.gmail.com>
 <CAN6JmWPYdp-6vYSJz=hJo+4_fRi4X7S5Oqox523mUT+YxZqumA@mail.gmail.com>
 <CA+X4w0xVvQ=yQHamjta8=EaGA+Dnts5oUBD+qMKvsdECWskbVQ@mail.gmail.com>
 <CAH6Pt5rkGXkPoiWB4HX6eVsi1xS=ZKspe61azxTrmnRwnyy3ag@mail.gmail.com>
 <CA+X4w0yQvYEpAb3202Uhyge_ARDQ4OoaH9cNJ-skCdEx8eORkw@mail.gmail.com>
Message-ID: <CAH6Pt5rmtq4HK7+pN2U2RYueX4i1gkE=MhEwUrfK_=BP_4MBjQ@mail.gmail.com>

On Tue, Jul 28, 2015 at 4:59 PM, Ariel Rokem <arokem at gmail.com> wrote:
>
>
> On Tue, Jul 28, 2015 at 8:53 AM, Matthew Brett <matthew.brett at gmail.com>
> wrote:
>>
>> Hi,
>>
>> On Tue, Jul 28, 2015 at 4:43 PM, Ariel Rokem <arokem at gmail.com> wrote:
>> >
>> >
>> > On Mon, Jul 27, 2015 at 8:58 PM, Eleftherios Garyfallidis
>> > <garyfallidis at gmail.com> wrote:
>> >>
>> >> Hi,
>> >>
>> >> On Mon, Jul 27, 2015 at 5:13 AM, Matthew Brett
>> >> <matthew.brett at gmail.com>
>> >> wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> On Mon, Jul 27, 2015 at 6:25 AM, Gael Varoquaux
>> >>> <gael.varoquaux at normalesup.org> wrote:
>> >>> > Hi,
>> >>> >
>> >>> > Since it is the time to gives one opinion
>> >>>
>> >>> Sorry to be quiet.
>> >>>
>> >>> I don't have strong feelings about whether the new or old website is
>> >>> better, but Ariel saved us from a lot of frustration by moving us to
>> >>> github pages before the recent Sourceforge meltdown [1].
>> >>>
>> >>
>> >> Nobody is saying something different about that. This is irrelevant to
>> >> the
>> >> point of the thread.
>> >> I very much appreciate Ariel's push and work on the gh-pages.
>> >>
>> >>>
>> >>> Eleftherios - your main complaint against Jeykll is that it's hard to
>> >>> render the pages before you submit a PR?
>> >>
>> >>
>> >> No, Jeykill is great but Pelican is as as great and in Python and
>> >> supports
>> >> both md and rst.
>> >> So, as this being a Python project I would give it a chance.
>> >>
>> >>>
>> >>> I don't think it's that
>> >>> hard - see http://jekyllrb.com  . OK, it involves installing something
>> >>> in Ruby via gem, but that's not a major burden, and pelican is not
>> >>> trivial to set up either.
>> >>>
>> >> Pelican is easy to setup at least this is my experience from trying it
>> >> on
>> >> my machine.
>> >> I haven't played with Jekyll to see if Jekyll is easier in some way.
>> >
>> >
>> > The main advantage of Jekyll relative to all the other solutions is that
>> > no
>> > one has to *ever* build the site on their machine, and that you really
>> > didn't need to go through even the minor burden of installing Jekyll on
>> > your
>> > machine. Everything is done on the Github side. You can review the fully
>> > rendered site on a contributor's fork, before merging any changes. For
>> > example, here is the website on the gh-pages branch of my fork of the
>> > repo:
>> >
>> > http://arokem.github.io/nipy.github.com/
>> >
>> > Any less automated process poses a barrier to contribution and
>> > collaboration, relative to this workflow. I too love the new design, but
>> > I
>> > would like to see it implemented in an automated manner, and I don't see
>> > how
>> > we do that with Flask (or with Pelican). Since the main difference is
>> > really
>> > the design used, maybe there's some way to use that design on a
>> > Jekyll-based
>> > infrastructure?
>>
>> I don't think it's absolutely necessary for there to be an automated
>> online build.   There are also advantages to website builders with
>> nice features, so we end up with a better-looking and more
>> configurable website.  I guess that most of the work here will be done
>> by people who aren't afraid to set up sphinx or pelican or flask on
>> their own machines.   It's easy to do minor edits on the page source
>> with the github interface, for rephrasings or typos.
>>
>
> Our best data on the topic comes from the old nipy.org repo
> (https://github.com/nipy/nipyco). There are 0 (zero) PRs on this repo, even
> though the content was really running out of date. I would argue that at
> least part of that is that no one wants to bother building this thing on
> their machine. Recall also the difference in the experience of making and
> merging PRs before and after Travis.

The old repo was a sphinx repo - so I would be surprised if a moderate
contributor to any of the nipy projects would have any difficulty
building the pages.  I suspect there was some other reason no-one was
editing those pages.

Ch,Mw

From gael.varoquaux at normalesup.org  Tue Jul 28 19:10:28 2015
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Tue, 28 Jul 2015 19:10:28 +0200
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <CAH6Pt5rmtq4HK7+pN2U2RYueX4i1gkE=MhEwUrfK_=BP_4MBjQ@mail.gmail.com>
References: <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CAM=pu+J6K7fe3aEs7RyZ9_ecNf=SJUTNNJzX2FzVq2HAd3ne7Q@mail.gmail.com>
 <20150727052501.GB550510@phare.normalesup.org>
 <CAH6Pt5qMOjwq39UvitoXjEA6LydxmVkbJQN=cwFBgMZct-7U0A@mail.gmail.com>
 <CAN6JmWPYdp-6vYSJz=hJo+4_fRi4X7S5Oqox523mUT+YxZqumA@mail.gmail.com>
 <CA+X4w0xVvQ=yQHamjta8=EaGA+Dnts5oUBD+qMKvsdECWskbVQ@mail.gmail.com>
 <CAH6Pt5rkGXkPoiWB4HX6eVsi1xS=ZKspe61azxTrmnRwnyy3ag@mail.gmail.com>
 <CA+X4w0yQvYEpAb3202Uhyge_ARDQ4OoaH9cNJ-skCdEx8eORkw@mail.gmail.com>
 <CAH6Pt5rmtq4HK7+pN2U2RYueX4i1gkE=MhEwUrfK_=BP_4MBjQ@mail.gmail.com>
Message-ID: <20150728171028.GC1164456@phare.normalesup.org>

On Tue, Jul 28, 2015 at 05:08:15PM +0100, Matthew Brett wrote:
> The old repo was a sphinx repo - so I would be surprised if a moderate
> contributor to any of the nipy projects would have any difficulty
> building the pages.  I suspect there was some other reason no-one was
> editing those pages.

+1. I feel more confortable with sphinx, that I have already used many
times, than Jekyll, which I have never used, and forces me to learn
things.

G

From bobd at stanford.edu  Tue Jul 28 18:55:26 2015
From: bobd at stanford.edu (Bob Dougherty)
Date: Tue, 28 Jul 2015 09:55:26 -0700
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <CAH6Pt5rmtq4HK7+pN2U2RYueX4i1gkE=MhEwUrfK_=BP_4MBjQ@mail.gmail.com>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CAM=pu+J6K7fe3aEs7RyZ9_ecNf=SJUTNNJzX2FzVq2HAd3ne7Q@mail.gmail.com>
 <20150727052501.GB550510@phare.normalesup.org>
 <CAH6Pt5qMOjwq39UvitoXjEA6LydxmVkbJQN=cwFBgMZct-7U0A@mail.gmail.com>
 <CAN6JmWPYdp-6vYSJz=hJo+4_fRi4X7S5Oqox523mUT+YxZqumA@mail.gmail.com>
 <CA+X4w0xVvQ=yQHamjta8=EaGA+Dnts5oUBD+qMKvsdECWskbVQ@mail.gmail.com>
 <CAH6Pt5rkGXkPoiWB4HX6eVsi1xS=ZKspe61azxTrmnRwnyy3ag@mail.gmail.com>
 <CA+X4w0yQvYEpAb3202Uhyge_ARDQ4OoaH9cNJ-skCdEx8eORkw@mail.gmail.com>
 <CAH6Pt5rmtq4HK7+pN2U2RYueX4i1gkE=MhEwUrfK_=BP_4MBjQ@mail.gmail.com>
Message-ID: <55B7B3FE.8090801@stanford.edu>

I have to agree with Ariel on this. I think that any additional barrier 
(no matter how small) will deter contributors. Like Ariel, I'm not a web 
designer. For my limited forays into web design I use docpad, because 
when I'm in web-design mode I like to think in javascript, so a js-based 
tool seemed to make sense. I don't have any desire to learn (no matter 
how trivial) yet another tool. If all I want to do is contribute 
content, I just want to edit some markdown and be done with it. Ariel 
has laid out some very good reasons to use jekyll. I haven't seen any 
similarly compelling reasons not to use it. Is there any practical 
advantage to the alternatives?



From vsochat at stanford.edu  Tue Jul 28 19:36:49 2015
From: vsochat at stanford.edu (vanessa sochat)
Date: Tue, 28 Jul 2015 10:36:49 -0700
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <55B7B3FE.8090801@stanford.edu>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CAM=pu+J6K7fe3aEs7RyZ9_ecNf=SJUTNNJzX2FzVq2HAd3ne7Q@mail.gmail.com>
 <20150727052501.GB550510@phare.normalesup.org>
 <CAH6Pt5qMOjwq39UvitoXjEA6LydxmVkbJQN=cwFBgMZct-7U0A@mail.gmail.com>
 <CAN6JmWPYdp-6vYSJz=hJo+4_fRi4X7S5Oqox523mUT+YxZqumA@mail.gmail.com>
 <CA+X4w0xVvQ=yQHamjta8=EaGA+Dnts5oUBD+qMKvsdECWskbVQ@mail.gmail.com>
 <CAH6Pt5rkGXkPoiWB4HX6eVsi1xS=ZKspe61azxTrmnRwnyy3ag@mail.gmail.com>
 <CA+X4w0yQvYEpAb3202Uhyge_ARDQ4OoaH9cNJ-skCdEx8eORkw@mail.gmail.com>
 <CAH6Pt5rmtq4HK7+pN2U2RYueX4i1gkE=MhEwUrfK_=BP_4MBjQ@mail.gmail.com>
 <55B7B3FE.8090801@stanford.edu>
Message-ID: <CAM=pu+Jkq=UiG7qq8AL5t2BstwymXeAATx4Vs9JaeQ3fDN015Q@mail.gmail.com>

Hi Bob,

I think we are moving toward a solution that will make it very easy to
contribute content. Regardless of if we use jekyll, flask, or something
else, right now contributing a new package just means adding a row to a tab
separated file, and adding a new blog entry means adding a new file to a
folder (with very minimal formatting). I think regardless of the solution
that we will choose, we are optimizing with this goal in mind, so you
should not worry.

Best,

Vanessa

On Tue, Jul 28, 2015 at 9:55 AM, Bob Dougherty <bobd at stanford.edu> wrote:

> I have to agree with Ariel on this. I think that any additional barrier
> (no matter how small) will deter contributors. Like Ariel, I'm not a web
> designer. For my limited forays into web design I use docpad, because when
> I'm in web-design mode I like to think in javascript, so a js-based tool
> seemed to make sense. I don't have any desire to learn (no matter how
> trivial) yet another tool. If all I want to do is contribute content, I
> just want to edit some markdown and be done with it. Ariel has laid out
> some very good reasons to use jekyll. I haven't seen any similarly
> compelling reasons not to use it. Is there any practical advantage to the
> alternatives?
>
>
>
> _______________________________________________
> Neuroimaging mailing list
> Neuroimaging at python.org
> https://mail.python.org/mailman/listinfo/neuroimaging
>



-- 
Vanessa Villamia Sochat
Stanford University
(603) 321-0676
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150728/eb73987b/attachment.html>

From matthew.brett at gmail.com  Tue Jul 28 19:39:08 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Tue, 28 Jul 2015 18:39:08 +0100
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <CAM=pu+Jkq=UiG7qq8AL5t2BstwymXeAATx4Vs9JaeQ3fDN015Q@mail.gmail.com>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CAM=pu+J6K7fe3aEs7RyZ9_ecNf=SJUTNNJzX2FzVq2HAd3ne7Q@mail.gmail.com>
 <20150727052501.GB550510@phare.normalesup.org>
 <CAH6Pt5qMOjwq39UvitoXjEA6LydxmVkbJQN=cwFBgMZct-7U0A@mail.gmail.com>
 <CAN6JmWPYdp-6vYSJz=hJo+4_fRi4X7S5Oqox523mUT+YxZqumA@mail.gmail.com>
 <CA+X4w0xVvQ=yQHamjta8=EaGA+Dnts5oUBD+qMKvsdECWskbVQ@mail.gmail.com>
 <CAH6Pt5rkGXkPoiWB4HX6eVsi1xS=ZKspe61azxTrmnRwnyy3ag@mail.gmail.com>
 <CA+X4w0yQvYEpAb3202Uhyge_ARDQ4OoaH9cNJ-skCdEx8eORkw@mail.gmail.com>
 <CAH6Pt5rmtq4HK7+pN2U2RYueX4i1gkE=MhEwUrfK_=BP_4MBjQ@mail.gmail.com>
 <55B7B3FE.8090801@stanford.edu>
 <CAM=pu+Jkq=UiG7qq8AL5t2BstwymXeAATx4Vs9JaeQ3fDN015Q@mail.gmail.com>
Message-ID: <CAH6Pt5pW5ycs8P9vydM4VvK2x7kTYqJfzAtC51vXTCr2VrXvAQ@mail.gmail.com>

On Tue, Jul 28, 2015 at 6:36 PM, vanessa sochat <vsochat at stanford.edu> wrote:
> Hi Bob,
>
> I think we are moving toward a solution that will make it very easy to
> contribute content. Regardless of if we use jekyll, flask, or something
> else, right now contributing a new package just means adding a row to a tab
> separated file, and adding a new blog entry means adding a new file to a
> folder (with very minimal formatting). I think regardless of the solution
> that we will choose, we are optimizing with this goal in mind, so you should
> not worry.

I agree, it seems reasonable to get something up and then review how
easy it is to work with, how good it looks, and so on.

Cheers,

Matthew

From ben.cipollini at gmail.com  Tue Jul 28 20:09:41 2015
From: ben.cipollini at gmail.com (Ben Cipollini)
Date: Tue, 28 Jul 2015 11:09:41 -0700
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <CAH6Pt5pW5ycs8P9vydM4VvK2x7kTYqJfzAtC51vXTCr2VrXvAQ@mail.gmail.com>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CAM=pu+J6K7fe3aEs7RyZ9_ecNf=SJUTNNJzX2FzVq2HAd3ne7Q@mail.gmail.com>
 <20150727052501.GB550510@phare.normalesup.org>
 <CAH6Pt5qMOjwq39UvitoXjEA6LydxmVkbJQN=cwFBgMZct-7U0A@mail.gmail.com>
 <CAN6JmWPYdp-6vYSJz=hJo+4_fRi4X7S5Oqox523mUT+YxZqumA@mail.gmail.com>
 <CA+X4w0xVvQ=yQHamjta8=EaGA+Dnts5oUBD+qMKvsdECWskbVQ@mail.gmail.com>
 <CAH6Pt5rkGXkPoiWB4HX6eVsi1xS=ZKspe61azxTrmnRwnyy3ag@mail.gmail.com>
 <CA+X4w0yQvYEpAb3202Uhyge_ARDQ4OoaH9cNJ-skCdEx8eORkw@mail.gmail.com>
 <CAH6Pt5rmtq4HK7+pN2U2RYueX4i1gkE=MhEwUrfK_=BP_4MBjQ@mail.gmail.com>
 <55B7B3FE.8090801@stanford.edu>
 <CAM=pu+Jkq=UiG7qq8AL5t2BstwymXeAATx4Vs9JaeQ3fDN015Q@mail.gmail.com>
 <CAH6Pt5pW5ycs8P9vydM4VvK2x7kTYqJfzAtC51vXTCr2VrXvAQ@mail.gmail.com>
Message-ID: <CANgTvZj5X2PCiA+kAJpd8UeLizWU3wGe1urWR3TaLKYYtPBOnw@mail.gmail.com>

Can we make a list of which project websites use which frameworks? Seems
best to select from the frameworks already in play if possible...
On Jul 28, 2015 10:41 AM, "Matthew Brett" <matthew.brett at gmail.com> wrote:

> On Tue, Jul 28, 2015 at 6:36 PM, vanessa sochat <vsochat at stanford.edu>
> wrote:
> > Hi Bob,
> >
> > I think we are moving toward a solution that will make it very easy to
> > contribute content. Regardless of if we use jekyll, flask, or something
> > else, right now contributing a new package just means adding a row to a
> tab
> > separated file, and adding a new blog entry means adding a new file to a
> > folder (with very minimal formatting). I think regardless of the solution
> > that we will choose, we are optimizing with this goal in mind, so you
> should
> > not worry.
>
> I agree, it seems reasonable to get something up and then review how
> easy it is to work with, how good it looks, and so on.
>
> 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/20150728/94129381/attachment.html>

From gael.varoquaux at normalesup.org  Tue Jul 28 20:35:32 2015
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Tue, 28 Jul 2015 20:35:32 +0200
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <CANgTvZj5X2PCiA+kAJpd8UeLizWU3wGe1urWR3TaLKYYtPBOnw@mail.gmail.com>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CAM=pu+J6K7fe3aEs7RyZ9_ecNf=SJUTNNJzX2FzVq2HAd3ne7Q@mail.gmail.com>
 <20150727052501.GB550510@phare.normalesup.org>
 <CAH6Pt5qMOjwq39UvitoXjEA6LydxmVkbJQN=cwFBgMZct-7U0A@mail.gmail.com>
 <CAN6JmWPYdp-6vYSJz=hJo+4_fRi4X7S5Oqox523mUT+YxZqumA@mail.gmail.com>
 <CA+X4w0xVvQ=yQHamjta8=EaGA+Dnts5oUBD+qMKvsdECWskbVQ@mail.gmail.com>
 <CAH6Pt5rkGXkPoiWB4HX6eVsi1xS=ZKspe61azxTrmnRwnyy3ag@mail.gmail.com>
 <CA+X4w0yQvYEpAb3202Uhyge_ARDQ4OoaH9cNJ-skCdEx8eORkw@mail.gmail.com>
 <CAH6Pt5rmtq4HK7+pN2U2RYueX4i1gkE=MhEwUrfK_=BP_4MBjQ@mail.gmail.com>
 <55B7B3FE.8090801@stanford.edu>
 <CAM=pu+Jkq=UiG7qq8AL5t2BstwymXeAATx4Vs9JaeQ3fDN015Q@mail.gmail.com>
 <CAH6Pt5pW5ycs8P9vydM4VvK2x7kTYqJfzAtC51vXTCr2VrXvAQ@mail.gmail.com>
 <CANgTvZj5X2PCiA+kAJpd8UeLizWU3wGe1urWR3TaLKYYtPBOnw@mail.gmail.com>
Message-ID: <3fdfec8e-650c-4db5-9480-293d44095535@typeapp.com>

We all use sphinx, as far as I can tell.

Sent from my phone. Please forgive brevity and mis spelling



On Jul 28, 2015, 20:27, at 20:27, Ben Cipollini <ben.cipollini at gmail.com> wrote:
>Can we make a list of which project websites use which frameworks?
>Seems
>best to select from the frameworks already in play if possible...
>On Jul 28, 2015 10:41 AM, "Matthew Brett" <matthew.brett at gmail.com>
>wrote:
>
>> On Tue, Jul 28, 2015 at 6:36 PM, vanessa sochat
><vsochat at stanford.edu>
>> wrote:
>> > Hi Bob,
>> >
>> > I think we are moving toward a solution that will make it very easy
>to
>> > contribute content. Regardless of if we use jekyll, flask, or
>something
>> > else, right now contributing a new package just means adding a row
>to a
>> tab
>> > separated file, and adding a new blog entry means adding a new file
>to a
>> > folder (with very minimal formatting). I think regardless of the
>solution
>> > that we will choose, we are optimizing with this goal in mind, so
>you
>> should
>> > not worry.
>>
>> I agree, it seems reasonable to get something up and then review how
>> easy it is to work with, how good it looks, and so on.
>>
>> 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/20150728/e3bee358/attachment.html>

From vsochat at stanford.edu  Tue Jul 28 23:50:09 2015
From: vsochat at stanford.edu (vanessa sochat)
Date: Tue, 28 Jul 2015 14:50:09 -0700
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <CAM=pu+Jkq=UiG7qq8AL5t2BstwymXeAATx4Vs9JaeQ3fDN015Q@mail.gmail.com>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CAM=pu+J6K7fe3aEs7RyZ9_ecNf=SJUTNNJzX2FzVq2HAd3ne7Q@mail.gmail.com>
 <20150727052501.GB550510@phare.normalesup.org>
 <CAH6Pt5qMOjwq39UvitoXjEA6LydxmVkbJQN=cwFBgMZct-7U0A@mail.gmail.com>
 <CAN6JmWPYdp-6vYSJz=hJo+4_fRi4X7S5Oqox523mUT+YxZqumA@mail.gmail.com>
 <CA+X4w0xVvQ=yQHamjta8=EaGA+Dnts5oUBD+qMKvsdECWskbVQ@mail.gmail.com>
 <CAH6Pt5rkGXkPoiWB4HX6eVsi1xS=ZKspe61azxTrmnRwnyy3ag@mail.gmail.com>
 <CA+X4w0yQvYEpAb3202Uhyge_ARDQ4OoaH9cNJ-skCdEx8eORkw@mail.gmail.com>
 <CAH6Pt5rmtq4HK7+pN2U2RYueX4i1gkE=MhEwUrfK_=BP_4MBjQ@mail.gmail.com>
 <55B7B3FE.8090801@stanford.edu>
 <CAM=pu+Jkq=UiG7qq8AL5t2BstwymXeAATx4Vs9JaeQ3fDN015Q@mail.gmail.com>
Message-ID: <CAM=pu++AaY=rRvV_JX8tGpQ=7tMSTTi8rFFP-684jSEToTbRUg@mail.gmail.com>

Hi everyone,

A quick update. I have never used github pages before, but was able to work
through the bugs of the freeze, and deploy the site to pages:

https://vsoch.github.io/nipy

A few other updates / notes:


   - All content / links must be https. This means it's best to serve most
   of our own css/js files, and embedded content that is not https will not
   render (for example, click on the embedded nbviewer post
   <https://vsoch.github.io/nipy/pages/7-28-2015-embed-ipython/>, and then
   inspect the browser to see the error)
   - The above would be an issue for any github pages. To address this, I
   figured out how to get syntax highlighting
   <https://vsoch.github.io/nipy/pages/7-28-2015-embed-code/> so we can
   code right in the markdown.
   - I styled the blog roll. I'm sure with more posts we would want some
   kind of pagination.
   - I added a few posts showing how to embed other content type.
   - The freezing process didn't grab the custom pages for some reason, and
   it worked when I did this
   <https://github.com/vsoch/nipy/blob/master/code/views.py#L46>.  This
   would mean that adding a project, it would be required to have a template
   for it. That comes down to copying a file and renaming it to the project
   name.

The process to update the pages is to basically:


   1. Add a new .md file in the code/pages folder
   2. python freeze.py
   3. Push to the gh-pages branch


Best,

Vanessa


On Tue, Jul 28, 2015 at 10:36 AM, vanessa sochat <vsochat at stanford.edu>
wrote:

> Hi Bob,
>
> I think we are moving toward a solution that will make it very easy to
> contribute content. Regardless of if we use jekyll, flask, or something
> else, right now contributing a new package just means adding a row to a tab
> separated file, and adding a new blog entry means adding a new file to a
> folder (with very minimal formatting). I think regardless of the solution
> that we will choose, we are optimizing with this goal in mind, so you
> should not worry.
>
> Best,
>
> Vanessa
>
> On Tue, Jul 28, 2015 at 9:55 AM, Bob Dougherty <bobd at stanford.edu> wrote:
>
>> I have to agree with Ariel on this. I think that any additional barrier
>> (no matter how small) will deter contributors. Like Ariel, I'm not a web
>> designer. For my limited forays into web design I use docpad, because when
>> I'm in web-design mode I like to think in javascript, so a js-based tool
>> seemed to make sense. I don't have any desire to learn (no matter how
>> trivial) yet another tool. If all I want to do is contribute content, I
>> just want to edit some markdown and be done with it. Ariel has laid out
>> some very good reasons to use jekyll. I haven't seen any similarly
>> compelling reasons not to use it. Is there any practical advantage to the
>> alternatives?
>>
>>
>>
>> _______________________________________________
>> Neuroimaging mailing list
>> Neuroimaging at python.org
>> https://mail.python.org/mailman/listinfo/neuroimaging
>>
>
>
>
> --
> Vanessa Villamia Sochat
> Stanford University
> (603) 321-0676
>



-- 
Vanessa Villamia Sochat
Stanford University
(603) 321-0676
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150728/b06fd93b/attachment-0001.html>

From bobd at stanford.edu  Wed Jul 29 00:14:25 2015
From: bobd at stanford.edu (Bob Dougherty)
Date: Tue, 28 Jul 2015 15:14:25 -0700
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <CAM=pu++AaY=rRvV_JX8tGpQ=7tMSTTi8rFFP-684jSEToTbRUg@mail.gmail.com>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CAM=pu+J6K7fe3aEs7RyZ9_ecNf=SJUTNNJzX2FzVq2HAd3ne7Q@mail.gmail.com>
 <20150727052501.GB550510@phare.normalesup.org>
 <CAH6Pt5qMOjwq39UvitoXjEA6LydxmVkbJQN=cwFBgMZct-7U0A@mail.gmail.com>
 <CAN6JmWPYdp-6vYSJz=hJo+4_fRi4X7S5Oqox523mUT+YxZqumA@mail.gmail.com>
 <CA+X4w0xVvQ=yQHamjta8=EaGA+Dnts5oUBD+qMKvsdECWskbVQ@mail.gmail.com>
 <CAH6Pt5rkGXkPoiWB4HX6eVsi1xS=ZKspe61azxTrmnRwnyy3ag@mail.gmail.com>
 <CA+X4w0yQvYEpAb3202Uhyge_ARDQ4OoaH9cNJ-skCdEx8eORkw@mail.gmail.com>
 <CAH6Pt5rmtq4HK7+pN2U2RYueX4i1gkE=MhEwUrfK_=BP_4MBjQ@mail.gmail.com>
 <55B7B3FE.8090801@stanford.edu>
 <CAM=pu+Jkq=UiG7qq8AL5t2BstwymXeAATx4Vs9JaeQ3fDN015Q@mail.gmail.com>
 <CAM=pu++AaY=rRvV_JX8tGpQ=7tMSTTi8rFFP-684jSEToTbRUg@mail.gmail.com>
Message-ID: <55B7FEC1.6050501@stanford.edu>

Hi Vanessa,

It looks great! Just a note on https: I know that github proper forces 
https, but github.io doesn't seem to. E.g., start on http: 
http://vsoch.github.io/nipy/ and it remains http (and then the embedded 
nbviewer works).

cheers,
bob



On 07/28/2015 02:50 PM, vanessa sochat wrote:
> Hi everyone,
>
> A quick update. I have never used github pages before, but was able to 
> work through the bugs of the freeze, and deploy the site to pages:
>
> https://vsoch.github.io/nipy
>
> A few other updates / notes:
>
>   * All content / links must be https. This means it's best to serve
>     most of our own css/js files, and embedded content that is not
>     https will not render (for example, click on the embedded nbviewer
>     post
>     <https://vsoch.github.io/nipy/pages/7-28-2015-embed-ipython/>, and
>     then inspect the browser to see the error)
>   * The above would be an issue for any github pages. To address this,
>     I figured out how to get syntax highlighting
>     <https://vsoch.github.io/nipy/pages/7-28-2015-embed-code/> so we
>     can code right in the markdown.
>   * I styled the blog roll. I'm sure with more posts we would want
>     some kind of pagination.
>   * I added a few posts showing how to embed other content type.
>   * The freezing process didn't grab the custom pages for some reason,
>     and it worked when I did this
>     <https://github.com/vsoch/nipy/blob/master/code/views.py#L46>. 
>     This would mean that adding a project, it would be required to
>     have a template for it. That comes down to copying a file and
>     renaming it to the project name.
>
> The process to update the pages is to basically:
>
>  1. Add a new .md file in the code/pages folder
>  2. python freeze.py
>  3. Push to the gh-pages branch
>
>
> Best,
>
> Vanessa
>
>
> On Tue, Jul 28, 2015 at 10:36 AM, vanessa sochat <vsochat at stanford.edu 
> <mailto:vsochat at stanford.edu>> wrote:
>
>     Hi Bob,
>
>     I think we are moving toward a solution that will make it very
>     easy to contribute content. Regardless of if we use jekyll, flask,
>     or something else, right now contributing a new package just means
>     adding a row to a tab separated file, and adding a new blog entry
>     means adding a new file to a folder (with very minimal
>     formatting). I think regardless of the solution that we will
>     choose, we are optimizing with this goal in mind, so you should
>     not worry.
>
>     Best,
>
>     Vanessa
>
>     On Tue, Jul 28, 2015 at 9:55 AM, Bob Dougherty <bobd at stanford.edu
>     <mailto:bobd at stanford.edu>> wrote:
>
>         I have to agree with Ariel on this. I think that any
>         additional barrier (no matter how small) will deter
>         contributors. Like Ariel, I'm not a web designer. For my
>         limited forays into web design I use docpad, because when I'm
>         in web-design mode I like to think in javascript, so a
>         js-based tool seemed to make sense. I don't have any desire to
>         learn (no matter how trivial) yet another tool. If all I want
>         to do is contribute content, I just want to edit some markdown
>         and be done with it. Ariel has laid out some very good reasons
>         to use jekyll. I haven't seen any similarly compelling reasons
>         not to use it. Is there any practical advantage to the
>         alternatives?
>
>
>
>         _______________________________________________
>         Neuroimaging mailing list
>         Neuroimaging at python.org <mailto:Neuroimaging at python.org>
>         https://mail.python.org/mailman/listinfo/neuroimaging
>
>
>
>
>     -- 
>     Vanessa Villamia Sochat
>     Stanford University
>     (603) 321-0676 <tel:%28603%29%20321-0676>
>
>
>
>
> -- 
> Vanessa Villamia Sochat
> Stanford University
> (603) 321-0676
>
>
> _______________________________________________
> Neuroimaging mailing list
> Neuroimaging at python.org
> https://mail.python.org/mailman/listinfo/neuroimaging

-- 
Robert F. Dougherty, PhD
Research Director
Stanford Center for Cognitive and Neurobiological Imaging
70 Jordan Hall  *  Stanford CA 94305  *  650-725-0051
http://www.stanford.edu/~bobd

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

From vsochat at stanford.edu  Wed Jul 29 00:16:25 2015
From: vsochat at stanford.edu (vanessa sochat)
Date: Tue, 28 Jul 2015 15:16:25 -0700
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <55B7FEC1.6050501@stanford.edu>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CAM=pu+J6K7fe3aEs7RyZ9_ecNf=SJUTNNJzX2FzVq2HAd3ne7Q@mail.gmail.com>
 <20150727052501.GB550510@phare.normalesup.org>
 <CAH6Pt5qMOjwq39UvitoXjEA6LydxmVkbJQN=cwFBgMZct-7U0A@mail.gmail.com>
 <CAN6JmWPYdp-6vYSJz=hJo+4_fRi4X7S5Oqox523mUT+YxZqumA@mail.gmail.com>
 <CA+X4w0xVvQ=yQHamjta8=EaGA+Dnts5oUBD+qMKvsdECWskbVQ@mail.gmail.com>
 <CAH6Pt5rkGXkPoiWB4HX6eVsi1xS=ZKspe61azxTrmnRwnyy3ag@mail.gmail.com>
 <CA+X4w0yQvYEpAb3202Uhyge_ARDQ4OoaH9cNJ-skCdEx8eORkw@mail.gmail.com>
 <CAH6Pt5rmtq4HK7+pN2U2RYueX4i1gkE=MhEwUrfK_=BP_4MBjQ@mail.gmail.com>
 <55B7B3FE.8090801@stanford.edu>
 <CAM=pu+Jkq=UiG7qq8AL5t2BstwymXeAATx4Vs9JaeQ3fDN015Q@mail.gmail.com>
 <CAM=pu++AaY=rRvV_JX8tGpQ=7tMSTTi8rFFP-684jSEToTbRUg@mail.gmail.com>
 <55B7FEC1.6050501@stanford.edu>
Message-ID: <CAM=pu+LFOZnPp_YSU+RfaqoUwwKYusc=ULQ3Rmk99=5ow67R6g@mail.gmail.com>

Wicked cool!

It's because I have this plugin :)

https://en.wikipedia.org/wiki/HTTPS_Everywhere

On Tue, Jul 28, 2015 at 3:14 PM, Bob Dougherty <bobd at stanford.edu> wrote:

>  Hi Vanessa,
>
> It looks great! Just a note on https: I know that github proper forces
> https, but github.io doesn't seem to. E.g., start on http:
> http://vsoch.github.io/nipy/ and it remains http (and then the embedded
> nbviewer works).
>
> cheers,
> bob
>
>
>
>
> On 07/28/2015 02:50 PM, vanessa sochat wrote:
>
> Hi everyone,
>
>  A quick update. I have never used github pages before, but was able to
> work through the bugs of the freeze, and deploy the site to pages:
>
>  https://vsoch.github.io/nipy
>
>  A few other updates / notes:
>
>
>    - All content / links must be https. This means it's best to serve
>    most of our own css/js files, and embedded content that is not https will
>    not render (for example, click on the embedded nbviewer post
>    <https://vsoch.github.io/nipy/pages/7-28-2015-embed-ipython/>, and
>    then inspect the browser to see the error)
>    - The above would be an issue for any github pages. To address this, I
>    figured out how to get syntax highlighting
>    <https://vsoch.github.io/nipy/pages/7-28-2015-embed-code/> so we can
>    code right in the markdown.
>    - I styled the blog roll. I'm sure with more posts we would want some
>    kind of pagination.
>    - I added a few posts showing how to embed other content type.
>    - The freezing process didn't grab the custom pages for some reason,
>    and it worked when I did this
>    <https://github.com/vsoch/nipy/blob/master/code/views.py#L46>.  This
>    would mean that adding a project, it would be required to have a template
>    for it. That comes down to copying a file and renaming it to the project
>    name.
>
> The process to update the pages is to basically:
>
>
>    1. Add a new .md file in the code/pages folder
>     2. python freeze.py
>     3. Push to the gh-pages branch
>
>
>  Best,
>
>  Vanessa
>
>
> On Tue, Jul 28, 2015 at 10:36 AM, vanessa sochat <vsochat at stanford.edu>
> wrote:
>
>> Hi Bob,
>>
>>  I think we are moving toward a solution that will make it very easy to
>> contribute content. Regardless of if we use jekyll, flask, or something
>> else, right now contributing a new package just means adding a row to a tab
>> separated file, and adding a new blog entry means adding a new file to a
>> folder (with very minimal formatting). I think regardless of the solution
>> that we will choose, we are optimizing with this goal in mind, so you
>> should not worry.
>>
>>  Best,
>>
>>  Vanessa
>>
>> On Tue, Jul 28, 2015 at 9:55 AM, Bob Dougherty <bobd at stanford.edu> wrote:
>>
>>> I have to agree with Ariel on this. I think that any additional barrier
>>> (no matter how small) will deter contributors. Like Ariel, I'm not a web
>>> designer. For my limited forays into web design I use docpad, because when
>>> I'm in web-design mode I like to think in javascript, so a js-based tool
>>> seemed to make sense. I don't have any desire to learn (no matter how
>>> trivial) yet another tool. If all I want to do is contribute content, I
>>> just want to edit some markdown and be done with it. Ariel has laid out
>>> some very good reasons to use jekyll. I haven't seen any similarly
>>> compelling reasons not to use it. Is there any practical advantage to the
>>> alternatives?
>>>
>>>
>>>
>>> _______________________________________________
>>> Neuroimaging mailing list
>>> Neuroimaging at python.org
>>> https://mail.python.org/mailman/listinfo/neuroimaging
>>>
>>
>>
>>
>>  --
>> Vanessa Villamia Sochat
>> Stanford University
>>  (603) 321-0676 <%28603%29%20321-0676>
>>
>
>
>
>  --
> Vanessa Villamia Sochat
> Stanford University
>  (603) 321-0676
>
>
> _______________________________________________
> Neuroimaging mailing listNeuroimaging at python.orghttps://mail.python.org/mailman/listinfo/neuroimaging
>
>
> --
> Robert F. Dougherty, PhD
> Research Director
> Stanford Center for Cognitive and Neurobiological Imaging
> 70 Jordan Hall  *  Stanford CA 94305  *  650-725-0051http://www.stanford.edu/~bobd
>
>
> _______________________________________________
> Neuroimaging mailing list
> Neuroimaging at python.org
> https://mail.python.org/mailman/listinfo/neuroimaging
>
>


-- 
Vanessa Villamia Sochat
Stanford University
(603) 321-0676
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150728/10c0bbc7/attachment.html>

From stefanv at berkeley.edu  Tue Jul 28 23:48:42 2015
From: stefanv at berkeley.edu (Stefan van der Walt)
Date: Tue, 28 Jul 2015 14:48:42 -0700
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <CAN6JmWP9rox4Gwu-AJvHXJGsD4Y=AAJmG3FSB62cf7WyzMzh+g@mail.gmail.com>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CAM=pu+J6K7fe3aEs7RyZ9_ecNf=SJUTNNJzX2FzVq2HAd3ne7Q@mail.gmail.com>
 <20150727052501.GB550510@phare.normalesup.org>
 <CAM=pu+LhN0=gksP+72r4u7-MNrMMN144XbJiawYujE8hkJ5o+A@mail.gmail.com>
 <CA+X4w0yr0kXgBL9JkZSPXzX7SZUf5OQwZksKMso-g04TgLSCMQ@mail.gmail.com>
 <CAM=pu++DL13+mv8JuQDJeg-6Eszc4npXEmc4GxXcyF_LTJx=Xg@mail.gmail.com>
 <CA+X4w0yi7kKOxmSZSJTYD-5B8TL8EQE1mPH_mAJ=0eTFqSbeZQ@mail.gmail.com>
 <CAM=pu+Khcxp+1Kc_9J6-Ns3JL75qFQ07pVavfzBmZEXaMDPFVg@mail.gmail.com>
 <CAM=pu+KSjO_iaW-MrMwM_o_6xgZrsg2eEo1L6fL8ZJqUTLmMYg@mail.gmail.com>
 <CAN6JmWP9rox4Gwu-AJvHXJGsD4Y=AAJmG3FSB62cf7WyzMzh+g@mail.gmail.com>
Message-ID: <871tfs6jid.fsf@berkeley.edu>

On 2015-07-27 21:41:00, Eleftherios Garyfallidis 
<garyfallidis at gmail.com> wrote:
> The website starts looking *much* better. Thank you for pushing 
> forward with this. And I am very happy that the website is built 
> with Flask now a Python tool!!! :)

I've never used Flask to generate static content--is that an 
option?  Otherwise it may be simpler to take the same design 
that's currently used and transplant it onto Sphinx, StaticJinja, 
Jekyll, Hyde or Pelican.

Those solutions are more-or-less a toss-up in terms of the 
functionality we need, with the caveat that most devs here (who 
already have configured Python environments) cannot simply install 
Jekyll for offline work.

Once the main design work is done, the issue of being able to do 
online previews of built pages may become less relevant, since 
most changes will be to content.

St?fan

From stefanv at berkeley.edu  Wed Jul 29 00:07:25 2015
From: stefanv at berkeley.edu (Stefan van der Walt)
Date: Tue, 28 Jul 2015 15:07:25 -0700
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <CAM=pu++AaY=rRvV_JX8tGpQ=7tMSTTi8rFFP-684jSEToTbRUg@mail.gmail.com>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CAM=pu+J6K7fe3aEs7RyZ9_ecNf=SJUTNNJzX2FzVq2HAd3ne7Q@mail.gmail.com>
 <20150727052501.GB550510@phare.normalesup.org>
 <CAH6Pt5qMOjwq39UvitoXjEA6LydxmVkbJQN=cwFBgMZct-7U0A@mail.gmail.com>
 <CAN6JmWPYdp-6vYSJz=hJo+4_fRi4X7S5Oqox523mUT+YxZqumA@mail.gmail.com>
 <CA+X4w0xVvQ=yQHamjta8=EaGA+Dnts5oUBD+qMKvsdECWskbVQ@mail.gmail.com>
 <CAH6Pt5rkGXkPoiWB4HX6eVsi1xS=ZKspe61azxTrmnRwnyy3ag@mail.gmail.com>
 <CA+X4w0yQvYEpAb3202Uhyge_ARDQ4OoaH9cNJ-skCdEx8eORkw@mail.gmail.com>
 <CAH6Pt5rmtq4HK7+pN2U2RYueX4i1gkE=MhEwUrfK_=BP_4MBjQ@mail.gmail.com>
 <55B7B3FE.8090801@stanford.edu>
 <CAM=pu+Jkq=UiG7qq8AL5t2BstwymXeAATx4Vs9JaeQ3fDN015Q@mail.gmail.com>
 <CAM=pu++AaY=rRvV_JX8tGpQ=7tMSTTi8rFFP-684jSEToTbRUg@mail.gmail.com>
Message-ID: <87zj2g542q.fsf@berkeley.edu>

On 2015-07-28 14:50:09, vanessa sochat <vsochat at stanford.edu> 
wrote:
>    - All content / links must be https. This means it's best to 
>    serve most of our own css/js files, and embedded content that 
>    is not https will not render (for example, click on the 
>    embedded nbviewer post 
>    <https://vsoch.github.io/nipy/pages/7-28-2015-embed-ipython/>, 
>    and then inspect the browser to see the error)

This will be an issue whenever you use an iframe, I suspect, but 
not if you simply embed static content.
 
>    - The freezing process didn't grab the custom pages for some 
>    reason, and it worked when I did this 
>    <https://github.com/vsoch/nipy/blob/master/code/views.py#L46>. 
>    This would mean that adding a project, it would be required 
>    to have a template for it. That comes down to copying a file 
>    and renaming it to the project name.

I think following this route will cause a lot of headaches--Flask 
isn't really meant to be converted to static pages, so we may find 
ourselves swimming against the stream more often than not.

St?fan

From vsochat at stanford.edu  Wed Jul 29 01:37:28 2015
From: vsochat at stanford.edu (vanessa sochat)
Date: Tue, 28 Jul 2015 16:37:28 -0700
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <87zj2g542q.fsf@berkeley.edu>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CAM=pu+J6K7fe3aEs7RyZ9_ecNf=SJUTNNJzX2FzVq2HAd3ne7Q@mail.gmail.com>
 <20150727052501.GB550510@phare.normalesup.org>
 <CAH6Pt5qMOjwq39UvitoXjEA6LydxmVkbJQN=cwFBgMZct-7U0A@mail.gmail.com>
 <CAN6JmWPYdp-6vYSJz=hJo+4_fRi4X7S5Oqox523mUT+YxZqumA@mail.gmail.com>
 <CA+X4w0xVvQ=yQHamjta8=EaGA+Dnts5oUBD+qMKvsdECWskbVQ@mail.gmail.com>
 <CAH6Pt5rkGXkPoiWB4HX6eVsi1xS=ZKspe61azxTrmnRwnyy3ag@mail.gmail.com>
 <CA+X4w0yQvYEpAb3202Uhyge_ARDQ4OoaH9cNJ-skCdEx8eORkw@mail.gmail.com>
 <CAH6Pt5rmtq4HK7+pN2U2RYueX4i1gkE=MhEwUrfK_=BP_4MBjQ@mail.gmail.com>
 <55B7B3FE.8090801@stanford.edu>
 <CAM=pu+Jkq=UiG7qq8AL5t2BstwymXeAATx4Vs9JaeQ3fDN015Q@mail.gmail.com>
 <CAM=pu++AaY=rRvV_JX8tGpQ=7tMSTTi8rFFP-684jSEToTbRUg@mail.gmail.com>
 <87zj2g542q.fsf@berkeley.edu>
Message-ID: <CAM=pu+JzmN2zM-Yz+qewbwRPpvGVuRpt=av6cTDz0A=3+Yzptg@mail.gmail.com>

Now that the design is (somewhat) materialized, if you guys want to hash it
out and decide an optimal solution, I'm down for converting to any
framework. Details can be worked on later. I haven't used anything outside
flask so I can't offer an opinion, but I do think it should have the
qualities that we've been discussing.  I wonder if there are continuous
integration services that would render an entire PR for preview before
accepting? That would be optimal.

On Tue, Jul 28, 2015 at 3:07 PM, Stefan van der Walt <stefanv at berkeley.edu>
wrote:

> On 2015-07-28 14:50:09, vanessa sochat <vsochat at stanford.edu> wrote:
>
>>    - All content / links must be https. This means it's best to    serve
>> most of our own css/js files, and embedded content that    is not https
>> will not render (for example, click on the    embedded nbviewer post    <
>> https://vsoch.github.io/nipy/pages/7-28-2015-embed-ipython/>,    and
>> then inspect the browser to see the error)
>>
>
> This will be an issue whenever you use an iframe, I suspect, but not if
> you simply embed static content.
>
>     - The freezing process didn't grab the custom pages for some
>> reason, and it worked when I did this    <
>> https://github.com/vsoch/nipy/blob/master/code/views.py#L46>.    This
>> would mean that adding a project, it would be required    to have a
>> template for it. That comes down to copying a file    and renaming it to
>> the project name.
>>
>
> I think following this route will cause a lot of headaches--Flask isn't
> really meant to be converted to static pages, so we may find ourselves
> swimming against the stream more often than not.
>
> St?fan
>
> _______________________________________________
> Neuroimaging mailing list
> Neuroimaging at python.org
> https://mail.python.org/mailman/listinfo/neuroimaging
>



-- 
Vanessa Villamia Sochat
Stanford University
(603) 321-0676
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150728/9f895e7f/attachment.html>

From krzysztof.gorgolewski at gmail.com  Wed Jul 29 01:43:33 2015
From: krzysztof.gorgolewski at gmail.com (Chris Filo Gorgolewski)
Date: Tue, 28 Jul 2015 16:43:33 -0700
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <CAM=pu+JzmN2zM-Yz+qewbwRPpvGVuRpt=av6cTDz0A=3+Yzptg@mail.gmail.com>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CAM=pu+J6K7fe3aEs7RyZ9_ecNf=SJUTNNJzX2FzVq2HAd3ne7Q@mail.gmail.com>
 <20150727052501.GB550510@phare.normalesup.org>
 <CAH6Pt5qMOjwq39UvitoXjEA6LydxmVkbJQN=cwFBgMZct-7U0A@mail.gmail.com>
 <CAN6JmWPYdp-6vYSJz=hJo+4_fRi4X7S5Oqox523mUT+YxZqumA@mail.gmail.com>
 <CA+X4w0xVvQ=yQHamjta8=EaGA+Dnts5oUBD+qMKvsdECWskbVQ@mail.gmail.com>
 <CAH6Pt5rkGXkPoiWB4HX6eVsi1xS=ZKspe61azxTrmnRwnyy3ag@mail.gmail.com>
 <CA+X4w0yQvYEpAb3202Uhyge_ARDQ4OoaH9cNJ-skCdEx8eORkw@mail.gmail.com>
 <CAH6Pt5rmtq4HK7+pN2U2RYueX4i1gkE=MhEwUrfK_=BP_4MBjQ@mail.gmail.com>
 <55B7B3FE.8090801@stanford.edu>
 <CAM=pu+Jkq=UiG7qq8AL5t2BstwymXeAATx4Vs9JaeQ3fDN015Q@mail.gmail.com>
 <CAM=pu++AaY=rRvV_JX8tGpQ=7tMSTTi8rFFP-684jSEToTbRUg@mail.gmail.com>
 <87zj2g542q.fsf@berkeley.edu>
 <CAM=pu+JzmN2zM-Yz+qewbwRPpvGVuRpt=av6cTDz0A=3+Yzptg@mail.gmail.com>
Message-ID: <CAAQzouOmAFo=C3OX4cGL5FQvgH_Z5DWiLgAGbGSz+MW=Vv0FZw@mail.gmail.com>

CircleCI can do this. This is how nilearn docs are being built (from
sphinx):
https://circle-artifacts.com/gh/nilearn/nilearn/234/artifacts/0/home/ubuntu/nilearn/doc/_build/html/building_blocks/index.html

Best,
Chris

On Tue, Jul 28, 2015 at 4:37 PM, vanessa sochat <vsochat at stanford.edu>
wrote:

> Now that the design is (somewhat) materialized, if you guys want to hash
> it out and decide an optimal solution, I'm down for converting to any
> framework. Details can be worked on later. I haven't used anything outside
> flask so I can't offer an opinion, but I do think it should have the
> qualities that we've been discussing.  I wonder if there are continuous
> integration services that would render an entire PR for preview before
> accepting? That would be optimal.
>
> On Tue, Jul 28, 2015 at 3:07 PM, Stefan van der Walt <stefanv at berkeley.edu
> > wrote:
>
>> On 2015-07-28 14:50:09, vanessa sochat <vsochat at stanford.edu> wrote:
>>
>>>    - All content / links must be https. This means it's best to    serve
>>> most of our own css/js files, and embedded content that    is not https
>>> will not render (for example, click on the    embedded nbviewer post    <
>>> https://vsoch.github.io/nipy/pages/7-28-2015-embed-ipython/>,    and
>>> then inspect the browser to see the error)
>>>
>>
>> This will be an issue whenever you use an iframe, I suspect, but not if
>> you simply embed static content.
>>
>>     - The freezing process didn't grab the custom pages for some
>>> reason, and it worked when I did this    <
>>> https://github.com/vsoch/nipy/blob/master/code/views.py#L46>.    This
>>> would mean that adding a project, it would be required    to have a
>>> template for it. That comes down to copying a file    and renaming it to
>>> the project name.
>>>
>>
>> I think following this route will cause a lot of headaches--Flask isn't
>> really meant to be converted to static pages, so we may find ourselves
>> swimming against the stream more often than not.
>>
>> St?fan
>>
>> _______________________________________________
>> Neuroimaging mailing list
>> Neuroimaging at python.org
>> https://mail.python.org/mailman/listinfo/neuroimaging
>>
>
>
>
> --
> Vanessa Villamia Sochat
> Stanford University
> (603) 321-0676
>
> _______________________________________________
> 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/20150728/34438ffc/attachment.html>

From vsochat at stanford.edu  Wed Jul 29 01:47:11 2015
From: vsochat at stanford.edu (vanessa sochat)
Date: Tue, 28 Jul 2015 16:47:11 -0700
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <CAAQzouOmAFo=C3OX4cGL5FQvgH_Z5DWiLgAGbGSz+MW=Vv0FZw@mail.gmail.com>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CAM=pu+J6K7fe3aEs7RyZ9_ecNf=SJUTNNJzX2FzVq2HAd3ne7Q@mail.gmail.com>
 <20150727052501.GB550510@phare.normalesup.org>
 <CAH6Pt5qMOjwq39UvitoXjEA6LydxmVkbJQN=cwFBgMZct-7U0A@mail.gmail.com>
 <CAN6JmWPYdp-6vYSJz=hJo+4_fRi4X7S5Oqox523mUT+YxZqumA@mail.gmail.com>
 <CA+X4w0xVvQ=yQHamjta8=EaGA+Dnts5oUBD+qMKvsdECWskbVQ@mail.gmail.com>
 <CAH6Pt5rkGXkPoiWB4HX6eVsi1xS=ZKspe61azxTrmnRwnyy3ag@mail.gmail.com>
 <CA+X4w0yQvYEpAb3202Uhyge_ARDQ4OoaH9cNJ-skCdEx8eORkw@mail.gmail.com>
 <CAH6Pt5rmtq4HK7+pN2U2RYueX4i1gkE=MhEwUrfK_=BP_4MBjQ@mail.gmail.com>
 <55B7B3FE.8090801@stanford.edu>
 <CAM=pu+Jkq=UiG7qq8AL5t2BstwymXeAATx4Vs9JaeQ3fDN015Q@mail.gmail.com>
 <CAM=pu++AaY=rRvV_JX8tGpQ=7tMSTTi8rFFP-684jSEToTbRUg@mail.gmail.com>
 <87zj2g542q.fsf@berkeley.edu>
 <CAM=pu+JzmN2zM-Yz+qewbwRPpvGVuRpt=av6cTDz0A=3+Yzptg@mail.gmail.com>
 <CAAQzouOmAFo=C3OX4cGL5FQvgH_Z5DWiLgAGbGSz+MW=Vv0FZw@mail.gmail.com>
Message-ID: <CAM=pu+KKyGVqimzMbhL83H7CURk3PCOvFq4GKsx5BF6WhZE7+Q@mail.gmail.com>

Excellent!

On Tue, Jul 28, 2015 at 4:43 PM, Chris Filo Gorgolewski <
krzysztof.gorgolewski at gmail.com> wrote:

> CircleCI can do this. This is how nilearn docs are being built (from
> sphinx):
> https://circle-artifacts.com/gh/nilearn/nilearn/234/artifacts/0/home/ubuntu/nilearn/doc/_build/html/building_blocks/index.html
>
> Best,
> Chris
>
> On Tue, Jul 28, 2015 at 4:37 PM, vanessa sochat <vsochat at stanford.edu>
> wrote:
>
>> Now that the design is (somewhat) materialized, if you guys want to hash
>> it out and decide an optimal solution, I'm down for converting to any
>> framework. Details can be worked on later. I haven't used anything outside
>> flask so I can't offer an opinion, but I do think it should have the
>> qualities that we've been discussing.  I wonder if there are continuous
>> integration services that would render an entire PR for preview before
>> accepting? That would be optimal.
>>
>> On Tue, Jul 28, 2015 at 3:07 PM, Stefan van der Walt <
>> stefanv at berkeley.edu> wrote:
>>
>>> On 2015-07-28 14:50:09, vanessa sochat <vsochat at stanford.edu> wrote:
>>>
>>>>    - All content / links must be https. This means it's best to
>>>> serve most of our own css/js files, and embedded content that    is not
>>>> https will not render (for example, click on the    embedded nbviewer post
>>>>   <https://vsoch.github.io/nipy/pages/7-28-2015-embed-ipython/>,
>>>> and then inspect the browser to see the error)
>>>>
>>>
>>> This will be an issue whenever you use an iframe, I suspect, but not if
>>> you simply embed static content.
>>>
>>>     - The freezing process didn't grab the custom pages for some
>>>> reason, and it worked when I did this    <
>>>> https://github.com/vsoch/nipy/blob/master/code/views.py#L46>.    This
>>>> would mean that adding a project, it would be required    to have a
>>>> template for it. That comes down to copying a file    and renaming it to
>>>> the project name.
>>>>
>>>
>>> I think following this route will cause a lot of headaches--Flask isn't
>>> really meant to be converted to static pages, so we may find ourselves
>>> swimming against the stream more often than not.
>>>
>>> St?fan
>>>
>>> _______________________________________________
>>> Neuroimaging mailing list
>>> Neuroimaging at python.org
>>> https://mail.python.org/mailman/listinfo/neuroimaging
>>>
>>
>>
>>
>> --
>> Vanessa Villamia Sochat
>> Stanford University
>> (603) 321-0676
>>
>> _______________________________________________
>> 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
>
>


-- 
Vanessa Villamia Sochat
Stanford University
(603) 321-0676
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150728/c32f1d42/attachment.html>

From njvack at wisc.edu  Wed Jul 29 04:16:36 2015
From: njvack at wisc.edu (Nate Vack)
Date: Wed, 29 Jul 2015 02:16:36 +0000
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <CAM=pu++AaY=rRvV_JX8tGpQ=7tMSTTi8rFFP-684jSEToTbRUg@mail.gmail.com>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CAM=pu+J6K7fe3aEs7RyZ9_ecNf=SJUTNNJzX2FzVq2HAd3ne7Q@mail.gmail.com>
 <20150727052501.GB550510@phare.normalesup.org>
 <CAH6Pt5qMOjwq39UvitoXjEA6LydxmVkbJQN=cwFBgMZct-7U0A@mail.gmail.com>
 <CAN6JmWPYdp-6vYSJz=hJo+4_fRi4X7S5Oqox523mUT+YxZqumA@mail.gmail.com>
 <CA+X4w0xVvQ=yQHamjta8=EaGA+Dnts5oUBD+qMKvsdECWskbVQ@mail.gmail.com>
 <CAH6Pt5rkGXkPoiWB4HX6eVsi1xS=ZKspe61azxTrmnRwnyy3ag@mail.gmail.com>
 <CA+X4w0yQvYEpAb3202Uhyge_ARDQ4OoaH9cNJ-skCdEx8eORkw@mail.gmail.com>
 <CAH6Pt5rmtq4HK7+pN2U2RYueX4i1gkE=MhEwUrfK_=BP_4MBjQ@mail.gmail.com>
 <55B7B3FE.8090801@stanford.edu>
 <CAM=pu+Jkq=UiG7qq8AL5t2BstwymXeAATx4Vs9JaeQ3fDN015Q@mail.gmail.com>
 <CAM=pu++AaY=rRvV_JX8tGpQ=7tMSTTi8rFFP-684jSEToTbRUg@mail.gmail.com>
Message-ID: <CA+1BpOuoWU-CBa4ztfFd7gpSh=P9aaPG=2inDkn4qoKZYWEtYg@mail.gmail.com>

On Tue, Jul 28, 2015 at 4:51 PM vanessa sochat <vsochat at stanford.edu> wrote:


> https://vsoch.github.io/nipy
>

I don't know if this is the appropriate time for this feedback (I didn't
realize the redesigned site was actually going to go live!) but this site
is really, really strange on my iPhone. I don't even know how to describe
it well, it's like it's horizontal scrolling by percentage or something.

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

From vsochat at stanford.edu  Wed Jul 29 04:20:47 2015
From: vsochat at stanford.edu (vanessa sochat)
Date: Tue, 28 Jul 2015 19:20:47 -0700
Subject: [Neuroimaging] Nipy.org new website needs a complete remake
In-Reply-To: <CA+1BpOuoWU-CBa4ztfFd7gpSh=P9aaPG=2inDkn4qoKZYWEtYg@mail.gmail.com>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CAM=pu+J6K7fe3aEs7RyZ9_ecNf=SJUTNNJzX2FzVq2HAd3ne7Q@mail.gmail.com>
 <20150727052501.GB550510@phare.normalesup.org>
 <CAH6Pt5qMOjwq39UvitoXjEA6LydxmVkbJQN=cwFBgMZct-7U0A@mail.gmail.com>
 <CAN6JmWPYdp-6vYSJz=hJo+4_fRi4X7S5Oqox523mUT+YxZqumA@mail.gmail.com>
 <CA+X4w0xVvQ=yQHamjta8=EaGA+Dnts5oUBD+qMKvsdECWskbVQ@mail.gmail.com>
 <CAH6Pt5rkGXkPoiWB4HX6eVsi1xS=ZKspe61azxTrmnRwnyy3ag@mail.gmail.com>
 <CA+X4w0yQvYEpAb3202Uhyge_ARDQ4OoaH9cNJ-skCdEx8eORkw@mail.gmail.com>
 <CAH6Pt5rmtq4HK7+pN2U2RYueX4i1gkE=MhEwUrfK_=BP_4MBjQ@mail.gmail.com>
 <55B7B3FE.8090801@stanford.edu>
 <CAM=pu+Jkq=UiG7qq8AL5t2BstwymXeAATx4Vs9JaeQ3fDN015Q@mail.gmail.com>
 <CAM=pu++AaY=rRvV_JX8tGpQ=7tMSTTi8rFFP-684jSEToTbRUg@mail.gmail.com>
 <CA+1BpOuoWU-CBa4ztfFd7gpSh=P9aaPG=2inDkn4qoKZYWEtYg@mail.gmail.com>
Message-ID: <CAM=pu+KVSWFO66Epn0sN0z16V3tw3Wp5u9WxbHOmhUJ3Vz6FDw@mail.gmail.com>

haha, I definitely didn't test anything on mobile... I think the culprit is
this code:

https://github.com/vsoch/nipy/blob/master/static/css/style.css#L220

A little tag along from a copy paste that shouldn't have been included :)
I'll test this out properly and debug, likely this weekend. Thanks for
catching it!

On Tue, Jul 28, 2015 at 7:16 PM, Nate Vack <njvack at wisc.edu> wrote:

> On Tue, Jul 28, 2015 at 4:51 PM vanessa sochat <vsochat at stanford.edu>
> wrote:
>
>
>> https://vsoch.github.io/nipy
>>
>
> I don't know if this is the appropriate time for this feedback (I didn't
> realize the redesigned site was actually going to go live!) but this site
> is really, really strange on my iPhone. I don't even know how to describe
> it well, it's like it's horizontal scrolling by percentage or something.
>
> -n
>
> _______________________________________________
> Neuroimaging mailing list
> Neuroimaging at python.org
> https://mail.python.org/mailman/listinfo/neuroimaging
>
>


-- 
Vanessa Villamia Sochat
Stanford University
(603) 321-0676
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150728/abb917d0/attachment-0001.html>

From effigies at bu.edu  Wed Jul 29 19:14:17 2015
From: effigies at bu.edu (Christopher J Markiewicz)
Date: Wed, 29 Jul 2015 13:14:17 -0400
Subject: [Neuroimaging] MNI-Talairach coordinate transforms
Message-ID: <55B909E9.9080407@bu.edu>

Hi all,

I'm interested in having coordinate transforms between MNI and Talairach
template spaces in the nipy ecosystem, and want to know where people
think these would fit, both in terms of which subproject and API.
Matthew suggested[0] either nipy or nibabel for subproject. It feels
slightly beyond the scope of nibabel to me, but I don't have a problem
with either choice.

Thanks for your thoughts!

[0] https://github.com/nipy/nipy/issues/336

-- 
Christopher J Markiewicz
Ph.D. Candidate, Quantitative Neuroscience Laboratory
Boston University



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150729/959abe15/attachment.sig>

From jbpoline at gmail.com  Wed Jul 29 19:27:52 2015
From: jbpoline at gmail.com (JB Poline)
Date: Wed, 29 Jul 2015 10:27:52 -0700
Subject: [Neuroimaging] [Nipy-devel] MNI-Talairach coordinate transforms
In-Reply-To: <55B90914.6030405@bu.edu>
References: <55B90914.6030405@bu.edu>
Message-ID: <CALMaa81tkzh-m=Jpc89+sFp3WmoGyGfQ7hLRoPGf1Gp986gX8w@mail.gmail.com>

The nipy list has been moved here
cheers
JB

On Wed, Jul 29, 2015 at 10:10 AM, Christopher J Markiewicz <effigies at bu.edu>
wrote:

> Hi all,
>
> I'm interested in having coordinate transforms between MNI and Talairach
> template spaces in the nipy ecosystem, and want to know where people
> think these would fit, both in terms of which subproject and API.
> Matthew suggested[0] either nipy or nibabel for subproject. It feels
> slightly beyond the scope of nibabel to me, but I don't have a problem
> with either choice.
>
> Thanks for your thoughts!
>
> [0] https://github.com/nipy/nipy/issues/336
>
> --
> Christopher J Markiewicz
> Ph.D. Candidate, Quantitative Neuroscience Laboratory
> Boston University
>
>
> _______________________________________________
> Nipy-devel mailing list
> Nipy-devel at neuroimaging.scipy.org
> http://mail.scipy.org/mailman/listinfo/nipy-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150729/aa07ba53/attachment.html>

From arokem at gmail.com  Wed Jul 29 20:06:02 2015
From: arokem at gmail.com (Ariel Rokem)
Date: Wed, 29 Jul 2015 11:06:02 -0700
Subject: [Neuroimaging] FA images Was: Nipy.org new website needs a
 complete remake
In-Reply-To: <20150727174426.GW705713@phare.normalesup.org>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CAM=pu+J6K7fe3aEs7RyZ9_ecNf=SJUTNNJzX2FzVq2HAd3ne7Q@mail.gmail.com>
 <20150727052501.GB550510@phare.normalesup.org>
 <CA+X4w0z-WpsKk0gBu9pmoaDVCDFZyHQfWLtNokFtJURWGFRCuQ@mail.gmail.com>
 <20150727174426.GW705713@phare.normalesup.org>
Message-ID: <CA+X4w0y4FsorxWsZMgjM2_HOmf6Oavev=kJmO3d1Ka-3vfvWjw@mail.gmail.com>

On Mon, Jul 27, 2015 at 10:44 AM, Gael Varoquaux <
gael.varoquaux at normalesup.org> wrote:

> On Mon, Jul 27, 2015 at 08:56:08AM -0700, Ariel Rokem wrote:
> >     PS: Vanessa: Nilearn is not only for fMRI. It's for statistical
> analysis
> >     of images. It is also used for anatomical images:
> >     http://nilearn.github.io/auto_examples/decoding/plot_oasis_vbm.html
> >     If we could get a preprocessed, openly downloadable set of images of
> eg
> >     FA, we would do an example with diffusion too.
>
> > Completely off-topic, but I can't resist: if only there was an
> > open-source project that computed FA images from freely available
> > diffusion MRI data-sets!
>
> Well, you're welcome to help us with preprocessing and pitching a
> relevant prediction problem from this data. I know nothing about
> diffusion and nothing about the datasets you are talking about. In my
> experience, writing a relevant example requires understanding the data
> and the questions. If you, or someone else, gets us to the point where
> there is a set of nifti images of FA with condition A and condition B,
> and helps us write the story, than we have an example.
>

Hmm. Interesting idea. I am looking around for something along these lines.
I think that there are some freely available data-sets that are already
preprocessed, so could be used in this way. Let me think about how to go
about this.


> Ga?l
> _______________________________________________
> 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/20150729/d2bde27c/attachment.html>

From kw401 at cam.ac.uk  Fri Jul 31 12:00:34 2015
From: kw401 at cam.ac.uk (Kirstie Whitaker)
Date: Fri, 31 Jul 2015 11:00:34 +0100
Subject: [Neuroimaging] [pysurfer] making background brain more transparent
Message-ID: <CAAipwu8OSGUAA2t6nGY+LrBt-SpZpM6=mVA4oqkpum7_tEYqaw@mail.gmail.com>

Hi everyone,

I'd like to make the background brain in pysurfer a little more
transparent, so I'm looking for an "alpha" flag or something similar. I
don't think this yet exists according to the documentation on changing the
curvature color scheme
<http://pysurfer.github.io/documentation/custom_viz.html#changing-the-curvature-color-scheme>
but I wonder if anyone has a hack that I could implement?

An alternative to the alpha parameter would be to create a fifth
(personalised) color scheme perhaps?

Thanks!
(This is also a question on neurostars.org <http://neurostars.org/p/3315/>
if anyone wants to answer there instead!)

Kx

-- 
Kirstie Whitaker, PhD
Research Associate

Department of Psychiatry
University of Cambridge

*Mailing Address*
Brain Mapping Unit
Department of Psychiatry
Sir William Hardy Building
Downing Street
Cambridge CB2 3EB

*Phone: *+44 7583 535 307
*Website:* www.kirstiewhitaker.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150731/dfd4f7ce/attachment.html>

From mwaskom at stanford.edu  Fri Jul 31 16:54:48 2015
From: mwaskom at stanford.edu (Michael Waskom)
Date: Fri, 31 Jul 2015 07:54:48 -0700
Subject: [Neuroimaging] [pysurfer] making background brain more
	transparent
In-Reply-To: <CAAipwu8OSGUAA2t6nGY+LrBt-SpZpM6=mVA4oqkpum7_tEYqaw@mail.gmail.com>
References: <CAAipwu8OSGUAA2t6nGY+LrBt-SpZpM6=mVA4oqkpum7_tEYqaw@mail.gmail.com>
Message-ID: <CAKZ-Uq3g5KBCPQOnvQ2w9VZfUXtqFhM=g9JC_amxZGWJuWLUSw@mail.gmail.com>

Hi Kristie,

I think I'm a bit confused about your question. What do you mean make it
*more* transparent? As far as I know, the brain geometry is drawn at full
opacity so I might not understand what you are trying to do.

Best,
Michael

On Fri, Jul 31, 2015 at 3:00 AM, Kirstie Whitaker <kw401 at cam.ac.uk> wrote:

> Hi everyone,
>
> I'd like to make the background brain in pysurfer a little more
> transparent, so I'm looking for an "alpha" flag or something similar. I
> don't think this yet exists according to the documentation on changing
> the curvature color scheme
> <http://pysurfer.github.io/documentation/custom_viz.html#changing-the-curvature-color-scheme>
> but I wonder if anyone has a hack that I could implement?
>
> An alternative to the alpha parameter would be to create a fifth
> (personalised) color scheme perhaps?
>
> Thanks!
> (This is also a question on neurostars.org <http://neurostars.org/p/3315/>
> if anyone wants to answer there instead!)
>
> Kx
>
> --
> Kirstie Whitaker, PhD
> Research Associate
>
> Department of Psychiatry
> University of Cambridge
>
> *Mailing Address*
> Brain Mapping Unit
> Department of Psychiatry
> Sir William Hardy Building
> Downing Street
> Cambridge CB2 3EB
>
> *Phone: *+44 7583 535 307
> *Website:* www.kirstiewhitaker.com
>
>
> _______________________________________________
> 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/20150731/5101c23e/attachment.html>

From njvack at wisc.edu  Fri Jul 31 18:13:33 2015
From: njvack at wisc.edu (Nate Vack)
Date: Fri, 31 Jul 2015 16:13:33 +0000
Subject: [Neuroimaging] Spamalize .voi reading for nibabel?
Message-ID: <CA+1BpOs=8HgQVBXBR1ymN-PvawWdONhfB11d_HhD=KUzwkwa4A@mail.gmail.com>

Hi all,

Here at Wisconsin, we used to draw volumes of interest in an in-house tool
called Spamalize, created by Terry Oakes. More recently, we wanted to
convert those .voi files into nifti files, and found doing that in IDL was
not working right.

So! I wrote something in python. It's up here:

https://github.com/njvack/voitools

I don't know if this is widely-enough used to be incorporated into nibabel,
but I'd be happy to try and bring it in there if it would be useful.

Thoughts?
-Nate
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150731/39e1fa24/attachment.html>

From kw401 at cam.ac.uk  Fri Jul 31 18:54:27 2015
From: kw401 at cam.ac.uk (Kirstie Whitaker)
Date: Fri, 31 Jul 2015 17:54:27 +0100
Subject: [Neuroimaging] [pysurfer] making background brain more
	transparent
In-Reply-To: <CAKZ-Uq3g5KBCPQOnvQ2w9VZfUXtqFhM=g9JC_amxZGWJuWLUSw@mail.gmail.com>
References: <CAAipwu8OSGUAA2t6nGY+LrBt-SpZpM6=mVA4oqkpum7_tEYqaw@mail.gmail.com>
 <CAKZ-Uq3g5KBCPQOnvQ2w9VZfUXtqFhM=g9JC_amxZGWJuWLUSw@mail.gmail.com>
Message-ID: <CAAipwu8okTP5-FUMx1tGaAc6KNq+kBTiickae=NVd+=2sEMQ3w@mail.gmail.com>

Sorry - Basically I want to just make the background brain stand out a
little less in my figures so what I'd hoped was that it would be possible
to simple "fade out" the background brain (not my ROI overlays) a little.

If I were showing a slice in matplotlib I'd do something like this:

import  numpy as np
import matplotlib.pylab as plt
a = np.random.rand(100,100)
plt.imshow(a, alpha=0.5, cmap='gray')
plt.show()

(with maybe a being my brain slice rather than just random numbers)

Sorry I wasn't clear - does that help??

Kx

On 31 July 2015 at 15:54, Michael Waskom <mwaskom at stanford.edu> wrote:

> Hi Kristie,
>
> I think I'm a bit confused about your question. What do you mean make it
> *more* transparent? As far as I know, the brain geometry is drawn at full
> opacity so I might not understand what you are trying to do.
>
> Best,
> Michael
>
> On Fri, Jul 31, 2015 at 3:00 AM, Kirstie Whitaker <kw401 at cam.ac.uk> wrote:
>
>> Hi everyone,
>>
>> I'd like to make the background brain in pysurfer a little more
>> transparent, so I'm looking for an "alpha" flag or something similar. I
>> don't think this yet exists according to the documentation on changing
>> the curvature color scheme
>> <http://pysurfer.github.io/documentation/custom_viz.html#changing-the-curvature-color-scheme>
>> but I wonder if anyone has a hack that I could implement?
>>
>> An alternative to the alpha parameter would be to create a fifth
>> (personalised) color scheme perhaps?
>>
>> Thanks!
>> (This is also a question on neurostars.org
>> <http://neurostars.org/p/3315/> if anyone wants to answer there instead!)
>>
>> Kx
>>
>> --
>> Kirstie Whitaker, PhD
>> Research Associate
>>
>> Department of Psychiatry
>> University of Cambridge
>>
>> *Mailing Address*
>> Brain Mapping Unit
>> Department of Psychiatry
>> Sir William Hardy Building
>> Downing Street
>> Cambridge CB2 3EB
>>
>> *Phone: *+44 7583 535 307
>> *Website:* www.kirstiewhitaker.com
>>
>>
>> _______________________________________________
>> 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
>
>


-- 
Kirstie Whitaker, PhD
Research Associate

Department of Psychiatry
University of Cambridge

*Mailing Address*
Brain Mapping Unit
Department of Psychiatry
Sir William Hardy Building
Downing Street
Cambridge CB2 3EB

*Phone: *+44 7583 535 307
*Website:* www.kirstiewhitaker.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150731/aa125430/attachment.html>

From vsochat at stanford.edu  Fri Jul 31 19:09:01 2015
From: vsochat at stanford.edu (vanessa sochat)
Date: Fri, 31 Jul 2015 10:09:01 -0700
Subject: [Neuroimaging] [pysurfer] making background brain more
	transparent
In-Reply-To: <CAAipwu8okTP5-FUMx1tGaAc6KNq+kBTiickae=NVd+=2sEMQ3w@mail.gmail.com>
References: <CAAipwu8OSGUAA2t6nGY+LrBt-SpZpM6=mVA4oqkpum7_tEYqaw@mail.gmail.com>
 <CAKZ-Uq3g5KBCPQOnvQ2w9VZfUXtqFhM=g9JC_amxZGWJuWLUSw@mail.gmail.com>
 <CAAipwu8okTP5-FUMx1tGaAc6KNq+kBTiickae=NVd+=2sEMQ3w@mail.gmail.com>
Message-ID: <CAM=pu++m2D5M6o+J=qtrVszdJ5EqkgY3i8HSvaEB6b+Lxv+h0A@mail.gmail.com>

Can't you just save as an svg, and then edit the color / alpha of the path?
Like:

<svg>
<g id="icon-cart">
<path opacity=0.8 fill="red" d="M30.549 6.077c-1.062-0.303-2.169
0.312-2.473 1.374l-0.157
0.549h-18.654l-0.281-2.248c-0.125-1.001-0.976-1.752-1.985-1.752h-5c-1.105
0-2 0.895-2 2s0.895 2 2 2h3.234l1.781 14.248c0.125 1.001 0.976 1.752 1.985
1.752h17c0.893 0 1.678-0.592
1.923-1.451l4-14c0.303-1.062-0.312-2.169-1.374-2.473zM16 16v-2h4v2h-4zM20
18v2h-4v-2h4zM16 12v-2h4v2h-4zM9.516 10h4.484v2h-4.234l-0.25-2zM10.016
14h3.984v2h-3.734l-0.25-2zM10.516 18h3.484v2h-3.234l-0.25-2zM24.491
20h-2.491v-2h3.063l-0.571 2zM25.634 16h-3.634v-2h4.206l-0.571 2zM26.777
12h-4.777v-2h5.349l-0.571 2zM8 29c0-1.657 1.343-3 3-3s3 1.343 3 3c0
1.657-1.343 3-3 3-1.657 0-3-1.343-3-3zM20 29c0-1.657 1.343-3 3-3s3 1.343 3
3c0 1.657-1.343 3-3 3-1.657 0-3-1.343-3-3z"></path>
</g>
</svg>

Play around with it here:

http://codepen.io/vsoch/pen/JdwKNQ

On Fri, Jul 31, 2015 at 9:54 AM, Kirstie Whitaker <kw401 at cam.ac.uk> wrote:

> Sorry - Basically I want to just make the background brain stand out a
> little less in my figures so what I'd hoped was that it would be possible
> to simple "fade out" the background brain (not my ROI overlays) a little.
>
> If I were showing a slice in matplotlib I'd do something like this:
>
> import  numpy as np
> import matplotlib.pylab as plt
> a = np.random.rand(100,100)
> plt.imshow(a, alpha=0.5, cmap='gray')
> plt.show()
>
> (with maybe a being my brain slice rather than just random numbers)
>
> Sorry I wasn't clear - does that help??
>
> Kx
>
> On 31 July 2015 at 15:54, Michael Waskom <mwaskom at stanford.edu> wrote:
>
>> Hi Kristie,
>>
>> I think I'm a bit confused about your question. What do you mean make it
>> *more* transparent? As far as I know, the brain geometry is drawn at full
>> opacity so I might not understand what you are trying to do.
>>
>> Best,
>> Michael
>>
>> On Fri, Jul 31, 2015 at 3:00 AM, Kirstie Whitaker <kw401 at cam.ac.uk>
>> wrote:
>>
>>> Hi everyone,
>>>
>>> I'd like to make the background brain in pysurfer a little more
>>> transparent, so I'm looking for an "alpha" flag or something similar. I
>>> don't think this yet exists according to the documentation on changing
>>> the curvature color scheme
>>> <http://pysurfer.github.io/documentation/custom_viz.html#changing-the-curvature-color-scheme>
>>> but I wonder if anyone has a hack that I could implement?
>>>
>>> An alternative to the alpha parameter would be to create a fifth
>>> (personalised) color scheme perhaps?
>>>
>>> Thanks!
>>> (This is also a question on neurostars.org
>>> <http://neurostars.org/p/3315/> if anyone wants to answer there
>>> instead!)
>>>
>>> Kx
>>>
>>> --
>>> Kirstie Whitaker, PhD
>>> Research Associate
>>>
>>> Department of Psychiatry
>>> University of Cambridge
>>>
>>> *Mailing Address*
>>> Brain Mapping Unit
>>> Department of Psychiatry
>>> Sir William Hardy Building
>>> Downing Street
>>> Cambridge CB2 3EB
>>>
>>> *Phone: *+44 7583 535 307
>>> *Website:* www.kirstiewhitaker.com
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
>
> --
> Kirstie Whitaker, PhD
> Research Associate
>
> Department of Psychiatry
> University of Cambridge
>
> *Mailing Address*
> Brain Mapping Unit
> Department of Psychiatry
> Sir William Hardy Building
> Downing Street
> Cambridge CB2 3EB
>
> *Phone: *+44 7583 535 307
> *Website:* www.kirstiewhitaker.com
>
> _______________________________________________
> Neuroimaging mailing list
> Neuroimaging at python.org
> https://mail.python.org/mailman/listinfo/neuroimaging
>
>


-- 
Vanessa Villamia Sochat
Stanford University
(603) 321-0676
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150731/09cd2bcc/attachment.html>

From mwaskom at stanford.edu  Fri Jul 31 19:15:56 2015
From: mwaskom at stanford.edu (Michael Waskom)
Date: Fri, 31 Jul 2015 10:15:56 -0700
Subject: [Neuroimaging] [pysurfer] making background brain more
	transparent
In-Reply-To: <CAAipwu8okTP5-FUMx1tGaAc6KNq+kBTiickae=NVd+=2sEMQ3w@mail.gmail.com>
References: <CAAipwu8OSGUAA2t6nGY+LrBt-SpZpM6=mVA4oqkpum7_tEYqaw@mail.gmail.com>
 <CAKZ-Uq3g5KBCPQOnvQ2w9VZfUXtqFhM=g9JC_amxZGWJuWLUSw@mail.gmail.com>
 <CAAipwu8okTP5-FUMx1tGaAc6KNq+kBTiickae=NVd+=2sEMQ3w@mail.gmail.com>
Message-ID: <CAKZ-Uq0r28WRZZV3PLSm9JcFmHqPSVAQ1avtSUX3mH1-e2WCAQ@mail.gmail.com>

Hi Kristie,

If you decrease the alpha value of the anatomy mesh, you'll be able to see
through it. While this can be useful for "glass brain" type volume
visualizations, it's probably not going to give you the effect you want for
showing surface-based ROIs, as it will just be hard to tell what you're
looking at (in my experience). For that reason, alpha isn't exposed as a
parameter. I would say though that the development version of pysurfer lets
you pass custom parameters for the colormap used to show the curvature (in
binary or continuous values) so you could play around with that to see if
you can find something that deemphasizes the anatomy. You can also plot
with curv=False, of course, but that makes it harder to understand where
the ROIs are.

Hope that helps,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150731/d813ff74/attachment.html>

From kw401 at cam.ac.uk  Fri Jul 31 19:19:34 2015
From: kw401 at cam.ac.uk (Kirstie Whitaker)
Date: Fri, 31 Jul 2015 18:19:34 +0100
Subject: [Neuroimaging] [pysurfer] making background brain more
	transparent
In-Reply-To: <CAKZ-Uq0r28WRZZV3PLSm9JcFmHqPSVAQ1avtSUX3mH1-e2WCAQ@mail.gmail.com>
References: <CAAipwu8OSGUAA2t6nGY+LrBt-SpZpM6=mVA4oqkpum7_tEYqaw@mail.gmail.com>
 <CAKZ-Uq3g5KBCPQOnvQ2w9VZfUXtqFhM=g9JC_amxZGWJuWLUSw@mail.gmail.com>
 <CAAipwu8okTP5-FUMx1tGaAc6KNq+kBTiickae=NVd+=2sEMQ3w@mail.gmail.com>
 <CAKZ-Uq0r28WRZZV3PLSm9JcFmHqPSVAQ1avtSUX3mH1-e2WCAQ@mail.gmail.com>
Message-ID: <CAAipwu8HrmLUT-YC18GpAQZOrEdPJduphPwEzYe6wadhrxro_w@mail.gmail.com>

Ah yes - very good point - I hadn't thought about the "see through" effect
of changing the alpha parameter.

I'll grab the development version and see if there are any parameters that
my boss likes better than the classic ;)

Thanks Michael and Vanessa for the suggestions!

Kx

On 31 July 2015 at 18:15, Michael Waskom <mwaskom at stanford.edu> wrote:

> Hi Kristie,
>
> If you decrease the alpha value of the anatomy mesh, you'll be able to see
> through it. While this can be useful for "glass brain" type volume
> visualizations, it's probably not going to give you the effect you want for
> showing surface-based ROIs, as it will just be hard to tell what you're
> looking at (in my experience). For that reason, alpha isn't exposed as a
> parameter. I would say though that the development version of pysurfer lets
> you pass custom parameters for the colormap used to show the curvature (in
> binary or continuous values) so you could play around with that to see if
> you can find something that deemphasizes the anatomy. You can also plot
> with curv=False, of course, but that makes it harder to understand where
> the ROIs are.
>
> Hope that helps,
> Michael
>
>
>
> _______________________________________________
> Neuroimaging mailing list
> Neuroimaging at python.org
> https://mail.python.org/mailman/listinfo/neuroimaging
>
>


-- 
Kirstie Whitaker, PhD
Research Associate

Department of Psychiatry
University of Cambridge

*Mailing Address*
Brain Mapping Unit
Department of Psychiatry
Sir William Hardy Building
Downing Street
Cambridge CB2 3EB

*Phone: *+44 7583 535 307
*Website:* www.kirstiewhitaker.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150731/c05231c3/attachment.html>

From jomaroceguedag at gmail.com  Fri Jul 31 19:29:00 2015
From: jomaroceguedag at gmail.com (Jesus-Omar Ocegueda-Gonzalez)
Date: Fri, 31 Jul 2015 12:29:00 -0500
Subject: [Neuroimaging] Technical details managing Python versions and
	packages.
Message-ID: <CAON14K3Hmyx7MqoJWqdUbWUtHmHR8xXKguLS-AKXchx6qsD+mw@mail.gmail.com>

Hello Python experts!,
I just wanted to ask if anyone of you could point me out to a good
reference to learn a good way to manage different python versions and their
corresponding packages. This is a bit embarrassing, but I guess the
following story may seem familiar to some people (probably those days when
you were python newbies): I had python 2.7 with a lot of packages already
installed, some of them installed with pip, some with easy_install, some
with apt-get, some built manually from source code... who knows? I just
sequentially tried each installation way, following instructions I found in
random internet pages whenever something went wrong, until one of the
installation instructions suddenly worked, and just moved on. Then, at some
point, I tried to install Python 3 to reproduce a bug reported to only
happen there, just to discover that now nothing works, I have no numpy, no
nibabel, none of the basic packages, so I tried to "re-install" them
(following instructions from random internet pages when something goes
wrong... again), see the pattern?. So the root cause is obviously that I
have no idea of what's going on behind scenes when I use these "mysterious"
installers, and how they affect my environment, which of them are
compatible with each other and which are not, etc.

So, to break the pattern, I think this is time to really learn exactly
what's going on when we "install" packages with different tools, and how to
correctly manage different versions. Could anyone point me out to a good
reference to learn these details (e.g. Is there a good way to actually
remove everything so we can start a totally fresh installation)?

Thank you very much in advance!.
With warm regards,
-A frustrated -but motivated- Python user.
-- 
"Cada quien es due?o de lo que calla y esclavo de lo que dice"
-Proverbio chino.
"We all are owners of what we keep silent and slaves of what we say"
-Chinese proverb.

http://www.cimat.mx/~omar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/neuroimaging/attachments/20150731/1c8f800a/attachment.html>

From bnniii at uw.edu  Fri Jul 31 19:50:20 2015
From: bnniii at uw.edu (Nolan Nichols)
Date: Fri, 31 Jul 2015 10:50:20 -0700
Subject: [Neuroimaging] Technical details managing Python versions and
	packages.
In-Reply-To: <CAON14K3Hmyx7MqoJWqdUbWUtHmHR8xXKguLS-AKXchx6qsD+mw@mail.gmail.com>
References: <CAON14K3Hmyx7MqoJWqdUbWUtHmHR8xXKguLS-AKXchx6qsD+mw@mail.gmail.com>
Message-ID: <CALLiDF03NwDD=dX_gyWR9itMKuyMWYPrTxq-uURLwbfqHtOX_g@mail.gmail.com>

?Not exactly what you asked for, but one suggestion is to standardize your
approach to installing packages. From my early experience with Python,
package management was notoriously confusing and mixing apt-get,
easy_install, and pip was a recipe for disaster.

I've switched to using the "Anaconda" distribution of Python and it has
made installing libraries a really smooth process. I use "miniconda" (
http://conda.pydata.org/miniconda.html) and the "conda" tool to install
anything available in their software registry and then I use 'pip' to
install everything else. I steer clear of apt-get and easy_install.

Conda also makes it super easy to create sandboxed environments to test out
new tools. For example, once miniconda is installed you can:

# create an environment to use nibabel
> conda create -n nibabel-env pip ipython scipy
> # activate the environment
> source activate ?nibabal
> # use pip to install a libary not available through conda
> pip install nibabel
> # turn off the nibabel environment and switch back to the main installation
> source deactivate


?If you give that a shot it will essentially ignore everything else you've
installed and give you a clean slate to work from.?


?Cheers,

Nolan?


On Fri, Jul 31, 2015 at 10:29 AM, Jesus-Omar Ocegueda-Gonzalez <
jomaroceguedag at gmail.com> wrote:

> Hello Python experts!,
> I just wanted to ask if anyone of you could point me out to a good
> reference to learn a good way to manage different python versions and their
> corresponding packages. This is a bit embarrassing, but I guess the
> following story may seem familiar to some people (probably those days when
> you were python newbies): I had python 2.7 with a lot of packages already
> installed, some of them installed with pip, some with easy_install, some
> with apt-get, some built manually from source code... who knows? I just
> sequentially tried each installation way, following instructions I found in
> random internet pages whenever something went wrong, until one of the
> installation instructions suddenly worked, and just moved on. Then, at some
> point, I tried to install Python 3 to reproduce a bug reported to only
> happen there, just to discover that now nothing works, I have no numpy, no
> nibabel, none of the basic packages, so I tried to "re-install" them
> (following instructions from random internet pages when something goes
> wrong... again), see the pattern?. So the root cause is obviously that I
> have no idea of what's going on behind scenes when I use these "mysterious"
> installers, and how they affect my environment, which of them are
> compatible with each other and which are not, etc.
>
> So, to break the pattern, I think this is time to really learn exactly
> what's going on when we "install" packages with different tools, and how to
> correctly manage different versions. Could anyone point me out to a good
> reference to learn these details (e.g. Is there a good way to actually
> remove everything so we can start a totally fresh installation)?
>
> Thank you very much in advance!.
> With warm regards,
> -A frustrated -but motivated- Python user.
> --
> "Cada quien es due?o de lo que calla y esclavo de lo que dice"
> -Proverbio chino.
> "We all are owners of what we keep silent and slaves of what we say"
> -Chinese proverb.
>
> http://www.cimat.mx/~omar
>
> _______________________________________________
> 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/20150731/202187c8/attachment.html>

From matthew.brett at gmail.com  Fri Jul 31 19:57:24 2015
From: matthew.brett at gmail.com (Matthew Brett)
Date: Fri, 31 Jul 2015 18:57:24 +0100
Subject: [Neuroimaging] Technical details managing Python versions and
	packages.
In-Reply-To: <CAON14K3Hmyx7MqoJWqdUbWUtHmHR8xXKguLS-AKXchx6qsD+mw@mail.gmail.com>
References: <CAON14K3Hmyx7MqoJWqdUbWUtHmHR8xXKguLS-AKXchx6qsD+mw@mail.gmail.com>
Message-ID: <CAH6Pt5rBPkOtf2NyPsY-N59LSP3LG81x=oZe9xGzEvVYFHnFuQ@mail.gmail.com>

Hi Omar,

On Fri, Jul 31, 2015 at 6:29 PM, Jesus-Omar Ocegueda-Gonzalez
<jomaroceguedag at gmail.com> wrote:
> Hello Python experts!,
> I just wanted to ask if anyone of you could point me out to a good reference
> to learn a good way to manage different python versions and their
> corresponding packages. This is a bit embarrassing, but I guess the
> following story may seem familiar to some people (probably those days when
> you were python newbies): I had python 2.7 with a lot of packages already
> installed, some of them installed with pip, some with easy_install, some
> with apt-get, some built manually from source code... who knows? I just
> sequentially tried each installation way, following instructions I found in
> random internet pages whenever something went wrong, until one of the
> installation instructions suddenly worked, and just moved on. Then, at some
> point, I tried to install Python 3 to reproduce a bug reported to only
> happen there, just to discover that now nothing works, I have no numpy, no
> nibabel, none of the basic packages, so I tried to "re-install" them
> (following instructions from random internet pages when something goes
> wrong... again), see the pattern?. So the root cause is obviously that I
> have no idea of what's going on behind scenes when I use these "mysterious"
> installers, and how they affect my environment, which of them are compatible
> with each other and which are not, etc.
>
> So, to break the pattern, I think this is time to really learn exactly
> what's going on when we "install" packages with different tools, and how to
> correctly manage different versions. Could anyone point me out to a good
> reference to learn these details (e.g. Is there a good way to actually
> remove everything so we can start a totally fresh installation)?
>
> Thank you very much in advance!.
> With warm regards,
> -A frustrated -but motivated- Python user.

I'm afraid I don't know of a very good reference.

I think your two options are:

* start from scratch using virtualenv and pip;
* use conda

I prefer virtualenv and pip, because want to support standard Python
packaging, and am worried about the effect of handing over Python
packaging to one company.  Although conda is open-source, almost all
the work and all the hosting is done by employees of Continuum IO.

Having said that, I have the impression that conda is a reliable
solution to the problem of having multiple different Python
environments you want to work on.

If you want to go the virtualenv / pip route, I recommend you start
from scratch.  In particular, easy_install had a very nasty trick of
putting installed packages unconditionally at the top of the Python
search path, using `easy-install.pth` files.

If you're interested to do that, let me know, I'll write up a summary
of what to do.  I guess you are on Debian / Ubuntu?

Cheers,

Matthew

From arokem at gmail.com  Fri Jul 31 20:13:30 2015
From: arokem at gmail.com (Ariel Rokem)
Date: Fri, 31 Jul 2015 11:13:30 -0700
Subject: [Neuroimaging] Technical details managing Python versions and
	packages.
In-Reply-To: <CALLiDF03NwDD=dX_gyWR9itMKuyMWYPrTxq-uURLwbfqHtOX_g@mail.gmail.com>
References: <CAON14K3Hmyx7MqoJWqdUbWUtHmHR8xXKguLS-AKXchx6qsD+mw@mail.gmail.com>
 <CALLiDF03NwDD=dX_gyWR9itMKuyMWYPrTxq-uURLwbfqHtOX_g@mail.gmail.com>
Message-ID: <CA+X4w0xDs4sad5XS_=ZpiBB_mY+h293NSO6EvD=MO=onc-NCJw@mail.gmail.com>

On Fri, Jul 31, 2015 at 10:50 AM, Nolan Nichols <bnniii at uw.edu> wrote:

> ?Not exactly what you asked for, but one suggestion is to standardize your
> approach to installing packages. From my early experience with Python,
> package management was notoriously confusing and mixing apt-get,
> easy_install, and pip was a recipe for disaster.
>
> I've switched to using the "Anaconda" distribution of Python and it has
> made installing libraries a really smooth process. I use "miniconda" (
> http://conda.pydata.org/miniconda.html) and the "conda" tool to install
> anything available in their software registry and then I use 'pip' to
> install everything else. I steer clear of apt-get and easy_install.
>
> Conda also makes it super easy to create sandboxed environments to test
> out new tools. For example, once miniconda is installed you can:
>
> # create an environment to use nibabel
>> conda create -n nibabel-env pip ipython scipy
>> # activate the environment
>> source activate ?nibabal
>> # use pip to install a libary not available through conda
>> pip install nibabel
>> # turn off the nibabel environment and switch back to the main
>> installation
>> source deactivate
>
>
>
Moreover, you can do things like:

conda create -n nibabel-py2 python=2.7 pip ipython scipy

or

conda create -n nibabel-py3 python=3.4 pip ipython scipy

To create envs with different versions of python (or any other library,
e.g. `numpy=1.6`)


> ?If you give that a shot it will essentially ignore everything else you've
> installed and give you a clean slate to work from.?
>
>
> ?Cheers,
>
> Nolan?
>
>
> On Fri, Jul 31, 2015 at 10:29 AM, Jesus-Omar Ocegueda-Gonzalez <
> jomaroceguedag at gmail.com> wrote:
>
>> Hello Python experts!,
>> I just wanted to ask if anyone of you could point me out to a good
>> reference to learn a good way to manage different python versions and their
>> corresponding packages. This is a bit embarrassing, but I guess the
>> following story may seem familiar to some people (probably those days when
>> you were python newbies): I had python 2.7 with a lot of packages already
>> installed, some of them installed with pip, some with easy_install, some
>> with apt-get, some built manually from source code... who knows? I just
>> sequentially tried each installation way, following instructions I found in
>> random internet pages whenever something went wrong, until one of the
>> installation instructions suddenly worked, and just moved on. Then, at some
>> point, I tried to install Python 3 to reproduce a bug reported to only
>> happen there, just to discover that now nothing works, I have no numpy, no
>> nibabel, none of the basic packages, so I tried to "re-install" them
>> (following instructions from random internet pages when something goes
>> wrong... again), see the pattern?. So the root cause is obviously that I
>> have no idea of what's going on behind scenes when I use these "mysterious"
>> installers, and how they affect my environment, which of them are
>> compatible with each other and which are not, etc.
>>
>> So, to break the pattern, I think this is time to really learn exactly
>> what's going on when we "install" packages with different tools, and how to
>> correctly manage different versions. Could anyone point me out to a good
>> reference to learn these details (e.g. Is there a good way to actually
>> remove everything so we can start a totally fresh installation)?
>>
>> Thank you very much in advance!.
>> With warm regards,
>> -A frustrated -but motivated- Python user.
>> --
>> "Cada quien es due?o de lo que calla y esclavo de lo que dice"
>> -Proverbio chino.
>> "We all are owners of what we keep silent and slaves of what we say"
>> -Chinese proverb.
>>
>> http://www.cimat.mx/~omar
>>
>> _______________________________________________
>> 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/20150731/c34e5e4a/attachment-0001.html>

From jbpoline at gmail.com  Fri Jul 31 20:37:59 2015
From: jbpoline at gmail.com (JB Poline)
Date: Fri, 31 Jul 2015 11:37:59 -0700
Subject: [Neuroimaging] Technical details managing Python versions and
	packages.
In-Reply-To: <CA+X4w0xDs4sad5XS_=ZpiBB_mY+h293NSO6EvD=MO=onc-NCJw@mail.gmail.com>
References: <CAON14K3Hmyx7MqoJWqdUbWUtHmHR8xXKguLS-AKXchx6qsD+mw@mail.gmail.com>
 <CALLiDF03NwDD=dX_gyWR9itMKuyMWYPrTxq-uURLwbfqHtOX_g@mail.gmail.com>
 <CA+X4w0xDs4sad5XS_=ZpiBB_mY+h293NSO6EvD=MO=onc-NCJw@mail.gmail.com>
Message-ID: <CALMaa82izjjPZnLXNpMnW5HTpdyvb7ADDPjjhe1Ok+_r5oTB7A@mail.gmail.com>

Hi,

I somehow feel less lonely after your mail J.-Omar: I am also deeply
missing some good reference that would described the mechanisms and
interactions behind the scenes of installations operation. I recently tried
to help a colleague with what seems to be tvtk install issue and I have not
yet recovered (or solved) that ...!

With help from colleagues and friends I ended up doing:

* virtualenvs for python stuff only - cf Matthew's argument
* conda for things that require more than python packages - because you
often need more than python stuff sandboxed

It does mean that I have several things installed several times, but it has
reduced (a little) my level of confusion.

cheers
JB


On Fri, Jul 31, 2015 at 11:13 AM, Ariel Rokem <arokem at gmail.com> wrote:

>
>
> On Fri, Jul 31, 2015 at 10:50 AM, Nolan Nichols <bnniii at uw.edu> wrote:
>
>> ?Not exactly what you asked for, but one suggestion is to standardize
>> your approach to installing packages. From my early experience with Python,
>> package management was notoriously confusing and mixing apt-get,
>> easy_install, and pip was a recipe for disaster.
>>
>> I've switched to using the "Anaconda" distribution of Python and it has
>> made installing libraries a really smooth process. I use "miniconda" (
>> http://conda.pydata.org/miniconda.html) and the "conda" tool to install
>> anything available in their software registry and then I use 'pip' to
>> install everything else. I steer clear of apt-get and easy_install.
>>
>> Conda also makes it super easy to create sandboxed environments to test
>> out new tools. For example, once miniconda is installed you can:
>>
>> # create an environment to use nibabel
>>> conda create -n nibabel-env pip ipython scipy
>>> # activate the environment
>>> source activate ?nibabal
>>> # use pip to install a libary not available through conda
>>> pip install nibabel
>>> # turn off the nibabel environment and switch back to the main
>>> installation
>>> source deactivate
>>
>>
>>
> Moreover, you can do things like:
>
> conda create -n nibabel-py2 python=2.7 pip ipython scipy
>
> or
>
> conda create -n nibabel-py3 python=3.4 pip ipython scipy
>
> To create envs with different versions of python (or any other library,
> e.g. `numpy=1.6`)
>
>
>> ?If you give that a shot it will essentially ignore everything else
>> you've installed and give you a clean slate to work from.?
>>
>>
>> ?Cheers,
>>
>> Nolan?
>>
>>
>> On Fri, Jul 31, 2015 at 10:29 AM, Jesus-Omar Ocegueda-Gonzalez <
>> jomaroceguedag at gmail.com> wrote:
>>
>>> Hello Python experts!,
>>> I just wanted to ask if anyone of you could point me out to a good
>>> reference to learn a good way to manage different python versions and their
>>> corresponding packages. This is a bit embarrassing, but I guess the
>>> following story may seem familiar to some people (probably those days when
>>> you were python newbies): I had python 2.7 with a lot of packages already
>>> installed, some of them installed with pip, some with easy_install, some
>>> with apt-get, some built manually from source code... who knows? I just
>>> sequentially tried each installation way, following instructions I found in
>>> random internet pages whenever something went wrong, until one of the
>>> installation instructions suddenly worked, and just moved on. Then, at some
>>> point, I tried to install Python 3 to reproduce a bug reported to only
>>> happen there, just to discover that now nothing works, I have no numpy, no
>>> nibabel, none of the basic packages, so I tried to "re-install" them
>>> (following instructions from random internet pages when something goes
>>> wrong... again), see the pattern?. So the root cause is obviously that I
>>> have no idea of what's going on behind scenes when I use these "mysterious"
>>> installers, and how they affect my environment, which of them are
>>> compatible with each other and which are not, etc.
>>>
>>> So, to break the pattern, I think this is time to really learn exactly
>>> what's going on when we "install" packages with different tools, and how to
>>> correctly manage different versions. Could anyone point me out to a good
>>> reference to learn these details (e.g. Is there a good way to actually
>>> remove everything so we can start a totally fresh installation)?
>>>
>>> Thank you very much in advance!.
>>> With warm regards,
>>> -A frustrated -but motivated- Python user.
>>> --
>>> "Cada quien es due?o de lo que calla y esclavo de lo que dice"
>>> -Proverbio chino.
>>> "We all are owners of what we keep silent and slaves of what we say"
>>> -Chinese proverb.
>>>
>>> http://www.cimat.mx/~omar
>>>
>>> _______________________________________________
>>> 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: <http://mail.python.org/pipermail/neuroimaging/attachments/20150731/2f90d672/attachment.html>

From d.mor.dom at gmail.com  Thu Jul 30 05:38:27 2015
From: d.mor.dom at gmail.com (David Moreno-Dominguez)
Date: Thu, 30 Jul 2015 05:38:27 +0200
Subject: [Neuroimaging] FA images Was: Nipy.org new website needs a
 complete remake
In-Reply-To: <CA+X4w0y4FsorxWsZMgjM2_HOmf6Oavev=kJmO3d1Ka-3vfvWjw@mail.gmail.com>
References: <CAN6JmWPr88-Rm=Q9LhyEaVrZCp+4m=t7CN86yL+q0fWMvbtfXw@mail.gmail.com>
 <20150725084155.GB87662@phare.normalesup.org>
 <CAN6JmWMXufEXgBnEcn6ERQjTXfP=KHpv_huJBM_RBLLOV9CuYw@mail.gmail.com>
 <CAM=pu+J6K7fe3aEs7RyZ9_ecNf=SJUTNNJzX2FzVq2HAd3ne7Q@mail.gmail.com>
 <20150727052501.GB550510@phare.normalesup.org>
 <CA+X4w0z-WpsKk0gBu9pmoaDVCDFZyHQfWLtNokFtJURWGFRCuQ@mail.gmail.com>
 <20150727174426.GW705713@phare.normalesup.org>
 <CA+X4w0y4FsorxWsZMgjM2_HOmf6Oavev=kJmO3d1Ka-3vfvWjw@mail.gmail.com>
Message-ID: <CACmvKtaKReFgC9nv8Xe0ixZG6W71fHvg8ezbqCP0wnr_jbgtiQ@mail.gmail.com>

Doesnt Dipy already do this? (be open source and compute FA images
[and much more] from any dwi dataset)

On Wed, Jul 29, 2015 at 8:06 PM, Ariel Rokem <arokem at gmail.com> wrote:
>
> On Mon, Jul 27, 2015 at 10:44 AM, Gael Varoquaux
> <gael.varoquaux at normalesup.org> wrote:
>>
>> On Mon, Jul 27, 2015 at 08:56:08AM -0700, Ariel Rokem wrote:
>> >     PS: Vanessa: Nilearn is not only for fMRI. It's for statistical
>> > analysis
>> >     of images. It is also used for anatomical images:
>> >     http://nilearn.github.io/auto_examples/decoding/plot_oasis_vbm.html
>> >     If we could get a preprocessed, openly downloadable set of images of
>> > eg
>> >     FA, we would do an example with diffusion too.
>>
>> > Completely off-topic, but I can't resist: if only there was an
>> > open-source project that computed FA images from freely available
>> > diffusion MRI data-sets!
>>
>> Well, you're welcome to help us with preprocessing and pitching a
>> relevant prediction problem from this data. I know nothing about
>> diffusion and nothing about the datasets you are talking about. In my
>> experience, writing a relevant example requires understanding the data
>> and the questions. If you, or someone else, gets us to the point where
>> there is a set of nifti images of FA with condition A and condition B,
>> and helps us write the story, than we have an example.
>
>
> Hmm. Interesting idea. I am looking around for something along these lines.
> I think that there are some freely available data-sets that are already
> preprocessed, so could be used in this way. Let me think about how to go
> about this.
>
>>
>> Ga?l
>> _______________________________________________
>> 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
>