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

Chao Wu wuchao04 at gmail.com
Wed Aug 22 08:45:50 EDT 2018 

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 <http://www.openrtk.org/Doxygen/DocGeo3D.html>
>>> 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
>>>>>>> <https://gitlab.com/agravgaard/cbctrecon/wikis/Installation> )
>>>>>>> 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
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20180822/6ee41e4a/attachment-0001.html>

More information about the Rtk-users mailing list