[Rtk-users] Cannot reconstruct the volume, what might be the problem?

Simon Rit simon.rit at creatis.insa-lyon.fr
Wed Aug 22 09:40:22 EDT 2018 

It's actually more complex than that. The index to mm conversion is
m_Direction*m_Spacing*index+m_Origin
so point with all mm coordinates at 0 has index (that's what you're
trying to give ?)
-m_Spacing^-1*m_Direction^-1*m_Origin.
I find it a bit too complex for this documentation which is not meant
to deal with pixel index stuff...
On Wed, Aug 22, 2018 at 2:46 PM Chao Wu <wuchao04 at gmail.com> wrote:
>
> Looks great.
> Now I understand you story about point (0,0) and the itk m_Origin.
> I read point (0,0) as pixel (0,0) yesterday so I was confused.
> "point (0,0)" followed by "mm" is much less ambiguous.
> Maybe instead of saying "... (and not to m_Origin in ITK)", you can write down the actual relationship, something like
>    In the following, origin refers to point with coordinates 0 mm. In ITK this is at Pixel(0,0)−m_Origin in 2D or Voxel(0,0,0)−m_Origin in 3D.
>
> Regards,
> Chao
>
> Simon Rit <simon.rit at creatis.insa-lyon.fr> 于2018年8月22日周三 下午1:42写道：
>>
>> Hi,
>> I have made some amendments to the documentation to try to clarify this:
>> https://github.com/SimonRit/RTK/commit/fea8e136b7248f42be29ef2d5fbaf3d26e12cfbb
>> http://www.openrtk.org/Doxygen/DocGeo3D.html
>> Any suggestion to improve this is welcome.
>> Best regards,
>> Simon
>>
>>
>> On Tue, Aug 21, 2018 at 4:39 PM Chao Wu <wuchao04 at gmail.com> wrote:
>>>
>>> Thank you for the clarification and confirmation of the minus sign here.
>>>
>>> To me the source of confusion is the description of --proj_iso_x and --proj_iso_x in the command line (or from the GGO file):
>>>>
>>>> option "proj_iso_x"  - "X coordinate on the projection image of isocenter"     double no  default="0"
>>>> option "proj_iso_y"  - "Y coordinate on the projection image of isocenter"     double no  default="0"
>>>
>>> If one read this, he may give positive values to the two arguments since "the coordinates of isocenter in the projection image coordinate system" are positive.
>>>
>>> I did not suggest the redundance. I meant the way how the tranlation is calculated (source_# - proj_iso_#) proves that proj_iso_# is projection origin wrt isocenter, not the other way around (then the right form will be source_# + proj_iso_#).
>>>
>>>
>>> Simon Rit <simon.rit at creatis.insa-lyon.fr> 于2018年8月21日周二 下午3:44写道：
>>>>
>>>> Sorry, I checked the doc and you're right, "(ProjectionOffsetX,ProjectionOffsetY,SourceToIsocenterDistance-SourceToDetectorDistance) are the coordinates of the detector origin in the rotated coordinated system". So yes, add minus signs in front of proj_iso_x and proj_iso_y in my email.
>>>> One source of confusion here (to me too) is that I refer here to "origin" as point "(0,0)" and not to m_Origin in the itk::Image object... Any suggestion to improve this is welcome.
>>>> On the other hand, you seem to suggest that source offsets and projection offsets are redundant which is not true in a divergent geometry (or I did not get you).
>>>> Thanks a lot for your correction.
>>>> Simon
>>>>
>>>>
>>>> On Tue, Aug 21, 2018 at 3:28 PM Chao Wu <wuchao04 at gmail.com> wrote:
>>>>>
>>>>> Hi Simon,
>>>>>
>>>>> The --proj_iso_x and --proj_iso_y arguments are confusing to me.
>>>>>
>>>>> Their explanation states that they are the X/Y coordinates on the projection image of isocenter, but in practice I found them to be the projection offset in X/Y wrt to central ray (similar to --source_x and --source_y arguments).
>>>>>
>>>>> Therefore in the above case I would give --proj_iso_x=-202.3 --proj_iso_y=-202.3 if the image origin is at pixel (0,0) and the +x and +y directions are aligned with the i and j indices of projection images, respectively, which is the normal case when reading from TIFF files.
>>>>>
>>>>> In rtk::ThreeDCircularProjectionGeometry::AddProjectionInRadians() this two arguments are named as projOffsetX and projOffsetY, similar to the ones for the source sourceOffsetX and sourceOffsetY, implying that the argument description is problematic. The way of calculation of submatrix AddProjectionTranslationMatrix( ComputeTranslationHomogeneousMatrix(sourceOffsetX-projOffsetX, sourceOffsetY-projOffsetY) ) also supports that they are projection origin wrt isocenter instead of isocenter wrt projection origin.
>>>>>
>>>>> Best regards,
>>>>> Chao
>>>>>
>>>>>
>>>>> Simon Rit <simon.rit at creatis.insa-lyon.fr> 于2018年8月21日周二 下午1:26写道：
>>>>>>
>>>>>> Hi,
>>>>>> It's not clear to me how you came up with your source_y value. Assuming that the origin of your projections is 0,0,0, I would advise to set the geometry with --proj_iso_x=202.3 --proj_iso_y=202.3 (or, equivalently, set a new origin to the projection equal to -202.3,-202.3,0).
>>>>>> The --arc value is also a bit surprising but you can check if the assigned GantryAngle is the correct one for each projection.
>>>>>> Finally, in rtkfdk, setting origin (this time for the volume) to a y-value equal 0 means that you only look at the part above the source trajectory. I would leave the default values (centered volume around the center of rotation).
>>>>>> Best regards,
>>>>>> Simon
>>>>>>
>>>>>>
>>>>>> On Tue, Aug 21, 2018 at 12:01 AM Andreas Andersen <andreasga22 at gmail.com> wrote:
>>>>>>>
>>>>>>> Hi Milan
>>>>>>>
>>>>>>> 1) OK, I guess it makes sense with the source/detector geometry.
>>>>>>>
>>>>>>> 2) I forgot to check which group RawImageIO was in; it's own apparently.
>>>>>>> So you'll have to re-compile ITK with the CMake option: Module_ITKIORAW=ON
>>>>>>> (You'll have to add the entry manually if you use a CMake GUI)
>>>>>>>
>>>>>>> 3) Origin is not the isocenter, it is the offset of the image origin, i.e. index 0,0,0, in relation to the isocenter (AFAIK).
>>>>>>> Just a guess: Try with an offset of: -0.03840368 * {421,0,471} / 2 => "--origin -8.08,0,-9.04"
>>>>>>> (I forget the definition of the y-axis, so I'm unsure about the "0", if it doesn't work also try -10.23, 10.23, multiplying it by 2, and 0.)
>>>>>>>
>>>>>>> Best regards
>>>>>>> Andreas
>>>>>>>
>>>>>>> __________________________________
>>>>>>>
>>>>>>> Andreas Gravgaard Andersen
>>>>>>>
>>>>>>> Department of Oncology,
>>>>>>>
>>>>>>> Aarhus University Hospital
>>>>>>>
>>>>>>> Nørrebrogade 44,
>>>>>>>
>>>>>>> 8000, Aarhus C
>>>>>>>
>>>>>>> Mail:     agravgaard at protonmail.com
>>>>>>>
>>>>>>> Cell:      +45 3165 8140
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, 20 Aug 2018 at 22:10, Milan Manasijevic <milan-manasijevic at t-online.de> wrote:
>>>>>>>>
>>>>>>>> Hi Andreas,
>>>>>>>> I am really grateful that you've found time to response so quickly.
>>>>>>>>
>>>>>>>> 1) Following your suggestions I first checked the spacing. I suppose, you refer to the value of 0.03840368. I am confident, this is the correct value in the correct unit (mm).
>>>>>>>> The 4D Slicer shows the dimensions in mm and this is near to the object measures.
>>>>>>>>
>>>>>>>> 2) The second try was to check if the " -o fdk.raw" works.
>>>>>>>> Unfortunately not, I get such exception:
>>>>>>>> itk::ImageFileWriterException (000000C71D4FE5D0)
>>>>>>>> Location: "void __cdecl itk::ImageFileWriter<class itk::Image<float,3> >::Write(void)"
>>>>>>>> File: d:\reconstruction_rtk\itk\modules\io\imagebase\include\itkImageFileWriter.hxx
>>>>>>>> Line: 151
>>>>>>>> Description:  Could not create IO object for writing file fdk.raw
>>>>>>>>   Tried to create one of the following:
>>>>>>>>     NiftiImageIO
>>>>>>>>     NrrdImageIO
>>>>>>>>     GiplImageIO
>>>>>>>>     HDF5ImageIO
>>>>>>>>     JPEGImageIO
>>>>>>>>     BMPImageIO
>>>>>>>>     LSMImageIO
>>>>>>>>     PNGImageIO
>>>>>>>>     TIFFImageIO
>>>>>>>>     VTKImageIO
>>>>>>>>     StimulateImageIO
>>>>>>>>     BioRadImageIO
>>>>>>>>     MetaImageIO
>>>>>>>>     MRCImageIO
>>>>>>>>     GE4ImageIO
>>>>>>>>     GE5ImageIO
>>>>>>>>     HndImageIO
>>>>>>>>     XimImageIO
>>>>>>>>     HisImageIO
>>>>>>>>     ImagXImageIO
>>>>>>>>     DCMImagXImageIO
>>>>>>>>     EdfImageIO
>>>>>>>>     XRadImageIO
>>>>>>>>     OraImageIO
>>>>>>>>     GDCMImageIO
>>>>>>>>   You probably failed to set a file suffix, or
>>>>>>>>     set the suffix to an unsupported type.
>>>>>>>>
>>>>>>>>
>>>>>>>> 3) Regarding the "--origin argument" and refering to my context (see attached files please), what would you suggest, what should I pass as the origin values? The detecetor origin is at 0,0 but for the Volume I am not quit sure if I should provide some values and which (actually isocenter should be at 0,0,0 and if I provide these values I still get no result ). Probably this would solve my problem.
>>>>>>>>
>>>>>>>> Again, many thanks for your time and thank you for your help.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Milan
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Am 20.08.2018 um 14:26 schrieb Andreas Andersen:
>>>>>>>>
>>>>>>>> Hi Milan
>>>>>>>>
>>>>>>>> I didn't open the dropbox link, but I think in general one should take an extra look at the rtkfdk arguments if nothing "meaningful" comes out:
>>>>>>>>  Is your spacing in the correct unit (mm)? it seems quite small in relation to the dimensions.
>>>>>>>>  Also try adding the --origin argument.
>>>>>>>>
>>>>>>>> Additional 1:
>>>>>>>> Slicer is a good tool for exactly that.
>>>>>>>> ( I have also made a similar tool with some reconstruction options, mainly for scatter correction: cbctrecon )
>>>>>>>> Additional 2:
>>>>>>>> try giving " -o fdk.raw" instead of  "-o fdk.mha", the default output value type is 32-bit floating point.
>>>>>>>>
>>>>>>>> Best regards
>>>>>>>>  Andreas
>>>>>>>>
>>>>>>>> __________________________________
>>>>>>>>
>>>>>>>> Andreas Gravgaard Andersen
>>>>>>>>
>>>>>>>> Department of Oncology,
>>>>>>>>
>>>>>>>> Aarhus University Hospital
>>>>>>>>
>>>>>>>> Nørrebrogade 44,
>>>>>>>>
>>>>>>>> 8000, Aarhus C
>>>>>>>>
>>>>>>>> Mail:     agravgaard at protonmail.com
>>>>>>>>
>>>>>>>> Cell:      +45 3165 8140
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sun, 19 Aug 2018 at 23:44, Milan Manasijevic <milan-manasijevic at t-online.de> wrote:
>>>>>>>>>
>>>>>>>>> Hi RTK-users,
>>>>>>>>>
>>>>>>>>> I am trying to reconstruct a sample scanned using the CBCT. Rtk seems to
>>>>>>>>> be the best chioce for that, but unfortenately I have no success.
>>>>>>>>> Hopefully, some of you guys can help.
>>>>>>>>>
>>>>>>>>> The outcome of the scanning are 2500 projections (each 2024x2024 pixels).
>>>>>>>>> The increasement of the rotation angle is 0.144 degree
>>>>>>>>> To reduce the reconstruction time I use just 79 projection images and
>>>>>>>>> angle increasement is 4.608 degree.
>>>>>>>>>
>>>>>>>>> The data regarding the scanning process are (test.pca, test.pcj and
>>>>>>>>> test.pcr) dropped
>>>>>>>>> here:https://www.dropbox.com/sh/on7c049aqx5ep1r/AAA7THDCkIHPF_9DBRl7MwROa?dl=0
>>>>>>>>>
>>>>>>>>>  From these three files I have the following values required for the
>>>>>>>>> reconstruction:
>>>>>>>>> [Geometry]
>>>>>>>>> FDD=940.59570922
>>>>>>>>> FOD=180.61168750
>>>>>>>>> VoxelSizeX=0.03840368
>>>>>>>>> VoxelSizeY=0.03840368
>>>>>>>>>
>>>>>>>>> [VolumeData]
>>>>>>>>> Volume_SizeX=421
>>>>>>>>> Volume_SizeY=533
>>>>>>>>> Volume_SizeZ=471
>>>>>>>>>
>>>>>>>>> [Detector]
>>>>>>>>> PixelsizeX=0.20000000
>>>>>>>>> PixelsizeY=0.20000000
>>>>>>>>> NrPixelsX=2024
>>>>>>>>> NrPixelsY=2024
>>>>>>>>>
>>>>>>>>> Finally, these are commands that I used to reconstruct the volume:
>>>>>>>>>
>>>>>>>>> ==========================================================================================================================================
>>>>>>>>> rtksimulatedgeometry --output="geometry.xml" --nproj=79 --arc=364.032
>>>>>>>>> --sdd=940.59570922 --sid=180.611687 --source_y=-16.412937
>>>>>>>>> rtkprojections --path "d:\data\test\tiffs" --output "projections.mha"
>>>>>>>>> --regexp .tif --newspacing 0.2
>>>>>>>>> rtkfdk -p . -r projections.mha -o fdk.mha -g geometry.xml
>>>>>>>>> --spacing=0.03840368,0.03840368,0.03840368 --dimension=421,533,471
>>>>>>>>> ==========================================================================================================================================
>>>>>>>>>
>>>>>>>>> I use the VV, the 4D Slicer to check the results fro both,
>>>>>>>>> projections.mha and fdk.mha. The first one looks fine and shows tha
>>>>>>>>> sample correctly, but fdk.mha does not show any meaningfull information.
>>>>>>>>> The jpgs that show that, you can also find in the dropbox.
>>>>>>>>>
>>>>>>>>> Probably, I need to include the ROI values given in the test.pcr file
>>>>>>>>> but I am not sure how. Would that be the neworigin value. (I have tried
>>>>>>>>> but no success).
>>>>>>>>>
>>>>>>>>> Any help on that is highly appreciated!
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> In addition I would have another two questions:
>>>>>>>>> 1. Can anyone advice a proper tool to check the reconstruction result
>>>>>>>>> (the reconstructed volume)?
>>>>>>>>> 2. I am using the Voreen (https://www.uni-muenster.de/Voreen/) and would
>>>>>>>>> rather have the reconstruction result in a raw file format (containing
>>>>>>>>> intensities as a 32-Bit floats). How can I convert mha into raw? (I
>>>>>>>>> tried to split the mha into mhd and raw, but no success)
>>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>> Milan
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Rtk-users mailing list
>>>>>>>>> Rtk-users at public.kitware.com
>>>>>>>>> https://public.kitware.com/mailman/listinfo/rtk-users
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Rtk-users mailing list
>>>>>>> Rtk-users at public.kitware.com
>>>>>>> https://public.kitware.com/mailman/listinfo/rtk-users
>>>>>>
>>>>>> _______________________________________________
>>>>>> Rtk-users mailing list
>>>>>> Rtk-users at public.kitware.com
>>>>>> https://public.kitware.com/mailman/listinfo/rtk-users

More information about the Rtk-users mailing list