[Rtk-users] Fwd: Have you encountered this artifact?

Fri Nov 25 10:25:55 EST 2016

Dear Simon,

I have created a pull-request with the XIM file reader.
I'm sorry for being late with the promised pull-request (there were a lot
of merge conflicts, so it got postponed).

I have cleaned it up, but it is still not flawless as mentioned in the
pull-request-message.
I have tried to keep the RTK coding-style by creating it as a modified HND
file reader, but I have only a year of experience with C++, so I apologize
if I've left some ugly code in there..

Best regards
Andreas

__________________________________

Andreas Gravgaard Andersen

Department of Oncology,

Aarhus University Hospital

Nørrebrogade 44,

8000, Aarhus C

Mail:     andreasg at phys.au.dk

Cell:      +45 3165 8140

2016-11-23 18:44 GMT+01:00 Simon Rit <simon.rit at creatis.insa-lyon.fr>:

> Dear Andreas,
> Today we had the RTK training and some users were looking for a XIM file
> reader. I pointed to your contributions but any chance to have it put in
> RTK soon?
> Thanks in advance,
> Simon
>
> On Mon, Sep 19, 2016 at 9:26 AM, Simon Rit <simon.rit at creatis.insa-lyon.fr
> > wrote:
>
>> 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 <
>> andreasg at 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:     andreasg at phys.au.dk
>>>
>>> Cell:      +45 3165 8140
>>>
>>>
>>>
>>> 2016-09-16 16:13 GMT+02:00 Simon Rit <simon.rit at 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 <
>>>> andreasg at 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:     andreasg at phys.au.dk
>>>>>
>>>>> Cell:      +45 3165 8140
>>>>>
>>>>>
>>>>>
>>>>> 2016-09-14 9:10 GMT+02:00 Cyril Mory <cyril.mory at 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
>>>>>>> <andreasg at 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:     andreasg at phys.au.dk
>>>>>>>>
>>>>>>>> Cell:      +45 3165 8140
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Rtk-users mailing list
>>>>>>>> Rtk-users at public.kitware.com
>>>>>>>> http://public.kitware.com/mailman/listinfo/rtk-users
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>> Rtk-users mailing list
>>>>>>> Rtk-users at public.kitware.com
>>>>>>> http://public.kitware.com/mailman/listinfo/rtk-users
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20161125/1fea4797/attachment-0010.html>