[Rtk-users] I0EstimationProjectionFilter

Lotte Schyns lotte.schyns at maastro.nl
Thu Mar 9 09:36:19 EST 2017


Hello Simon,

That is exactly what I'm doing now, I just wanted to see if using the full depth of the image gives a better result. I sent you a pull request for an updated version of rtkLUTbasedVariableI0RawToAttenuationImageFilter.hxx. At least now the users can decide for themselves which data type they want to use. Thanks again for your help :)

Lotte

On 08-03-17 13:23, Simon Rit wrote:
Hi,
Yes, you need to modify it, add the TOutputImageType to overwrite the default line 80 of rtkLUTbasedVariableI0RawToAttenuationImageFilter.hxx<https://github.com/SimonRit/RTK/blob/master/code/rtkLUTbasedVariableI0RawToAttenuationImageFilter.hxx>. But note that bitshift 2 (the default) seems small to me for unsigned int because your histogram will be 8 GB. You probably want to test different bitshifts in this function and use a larger one for int. Actually, you'll also have a similarly huge lookup table. Have you considered casting your projections to unsigned short for the I0 estimation?
Simon

On Wed, Mar 8, 2017 at 12:03 PM, Lotte Schyns <lotte.schyns at maastro.nl<mailto:lotte.schyns at maastro.nl>> wrote:

Hello Simon,

Thanks for fixing it. The reason I removed the default templates was because there were unsigned shorts in the default templates and for an instance of the I0EstimationProjectionFilter class in rtk::LUTbasedVariableI0RawToAttenuationImageFilter::BeforeThreadedGenerateData(), only TInputImage is defined, so I wanted to prevent some undesired unsigned shorts to show up there because of the default templates. Do you think LUTbasedVariableI0RawToAttenuationImageFilter can now also handle unsigned ints in BeforeThreadedGenerateData, even with the default templates? I wasn't sure, so I deleted them.

Lotte

On 07-03-17 22:38, Simon Rit wrote:
Hi Lotte,
You had removed the default templates, which was the cause of the compilation problem. I have fixed it and put the change in a new branch:
https://github.com/SimonRit/RTK/tree/Lotte1990-patch
I'll merge tomorrow if the tests pass.
Thanks for the work,
Simon

On Mon, Mar 6, 2017 at 1:02 PM, Lotte Schyns <lotte.schyns at maastro.nl<mailto:lotte.schyns at maastro.nl>> wrote:
Hello Simon,

Thanks for the quick response. I made some changes and sent you a pull request. However, because of the changes I made, I'm now having some problems in rtk::LUTbasedVariableI0RawToAttenuationImageFilter::BeforeThreadedGenerateData(). I tried to solve it using typename, but it seems to be unsuccessful. Could you please have a look? The I0EstimationProjectionFilter seems to work now.

Lotte


On 04-03-17 11:25, Simon Rit wrote:
Hi Lotte,
This code has only be used for unsigned short. I guess you should replace all "unsigned short" in the two code files by InputImagePixelType which is already defined in the header. I would also advise a code review, for example 16 line 33 of rtkI0EstimationProjectionFilter.hxx should be replace by std::numeric_limits<http://en.cppreference.com/w/cpp/types/numeric_limits><InputImagePixelType>::digits.
I0EstimationProjectionFilter is based on a histogram analysis. Using 2^16 bins for unsigned shorts or 2^32 for unsigned int is too large so bitShift is used to reduce the number of bins to, e.g., for unsigned shorts, 2^(16-bitShift) bins.
If you can't figure it out, let us know. If you do, please share your dev!
Thanks,
Simon

On Fri, Mar 3, 2017 at 2:39 PM, Lotte Schyns <lotte.schyns at maastro.nl<mailto:lotte.schyns at maastro.nl>> wrote:
Hello,

I would like to set the maximum pixel value in
rtk::I0EstimationProjectionFilter to (2^32)-1 since I have (unsigned)
pixels of 4 bytes each. However, the input for SetMaxPixelValue requires
an unsigned short, so I can only set a maximum value of (2^16)-1, which
is not enough. Is there a possible solution/workaround for this? Could
you also tell me what the bitShift represents in
rtk::I0EstimationProjectionFilter? Thanks in advance.

Lotte
_______________________________________________
Rtk-users mailing list
Rtk-users at public.kitware.com<mailto: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/20170309/bfcab7c9/attachment.html>


More information about the Rtk-users mailing list