Adding variable for user specific coverage to roiquant module

[adrose]

Hi,

I am currently running structural data through the struc pipeline. I am running into the problem where my dgm roi's are being rm'ed due to inadequate coverage (<.5 of the voxels have values). This is due to the DGM's k means segmentation, the DGM is being called WM more than GM.

Is it possible to either turn off the coverage flag, or lower the threshold to ~.25?

The threshold as determined here: https://github.com/PennBBL/xcpEngine/blob/master/utils/nodeCoverage.R#L29

[adrose]

It appears this issue is a result of GIGO

One way to possibly avoid this issue, specific to GMD calculation in the deep gray matter (DGM), would be a check for the DGM CNR w/ WM.

Calculating the CNR would be easy: |(mean GM intensity) - (mean WM intensity)| /(std of background intensities)

If the contrast is v low, then be aware of v low or 0 dgm gmd values.

I would consider adding this specifically to the GMD module, and then having the dgmcnr be output to the quality csv.

[adrose]

Potentially of interest for this issue: https://ieeexplore.ieee.org/abstract/document/897810

&

https://ieeexplore.ieee.org/abstract/document/704309

And also relevant: https://link.springer.com/protocol/10.1007%2F978-1-4939-7647-8_2

[adrose]

I actually think I am going to throw this into the QCANAT module, I'm not sure if people use the qcanat but in terms of workflow and what the module is reading in I think it makes much more sense.

I still think moving segmentations to use CNN's could be an incredibly interesting experiment and would deal much better with partial volume effects though

[adrose]

@rciric @mattcieslak @a3sha2

How are we checking if a module / PR / is good to integrate to master?

Is there a dataset I should be working with to see if structural results are identical to some standard output?

I'm not modifying really any processing code but just want to know if there is a PR format and code check I should adhere to?

[adrose]

This is a separate issue, but it'll be pertinent to this PR.

It appears that in the qcanat module, some varibales are not being defined correctly.

Here are some example failed registrations because some variables were not declared correctly:

 antsApplyTransforms -d 3 -i /xcpEngine/modules/qcanat/mniForeGroundMask.nii.gz -o /home/arosen/data/joy/BBL/studies/nasa_antartica/processedData/structural_containerized/xcpAccel_longJLF_OldAnts/wo_2016/concordia_105/t12/qcanat/wo_2016_concordia_105_t12~TEMP~-fg.nii.gz -r -n NearestNeighbor -t /home/arosen/data/joy/BBL/studies/nasa_antartica/processedData/structural_containerized/xcpAccel_longJLF_OldAnts/wo_2016/concordia_105/t12/qcanat/wo_2016_concordia_105_t12_0GenericAffine.mat

In both of these the reference images and land marks were not declared correctly... Will investigate further but wanted to post this here

[adrose]

BRAINSPACE was not declared correctly? Could be something wrong with the core files... will come back to this issue later.