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

Chao Wu wuchao04 at gmail.com
Wed Aug 22 09:55:29 EDT 2018 

What I tried to give is the physical position of the origin in an ITK
image: a vector shift of -m_Origin from the center of the first pixel. I
didn't mean the position represented by indices.
I should say "... In ITK this is at Pixel(0,0)−m_Origin in 2D or
Voxel(0,0,0)−m_Origin in 3D in physical space".
I agree this is complex for this document, so maybe best to keep your first
change.

Simon Rit <simon.rit at creatis.insa-lyon.fr> 于2018年8月22日周三 下午3:40写道：

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20180822/c1575dcc/attachment-0001.html>

More information about the Rtk-users mailing list