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

Skull indices are used instead of new layer labels #25

Closed
KTZ228 opened this issue Jul 5, 2023 · 2 comments
Closed

Skull indices are used instead of new layer labels #25

KTZ228 opened this issue Jul 5, 2023 · 2 comments
Labels
bug Something isn't working

Comments

@KTZ228
Copy link
Collaborator

KTZ228 commented Jul 5, 2023

When the switch to charm was made in the previous major revision, the pipeline was adjusted to accept skull indices instead of the new layer labels to save time.
This can lead (and has led) to issues by using the incorrect layer labels.
To prevent further confusion in the future, I suggest to adjust all the code to accept the updated layer labels from charm instead of the layer indices.

MaCuinea added a commit to MaCuinea/PRESTUS that referenced this issue Jul 27, 2023
The segmentation in SimNibs is now done using Charm instead of headreco. Therefore, the labels of every tissue are different. This is fixed and the code is also made more robust, so less hardcoded label values.
@MaCuinea
Copy link
Collaborator

MaCuinea commented Jul 27, 2023

Fix has been made for this issue. Pull request (#27) is created, so code can be tested first.

@jkosciessa
Copy link
Collaborator

jkosciessa commented Jun 11, 2024

The current master still has quite a few hardcoded values, see e.g., this block.

I am currently working on a solution. This partially arises from how the specification is designed: parameters.layer_labels specifies the layers that are to-be-modelled, and this specification is sequential. If we would specify an additional csf field in the end, it may interfere with the more global water layer that we would like to model.

Beyond the obvious solution of requiring the standard layer specifiation, my current solution relies on an additional config field "seg_labels":

seg_labels:
  csf: [3]
  bonemask: [1,2,3,4,7,8,9]

If this field is absent, I throw a warning that hardcoded values are being used.

I now also export niftis of density and soundspeed, as those provide critical checks of whether everything has been properly implemented before running acoustics & heating.

Included in commit 3195d93

@jkosciessa jkosciessa added the bug Something isn't working label Sep 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants