search

SlicerIGT / SlicerBoneReconstructionPlanner

3D Slicer module for planning mandible reconstruction surgery using fibula flap
BSD 3-Clause "New" or "Revised" License
26 stars 7 forks source link

Bone segments rotating when moving the planes #56

Closed mrtig closed 6 months ago

mrtig commented 2 years ago

When I move a plane the bone segments also rotate a bit. This should not happen. I only want to make the segments shorter or longer.

mauigna06 commented 2 years ago

Hi mrtig.

You would need to be a bit more specific. When you move the plane in what direction (e.g. normal direction, orthogonal to normal direction, random direction) the bone segments rotate a bit? This must be an optical illusion because of the pipeline Fibula pieces are created from fibula planes that are transformed to the mandible and fibula planes are created from mandible planes by applying the mandibleFrameToFibulaFrameRegistration transform, that is a linear transform. i.e. a mandible plane moved along a line, will make the fibula plane move along a line also. The linear transform also accounts for rotations of the first mandible plane in curveCrescentOrder of the two that make the boneSegment. That means, rotations to that plane will make the corresponding fibula piece 'rotate' (in reality the fibula cut planes do rotate and generate a new corresponding the fibula piece). No rotation of the fibulaPieces will happen if you just move the origin of the mandiblePlanes, that is not possible (unless you are using the option "make all mandible planes rotate together").

Using "more exact planning" will create a frame for each fibulaPiece. Making the mandible planes origin coincide with centroid of the fibula piece intersection with the mandible plane, that maybe it's more expected behavior. Anyway the software is a what-you-see-is-what-you-get editor and the surgical guides will be accurate on both modes.

I'm not sure if I understand the problem correctly maybe you can add some pictures to illustrate.

Mauro

mrtig commented 2 years ago

Before: image

After moving the first plane: image After moving the plane once everything was ok, but then I did a smaller movement to fine tune the position. I tried this many times. Sometime happened after first move, sometimes after second. The first two segments have been rotated about 90 degrees.

mauigna06 commented 2 years ago

Please check if the mandible planes do rotate after you make the small adjustment. You can check this by creating a copy of the mandible planes befores moving them and using that to compare (looking at the interaction handles). If you can post a picture of both group of planes. Thank you

mrtig commented 2 years ago

Now this happened - the start of the first segment jumped up. image The planes didn't rotate.

mauigna06 commented 2 years ago

Thanks Martin for researching on this. If you find a reliable way to replicate this problems this is definitely solvable. I suspect it could be because there is an alternative way of calculating the reconstruction when mandible-planes-position-changes are small that is there for performance reasons, may be I could create a new branch without this feature to see if the problem goes away but the best would be to find a reliable way to replicate the bugs.

mauigna06 commented 2 years ago

I'm not being able to replicate this bug myself by hand. @cmfsx has this ever happened to you?

@mrtig when you post screenshots be sure they are of the fullscreen so I can see what reconstruction options you were using. If you cannot get to replicate the bug reliably a screenrecord of this bug before and after happening will be useful. Hope you can help me solve this.

Mauro

mrtig commented 2 years ago

@mauigna06 Here's the video https://we.tl/t-kd6xLwS7RG

mauigna06 commented 2 years ago

@mrtig I see. Thank you for researching into this.

Could you assure this happens only with the option "more exact planning" checked?

cmfsx commented 2 years ago

Sorry for ghosting... Down with COVID-19. Now recovering slowly. This has sometimes happened during various stages of the software. but i cannot say exact way of replication. i will do some research in to it and see too.

mauigna06 commented 2 years ago

Hi Manjula.

Hope you get better

So are you saying this bug has always been there? It would be easier to track down if I would knew since what day it started doing this sometimes.

When you are recoved you may check into this, leave it for now unless you are bored and want to experiment

Mauro

mrtig commented 2 years ago

I think this is an issue of the "more exact planning" option. I don't think I have experienced this before.

mauigna06 commented 2 years ago

Ok. That's useful. Thank you.

I'll check. Please give me sometime.

Mauro

mauigna06 commented 2 years ago

Hi @mrtig.

So I'm still not able to replicate the bug. Maybe you can send me your error prone scene and I can check it.

A better idea I have to debug this is that you make update the fibula pieces till you have a good reconstruction then go to the data module and clone the folder "Mandible2Fibula transforms" and rename it "Mandible2Fibula transforms correct" (also do this for the folders "Mandibular planes", "Fibula planes", "Cut Bones", "Bone Pieces Transforms" and "Transformed Fibula Pieces"), then translate with the arrow the first plane of your reconstruction back and forthward slightly till you get the wrong-rotation behavior (it is important that the change of position is small enough to not change the transform so much to make them hard to compare). then save the scene and send it to me. I'll check it and probably find the reason of this problem.

Mauro

mauigna06 commented 2 years ago

@mrtig Another idea: I remade the dentalImplantsPlanning completely from zero when I set up its transforms. Maybe the error that produces this bug is not on that code. You could check that if you want

Mauro

mauigna06 commented 2 years ago

@mrtig I think I found the source of the bug.

First you have selected S0 as fibulaLine which should not be done because it's position changes with each plane recalculaton (because you have a initialSpace greater than zero) that could lead to small changes on the result of the moreExactPlanning algorithm. Secondly, you are used to making the fibula point on Anterior-Posterior direction. This direction is hard-coded (used) to compute one of cross products that create the mandibleToFibulaRegistrationTransform, the second input of the cross product is a vector with fibulaLine direction. That results in two very similar input unit vectors (have little angle between them) and this causes an instability of the cross-product result causing the change of angle in the transforms sometimes.

Related: https://github.com/SlicerIGT/SlicerBoneReconstructionPlanner/blob/699c9970f163a14c7289dd8c8a7aa8b7346969d3/BoneReconstructionPlanner/BoneReconstructionPlanner.py#L2319-L2328

If my analysis is correct you should not face this problem by not using any Snumber line (e.g. S0,S1,S2,etc) as fibulaLine and not orienting the fibula on anterior-posterior direction. Please let me know if this is correct

mrtig commented 2 years ago

@mauigna06, thank you for looking into this. I will test it with the next case.

mauigna06 commented 2 years ago

@mrtig great. Thank you

mauigna06 commented 2 years ago

@mrtig can you confirm if the diagnostic I did is correct?

mrtig commented 2 years ago

@mauigna06 Sorry, there haven't been any cases for a while and I've been busy with some other things. I'll try to look at it when I get some time.

mauigna06 commented 2 years ago

@mauigna06 Sorry, there haven't been any cases for a while and I've been busy with some other things. I'll try to look at it when I get some time.

Hi @mrtig ...

Do you know if the bug was catched? Do you have any other bug to report? Have you helped in any other surgery using BRP since Febraury?

mrtig commented 2 years ago

Hi @mauigna06 ,

It seems that there have been no cases during this time. Just a few days ago I got a new case. I will see if the bug appears with this case. I will let you know soon.

mauigna06 commented 2 years ago

Hi @mrtig ... how is all going? Did you encounter the bug again?

Mauro

mauigna06 commented 1 year ago

I consider this bug solved. And fixing #73 will make this unlikely scenario even more rare.