[Rtk-users] Fwd: Have you encountered this artifact?
Simon Rit
simon.rit at creatis.insa-lyon.fr
Thu Dec 1 00:59:17 EST 2016
Hi,
Thanks a lot! It's been merged after minor modifications but would you
have one projection to share for creating a small test?
You seemed to be unsure of the offsets sign, I think that a wrong sign
would show up on the reconstructions. I would suggest to test it if
you have time.
Simon
On Fri, Nov 25, 2016 at 4:25 PM, Andreas Gravgaard Andersen
<andreasg at phys.au.dk> wrote:
> 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 (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 (also available from Varian
>>>> bitbucket along a with a python version and a C#->matlab plugin). 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
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
More information about the Rtk-users
mailing list