Past, Present and Future of Open Science (Lightning talk): Nilearn: open, easy, and powerful statistical analysis of brain images

[jsheunis]

Nilearn: open, easy, and powerful statistical analysis of brain images

By Gael Varoquaux, MNI, McGill, Montreal, Canada

• Theme: Past, Present and Future of Open Science
• Format: Lightning talk

Abstract

Nilearn is a Python toolbox for advanced statistical analysis of brain images. It implements standard analysis, functional connectivity, and multivariate statistics. It is driven by a community, developed in an open-source way with high standards of quality for the code, the numerics, and the documentation.

We will talk about the project vision, the recent progress, and showcase a few functionality.

Useful Links

http://nilearn.github.io/ []()

Tagging @GaelVaroquaux

[Starborn]

Gael, regarding the cost of interfaces, I d like to take you up on that point, Using cocomo (costing model) approach, and depending on how/what you count as a cost, it can be argued that training people and paying highly qualified programmers is much much higher than developing a GUI that anyone (hundreds. thousands of people) can use. I think we should take away the cost of paying programmers to do the work for us, at the same time, we should also learn some python. But we can talk about costing with hard figures anytime you like, possibly next year, I ll propose a session on interfaces. I have been doing this work for over a decade now in semantic web research :-) Lets talk.

[GaelVaroquaux]

I would rather estimate the cost of usable GUIs in multiple millions, given that the cost of nilearn is currently above the million.

I don't fully dispute that it's a question of where you spend this cost: at the level of the users, forcing the user to pick up software that is technical, versus at the level of the developers, forcing them to work on UI. Indeed, there would be interesting big-picture discussions to have on what is best for the field. However, my experience is that it's very hard to divert multiple millions in open-source software: the academic community is not willing to accept this, in particular in neuroscience. I have done open-source software with GUIs in the past (Mayavi is a well-known example), and they really felt not sustainable.

In addition, I believe that top-notch research demands a level of understanding and control from the practitioner that is very difficult to put in a GUI.

We have been trying to find a middle ground, by adding as many UI components as we could in the notebooks (for instance the reports), and developing APIs that are as high-level as possible. Even this middle ground is something that we are currently having difficulties sustain, for lack of human-resources.

Happy to continue this discussion, in particular to explore the middle ground in which I believe :). Cheers!

[Starborn]

Gael Like every other discussion, here and elsewhere, talking in this terms is a bit of a generalization

There are different kinds of GUIS, there are different types of projects, systems, software , requirements, interfaces

In my experience GUIs should not be made by developers, thats why they may become costly and unsustainable I may have to make this point in a paper, showing some figures - it depend what functionality is needed, at what scale

Not everything can be addressed at GUI level, but a GUI can be easily and inexpensively developed for each computation function (so GUIS can be modular too) In essence, for each command line code, there can be an equivalent visual interface to execute it - it can be as easy as that, But of course, programmers generally lose sight of this simple truth because of the lens through which they see the world is code

Learning interfaces can be used to teach command line code via visual interfaces too-

It depends at what level the system is pitched Ultimately, the data *images and their narrative interpretation, should be accessible to medical without any code whatsoever the manipulation (extraction, querying) of the data contained in images and other clinical repositories should be represented in a way that it can be accessed manually, as well as made available to machine learning and NL apps. The GUIs should facilitate the user navigation among all the options, Of course, there may be operations for which GUIS are not available, not required, or not economical Lets continue to talk P

On Thu, Jun 25, 2020 at 6:22 PM Gael Varoquaux notifications@github.com wrote:

I would rather estimate the cost of usable GUIs in multiple millions, given that the cost of nilearn is currently above the million.

I don't fully dispute that it's a question of where you spend this cost: at the level of the users, forcing the user to pick up software that is technical, versus at the level of the developers, forcing them to work on UI. Indeed, there would be interesting big-picture discussions to have on what is best for the field. However, my experience is that it's very hard to divert multiple millions in open-source software: the academic community is not willing to accept this, in particular in neuroscience. I have done open-source software with GUIs in the past (Mayavi is a well-known example), and they really felt not sustainable.

In addition, I believe that top-notch research demands a level of understanding and control from the practitioner that is very difficult to put in a GUI.

We have been trying to find a middle ground, by adding as many UI components as we could in the notebooks (for instance the reports), and developing APIs that are as high-level as possible. Even this middle ground is something that we are currently having difficulties sustain, for lack of human-resources.

Happy to continue this discussion, in particular to explore the middle ground in which I believe :). Cheers!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ohbm/osr2020/issues/63#issuecomment-649451515, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACFKUCMSYDGNCUSNUOKWXFTRYMQPXANCNFSM4N2NXPBQ .