Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Evaluate obliquity as an array of values #421

Open
tsalo opened this issue Jan 31, 2025 · 4 comments
Open

Evaluate obliquity as an array of values #421

tsalo opened this issue Jan 31, 2025 · 4 comments
Labels
enhancement New feature or request

Comments

@tsalo
Copy link
Member

tsalo commented Jan 31, 2025

Summary

Obliquity is currently evaluated as a single boolean (np.any(nb.affines.obliquity(img.affine) > 1e-4)). Maybe we could retain the actual obliquity values as a 3-element array? That way obliquity could be clustered like other numeric attributes, once #407 is merged.

@tsalo tsalo added the enhancement New feature or request label Jan 31, 2025
@mattcieslak
Copy link
Contributor

I was told we could simplify this even further by looking directly at ImageOrientationPatient that's already in the sidecars. If any of those elements not a 1 or a 0 then we know it's an oblique acquisition. Although I don't know if this covers all cases. For example, I think dcm2niix can de-oblique images and I'm not sure if it updates this field.

We're currently grabbing it from the added field from add-nifti-info.

Are you thinking we could have it set up so there would be acq-VARIANTOblique[XYZ]?

@tsalo
Copy link
Member Author

tsalo commented Jan 31, 2025

I was thinking that variant names could include the group or value at some point, so something more like acq-VARIANTOblique3 to indicate it was the 3rd group of oblique values.

@mattcieslak
Copy link
Contributor

So a user would need to look up what Oblique3 means somewhere in a metadata file? At first I was thinking this would be inconvenient, but after some more thinking I'm starting to really like this idea. It applies to the other variants too. Right now the variant names only tell you that the acquisition varies from the dominant acquisition, but not how. There's no info on how it differs, so users will need to look up the actual info somewhere anyways.

@tsalo
Copy link
Member Author

tsalo commented Jan 31, 2025

With the fix we pushed in #417, the summary and file TSVs will retain the Cluster_<x> columns, so users shouldn't need to open other files to link a cluster value to the metadata values.

However, some kind of cluster summary file would probably be useful at some point, so that users can see what range of values goes into each cluster. Especially for figures.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants