populse / populse_mia

Multiparametric Image Analysis
Other
10 stars 9 forks source link

[history] Complex types are not (or poorly) supported in the data history display. #288

Closed servoz closed 10 months ago

servoz commented 1 year ago

Working on mia_processes.bricks.stat.spm.Level1Design(), it is observed that complex type parameters are not displayed correctly in the data history display. The pipeline: Screenshot from 2022-12-06 15-34-59 The data history display: Screenshot from 2022-12-06 15-39-31_2 Screenshot from 2022-12-06 15-38-30_2

In fact we have for this case: dict4runtime == {'sessions': [{'scans': '/data_2/populse_mia_project/test/data/derived_data/swralej-IRMFonct_+perfusion-2016-03-17083444-05-BOLD_CVR_7_53sl_ModeratePNSSENSE-FEEPI-001212_000.nii', 'multi_reg': [[['/data_2/populse_mia_project/test/data/downloaded_data/regressor_physio_EtCO2_ctl.mat']], [['/data_2/populse_mia_project/test/data/derived_data/rp_alej-IRMFonct_+perfusion-2016-03-17083444-05-BOLD_CVR_7_53sl_ModeratePNSSENSE-FEEPI-001212_000.txt']]], 'hpf': 427.2}]} and sess_multi_reg == [['/data_2/populse_mia_project/test/data/downloaded_data/regressor_physio_EtCO2_ctl.mat', '/data_2/populse_mia_project/test/data/derived_data/rp_alej-IRMFonct_+perfusion-2016-03-17083444-05-BOLD_CVR_7_53sl_ModeratePNSSENSE-FEEPI-001212_000.txt']]

We need to rework the relevant part of the scripts.

I don't have time to work on this at all at the moment. I open this ticket to keep in mind that we will have to work on ASAP.

The dict4runtime parameter is a special parameter (acting as a messenger between initialisation and runtime). As already mentioned in tickets, I think it should not appear in the history display (userlevel =1). When fixing this ticket, it would be nice to handle parameters with userlevel=1 in the history display.

servoz commented 10 months ago

There's a feature that lets we switch from a file in the history window to the same file in the data browser (if the file is indexed in the database).

The idea is simple, but it's not so easy to code, as we have to take into account all the type possibilities. To avoid wasting time on cases that don't exist, only the list and list of lists types are implemented for now. It may be necessary to extend this to dictionary , set, list of dictionaries, etc... The number of cases could be virtually infinite. We'll see if the need arises, and if so, there's always time to code an enhancement.

Another simplification is currently being implemented: if an element of the list or list of lists is not an indexed file in the database, we currently consider that all elements are not indexed. I don't yet have an example in mind like [notIndexed, Indexed, ...], which is why it's currently coded this way, as it simplifies things considerably. Similarly, if the need arises, we'll code in that direction.

servoz commented 10 months ago

Fixed.