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 <[email protected]> 于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 <[email protected]> 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 <[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 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 ) > >>>>>>>> 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
