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

BB templateseg & outlier vertices #328

Closed
wants to merge 12 commits into from
Closed

BB templateseg & outlier vertices #328

wants to merge 12 commits into from

Conversation

jordandekraker
Copy link
Collaborator

This is an older branch which I forgot to merge, but I think it is doable.

Basically the idea is to have a BigBrain template available in the templateseg workflow. This isn't always advisable, because of the well known issue of volumetric registration smearing gyri/sulci, but it can give a reasonable starting point for someone wanting to do their own manual segmentations or just to get an idea of how volumetric registration WOULD perform.

I'm merging this into master rather than dev-v2.0.0 since it relaly does pertain to the templateseg workflow. Will run a local test too.

@akhanf
Copy link
Member

akhanf commented Dec 13, 2024

ok hold off on merging -- I'm about to fix the accidental push ..

@jordandekraker
Copy link
Collaborator Author

Yes this still needs testing

I see that I also made some changes to try and correct bad vertices. I believe this was resolved in https://github.com/khanlab/hippunfold/releases/tag/v1.5.0 though, so its probably not necessary. I will remove those changes and then try a test.

return specs


def get_final_surf():
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this redundant if the surfaces are in the spec?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe I added this so that we could specify mid-inner-outer surfaces in the dentate within the config file too. Without this they will never be generated since they are not in the spec. I will see with some testing though...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess the better place to update it is in the expand() for the spec file then, ie if inner outer surfaces are requested then, they are put into the spec

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

right, i remember now. This was a bit challenging since the config can be different for hipp and dentate surfaces. This is likely solvable with wildcards, but I found a rule for surfaces to be a bit more intuitive since they are a major class out outputs, so its nice to have them listed explicitly. What do you think?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would be nicer to have fewer target rules generally, but the main issue I worry about is having redundant code that gets out-of-sync, e.g. if we expand over surfaces in the cifti creation and the target rules -- the code so far would make it out of sync.. The create_spec_file_dentate rule is where you could just update what wildcards to expand over what you need (and then only have it appear once in the code).

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

was just looking to undo this when i found that it had actually already made its way into the master branch:

c32bac2#diff-44c3321b981bf8e9ad7e5f10740de98858b868cd8a75cbbcbbe08170249441ee

I'm not quite sure what you mean about these files going out of sync though

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok then it's something we can clean up in the v2.0 refactor -- I wasn't talking about files going out of sync, but about redundancy in the code (eg expanding over wildcards in two different places, and having to maintain those two expands to be the same..) - probably occuring more than just here, but is something we should try to avoid for easier maintenance (ie in the future when we change things, only have to change in one place, not two..)..

@jordandekraker jordandekraker changed the title BB templateseg BB templateseg & outlier vertices Dec 13, 2024
@jordandekraker
Copy link
Collaborator Author

Currently the bigbrain histology is simply named T1w to flow smoothly with most pipelines. However, we could also import simulated T1w&T2w phantoms: https://www.sciencedirect.com/science/article/pii/S1053811923002203

@akhanf
Copy link
Member

akhanf commented Dec 13, 2024

just a heads up - still working on fixing the master branch, as it seems now the commits to merge the bugfix PRs are gone.. I made a backup just in case..

@akhanf
Copy link
Member

akhanf commented Dec 13, 2024

just a heads up - still working on fixing the master branch, as it seems now the commits to merge the bugfix PRs are gone.. I made a backup just in case..

OK master should be good now (I was reverting back to the wrong commit!)

@jordandekraker
Copy link
Collaborator Author

This branch is technically working, BUT:

Major:

Minor:

  • in generating warps, unfolded coords are now 256x128x16 instead of 1x1x1 when generating warps. This affects the behaviour of natural interpolation, but I believe its actually better.
  • relatedly, epsilon is now expressed in unfolded voxels rather than as a fraction of coords
  • outlier removal on surfaces is applied
  • we have def get_final_surf(): in common.smk, but this is actually also in the master branch

@jordandekraker
Copy link
Collaborator Author

was thinking about this during lunch: given the magnitude of the changes, maybe we should merge this to dev-v2.0.0.

Also to consider: with the new native surfaces we may end up changing the behaviour of warps.smk completely, so having this in the dev branch might be best. @akhanf does that sound good?

I'll see about adding those phantoms and if the registration runs well now.

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

Successfully merging this pull request may close these issues.

2 participants