[Rtk-users] Sophia beads reconstruction

Tue Feb 9 09:39:04 EST 2016

Hi Simon,

thank you for your code. Unfortunately, I can not work on this any longer.
I hope it will be useful for someone else.

Cheers,
MG

2016-02-05 9:32 GMT-05:00 Simon Rit <simon.rit at creatis.insa-lyon.fr>:

> Hi MG,
> Sorry, I realized I said something stupid. Using tif or mha won't make any
> difference because there is a branching on the pixel type in the
> projectionsreader
> <http://www.openrtk.org/Doxygen/classrtk_1_1ProjectionsReader.html>
> (search for ushort in the graph of the doxygen doc
> <http://www.openrtk.org/Doxygen/classrtk_1_1ProjectionsReader.html>) and
> unsigned short are handled differently.
> The enclosed pyhon code will reproduce the same as my previous command
> line application. The commented code in it is what I initially used to read
> projections without any processing, i.e., assuming line integrals.
> I still think there is a problem in the geometry but someone (you?) has to
> spend sometime trying to understand what are the parameters from the Matlab
> code.
> Keep us posted and good luck,
> Simon
>
>
> On 28/01/2016 22:27, MG Vallet wrote:
>
> Louie,
> I played with sdd and sid, following your advise. But they have few
> effect, clearly less effect than proj_iso_x. And none of these parameters
> can significantly improve my result.
>
> Simon,
> I carefully checked every input data and I cant see what I did wrong. I
> want first to reproduce your output. You said earlier it's easy to convert
> a series of tiff image into a mha file using SimpleRTK. Do you mean by
> writing a short program, or is it possible from the command line ?
>
> MG
>
> 2016-01-26 17:17 GMT-05:00 louie L <ghostcz at hotmail.com>:
>
>> Hi MG,
>>
>>
>>
>> Sometimes, the progressive deformation from the center of rotation to the
>> edge of the image is caused by wrong sdd/sid ratio. Such as change in the
>> geometry will lead to distortion of the image and wrong magnification.
>>
>> Maybe you can play with that parameter and report your result.
>>
>>
>>
>> Cheers,
>>
>> Louie
>>
>>
>>
>> Sent from Mail <http://go.microsoft.com/fwlink/?LinkId=550986> for
>> Windows 10
>>
>>
>>
>>
>> *From: *Simon Rit <simon.rit at creatis.insa-lyon.fr>
>> *Sent: *Tuesday, January 26, 2016 13:24
>> *To: *MG Vallet <mgvallet.pro at gmail.com>
>> *Cc: *rtk-users at public.kitware.com
>> *Subject: *Re: [Rtk-users] Sophia beads reconstruction
>>
>>
>>
>> Hi,
>>
>> I think it's likely a problem with parameters. The best would be to
>> obtain them from the Matlab code they provide.
>>
>> Good luck,
>>
>> Simon
>>
>>
>>
>> On Mon, Jan 25, 2016 at 5:48 PM, MG Vallet < <mgvallet.pro at gmail.com>
>> mgvallet.pro at gmail.com> wrote:
>>
>> Hi Simon,
>>
>>
>>
>> this was a point I missed. I had to do the log mapping.
>>
>>
>>
>> I must say, I do not use RTK from shell. I just plugged the objects
>>
>> FDKConeBeamReconstructionFilter and ThreeDCircularProjectionGeometry from
>> RTK into a visualisation software. That's the reason I'm not absolutely
>> sure about the length parameter setting.
>>
>>
>>
>> Anyway, I'm now pretty close to your result. I believe the only
>> difference is the progressive deformation of beads with the distance to
>> center.
>>
>>
>>
>> What's your opinion : is there another step I might have missed, or is it
>> more likely a problem with parameters ?
>>
>>
>>
>> MG
>>
>>
>>
>> 2016-01-21 14:22 GMT-05:00 Simon Rit < <simon.rit at creatis.insa-lyon.fr>
>> simon.rit at creatis.insa-lyon.fr>:
>>
>> Not exactly. rtk::FDKConeBeamProjectionFilter assumes that you pass the
>> line integral (ln(I0/I)). But rtkfdk uses the ProjectionsReader to read the
>> projections and converts them depending on the type: for mha or mhd, it
>> just reads it and nothing else. For tif, it assumes that I is passed, try
>> to guess I0 (or gets it from the cmd line) and computes ln(I0/I).
>> So from each tif projection, instead of letting them go through the
>> ProjectionsReader in RTK, directly use the ImageReader, stack them and pass
>> it to the reconstruction algorithm. In other words, if you use SimpleRTK,
>> use ImageSeriesReader instead of ProjectionsReader.
>> Regarding the geometry, it would be nice to be confident in the geometry
>> parameters, maybe from their Matlab code?
>> Simon
>>
>>
>>
>> On 21/01/2016 20:02, MG Vallet wrote:
>>
>> Hi Simon and Cyril,
>>
>>
>>
>> I really appreciate your insight.
>>
>>
>>
>> By examining the parameters of the acquisition, I saw that the center
>> must effectively be offset (4.8 mm in both directions). For the attached
>> image, I also increases sdd and sid by a factor 1000, just in case I would
>> be wrong in units. It reduces the first default I pointed out in my first
>> message. Also note that my input dataset was SophiaBeads_512_averaged.
>>
>>
>>
>> Regarding the pre-processing mentioned by Simon, I need more help. Is it
>> as simple as the FDK filter assumes that the input is intensity, but the
>> dataset provides -ln(I/I0) ?
>>
>>
>>
>> Regards,
>>
>> mg
>>
>>
>>
>> 2016-01-20 3:33 GMT-05:00 Simon Rit < <simon.rit at creatis.insa-lyon.fr>
>> simon.rit at creatis.insa-lyon.fr>:
>>
>> Hi,
>>
>> I quickly checked SophiaBeads_64_averaged.zip. First, it seems that what
>> is provided is directly the line integral. RTK will process the tif images
>> as if it were a photon count so I converted the tif projections to mha to
>> avoid this. For the conversion, I used another piece of software but you
>> can easily do the same thing with SimpleRTK.
>>
>> Second, I used the enclosed script which gives me a much better result. I
>> have however a geometry problem. I think they provide a Matlab piece of
>> code to get the center of rotation. If you can run it and find out what is
>> this center, then you can use it to configure the geometry better with the
>> options --proj_iso_x and --proj_iso_y.
>>
>> Good luck,
>>
>> Simon
>>
>>
>>
>> On Tue, Jan 19, 2016 at 8:02 PM, MG Vallet < <mgvallet.pro at gmail.com>
>> mgvallet.pro at gmail.com> wrote:
>>
>> Thanks Cyril!
>>
>> going to carefully check my inputs and I give you some news.
>>
>> mgv
>>
>>
>>
>> 2016-01-19 10:33 GMT-05:00 Cyril Mory < <cyril.mory at uclouvain.be>
>> cyril.mory at uclouvain.be>:
>>
>> Hi,
>>
>> It looks like the geometry is wrong indeed, because I have never seen
>> such artifacts.
>>
>> Hope that helps,
>> Cyril
>>
>>
>>
>> Le 19/01/2016 16:19, MG Vallet a écrit :
>>
>> Dear rtk-users,
>>
>>
>>
>> I applied the FDKConeBeamReconstructionFilter to a data set from
>> <https://zenodo.org/record/16539>https://zenodo.org/record/16539.
>>
>> This is a plastic tube filled with glass beads that has been scanned.
>>
>>
>>
>> Attached is a view of the reconstructed central slice. It is found that:
>>
>>    1. the beads are quickly deformed outside the center
>>    2. each one has a halo, or a shadow (dont know the proper term)
>>
>> My question is if these are simply expected artifacts. I am not 100% sure
>> I properly set the geometry parameters.
>>
>>
>>
>> Regards,
>>
>> mgv
>>
>>
>>
>> _______________________________________________
>>
>> Rtk-users mailing list
>>
>> Rtk-users at public.kitware.com
>>
>> http://public.kitware.com/mailman/listinfo/rtk-users
>>
>>
>>
>>
>> L'absence de virus dans ce courrier électronique a été vérifiée par le
>> logiciel antivirus Avast.
>> <https://www.avast.com/antivirus>www.avast.com
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Rtk-users mailing list
>> <Rtk-users at public.kitware.com>Rtk-users at public.kitware.com
>> <http://public.kitware.com/mailman/listinfo/rtk-users>
>> http://public.kitware.com/mailman/listinfo/rtk-users
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20160209/f05c9857/attachment-0010.html>