[ITK-users] Digitaly Reconstructed Radiograph (itk Python)

[D'Isidoro Fabio]

Hallo,

I am coding in Python the C++ version of DigitallyReconstructedRadiograph1.cxx. I use itk.RayCastInterpolateImageFunction as interpolator, itk.CenteredEuler3DTransform as transform.


1)      I generate my DRR and write it as .png image. The generated DRR has the "y axis" (increasing values of the physical y coordinates, since the direction matrix is the identity) pointing downwards intead of upwards. This is in contrast with the standard physical coordinate system for images explained the manual. Why does the coordinate system of the generated DRR goes left-to-right and top-to-bottom (origin at the top left corner)?


2)      The axes of my input CT scan would need to be switched in order to generate a DRR where the body is seen from a frontal view. I achieve this by applying a proper 90° centered rotation about one axis (CenteredEuler3DTransform) and resampling the image volume (ResampleImageFilter). I make sure to set the proper origin, spacing and size of the resampled image volume, so that the image volume is exactly the same as the original one (but with the axes switched). I can visualize the resampled rotated image volume with a viewer and it looks correct.



-        When I load the original CT scan, the DRR generation works well (both .png image and .mha image are written as DRRs).

-        When I load the CT scan after rotation by 90°, the program works (both .png image and .mha image are written as DRRs and they look alright) but it crashes immediately after writing the images ("Python.exe has stopped working").

-        If I rotate the original CT scan by 0° rather than by 90°, the crash does not occur (meaning that my code for rotation+resampling works for a 0° rotation).

-        I tried to rotate the original CT scan by only 0.1°, and the problem comes up again, meaning the that it's not an issue concerning the geometry of the camera system (focal length, principal point coordinates).

Why could this be happening?


I would appreciate any clarification about these two points.

Thank you,

Fabio.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20160926/cf9f2c8d/attachment.html>