Hi, Thanks for sharing. There still seems to be some streak artefacts, do you see the same in the Varian reconstruction? I'm looking forward to the pull-request, I think we should try to make the bzip2 optional. Simon
On Fri, Sep 16, 2016 at 10:37 PM, Andreas Gravgaard Andersen < andre...@phys.au.dk> wrote: > Thanks for the fast response Simon! > > I flipped the angles (360 - angle[deg]) and it worked! Thanks, you were > right all along! > I just didn't get why it makes a difference. I think I do now, as the > resulting image was flipped upside down and not left/right as I expected. > [attached] > > The reconstruction is significantly better, I'll look into what should be > included in the reader and what I should keep in my program to keep > conformity with the other readers. Then I'll create a pull request. > > Just for the purpose of others hitting the same or a similar bug, I also > attempted: > I did the SART reconstruction with 10 iterations, lambda=0.3, and Joseph > back/forward projection, *but with no* significant improvement [attached] > > And: > If you want you can download the data set from: [Dropbox link to 460MB zip > <https://www.dropbox.com/s/hg2k50vw3f7bt4b/CatPhan.zip?dl=0> (I'll keep > it up as long as Dropbox allows me)] Only the Acquisitions/subfolder is > used along with the Scan.xml (Calibrations folder may be used in the future > in my program, but I'm not sure if you can rely on the existence of the > content). > > A MatLab XimReader is available: link > <https://github.com/agravgaard/RTK/blob/master/code/ReadXim.m> (also > available from Varian bitbucket along a with a python version and a > C#->matlab plugin > <https://bitbucket.org/dmoderesearchtools/ximreader/downloads>). > Otherwise my fork with the RTK-style reader is available from the same > repository (I have also added Hnc support, thanks to the Geoff Hugo fork, > so bzip2 is a new dependancy). > > Best regards > Andreas > > > __________________________________ > > Andreas Gravgaard Andersen > > Department of Oncology, > > Aarhus University Hospital > > Nørrebrogade 44, > > 8000, Aarhus C > > Mail: andre...@phys.au.dk > > Cell: +45 3165 8140 > > > > 2016-09-16 16:13 GMT+02:00 Simon Rit <simon....@creatis.insa-lyon.fr>: > >> Hi, >> You can try any iterative reconstruction, they can also handle short >> scans. Start with a few iterations of rtksart or rtkconjugategradient. >> However, the nature of the artifacts indicate more a problem in the >> geometry in my opinion. I have seen such errors when, for example, rotating >> in the wrong direction. I can have a look if you share the dataset. >> Cheers, >> Simon >> >> On Fri, Sep 16, 2016 at 2:56 PM, Andreas Gravgaard Andersen < >> andre...@phys.au.dk> wrote: >> >>> Thanks for the suggestions, Simon and Cyril! >>> >>> I have been carefully looking though the geometry and from what I >>> understand of the transformations matrices, the geometry looks correct/(as >>> expected). >>> >>> HOWEVER: I found out that the reason for the Hnd to behave differently >>> were because had used half-fan scans (full-arc). >>> When I used a full-fan (half-arc) scan of Hnd projections the same >>> artifacts occurs! >>> >>> Are there other (built-in) means of improving half-arc scans, than the >>> parker short scan filter? >>> >>> Parker short scan does a decent job, but the result is still far from >>> the quality of the Varian software reconstruction at least for the CatPhan. >>> >>> Best regards >>> Andreas >>> >>> >>> __________________________________ >>> >>> Andreas Gravgaard Andersen >>> >>> Department of Oncology, >>> >>> Aarhus University Hospital >>> >>> Nørrebrogade 44, >>> >>> 8000, Aarhus C >>> >>> Mail: andre...@phys.au.dk >>> >>> Cell: +45 3165 8140 >>> >>> >>> >>> 2016-09-14 9:10 GMT+02:00 Cyril Mory <cyril.m...@creatis.insa-lyon.fr>: >>> >>>> One suggestion since it works with the Hnd projections: >>>> You can run rtkprojections twice (with the Hnd projections, then with >>>> Xim projections) and output two projection stack files and two geometry >>>> files, then compare the projection stack files by subtracting one to the >>>> other (with SimpleRTK or clitk) and the geometry files with diff. If they >>>> are identical, then I do not see any reason why the reconstructions should >>>> be different, so my guess is that you will find differences. >>>> >>>> >>>> On 09/13/2016 10:18 PM, Simon Rit wrote: >>>> >>>>> Hi, >>>>> I have almost never worked with Varian data but it looks like a >>>>> geometry problem. Maybe the problem comes from a bad ordering of the >>>>> projections which results in assigning a bad geometry to each >>>>> projection. How did you name your projections? Maybe check that the >>>>> order matches that of the RTK geometry file. Otherwise, there might be >>>>> an issue in the creation of the geometry file itself. >>>>> All this sounds good, happy bug hunt and don't hesitate to share your >>>>> code when you feel it's ready. >>>>> Simon >>>>> >>>>> On Tue, Sep 13, 2016 at 7:06 PM, Andreas Gravgaard Andersen >>>>> <andre...@phys.au.dk> wrote: >>>>> >>>>>> Dear RTK experts, >>>>>> >>>>>> I am reconstructing Varian ProBeam projections of the Xim image >>>>>> format. I >>>>>> have written the reader myself - very similar to the Hnd one already >>>>>> available with RTK. >>>>>> Links to my fork: [XimReader, XMLReader, GeometryReader] >>>>>> >>>>>> The reader apparently works (Images and angles displays as expected >>>>>> in UI), >>>>>> however when reconstructing with a regular FDK I get a reconstructed >>>>>> image >>>>>> that is smeared out around the high and low density areas [see >>>>>> attached >>>>>> image] >>>>>> >>>>>> I'm using half arc, full fan images with no bow-tie filter from >>>>>> Scripps >>>>>> (~520 projections). Fixed detector and source (offset=0) with SID=2m, >>>>>> SDD=3m. >>>>>> >>>>>> For the Hnd projections the reconstruction works perfectly (Same >>>>>> algorithm). >>>>>> The reconstruction of the Xim projections performed on Varian >>>>>> software works >>>>>> perfectly. >>>>>> >>>>>> Without the Parker Short Scan Filter the first and last projections >>>>>> creates >>>>>> streaks across the reconstruction as if they were way too bright. >>>>>> If the first few projections are excluded, the following projection >>>>>> will act >>>>>> the same way. >>>>>> >>>>>> The projections are corrected for beam hardening and all the >>>>>> projections >>>>>> have the expected attenuation. >>>>>> No "smearing" filters (like median) is used, and iterative >>>>>> reconstruction >>>>>> makes the same artifacts. >>>>>> >>>>>> Setting the value of the first and last projection to zero has the >>>>>> same >>>>>> effect as excluding. Changing the ramp filter only changes noise, not >>>>>> the >>>>>> artifacts. >>>>>> >>>>>> Have any of you had a similar problem? Am I missing something? >>>>>> Any suggestions are welcome I'm running out of ideas. >>>>>> >>>>>> Best regards >>>>>> Andreas >>>>>> >>>>>> __________________________________ >>>>>> >>>>>> Andreas Gravgaard Andersen >>>>>> >>>>>> Department of Oncology, >>>>>> >>>>>> Aarhus University Hospital >>>>>> >>>>>> Nørrebrogade 44, >>>>>> >>>>>> 8000, Aarhus C >>>>>> >>>>>> Mail: andre...@phys.au.dk >>>>>> >>>>>> Cell: +45 3165 8140 >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Rtk-users mailing list >>>>>> Rtk-users@public.kitware.com >>>>>> http://public.kitware.com/mailman/listinfo/rtk-users >>>>>> >>>>>> _______________________________________________ >>>>> Rtk-users mailing list >>>>> Rtk-users@public.kitware.com >>>>> http://public.kitware.com/mailman/listinfo/rtk-users >>>>> >>>>> >>>> >>> >> >
_______________________________________________ Rtk-users mailing list Rtk-users@public.kitware.com http://public.kitware.com/mailman/listinfo/rtk-users