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
