[Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images.

Mon Sep 9 12:03:55 EDT 2013

Thanks for looking into this.
(And sorry I haven't responded earlier.  I've been away in 
Germany/Poland for about a month, and this is my first day back).
The 3D FFT explains why the result is a total catastrophe.  I didn't 
have time to submit a bug report on this issue, as requested by Marc, 
before I left.  I don't think the report is necessary any more.  It is a 
case of garbage in, garbage out. I was just expecting garbage on the 
first few slices, but as I said, the 3D FFT explains the blank data set 
after the RAMP filter.  If you still want a report submitted, however, I 
can still do that.

I did come across another issue before I left (again, that I didn't have 
time to report).  It is related to the CUDA Forward projection 
generating moire/aliasing artifacts that does not occur in the CPU 
implementation (which was a good enough workaround for the limited time 
I had :).  I will dig up that data tomorrow, and report back to the 
mailing list.

Anyhow, thanks again for looking into the Rubiks data.  The 3D FFT makes 
perfect sense.

Steve

On 13-08-12 03:39 PM, Simon Rit wrote:
> Hi Steven,
> Thanks for sharing the dataset. I had a look and it seems that some of
> your pixels contain nan values. In this case, one pixel can
> contaminate all the others, especially since RTK uses a 3D FFT (for
> speed). To illustrate this, I have enclosed a vv snapshot of the mhd
> of projection 525. At location of the crosshair, i.e. pixel (924,679),
> the value is nan.
> Surprisingly, when I ran statistics on the file, I found like you that
> nan values did not contaminate min/max but it did contaminate the sum.
> Simon
>
> On Sun, Aug 4, 2013 at 8:22 PM, Steven Pollmann <spollmann at robarts.ca> wrote:
>> Grrr....
>> e-mail program is auto-correcting!
>> rubiks_MM_PROJ.mhd NOT rubies_MM_PROJ.mhd
>>
>>
>> Steve
>>
>> ________________________________________
>> From: Steven Pollmann
>> Sent: August 4, 2013 2:20 PM
>> To: Steven Pollmann; MORY, CYRIL; rtk-users at openrtk.org
>> Subject: RE: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images.
>>
>> Just a quick correction...
>> The Projection .mhd file is called rubies_MM_PROJ.mhd, not rubies_MM_PROJ.mhd
>>
>> Steve
>> ________________________________________
>> From: rtk-users-bounces at openrtk.org [rtk-users-bounces at openrtk.org] On Behalf Of Steven Pollmann [spollmann at robarts.ca]
>> Sent: August 4, 2013 2:19 PM
>> To: MORY, CYRIL; rtk-users at openrtk.org
>> Subject: Re: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images.
>>
>> Hello,
>> I have finally been able to upload the Rubiks projections to Box.com.  It is about 2GB.  This is the link:
>> https://app.box.com/s/bgh5a2i3grxi6lkltrj2
>>
>> In that directory, I have included a geometry file for reconstruction, and 2 linux tcsh scripts that I use to perform just a ramp filter, or a full fdk reconstruction (ZZ_doRamp.tcsh, and ZZ_doFDKRecon.tcsh).  The projections are 1024x680 floating point, but I have created a rubies_MM_Proj.mhd with the appropriate info.
>> I have been playing a little more with the data, and I think the issue is possibly related to the top and bottom of the projections where a collimator is partially visible (These areas do not correct well with bright- and dark-field images, as I think the collumator changes a little between acquisitions of the bright and dark fields, and the actual projections).  If I blank (set to 0.0), say the first 50 and last 50 lines, the ramp filter does not get an NaN, and is ok.  It seems the RAMP filtering function is not handling some data in these region well, possibly resulting in a divide by zero?
>>
>> I've been using this data set with RTK to test some corrections we'd like to do on the projection images...and, also, it is a pretty fun dataset to work with (4x4x4 Rubiks Cube!)
>> :)
>> Anyhow, thanks for looking at this data.
>> Steven
>>
>> ________________________________________
>> From: rtk-users-bounces at openrtk.org [rtk-users-bounces at openrtk.org] On Behalf Of MORY, CYRIL [Cyril.Mory at philips.com]
>> Sent: August 2, 2013 3:09 AM
>> To: rtk-users at openrtk.org
>> Subject: Re: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images.
>>
>> Hi Steve,
>>
>> The problem seems to lie in the data indeed. Can you send a link to the dataset (using a Dropbox link, for example) ?
>>
>> Cyril
>>
>> -----Message d'origine-----
>> De : rtk-users-bounces at openrtk.org [mailto:rtk-users-bounces at openrtk.org] De la part de Steven Pollmann
>> Envoyé : jeudi 1 août 2013 22:54
>> À : rtk-users at openrtk.org
>> Objet : Re: [Rtk-users] Volume error with fdkrtk backprojecting Polynomial corrected logged Projection Images.
>>
>> Just an update on this issue I am having.
>> If I just use rtkbackprojections with --method CudaBackProjection, I get an output volume that looks ok (obviously blurry, as no filter was applied).  So I target my efforts to look into the Ramp Filter.  It seems that this is where the issue stems from.  I have included 2 image screenshots.  The first (RawProjections.jpg) is a slice of the sinogram of the polynomial corrected projection data I would like to backproject, and the second (RawProjectionsRAMP.jpg) is the same data, after the RAMP filter has been applied (using rtkramp).  The black lines contain "NaN"
>> values, and for that particular projection image, the entire image is turned into NaN.  So the backprojection obciously fails through those values.
>> I will do one more check to see if there are any erroneous pixels for the projections where the NaN occurs, but I am not confident that there should be any abnormal values.
>>
>> Any suggestions from here?
>> Thanks!
>> Steve
>>
>>
>>
>> On 13-08-01 11:57 AM, Steven Pollmann wrote:
>>> Hey RTK Users,
>>>
>>> I'm having an issue with rtkfdk output that I am trying to track down. I'm using logged projection images that have had a polynomial-based correction applied to them.  Every voxel in the output 3D mhd file (float) has a floating point value of 7FFFFFFF which, I believe is the largest 32bit float representation.  The input projection images look fine when I open them with VolView (having values ranging from -0.3(air) to 45.0 (metal screw)). The original non-corrected projections (having values ranging from -0.02(air) to 2.88(screw)) work with rtkfdk to produce a nice looking volume, so there is something I am missing.  Using in-house software, this polynomial corrected projection data reconstructs on a CPU-based implementation fine, however both CPU and CUDA backprojections from rtkfdk will not produce a valid 3d Volume for me.  If anyone has insight into what change in the projection data may cause this, that would be appreciated.  The dataset isn't proprietary (it is a scan
>>>    of a 4x4x4 Rubiks Cube), and so I can send files to some online storage, if needed. (It is around 2GB of projection data...).
>>>
>>> Thanks again,
>>> Steve
>>> _______________________________________________
>>> Rtk-users mailing list
>>> Rtk-users at openrtk.org
>>> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users
>>
>> ________________________________
>> The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.
>>
>> _______________________________________________
>> Rtk-users mailing list
>> Rtk-users at openrtk.org
>> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users
>> _______________________________________________
>> Rtk-users mailing list
>> Rtk-users at openrtk.org
>> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users
>> _______________________________________________
>> Rtk-users mailing list
>> Rtk-users at openrtk.org
>> http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users