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

[Chao Wu]

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  于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  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  于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  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  于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  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  于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 

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

[Simon Rit]

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  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  于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  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  于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  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  于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. 

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

[Chao Wu]

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  于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  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  于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  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  于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 <
> andreasg...@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 

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

[Simon Rit]

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  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  于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  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  于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 <
 andreasg...@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
>

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

[Simon Rit]

Hi,
To be honest, it's quite hard to guess the meaning of YS in test.pcj
but I would be suprised if it corresponds to source_y... Maybe you
should find the documentation regarding the meaning of YS and we can
help in relating it to RTK's geometry parameters.
Best regards,
Simon
On Tue, Aug 21, 2018 at 11:35 PM Milan Manasijevic
 wrote:
>
> Hi Simon,
>
> my understanding of origin in this context was wrong. Your advise makes sense 
> and I ran the reconstruction succesfully by setting the values 
> --proj_iso_x=-202.3 --proj_iso_y=-202.3. I didn't investigate the result 
> further, but at first glance it is a big step ahead for me. Regarding the 
> source_y value, It is given in the test.pca and also in the test.pcj file 
> (please check the dropbox).
> Similar to the value of the ZSample=180.611687 (which is SID) the value of 
> YSample is given by YSample=-16.412937. My understanding is that this should 
> be the SourceOfsetY. However, in my first attempt today, I didn't use that 
> argument.
>
> Many thanks for helping me.
>
> Best Regards,
> Milan
>
>
>
> Am 21.08.2018 um 13:25 schrieb Simon Rit:
>
> 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  
> 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: agravga...@protonmail.com
>>
>> Cell:  +45 3165 8140
>>
>>
>>
>> On Mon, 20 Aug 2018 at 22:10, Milan Manasijevic 
>>  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 (00C71D4FE5D0)
>>> Location: "void __cdecl itk::ImageFileWriter 
>>> >::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 

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

[Milan Manasijevic]

Hi Simon,

my understanding of origin in this context was wrong. Your advise makes 
sense and I ran the reconstruction succesfully by setting the values 
--proj_iso_x=-202.3 --proj_iso_y=-202.3. I didn't investigate the result 
further, but at first glance it is a big step ahead for me. Regarding 
the source_y value, It is given in the test.pca and also in the test.pcj 
file (please check the dropbox).
Similar to the value of the ZSample=180.611687 (which is SID) the value 
of YSample is given by YSample=-16.412937. My understanding is that this 
should be the SourceOfsetY. However, in my first attempt today, I didn't 
use that argument.


Many thanks for helping me.

Best Regards,
Milan



Am 21.08.2018 um 13:25 schrieb Simon Rit:

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 
mailto:andreasg...@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: agravga...@protonmail.com 

Cell: +45 3165 8140



On Mon, 20 Aug 2018 at 22:10, Milan Manasijevic
mailto:milan-manasije...@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 (00C71D4FE5D0)
Location: "void __cdecl itk::ImageFileWriter >::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
   

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

[Chao Wu]

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  于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  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  于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 
>>> 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: agravga...@protonmail.com

 Cell:  +45 3165 8140


 On Mon, 20 Aug 2018 at 22:10, Milan Manasijevic <
 milan-manasije...@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 

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

[Simon Rit]

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  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  于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 
>> 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: agravga...@protonmail.com
>>>
>>> Cell:  +45 3165 8140
>>>
>>>
>>> On Mon, 20 Aug 2018 at 22:10, Milan Manasijevic <
>>> milan-manasije...@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 (00C71D4FE5D0)
 Location: "void __cdecl itk::ImageFileWriter
 >::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
 

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

[Chao Wu]

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  于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 
> 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: agravga...@protonmail.com
>>
>> Cell:  +45 3165 8140
>>
>>
>> On Mon, 20 Aug 2018 at 22:10, Milan Manasijevic <
>> milan-manasije...@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 (00C71D4FE5D0)
>>> Location: "void __cdecl itk::ImageFileWriter
>>> >::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 

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

[Simon Rit]

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 
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: agravga...@protonmail.com
>
> Cell:  +45 3165 8140
>
>
> On Mon, 20 Aug 2018 at 22:10, Milan Manasijevic <
> milan-manasije...@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 (00C71D4FE5D0)
>> Location: "void __cdecl itk::ImageFileWriter
>> >::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: agravga...@protonmail.com
>>
>> Cell:  +45 3165 8140
>>
>>
>> On Sun, 19 Aug 2018 at 23:44, Milan Manasijevic <
>> milan-manasije...@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 

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

[Andreas Andersen]

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: agravga...@protonmail.com

Cell:  +45 3165 8140


On Mon, 20 Aug 2018 at 22:10, Milan Manasijevic <
milan-manasije...@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 (00C71D4FE5D0)
> Location: "void __cdecl itk::ImageFileWriter
> >::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: agravga...@protonmail.com
>
> Cell:  +45 3165 8140
>
>
> On Sun, 19 Aug 2018 at 23:44, Milan Manasijevic <
> milan-manasije...@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.2000
>> PixelsizeY=0.2000
>> NrPixelsX=2024
>> NrPixelsY=2024
>>
>> Finally, these are commands that I used to reconstruct the volume:

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

[Milan Manasijevic]

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 (00C71D4FE5D0)
Location: "void __cdecl itk::ImageFileWriter 
>::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: agravga...@protonmail.com 

Cell: +45 3165 8140



On Sun, 19 Aug 2018 at 23:44, Milan Manasijevic 
mailto:milan-manasije...@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.2000
PixelsizeY=0.2000
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. 

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

[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: agravga...@protonmail.com

Cell:  +45 3165 8140


On Sun, 19 Aug 2018 at 23:44, Milan Manasijevic <
milan-manasije...@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.2000
> PixelsizeY=0.2000
> 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@public.kitware.com
> https://public.kitware.com/mailman/listinfo/rtk-users
>
___
Rtk-users mailing list
Rtk-users@public.kitware.com
https://public.kitware.com/mailman/listinfo/rtk-users

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

[Milan Manasijevic]

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.2000
PixelsizeY=0.2000
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@public.kitware.com
https://public.kitware.com/mailman/listinfo/rtk-users