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 <[email protected]> 于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 <[email protected]> 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 <[email protected]> 于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 <[email protected]> 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 <[email protected]> 于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 < >>>>> [email protected]> 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: [email protected] >>>>>> >>>>>> Cell: +45 3165 8140 >>>>>> >>>>>> >>>>>> On Mon, 20 Aug 2018 at 22:10, Milan Manasijevic < >>>>>> [email protected]> 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: [email protected] >>>>>>> >>>>>>> Cell: +45 3165 8140 >>>>>>> >>>>>>> >>>>>>> On Sun, 19 Aug 2018 at 23:44, Milan Manasijevic < >>>>>>> [email protected]> 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 >>>>>>>> [email protected] >>>>>>>> https://public.kitware.com/mailman/listinfo/rtk-users >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>> Rtk-users mailing list >>>>>> [email protected] >>>>>> https://public.kitware.com/mailman/listinfo/rtk-users >>>>>> >>>>> _______________________________________________ >>>>> Rtk-users mailing list >>>>> [email protected] >>>>> https://public.kitware.com/mailman/listinfo/rtk-users >>>>> >>>>
_______________________________________________ Rtk-users mailing list [email protected] https://public.kitware.com/mailman/listinfo/rtk-users
