Calibration issue: EITHER correct animation OR correct calibration - in 3D world view

[Slow Motion]

Hello XMALab Group

In 2018/2019 I did some experiments at the CFS when I was a visiting researcher at Nicolai Konows Lab.

For this I used the calibration body of the station which is marked L-S-I-U (see Fig. 1 and reference / framespec).

When I calibrate my dataset, there are two types of problems: (A) either the calibration looks good, but the animation is inverted (Fig. 2) or (B) the calibration is inverted, but the animation is OK (Fig 3).

I discussed this problem with Nicolai but we couldn't find a solution.

At first I thought that this happened because the physical markings on the cube were misplaced.

I think I can disprove this idea; because I tested all 6 possible combinations of the marking sequence, in which S, I and U define different axes, but "L" is the coordinate origin in the corner of the cube

(since it is also physically in the corner as the coordinate origin (compare Fig. 1 with reference / framespec)).

Three combinations resulted in type (A) errors and 3 combinations in type (B) errors.

Then I thought this happened because I might have flipped or rotated the images of one or both perspectives during recording.

I have now tried to create an experimental XMA calibration data set with a self-made calibration body and the X-ray machine used in Germany.

I didn't flip or rotate a perspective when recording the experimental data set. Nevertheless, the calibration is also inverted.

I think it's pretty unlikely that two different people will make the same mistake when creating a calibration body - or isn’t it?

Have I overlooked something or could that be a bug in XMALab?

I would be very grateful for help and suggestions.

Thanks a lot,

Daniel Schwarz

[Gatesy, Stephen]

Hi Daniel,

Is this a problem with exported data or only within the 3D World View in XMALab?  Please check your data in Maya or elsewhere, because the 3D World View is not stable.  If you zoom in too far you'll find the coordinate system changes from right-handed to left-handed (as appears to be the case in the two images attached) and the geometry changes handedness as well.  

You have to be very careful to not go past this point and always check the handedness of your coordinate systems.  I've warned Ben about this possibility; it's thrown off students working on our data in the past.

Steve Gatesy

--

Stephen Gatesy
Dept. Ecology & Evolutionary Biology
Box G-B209
Brown University
Providence, RI 02912 USA
401-863-3770 (office)
401-863-9169 (lab)

[Benjamin Knorlein]

Hi Daniel, Hi Steve,

I do not think this is related to the camera zoom in the view. In that case it will not turn the cameras inside out., but will invert the whole world.

David, did you check if the 3D models you have are correct. It might be that the handedness of you CT-data might be wrong and you have to flip them. You can easily check this by confirming the marker positions on them.

Otherwise, do you have rigid bodies with 4 markers in them? If you have some of them how does the rigid body error look in both calibrations?

Best,

Ben

[Gatesy, Stephen]

Good call, Ben.  Armita made me realize I could be seeing the axes wrong in these still images.

It's very easy to get CT models to flip.

steve

[Robert Kambic]

I had what I think may be the exact same problem for one data collection on CFS equipment that I never figured out how to fix. I tried mirroring and rotating the images in a variety of ways thinking that was the problem, none of which fixed the issue. I spaced out data collections, so the closest ones bookending were weeks apart but neither had the issue. I also scanned and reconstructed for the entire project using the same scanner. 

Is that the small CFS cube? I had this result happen while I was using the big one which I taped up with letters and numbers to ensure I didn't accidentally mirror it. 

--
To unsubscribe from this group and stop receiving emails from it, send an email to xmalab+un...@brown.edu.

[Beth Brainerd]

With our opossum data collected at CFS/Harvard, we had a problem for a long time that we thought was caused by cube or data images being mirrored, but it turned out to be that our CT scan mesh bone models were mirrored. Or at least — we fixed the problem and got good bone animations after we mirrored the bone models. We figured it out because the marker configurations in the left and right hemimandibles were different between the fluoroscopy data and the CT data.

Just a reminder to everyone — Best practice when collecting grid, cube and data images/videos is to have a radio-opaque letter or number (we use F and 2) in the video images to make certain the images themselves are mirrored correctly. I do see that the images that Daniel sent in his zipped folder do have orientation letters/numbers on them, and the characters are mirrored, as would be expected coming from a C-arm system with no built-in image mirror. 

The orientation letters/numbers must be placed correctly on the IIs — they should be in correct orientation when viewed from the face of the II (correct for “X-ray eye”) Then mirror troubleshooting comes down to whether calibration cube point IDs may be inverted or CT scans inverted. 

Daniel — in the 3D views you sent from XMALab, the calibration cube looks tiny relative to the source-image distances and I can’t see the array of 48-64 points that I would expect to see. But it’s very hard to tell this from images. 

And thanks, Daniel, for sending this problem to the XMALab Google group. It's valuable for others to see problems and (we hope eventual) solutions. Also everyone who has ideas for solutions should chime in!

— Beth

[Slow Motion]

Thanks Beth for sharing your experience regarding your mirroring issues!

Now that I've finally had the time to review my data, I can definitely say that the error came from the CT data, or to be more specific: from the segmentation software.

The following steps can help anyone faced with similar issues:

I solved the problem by mirroring the meshes along the x-axis in Maya before calculating “vAv2” (Fig. 1; simply changed the x-scale to -1). After the "vav2" calculation, I also exported the mirrored meshes to enable the further XMALab steps.

 

Perhaps such problems could be avoided generally in the future. I assume that the error is due to the use of different segmentation software. Because different programs seem to use different internal coordinate system orientations (left-hand rule vs. right-hand rule) and seem to store this information in the mesh objects. If so, the error might be avoided by "simply" telling XMALab to ignore the absolute x, y, z orientation of the markers and instead use the relative orientation of the markers to one another - to calculate how a mesh needs to be placed on the points that form a rigid body. – Does that make any sense & would that be possible? :)

[Gatesy, Stephen]

I'm glad you found the problem and a solution, Dan.

My suggestion is to simply make sure your models look like your specimen.  It's rare that markers are put in completely symmetrically, 

so they are usually the easiest clue that the Z on the segmentation has flipped.  In this case, as with so many aspects of XROMM,
it's healthy to be a bit paranoid and do as many checks as possible.

Best,

Steve