-
Notifications
You must be signed in to change notification settings - Fork 12
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
FIX: Correct a number of problems introduced by changes for MIALSRTK v2.0.2 #110
Conversation
…x_stuck_running_nodes Temporary fix for nipype nodes stuckes in running state. Remove specification of number of processes (n_procs) to run the workflow
…and enable caching
…tion interface to prevent Segmentation Fault
…terface to prevent Segmentation fault
@pdedumast I was indeed about to get to you about that! Doing so would act more as a refinement process, as for each new iteration, we initialize the transforms and update the reference image from the ones obtained from the previous iteration. But yes for sure, let's see how this works! 👌 |
@pdedumast The idea needs in fact to be better implemented as now the step length decreases after each iteration AND each image... which is wrong :/ So I got back to your old implmentation i.e. dividing by 4 the default values once and for all. |
@sebastientourbier, based on the few tests I've made, reducing only once the registration step length seems enough to avoid slices that get completely lost. Though, further investigation might still be helpful to improve that. Note: It seems that starting with big step length and then reducing it is not the correct strategy. I have observed strongly misregistered slices this way. That's why keeping a constant and not to large step lengths seems appropriate for now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pdedumast Just reviewed all the changes and it seems we are almost ready for the merge! But I noticed there is still a bug in the last execution of test 01 on circleci. When the pipeline is executed with the manual masks, a list of images defined by "stacks"
in the param file, and the stackordering, all the images are then considered, while one would expect to take only the list of images defined by "stacks"
in the param file.
… by "stacks" in the param file right after the datagrabber for masks
@pdedumast I should have fixed the issue with the last commit cb7b769. I added a mialsuperresolutiontoolkit/pymialsrtk/pipelines/anatomical/srr.py Lines 298 to 301 in cb7b769
and review the inputs/outputs connection of nodes: mialsuperresolutiontoolkit/pymialsrtk/pipelines/anatomical/srr.py Lines 462 to 467 in cb7b769
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All tests passed on circleci for the lastest commit and after reviewing the changes introduced, this PR looks ready to be merged! Just wait from you to give me the go-head 👍
@hamzake: Could you test the singularity image built by circleci based on the latest commit (fea1a63): https://2023-210386291-gh.circle-artifacts.com/0/tmp/cache/mialsuperresolutiontoolkit.simg ?
@pdedumast: Have you noticed any issue that would need to be addressed in this PR before merging?
@sebastientourbier, looks good to me ! 👌 |
This PR proposes a number of changes that should correct all the problems introduced by PR #70 already merged into
master
for version2.0.2
. In particular, it includes: