From simon.rit at creatis.insa-lyon.fr  Thu Aug  2 03:19:49 2018
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Thu, 2 Aug 2018 09:19:49 +0200
Subject: [Rtk-users] RTK - reconstruction of simulated images
In-Reply-To: <CAPpmpVbhQwzVyoU5ZhZ3C0vDOJo_NBzq_wEBy247_bhgROaGAQ@mail.gmail.com>
References: <CAPpmpVbhQwzVyoU5ZhZ3C0vDOJo_NBzq_wEBy247_bhgROaGAQ@mail.gmail.com>
Message-ID: <CAF0oig1Lxgv2=PBupAZXwnQgmzMWF=nmLarbCghTh5tnnnPnDw@mail.gmail.com>

Dear Anna,
Please use RTK's mailing list for your questions.
As far as I know, ASTRA is iterative so it should handle offset detectors.
You'll just have minor residual artifacts, see e.g. figure 8 of
dx.doi.org/10.1088/0031-9155/58/2/205.
Yes, RTK can handle jpeg and png. Any file type that is handled by ITK is
handled by RTK.
There are no hardware requirements, it just gets slower with poorer
hardware.
I hope this helps,
Simon

On Wed, Aug 1, 2018 at 10:50 PM, Anna Povoln? <anna.povolna at gmail.com>
wrote:

> Dear Mr. Rit,
>
> I'm a student of Radiological Physics at FNSPE CTU, currently working on
> my diploma thesis and I'm writing you, because today I ran into your
> Reconstruction Toolkit and I wanted to ask if its possible to use the RTK
> for simulated images/projections (from EGSnrc code) which are in png/jpg
> format? So far I have been using the ASTRA Toolbox in Matlab for the
> reconstruction, so I managed to put my images there, but I still need to
> implement a shifted geometry of a detector and x-ray source for Varian's
> TrueBeam CBCT and I was told at the ASTRA forum that I should look at your
> RTK for this.
>
> Also what are the hardware requirements for the reconstruction? Because I
> can use Matlab on powerful PCs at my university, but they wouldn't allow me
> to install the RTK there, so I would have to use my own notebook...
>
> I'm sorry for asking so many questions, but it will help me a lot if
> you'll answer them before I'll try the RTK.
> Thank you very much and have a nice day!
>
> Yours sincerely,
> Anna Povoln?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20180802/01ac255b/attachment.html>

From James.Korte at petermac.org  Wed Aug  8 01:20:46 2018
From: James.Korte at petermac.org (Korte James)
Date: Wed, 8 Aug 2018 05:20:46 +0000
Subject: [Rtk-users] Reconstructing from TrueBeam data
Message-ID: <5422EC0047E2FA49B1B02A7AA280DDE107593A7E@STPR-EXMBX1.petermac.org.au>

Hi,

I'm having some issues reconstructing CBCT data from a Varian TrueBeam system.

Just wondering if I am doing something really stupid? Does RTK support imaging data off a TrueBeam system?

I found a good masters thesis where they modified RTK and pre-processed TrueBeam data, but wanted to get some feedback before investing time into a custom solution (https://open.library.ubc.ca/cIRcle/collections/ubctheses/24/items/1.0167188)

I've just been using the RTK command line interface. First creating a geometry file using "rtkvarianprobeamgeometry.exe" as the Scan.xml file from our TrueBeam data has a very similar structure to the Scan.xml from the RTK probeam example:
rtkvarianprobeamgeometry.exe -v -x Scan.xml -o geometry.xml -p Acquisitions\763250797\ -r Proj.*.xim

I then try to reconstruct using the FDK algorithm using the following command:
rtkfdk.exe -v -g geometry.xml -o slices.mha -p Acquisitions\763250797\ -r Proj.*.xim

And I get the following error:
Regular expression matches 893 file(s)...
Reading...
ExceptionObject caught with reader->Update() in file c:\path-to-rtk-src\rtk
\applications\rtkfdk\rtkfdk.cxx line 63

itk::InvalidRequestedRegionError (00000000002FDFF8)
Location: "void __cdecl itk::ImageFileReader<class itk::Image<unsigned int,3>,cl
ass itk::DefaultConvertPixelTraits<unsigned int> >::EnlargeOutputRequestedRegion
(class itk::DataObject *)"
File: c:\path-to-itk-src\src\modules\io\imagebase\include\itkimagefilereader.hxx
Line: 350
Description: ImageIO returns IO region that does not fully contain the requested
regionRequested region: ImageRegion (00000000002FDC48)
  Dimension: 3
  Index: [0, 0, 0]
  Size: [1024, 768, 1]
StreamableRegion region: ImageRegion (00000000002FDBF8)
  Dimension: 3
  Index: [0, 0, 0]
  Size: [0, 0, 1]


Cheers!
James Korte

Disclaimer: This email (including any attachments or links) may contain confidential and/or legally privileged information and is intended only to be read or used by the addressee.  If you are not the intended addressee, any use, distribution, disclosure or copying of this email is strictly prohibited.  Confidentiality and legal privilege attached to this email (including any attachments) are not waived or lost by reason of its mistaken delivery to you.  If you have received this email in error, please delete it and notify us immediately by telephone or email.  Peter MacCallum Cancer Centre provides no guarantee that this transmission is free of virus or that it has not been intercepted or altered and will not be liable for any delay in its receipt.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20180808/72af09aa/attachment.html>

From andreasga22 at gmail.com  Wed Aug  8 03:21:23 2018
From: andreasga22 at gmail.com (Andreas Andersen)
Date: Wed, 8 Aug 2018 09:21:23 +0200
Subject: [Rtk-users] Reconstructing from TrueBeam data
In-Reply-To: <5422EC0047E2FA49B1B02A7AA280DDE107593A7E@STPR-EXMBX1.petermac.org.au>
References: <5422EC0047E2FA49B1B02A7AA280DDE107593A7E@STPR-EXMBX1.petermac.org.au>
Message-ID: <CAE0aawE6hM64KUb3e9mMtyLQG9P5pFdgu2eBWs6n43fuLt2wmQ@mail.gmail.com>

Hi James,
The probeam and truebeam .xim format should be the same.
 Sometimes the last projection is empty, which could cause problems like
what you see.
Moving, deleting, or just renaming, the last projection should solve that
problem.
Let me know if this works for you.

Best regards
Andreas



On Wed, 8 Aug 2018, 07:31 Korte James, <James.Korte at petermac.org> wrote:

> Hi,
>
>
>
> I?m having some issues reconstructing CBCT data from a Varian TrueBeam
> system.
>
>
>
> Just wondering if I am doing something really stupid? Does RTK support
> imaging data off a TrueBeam system?
>
>
>
> I found a good masters thesis where they modified RTK and pre-processed
> TrueBeam data, but wanted to get some feedback before investing time into a
> custom solution (
> https://open.library.ubc.ca/cIRcle/collections/ubctheses/24/items/1.0167188
> )
>
>
>
> I?ve just been using the RTK command line interface. First creating a
> geometry file using ?rtkvarianprobeamgeometry.exe? as the Scan.xml file
> from our TrueBeam data has a very similar structure to the Scan.xml from
> the RTK probeam example:
>
> rtkvarianprobeamgeometry.exe -v -x Scan.xml -o geometry.xml -p
> Acquisitions\763250797\ -r Proj.*.xim
>
>
>
> I then try to reconstruct using the FDK algorithm using the following
> command:
>
> rtkfdk.exe -v -g geometry.xml -o slices.mha -p Acquisitions\763250797\ -r
> Proj.*.xim
>
>
>
> And I get the following error:
>
> Regular expression matches 893 file(s)...
>
> Reading...
>
> ExceptionObject caught with reader->Update() in file c:\path-to-rtk-src\rtk
>
> \applications\rtkfdk\rtkfdk.cxx line 63
>
>
>
> itk::InvalidRequestedRegionError (00000000002FDFF8)
>
> Location: "void __cdecl itk::ImageFileReader<class itk::Image<unsigned
> int,3>,cl
>
> ass itk::DefaultConvertPixelTraits<unsigned int>
> >::EnlargeOutputRequestedRegion
>
> (class itk::DataObject *)"
>
> File:
> c:\path-to-itk-src\src\modules\io\imagebase\include\itkimagefilereader.hxx
>
> Line: 350
>
> Description: ImageIO returns IO region that does not fully contain the
> requested
>
> regionRequested region: ImageRegion (00000000002FDC48)
>
>   Dimension: 3
>
>   Index: [0, 0, 0]
>
>   Size: [1024, 768, 1]
>
> StreamableRegion region: ImageRegion (00000000002FDBF8)
>
>   Dimension: 3
>
>   Index: [0, 0, 0]
>
>   Size: [0, 0, 1]
>
>
>
>
>
> Cheers!
>
> James Korte
>
>
>
> *Disclaimer:* This email (including any attachments or links) may contain
> confidential and/or legally privileged information and is intended only to
> be read or used by the addressee.  If you are not the intended addressee,
> any use, distribution, disclosure or copying of this email is strictly
> prohibited.  Confidentiality and legal privilege attached to this email
> (including any attachments) are not waived or lost by reason of its
> mistaken delivery to you.  If you have received this email in error, please
> delete it and notify us immediately by telephone or email.  Peter MacCallum
> Cancer Centre provides no guarantee that this transmission is free of virus
> or that it has not been intercepted or altered and will not be liable for
> any delay in its receipt.
> _______________________________________________
> Rtk-users mailing list
> Rtk-users at public.kitware.com
> https://public.kitware.com/mailman/listinfo/rtk-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20180808/7cb366c7/attachment.html>

From andreasga22 at gmail.com  Wed Aug  8 10:04:10 2018
From: andreasga22 at gmail.com (Andreas Andersen)
Date: Wed, 8 Aug 2018 16:04:10 +0200
Subject: [Rtk-users] Reconstructing from TrueBeam data
In-Reply-To: <5422EC0047E2FA49B1B02A7AA280DDE107593C8F@STPR-EXMBX1.petermac.org.au>
References: <5422EC0047E2FA49B1B02A7AA280DDE107593A7E@STPR-EXMBX1.petermac.org.au>
 <CAE0aawE6hM64KUb3e9mMtyLQG9P5pFdgu2eBWs6n43fuLt2wmQ@mail.gmail.com>
 <5422EC0047E2FA49B1B02A7AA280DDE107593C8F@STPR-EXMBX1.petermac.org.au>
Message-ID: <CAE0aawGpB2EXX+kW3TSZjibSSK=BLJ4BFK7g9hT72jFs543mqA@mail.gmail.com>

Hi James,

Good that it works.
I know it is a work-around and not a real solution. I'll look into how to
best do the check. (And then create a pull request on GitHub)

Best regards
Andreas

On Wed, 8 Aug 2018, 12:49 Korte James, <James.Korte at petermac.org> wrote:

> Hi Andreas,
>
>
>
> Everything works now! Can?t believe I missed this? should have kept
> scrolling till the final projection.
>
>
>
> Perhaps a check could be added to the code,  the .xml file has a count
> field that could be matched to the number of projection files selected by
> the regex?
>
>
>
> Thanks for your help!
>
>
>
> Cheers,
>
> James
>
>
>
>
>
> *From:* Andreas Andersen [mailto:andreasga22 at gmail.com]
> *Sent:* Wednesday, 8 August 2018 5:21 PM
> *To:* Korte James
> *Cc:* rtk-users at public.kitware.com
> *Subject:* Re: [Rtk-users] Reconstructing from TrueBeam data
>
>
>
> Hi James,
>
> The probeam and truebeam .xim format should be the same.
>
>  Sometimes the last projection is empty, which could cause problems like
> what you see.
>
> Moving, deleting, or just renaming, the last projection should solve that
> problem.
>
> Let me know if this works for you.
>
>
>
> Best regards
>
> Andreas
>
>
>
>
>
> On Wed, 8 Aug 2018, 07:31 Korte James, <James.Korte at petermac.org> wrote:
>
> Hi,
>
>
>
> I?m having some issues reconstructing CBCT data from a Varian TrueBeam
> system.
>
>
>
> Just wondering if I am doing something really stupid? Does RTK support
> imaging data off a TrueBeam system?
>
>
>
> I found a good masters thesis where they modified RTK and pre-processed
> TrueBeam data, but wanted to get some feedback before investing time into a
> custom solution (
> https://open.library.ubc.ca/cIRcle/collections/ubctheses/24/items/1.0167188
> )
>
>
>
> I?ve just been using the RTK command line interface. First creating a
> geometry file using ?rtkvarianprobeamgeometry.exe? as the Scan.xml file
> from our TrueBeam data has a very similar structure to the Scan.xml from
> the RTK probeam example:
>
> rtkvarianprobeamgeometry.exe -v -x Scan.xml -o geometry.xml -p
> Acquisitions\763250797\ -r Proj.*.xim
>
>
>
> I then try to reconstruct using the FDK algorithm using the following
> command:
>
> rtkfdk.exe -v -g geometry.xml -o slices.mha -p Acquisitions\763250797\ -r
> Proj.*.xim
>
>
>
> And I get the following error:
>
> Regular expression matches 893 file(s)...
>
> Reading...
>
> ExceptionObject caught with reader->Update() in file c:\path-to-rtk-src\rtk
>
> \applications\rtkfdk\rtkfdk.cxx line 63
>
>
>
> itk::InvalidRequestedRegionError (00000000002FDFF8)
>
> Location: "void __cdecl itk::ImageFileReader<class itk::Image<unsigned
> int,3>,cl
>
> ass itk::DefaultConvertPixelTraits<unsigned int>
> >::EnlargeOutputRequestedRegion
>
> (class itk::DataObject *)"
>
> File:
> c:\path-to-itk-src\src\modules\io\imagebase\include\itkimagefilereader.hxx
>
> Line: 350
>
> Description: ImageIO returns IO region that does not fully contain the
> requested
>
> regionRequested region: ImageRegion (00000000002FDC48)
>
>   Dimension: 3
>
>   Index: [0, 0, 0]
>
>   Size: [1024, 768, 1]
>
> StreamableRegion region: ImageRegion (00000000002FDBF8)
>
>   Dimension: 3
>
>   Index: [0, 0, 0]
>
>   Size: [0, 0, 1]
>
>
>
>
>
> Cheers!
>
> James Korte
>
>
>
> *Disclaimer:* This email (including any attachments or links) may contain
> confidential and/or legally privileged information and is intended only to
> be read or used by the addressee.  If you are not the intended addressee,
> any use, distribution, disclosure or copying of this email is strictly
> prohibited.  Confidentiality and legal privilege attached to this email
> (including any attachments) are not waived or lost by reason of its
> mistaken delivery to you.  If you have received this email in error, please
> delete it and notify us immediately by telephone or email.  Peter MacCallum
> Cancer Centre provides no guarantee that this transmission is free of virus
> or that it has not been intercepted or altered and will not be liable for
> any delay in its receipt.
>
> _______________________________________________
> Rtk-users mailing list
> Rtk-users at public.kitware.com
> https://public.kitware.com/mailman/listinfo/rtk-users
>
> *Disclaimer:* This email (including any attachments or links) may contain
> confidential and/or legally privileged information and is intended only to
> be read or used by the addressee.  If you are not the intended addressee,
> any use, distribution, disclosure or copying of this email is strictly
> prohibited.  Confidentiality and legal privilege attached to this email
> (including any attachments) are not waived or lost by reason of its
> mistaken delivery to you.  If you have received this email in error, please
> delete it and notify us immediately by telephone or email.  Peter MacCallum
> Cancer Centre provides no guarantee that this transmission is free of virus
> or that it has not been intercepted or altered and will not be liable for
> any delay in its receipt.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20180808/88ec586e/attachment-0001.html>

From no-reply at dropbox.com  Sun Aug 19 17:13:42 2018
From: no-reply at dropbox.com (Milan Manasijevic (via Dropbox))
Date: Sun, 19 Aug 2018 21:13:42 +0000
Subject: [Rtk-users] =?utf-8?q?Milan_Manasijevic_hat_=E2=80=9Etest=5Freco?=
 =?utf-8?q?nstruction=E2=80=9C_f=C3=BCr_Sie_freigegeben?=
Message-ID: <01010165540955a4-6a1ea255-82d5-4e90-b8a6-09411dc603a1-000000@us-west-2.amazonses.com>

Hallo,

Milan Manasijevic (milan-manasijevic at t-online.de) hat Sie dazu eingeladen, sich den Ordner ? test_reconstruction ? in Dropbox anzusehen.

Zum Ordner[1]

Viel Vergn?gen!
Das Dropbox-Team 
 Milan Manasijevic und weitere Nutzer k?nnen sehen, wenn Sie Dateien in diesem Ordner aufrufen. Auch bei anderen f?r Sie ?ber Dropbox freigegebenen Dateien kann es sein, dass diese Informationen angezeigt werden.Weitere Informationen[2] dazu finden Sie in unserem Hilfecenter. 

[1]: https://www.dropbox.com/l/scl/AACzzTGwknB9wzmnS9xGZUMeQHP20JM3g5o
[2]: https://www.dropbox.com/l/AABdNEPtjgp8kUZPWz9GMjAKBiWWDyP4UL0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20180819/c08d517b/attachment.html>

From milan-manasijevic at t-online.de  Sun Aug 19 17:35:22 2018
From: milan-manasijevic at t-online.de (Milan Manasijevic)
Date: Sun, 19 Aug 2018 23:35:22 +0200
Subject: [Rtk-users] Cannot reconstruct the volume,
 what might be the problem?
Message-ID: <a544c7df-0dc2-be73-f072-1df97c78274b@t-online.de>

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



From andreasga22 at gmail.com  Mon Aug 20 08:26:52 2018
From: andreasga22 at gmail.com (Andreas Andersen)
Date: Mon, 20 Aug 2018 14:26:52 +0200
Subject: [Rtk-users] Cannot reconstruct the volume,
 what might be the problem?
In-Reply-To: <a544c7df-0dc2-be73-f072-1df97c78274b@t-online.de>
References: <a544c7df-0dc2-be73-f072-1df97c78274b@t-online.de>
Message-ID: <CAE0aawGFd+W52wSaRp4Gp8vs1LyYkQ06tScCm8S95pfiJ4-CEw@mail.gmail.com>

Hi Milan

I didn't open the dropbox link, but I think in general one should take an
extra look at the rtkfdk arguments if nothing "meaningful" comes out:
 Is your spacing in the correct unit (mm)? it seems quite small in relation
to the dimensions.
 Also try adding the --origin argument.

Additional 1:
Slicer is a good tool for exactly that.
( I have also made a similar tool with some reconstruction options, mainly
for scatter correction: cbctrecon
<https://gitlab.com/agravgaard/cbctrecon/wikis/Installation> )
Additional 2:
try giving " -o fdk.raw" instead of  "-o fdk.mha", the default output value
type is 32-bit floating point.

Best regards
 Andreas

__________________________________

Andreas Gravgaard Andersen

Department of Oncology,

Aarhus University Hospital

N?rrebrogade 44,

8000, Aarhus C

Mail:     agravgaard at protonmail.com

Cell:      +45 3165 8140


On Sun, 19 Aug 2018 at 23:44, Milan Manasijevic <
milan-manasijevic at 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.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
> Rtk-users at public.kitware.com
> https://public.kitware.com/mailman/listinfo/rtk-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20180820/1a559431/attachment.html>

From milan-manasijevic at t-online.de  Mon Aug 20 16:10:12 2018
From: milan-manasijevic at t-online.de (Milan Manasijevic)
Date: Mon, 20 Aug 2018 22:10:12 +0200
Subject: [Rtk-users] Cannot reconstruct the volume,
 what might be the problem?
In-Reply-To: <CAE0aawGFd+W52wSaRp4Gp8vs1LyYkQ06tScCm8S95pfiJ4-CEw@mail.gmail.com>
References: <a544c7df-0dc2-be73-f072-1df97c78274b@t-online.de>
 <CAE0aawGFd+W52wSaRp4Gp8vs1LyYkQ06tScCm8S95pfiJ4-CEw@mail.gmail.com>
Message-ID: <23396d7d-9745-bc33-158d-e5346e6fd1c0@t-online.de>

Hi Andreas,
I am really grateful that you've found time to response so quickly.

1) Following your suggestions I first checked the spacing. I suppose, 
you refer to the value of 0.03840368. I am confident, this is the 
correct value in the correct unit (mm).
The 4D Slicer shows the dimensions in mm and this is near to the object 
measures.

2) The second try was to check if the "?-o fdk.raw" works.
Unfortunately not, I get such exception:
itk::ImageFileWriterException (000000C71D4FE5D0)
Location: "void __cdecl itk::ImageFileWriter<class itk::Image<float,3> 
 >::Write(void)"
File: 
d:\reconstruction_rtk\itk\modules\io\imagebase\include\itkImageFileWriter.hxx
Line: 151
Description:? Could not create IO object for writing file fdk.raw
 ? Tried to create one of the following:
 ??? NiftiImageIO
 ??? NrrdImageIO
 ??? GiplImageIO
 ??? HDF5ImageIO
 ??? JPEGImageIO
 ??? BMPImageIO
 ??? LSMImageIO
 ??? PNGImageIO
 ??? TIFFImageIO
 ??? VTKImageIO
 ??? StimulateImageIO
 ??? BioRadImageIO
 ??? MetaImageIO
 ??? MRCImageIO
 ??? GE4ImageIO
 ??? GE5ImageIO
 ??? HndImageIO
 ??? XimImageIO
 ??? HisImageIO
 ??? ImagXImageIO
 ??? DCMImagXImageIO
 ??? EdfImageIO
 ??? XRadImageIO
 ??? OraImageIO
 ??? GDCMImageIO
 ? You probably failed to set a file suffix, or
 ??? set the suffix to an unsupported type.


3) Regarding the "--origin argument" and refering to my context (see 
attached files please), what would you suggest, what should I pass as 
the origin values? The detecetor origin is at 0,0 but for the Volume I 
am not quit sure if I should provide some values and which (actually 
isocenter should be at 0,0,0 and if I provide these values I still get 
no result ). Probably this would solve my problem.

Again, many thanks for your time and thank you for your help.

Best regards,
Milan




Am 20.08.2018 um 14:26 schrieb Andreas Andersen:
> Hi Milan
>
> I didn't open the dropbox link, but I think in general one should take 
> an extra look at the rtkfdk arguments if nothing "meaningful" comes out:
> ?Is your spacing in the correct unit (mm)? it seems quite small in 
> relation to the dimensions.
> ?Also try adding the --origin argument.
>
> Additional 1:
> Slicer is a good tool for exactly that.
> ( I have also made a similar tool with some reconstruction options, 
> mainly for scatter correction: cbctrecon 
> <https://gitlab.com/agravgaard/cbctrecon/wikis/Installation>?)
> Additional 2:
> try giving "?-o fdk.raw" instead of? "-o fdk.mha", the default output 
> value type is 32-bit floating point.
>
> Best regards
> ?Andreas
>
> __________________________________
>
> Andreas Gravgaard Andersen
>
> Department of Oncology,
>
> Aarhus University Hospital
>
> N?rrebrogade 44,
>
> 8000, Aarhus C
>
> Mail: agravgaard at protonmail.com <mailto:agravgaard at protonmail.com>
>
> Cell: +45 3165 8140
>
>
>
> On Sun, 19 Aug 2018 at 23:44, Milan Manasijevic 
> <milan-manasijevic at t-online.de <mailto:milan-manasijevic at 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.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
>     Rtk-users at public.kitware.com <mailto:Rtk-users at public.kitware.com>
>     https://public.kitware.com/mailman/listinfo/rtk-users
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20180820/20563eea/attachment.html>

From andreasga22 at gmail.com  Mon Aug 20 18:01:39 2018
From: andreasga22 at gmail.com (Andreas Andersen)
Date: Tue, 21 Aug 2018 00:01:39 +0200
Subject: [Rtk-users] Cannot reconstruct the volume,
 what might be the problem?
In-Reply-To: <23396d7d-9745-bc33-158d-e5346e6fd1c0@t-online.de>
References: <a544c7df-0dc2-be73-f072-1df97c78274b@t-online.de>
 <CAE0aawGFd+W52wSaRp4Gp8vs1LyYkQ06tScCm8S95pfiJ4-CEw@mail.gmail.com>
 <23396d7d-9745-bc33-158d-e5346e6fd1c0@t-online.de>
Message-ID: <CAE0aawG3TtyakERoVxH0YNj4Ztk=cN32FXM8THXZpZryOJ+YEw@mail.gmail.com>

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:     agravgaard at protonmail.com

Cell:      +45 3165 8140


On Mon, 20 Aug 2018 at 22:10, Milan Manasijevic <
milan-manasijevic at 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 (000000C71D4FE5D0)
> Location: "void __cdecl itk::ImageFileWriter<class itk::Image<float,3>
> >::Write(void)"
> File:
> d:\reconstruction_rtk\itk\modules\io\imagebase\include\itkImageFileWriter.hxx
> Line: 151
> Description:  Could not create IO object for writing file fdk.raw
>   Tried to create one of the following:
>     NiftiImageIO
>     NrrdImageIO
>     GiplImageIO
>     HDF5ImageIO
>     JPEGImageIO
>     BMPImageIO
>     LSMImageIO
>     PNGImageIO
>     TIFFImageIO
>     VTKImageIO
>     StimulateImageIO
>     BioRadImageIO
>     MetaImageIO
>     MRCImageIO
>     GE4ImageIO
>     GE5ImageIO
>     HndImageIO
>     XimImageIO
>     HisImageIO
>     ImagXImageIO
>     DCMImagXImageIO
>     EdfImageIO
>     XRadImageIO
>     OraImageIO
>     GDCMImageIO
>   You probably failed to set a file suffix, or
>     set the suffix to an unsupported type.
>
>
> 3) Regarding the "--origin argument" and refering to my context (see
> attached files please), what would you suggest, what should I pass as the
> origin values? The detecetor origin is at 0,0 but for the Volume I am not
> quit sure if I should provide some values and which (actually isocenter
> should be at 0,0,0 and if I provide these values I still get no result ).
> Probably this would solve my problem.
>
> Again, many thanks for your time and thank you for your help.
>
> Best regards,
> Milan
>
>
>
>
> Am 20.08.2018 um 14:26 schrieb Andreas Andersen:
>
> Hi Milan
>
> I didn't open the dropbox link, but I think in general one should take an
> extra look at the rtkfdk arguments if nothing "meaningful" comes out:
>  Is your spacing in the correct unit (mm)? it seems quite small in
> relation to the dimensions.
>  Also try adding the --origin argument.
>
> Additional 1:
> Slicer is a good tool for exactly that.
> ( I have also made a similar tool with some reconstruction options, mainly
> for scatter correction: cbctrecon
> <https://gitlab.com/agravgaard/cbctrecon/wikis/Installation> )
> Additional 2:
> try giving " -o fdk.raw" instead of  "-o fdk.mha", the default output
> value type is 32-bit floating point.
>
> Best regards
>  Andreas
>
> __________________________________
>
> Andreas Gravgaard Andersen
>
> Department of Oncology,
>
> Aarhus University Hospital
>
> N?rrebrogade 44,
>
> 8000, Aarhus C
>
> Mail:     agravgaard at protonmail.com
>
> Cell:      +45 3165 8140
>
>
> On Sun, 19 Aug 2018 at 23:44, Milan Manasijevic <
> milan-manasijevic at 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.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
>> Rtk-users at public.kitware.com
>> https://public.kitware.com/mailman/listinfo/rtk-users
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20180821/f4c9dd84/attachment-0001.html>

From simon.rit at creatis.insa-lyon.fr  Tue Aug 21 07:25:53 2018
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Tue, 21 Aug 2018 13:25:53 +0200
Subject: [Rtk-users] Cannot reconstruct the volume,
 what might be the problem?
In-Reply-To: <CAE0aawG3TtyakERoVxH0YNj4Ztk=cN32FXM8THXZpZryOJ+YEw@mail.gmail.com>
References: <a544c7df-0dc2-be73-f072-1df97c78274b@t-online.de>
 <CAE0aawGFd+W52wSaRp4Gp8vs1LyYkQ06tScCm8S95pfiJ4-CEw@mail.gmail.com>
 <23396d7d-9745-bc33-158d-e5346e6fd1c0@t-online.de>
 <CAE0aawG3TtyakERoVxH0YNj4Ztk=cN32FXM8THXZpZryOJ+YEw@mail.gmail.com>
Message-ID: <CAF0oig2KnfcxtY+7sYQnj6yEXgtH763nuWmMSrehrOXO+Msm_A@mail.gmail.com>

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 <andreasga22 at 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:     agravgaard at protonmail.com
>
> Cell:      +45 3165 8140
>
>
> On Mon, 20 Aug 2018 at 22:10, Milan Manasijevic <
> milan-manasijevic at 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 (000000C71D4FE5D0)
>> Location: "void __cdecl itk::ImageFileWriter<class itk::Image<float,3>
>> >::Write(void)"
>> File:
>> d:\reconstruction_rtk\itk\modules\io\imagebase\include\itkImageFileWriter.hxx
>> Line: 151
>> Description:  Could not create IO object for writing file fdk.raw
>>   Tried to create one of the following:
>>     NiftiImageIO
>>     NrrdImageIO
>>     GiplImageIO
>>     HDF5ImageIO
>>     JPEGImageIO
>>     BMPImageIO
>>     LSMImageIO
>>     PNGImageIO
>>     TIFFImageIO
>>     VTKImageIO
>>     StimulateImageIO
>>     BioRadImageIO
>>     MetaImageIO
>>     MRCImageIO
>>     GE4ImageIO
>>     GE5ImageIO
>>     HndImageIO
>>     XimImageIO
>>     HisImageIO
>>     ImagXImageIO
>>     DCMImagXImageIO
>>     EdfImageIO
>>     XRadImageIO
>>     OraImageIO
>>     GDCMImageIO
>>   You probably failed to set a file suffix, or
>>     set the suffix to an unsupported type.
>>
>>
>> 3) Regarding the "--origin argument" and refering to my context (see
>> attached files please), what would you suggest, what should I pass as the
>> origin values? The detecetor origin is at 0,0 but for the Volume I am not
>> quit sure if I should provide some values and which (actually isocenter
>> should be at 0,0,0 and if I provide these values I still get no result ).
>> Probably this would solve my problem.
>>
>> Again, many thanks for your time and thank you for your help.
>>
>> Best regards,
>> Milan
>>
>>
>>
>>
>> Am 20.08.2018 um 14:26 schrieb Andreas Andersen:
>>
>> Hi Milan
>>
>> I didn't open the dropbox link, but I think in general one should take an
>> extra look at the rtkfdk arguments if nothing "meaningful" comes out:
>>  Is your spacing in the correct unit (mm)? it seems quite small in
>> relation to the dimensions.
>>  Also try adding the --origin argument.
>>
>> Additional 1:
>> Slicer is a good tool for exactly that.
>> ( I have also made a similar tool with some reconstruction options,
>> mainly for scatter correction: cbctrecon
>> <https://gitlab.com/agravgaard/cbctrecon/wikis/Installation> )
>> Additional 2:
>> try giving " -o fdk.raw" instead of  "-o fdk.mha", the default output
>> value type is 32-bit floating point.
>>
>> Best regards
>>  Andreas
>>
>> __________________________________
>>
>> Andreas Gravgaard Andersen
>>
>> Department of Oncology,
>>
>> Aarhus University Hospital
>>
>> N?rrebrogade 44,
>>
>> 8000, Aarhus C
>>
>> Mail:     agravgaard at protonmail.com
>>
>> Cell:      +45 3165 8140
>>
>>
>> On Sun, 19 Aug 2018 at 23:44, Milan Manasijevic <
>> milan-manasijevic at 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.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
>>> Rtk-users at public.kitware.com
>>> https://public.kitware.com/mailman/listinfo/rtk-users
>>>
>>
>> _______________________________________________
> Rtk-users mailing list
> Rtk-users at public.kitware.com
> https://public.kitware.com/mailman/listinfo/rtk-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20180821/d32c8725/attachment.html>

From wuchao04 at gmail.com  Tue Aug 21 09:28:21 2018
From: wuchao04 at gmail.com (Chao Wu)
Date: Tue, 21 Aug 2018 15:28:21 +0200
Subject: [Rtk-users] Cannot reconstruct the volume,
 what might be the problem?
In-Reply-To: <CAF0oig2KnfcxtY+7sYQnj6yEXgtH763nuWmMSrehrOXO+Msm_A@mail.gmail.com>
References: <a544c7df-0dc2-be73-f072-1df97c78274b@t-online.de>
 <CAE0aawGFd+W52wSaRp4Gp8vs1LyYkQ06tScCm8S95pfiJ4-CEw@mail.gmail.com>
 <23396d7d-9745-bc33-158d-e5346e6fd1c0@t-online.de>
 <CAE0aawG3TtyakERoVxH0YNj4Ztk=cN32FXM8THXZpZryOJ+YEw@mail.gmail.com>
 <CAF0oig2KnfcxtY+7sYQnj6yEXgtH763nuWmMSrehrOXO+Msm_A@mail.gmail.com>
Message-ID: <CAH+sHrVVvvoL=DHCMigC-aJbGarC_=mubmtexxq=E0gFXTmLJg@mail.gmail.com>

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 <simon.rit at creatis.insa-lyon.fr> ?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 <andreasga22 at 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:     agravgaard at protonmail.com
>>
>> Cell:      +45 3165 8140
>>
>>
>> On Mon, 20 Aug 2018 at 22:10, Milan Manasijevic <
>> milan-manasijevic at 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 (000000C71D4FE5D0)
>>> Location: "void __cdecl itk::ImageFileWriter<class itk::Image<float,3>
>>> >::Write(void)"
>>> File:
>>> d:\reconstruction_rtk\itk\modules\io\imagebase\include\itkImageFileWriter.hxx
>>> Line: 151
>>> Description:  Could not create IO object for writing file fdk.raw
>>>   Tried to create one of the following:
>>>     NiftiImageIO
>>>     NrrdImageIO
>>>     GiplImageIO
>>>     HDF5ImageIO
>>>     JPEGImageIO
>>>     BMPImageIO
>>>     LSMImageIO
>>>     PNGImageIO
>>>     TIFFImageIO
>>>     VTKImageIO
>>>     StimulateImageIO
>>>     BioRadImageIO
>>>     MetaImageIO
>>>     MRCImageIO
>>>     GE4ImageIO
>>>     GE5ImageIO
>>>     HndImageIO
>>>     XimImageIO
>>>     HisImageIO
>>>     ImagXImageIO
>>>     DCMImagXImageIO
>>>     EdfImageIO
>>>     XRadImageIO
>>>     OraImageIO
>>>     GDCMImageIO
>>>   You probably failed to set a file suffix, or
>>>     set the suffix to an unsupported type.
>>>
>>>
>>> 3) Regarding the "--origin argument" and refering to my context (see
>>> attached files please), what would you suggest, what should I pass as the
>>> origin values? The detecetor origin is at 0,0 but for the Volume I am not
>>> quit sure if I should provide some values and which (actually isocenter
>>> should be at 0,0,0 and if I provide these values I still get no result ).
>>> Probably this would solve my problem.
>>>
>>> Again, many thanks for your time and thank you for your help.
>>>
>>> Best regards,
>>> Milan
>>>
>>>
>>>
>>>
>>> Am 20.08.2018 um 14:26 schrieb Andreas Andersen:
>>>
>>> Hi Milan
>>>
>>> I didn't open the dropbox link, but I think in general one should take
>>> an extra look at the rtkfdk arguments if nothing "meaningful" comes out:
>>>  Is your spacing in the correct unit (mm)? it seems quite small in
>>> relation to the dimensions.
>>>  Also try adding the --origin argument.
>>>
>>> Additional 1:
>>> Slicer is a good tool for exactly that.
>>> ( I have also made a similar tool with some reconstruction options,
>>> mainly for scatter correction: cbctrecon
>>> <https://gitlab.com/agravgaard/cbctrecon/wikis/Installation> )
>>> Additional 2:
>>> try giving " -o fdk.raw" instead of  "-o fdk.mha", the default output
>>> value type is 32-bit floating point.
>>>
>>> Best regards
>>>  Andreas
>>>
>>> __________________________________
>>>
>>> Andreas Gravgaard Andersen
>>>
>>> Department of Oncology,
>>>
>>> Aarhus University Hospital
>>>
>>> N?rrebrogade 44,
>>>
>>> 8000, Aarhus C
>>>
>>> Mail:     agravgaard at protonmail.com
>>>
>>> Cell:      +45 3165 8140
>>>
>>>
>>> On Sun, 19 Aug 2018 at 23:44, Milan Manasijevic <
>>> milan-manasijevic at 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.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
>>>> Rtk-users at public.kitware.com
>>>> https://public.kitware.com/mailman/listinfo/rtk-users
>>>>
>>>
>>> _______________________________________________
>> Rtk-users mailing list
>> Rtk-users at public.kitware.com
>> https://public.kitware.com/mailman/listinfo/rtk-users
>>
> _______________________________________________
> Rtk-users mailing list
> Rtk-users at public.kitware.com
> https://public.kitware.com/mailman/listinfo/rtk-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20180821/a7db56ad/attachment-0001.html>

From simon.rit at creatis.insa-lyon.fr  Tue Aug 21 09:44:37 2018
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Tue, 21 Aug 2018 15:44:37 +0200
Subject: [Rtk-users] Cannot reconstruct the volume,
 what might be the problem?
In-Reply-To: <CAH+sHrVVvvoL=DHCMigC-aJbGarC_=mubmtexxq=E0gFXTmLJg@mail.gmail.com>
References: <a544c7df-0dc2-be73-f072-1df97c78274b@t-online.de>
 <CAE0aawGFd+W52wSaRp4Gp8vs1LyYkQ06tScCm8S95pfiJ4-CEw@mail.gmail.com>
 <23396d7d-9745-bc33-158d-e5346e6fd1c0@t-online.de>
 <CAE0aawG3TtyakERoVxH0YNj4Ztk=cN32FXM8THXZpZryOJ+YEw@mail.gmail.com>
 <CAF0oig2KnfcxtY+7sYQnj6yEXgtH763nuWmMSrehrOXO+Msm_A@mail.gmail.com>
 <CAH+sHrVVvvoL=DHCMigC-aJbGarC_=mubmtexxq=E0gFXTmLJg@mail.gmail.com>
Message-ID: <CAF0oig3pwg4t_kLRKKBkCJw0PKsV9B45tiDy5xiaUeAzPO42cQ@mail.gmail.com>

Sorry, I checked the doc <http://www.openrtk.org/Doxygen/DocGeo3D.html> and
you're right,
"(ProjectionOffsetX,ProjectionOffsetY,SourceToIsocenterDistance-SourceToDetectorDistance)
are the coordinates of the detector origin in the rotated coordinated
system". So yes, add minus signs in front of proj_iso_x and proj_iso_y in
my email.
One source of confusion here (to me too) is that I refer here to "origin"
as point "(0,0)" and not to m_Origin in the itk::Image object... Any
suggestion to improve this is welcome.
On the other hand, you seem to suggest that source offsets and projection
offsets are redundant which is not true in a divergent geometry (or I did
not get you).
Thanks a lot for your correction.
Simon


On Tue, Aug 21, 2018 at 3:28 PM Chao Wu <wuchao04 at gmail.com> 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 <simon.rit at creatis.insa-lyon.fr> ?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 <andreasga22 at 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:     agravgaard at protonmail.com
>>>
>>> Cell:      +45 3165 8140
>>>
>>>
>>> On Mon, 20 Aug 2018 at 22:10, Milan Manasijevic <
>>> milan-manasijevic at 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 (000000C71D4FE5D0)
>>>> Location: "void __cdecl itk::ImageFileWriter<class itk::Image<float,3>
>>>> >::Write(void)"
>>>> File:
>>>> d:\reconstruction_rtk\itk\modules\io\imagebase\include\itkImageFileWriter.hxx
>>>> Line: 151
>>>> Description:  Could not create IO object for writing file fdk.raw
>>>>   Tried to create one of the following:
>>>>     NiftiImageIO
>>>>     NrrdImageIO
>>>>     GiplImageIO
>>>>     HDF5ImageIO
>>>>     JPEGImageIO
>>>>     BMPImageIO
>>>>     LSMImageIO
>>>>     PNGImageIO
>>>>     TIFFImageIO
>>>>     VTKImageIO
>>>>     StimulateImageIO
>>>>     BioRadImageIO
>>>>     MetaImageIO
>>>>     MRCImageIO
>>>>     GE4ImageIO
>>>>     GE5ImageIO
>>>>     HndImageIO
>>>>     XimImageIO
>>>>     HisImageIO
>>>>     ImagXImageIO
>>>>     DCMImagXImageIO
>>>>     EdfImageIO
>>>>     XRadImageIO
>>>>     OraImageIO
>>>>     GDCMImageIO
>>>>   You probably failed to set a file suffix, or
>>>>     set the suffix to an unsupported type.
>>>>
>>>>
>>>> 3) Regarding the "--origin argument" and refering to my context (see
>>>> attached files please), what would you suggest, what should I pass as the
>>>> origin values? The detecetor origin is at 0,0 but for the Volume I am not
>>>> quit sure if I should provide some values and which (actually isocenter
>>>> should be at 0,0,0 and if I provide these values I still get no result ).
>>>> Probably this would solve my problem.
>>>>
>>>> Again, many thanks for your time and thank you for your help.
>>>>
>>>> Best regards,
>>>> Milan
>>>>
>>>>
>>>>
>>>>
>>>> Am 20.08.2018 um 14:26 schrieb Andreas Andersen:
>>>>
>>>> Hi Milan
>>>>
>>>> I didn't open the dropbox link, but I think in general one should take
>>>> an extra look at the rtkfdk arguments if nothing "meaningful" comes out:
>>>>  Is your spacing in the correct unit (mm)? it seems quite small in
>>>> relation to the dimensions.
>>>>  Also try adding the --origin argument.
>>>>
>>>> Additional 1:
>>>> Slicer is a good tool for exactly that.
>>>> ( I have also made a similar tool with some reconstruction options,
>>>> mainly for scatter correction: cbctrecon
>>>> <https://gitlab.com/agravgaard/cbctrecon/wikis/Installation> )
>>>> Additional 2:
>>>> try giving " -o fdk.raw" instead of  "-o fdk.mha", the default output
>>>> value type is 32-bit floating point.
>>>>
>>>> Best regards
>>>>  Andreas
>>>>
>>>> __________________________________
>>>>
>>>> Andreas Gravgaard Andersen
>>>>
>>>> Department of Oncology,
>>>>
>>>> Aarhus University Hospital
>>>>
>>>> N?rrebrogade 44,
>>>>
>>>> 8000, Aarhus C
>>>>
>>>> Mail:     agravgaard at protonmail.com
>>>>
>>>> Cell:      +45 3165 8140
>>>>
>>>>
>>>> On Sun, 19 Aug 2018 at 23:44, Milan Manasijevic <
>>>> milan-manasijevic at 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.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
>>>>> Rtk-users at public.kitware.com
>>>>> https://public.kitware.com/mailman/listinfo/rtk-users
>>>>>
>>>>
>>>> _______________________________________________
>>> Rtk-users mailing list
>>> Rtk-users at public.kitware.com
>>> https://public.kitware.com/mailman/listinfo/rtk-users
>>>
>> _______________________________________________
>> Rtk-users mailing list
>> Rtk-users at public.kitware.com
>> https://public.kitware.com/mailman/listinfo/rtk-users
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20180821/4af17a86/attachment-0001.html>

From wuchao04 at gmail.com  Tue Aug 21 10:38:52 2018
From: wuchao04 at gmail.com (Chao Wu)
Date: Tue, 21 Aug 2018 16:38:52 +0200
Subject: [Rtk-users] Cannot reconstruct the volume,
 what might be the problem?
In-Reply-To: <CAF0oig3pwg4t_kLRKKBkCJw0PKsV9B45tiDy5xiaUeAzPO42cQ@mail.gmail.com>
References: <a544c7df-0dc2-be73-f072-1df97c78274b@t-online.de>
 <CAE0aawGFd+W52wSaRp4Gp8vs1LyYkQ06tScCm8S95pfiJ4-CEw@mail.gmail.com>
 <23396d7d-9745-bc33-158d-e5346e6fd1c0@t-online.de>
 <CAE0aawG3TtyakERoVxH0YNj4Ztk=cN32FXM8THXZpZryOJ+YEw@mail.gmail.com>
 <CAF0oig2KnfcxtY+7sYQnj6yEXgtH763nuWmMSrehrOXO+Msm_A@mail.gmail.com>
 <CAH+sHrVVvvoL=DHCMigC-aJbGarC_=mubmtexxq=E0gFXTmLJg@mail.gmail.com>
 <CAF0oig3pwg4t_kLRKKBkCJw0PKsV9B45tiDy5xiaUeAzPO42cQ@mail.gmail.com>
Message-ID: <CAH+sHrX272_PqXnN_1O8x9dcGr82yrUsFG95apCUHdPthMrzdg@mail.gmail.com>

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 <simon.rit at creatis.insa-lyon.fr> ?2018?8?21??? ??3:44???

> Sorry, I checked the doc <http://www.openrtk.org/Doxygen/DocGeo3D.html>
> and you're right,
> "(ProjectionOffsetX,ProjectionOffsetY,SourceToIsocenterDistance-SourceToDetectorDistance)
> are the coordinates of the detector origin in the rotated coordinated
> system". So yes, add minus signs in front of proj_iso_x and proj_iso_y in
> my email.
> One source of confusion here (to me too) is that I refer here to "origin"
> as point "(0,0)" and not to m_Origin in the itk::Image object... Any
> suggestion to improve this is welcome.
> On the other hand, you seem to suggest that source offsets and projection
> offsets are redundant which is not true in a divergent geometry (or I did
> not get you).
> Thanks a lot for your correction.
> Simon
>
>
> On Tue, Aug 21, 2018 at 3:28 PM Chao Wu <wuchao04 at gmail.com> 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 <simon.rit at creatis.insa-lyon.fr> ?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 <andreasga22 at 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:     agravgaard at protonmail.com
>>>>
>>>> Cell:      +45 3165 8140
>>>>
>>>>
>>>> On Mon, 20 Aug 2018 at 22:10, Milan Manasijevic <
>>>> milan-manasijevic at 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 (000000C71D4FE5D0)
>>>>> Location: "void __cdecl itk::ImageFileWriter<class itk::Image<float,3>
>>>>> >::Write(void)"
>>>>> File:
>>>>> d:\reconstruction_rtk\itk\modules\io\imagebase\include\itkImageFileWriter.hxx
>>>>> Line: 151
>>>>> Description:  Could not create IO object for writing file fdk.raw
>>>>>   Tried to create one of the following:
>>>>>     NiftiImageIO
>>>>>     NrrdImageIO
>>>>>     GiplImageIO
>>>>>     HDF5ImageIO
>>>>>     JPEGImageIO
>>>>>     BMPImageIO
>>>>>     LSMImageIO
>>>>>     PNGImageIO
>>>>>     TIFFImageIO
>>>>>     VTKImageIO
>>>>>     StimulateImageIO
>>>>>     BioRadImageIO
>>>>>     MetaImageIO
>>>>>     MRCImageIO
>>>>>     GE4ImageIO
>>>>>     GE5ImageIO
>>>>>     HndImageIO
>>>>>     XimImageIO
>>>>>     HisImageIO
>>>>>     ImagXImageIO
>>>>>     DCMImagXImageIO
>>>>>     EdfImageIO
>>>>>     XRadImageIO
>>>>>     OraImageIO
>>>>>     GDCMImageIO
>>>>>   You probably failed to set a file suffix, or
>>>>>     set the suffix to an unsupported type.
>>>>>
>>>>>
>>>>> 3) Regarding the "--origin argument" and refering to my context (see
>>>>> attached files please), what would you suggest, what should I pass as the
>>>>> origin values? The detecetor origin is at 0,0 but for the Volume I am not
>>>>> quit sure if I should provide some values and which (actually isocenter
>>>>> should be at 0,0,0 and if I provide these values I still get no result ).
>>>>> Probably this would solve my problem.
>>>>>
>>>>> Again, many thanks for your time and thank you for your help.
>>>>>
>>>>> Best regards,
>>>>> Milan
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Am 20.08.2018 um 14:26 schrieb Andreas Andersen:
>>>>>
>>>>> Hi Milan
>>>>>
>>>>> I didn't open the dropbox link, but I think in general one should take
>>>>> an extra look at the rtkfdk arguments if nothing "meaningful" comes out:
>>>>>  Is your spacing in the correct unit (mm)? it seems quite small in
>>>>> relation to the dimensions.
>>>>>  Also try adding the --origin argument.
>>>>>
>>>>> Additional 1:
>>>>> Slicer is a good tool for exactly that.
>>>>> ( I have also made a similar tool with some reconstruction options,
>>>>> mainly for scatter correction: cbctrecon
>>>>> <https://gitlab.com/agravgaard/cbctrecon/wikis/Installation> )
>>>>> Additional 2:
>>>>> try giving " -o fdk.raw" instead of  "-o fdk.mha", the default output
>>>>> value type is 32-bit floating point.
>>>>>
>>>>> Best regards
>>>>>  Andreas
>>>>>
>>>>> __________________________________
>>>>>
>>>>> Andreas Gravgaard Andersen
>>>>>
>>>>> Department of Oncology,
>>>>>
>>>>> Aarhus University Hospital
>>>>>
>>>>> N?rrebrogade 44,
>>>>>
>>>>> 8000, Aarhus C
>>>>>
>>>>> Mail:     agravgaard at protonmail.com
>>>>>
>>>>> Cell:      +45 3165 8140
>>>>>
>>>>>
>>>>> On Sun, 19 Aug 2018 at 23:44, Milan Manasijevic <
>>>>> milan-manasijevic at 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.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
>>>>>> Rtk-users at public.kitware.com
>>>>>> https://public.kitware.com/mailman/listinfo/rtk-users
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>> Rtk-users mailing list
>>>> Rtk-users at public.kitware.com
>>>> https://public.kitware.com/mailman/listinfo/rtk-users
>>>>
>>> _______________________________________________
>>> Rtk-users mailing list
>>> Rtk-users at public.kitware.com
>>> https://public.kitware.com/mailman/listinfo/rtk-users
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20180821/8b32662b/attachment-0001.html>

From milan-manasijevic at t-online.de  Tue Aug 21 17:28:55 2018
From: milan-manasijevic at t-online.de (Milan Manasijevic)
Date: Tue, 21 Aug 2018 23:28:55 +0200
Subject: [Rtk-users] Cannot reconstruct the volume,
 what might be the problem?
In-Reply-To: <CAF0oig2KnfcxtY+7sYQnj6yEXgtH763nuWmMSrehrOXO+Msm_A@mail.gmail.com>
References: <a544c7df-0dc2-be73-f072-1df97c78274b@t-online.de>
 <CAE0aawGFd+W52wSaRp4Gp8vs1LyYkQ06tScCm8S95pfiJ4-CEw@mail.gmail.com>
 <23396d7d-9745-bc33-158d-e5346e6fd1c0@t-online.de>
 <CAE0aawG3TtyakERoVxH0YNj4Ztk=cN32FXM8THXZpZryOJ+YEw@mail.gmail.com>
 <CAF0oig2KnfcxtY+7sYQnj6yEXgtH763nuWmMSrehrOXO+Msm_A@mail.gmail.com>
Message-ID: <e0c07452-dbf6-62a7-8883-ec283122a5f0@t-online.de>

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 
> <andreasga22 at gmail.com <mailto:andreasga22 at 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: agravgaard at protonmail.com <mailto:agravgaard at protonmail.com>
>
>     Cell: +45 3165 8140
>
>
>
>     On Mon, 20 Aug 2018 at 22:10, Milan Manasijevic
>     <milan-manasijevic at t-online.de
>     <mailto:milan-manasijevic at 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 (000000C71D4FE5D0)
>         Location: "void __cdecl itk::ImageFileWriter<class
>         itk::Image<float,3> >::Write(void)"
>         File:
>         d:\reconstruction_rtk\itk\modules\io\imagebase\include\itkImageFileWriter.hxx
>         Line: 151
>         Description:? Could not create IO object for writing file fdk.raw
>         ? Tried to create one of the following:
>         ??? NiftiImageIO
>         ??? NrrdImageIO
>         ??? GiplImageIO
>         ??? HDF5ImageIO
>         ??? JPEGImageIO
>         ??? BMPImageIO
>         ??? LSMImageIO
>         ??? PNGImageIO
>         ??? TIFFImageIO
>         ??? VTKImageIO
>         ??? StimulateImageIO
>         ??? BioRadImageIO
>         ??? MetaImageIO
>         ??? MRCImageIO
>         ??? GE4ImageIO
>         ??? GE5ImageIO
>         ??? HndImageIO
>         ??? XimImageIO
>         ??? HisImageIO
>         ??? ImagXImageIO
>         ??? DCMImagXImageIO
>         ??? EdfImageIO
>         ??? XRadImageIO
>         ??? OraImageIO
>         ??? GDCMImageIO
>         ? You probably failed to set a file suffix, or
>         ??? set the suffix to an unsupported type.
>
>
>         3) Regarding the "--origin argument" and refering to my
>         context (see attached files please), what would you suggest,
>         what should I pass as the origin values? The detecetor origin
>         is at 0,0 but for the Volume I am not quit sure if I should
>         provide some values and which (actually isocenter should be at
>         0,0,0 and if I provide these values I still get no result ).
>         Probably this would solve my problem.
>
>         Again, many thanks for your time and thank you for your help.
>
>         Best regards,
>         Milan
>
>
>
>
>         Am 20.08.2018 um 14:26 schrieb Andreas Andersen:
>>         Hi Milan
>>
>>         I didn't open the dropbox link, but I think in general one
>>         should take an extra look at the rtkfdk arguments if nothing
>>         "meaningful" comes out:
>>         ?Is your spacing in the correct unit (mm)? it seems quite
>>         small in relation to the dimensions.
>>         ?Also try adding the --origin argument.
>>
>>         Additional 1:
>>         Slicer is a good tool for exactly that.
>>         ( I have also made a similar tool with some reconstruction
>>         options, mainly for scatter correction: cbctrecon
>>         <https://gitlab.com/agravgaard/cbctrecon/wikis/Installation>?)
>>         Additional 2:
>>         try giving "?-o fdk.raw" instead of? "-o fdk.mha", the
>>         default output value type is 32-bit floating point.
>>
>>         Best regards
>>         ?Andreas
>>
>>         __________________________________
>>
>>         Andreas Gravgaard Andersen
>>
>>         Department of Oncology,
>>
>>         Aarhus University Hospital
>>
>>         N?rrebrogade 44,
>>
>>         8000, Aarhus C
>>
>>         Mail: agravgaard at protonmail.com
>>         <mailto:agravgaard at protonmail.com>
>>
>>         Cell: +45 3165 8140
>>
>>
>>
>>         On Sun, 19 Aug 2018 at 23:44, Milan Manasijevic
>>         <milan-manasijevic at t-online.de
>>         <mailto:milan-manasijevic at 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.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
>>             Rtk-users at public.kitware.com
>>             <mailto:Rtk-users at public.kitware.com>
>>             https://public.kitware.com/mailman/listinfo/rtk-users
>>
>
>     _______________________________________________
>     Rtk-users mailing list
>     Rtk-users at public.kitware.com <mailto:Rtk-users at public.kitware.com>
>     https://public.kitware.com/mailman/listinfo/rtk-users
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20180821/294489dc/attachment-0001.html>

From simon.rit at creatis.insa-lyon.fr  Wed Aug 22 07:36:47 2018
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Wed, 22 Aug 2018 13:36:47 +0200
Subject: [Rtk-users] Cannot reconstruct the volume,
 what might be the problem?
In-Reply-To: <e0c07452-dbf6-62a7-8883-ec283122a5f0@t-online.de>
References: <a544c7df-0dc2-be73-f072-1df97c78274b@t-online.de>
 <CAE0aawGFd+W52wSaRp4Gp8vs1LyYkQ06tScCm8S95pfiJ4-CEw@mail.gmail.com>
 <23396d7d-9745-bc33-158d-e5346e6fd1c0@t-online.de>
 <CAE0aawG3TtyakERoVxH0YNj4Ztk=cN32FXM8THXZpZryOJ+YEw@mail.gmail.com>
 <CAF0oig2KnfcxtY+7sYQnj6yEXgtH763nuWmMSrehrOXO+Msm_A@mail.gmail.com>
 <e0c07452-dbf6-62a7-8883-ec283122a5f0@t-online.de>
Message-ID: <CAF0oig2AiG-Pkw8=pH9z1GC4JhjzJeVC8SNi76QQOECuxPkoVQ@mail.gmail.com>

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
<milan-manasijevic at t-online.de> 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 <andreasga22 at 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:     agravgaard at protonmail.com
>>
>> Cell:      +45 3165 8140
>>
>>
>>
>> On Mon, 20 Aug 2018 at 22:10, Milan Manasijevic <milan-manasijevic at 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 (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:     agravgaard at protonmail.com
>>>
>>> Cell:      +45 3165 8140
>>>
>>>
>>>
>>> On Sun, 19 Aug 2018 at 23:44, Milan Manasijevic <milan-manasijevic at 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.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
>>>> Rtk-users at public.kitware.com
>>>> https://public.kitware.com/mailman/listinfo/rtk-users
>>>
>>>
>> _______________________________________________
>> Rtk-users mailing list
>> Rtk-users at public.kitware.com
>> https://public.kitware.com/mailman/listinfo/rtk-users
>
>

From simon.rit at creatis.insa-lyon.fr  Wed Aug 22 07:42:02 2018
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Wed, 22 Aug 2018 13:42:02 +0200
Subject: [Rtk-users] Cannot reconstruct the volume,
 what might be the problem?
In-Reply-To: <CAH+sHrX272_PqXnN_1O8x9dcGr82yrUsFG95apCUHdPthMrzdg@mail.gmail.com>
References: <a544c7df-0dc2-be73-f072-1df97c78274b@t-online.de>
 <CAE0aawGFd+W52wSaRp4Gp8vs1LyYkQ06tScCm8S95pfiJ4-CEw@mail.gmail.com>
 <23396d7d-9745-bc33-158d-e5346e6fd1c0@t-online.de>
 <CAE0aawG3TtyakERoVxH0YNj4Ztk=cN32FXM8THXZpZryOJ+YEw@mail.gmail.com>
 <CAF0oig2KnfcxtY+7sYQnj6yEXgtH763nuWmMSrehrOXO+Msm_A@mail.gmail.com>
 <CAH+sHrVVvvoL=DHCMigC-aJbGarC_=mubmtexxq=E0gFXTmLJg@mail.gmail.com>
 <CAF0oig3pwg4t_kLRKKBkCJw0PKsV9B45tiDy5xiaUeAzPO42cQ@mail.gmail.com>
 <CAH+sHrX272_PqXnN_1O8x9dcGr82yrUsFG95apCUHdPthMrzdg@mail.gmail.com>
Message-ID: <CAF0oig2qbX=HTB_3MPxSvKAyb-C_bynSa-5HON40GziGHd_yDw@mail.gmail.com>

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 <wuchao04 at gmail.com> 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 <simon.rit at creatis.insa-lyon.fr> ?2018?8?21??? ??3:44???
>
>> Sorry, I checked the doc <http://www.openrtk.org/Doxygen/DocGeo3D.html>
>> and you're right,
>> "(ProjectionOffsetX,ProjectionOffsetY,SourceToIsocenterDistance-SourceToDetectorDistance)
>> are the coordinates of the detector origin in the rotated coordinated
>> system". So yes, add minus signs in front of proj_iso_x and proj_iso_y in
>> my email.
>> One source of confusion here (to me too) is that I refer here to "origin"
>> as point "(0,0)" and not to m_Origin in the itk::Image object... Any
>> suggestion to improve this is welcome.
>> On the other hand, you seem to suggest that source offsets and projection
>> offsets are redundant which is not true in a divergent geometry (or I did
>> not get you).
>> Thanks a lot for your correction.
>> Simon
>>
>>
>> On Tue, Aug 21, 2018 at 3:28 PM Chao Wu <wuchao04 at gmail.com> 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 <simon.rit at creatis.insa-lyon.fr> ?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 <
>>>> andreasga22 at 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:     agravgaard at protonmail.com
>>>>>
>>>>> Cell:      +45 3165 8140
>>>>>
>>>>>
>>>>> On Mon, 20 Aug 2018 at 22:10, Milan Manasijevic <
>>>>> milan-manasijevic at 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 (000000C71D4FE5D0)
>>>>>> Location: "void __cdecl itk::ImageFileWriter<class
>>>>>> itk::Image<float,3> >::Write(void)"
>>>>>> File:
>>>>>> d:\reconstruction_rtk\itk\modules\io\imagebase\include\itkImageFileWriter.hxx
>>>>>> Line: 151
>>>>>> Description:  Could not create IO object for writing file fdk.raw
>>>>>>   Tried to create one of the following:
>>>>>>     NiftiImageIO
>>>>>>     NrrdImageIO
>>>>>>     GiplImageIO
>>>>>>     HDF5ImageIO
>>>>>>     JPEGImageIO
>>>>>>     BMPImageIO
>>>>>>     LSMImageIO
>>>>>>     PNGImageIO
>>>>>>     TIFFImageIO
>>>>>>     VTKImageIO
>>>>>>     StimulateImageIO
>>>>>>     BioRadImageIO
>>>>>>     MetaImageIO
>>>>>>     MRCImageIO
>>>>>>     GE4ImageIO
>>>>>>     GE5ImageIO
>>>>>>     HndImageIO
>>>>>>     XimImageIO
>>>>>>     HisImageIO
>>>>>>     ImagXImageIO
>>>>>>     DCMImagXImageIO
>>>>>>     EdfImageIO
>>>>>>     XRadImageIO
>>>>>>     OraImageIO
>>>>>>     GDCMImageIO
>>>>>>   You probably failed to set a file suffix, or
>>>>>>     set the suffix to an unsupported type.
>>>>>>
>>>>>>
>>>>>> 3) Regarding the "--origin argument" and refering to my context (see
>>>>>> attached files please), what would you suggest, what should I pass as the
>>>>>> origin values? The detecetor origin is at 0,0 but for the Volume I am not
>>>>>> quit sure if I should provide some values and which (actually isocenter
>>>>>> should be at 0,0,0 and if I provide these values I still get no result ).
>>>>>> Probably this would solve my problem.
>>>>>>
>>>>>> Again, many thanks for your time and thank you for your help.
>>>>>>
>>>>>> Best regards,
>>>>>> Milan
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Am 20.08.2018 um 14:26 schrieb Andreas Andersen:
>>>>>>
>>>>>> Hi Milan
>>>>>>
>>>>>> I didn't open the dropbox link, but I think in general one should
>>>>>> take an extra look at the rtkfdk arguments if nothing "meaningful" comes
>>>>>> out:
>>>>>>  Is your spacing in the correct unit (mm)? it seems quite small in
>>>>>> relation to the dimensions.
>>>>>>  Also try adding the --origin argument.
>>>>>>
>>>>>> Additional 1:
>>>>>> Slicer is a good tool for exactly that.
>>>>>> ( I have also made a similar tool with some reconstruction options,
>>>>>> mainly for scatter correction: cbctrecon
>>>>>> <https://gitlab.com/agravgaard/cbctrecon/wikis/Installation> )
>>>>>> Additional 2:
>>>>>> try giving " -o fdk.raw" instead of  "-o fdk.mha", the default output
>>>>>> value type is 32-bit floating point.
>>>>>>
>>>>>> Best regards
>>>>>>  Andreas
>>>>>>
>>>>>> __________________________________
>>>>>>
>>>>>> Andreas Gravgaard Andersen
>>>>>>
>>>>>> Department of Oncology,
>>>>>>
>>>>>> Aarhus University Hospital
>>>>>>
>>>>>> N?rrebrogade 44,
>>>>>>
>>>>>> 8000, Aarhus C
>>>>>>
>>>>>> Mail:     agravgaard at protonmail.com
>>>>>>
>>>>>> Cell:      +45 3165 8140
>>>>>>
>>>>>>
>>>>>> On Sun, 19 Aug 2018 at 23:44, Milan Manasijevic <
>>>>>> milan-manasijevic at 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.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
>>>>>>> Rtk-users at public.kitware.com
>>>>>>> https://public.kitware.com/mailman/listinfo/rtk-users
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>> Rtk-users mailing list
>>>>> Rtk-users at public.kitware.com
>>>>> https://public.kitware.com/mailman/listinfo/rtk-users
>>>>>
>>>> _______________________________________________
>>>> Rtk-users mailing list
>>>> Rtk-users at public.kitware.com
>>>> https://public.kitware.com/mailman/listinfo/rtk-users
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20180822/0cbb40d2/attachment-0001.html>

From wuchao04 at gmail.com  Wed Aug 22 08:45:50 2018
From: wuchao04 at gmail.com (Chao Wu)
Date: Wed, 22 Aug 2018 14:45:50 +0200
Subject: [Rtk-users] Cannot reconstruct the volume,
 what might be the problem?
In-Reply-To: <CAF0oig2qbX=HTB_3MPxSvKAyb-C_bynSa-5HON40GziGHd_yDw@mail.gmail.com>
References: <a544c7df-0dc2-be73-f072-1df97c78274b@t-online.de>
 <CAE0aawGFd+W52wSaRp4Gp8vs1LyYkQ06tScCm8S95pfiJ4-CEw@mail.gmail.com>
 <23396d7d-9745-bc33-158d-e5346e6fd1c0@t-online.de>
 <CAE0aawG3TtyakERoVxH0YNj4Ztk=cN32FXM8THXZpZryOJ+YEw@mail.gmail.com>
 <CAF0oig2KnfcxtY+7sYQnj6yEXgtH763nuWmMSrehrOXO+Msm_A@mail.gmail.com>
 <CAH+sHrVVvvoL=DHCMigC-aJbGarC_=mubmtexxq=E0gFXTmLJg@mail.gmail.com>
 <CAF0oig3pwg4t_kLRKKBkCJw0PKsV9B45tiDy5xiaUeAzPO42cQ@mail.gmail.com>
 <CAH+sHrX272_PqXnN_1O8x9dcGr82yrUsFG95apCUHdPthMrzdg@mail.gmail.com>
 <CAF0oig2qbX=HTB_3MPxSvKAyb-C_bynSa-5HON40GziGHd_yDw@mail.gmail.com>
Message-ID: <CAH+sHrXFKn=g_ObxP+Ynu=G0YNBYx+vFcxg_sytVg0gQAa4HFA@mail.gmail.com>

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 <simon.rit at creatis.insa-lyon.fr> ?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 <wuchao04 at gmail.com> 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 <simon.rit at creatis.insa-lyon.fr> ?2018?8?21??? ??3:44???
>>
>>> Sorry, I checked the doc <http://www.openrtk.org/Doxygen/DocGeo3D.html>
>>> and you're right,
>>> "(ProjectionOffsetX,ProjectionOffsetY,SourceToIsocenterDistance-SourceToDetectorDistance)
>>> are the coordinates of the detector origin in the rotated coordinated
>>> system". So yes, add minus signs in front of proj_iso_x and proj_iso_y in
>>> my email.
>>> One source of confusion here (to me too) is that I refer here to
>>> "origin" as point "(0,0)" and not to m_Origin in the itk::Image object...
>>> Any suggestion to improve this is welcome.
>>> On the other hand, you seem to suggest that source offsets and
>>> projection offsets are redundant which is not true in a divergent geometry
>>> (or I did not get you).
>>> Thanks a lot for your correction.
>>> Simon
>>>
>>>
>>> On Tue, Aug 21, 2018 at 3:28 PM Chao Wu <wuchao04 at gmail.com> 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 <simon.rit at creatis.insa-lyon.fr> ?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 <
>>>>> andreasga22 at 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:     agravgaard at protonmail.com
>>>>>>
>>>>>> Cell:      +45 3165 8140
>>>>>>
>>>>>>
>>>>>> On Mon, 20 Aug 2018 at 22:10, Milan Manasijevic <
>>>>>> milan-manasijevic at 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 (000000C71D4FE5D0)
>>>>>>> Location: "void __cdecl itk::ImageFileWriter<class
>>>>>>> itk::Image<float,3> >::Write(void)"
>>>>>>> File:
>>>>>>> d:\reconstruction_rtk\itk\modules\io\imagebase\include\itkImageFileWriter.hxx
>>>>>>> Line: 151
>>>>>>> Description:  Could not create IO object for writing file fdk.raw
>>>>>>>   Tried to create one of the following:
>>>>>>>     NiftiImageIO
>>>>>>>     NrrdImageIO
>>>>>>>     GiplImageIO
>>>>>>>     HDF5ImageIO
>>>>>>>     JPEGImageIO
>>>>>>>     BMPImageIO
>>>>>>>     LSMImageIO
>>>>>>>     PNGImageIO
>>>>>>>     TIFFImageIO
>>>>>>>     VTKImageIO
>>>>>>>     StimulateImageIO
>>>>>>>     BioRadImageIO
>>>>>>>     MetaImageIO
>>>>>>>     MRCImageIO
>>>>>>>     GE4ImageIO
>>>>>>>     GE5ImageIO
>>>>>>>     HndImageIO
>>>>>>>     XimImageIO
>>>>>>>     HisImageIO
>>>>>>>     ImagXImageIO
>>>>>>>     DCMImagXImageIO
>>>>>>>     EdfImageIO
>>>>>>>     XRadImageIO
>>>>>>>     OraImageIO
>>>>>>>     GDCMImageIO
>>>>>>>   You probably failed to set a file suffix, or
>>>>>>>     set the suffix to an unsupported type.
>>>>>>>
>>>>>>>
>>>>>>> 3) Regarding the "--origin argument" and refering to my context (see
>>>>>>> attached files please), what would you suggest, what should I pass as the
>>>>>>> origin values? The detecetor origin is at 0,0 but for the Volume I am not
>>>>>>> quit sure if I should provide some values and which (actually isocenter
>>>>>>> should be at 0,0,0 and if I provide these values I still get no result ).
>>>>>>> Probably this would solve my problem.
>>>>>>>
>>>>>>> Again, many thanks for your time and thank you for your help.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Milan
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Am 20.08.2018 um 14:26 schrieb Andreas Andersen:
>>>>>>>
>>>>>>> Hi Milan
>>>>>>>
>>>>>>> I didn't open the dropbox link, but I think in general one should
>>>>>>> take an extra look at the rtkfdk arguments if nothing "meaningful" comes
>>>>>>> out:
>>>>>>>  Is your spacing in the correct unit (mm)? it seems quite small in
>>>>>>> relation to the dimensions.
>>>>>>>  Also try adding the --origin argument.
>>>>>>>
>>>>>>> Additional 1:
>>>>>>> Slicer is a good tool for exactly that.
>>>>>>> ( I have also made a similar tool with some reconstruction options,
>>>>>>> mainly for scatter correction: cbctrecon
>>>>>>> <https://gitlab.com/agravgaard/cbctrecon/wikis/Installation> )
>>>>>>> Additional 2:
>>>>>>> try giving " -o fdk.raw" instead of  "-o fdk.mha", the default
>>>>>>> output value type is 32-bit floating point.
>>>>>>>
>>>>>>> Best regards
>>>>>>>  Andreas
>>>>>>>
>>>>>>> __________________________________
>>>>>>>
>>>>>>> Andreas Gravgaard Andersen
>>>>>>>
>>>>>>> Department of Oncology,
>>>>>>>
>>>>>>> Aarhus University Hospital
>>>>>>>
>>>>>>> N?rrebrogade 44,
>>>>>>>
>>>>>>> 8000, Aarhus C
>>>>>>>
>>>>>>> Mail:     agravgaard at protonmail.com
>>>>>>>
>>>>>>> Cell:      +45 3165 8140
>>>>>>>
>>>>>>>
>>>>>>> On Sun, 19 Aug 2018 at 23:44, Milan Manasijevic <
>>>>>>> milan-manasijevic at 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.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
>>>>>>>> Rtk-users at public.kitware.com
>>>>>>>> https://public.kitware.com/mailman/listinfo/rtk-users
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>> Rtk-users mailing list
>>>>>> Rtk-users at public.kitware.com
>>>>>> https://public.kitware.com/mailman/listinfo/rtk-users
>>>>>>
>>>>> _______________________________________________
>>>>> Rtk-users mailing list
>>>>> Rtk-users at public.kitware.com
>>>>> https://public.kitware.com/mailman/listinfo/rtk-users
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20180822/6ee41e4a/attachment-0001.html>

From simon.rit at creatis.insa-lyon.fr  Wed Aug 22 09:40:22 2018
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Wed, 22 Aug 2018 15:40:22 +0200
Subject: [Rtk-users] Cannot reconstruct the volume,
 what might be the problem?
In-Reply-To: <CAH+sHrXFKn=g_ObxP+Ynu=G0YNBYx+vFcxg_sytVg0gQAa4HFA@mail.gmail.com>
References: <a544c7df-0dc2-be73-f072-1df97c78274b@t-online.de>
 <CAE0aawGFd+W52wSaRp4Gp8vs1LyYkQ06tScCm8S95pfiJ4-CEw@mail.gmail.com>
 <23396d7d-9745-bc33-158d-e5346e6fd1c0@t-online.de>
 <CAE0aawG3TtyakERoVxH0YNj4Ztk=cN32FXM8THXZpZryOJ+YEw@mail.gmail.com>
 <CAF0oig2KnfcxtY+7sYQnj6yEXgtH763nuWmMSrehrOXO+Msm_A@mail.gmail.com>
 <CAH+sHrVVvvoL=DHCMigC-aJbGarC_=mubmtexxq=E0gFXTmLJg@mail.gmail.com>
 <CAF0oig3pwg4t_kLRKKBkCJw0PKsV9B45tiDy5xiaUeAzPO42cQ@mail.gmail.com>
 <CAH+sHrX272_PqXnN_1O8x9dcGr82yrUsFG95apCUHdPthMrzdg@mail.gmail.com>
 <CAF0oig2qbX=HTB_3MPxSvKAyb-C_bynSa-5HON40GziGHd_yDw@mail.gmail.com>
 <CAH+sHrXFKn=g_ObxP+Ynu=G0YNBYx+vFcxg_sytVg0gQAa4HFA@mail.gmail.com>
Message-ID: <CAF0oig24cS=LyNQ9ZLpoV+ZtRt92KVMdfR3WASLS=6K+e8kygg@mail.gmail.com>

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 <wuchao04 at gmail.com> 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 <simon.rit at creatis.insa-lyon.fr> ?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 <wuchao04 at gmail.com> 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 <simon.rit at creatis.insa-lyon.fr> ?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 <wuchao04 at gmail.com> 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 <simon.rit at creatis.insa-lyon.fr> ?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 <andreasga22 at 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:     agravgaard at protonmail.com
>>>>>>>
>>>>>>> Cell:      +45 3165 8140
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, 20 Aug 2018 at 22:10, Milan Manasijevic <milan-manasijevic at 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 (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:     agravgaard at protonmail.com
>>>>>>>>
>>>>>>>> Cell:      +45 3165 8140
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sun, 19 Aug 2018 at 23:44, Milan Manasijevic <milan-manasijevic at 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.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
>>>>>>>>> Rtk-users at public.kitware.com
>>>>>>>>> https://public.kitware.com/mailman/listinfo/rtk-users
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Rtk-users mailing list
>>>>>>> Rtk-users at public.kitware.com
>>>>>>> https://public.kitware.com/mailman/listinfo/rtk-users
>>>>>>
>>>>>> _______________________________________________
>>>>>> Rtk-users mailing list
>>>>>> Rtk-users at public.kitware.com
>>>>>> https://public.kitware.com/mailman/listinfo/rtk-users

From wuchao04 at gmail.com  Wed Aug 22 09:55:29 2018
From: wuchao04 at gmail.com (Chao Wu)
Date: Wed, 22 Aug 2018 15:55:29 +0200
Subject: [Rtk-users] Cannot reconstruct the volume,
 what might be the problem?
In-Reply-To: <CAF0oig24cS=LyNQ9ZLpoV+ZtRt92KVMdfR3WASLS=6K+e8kygg@mail.gmail.com>
References: <a544c7df-0dc2-be73-f072-1df97c78274b@t-online.de>
 <CAE0aawGFd+W52wSaRp4Gp8vs1LyYkQ06tScCm8S95pfiJ4-CEw@mail.gmail.com>
 <23396d7d-9745-bc33-158d-e5346e6fd1c0@t-online.de>
 <CAE0aawG3TtyakERoVxH0YNj4Ztk=cN32FXM8THXZpZryOJ+YEw@mail.gmail.com>
 <CAF0oig2KnfcxtY+7sYQnj6yEXgtH763nuWmMSrehrOXO+Msm_A@mail.gmail.com>
 <CAH+sHrVVvvoL=DHCMigC-aJbGarC_=mubmtexxq=E0gFXTmLJg@mail.gmail.com>
 <CAF0oig3pwg4t_kLRKKBkCJw0PKsV9B45tiDy5xiaUeAzPO42cQ@mail.gmail.com>
 <CAH+sHrX272_PqXnN_1O8x9dcGr82yrUsFG95apCUHdPthMrzdg@mail.gmail.com>
 <CAF0oig2qbX=HTB_3MPxSvKAyb-C_bynSa-5HON40GziGHd_yDw@mail.gmail.com>
 <CAH+sHrXFKn=g_ObxP+Ynu=G0YNBYx+vFcxg_sytVg0gQAa4HFA@mail.gmail.com>
 <CAF0oig24cS=LyNQ9ZLpoV+ZtRt92KVMdfR3WASLS=6K+e8kygg@mail.gmail.com>
Message-ID: <CAH+sHrWSX27T-4tstT3DjLPWmZ27fuwQNCDSZEC6h5kK-kOK4g@mail.gmail.com>

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 <simon.rit at creatis.insa-lyon.fr> ?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 <wuchao04 at gmail.com> 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 <simon.rit at creatis.insa-lyon.fr> ?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 <wuchao04 at gmail.com> 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 <simon.rit at creatis.insa-lyon.fr> ?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 <wuchao04 at gmail.com> 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 <simon.rit at creatis.insa-lyon.fr> ?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 <
> andreasga22 at 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:     agravgaard at protonmail.com
> >>>>>>>
> >>>>>>> Cell:      +45 3165 8140
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On Mon, 20 Aug 2018 at 22:10, Milan Manasijevic <
> milan-manasijevic at 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 (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:     agravgaard at protonmail.com
> >>>>>>>>
> >>>>>>>> Cell:      +45 3165 8140
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Sun, 19 Aug 2018 at 23:44, Milan Manasijevic <
> milan-manasijevic at 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.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
> >>>>>>>>> Rtk-users at public.kitware.com
> >>>>>>>>> https://public.kitware.com/mailman/listinfo/rtk-users
> >>>>>>>>
> >>>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Rtk-users mailing list
> >>>>>>> Rtk-users at public.kitware.com
> >>>>>>> https://public.kitware.com/mailman/listinfo/rtk-users
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Rtk-users mailing list
> >>>>>> Rtk-users at public.kitware.com
> >>>>>> https://public.kitware.com/mailman/listinfo/rtk-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20180822/c1575dcc/attachment-0001.html>