Implementation of the workflow

[celprov]

Closes #

This PR implements the workflow.

Proposed Changes

• Implement a parser (strongly inspired by the parser of phys2denoise)
• Add an interface to iteratively generates the figures
• Add an interface to compute the metrics iteratively
• Add an interface to save the metrics as a json or csv
• Adapt the documentation to the reality that certain metrics function can take as input a peakdet Physio object or a np.array
• Remove smoothness as its implementation is not working

!! The generation of the visual report is missing in the workflow and needs to be added !!

Change Type

• bugfix (+0.0.1)
• minor (+0.1.0)
• major (+1.0.0)
• refactoring (no version update)
• test (no version update)
• infrastructure (no version update)
• documentation (no version update)
• other

[SRSteinkamp]

@celprov

In smoothness, you use:

    time = np.arange(0, len(data.data) / data.fs, 1 / data.fs)
    dx2 = np.empty(len(time))
    for t in time:
        dx2[t] = derivative(data.data, t, n=2)

for the derivative, could we simply replace it with np.diff(np.diff(data.data)), i.e. computing the derivative numerically, assuming a dt of 1?

[celprov]

@SRSteinkamp oula it has been a long time ^^'
Given that I left a comment that this function currently did not work, I guess any alternative implementation is welcome. So I guess it should be fine.

[SRSteinkamp]

Jup, it has been long ;) ... I'm not sure anymore if it is as simple as taking the two np.diffs going to think about it.

Quick update (@celprov , @smoia ):

I think

time = np.arange(0, len(data.data) / data.fs, 1 / data.fs)
dx1 = np.gradient(data.data, time)
dx2 = np.gradient(dx1, time)

might be the way to go, as it keeps the unit of the derivative at (hope I have the notation right): d^2 x / dt^2. Is it necessary to further normalize it? - i.e. if we want to compare signals with different sampling rates?

There are still massive differences in terms of the mean absolute value for the time series, dependent on the sampling rate. Which makes sense, if we redefine the smoothness measure as "ruggedness" or something, i.e. the higher the value, the less smooth the signal.

[smoia]

I'm trying to wrap my head around this, but I don't have enough signal processing background to provide any useful suggestion.

However, a couple of things:

• does MRIQC compute smoothness? If so, it might be nice to check how it does it
• in any case, I'd write in the docstrings what you mean by smoothness and why you decided to go for this implementation - it will make it easier for documentation to be clear and for users to understand how to interpret this measure (especially if, as you said, this measure is not so well defined)

[SRSteinkamp]

Same...
The only thing I have to go by is the GoogleDoc you shared for physioQC and Celine's implementation (which is not working as intended) ... so I am also not sure what smoothness is here and had hoped you had some insight :) ... also happy to remove the measure for now until we have a better grasp of it.

[celprov]

@SRSteinkamp MRIQC computes the smoothness of the fMRI image as Full-width half maximum smoothness (fwhm*)
Here is the info I've found in MRIQC code about how it is implemented

fwhm (nipype interface to AFNI): The :abbr:FWHM (full-width half maximum) of
the spatial distribution of the image intensity values in units of voxels [Forman1995]_.
Lower values are better, higher values indicate a blurrier image. Uses the gaussian
width estimator filter implemented in AFNI's 3dFWHMx:

.. math ::

  \text{FWHM} = \sqrt{-{\left[4 \ln{(1-\frac{\sigma^2_{X^m_{i+1,j}-X^m_{i,j}}}
  {2\sigma^2_{X^m_{i,j}}}})\right]}^{-1}}

Here is the visual representation of the equation

[SRSteinkamp]

Will have a look if it fits for 1D time series signals (and not images) @celprov :)

@smoia ... before this PR is ready for review, we need to review and merge #5 first. This PR already references the visualizations we implemented.

[celprov]

In the project wrap-up, we proposed to separate the smoothness from this PR, so that the rest of the content can already be reviewed and merged and to work on developing the smoothness in another PR.

@SRSteinkamp feel free to open a draft PR with your implementation of the smoothness.

[celprov]

@m-miedema I think this PR is ready for review (unless @SRSteinkamp says otherwise).

[SRSteinkamp]

Couldn't check if the actual implementation of the workflow yet, as visualizations are not included.

Please prioritize #5 - after #5 is merged in main (and this here) I will finish what is left to do on this PR.

[m-miedema]

This is a really exciting PR! I know @SRSteinkamp still wants to work on some visualizations but I thought I'd go ahead and take a look in the meantime. However, I can't get the CLI to run. I'm on Windows (I know this is new ground) and after installing with pip, and running physioqc -h I receive the following error:

Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code 
  File "C:\Users\data_acq\AppData\Local\Programs\Python\Python311\Scripts\physioqc.exe\__main__.py", line 4, in <module>
  File "C:\Users\data_acq\AppData\Local\Programs\Python\Python311\Lib\site-packages\physioqc\workflow.py", line 10, in <module>
    from physioqc.cli.run import _get_parser
ModuleNotFoundError: No module named 'physioqc.cli'

I haven't figured out how to solve this myself, although @me-pic has replicated the error running on a Mac.

[m-miedema]

It seems like there were some __init__ files missing! Thank you @me-pic :)
After that, it seems like the main thing is to add in the visualizations. @SRSteinkamp let me know if you need any help :)

[smoia]

@m-miedema or @me-pic can you push the missing init to this branch?

[celprov]

If the workflow works as such, I would merge this PR and work on adding new visualizations in another PR. Get Outlook for Android<https://aka.ms/AAb9ysg>

…

________________________________ From: Stefano Moia ***@***.***> Sent: Thursday, April 18, 2024 11:26:55 PM To: physiopy/physioqc ***@***.***> Cc: Céline Provins ***@***.***>; Assign ***@***.***> Subject: Re: [physiopy/physioqc] Implementation of the workflow (PR #11) @m-miedema<https://github.com/m-miedema> or @me-pic<https://github.com/me-pic> can you push the missing init to this branch? — Reply to this email directly, view it on GitHub<#11 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ASOZWOGQTMXYITUXJQUSBP3Y6A3B7AVCNFSM6AAAAAA2TI7IBOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRVGM2TCMJWG4>. You are receiving this because you were assigned.Message ID: ***@***.***>

[m-miedema]

@celprov I haven't been able to fully test it yet, as the workflow file was raising errors where the visualizations are missing.

[celprov]

Is it a matter that the visualizations missing are implemented in PR #5 ?

[m-miedema]

I'm not quite sure -- from what I can tell, the visualizations have inconsistent naming conventions across the two branches, but it seems like from @SRSteinkamp's comment above, it will not be too difficult to implement once that PR has been merged.

[goodalse2019]

Looks good from my end!

[goodalse2019]

Try 2, looks good

[goodalse2019]

yes!

[goodalse2019]

I officially viewed!

[goodalse2019]

looks good!