MRtrix3 / mrtrix3

MRtrix3 provides a set of tools to perform various advanced diffusion MRI analyses, including constrained spherical deconvolution (CSD), probabilistic tractography, track-density imaging, and apparent fibre density
http://www.mrtrix.org
Mozilla Public License 2.0
281 stars 176 forks source link

Scripting in GUI #918

Open maedoc opened 7 years ago

maedoc commented 7 years ago

I use mrview fairly regularly to work on some of my image processing scripts since the UX is great. However, what is not great is opening and closing files with mouse clicks over and over. It'd be really useful to script the Qt components in mrview. Qt provides QtScript module making it easy (if you've exposed stuff in the C++ in a straightforward fashion) to do this, though working with it from Python would be even better.

I don't mean this as a bug or demand or whatever: I know it'd be a ton of work and source of bugs; I'm just interested if this is on your roadmap or you've decided UI scripting is out of scope for mrview.

maxpietsch commented 7 years ago

opening and closing files with mouse clicks over and over

Just to double check, the mrview options -overlay.load image -load image -roi.load image odf.load_sh image -exit are not sufficient?

maedoc commented 7 years ago

Those are great, yep; but I have for example an algorithm to identify implanted electrodes on patient data where we are doing tractography. That algorithm has at least 5 binarization, erosion, dilation, labeling etc steps where I'm tuning the parameters based on what I see in mrview.

again feel free to say 'out of scope' and close the issue, but scripting some of the i/o and viz widgets would make this sort of work easier.

edit for clarity I think what's not captured by mrview cmd line args is the case where one tunes a threshold on an overlay, for example, and use that value to rerun an external algorithm and update the visualized overlay... sounds ridiculous I guess.

jdtournier commented 7 years ago

Qt provides QtScript module making it easy

I have considered this in the past, but never looked into the details of how it works. But given that the command-line can be used to achieve most of functionality, I've never come across a sufficiently compelling use case to justify investing any time into it.

In your case, I'm not completely sure what you're actually after, what workflow would you like to use exactly? Is it something that you can script using a simple bash script like this:

#!/bin/bash

mrview $1 -overlay.load $2 -roi.load $3 -capture.grab -exit 

or something?

Based on your recent edit though, I see that what you're after is really the ability to export values from mrview for use in a script? Would something like a -overlay.dump_parameters_at_exit option be useful? Although hopefully something a little less verbose... We could have such an option register to dump the parameters of the tool's UI to stdout, so that you can grep out the value of interest and adjust your script accordingly. I can see that might be of value - although not something I'd expect all that many users to even know about... If that is of interest, then it would be trivial to add, but would obviously need a little bit of work to implement, particularly since it would need to be tool-specific. All it would need is to dump out the values in the tool's destructor, based on whether the option was set. The hardest part is going to be to walk through all the parameters, and figure out a simple, easily parsed format for the output... I'd probably opt for a key: value format, maybe with indexed keys where necessary, e.g.:

roi[1].name: image.mif
roi[1].opacity: 0.8
roi[1].colourmap: 2
roi[1].threshold_lower: 0.05
roi[2].threshold_upper: NaN
roi[2].name: other.mif
roi[2].opacity: 0.2
roi[2].colourmap: 1
roi[2].threshold_lower: NaN
roi[2].threshold_upper: NaN

etc. You get the picture... Point being that this would be enough to use in a script, e.g.:

value=$(mrview main.mif -roi.load image.mif -roi.dump_at_exit | sed -n 's/roi[0].threshold_lower://p')

Would this fit the bill...?

maedoc commented 7 years ago

Thanks for thinking it through in detail. I think that'd do it.. I expect it would be a maintainability burden though, so I don't envy having to implement.