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
