From andy.shieh at sydney.edu.au Fri Jan 5 19:54:03 2018 From: andy.shieh at sydney.edu.au (Chun-Chien (Andy) Shieh) Date: Sat, 6 Jan 2018 00:54:03 +0000 Subject: [Rtk-users] The SPARE Challenge - Sparse-view Reconstruction Challenge for Four-dimensional Cone-beam CT Message-ID: Dear friends in the RTK community, Greetings from Australia. I am a research fellow from the ACRF Image X Institute at the University of Sydney. Our lab is conducting an international challenge study on high quality 4D-CBCT reconstruction using sparse data - The SPARE challenge. Simon is also a co-host of the challenge, who has provided a lot of inputs and datasets (Thanks Simon!) The purpose of the study is to systematically investigate the feasibility of high quality 4D-CBCT from a one-minute scan. With the audience of this mailing list being one of the biggest CBCT reconstruction communities, participation from the RTK community would definitely be of very valuable contribution to the study. Details on the study and how to register are included below. At the moment the participants will be given about 2 months to perform the reconstruction after receiving the raw projection data around end of January 2018. But this can be discussed with the participants after registration closes. Participants with the best performing algorithms will be contacted regarding being included as co-authors on the related publications. Please do not hesitate to contact me if you have any questions. Thanks everyone and we look forward to seeing participants from this brilliant community! Best regards, Andy DR CHUN-CHIEN (ANDY) SHIEH | NHMRC & CINSW Early Career Research Fellow ACRF Image X Institute | Sydney Medical School | The University of Sydney Room 215, Biomedical Building, Central Ave, Eveleigh | NSW | 2015 T +61 2 8627 1184 M +61 411 790 746 E andy.shieh at sydney.edu.au | W http://sydney.edu.au/medicine/image-x/ ===================== The SPARE Challenge - Sparse-view Reconstruction Challenge for Four-dimensional Cone-beam CT Now open for participant registration. The ACRF Image X Institute in Sydney led by Prof Paul Keall is starting a challenge study on reconstructing high quality 4DCBCT images from one-minute scans - the SPARE challenge. The goal of this study is to investigate the potential of 4DCBCT reconstructions from existing 3D CBCT acquisition. In this study, participants will receive down-sampled projection data and prior CT to apply their reconstruction algorithms on. The final reconstructions will be submitted to the host, who will systematically compare the performance of the algorithms using a set of ground truths not available to the participants. Participants with the best performing algorithms will be contacted to provide further details of their methods, and will be included as co-authors of the paper that is planned to be submitted to MedPhys. More details on the challenge datasets and timeline can be found on the SPARE Challenge webpage: http://sydney.edu.au/medicine/image-x/research/SPARE-Challenge.php The registration link is at the bottom of the webpage, or here: https://docs.google.com/forms/d/e/1FAIpQLSdUH3iGgayA3iNGnGA4UPHxUZdluUo50GSjwDWImIezuVg64Q/viewform Registration closes 5pm 15 January 2018 Australia Eastern Daylight Time. Please feel free to share this with anyone who might be interested in participating. ===================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From cyril.mory at creatis.insa-lyon.fr Tue Jan 9 05:31:12 2018 From: cyril.mory at creatis.insa-lyon.fr (Cyril Mory) Date: Tue, 9 Jan 2018 11:31:12 +0100 Subject: [Rtk-users] problem while determining the interpolation weights in 4D ROOSTER Reconstruction In-Reply-To: <88BEDC3F-802B-4D7D-A627-C28A26D68ED5@siat.ac.cn> References: <67C09C9C-1748-4508-B287-C15F769256D6@siat.ac.cn> <88BEDC3F-802B-4D7D-A627-C28A26D68ED5@siat.ac.cn> Message-ID: <66e33d08-af6f-0d34-d5c4-628ad91a157c@creatis.insa-lyon.fr> Hi Ruoyan, I've had a look at your file sphase.txt, it looks perfectly fine to me. The problem must lie elsewhere. Does the application 4D ROOSTER work with the example data provided on the wiki ? If it does, then the problem lies in your data. In that case, please run rtkprojections --path D:\bd\20171116 --regexp .*.his -o projections.mhd and send us the "projections.mhd" file. It will contain only the metadata of your projections, and we'll be able to run the same command line as you and try to reproduce the problem. If, on the other hand, it doesn't even work with the example data provided on the wiki, it is a software problem. In that case, can you first update to the latest RTK (the git master branch), recompile and test again ? Best regards, Cyril On 26/12/2017 10:47, ry.meng wrote: > Hi > > Thank you for your reply. I have checked the value in sphase.txt and > don't have any value larger or equal to 5. Maybe the problem lies > elsewhere? Thanks. > > Regards > > Ruoyan Meng > > On 12/26/2017 17:14?Simon Rit > wrote? > > Hi, > If you look at the code > , > you'll see that the error message corresponds to the case where > you have a phase which equals the number of frames. This cannot be > since it is 0-based. In other words, with the option "--frames 5", > you cannot have a value larger or equal to 5 in your file sphase.txt. > Simon > > On Mon, Dec 25, 2017 at 9:36 AM, ry.meng > wrote: > > > Hi: > When I tried ?the application of 4D ROOSTER Reconstruction > with my own data, it will stop for the following reason: > problem while determining the interpolation weights. Maybe you > guys have met this problem before and have a solution for > it.?Thank you very much and I hope to receive your reply soon. > > > Happy Holidays! > > > Regards > > Ruoyan Meng > > ------------------------------------------------------------------------------------------ > > Research Center for Medical Robotics and Minimally Invasive > Surgical Devices, > Institute of Biomedical and Health Engineering, > Shenzhen Institutes of Advanced Technology, Chinese Academy of > Sciences > Tel: +86-18576617767 > Email: ry.meng at siat.ac.cn > Zip:? ? ? ?518055 > Add: No. 1068 Xueyuan Avenue, Nanshan, Shenzhen, China > > > > > > > > > _______________________________________________ > 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: From cyril.mory at creatis.insa-lyon.fr Tue Jan 9 07:48:11 2018 From: cyril.mory at creatis.insa-lyon.fr (Cyril Mory) Date: Tue, 9 Jan 2018 13:48:11 +0100 Subject: [Rtk-users] problem while determining the interpolation weights in 4D ROOSTER Reconstruction In-Reply-To: <66e33d08-af6f-0d34-d5c4-628ad91a157c@creatis.insa-lyon.fr> References: <67C09C9C-1748-4508-B287-C15F769256D6@siat.ac.cn> <88BEDC3F-802B-4D7D-A627-C28A26D68ED5@siat.ac.cn> <66e33d08-af6f-0d34-d5c4-628ad91a157c@creatis.insa-lyon.fr> Message-ID: Hi again Ruoyan, I have investigated further and found the source of the problem: the code performs a rounding of the phase signal to two digits, which for some values of your phase ended up to be 1. And the rest of the code assumes that the phase belongs to [0; 1[, i.e. there should never be a value 1. The rounding is useful for optimization: projections with identical phases can be forward and backprojected together, which is faster than one-by-one, and with high-precision phase values, there are never two equal phase values. So I just fixed the bug by setting the phase to 0 when its rounding is equal to 1, which should do the trick. The pull request is being tested, it should be merged soon. Thanks for reporting your issue. Regards, Cyril On 09/01/2018 11:31, Cyril Mory wrote: > > Hi Ruoyan, > > > I've had a look at your file sphase.txt, it looks perfectly fine to > me. The problem must lie elsewhere. Does the application 4D ROOSTER > work with the example data provided on the wiki ? If it does, then the > problem lies in your data. In that case, please run > > > rtkprojections --path D:\bd\20171116 --regexp .*.his -o projections.mhd > > > and send us the "projections.mhd" file. It will contain only the > metadata of your projections, and we'll be able to run the same > command line as you and try to reproduce the problem. > > > If, on the other hand, it doesn't even work with the example data > provided on the wiki, it is a software problem. In that case, can you > first update to the latest RTK (the git master branch), recompile and > test again ? > > > Best regards, > > Cyril > > > On 26/12/2017 10:47, ry.meng wrote: >> Hi >> >> Thank you for your reply. I have checked the value in sphase.txt and >> don't have any value larger or equal to 5. Maybe the problem lies >> elsewhere? Thanks. >> >> Regards >> >> Ruoyan Meng >> >> On 12/26/2017 17:14?Simon Rit >> wrote? >> >> Hi, >> If you look at the code >> , >> you'll see that the error message corresponds to the case where >> you have a phase which equals the number of frames. This cannot >> be since it is 0-based. In other words, with the option "--frames >> 5", you cannot have a value larger or equal to 5 in your file >> sphase.txt. >> Simon >> >> On Mon, Dec 25, 2017 at 9:36 AM, ry.meng > > wrote: >> >> >> Hi: >> When I tried ?the application of 4D ROOSTER Reconstruction >> with my own data, it will stop for the following reason: >> problem while determining the interpolation weights. Maybe >> you guys have met this problem before and have a solution for >> it.?Thank you very much and I hope to receive your reply soon. >> >> >> Happy Holidays! >> >> >> Regards >> >> Ruoyan Meng >> >> ------------------------------------------------------------------------------------------ >> >> Research Center for Medical Robotics and Minimally Invasive >> Surgical Devices, >> Institute of Biomedical and Health Engineering, >> Shenzhen Institutes of Advanced Technology, Chinese Academy >> of Sciences >> Tel: +86-18576617767 >> Email: ry.meng at siat.ac.cn >> Zip:? ? ? ?518055 >> Add: No. 1068 Xueyuan Avenue, Nanshan, Shenzhen, China >> >> >> >> >> >> >> >> >> _______________________________________________ >> 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: From cyril.mory at creatis.insa-lyon.fr Tue Jan 9 11:33:43 2018 From: cyril.mory at creatis.insa-lyon.fr (Cyril Mory) Date: Tue, 9 Jan 2018 17:33:43 +0100 Subject: [Rtk-users] problem while determining the interpolation weights in 4D ROOSTER Reconstruction In-Reply-To: References: <67C09C9C-1748-4508-B287-C15F769256D6@siat.ac.cn> <88BEDC3F-802B-4D7D-A627-C28A26D68ED5@siat.ac.cn> <66e33d08-af6f-0d34-d5c4-628ad91a157c@creatis.insa-lyon.fr> <5D207BEE-6153-4D53-BD0C-6CD67BE69149@siat.ac.cn> Message-ID: <469fa9e3-6104-f2fe-933c-8cb81f628db6@creatis.insa-lyon.fr> > Ruoyan, > > > From the shroud image, the signal extraction sometimes fails to find > the period of the motion of the diaphragm, which results in incorrect > phase detection. The easiest way to make sure your respiratory phase > has been correctly detected is to used the following python script: > > https://www.creatis.insa-lyon.fr/~mory/showPeaksOverShroud.py > > > You have to save your shroud image with .mhd extension, because > simpleRTK can't read .mha (I think), so modify the command line that > generates it (in the 4DROOSTER wiki page, that would be > > rtkamsterdamshroud--path . \ > --regexp '.*.his' \ > --output shroud.mha \ > --unsharp 650) > Change "shroud.mha" into "shroud.mhd", re-run all command lines except > the ROOSTER reconstruction, and then run > > "showPeaksOverShroud.py shroud.mhd sphase.txt" > > It will generate an RGB image named "peaksOverShroud.png", which shows > the shroud, and overlays the detected extrema of the phase. If your > detection is wrong, you'll see it. The script requires SimpleRTK, > python and a few python libs. > > If your peaks detection is indeed incorrect, you can try cropping the > shroud to the region where the periodic signal is most visible. This > is usually sufficient. If you need more help, send over your > shroud.mhd and shroud.raw file. > > Regards, > Cyril > > On 09/01/2018 15:47, ry.meng wrote: >> Hi Cyril, >> >> The attachment is our projections.mhdfile and we are running the >> latest RTK, example data works well. >> I have another question about our sphase.txt file. As my >> understanding of 4D reconstruction process, spase.txt file should be >> the?optimal fit respiration signals. But in our file, it only has 6 >> cycles, which is impossible, it confused me. >> I'm now testing your new code with our data, hope it works! >> Thanks for your help. >>>> >>>> >>>> Regards >>>> >>>> Ruoyan Meng >>>> >> On 1/9/2018 20:48?Cyril Mory >> wrote? >> >> Hi again Ruoyan, >> >> >> I have investigated further and found the source of the problem: >> the code performs a rounding of the phase signal to two digits, >> which for some values of your phase ended up to be 1. And the >> rest of the code assumes that the phase belongs to [0; 1[, i.e. >> there should never be a value 1. >> The rounding is useful for optimization: projections with >> identical phases can be forward and backprojected together, which >> is faster than one-by-one, and with high-precision phase values, >> there are never two equal phase values. >> >> >> So I just fixed the bug by setting the phase to 0 when its >> rounding is equal to 1, which should do the trick. The pull >> request is being tested, it should be merged soon. >> >> >> Thanks for reporting your issue. >> >> Regards, >> >> Cyril >> >> >> On 09/01/2018 11:31, Cyril Mory wrote: >>> >>> Hi Ruoyan, >>> >>> >>> I've had a look at your file sphase.txt, it looks perfectly fine >>> to me. The problem must lie elsewhere. Does the application 4D >>> ROOSTER work with the example data provided on the wiki ? If it >>> does, then the problem lies in your data. In that case, please run >>> >>> >>> rtkprojections --path D:\bd\20171116 --regexp .*.his >>> -oD:\bd\20171116\projections.mhd >>> >>> >>> and send us the "projections.mhd" file. It will contain only the >>> metadata of your projections, and we'll be able to run the same >>> command line as you and try to reproduce the problem. >>> >>> >>> If, on the other hand, it doesn't even work with the example >>> data provided on the wiki, it is a software problem. In that >>> case, can you first update to the latest RTK (the git master >>> branch), recompile and test again ? >>> >>> >>> Best regards, >>> >>> Cyril >>> >>> >>> On 26/12/2017 10:47, ry.meng wrote: >>>> Hi >>>> >>>> Thank you for your reply. I have checked the value in >>>> sphase.txt and don't have any value larger or equal to 5. Maybe >>>> the problem lies elsewhere? Thanks. >>>> >>>> Regards >>>> >>>> Ruoyan Meng >>>> >>>> On 12/26/2017 17:14?Simon Rit >>>> wrote? >>>> >>>> Hi, >>>> If you look at the code >>>> , >>>> you'll see that the error message corresponds to the case >>>> where you have a phase which equals the number of frames. >>>> This cannot be since it is 0-based. In other words, with >>>> the option "--frames 5", you cannot have a value larger or >>>> equal to 5 in your file sphase.txt. >>>> Simon >>>> >>>> On Mon, Dec 25, 2017 at 9:36 AM, ry.meng >>>> > wrote: >>>> >>>> >>>> Hi: >>>> When I tried ?the application of 4D ROOSTER >>>> Reconstruction with my own data, it will stop for the >>>> following reason: problem while determining the >>>> interpolation weights. Maybe you guys have met this >>>> problem before and have a solution for it.?Thank you >>>> very much and I hope to receive your reply soon. >>>> >>>> >>>> Happy Holidays! >>>> >>>> >>>> Regards >>>> >>>> Ruoyan Meng >>>> >>>> ------------------------------------------------------------------------------------------ >>>> >>>> Research Center for Medical Robotics and Minimally >>>> Invasive Surgical Devices, >>>> Institute of Biomedical and Health Engineering, >>>> Shenzhen Institutes of Advanced Technology, Chinese >>>> Academy of Sciences >>>> Tel: +86-18576617767 >>>> Email: ry.meng at siat.ac.cn >>>> Zip:? ? ? ?518055 >>>> Add: No. 1068 Xueyuan Avenue, Nanshan, Shenzhen, China >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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: From cyril.mory at creatis.insa-lyon.fr Thu Jan 11 03:57:22 2018 From: cyril.mory at creatis.insa-lyon.fr (Cyril Mory) Date: Thu, 11 Jan 2018 09:57:22 +0100 Subject: [Rtk-users] problem while determining the interpolation weights in 4D ROOSTER Reconstruction In-Reply-To: <66E4352A-AC64-4CFD-8DA0-E22BC5168E07@siat.ac.cn> References: <67C09C9C-1748-4508-B287-C15F769256D6@siat.ac.cn> <88BEDC3F-802B-4D7D-A627-C28A26D68ED5@siat.ac.cn> <66e33d08-af6f-0d34-d5c4-628ad91a157c@creatis.insa-lyon.fr> <5D207BEE-6153-4D53-BD0C-6CD67BE69149@siat.ac.cn> <469fa9e3-6104-f2fe-933c-8cb81f628db6@creatis.insa-lyon.fr> <66E4352A-AC64-4CFD-8DA0-E22BC5168E07@siat.ac.cn> Message-ID: <3dff8cae-3131-f9ce-6fc9-2ee1bc7f400b@creatis.insa-lyon.fr> Hi Ruoyan, The original sphase.txt you sent a few days earlier does not look like the Matlab plot you just sent. I guess you modified it in the meantime. It does not matter much, but for one of the images I'm sending, I've used your old sphase.txt. I am not the best person to help you with your SimpleRTK problem. If you're used to Matlab, let's go for that way. First, you can open your shroud image using Matlab, for example with the function read_mhd() provided in MITK. See http://mitk.org/wiki/The_Medical_Imaging_Interaction_Toolkit_(MITK) . Second, to crop it using Matlab, simply keep the part where the diaphragm motion is most visible (I removed the whole top part, wide 285 pixels), then save the file back to croppedShroud.mhd, then rerun phase extraction. I have used another tool than Matlab to crop the image, but it shouldn't matter. And I have rerun phase extraction, and generated the overlay of peaks over shroud image in both cases. See the attached pictures. Note that a few respiratory cycles have been missed by the algorithm. You can try playing with parameters of rtkextractshroudsignal, but those cycles will be hard to detect anyway, since they correspond to irregular breathing (it looks like the patient coughed). You can live with that, or modify the phase file manually to add those cycles: the phase is nothing more than a number that goes linearly from 0 to 1 between one peak and the next. I hope it helps, Cyril On 11/01/2018 07:54, ry.meng wrote: > Hi Cyril, > > The new code works fine, I still got some questions about sphase.txt file. > When building simpleRTK, I met an error "error MSB6006: > ?cmd.exe?exit?code 1", and I didn't find a solution. So I just plot > sphase.txt with Matlab and compare it with respiration signals > provided by raw data. They are quite different. I am not very clear > about how to crop the shroud, can you share the method? Thanks a lot. > >>>>> Regards >>>>> >>>>> Ruoyan Meng >>>>> > > On 1/10/2018 00:33?Cyril Mory > wrote? > >> Ruoyan, >> >> >> From the shroud image, the signal extraction sometimes fails to >> find the period of the motion of the diaphragm, which results in >> incorrect phase detection. The easiest way to make sure your >> respiratory phase has been correctly detected is to used the >> following python script: >> >> https://www.creatis.insa-lyon.fr/~mory/showPeaksOverShroud.py >> >> >> You have to save your shroud image with .mhd extension, because >> simpleRTK can't read .mha (I think), so modify the command line >> that generates it (in the 4DROOSTER wiki page, that would be >> >> rtkamsterdamshroud--path . \ >> --regexp '.*.his' \ >> --output shroud.mha \ >> --unsharp 650) >> Change "shroud.mha" into "shroud.mhd", re-run all command lines >> except the ROOSTER reconstruction, and then run >> >> "showPeaksOverShroud.py shroud.mhd sphase.txt" >> >> It will generate an RGB image named "peaksOverShroud.png", which >> shows the shroud, and overlays the detected extrema of the phase. >> If your detection is wrong, you'll see it. The script requires >> SimpleRTK, python and a few python libs. >> >> If your peaks detection is indeed incorrect, you can try cropping >> the shroud to the region where the periodic signal is most >> visible. This is usually sufficient. If you need more help, send >> over your shroud.mhd and shroud.raw file. >> >> Regards, >> Cyril >> >> On 09/01/2018 15:47, ry.meng wrote: >>> Hi Cyril, >>> >>> The attachment is our projections.mhdfile and we are running the >>> latest RTK, example data works well. >>> I have another question about our sphase.txt file. As my >>> understanding of 4D reconstruction process, spase.txt file >>> should be the?optimal fit respiration signals. But in our file, >>> it only has 6 cycles, which is impossible, it confused me. >>> I'm now testing your new code with our data, hope it works! >>> Thanks for your help. >>>>> >>>>> >>>>> Regards >>>>> >>>>> Ruoyan Meng >>>>> >>> On 1/9/2018 20:48?Cyril Mory >>> wrote? >>> >>> Hi again Ruoyan, >>> >>> >>> I have investigated further and found the source of the >>> problem: the code performs a rounding of the phase signal to >>> two digits, which for some values of your phase ended up to >>> be 1. And the rest of the code assumes that the phase >>> belongs to [0; 1[, i.e. there should never be a value 1. >>> The rounding is useful for optimization: projections with >>> identical phases can be forward and backprojected together, >>> which is faster than one-by-one, and with high-precision >>> phase values, there are never two equal phase values. >>> >>> >>> So I just fixed the bug by setting the phase to 0 when its >>> rounding is equal to 1, which should do the trick. The pull >>> request is being tested, it should be merged soon. >>> >>> >>> Thanks for reporting your issue. >>> >>> Regards, >>> >>> Cyril >>> >>> >>> On 09/01/2018 11:31, Cyril Mory wrote: >>>> >>>> Hi Ruoyan, >>>> >>>> >>>> I've had a look at your file sphase.txt, it looks perfectly >>>> fine to me. The problem must lie elsewhere. Does the >>>> application 4D ROOSTER work with the example data provided >>>> on the wiki ? If it does, then the problem lies in your >>>> data. In that case, please run >>>> >>>> >>>> rtkprojections --path D:\bd\20171116 --regexp .*.his >>>> -oD:\bd\20171116\projections.mhd >>>> >>>> >>>> and send us the "projections.mhd" file. It will contain >>>> only the metadata of your projections, and we'll be able to >>>> run the same command line as you and try to reproduce the >>>> problem. >>>> >>>> >>>> If, on the other hand, it doesn't even work with the >>>> example data provided on the wiki, it is a software >>>> problem. In that case, can you first update to the latest >>>> RTK (the git master branch), recompile and test again ? >>>> >>>> >>>> Best regards, >>>> >>>> Cyril >>>> >>>> >>>> On 26/12/2017 10:47, ry.meng wrote: >>>>> Hi >>>>> >>>>> Thank you for your reply. I have checked the value in >>>>> sphase.txt and don't have any value larger or equal to 5. >>>>> Maybe the problem lies elsewhere? Thanks. >>>>> >>>>> Regards >>>>> >>>>> Ruoyan Meng >>>>> >>>>> On 12/26/2017 17:14?Simon >>>>> Rit >>>>> wrote? >>>>> >>>>> Hi, >>>>> If you look at the code >>>>> , >>>>> you'll see that the error message corresponds to the >>>>> case where you have a phase which equals the number of >>>>> frames. This cannot be since it is 0-based. In other >>>>> words, with the option "--frames 5", you cannot have a >>>>> value larger or equal to 5 in your file sphase.txt. >>>>> Simon >>>>> >>>>> On Mon, Dec 25, 2017 at 9:36 AM, ry.meng >>>>> > wrote: >>>>> >>>>> >>>>> Hi: >>>>> When I tried ?the application of 4D ROOSTER >>>>> Reconstruction with my own data, it will stop for >>>>> the following reason: problem while determining >>>>> the interpolation weights. Maybe you guys have met >>>>> this problem before and have a solution for >>>>> it.?Thank you very much and I hope to receive your >>>>> reply soon. >>>>> >>>>> >>>>> Happy Holidays! >>>>> >>>>> >>>>> Regards >>>>> >>>>> Ruoyan Meng >>>>> >>>>> ------------------------------------------------------------------------------------------ >>>>> >>>>> Research Center for Medical Robotics and Minimally >>>>> Invasive Surgical Devices, >>>>> Institute of Biomedical and Health Engineering, >>>>> Shenzhen Institutes of Advanced Technology, >>>>> Chinese Academy of Sciences >>>>> Tel: +86-18576617767 >>>>> Email: ry.meng at siat.ac.cn >>>>> Zip:? ? ? ?518055 >>>>> Add: No. 1068 Xueyuan Avenue, Nanshan, Shenzhen, >>>>> China >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: peaksOverCroppedShroud.png Type: image/png Size: 200873 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: peaksOverShroud.png Type: image/png Size: 119058 bytes Desc: not available URL: -------------- next part -------------- 0.117647 0.176471 0.235294 0.294118 0.352941 0.411765 0.470588 0.529412 0.588235 0.647059 0.705882 0.764706 0.823529 0.882353 0.941176 0 0.0588235 0.117647 0.176471 0.235294 0.294118 0.352941 0.411765 0.470588 0.529412 0.588235 0.647059 0.705882 0.764706 0.823529 0.882353 0.941176 0 0.0714286 0.142857 0.214286 0.285714 0.357143 0.428571 0.5 0.571429 0.642857 0.714286 0.785714 0.857143 0.928571 0 0.0526316 0.105263 0.157895 0.210526 0.263158 0.315789 0.368421 0.421053 0.473684 0.526316 0.578947 0.631579 0.684211 0.736842 0.789474 0.842105 0.894737 0.947368 0 0.0555556 0.111111 0.166667 0.222222 0.277778 0.333333 0.388889 0.444444 0.5 0.555556 0.611111 0.666667 0.722222 0.777778 0.833333 0.888889 0.944444 0 0.0714286 0.142857 0.214286 0.285714 0.357143 0.428571 0.5 0.571429 0.642857 0.714286 0.785714 0.857143 0.928571 0 0.0714286 0.142857 0.214286 0.285714 0.357143 0.428571 0.5 0.571429 0.642857 0.714286 0.785714 0.857143 0.928571 0 0.0769231 0.153846 0.230769 0.307692 0.384615 0.461538 0.538462 0.615385 0.692308 0.769231 0.846154 0.923077 0 0.0588235 0.117647 0.176471 0.235294 0.294118 0.352941 0.411765 0.470588 0.529412 0.588235 0.647059 0.705882 0.764706 0.823529 0.882353 0.941176 0 0.0625 0.125 0.1875 0.25 0.3125 0.375 0.4375 0.5 0.5625 0.625 0.6875 0.75 0.8125 0.875 0.9375 0 0.0769231 0.153846 0.230769 0.307692 0.384615 0.461538 0.538462 0.615385 0.692308 0.769231 0.846154 0.923077 0 0.0714286 0.142857 0.214286 0.285714 0.357143 0.428571 0.5 0.571429 0.642857 0.714286 0.785714 0.857143 0.928571 0 0.0833333 0.166667 0.25 0.333333 0.416667 0.5 0.583333 0.666667 0.75 0.833333 0.916667 0 0.0833333 0.166667 0.25 0.333333 0.416667 0.5 0.583333 0.666667 0.75 0.833333 0.916667 0 0.0666667 0.133333 0.2 0.266667 0.333333 0.4 0.466667 0.533333 0.6 0.666667 0.733333 0.8 0.866667 0.933333 0 0.0333333 0.0666667 0.1 0.133333 0.166667 0.2 0.233333 0.266667 0.3 0.333333 0.366667 0.4 0.433333 0.466667 0.5 0.533333 0.566667 0.6 0.633333 0.666667 0.7 0.733333 0.766667 0.8 0.833333 0.866667 0.9 0.933333 0.966667 0 0.0555556 0.111111 0.166667 0.222222 0.277778 0.333333 0.388889 0.444444 0.5 0.555556 0.611111 0.666667 0.722222 0.777778 0.833333 0.888889 0.944444 0 0.0555556 0.111111 0.166667 0.222222 0.277778 0.333333 0.388889 0.444444 0.5 0.555556 0.611111 0.666667 0.722222 0.777778 0.833333 0.888889 0.944444 0 0.0588235 0.117647 0.176471 0.235294 0.294118 0.352941 0.411765 0.470588 0.529412 0.588235 0.647059 0.705882 0.764706 0.823529 0.882353 0.941176 0 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 0.5 0.55 0.6 0.65 0.7 0.75 0.8 0.85 0.9 0.95 0 0.0555556 0.111111 0.166667 0.222222 0.277778 0.333333 0.388889 0.444444 0.5 0.555556 0.611111 0.666667 0.722222 0.777778 0.833333 0.888889 0.944444 0 0.0555556 0.111111 0.166667 0.222222 0.277778 0.333333 0.388889 0.444444 0.5 0.555556 0.611111 0.666667 0.722222 0.777778 0.833333 0.888889 0.944444 0 0.0588235 0.117647 0.176471 0.235294 0.294118 0.352941 0.411765 0.470588 0.529412 0.588235 0.647059 0.705882 0.764706 0.823529 0.882353 0.941176 0 0.0625 0.125 0.1875 0.25 0.3125 0.375 0.4375 0.5 0.5625 0.625 0.6875 0.75 0.8125 0.875 0.9375 0 0.0588235 0.117647 0.176471 0.235294 0.294118 0.352941 0.411765 0.470588 0.529412 0.588235 0.647059 0.705882 0.764706 0.823529 0.882353 0.941176 0 0.0526316 0.105263 0.157895 0.210526 0.263158 0.315789 0.368421 0.421053 0.473684 0.526316 0.578947 0.631579 0.684211 0.736842 0.789474 0.842105 0.894737 0.947368 0 0.03125 0.0625 0.09375 0.125 0.15625 0.1875 0.21875 0.25 0.28125 0.3125 0.34375 0.375 0.40625 0.4375 0.46875 0.5 0.53125 0.5625 0.59375 0.625 0.65625 0.6875 0.71875 0.75 0.78125 0.8125 0.84375 0.875 0.90625 0.9375 0.96875 0 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 0.5 0.55 0.6 0.65 0.7 0.75 0.8 0.85 0.9 0.95 0 0.0625 0.125 0.1875 0.25 0.3125 0.375 0.4375 0.5 0.5625 0.625 0.6875 0.75 0.8125 0.875 0.9375 0 0.0588235 0.117647 0.176471 0.235294 0.294118 0.352941 0.411765 0.470588 0.529412 0.588235 0.647059 0.705882 0.764706 0.823529 0.882353 0.941176 0 0.0666667 0.133333 0.2 0.266667 0.333333 0.4 0.466667 0.533333 0.6 0.666667 0.733333 0.8 0.866667 0.933333 0 0.0526316 0.105263 0.157895 0.210526 0.263158 0.315789 0.368421 0.421053 0.473684 0.526316 0.578947 0.631579 0.684211 0.736842 0.789474 0.842105 0.894737 0.947368 0 0.0555556 0.111111 0.166667 0.222222 0.277778 0.333333 0.388889 0.444444 0.5 0.555556 0.611111 0.666667 0.722222 0.777778 0.833333 0.888889 0.944444 0 0.0526316 0.105263 0.157895 0.210526 0.263158 0.315789 0.368421 0.421053 0.473684 0.526316 0.578947 0.631579 0.684211 0.736842 0.789474 0.842105 0.894737 0.947368 0 0.047619 0.0952381 0.142857 0.190476 0.238095 0.285714 0.333333 0.380952 0.428571 0.47619 0.52381 0.571429 0.619048 0.666667 0.714286 0.761905 0.809524 0.857143 0.904762 0.952381 0 0.0357143 0.0714286 0.107143 0.142857 0.178571 0.214286 0.25 0.285714 0.321429 0.357143 0.392857 0.428571 0.464286 0.5 0.535714 0.571429 0.607143 0.642857 0.678571 0.714286 0.75 0.785714 0.821429 0.857143 0.892857 0.928571 0.964286 0 0.0526316 0.105263 0.157895 0.210526 0.263158 0.315789 0.368421 0.421053 0.473684 0.526316 0.578947 0.631579 0.684211 0.736842 0.789474 0.842105 0.894737 0.947368 0 0.0526316 0.105263 0.157895 0.210526 0.263158 0.315789 0.368421 0.421053 0.473684 0.526316 0.578947 0.631579 0.684211 0.736842 0.789474 0.842105 0.894737 0.947368 0 0.0526316 0.105263 0.157895 0.210526 0.263158 0.315789 0.368421 0.421053 0.473684 0.526316 0.578947 0.631579 0.684211 0.736842 0.789474 0.842105 0.894737 0.947368 0 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 0.5 0.55 0.6 0.65 0.7 0.75 0.8 0.85 0.9 0.95 0 0.0555556 0.111111 0.166667 0.222222 0.277778 0.333333 0.388889 0.444444 0.5 0.555556 0.611111 0.666667 0.722222 0.777778 0.833333 0.888889 0.944444 0 0.0625 0.125 0.1875 0.25 0.3125 0.375 0.4375 0.5 0.5625 0.625 0.6875 0.75 0.8125 0.875 0.9375 0 0.0666667 0.133333 0.2 0.266667 0.333333 0.4 0.466667 0.533333 0.6 0.666667 0.733333 0.8 0.866667 0.933333 0 0.0714286 0.142857 0.214286 0.285714 0.357143 0.428571 0.5 0.571429 0.642857 0.714286 0.785714 0.857143 0.928571 0 0.0625 0.125 0.1875 0.25 0.3125 0.375 0.4375 0.5 0.5625 0.625 0.6875 0.75 0.8125 0.875 0.9375 0 0.047619 0.0952381 0.142857 0.190476 0.238095 0.285714 0.333333 0.380952 0.428571 0.47619 0.52381 0.571429 0.619048 0.666667 0.714286 0.761905 0.809524 0.857143 0.904762 0.952381 0 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 0.5 0.55 0.6 0.65 0.7 0.75 0.8 0.85 0.9 0.95 0 0.0588235 0.117647 0.176471 0.235294 0.294118 0.352941 0.411765 0.470588 0.529412 0.588235 0.647059 0.705882 0.764706 0.823529 0.882353 0.941176 0 0.0555556 0.111111 0.166667 0.222222 0.277778 0.333333 0.388889 0.444444 0.5 0.555556 0.611111 0.666667 0.722222 0.777778 0.833333 0.888889 0.944444 0 0.0625 0.125 0.1875 0.25 0.3125 0.375 0.4375 0.5 0.5625 0.625 0.6875 0.75 0.8125 0.875 0.9375 0 0.047619 0.0952381 0.142857 0.190476 0.238095 0.285714 0.333333 0.380952 0.428571 0.47619 0.52381 0.571429 0.619048 0.666667 0.714286 0.761905 0.809524 0.857143 0.904762 0.952381 0 0.0526316 0.105263 0.157895 0.210526 0.263158 0.315789 0.368421 0.421053 0.473684 0.526316 0.578947 0.631579 0.684211 0.736842 0.789474 0.842105 0.894737 0.947368 0 0.0625 0.125 0.1875 0.25 0.3125 0.375 0.4375 0.5 0.5625 0.625 0.6875 0.75 0.8125 0.875 0.9375 0 0.0625 0.125 0.1875 0.25 0.3125 0.375 0.4375 0.5 0.5625 0.625 0.6875 0.75 0.8125 0.875 0.9375 0 0.0555556 0.111111 0.166667 0.222222 0.277778 0.333333 0.388889 0.444444 0.5 0.555556 0.611111 0.666667 0.722222 0.777778 0.833333 0.888889 0.944444 0 0.0714286 0.142857 0.214286 0.285714 0.357143 0.428571 0.5 0.571429 0.642857 0.714286 0.785714 0.857143 0.928571 0 0.0588235 0.117647 0.176471 0.235294 0.294118 0.352941 0.411765 0.470588 0.529412 0.588235 0.647059 0.705882 0.764706 0.823529 0.882353 0.941176 0 0.0357143 0.0714286 0.107143 0.142857 0.178571 0.214286 0.25 0.285714 0.321429 0.357143 0.392857 0.428571 0.464286 0.5 0.535714 0.571429 0.607143 0.642857 0.678571 0.714286 0.75 0.785714 0.821429 0.857143 0.892857 0.928571 0.964286 0 0.0666667 0.133333 0.2 0.266667 0.333333 0.4 0.466667 0.533333 0.6 0.666667 0.733333 0.8 0.866667 0.933333 0 0.0526316 0.105263 0.157895 0.210526 0.263158 0.315789 0.368421 0.421053 0.473684 0.526316 0.578947 0.631579 0.684211 0.736842 0.789474 0.842105 0.894737 0.947368 0 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 0.5 0.55 0.6 0.65 0.7 0.75 0.8 0.85 0.9 0.95 0 0.0555556 0.111111 0.166667 0.222222 0.277778 0.333333 0.388889 0.444444 0.5 0.555556 0.611111 0.666667 0.722222 0.777778 0.833333 0.888889 0.944444 0 0.0434783 0.0869565 0.130435 0.173913 0.217391 0.26087 0.304348 0.347826 0.391304 0.434783 0.478261 0.521739 0.565217 0.608696 0.652174 0.695652 0.73913 0.782609 0.826087 0.869565 0.913043 0.956522 0 0.0588235 0.117647 0.176471 0.235294 0.294118 0.352941 0.411765 0.470588 0.529412 0.588235 0.647059 0.705882 0.764706 0.823529 0.882353 0.941176 0 0.0666667 0.133333 0.2 0.266667 0.333333 0.4 0.466667 0.533333 0.6 0.666667 0.733333 0.8 0.866667 0.933333 0 0.0769231 0.153846 0.230769 0.307692 0.384615 0.461538 0.538462 0.615385 0.692308 0.769231 0.846154 0.923077 0 0.0588235 0.117647 0.176471 0.235294 0.294118 0.352941 0.411765 0.470588 0.529412 0.588235 0.647059 0.705882 0.764706 0.823529 0.882353 0.941176 0 0.0526316 0.105263 0.157895 0.210526 0.263158 0.315789 0.368421 0.421053 0.473684 0.526316 0.578947 0.631579 0.684211 0.736842 0.789474 0.842105 0.894737 0.947368 0 0.0588235 0.117647 0.176471 0.235294 0.294118 0.352941 0.411765 0.470588 0.529412 0.588235 0.647059 0.705882 0.764706 0.823529 0.882353 0.941176 0 0.047619 0.0952381 0.142857 0.190476 0.238095 0.285714 0.333333 0.380952 0.428571 0.47619 0.52381 0.571429 0.619048 0.666667 0.714286 0.761905 0.809524 0.857143 0.904762 0.952381 0 0.0454545 0.0909091 0.136364 0.181818 0.227273 0.272727 0.318182 0.363636 0.409091 0.454545 0.5 0.545455 0.590909 0.636364 0.681818 0.727273 0.772727 0.818182 0.863636 0.909091 0.954545 0 0.047619 0.0952381 0.142857 0.190476 0.238095 0.285714 0.333333 0.380952 0.428571 0.47619 0.52381 0.571429 0.619048 0.666667 0.714286 0.761905 0.809524 0.857143 0.904762 0.952381 0 0.0555556 0.111111 0.166667 0.222222 0.277778 0.333333 0.388889 0.444444 0.5 0.555556 0.611111 0.666667 0.722222 0.777778 0.833333 0.888889 0.944444 0 0.0555556 0.111111 0.166667 0.222222 0.277778 0.333333 0.388889 0.444444 0.5 0.555556 0.611111 0.666667 0.722222 0.777778 0.833333 0.888889 0.944444 0 0.047619 0.0952381 0.142857 0.190476 0.238095 0.285714 0.333333 0.380952 0.428571 0.47619 0.52381 0.571429 0.619048 0.666667 0.714286 0.761905 0.809524 0.857143 0.904762 0.952381 0 0.0714286 0.142857 0.214286 0.285714 0.357143 0.428571 0.5 0.571429 0.642857 0.714286 0.785714 0.857143 0.928571 0 0.0555556 0.111111 0.166667 0.222222 0.277778 0.333333 0.388889 0.444444 0.5 0.555556 0.611111 0.666667 0.722222 0.777778 0.833333 0.888889 0.944444 0 0.0666667 0.133333 0.2 0.266667 0.333333 0.4 0.466667 0.533333 0.6 0.666667 0.733333 0.8 0.866667 0.933333 0 0.03125 0.0625 0.09375 0.125 0.15625 0.1875 0.21875 0.25 0.28125 0.3125 0.34375 0.375 0.40625 0.4375 0.46875 0.5 0.53125 0.5625 0.59375 0.625 0.65625 0.6875 0.71875 0.75 0.78125 0.8125 0.84375 0.875 0.90625 0.9375 0.96875 0 0.0555556 0.111111 0.166667 0.222222 0.277778 0.333333 0.388889 0.444444 0.5 0.555556 0.611111 0.666667 0.722222 0.777778 0.833333 0.888889 0.944444 0 0.0555556 0.111111 0.166667 0.222222 0.277778 0.333333 0.388889 0.444444 0.5 0.555556 0.611111 0.666667 0.722222 0.777778 0.833333 0.888889 0.944444 0 0.0526316 0.105263 0.157895 0.210526 0.263158 0.315789 0.368421 0.421053 0.473684 0.526316 0.578947 0.631579 0.684211 0.736842 0.789474 0.842105 0.894737 0.947368 0 0.0909091 0.181818 0.272727 0.363636 0.454545 0.545455 0.636364 0.727273 0.818182 0.909091 0 0.0526316 0.105263 0.157895 0.210526 0.263158 0.315789 0.368421 0.421053 0.473684 0.526316 0.578947 0.631579 0.684211 0.736842 0.789474 0.842105 0.894737 0.947368 0 0.0434783 0.0869565 0.130435 0.173913 0.217391 0.26087 0.304348 0.347826 0.391304 0.434783 0.478261 0.521739 0.565217 0.608696 0.652174 0.695652 0.73913 0.782609 0.826087 0.869565 0.913043 0.956522 0 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 0.5 0.55 0.6 0.65 0.7 0.75 0.8 0.85 0.9 0.95 0 0.047619 0.0952381 0.142857 0.190476 0.238095 0.285714 0.333333 0.380952 0.428571 0.47619 0.52381 0.571429 0.619048 0.666667 0.714286 0.761905 0.809524 0.857143 0.904762 0.952381 0 0.0526316 0.105263 0.157895 0.210526 0.263158 0.315789 0.368421 0.421053 0.473684 0.526316 0.578947 0.631579 0.684211 0.736842 0.789474 0.842105 0.894737 0.947368 0 0.0555556 0.111111 0.166667 0.222222 0.277778 0.333333 0.388889 0.444444 0.5 0.555556 0.611111 0.666667 0.722222 0.777778 0.833333 0.888889 0.944444 0 0.0588235 0.117647 0.176471 0.235294 0.294118 0.352941 0.411765 0.470588 0.529412 0.588235 0.647059 0.705882 0.764706 0.823529 0.882353 0.941176 0 0.0588235 0.117647 0.176471 0.235294 0.294118 0.352941 0.411765 0.470588 0.529412 0.588235 0.647059 0.705882 0.764706 0.823529 0.882353 0.941176 0 0.0714286 0.142857 0.214286 0.285714 0.357143 0.428571 0.5 0.571429 0.642857 0.714286 0.785714 0.857143 0.928571 0 0.0526316 0.105263 0.157895 0.210526 0.263158 0.315789 0.368421 0.421053 0.473684 0.526316 0.578947 0.631579 0.684211 0.736842 0.789474 0.842105 0.894737 0.947368 0 0.0769231 0.153846 0.230769 0.307692 0.384615 0.461538 0.538462 0.615385 0.692308 0.769231 0.846154 0.923077 0 0.047619 0.0952381 0.142857 0.190476 0.238095 0.285714 0.333333 0.380952 0.428571 0.47619 0.52381 0.571429 0.619048 0.666667 0.714286 0.761905 0.809524 0.857143 0.904762 0.952381 0 0.047619 0.0952381 0.142857 0.190476 0.238095 0.285714 0.333333 0.380952 0.428571 0.47619 0.52381 0.571429 0.619048 0.666667 0.714286 0.761905 0.809524 0.857143 0.904762 0.952381 0 0.0588235 0.117647 0.176471 0.235294 0.294118 0.352941 0.411765 0.470588 0.529412 0.588235 0.647059 0.705882 0.764706 0.823529 0.882353 0.941176 0 0.0588235 0.117647 0.176471 0.235294 0.294118 0.352941 0.411765 0.470588 0.529412 0.588235 0.647059 0.705882 0.764706 0.823529 0.882353 0.941176 0 0.0555556 0.111111 0.166667 0.222222 0.277778 0.333333 0.388889 0.444444 0.5 0.555556 0.611111 0.666667 0.722222 0.777778 0.833333 0.888889 0.944444 0 0.0588235 0.117647 0.176471 0.235294 0.294118 0.352941 0.411765 0.470588 0.529412 0.588235 0.647059 0.705882 0.764706 0.823529 0.882353 0.941176 0 0.047619 0.0952381 0.142857 0.190476 0.238095 0.285714 0.333333 0.380952 0.428571 0.47619 0.52381 0.571429 0.619048 0.666667 0.714286 0.761905 0.809524 0.857143 0.904762 0.952381 0 0.0588235 0.117647 0.176471 0.235294 0.294118 0.352941 0.411765 0.470588 0.529412 0.588235 0.647059 0.705882 0.764706 0.823529 0.882353 0.941176 0 0.0526316 0.105263 0.157895 0.210526 0.263158 0.315789 0.368421 0.421053 0.473684 0.526316 0.578947 0.631579 0.684211 0.736842 0.789474 0.842105 0.894737 0.947368 0 0.047619 0.0952381 0.142857 0.190476 0.238095 0.285714 0.333333 0.380952 0.428571 0.47619 0.52381 0.571429 0.619048 0.666667 0.714286 0.761905 0.809524 0.857143 0.904762 0.952381 0 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 0.5 0.55 0.6 0.65 0.7 0.75 0.8 0.85 0.9 0.95 0 0.0555556 0.111111 0.166667 0.222222 0.277778 0.333333 0.388889 0.444444 0.5 0.555556 0.611111 0.666667 0.722222 0.777778 0.833333 0.888889 0.944444 0 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 0.5 0.55 0.6 0.65 0.7 0.75 0.8 0.85 0.9 0.95 0 0.0384615 0.0769231 0.115385 0.153846 0.192308 0.230769 0.269231 0.307692 0.346154 0.384615 0.423077 0.461538 0.5 0.538462 0.576923 0.615385 0.653846 0.692308 0.730769 0.769231 0.807692 0.846154 0.884615 0.923077 0.961538 0 0.0526316 0.105263 0.157895 0.210526 0.263158 0.315789 0.368421 0.421053 0.473684 0.526316 0.578947 0.631579 0.684211 0.736842 0.789474 0.842105 0.894737 0.947368 0 0.0555556 0.111111 0.166667 0.222222 0.277778 0.333333 0.388889 0.444444 0.5 0.555556 0.611111 0.666667 0.722222 0.777778 0.833333 0.888889 0.944444 0 0.0454545 0.0909091 0.136364 0.181818 0.227273 0.272727 0.318182 0.363636 0.409091 0.454545 0.5 0.545455 0.590909 0.636364 0.681818 0.727273 0.772727 0.818182 0.863636 0.909091 0.954545 0 0.0588235 0.117647 0.176471 0.235294 0.294118 0.352941 0.411765 0.470588 0.529412 0.588235 0.647059 0.705882 0.764706 0.823529 0.882353 0.941176 0 From cyril.mory at creatis.insa-lyon.fr Thu Jan 11 04:01:54 2018 From: cyril.mory at creatis.insa-lyon.fr (Cyril Mory) Date: Thu, 11 Jan 2018 10:01:54 +0100 Subject: [Rtk-users] problem while determining the interpolation weights in 4D ROOSTER Reconstruction In-Reply-To: <3dff8cae-3131-f9ce-6fc9-2ee1bc7f400b@creatis.insa-lyon.fr> References: <67C09C9C-1748-4508-B287-C15F769256D6@siat.ac.cn> <88BEDC3F-802B-4D7D-A627-C28A26D68ED5@siat.ac.cn> <66e33d08-af6f-0d34-d5c4-628ad91a157c@creatis.insa-lyon.fr> <5D207BEE-6153-4D53-BD0C-6CD67BE69149@siat.ac.cn> <469fa9e3-6104-f2fe-933c-8cb81f628db6@creatis.insa-lyon.fr> <66E4352A-AC64-4CFD-8DA0-E22BC5168E07@siat.ac.cn> <3dff8cae-3131-f9ce-6fc9-2ee1bc7f400b@creatis.insa-lyon.fr> Message-ID: Sorry, I made a mistake in the attached files. Ignore peaksOverShroud.png, I intended to send peaksOverOriginalShroud.png instead (the shroud.mhd you sent, overlaid with the sphase.txt you sent) so you can see how I cropped the shroud to improve the results of rtkextractshroudsignal. Regards Cyril On 11/01/2018 09:57, Cyril Mory wrote: > > Hi Ruoyan, > > > The original sphase.txt you sent a few days earlier does not look like > the Matlab plot you just sent. I guess you modified it in the > meantime. It does not matter much, but for one of the images I'm > sending, I've used your old sphase.txt. > > > I am not the best person to help you with your SimpleRTK problem. If > you're used to Matlab, let's go for that way. > > First, you can open your shroud image using Matlab, for example with > the function read_mhd() provided in MITK. See > http://mitk.org/wiki/The_Medical_Imaging_Interaction_Toolkit_(MITK) . > Second, to crop it using Matlab, simply keep the part where the > diaphragm motion is most visible (I removed the whole top part, wide > 285 pixels), then save the file back to croppedShroud.mhd, then rerun > phase extraction. > > > I have used another tool than Matlab to crop the image, but it > shouldn't matter. And I have rerun phase extraction, and generated the > overlay of peaks over shroud image in both cases. See the attached > pictures. Note that a few respiratory cycles have been missed by the > algorithm. You can try playing with parameters of > rtkextractshroudsignal, but those cycles will be hard to detect > anyway, since they correspond to irregular breathing (it looks like > the patient coughed). You can live with that, or modify the phase file > manually to add those cycles: the phase is nothing more than a number > that goes linearly from 0 to 1 between one peak and the next. > > I hope it helps, > Cyril > > On 11/01/2018 07:54, ry.meng wrote: >> Hi Cyril, >> >> The new code works fine, I still got some questions about sphase.txt >> file. >> When building simpleRTK, I met an error "error MSB6006: >> ?cmd.exe?exit?code 1", and I didn't find a solution. So I just plot >> sphase.txt with Matlab and compare it with respiration signals >> provided by raw data. They are quite different. I am not very clear >> about how to crop the shroud, can you share the method? Thanks a lot. >> >>>>>> Regards >>>>>> >>>>>> Ruoyan Meng >>>>>> >> >> On 1/10/2018 00:33?Cyril Mory >> wrote? >> >>> Ruoyan, >>> >>> >>> From the shroud image, the signal extraction sometimes fails to >>> find the period of the motion of the diaphragm, which results in >>> incorrect phase detection. The easiest way to make sure your >>> respiratory phase has been correctly detected is to used the >>> following python script: >>> >>> https://www.creatis.insa-lyon.fr/~mory/showPeaksOverShroud.py >>> >>> >>> You have to save your shroud image with .mhd extension, because >>> simpleRTK can't read .mha (I think), so modify the command line >>> that generates it (in the 4DROOSTER wiki page, that would be >>> >>> rtkamsterdamshroud--path . \ >>> --regexp '.*.his' \ >>> --output shroud.mha \ >>> --unsharp 650) >>> Change "shroud.mha" into "shroud.mhd", re-run all command lines >>> except the ROOSTER reconstruction, and then run >>> >>> "showPeaksOverShroud.py shroud.mhd sphase.txt" >>> >>> It will generate an RGB image named "peaksOverShroud.png", which >>> shows the shroud, and overlays the detected extrema of the >>> phase. If your detection is wrong, you'll see it. The script >>> requires SimpleRTK, python and a few python libs. >>> >>> If your peaks detection is indeed incorrect, you can try >>> cropping the shroud to the region where the periodic signal is >>> most visible. This is usually sufficient. If you need more help, >>> send over your shroud.mhd and shroud.raw file. >>> >>> Regards, >>> Cyril >>> >>> On 09/01/2018 15:47, ry.meng wrote: >>>> Hi Cyril, >>>> >>>> The attachment is our projections.mhdfile and we are running >>>> the latest RTK, example data works well. >>>> I have another question about our sphase.txt file. As my >>>> understanding of 4D reconstruction process, spase.txt file >>>> should be the?optimal fit respiration signals. But in our file, >>>> it only has 6 cycles, which is impossible, it confused me. >>>> I'm now testing your new code with our data, hope it works! >>>> Thanks for your help. >>>>>> >>>>>> >>>>>> Regards >>>>>> >>>>>> Ruoyan Meng >>>>>> >>>> On 1/9/2018 20:48?Cyril Mory >>>> wrote? >>>> >>>> Hi again Ruoyan, >>>> >>>> >>>> I have investigated further and found the source of the >>>> problem: the code performs a rounding of the phase signal >>>> to two digits, which for some values of your phase ended up >>>> to be 1. And the rest of the code assumes that the phase >>>> belongs to [0; 1[, i.e. there should never be a value 1. >>>> The rounding is useful for optimization: projections with >>>> identical phases can be forward and backprojected together, >>>> which is faster than one-by-one, and with high-precision >>>> phase values, there are never two equal phase values. >>>> >>>> >>>> So I just fixed the bug by setting the phase to 0 when its >>>> rounding is equal to 1, which should do the trick. The pull >>>> request is being tested, it should be merged soon. >>>> >>>> >>>> Thanks for reporting your issue. >>>> >>>> Regards, >>>> >>>> Cyril >>>> >>>> >>>> On 09/01/2018 11:31, Cyril Mory wrote: >>>>> >>>>> Hi Ruoyan, >>>>> >>>>> >>>>> I've had a look at your file sphase.txt, it looks >>>>> perfectly fine to me. The problem must lie elsewhere. Does >>>>> the application 4D ROOSTER work with the example data >>>>> provided on the wiki ? If it does, then the problem lies >>>>> in your data. In that case, please run >>>>> >>>>> >>>>> rtkprojections --path D:\bd\20171116 --regexp .*.his >>>>> -oD:\bd\20171116\projections.mhd >>>>> >>>>> >>>>> and send us the "projections.mhd" file. It will contain >>>>> only the metadata of your projections, and we'll be able >>>>> to run the same command line as you and try to reproduce >>>>> the problem. >>>>> >>>>> >>>>> If, on the other hand, it doesn't even work with the >>>>> example data provided on the wiki, it is a software >>>>> problem. In that case, can you first update to the latest >>>>> RTK (the git master branch), recompile and test again ? >>>>> >>>>> >>>>> Best regards, >>>>> >>>>> Cyril >>>>> >>>>> >>>>> On 26/12/2017 10:47, ry.meng wrote: >>>>>> Hi >>>>>> >>>>>> Thank you for your reply. I have checked the value in >>>>>> sphase.txt and don't have any value larger or equal to 5. >>>>>> Maybe the problem lies elsewhere? Thanks. >>>>>> >>>>>> Regards >>>>>> >>>>>> Ruoyan Meng >>>>>> >>>>>> On 12/26/2017 17:14?Simon >>>>>> Rit >>>>>> wrote? >>>>>> >>>>>> Hi, >>>>>> If you look at the code >>>>>> , >>>>>> you'll see that the error message corresponds to the >>>>>> case where you have a phase which equals the number >>>>>> of frames. This cannot be since it is 0-based. In >>>>>> other words, with the option "--frames 5", you cannot >>>>>> have a value larger or equal to 5 in your file >>>>>> sphase.txt. >>>>>> Simon >>>>>> >>>>>> On Mon, Dec 25, 2017 at 9:36 AM, ry.meng >>>>>> > wrote: >>>>>> >>>>>> >>>>>> Hi: >>>>>> When I tried ?the application of 4D ROOSTER >>>>>> Reconstruction with my own data, it will stop for >>>>>> the following reason: problem while determining >>>>>> the interpolation weights. Maybe you guys have >>>>>> met this problem before and have a solution for >>>>>> it.?Thank you very much and I hope to receive >>>>>> your reply soon. >>>>>> >>>>>> >>>>>> Happy Holidays! >>>>>> >>>>>> >>>>>> Regards >>>>>> >>>>>> Ruoyan Meng >>>>>> >>>>>> ------------------------------------------------------------------------------------------ >>>>>> >>>>>> Research Center for Medical Robotics and >>>>>> Minimally Invasive Surgical Devices, >>>>>> Institute of Biomedical and Health Engineering, >>>>>> Shenzhen Institutes of Advanced Technology, >>>>>> Chinese Academy of Sciences >>>>>> Tel: +86-18576617767 >>>>>> Email: ry.meng at siat.ac.cn >>>>>> Zip:? ? ? ?518055 >>>>>> Add: No. 1068 Xueyuan Avenue, Nanshan, Shenzhen, >>>>>> China >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>> >> > > > > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: peaksOverOriginalShroud.png Type: image/png Size: 329838 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Tue Jan 16 12:42:09 2018 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 16 Jan 2018 18:42:09 +0100 Subject: [Rtk-users] rtk user : FDKConeBeamReconstructionFilter In-Reply-To: References: Message-ID: Hi Elena, Please post your questions to the mailing list, they can interest everyone in the community and you may get (better) answers before mine. FDK is very simple: it takes the projections, weight them with the cosine + angular gaps, apply the ramp filter with a kernel adapted to the number of pixels and backproject. The backprojection is voxel based so it does a linear interpolation between pixels. There is never any attemps to "adjust" one of these steps according to the pixel and the voxel spacings so the user must manage it. There are different solutions to do it: - do a binning of the projections (average 4 or 16 pixels as you maybe did?). In the command line tool, you can do it with the --binning option. - cut high frequencies during ramp filtering using --hann and --hannY options This is assuming larger voxels than pixels (there is no reason to have smaller voxels than pixels). Let me know if this does not answer your question. Simon On Tue, Jan 16, 2018 at 11:08 AM, Elena Padovani wrote: > Dear Simon, > I am a new user of the Reconstruction toolkit. I've been testing some > tools lately and i was able to reconstruct using > FDKConeBeamReconstructionFilter. I am now trying to figure out something > more about it and i was wondering if you could help me understand how > rtkFDKConeBeamReconstructionFilter works. > > I am now reading raw images and importing them into the pipeline through > the importFilter and then a tilerFilter is used to create the stack of > projections. i was testing if the reconstructed volume would change using > as input to rtkFDKConeBeamReconstructionFilter images of different > resolutions. More precisely, i tested 2 cases: > - 1) the input images are 1536x1536 with spacing 0.2,0.2 and the > ConstantImageSource volume is 384,384,384 with spacing 0.8,0.8,0.8 > - 2) the input images are scaled-down to 384,384 with spacing 0.8,0.8 and > the constantImageSource is again 384,384,384 with spacing 0.8,0.8,0.8 > The reconstructed volumes appear to be different. Indeed, the range of > values is quite different and in the first case the image does not seem > totally right (even tough the volume is reconstructed). Can you explain me > how rtkFDKConeBeamReconstructionFilter (or maybe other filters used > inside, such as ExtractImageFIlter) manages different resolution in input > and output ? Does it average the pixel value over the bigger voxel/pixel > area ? > > Thank you in advance for any hint, > Kind regards, > > Elena > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Wed Jan 17 08:34:57 2018 From: wuchao04 at gmail.com (Chao Wu) Date: Wed, 17 Jan 2018 14:34:57 +0100 Subject: [Rtk-users] rtk user : FDKConeBeamReconstructionFilter In-Reply-To: References: Message-ID: Hi Simon, I have related questions. Maybe you or someone else has some empirical experience or something like a rule of thumb: We talk about voxels and pixels of a virtual detector at isocenter, so no influence from geometrical magnification. Then we can say that the best practice would be setting voxel size similar to the pixel size. My questions are: - If you are going to use a bigger voxel size as an arbitrary times of pixel size such as 1.5x, 2.7x or 6.2x, how do you determine whether you should do a binning of the detector images and which binning factor is optimal? Should you always make the binned pixel size just bigger or smaller than the voxel size (so for the example before you use 2x2, 3x3 and 7x7 binning, or 1x1, 2x2 and 6x6, respectively)? - Instead of detector binning, another solution may be using an upsampled voxel grid for reconstruction and then do the binning on the 3D volume. For example you may reconstruct a volume in a 2x2x2 finner grid and then perform a 2x2x2 binning to the output, if the voxel size is about 2 times of the pixel size. Despite that the amount of computation is 8 times higher, is there any obvious benefit (resolution, contrast, S/N etc.) under this scheme? Best regards, Chao 2018-01-16 18:42 GMT+01:00 Simon Rit : > Hi Elena, > Please post your questions to the mailing list, they can interest everyone > in the community and you may get (better) answers before mine. > FDK is very simple: it takes the projections, weight them with the cosine > + angular gaps, apply the ramp filter with a kernel adapted to the number > of pixels and backproject. The backprojection is voxel based so it does a > linear interpolation between pixels. There is never any attemps to "adjust" > one of these steps according to the pixel and the voxel spacings so the > user must manage it. There are different solutions to do it: > - do a binning of the projections (average 4 or 16 pixels as you maybe > did?). In the command line tool, you can do it with the --binning option. > - cut high frequencies during ramp filtering using --hann and --hannY > options > This is assuming larger voxels than pixels (there is no reason to have > smaller voxels than pixels). > Let me know if this does not answer your question. > Simon > > On Tue, Jan 16, 2018 at 11:08 AM, Elena Padovani > wrote: > >> Dear Simon, >> I am a new user of the Reconstruction toolkit. I've been testing some >> tools lately and i was able to reconstruct using >> FDKConeBeamReconstructionFilter. I am now trying to figure out something >> more about it and i was wondering if you could help me understand how >> rtkFDKConeBeamReconstructionFilter works. >> >> I am now reading raw images and importing them into the pipeline through >> the importFilter and then a tilerFilter is used to create the stack of >> projections. i was testing if the reconstructed volume would change using >> as input to rtkFDKConeBeamReconstructionFilter images of different >> resolutions. More precisely, i tested 2 cases: >> - 1) the input images are 1536x1536 with spacing 0.2,0.2 and the >> ConstantImageSource volume is 384,384,384 with spacing 0.8,0.8,0.8 >> - 2) the input images are scaled-down to 384,384 with spacing 0.8,0.8 and >> the constantImageSource is again 384,384,384 with spacing 0.8,0.8,0.8 >> The reconstructed volumes appear to be different. Indeed, the range of >> values is quite different and in the first case the image does not seem >> totally right (even tough the volume is reconstructed). Can you explain me >> how rtkFDKConeBeamReconstructionFilter (or maybe other filters used >> inside, such as ExtractImageFIlter) manages different resolution in input >> and output ? Does it average the pixel value over the bigger voxel/pixel >> area ? >> >> Thank you in advance for any hint, >> Kind regards, >> >> Elena >> >> > > _______________________________________________ > 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: From simon.rit at creatis.insa-lyon.fr Thu Jan 18 11:31:46 2018 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 18 Jan 2018 17:31:46 +0100 Subject: [Rtk-users] rtk user : FDKConeBeamReconstructionFilter In-Reply-To: References: Message-ID: Hi, My experience is too limited to have a good answer. This is probably very task dependent. There are papers on the question of binning: https://doi.org/10.1088/0031-9155/58/5/1433 I don't know of people considering binning of the volume except for iterative reconstruction https://doi.org/10.1088/0031-9155/49/1/010 Maybe others have an opinion? Simon On Wed, Jan 17, 2018 at 2:34 PM, Chao Wu wrote: > Hi Simon, > > I have related questions. Maybe you or someone else has some empirical experience > or something like a rule of thumb: > > We talk about voxels and pixels of a virtual detector at isocenter, so no > influence from geometrical magnification. > Then we can say that the best practice would be setting voxel size similar > to the pixel size. > > My questions are: > > - If you are going to use a bigger voxel size as an arbitrary times of > pixel size such as 1.5x, 2.7x or 6.2x, how do you determine whether you > should do a binning of the detector images and which binning factor is > optimal? Should you always make the binned pixel size just bigger or > smaller than the voxel size (so for the example before you use 2x2, 3x3 and > 7x7 binning, or 1x1, 2x2 and 6x6, respectively)? > > - Instead of detector binning, another solution may be using an upsampled > voxel grid for reconstruction and then do the binning on the 3D volume. For > example you may reconstruct a volume in a 2x2x2 finner grid and then > perform a 2x2x2 binning to the output, if the voxel size is about 2 times > of the pixel size. Despite that the amount of computation is 8 times > higher, is there any obvious benefit (resolution, contrast, S/N etc.) under > this scheme? > > Best regards, > Chao > > > 2018-01-16 18:42 GMT+01:00 Simon Rit : > >> Hi Elena, >> Please post your questions to the mailing list, they can interest >> everyone in the community and you may get (better) answers before mine. >> FDK is very simple: it takes the projections, weight them with the cosine >> + angular gaps, apply the ramp filter with a kernel adapted to the number >> of pixels and backproject. The backprojection is voxel based so it does a >> linear interpolation between pixels. There is never any attemps to "adjust" >> one of these steps according to the pixel and the voxel spacings so the >> user must manage it. There are different solutions to do it: >> - do a binning of the projections (average 4 or 16 pixels as you maybe >> did?). In the command line tool, you can do it with the --binning option. >> - cut high frequencies during ramp filtering using --hann and --hannY >> options >> This is assuming larger voxels than pixels (there is no reason to have >> smaller voxels than pixels). >> Let me know if this does not answer your question. >> Simon >> >> On Tue, Jan 16, 2018 at 11:08 AM, Elena Padovani >> wrote: >> >>> Dear Simon, >>> I am a new user of the Reconstruction toolkit. I've been testing some >>> tools lately and i was able to reconstruct using >>> FDKConeBeamReconstructionFilter. I am now trying to figure out >>> something more about it and i was wondering if you could help me understand >>> how rtkFDKConeBeamReconstructionFilter works. >>> >>> I am now reading raw images and importing them into the pipeline through >>> the importFilter and then a tilerFilter is used to create the stack of >>> projections. i was testing if the reconstructed volume would change using >>> as input to rtkFDKConeBeamReconstructionFilter images of different >>> resolutions. More precisely, i tested 2 cases: >>> - 1) the input images are 1536x1536 with spacing 0.2,0.2 and the >>> ConstantImageSource volume is 384,384,384 with spacing 0.8,0.8,0.8 >>> - 2) the input images are scaled-down to 384,384 with spacing 0.8,0.8 >>> and the constantImageSource is again 384,384,384 with spacing 0.8,0.8,0.8 >>> The reconstructed volumes appear to be different. Indeed, the range of >>> values is quite different and in the first case the image does not seem >>> totally right (even tough the volume is reconstructed). Can you explain me >>> how rtkFDKConeBeamReconstructionFilter (or maybe other filters used >>> inside, such as ExtractImageFIlter) manages different resolution in input >>> and output ? Does it average the pixel value over the bigger voxel/pixel >>> area ? >>> >>> Thank you in advance for any hint, >>> Kind regards, >>> >>> Elena >>> >>> >> >> _______________________________________________ >> 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: From anais.capouillez at student.uliege.be Mon Jan 29 06:03:45 2018 From: anais.capouillez at student.uliege.be (anais.capouillez at student.uliege.be) Date: Mon, 29 Jan 2018 12:03:45 +0100 (CET) Subject: [Rtk-users] Problems with --like and --dimension parameters of rtkforwardprojections and rtkfdk Message-ID: <2005346943.3159112.1517223825247.JavaMail.zimbra@student.uliege.be> Hi, My name is Ana?s, I?m a student in computer sciences, and I'm currently doing my internship, which consists partly to do a tomographic reconstruction. I use rtk to reconstruct my model, but I have problems when I use rtkforwardprojections and rtkfdk with ?like or ?dimension. Indeed, if I use them with the default parameters, it works correctly, but when I specify ?like or certain values of ?dimension the reconstruction isn?t correct. For instance if I use the example file muCT.mha as my model, it works perfectly with the default parameters, but if I choose ?like=muCT.mha, in my reconstruction file there are mostly black voxels. I also saw that the example in the scripts for forward projections (http://wiki.openrtk.org/index.php/RTK/Scripts/ForwardProjection) works when the spacing, the origin, and the dimension specified to rtkfdk are the same than the model. I wanted to know why it doesn?t works when I use ?like. Is there a relation between the geometry and dimensions and that?s why I have problems (for instance due to the source being too close to the object)? Thank you very much. Ana?s From simon.rit at creatis.insa-lyon.fr Mon Jan 29 06:33:20 2018 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 29 Jan 2018 12:33:20 +0100 Subject: [Rtk-users] Problems with --like and --dimension parameters of rtkforwardprojections and rtkfdk In-Reply-To: <2005346943.3159112.1517223825247.JavaMail.zimbra@student.uliege.be> References: <2005346943.3159112.1517223825247.JavaMail.zimbra@student.uliege.be> Message-ID: Hi Anais, It's a bit hard to check what's going on without the command lines. Can you try to send the command lines that give you some problems, e.g. based on the forwardprojection example? Thanks, Simon On Mon, Jan 29, 2018 at 12:03 PM, wrote: > Hi, > > My name is Ana?s, I?m a student in computer sciences, and I'm currently > doing my internship, which consists partly to do a tomographic > reconstruction. > > I use rtk to reconstruct my model, but I have problems when I use > rtkforwardprojections and rtkfdk with ?like or ?dimension. > Indeed, if I use them with the default parameters, it works correctly, but > when I specify ?like or certain values of ?dimension the reconstruction > isn?t correct. > For instance if I use the example file muCT.mha as my model, it works > perfectly with the default parameters, but if I choose ?like=muCT.mha, in > my reconstruction file there are mostly black voxels. > I also saw that the example in the scripts for forward projections ( > http://wiki.openrtk.org/index.php/RTK/Scripts/ForwardProjection) works > when the spacing, the origin, and the dimension specified to rtkfdk are the > same than the model. > > I wanted to know why it doesn?t works when I use ?like. > Is there a relation between the geometry and dimensions and that?s why I > have problems (for instance due to the source being too close to the > object)? > > > Thank you very much. > > Ana?s > _______________________________________________ > 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: From anais.capouillez at student.uliege.be Mon Jan 29 09:20:35 2018 From: anais.capouillez at student.uliege.be (anais.capouillez at student.uliege.be) Date: Mon, 29 Jan 2018 15:20:35 +0100 (CET) Subject: [Rtk-users] Problems with --like and --dimension parameters of rtkforwardprojections and rtkfdk In-Reply-To: References: <2005346943.3159112.1517223825247.JavaMail.zimbra@student.uliege.be> Message-ID: <2031371115.3293941.1517235635975.JavaMail.zimbra@student.uliege.be> Hi Simon, I have just redone an analysis and everything went through with no issue. My advisor and I probably messed up the values of spacing and/or dimension when we used the rtkforwardprojections. Thank you for the quick reply and sorry for wasting a little bit of your time. Best regards. Ana?s ----- Mail original ----- De: "Simon Rit" ?: "anais capouillez" Cc: rtk-users at public.kitware.com Envoy?: Lundi 29 Janvier 2018 12:33:20 Objet: Re: [Rtk-users] Problems with --like and --dimension parameters of rtkforwardprojections and rtkfdk Hi Anais, It's a bit hard to check what's going on without the command lines. Can you try to send the command lines that give you some problems, e.g. based on the forwardprojection example? Thanks, Simon On Mon, Jan 29, 2018 at 12:03 PM, wrote: > Hi, > > My name is Ana?s, I?m a student in computer sciences, and I'm currently > doing my internship, which consists partly to do a tomographic > reconstruction. > > I use rtk to reconstruct my model, but I have problems when I use > rtkforwardprojections and rtkfdk with ?like or ?dimension. > Indeed, if I use them with the default parameters, it works correctly, but > when I specify ?like or certain values of ?dimension the reconstruction > isn?t correct. > For instance if I use the example file muCT.mha as my model, it works > perfectly with the default parameters, but if I choose ?like=muCT.mha, in > my reconstruction file there are mostly black voxels. > I also saw that the example in the scripts for forward projections ( > http://wiki.openrtk.org/index.php/RTK/Scripts/ForwardProjection) works > when the spacing, the origin, and the dimension specified to rtkfdk are the > same than the model. > > I wanted to know why it doesn?t works when I use ?like. > Is there a relation between the geometry and dimensions and that?s why I > have problems (for instance due to the source being too close to the > object)? > > > Thank you very much. > > Ana?s > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > https://public.kitware.com/mailman/listinfo/rtk-users >