From mdupont at cppm.in2p3.fr  Sun Nov  1 12:41:49 2015
From: mdupont at cppm.in2p3.fr (Mathieu Dupont)
Date: Sun, 01 Nov 2015 18:41:49 +0100
Subject: [Rtk-users] question about rtkDraw*ImageFilter
In-Reply-To: <56334CF2.8070902@cppm.in2p3.fr>
References: <5630EE01.5070900@cppm.in2p3.fr>
 <CAF0oig279ZWGJMFnJdXaPiYLPponadz_J-PVKt2z3iHiTRQ_gg@mail.gmail.com>
 <56334CF2.8070902@cppm.in2p3.fr>
Message-ID: <1539144.WPSdtJ8lhZ@marabunta>

Hello Simon, 

I started to implement what I suggested : 

https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawImageFilter.h
and 
https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawCylinderImageFilter.h

rtk::DrawCylinderImageFilter derives from rtk::DrawImageFilter and specializes 
it (by defaulting the template parameter TSpatialObject with 
DrawCylinderSpatialObject). 

By default, DrawCylinderImageFilter uses Add2 for filling output image (to be 
backward compatible (all tests pass)). I created Discard (I did not find 
equivalent in itk) functor in order to do what I wanted in my first email.  

I just implemented DrawCylinderImageFilter, the others will follow. 

What do you think about it ?

Le vendredi 30 octobre 2015, 11:56:50 Mathieu Dupont a ?crit :
> Hi,
> 
> In case of your first solution, you can not chain several
> Draw*ImageFilters. For example, if you want to create small cylinders in
> a big cylinder.
> 
> Your second solution is better.
> 
> One another solution can be a thing like itk:SpatialObject but more
> simpler. An rtk::SpatialObject which one function (isInside(point)). We
> create a rtkDrawImageFilter class and implement ThreadedGenerateData
> like this :
> 
> DrawImageFilter<InImage, OutImage, rtkSpatialObject,
> rtkFillFunctor>::ThreadedGenerateData(const OutputImageRegionType&
> outputRegionForThread,                 ThreadIdType itkNotUsed(threadId)
> {
> ...
> 
>   while( !itOut.IsAtEnd() )
>      {
>      this->GetInput()->TransformIndexToPhysicalPoint(itOut.GetIndex(),
> point);
> 
>     if(m_rtkSpatialObject.isInside(point)
>       itOut.Set(m_rtkFillFunctor(density, itIn.Get());
> ...
> }
> 
> 
> DrawConeImageFilter class can be a child of this new DrawImageFilter
> (with new methods like setAngle, SetRadius which will adjust the
> rtkConeSpatialObject)
> 
> This solution suppress duplicated code in
> Draw*ImageFilter::ThreadedGenerateData and makes easier implementation
> of another type of filling.
> 
> On 28/10/2015 20:52, Simon Rit wrote:
> > Hi Mathieu,
> > Thanks for pointing this out. I agree that it might not be the best
> > solution, yet one could argue that you could simply create a constant
> > image with 0 to do what you'd like from the current implementation. My
> > main problem is that I just tried to do what you suggest and some tests
> > then fail... which shows the obvious, it's not a backward compatible
> > change. I see two solutions:
> > - keep it as is and you use ConstantImageFilter + we remove useless add
> > filters,
> > - a more complex but maybe more elegant solution: add a third template
> > parameter for the operation that would allow the user to do what he'd
> > like in a functor. That's what's done with filters that derive from
> > itk::UnaryImageFilter
> > <http://www.itk.org/Doxygen/html/classitk_1_1UnaryFunctorImageFilter.html>
> > .
> > The default would be itk::Add2 but we could find or implement another
> > one that simply discards the pixel value.
> > What do you think?
> > Simon
> > 
> > PS: looking in the code, I just found that rtk::DrawConeImageFilter is
> > not consistent with the others, it was always setting to 0 outside...
> > that's been fixed!
> > 
> > On Wed, Oct 28, 2015 at 4:47 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr
> > 
> > <mailto:mdupont at cppm.in2p3.fr>> wrote:
> >     Hello everyone,
> >     
> >     I have a question/suggestion about the set of rtkDraw*ImageFilter.
> >     This filter are written as additive filters: for example, in
> >     rtkDrawEllipsoidImageFilter.txx, we can find
> >     
> >     for(..)
> >     
> >       itOut.Set( ellipsoid.density + itIn.Get() )
> >     
> >     instead of
> >     
> >     for(..)
> >     itOut.Set( ellipsoid.density )
> >     
> >     
> >     I think it can be more flexible the second option, because we can
> >     always associate Draw*ImageFilter and itkAddImageFilter to get an
> >     additive filter.
> >     
> >     Moreover, the  rtkDrawGeometricPhantomImageFilter class already uses
> >     itkAddImageFilter in order to have additive filters (which is
> >     redundant in current situation).
> >     
> >     What do you think ?
> >     
> >     
> >     
> >     
> >     
> >     Regards
> >     
> >     
> >     
> >     _______________________________________________
> >     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

From gnthibault at gmail.com  Mon Nov  2 08:08:42 2015
From: gnthibault at gmail.com (Notargiacomo Thibault)
Date: Mon, 2 Nov 2015 14:08:42 +0100
Subject: [Rtk-users] Problem with rtkGgoFunctions when importing series of
	images
Message-ID: <CAP+mR7Zw7WmRmEgVUTamNhS6m4S6ORvWFjRu1EANViPRJ7jtuQ@mail.gmail.com>

I recently experienced the following problem, when importing multiple tif
files inside a directory using itk::ImageSeriesReader:

[...]
code/rtkGgoFunctions.h: In instantiation of ?void
rtk::SetProjectionsReaderFromGgo(typename TProjectionsReaderType::Pointer,
const TArgsInfo&)
[...]
code/rtkGgoFunctions.h:121:61: error: no type named
?OutputImageDirectionType? in ?class
itk::ImageSeriesReader<itk::Image<short unsigned int, 3u> >?
   typename TProjectionsReaderType::OutputImageDirectionType direction;
[...]

It seems that, a new functionality added in rtkGgoFunctions.h (19/05/2015),
allowing to directly modify input images properties through command line,
like geometry (direction vector), assumes that the input image type defines
OutputImageDirectionType, but in the case of itk::ImageSeriesReader, it
does not.

Is this considered as a regression, or should the
SetProjectionsReaderFromGgo function be used with specific input image type
?

Thank you in advance for your help.

Kind regards

Thibault Notargiacomo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151102/6cad3583/attachment.html>

From simon.rit at creatis.insa-lyon.fr  Mon Nov  2 08:58:24 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Mon, 2 Nov 2015 14:58:24 +0100
Subject: [Rtk-users] Problem with rtkGgoFunctions when importing series
	of images
In-Reply-To: <CAP+mR7Zw7WmRmEgVUTamNhS6m4S6ORvWFjRu1EANViPRJ7jtuQ@mail.gmail.com>
References: <CAP+mR7Zw7WmRmEgVUTamNhS6m4S6ORvWFjRu1EANViPRJ7jtuQ@mail.gmail.com>
Message-ID: <CAF0oig2bAidO4JR7pa_PUxOQm-X7JrEz8=ybGX3bskYJM9YRAQ@mail.gmail.com>

Hi Thibault,
SetProjectionsReaderFromGgo is a macro designed for the
rtk::ProjectionsReader
<http://www.openrtk.org/Doxygen/classrtk_1_1ProjectionsReader.html>, I'm
not surprised that it does not work with the itk::ImageSeriesReader. It's
not about the image type but about the filter type... We use this macro to
set many parameters specific to the rtk::ProjectionsReader
<http://www.openrtk.org/Doxygen/classrtk_1_1ProjectionsReader.html>. Since
a while, I have made have a common rtkinputprojections_section.ggo
<https://github.com/SimonRit/RTK/blob/master/applications/rtkinputprojections_section.ggo>
file for all the applications that use the rtk::ProjectionsReader.
If you don't want to use the rtk::ProjectionsReader but
itk::ImageSeriesReader (e.g., because it does a lot of automatic processing
that you don't want), you'll have to write your own code to set it up.
I hope this clarifies things.
Simon

On Mon, Nov 2, 2015 at 2:08 PM, Notargiacomo Thibault <gnthibault at gmail.com>
wrote:

> I recently experienced the following problem, when importing multiple tif
> files inside a directory using itk::ImageSeriesReader:
>
> [...]
> code/rtkGgoFunctions.h: In instantiation of ?void
> rtk::SetProjectionsReaderFromGgo(typename TProjectionsReaderType::Pointer,
> const TArgsInfo&)
> [...]
> code/rtkGgoFunctions.h:121:61: error: no type named
> ?OutputImageDirectionType? in ?class
> itk::ImageSeriesReader<itk::Image<short unsigned int, 3u> >?
>    typename TProjectionsReaderType::OutputImageDirectionType direction;
> [...]
>
> It seems that, a new functionality added in rtkGgoFunctions.h
> (19/05/2015), allowing to directly modify input images properties through
> command line, like geometry (direction vector), assumes that the input
> image type defines OutputImageDirectionType, but in the case of
> itk::ImageSeriesReader, it does not.
>
> Is this considered as a regression, or should the
> SetProjectionsReaderFromGgo function be used with specific input image type
> ?
>
> Thank you in advance for your help.
>
> Kind regards
>
> Thibault Notargiacomo
>
> _______________________________________________
> 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/20151102/ee7e2c17/attachment.html>

From simon.rit at creatis.insa-lyon.fr  Wed Nov  4 16:38:18 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Wed, 4 Nov 2015 22:38:18 +0100
Subject: [Rtk-users] question about rtkDraw*ImageFilter
In-Reply-To: <1539144.WPSdtJ8lhZ@marabunta>
References: <5630EE01.5070900@cppm.in2p3.fr>
 <CAF0oig279ZWGJMFnJdXaPiYLPponadz_J-PVKt2z3iHiTRQ_gg@mail.gmail.com>
 <56334CF2.8070902@cppm.in2p3.fr> <1539144.WPSdtJ8lhZ@marabunta>
Message-ID: <CAF0oig3jBsfoadM_k6SYvOMwikOCNFmH19J7m1YJZx-RU0y+5g@mail.gmail.com>

Hi Mathieu,
Sorry, I'm very busy these days. I had a first quick look. Why not, it
looks a bit complicated but good. I would have a few things I would change
style wise, e.g., move DrawCylinderSpatialObject to
DrawCylinderImageFilter, create a common DrawQuadricSpatialObject that
would all have the same IsInside function, make DrawSpatialObjectpurely
virtual by not defining
IsInside etc. but those are details I can correct myself. Do you want to
finish what you started and I work from there or should I finish everything?
Simon

On Sun, Nov 1, 2015 at 6:41 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr>
wrote:

> Hello Simon,
>
> I started to implement what I suggested :
>
>
> https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawImageFilter.h
> and
>
> https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawCylinderImageFilter.h
>
> rtk::DrawCylinderImageFilter derives from rtk::DrawImageFilter and
> specializes
> it (by defaulting the template parameter TSpatialObject with
> DrawCylinderSpatialObject).
>
> By default, DrawCylinderImageFilter uses Add2 for filling output image (to
> be
> backward compatible (all tests pass)). I created Discard (I did not find
> equivalent in itk) functor in order to do what I wanted in my first email.
>
> I just implemented DrawCylinderImageFilter, the others will follow.
>
> What do you think about it ?
>
> Le vendredi 30 octobre 2015, 11:56:50 Mathieu Dupont a ?crit :
> > Hi,
> >
> > In case of your first solution, you can not chain several
> > Draw*ImageFilters. For example, if you want to create small cylinders in
> > a big cylinder.
> >
> > Your second solution is better.
> >
> > One another solution can be a thing like itk:SpatialObject but more
> > simpler. An rtk::SpatialObject which one function (isInside(point)). We
> > create a rtkDrawImageFilter class and implement ThreadedGenerateData
> > like this :
> >
> > DrawImageFilter<InImage, OutImage, rtkSpatialObject,
> > rtkFillFunctor>::ThreadedGenerateData(const OutputImageRegionType&
> > outputRegionForThread,                 ThreadIdType itkNotUsed(threadId)
> > {
> > ...
> >
> >   while( !itOut.IsAtEnd() )
> >      {
> >      this->GetInput()->TransformIndexToPhysicalPoint(itOut.GetIndex(),
> > point);
> >
> >     if(m_rtkSpatialObject.isInside(point)
> >       itOut.Set(m_rtkFillFunctor(density, itIn.Get());
> > ...
> > }
> >
> >
> > DrawConeImageFilter class can be a child of this new DrawImageFilter
> > (with new methods like setAngle, SetRadius which will adjust the
> > rtkConeSpatialObject)
> >
> > This solution suppress duplicated code in
> > Draw*ImageFilter::ThreadedGenerateData and makes easier implementation
> > of another type of filling.
> >
> > On 28/10/2015 20:52, Simon Rit wrote:
> > > Hi Mathieu,
> > > Thanks for pointing this out. I agree that it might not be the best
> > > solution, yet one could argue that you could simply create a constant
> > > image with 0 to do what you'd like from the current implementation. My
> > > main problem is that I just tried to do what you suggest and some tests
> > > then fail... which shows the obvious, it's not a backward compatible
> > > change. I see two solutions:
> > > - keep it as is and you use ConstantImageFilter + we remove useless add
> > > filters,
> > > - a more complex but maybe more elegant solution: add a third template
> > > parameter for the operation that would allow the user to do what he'd
> > > like in a functor. That's what's done with filters that derive from
> > > itk::UnaryImageFilter
> > > <
> http://www.itk.org/Doxygen/html/classitk_1_1UnaryFunctorImageFilter.html>
> > > .
> > > The default would be itk::Add2 but we could find or implement another
> > > one that simply discards the pixel value.
> > > What do you think?
> > > Simon
> > >
> > > PS: looking in the code, I just found that rtk::DrawConeImageFilter is
> > > not consistent with the others, it was always setting to 0 outside...
> > > that's been fixed!
> > >
> > > On Wed, Oct 28, 2015 at 4:47 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr
> > >
> > > <mailto:mdupont at cppm.in2p3.fr>> wrote:
> > >     Hello everyone,
> > >
> > >     I have a question/suggestion about the set of rtkDraw*ImageFilter.
> > >     This filter are written as additive filters: for example, in
> > >     rtkDrawEllipsoidImageFilter.txx, we can find
> > >
> > >     for(..)
> > >
> > >       itOut.Set( ellipsoid.density + itIn.Get() )
> > >
> > >     instead of
> > >
> > >     for(..)
> > >     itOut.Set( ellipsoid.density )
> > >
> > >
> > >     I think it can be more flexible the second option, because we can
> > >     always associate Draw*ImageFilter and itkAddImageFilter to get an
> > >     additive filter.
> > >
> > >     Moreover, the  rtkDrawGeometricPhantomImageFilter class already
> uses
> > >     itkAddImageFilter in order to have additive filters (which is
> > >     redundant in current situation).
> > >
> > >     What do you think ?
> > >
> > >
> > >
> > >
> > >
> > >     Regards
> > >
> > >
> > >
> > >     _______________________________________________
> > >     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/20151104/46314d97/attachment.html>

From mdupont at cppm.in2p3.fr  Mon Nov  9 14:35:47 2015
From: mdupont at cppm.in2p3.fr (Mathieu Dupont)
Date: Mon, 09 Nov 2015 20:35:47 +0100
Subject: [Rtk-users] question about rtkDraw*ImageFilter
In-Reply-To: <CAF0oig3jBsfoadM_k6SYvOMwikOCNFmH19J7m1YJZx-RU0y+5g@mail.gmail.com>
References: <5630EE01.5070900@cppm.in2p3.fr> <1539144.WPSdtJ8lhZ@marabunta>
 <CAF0oig3jBsfoadM_k6SYvOMwikOCNFmH19J7m1YJZx-RU0y+5g@mail.gmail.com>
Message-ID: <5634494.U9CmFl2V79@marabunta>

hi, 

i will do this during this week and try to implement your remarks. 


Le mercredi 4 novembre 2015, 22:38:18 Simon Rit a ?crit :
> Hi Mathieu,
> Sorry, I'm very busy these days. I had a first quick look. Why not, it
> looks a bit complicated but good. I would have a few things I would change
> style wise, e.g., move DrawCylinderSpatialObject to
> DrawCylinderImageFilter, create a common DrawQuadricSpatialObject that
> would all have the same IsInside function, make DrawSpatialObjectpurely
> virtual by not defining
> IsInside etc. but those are details I can correct myself. Do you want to
> finish what you started and I work from there or should I finish everything?
> Simon
> 
> On Sun, Nov 1, 2015 at 6:41 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr>
> 
> wrote:
> > Hello Simon,
> > 
> > I started to implement what I suggested :
> > 
> > 
> > https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawImag
> > eFilter.h and
> > 
> > https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawCyli
> > nderImageFilter.h
> > 
> > rtk::DrawCylinderImageFilter derives from rtk::DrawImageFilter and
> > specializes
> > it (by defaulting the template parameter TSpatialObject with
> > DrawCylinderSpatialObject).
> > 
> > By default, DrawCylinderImageFilter uses Add2 for filling output image (to
> > be
> > backward compatible (all tests pass)). I created Discard (I did not find
> > equivalent in itk) functor in order to do what I wanted in my first email.
> > 
> > I just implemented DrawCylinderImageFilter, the others will follow.
> > 
> > What do you think about it ?
> > 
> > Le vendredi 30 octobre 2015, 11:56:50 Mathieu Dupont a ?crit :
> > > Hi,
> > > 
> > > In case of your first solution, you can not chain several
> > > Draw*ImageFilters. For example, if you want to create small cylinders in
> > > a big cylinder.
> > > 
> > > Your second solution is better.
> > > 
> > > One another solution can be a thing like itk:SpatialObject but more
> > > simpler. An rtk::SpatialObject which one function (isInside(point)). We
> > > create a rtkDrawImageFilter class and implement ThreadedGenerateData
> > > like this :
> > > 
> > > DrawImageFilter<InImage, OutImage, rtkSpatialObject,
> > > rtkFillFunctor>::ThreadedGenerateData(const OutputImageRegionType&
> > > outputRegionForThread,                 ThreadIdType itkNotUsed(threadId)
> > > {
> > > ...
> > > 
> > >   while( !itOut.IsAtEnd() )
> > >   
> > >      {
> > >      this->GetInput()->TransformIndexToPhysicalPoint(itOut.GetIndex(),
> > > 
> > > point);
> > > 
> > >     if(m_rtkSpatialObject.isInside(point)
> > >     
> > >       itOut.Set(m_rtkFillFunctor(density, itIn.Get());
> > > 
> > > ...
> > > }
> > > 
> > > 
> > > DrawConeImageFilter class can be a child of this new DrawImageFilter
> > > (with new methods like setAngle, SetRadius which will adjust the
> > > rtkConeSpatialObject)
> > > 
> > > This solution suppress duplicated code in
> > > Draw*ImageFilter::ThreadedGenerateData and makes easier implementation
> > > of another type of filling.
> > > 
> > > On 28/10/2015 20:52, Simon Rit wrote:
> > > > Hi Mathieu,
> > > > Thanks for pointing this out. I agree that it might not be the best
> > > > solution, yet one could argue that you could simply create a constant
> > > > image with 0 to do what you'd like from the current implementation. My
> > > > main problem is that I just tried to do what you suggest and some
> > > > tests
> > > > then fail... which shows the obvious, it's not a backward compatible
> > > > change. I see two solutions:
> > > > - keep it as is and you use ConstantImageFilter + we remove useless
> > > > add
> > > > filters,
> > > > - a more complex but maybe more elegant solution: add a third template
> > > > parameter for the operation that would allow the user to do what he'd
> > > > like in a functor. That's what's done with filters that derive from
> > > > itk::UnaryImageFilter
> > > > <
> > 
> > http://www.itk.org/Doxygen/html/classitk_1_1UnaryFunctorImageFilter.html>
> > 
> > > > .
> > > > The default would be itk::Add2 but we could find or implement another
> > > > one that simply discards the pixel value.
> > > > What do you think?
> > > > Simon
> > > > 
> > > > PS: looking in the code, I just found that rtk::DrawConeImageFilter is
> > > > not consistent with the others, it was always setting to 0 outside...
> > > > that's been fixed!
> > > > 
> > > > On Wed, Oct 28, 2015 at 4:47 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr
> > > > 
> > > > <mailto:mdupont at cppm.in2p3.fr>> wrote:
> > > >     Hello everyone,
> > > >     
> > > >     I have a question/suggestion about the set of rtkDraw*ImageFilter.
> > > >     This filter are written as additive filters: for example, in
> > > >     rtkDrawEllipsoidImageFilter.txx, we can find
> > > >     
> > > >     for(..)
> > > >     
> > > >       itOut.Set( ellipsoid.density + itIn.Get() )
> > > >     
> > > >     instead of
> > > >     
> > > >     for(..)
> > > >     itOut.Set( ellipsoid.density )
> > > >     
> > > >     
> > > >     I think it can be more flexible the second option, because we can
> > > >     always associate Draw*ImageFilter and itkAddImageFilter to get an
> > > >     additive filter.
> > > >     
> > > >     Moreover, the  rtkDrawGeometricPhantomImageFilter class already
> > 
> > uses
> > 
> > > >     itkAddImageFilter in order to have additive filters (which is
> > > >     redundant in current situation).
> > > >     
> > > >     What do you think ?
> > > >     
> > > >     
> > > >     
> > > >     
> > > >     
> > > >     Regards
> > > >     
> > > >     
> > > >     
> > > >     _______________________________________________
> > > >     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

From gnthibault at gmail.com  Tue Nov 10 07:39:46 2015
From: gnthibault at gmail.com (Notargiacomo Thibault)
Date: Tue, 10 Nov 2015 13:39:46 +0100
Subject: [Rtk-users] Understanding projection matrices management in
	rtkCudaBackProjectionImageFilter
Message-ID: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>

Hi all,

I am currently trying to use the "AddProjectionInRadians" method from the
ThreeDCircularProjectionGeometry class in RTK to import my geometry.

First things first, I would like to know if the information on this pdf are
still valid: http://www.openrtk.org/Doxygen/geometry.pdf

Because I used them to deduce the source offset and Projection offset from
my own matrix decomposition.

Notice that I don't want to use geometric informations coming from the
projection images themselves, so their geometric origin is assumed to be
(0,0,0) in my case.

In order to check if my geometry import method is correct, I print out one
of the intermediate form of the projection matrix used in the
backprojection process, in order to check if it is the same as in my own
implementation.

To do so, I print out one of the intermediate matrix that is generated in
rtkCudaBackProjectionImageFilter while launching a SART reconstruction for
instance.

I was surpised by the fact that, the matrix allowing the transformation
from 2D geometric world to 2D image index world, namely matrixIdxProj in
rtkCudaBackProjectionImageFilte.cxx
<http://www.openrtk.org/Doxygen/rtkCudaBackProjectionImageFilter_8cxx_source.html>
is not always the same along the reconstruction process ?

Here is the line that generates the matrix I don't understand:

for(unsigned int i=0; i<2; i++)
 //SR: 0.5 for 2D texture
  matrixIdxProj[i][2] =
-1*(this->GetInput(1)->GetBufferedRegion().GetIndex()[i])+0.5;

What I understand here, is that, we are generating a 2D translation matrix
embedded in a 3*3 matrix that allows to take into account two things
related to the 2D projection:

-If the internal behaviour of the imageContainer, allows buffering of only
a part of the image, beginning at index (i,j), this information will be
embeded in the projection matrix

-the ITK floating point addressing definition seems to differ from the one
from cuda (and openCV):
When I take a look at this page
<http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#texture-fetching>
I understand that the floating point indexing (0.5,0.5) in Cuda points to
the center of the pixel (0,0) hence a linear contribution of 100%, while it
seems that we must add a translation of (0.5,0.5) to the ITK geometric
framework in order to get the same behaviour.

In practice matrixIdxProj is based on a 3*3 identity matrix, where the
inner 2D translation (ie 2 first term of the last column) in my case are:
-in X, a random number between 10 and 150 plus 0.5
-in Y: always 0.5

I understand the 0.5 part, but why is there always a 0 offset in Y but a
random offset in X remains a mystery to me.

At first, I believed that each projection was splitted into multiple part,
each having a different X and Y offset.
But reconstructing using only one projection generates only one
backprojection operation, with a non zero offset in X, 123 in my case, for
an image of size 780 in X.

Do you think there is something wrong whith the values of matrixIdxProjI am
experiencing ?

Thank you in advance.

Kind regards

Thibault Notargiacomo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151110/fbd3fb46/attachment.html>

From simon.rit at creatis.insa-lyon.fr  Tue Nov 10 08:21:29 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Tue, 10 Nov 2015 14:21:29 +0100
Subject: [Rtk-users] Understanding projection matrices management in
	rtkCudaBackProjectionImageFilter
In-Reply-To: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>
References: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>
Message-ID: <CAF0oig3muuH+1=eLZ66DJ22QcnsSrUKzRFS4RzDRvDJXNxAVXg@mail.gmail.com>

Hi Thibault,
You started digging in the code so that gets complicated. First thing
first, yes, the link you provide is still valid.
The offset in X is not random but computed in
BackProjectionImageFilter::GenerateInputRequestedRegion
<https://github.com/SimonRit/RTK/blob/master/code/rtkBackProjectionImageFilter.txx>.
The idea is that we request only the part of the projections we need to do
the backprojection. This optimizes the streaming (we only read from disk
what we need). If you use a huge volume (the test I'd suggest to validate
that I'm correct and there is nothing wrong with your code), then you'll
need the full projection and you will always get 0 in X as in Y. If you use
a small volume and do a computation projection per projection, you will get
a varying index depending on your input volume and the geometry for that
projection.
I think you understood the rest pretty well. Does that make sense or am I
missing something else?
Simon

On Tue, Nov 10, 2015 at 1:39 PM, Notargiacomo Thibault <gnthibault at gmail.com
> wrote:

> Hi all,
>
> I am currently trying to use the "AddProjectionInRadians" method from the
> ThreeDCircularProjectionGeometry class in RTK to import my geometry.
>
> First things first, I would like to know if the information on this pdf
> are still valid: http://www.openrtk.org/Doxygen/geometry.pdf
>
> Because I used them to deduce the source offset and Projection offset from
> my own matrix decomposition.
>
> Notice that I don't want to use geometric informations coming from the
> projection images themselves, so their geometric origin is assumed to be
> (0,0,0) in my case.
>
> In order to check if my geometry import method is correct, I print out one
> of the intermediate form of the projection matrix used in the
> backprojection process, in order to check if it is the same as in my own
> implementation.
>
> To do so, I print out one of the intermediate matrix that is generated in
> rtkCudaBackProjectionImageFilter while launching a SART reconstruction for
> instance.
>
> I was surpised by the fact that, the matrix allowing the transformation
> from 2D geometric world to 2D image index world, namely matrixIdxProj in
> rtkCudaBackProjectionImageFilte.cxx
> <http://www.openrtk.org/Doxygen/rtkCudaBackProjectionImageFilter_8cxx_source.html>
> is not always the same along the reconstruction process ?
>
> Here is the line that generates the matrix I don't understand:
>
> for(unsigned int i=0; i<2; i++)
>  //SR: 0.5 for 2D texture
>   matrixIdxProj[i][2] =
> -1*(this->GetInput(1)->GetBufferedRegion().GetIndex()[i])+0.5;
>
> What I understand here, is that, we are generating a 2D translation matrix
> embedded in a 3*3 matrix that allows to take into account two things
> related to the 2D projection:
>
> -If the internal behaviour of the imageContainer, allows buffering of only
> a part of the image, beginning at index (i,j), this information will be
> embeded in the projection matrix
>
> -the ITK floating point addressing definition seems to differ from the one
> from cuda (and openCV):
> When I take a look at this page
> <http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#texture-fetching>
> I understand that the floating point indexing (0.5,0.5) in Cuda points to
> the center of the pixel (0,0) hence a linear contribution of 100%, while it
> seems that we must add a translation of (0.5,0.5) to the ITK geometric
> framework in order to get the same behaviour.
>
> In practice matrixIdxProj is based on a 3*3 identity matrix, where the
> inner 2D translation (ie 2 first term of the last column) in my case are:
> -in X, a random number between 10 and 150 plus 0.5
> -in Y: always 0.5
>
> I understand the 0.5 part, but why is there always a 0 offset in Y but a
> random offset in X remains a mystery to me.
>
> At first, I believed that each projection was splitted into multiple part,
> each having a different X and Y offset.
> But reconstructing using only one projection generates only one
> backprojection operation, with a non zero offset in X, 123 in my case, for
> an image of size 780 in X.
>
> Do you think there is something wrong whith the values of matrixIdxProjI
> am experiencing ?
>
> Thank you in advance.
>
> Kind regards
>
> Thibault Notargiacomo
>
> _______________________________________________
> 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/20151110/8b9b86e6/attachment-0001.html>

From simon.rit at creatis.insa-lyon.fr  Tue Nov 10 09:03:52 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Tue, 10 Nov 2015 15:03:52 +0100
Subject: [Rtk-users] Understanding projection matrices management in
	rtkCudaBackProjectionImageFilter
In-Reply-To: <CAP+mR7ZLJV8V5dMOW_jgM5G2-kCZhy8o0tB19685LGo-1bxLUg@mail.gmail.com>
References: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>
 <CAF0oig3muuH+1=eLZ66DJ22QcnsSrUKzRFS4RzDRvDJXNxAVXg@mail.gmail.com>
 <CAP+mR7ZLJV8V5dMOW_jgM5G2-kCZhy8o0tB19685LGo-1bxLUg@mail.gmail.com>
Message-ID: <CAF0oig3fALRnZNCJ53+TsSjBm7raRC_mqahWEU6x+D+zxwOnVQ@mail.gmail.com>

A small correction: it's actually the amount of data pre-processed (read
from disk + all the processing before backprojection) but that should
change nothing to what is backprojected.
I remembered something that can help you: you may want to run
UpdateLargestPossibleRegion() to the projections (input 1 of the
BackProjectImageFilter) before backprojection to avoid this and make things
clearer instead of using a large volume as I was suggesting before.
Simon

On Tue, Nov 10, 2015 at 2:34 PM, Notargiacomo Thibault <gnthibault at gmail.com
> wrote:

> Ok, using geometric information to reduce the amount of data to be
> backprojected is pretty clever ;)
> This explains the "random" index I was asking about in my previous
> question, I now know what it is used for and continue my debugging process.
>
> Kind regards
>
> Thibault Notargiacomo
>
> 2015-11-10 14:21 GMT+01:00 Simon Rit <simon.rit at creatis.insa-lyon.fr>:
>
>> Hi Thibault,
>> You started digging in the code so that gets complicated. First thing
>> first, yes, the link you provide is still valid.
>> The offset in X is not random but computed in
>> BackProjectionImageFilter::GenerateInputRequestedRegion
>> <https://github.com/SimonRit/RTK/blob/master/code/rtkBackProjectionImageFilter.txx>.
>> The idea is that we request only the part of the projections we need to do
>> the backprojection. This optimizes the streaming (we only read from disk
>> what we need). If you use a huge volume (the test I'd suggest to validate
>> that I'm correct and there is nothing wrong with your code), then you'll
>> need the full projection and you will always get 0 in X as in Y. If you use
>> a small volume and do a computation projection per projection, you will get
>> a varying index depending on your input volume and the geometry for that
>> projection.
>> I think you understood the rest pretty well. Does that make sense or am I
>> missing something else?
>> Simon
>>
>> On Tue, Nov 10, 2015 at 1:39 PM, Notargiacomo Thibault <
>> gnthibault at gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> I am currently trying to use the "AddProjectionInRadians" method from
>>> the ThreeDCircularProjectionGeometry class in RTK to import my geometry.
>>>
>>> First things first, I would like to know if the information on this pdf
>>> are still valid: http://www.openrtk.org/Doxygen/geometry.pdf
>>>
>>> Because I used them to deduce the source offset and Projection offset
>>> from my own matrix decomposition.
>>>
>>> Notice that I don't want to use geometric informations coming from the
>>> projection images themselves, so their geometric origin is assumed to be
>>> (0,0,0) in my case.
>>>
>>> In order to check if my geometry import method is correct, I print out
>>> one of the intermediate form of the projection matrix used in the
>>> backprojection process, in order to check if it is the same as in my own
>>> implementation.
>>>
>>> To do so, I print out one of the intermediate matrix that is generated
>>> in rtkCudaBackProjectionImageFilter while launching a SART reconstruction
>>> for instance.
>>>
>>> I was surpised by the fact that, the matrix allowing the transformation
>>> from 2D geometric world to 2D image index world, namely matrixIdxProj in
>>> rtkCudaBackProjectionImageFilte.cxx
>>> <http://www.openrtk.org/Doxygen/rtkCudaBackProjectionImageFilter_8cxx_source.html>
>>> is not always the same along the reconstruction process ?
>>>
>>> Here is the line that generates the matrix I don't understand:
>>>
>>> for(unsigned int i=0; i<2; i++)
>>>  //SR: 0.5 for 2D texture
>>>   matrixIdxProj[i][2] =
>>> -1*(this->GetInput(1)->GetBufferedRegion().GetIndex()[i])+0.5;
>>>
>>> What I understand here, is that, we are generating a 2D translation
>>> matrix embedded in a 3*3 matrix that allows to take into account two things
>>> related to the 2D projection:
>>>
>>> -If the internal behaviour of the imageContainer, allows buffering of
>>> only a part of the image, beginning at index (i,j), this information will
>>> be embeded in the projection matrix
>>>
>>> -the ITK floating point addressing definition seems to differ from the
>>> one from cuda (and openCV):
>>> When I take a look at this page
>>> <http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#texture-fetching>
>>> I understand that the floating point indexing (0.5,0.5) in Cuda points to
>>> the center of the pixel (0,0) hence a linear contribution of 100%, while it
>>> seems that we must add a translation of (0.5,0.5) to the ITK geometric
>>> framework in order to get the same behaviour.
>>>
>>> In practice matrixIdxProj is based on a 3*3 identity matrix, where the
>>> inner 2D translation (ie 2 first term of the last column) in my case are:
>>> -in X, a random number between 10 and 150 plus 0.5
>>> -in Y: always 0.5
>>>
>>> I understand the 0.5 part, but why is there always a 0 offset in Y but a
>>> random offset in X remains a mystery to me.
>>>
>>> At first, I believed that each projection was splitted into multiple
>>> part, each having a different X and Y offset.
>>> But reconstructing using only one projection generates only one
>>> backprojection operation, with a non zero offset in X, 123 in my case, for
>>> an image of size 780 in X.
>>>
>>> Do you think there is something wrong whith the values of matrixIdxProjI
>>> am experiencing ?
>>>
>>> Thank you in advance.
>>>
>>> Kind regards
>>>
>>> Thibault Notargiacomo
>>>
>>> _______________________________________________
>>> 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/20151110/d8913dc3/attachment.html>

From simon.rit at creatis.insa-lyon.fr  Tue Nov 10 11:21:29 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Tue, 10 Nov 2015 17:21:29 +0100
Subject: [Rtk-users] Understanding projection matrices management in
	rtkCudaBackProjectionImageFilter
In-Reply-To: <CAP+mR7ZKqnbUyRHyHkti=3sZd2dEw-OUV6oqsqcga55=tcQ9OQ@mail.gmail.com>
References: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>
 <CAF0oig3muuH+1=eLZ66DJ22QcnsSrUKzRFS4RzDRvDJXNxAVXg@mail.gmail.com>
 <CAP+mR7ZLJV8V5dMOW_jgM5G2-kCZhy8o0tB19685LGo-1bxLUg@mail.gmail.com>
 <CAF0oig3fALRnZNCJ53+TsSjBm7raRC_mqahWEU6x+D+zxwOnVQ@mail.gmail.com>
 <CAP+mR7ZKqnbUyRHyHkti=3sZd2dEw-OUV6oqsqcga55=tcQ9OQ@mail.gmail.com>
Message-ID: <CAF0oig12pRGBfgiCQMCwTG7zX_3vz87AEWhTQ4EYaVbH_m0t5Q@mail.gmail.com>

Your welcome (I cc the mailing list for info).
Simon

On Tue, Nov 10, 2015 at 5:03 PM, Notargiacomo Thibault <gnthibault at gmail.com
> wrote:

> I replaced the original Update by the "UpdateLargestPossibleRegion" to the
> divideFilter in SART (I bypassed displacedDetectorFilter for now) and it
> work as expected, I have now a "clean" matProjIdx.
>
> Thank you for your help !
>
> 2015-11-10 15:03 GMT+01:00 Simon Rit <simon.rit at creatis.insa-lyon.fr>:
>
>> A small correction: it's actually the amount of data pre-processed (read
>> from disk + all the processing before backprojection) but that should
>> change nothing to what is backprojected.
>> I remembered something that can help you: you may want to run
>> UpdateLargestPossibleRegion() to the projections (input 1 of the
>> BackProjectImageFilter) before backprojection to avoid this and make things
>> clearer instead of using a large volume as I was suggesting before.
>> Simon
>>
>> On Tue, Nov 10, 2015 at 2:34 PM, Notargiacomo Thibault <
>> gnthibault at gmail.com> wrote:
>>
>>> Ok, using geometric information to reduce the amount of data to be
>>> backprojected is pretty clever ;)
>>> This explains the "random" index I was asking about in my previous
>>> question, I now know what it is used for and continue my debugging process.
>>>
>>> Kind regards
>>>
>>> Thibault Notargiacomo
>>>
>>> 2015-11-10 14:21 GMT+01:00 Simon Rit <simon.rit at creatis.insa-lyon.fr>:
>>>
>>>> Hi Thibault,
>>>> You started digging in the code so that gets complicated. First thing
>>>> first, yes, the link you provide is still valid.
>>>> The offset in X is not random but computed in
>>>> BackProjectionImageFilter::GenerateInputRequestedRegion
>>>> <https://github.com/SimonRit/RTK/blob/master/code/rtkBackProjectionImageFilter.txx>.
>>>> The idea is that we request only the part of the projections we need to do
>>>> the backprojection. This optimizes the streaming (we only read from disk
>>>> what we need). If you use a huge volume (the test I'd suggest to validate
>>>> that I'm correct and there is nothing wrong with your code), then you'll
>>>> need the full projection and you will always get 0 in X as in Y. If you use
>>>> a small volume and do a computation projection per projection, you will get
>>>> a varying index depending on your input volume and the geometry for that
>>>> projection.
>>>> I think you understood the rest pretty well. Does that make sense or am
>>>> I missing something else?
>>>> Simon
>>>>
>>>> On Tue, Nov 10, 2015 at 1:39 PM, Notargiacomo Thibault <
>>>> gnthibault at gmail.com> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I am currently trying to use the "AddProjectionInRadians" method from
>>>>> the ThreeDCircularProjectionGeometry class in RTK to import my geometry.
>>>>>
>>>>> First things first, I would like to know if the information on this
>>>>> pdf are still valid: http://www.openrtk.org/Doxygen/geometry.pdf
>>>>>
>>>>> Because I used them to deduce the source offset and Projection offset
>>>>> from my own matrix decomposition.
>>>>>
>>>>> Notice that I don't want to use geometric informations coming from the
>>>>> projection images themselves, so their geometric origin is assumed to be
>>>>> (0,0,0) in my case.
>>>>>
>>>>> In order to check if my geometry import method is correct, I print out
>>>>> one of the intermediate form of the projection matrix used in the
>>>>> backprojection process, in order to check if it is the same as in my own
>>>>> implementation.
>>>>>
>>>>> To do so, I print out one of the intermediate matrix that is generated
>>>>> in rtkCudaBackProjectionImageFilter while launching a SART reconstruction
>>>>> for instance.
>>>>>
>>>>> I was surpised by the fact that, the matrix allowing the
>>>>> transformation from 2D geometric world to 2D image index world, namely
>>>>> matrixIdxProj in rtkCudaBackProjectionImageFilte.cxx
>>>>> <http://www.openrtk.org/Doxygen/rtkCudaBackProjectionImageFilter_8cxx_source.html>
>>>>> is not always the same along the reconstruction process ?
>>>>>
>>>>> Here is the line that generates the matrix I don't understand:
>>>>>
>>>>> for(unsigned int i=0; i<2; i++)
>>>>>  //SR: 0.5 for 2D texture
>>>>>   matrixIdxProj[i][2] =
>>>>> -1*(this->GetInput(1)->GetBufferedRegion().GetIndex()[i])+0.5;
>>>>>
>>>>> What I understand here, is that, we are generating a 2D translation
>>>>> matrix embedded in a 3*3 matrix that allows to take into account two things
>>>>> related to the 2D projection:
>>>>>
>>>>> -If the internal behaviour of the imageContainer, allows buffering of
>>>>> only a part of the image, beginning at index (i,j), this information will
>>>>> be embeded in the projection matrix
>>>>>
>>>>> -the ITK floating point addressing definition seems to differ from the
>>>>> one from cuda (and openCV):
>>>>> When I take a look at this page
>>>>> <http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#texture-fetching>
>>>>> I understand that the floating point indexing (0.5,0.5) in Cuda points to
>>>>> the center of the pixel (0,0) hence a linear contribution of 100%, while it
>>>>> seems that we must add a translation of (0.5,0.5) to the ITK geometric
>>>>> framework in order to get the same behaviour.
>>>>>
>>>>> In practice matrixIdxProj is based on a 3*3 identity matrix, where
>>>>> the inner 2D translation (ie 2 first term of the last column) in my case
>>>>> are:
>>>>> -in X, a random number between 10 and 150 plus 0.5
>>>>> -in Y: always 0.5
>>>>>
>>>>> I understand the 0.5 part, but why is there always a 0 offset in Y but
>>>>> a random offset in X remains a mystery to me.
>>>>>
>>>>> At first, I believed that each projection was splitted into multiple
>>>>> part, each having a different X and Y offset.
>>>>> But reconstructing using only one projection generates only one
>>>>> backprojection operation, with a non zero offset in X, 123 in my case, for
>>>>> an image of size 780 in X.
>>>>>
>>>>> Do you think there is something wrong whith the values of matrixIdxProjI
>>>>> am experiencing ?
>>>>>
>>>>> Thank you in advance.
>>>>>
>>>>> Kind regards
>>>>>
>>>>> Thibault Notargiacomo
>>>>>
>>>>> _______________________________________________
>>>>> 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/20151110/b7eba683/attachment-0001.html>

From theday79 at gmail.com  Wed Nov 11 13:50:45 2015
From: theday79 at gmail.com (Yang K Park)
Date: Wed, 11 Nov 2015 13:50:45 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after  a recent update
Message-ID: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>

Hi all,

 

I?ve updated rtk with the up-to-date revision and have encountered a couple of problems.

 

1.       Compile error: RTK couldn?t find itkMacro.h while it compiled rtkCudaUtilities.hcu. It was solved by a minor fetching:

#include <itkMacro.h>   --> #include "itkMacro.h" in rtkCudaUtilities.hcu

 

2.       Output of rtkfdk with CUDA was not the same as before. It was very blurry as seen in the attached image.

a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.

 

 

I?m using VS2013 with win7, itk4.8.1.

 

The command line I used was :

rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware cuda --pad 1 --hann 5 --hannY 5

 

Does anyone have any idea about this?

 

Thanks.

 

Yang

 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151111/b1c7df5f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 16577 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151111/b1c7df5f/attachment-0001.png>

From simon.rit at creatis.insa-lyon.fr  Wed Nov 11 16:15:49 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Wed, 11 Nov 2015 22:15:49 +0100
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
Message-ID: <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>

Hi,
I didn't manage to reproduce the two problems on linux with the same
ITK version.
For point 1, did you copy itkMacro.h by hand? Because I don't see how
replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not
in the same folder as rtkCudaUtilities.hcu
For point 2, no clue. Do you use FFTW? It looks like a ramp filter
issue. Can you try rtkramp --path projPath --regexp .*.his, with and
without --hardware cuda? Maybe you can provide your geometry file in
case it's a specific geometric issue.
Simon

On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
> Hi all,
>
>
>
> I?ve updated rtk with the up-to-date revision and have encountered a couple
> of problems.
>
>
>
> 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
> rtkCudaUtilities.hcu. It was solved by a minor fetching:
>
> #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>
>
>
> 2.       Output of rtkfdk with CUDA was not the same as before. It was very
> blurry as seen in the attached image.
>
> a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>
>
>
>
>
> I?m using VS2013 with win7, itk4.8.1.
>
>
>
> The command line I used was :
>
> rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his --output
> output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware cuda --pad 1
> --hann 5 --hannY 5
>
>
>
> Does anyone have any idea about this?
>
>
>
> Thanks.
>
>
>
> Yang
>
>
>
>
> _______________________________________________
> Rtk-users mailing list
> Rtk-users at public.kitware.com
> http://public.kitware.com/mailman/listinfo/rtk-users
>

From theday79 at gmail.com  Thu Nov 12 17:39:38 2015
From: theday79 at gmail.com (Yang K Park)
Date: Thu, 12 Nov 2015 17:39:38 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
Message-ID: <000001d11d9b$04142320$0c3c6960$@gmail.com>

Hi Simon,

 

Thanks for the advice. The current RTK was compiled with FFTW to use the phase extraction feature from Amsterdam shroud.

 

Regarding your suggestions,

 

1)      rtkramp w/ or w/o CUDA:

(command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda --output Ramp_wCUDA.mha? )

 

Then, I have encountered following error.

?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that input requested and buffered regions are equal.?

 



 

Without CUDA, it was successfully done.

 

2)      I?ve re-compiled ITK w/o FFTW and built RTK again. rtkfdk worked fine.

-          I?ve also repeated ?rtkramp+CUDA? with this rtk version and the error was same as above.

 

In conclusion, my FFTW seems to affect CUDA-based fdk reconstruction only.

But I do need FFTW for the phase extraction. What should I do?

 

Thanks.

 

Yang

 

 

-----Original Message-----
From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit
Sent: Wednesday, November 11, 2015 4:16 PM
To: Yang K Park <theday79 at gmail.com>
Cc: rtk-users at openrtk.org
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

I didn't manage to reproduce the two problems on linux with the same ITK version.

For point 1, did you copy itkMacro.h by hand? Because I don't see how replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW? It looks like a ramp filter issue. Can you try rtkramp --path projPath --regexp .*.his, with and without --hardware cuda? Maybe you can provide your geometry file in case it's a specific geometric issue.

Simon

 

On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park < <mailto:theday79 at gmail.com> theday79 at gmail.com> wrote:

> Hi all,

> 

> 

> 

> I?ve updated rtk with the up-to-date revision and have encountered a 

> couple of problems.

> 

> 

> 

> 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled

> rtkCudaUtilities.hcu. It was solved by a minor fetching:

> 

> #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu

> 

> 

> 

> 2.       Output of rtkfdk with CUDA was not the same as before. It was very

> blurry as seen in the attached image.

> 

> a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.

> 

> 

> 

> 

> 

> I?m using VS2013 with win7, itk4.8.1.

> 

> 

> 

> The command line I used was :

> 

> rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his 

> --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware 

> cuda --pad 1 --hann 5 --hannY 5

> 

> 

> 

> Does anyone have any idea about this?

> 

> 

> 

> Thanks.

> 

> 

> 

> Yang

> 

> 

> 

> 

> _______________________________________________

> Rtk-users mailing list

>  <mailto: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/20151112/4e0825dc/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151112/4e0825dc/attachment.png>

From simon.rit at creatis.insa-lyon.fr  Thu Nov 12 17:58:42 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Thu, 12 Nov 2015 23:58:42 +0100
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <000001d11d9b$04142320$0c3c6960$@gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
Message-ID: <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>

Hi,
Ok. Can you try rtkramp with only one projection? Then you shouldn't
encounter this regions issue (that should be solved one day but that's a
different story).
Can you also indicate which version of CUDA you're using?
FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft for
the FFT of the projections. So if they are not in the same format, you're
in trouble and that might be the issue here... The weird part is that I
didn't reproduce this problem on linux (with and without FFTW) but it might
be a CUDA version difference. I'll give it another try tomorrow when you
provide the CUDA version.
Thanks again for reporting the issue,
Simon

On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com> wrote:

> Hi Simon,
>
>
>
> Thanks for the advice. The current RTK was compiled with FFTW to use the
> phase extraction feature from Amsterdam shroud.
>
>
>
> Regarding your suggestions,
>
>
>
> 1)      rtkramp w/ or w/o CUDA:
>
> (command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda
> --output Ramp_wCUDA.mha? )
>
>
>
> Then, I have encountered following error.
>
> ?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that
> input requested and buffered regions are equal.?
>
>
>
>
>
> Without CUDA, it was successfully done.
>
>
>
> 2)      I?ve re-compiled *ITK w/o FFTW* and built RTK again. r*tkfdk
> worked fine.*
>
> -          I?ve also repeated ?rtkramp+CUDA? with this rtk version and
> the error was same as above.
>
>
>
> In conclusion, my *FFTW seems to affect CUDA-based fdk reconstruction
> only*.
>
> But I do need FFTW for the phase extraction. What should I do?
>
>
>
> Thanks.
>
>
>
> Yang
>
>
>
>
>
> -----Original Message-----
> From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon
> Rit
> Sent: Wednesday, November 11, 2015 4:16 PM
> To: Yang K Park <theday79 at gmail.com>
> Cc: rtk-users at openrtk.org
> Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
> update
>
>
>
> Hi,
>
> I didn't manage to reproduce the two problems on linux with the same ITK
> version.
>
> For point 1, did you copy itkMacro.h by hand? Because I don't see how
> replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the
> same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW?
> It looks like a ramp filter issue. Can you try rtkramp --path projPath
> --regexp .*.his, with and without --hardware cuda? Maybe you can provide
> your geometry file in case it's a specific geometric issue.
>
> Simon
>
>
>
> On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
>
> > Hi all,
>
> >
>
> >
>
> >
>
> > I?ve updated rtk with the up-to-date revision and have encountered a
>
> > couple of problems.
>
> >
>
> >
>
> >
>
> > 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
>
> > rtkCudaUtilities.hcu. It was solved by a minor fetching:
>
> >
>
> > #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>
> >
>
> >
>
> >
>
> > 2.       Output of rtkfdk with CUDA was not the same as before. It was
> very
>
> > blurry as seen in the attached image.
>
> >
>
> > a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > I?m using VS2013 with win7, itk4.8.1.
>
> >
>
> >
>
> >
>
> > The command line I used was :
>
> >
>
> > rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his
>
> > --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware
>
> > cuda --pad 1 --hann 5 --hannY 5
>
> >
>
> >
>
> >
>
> > Does anyone have any idea about this?
>
> >
>
> >
>
> >
>
> > Thanks.
>
> >
>
> >
>
> >
>
> > Yang
>
> >
>
> >
>
> >
>
> >
>
> > _______________________________________________
>
> > 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/20151112/e7c15ff8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151112/e7c15ff8/attachment-0001.png>

From theday79 at gmail.com  Mon Nov 16 09:54:01 2015
From: theday79 at gmail.com (Yang K Park)
Date: Mon, 16 Nov 2015 09:54:01 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
Message-ID: <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>

Hi Simon,

 

Sorry for the late response.

 

As you suggested, I?ve tried rtkramp+CUDA with only one projection and it was successfully done for both w/ FFTW and w/o FFTW.

(Two results were exactly same.)

 

Regarding  the CUDA version, I?m using v6.5.

 

Thanks a lot for the help!

 

Yang

 

 

From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit
Sent: Thursday, November 12, 2015 5:59 PM
To: Yang K Park <theday79 at gmail.com>
Cc: rtk-users at openrtk.org
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

Ok. Can you try rtkramp with only one projection? Then you shouldn't encounter this regions issue (that should be solved one day but that's a different story). 

Can you also indicate which version of CUDA you're using?

FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft for the FFT of the projections. So if they are not in the same format, you're in trouble and that might be the issue here... The weird part is that I didn't reproduce this problem on linux (with and without FFTW) but it might be a CUDA version difference. I'll give it another try tomorrow when you provide the CUDA version.

Thanks again for reporting the issue,
Simon

 

On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> > wrote:

Hi Simon,

 

Thanks for the advice. The current RTK was compiled with FFTW to use the phase extraction feature from Amsterdam shroud.

 

Regarding your suggestions,

 

1)      rtkramp w/ or w/o CUDA:

(command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda --output Ramp_wCUDA.mha? )

 

Then, I have encountered following error.

?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that input requested and buffered regions are equal.?

 



 

Without CUDA, it was successfully done.

 

2)      I?ve re-compiled ITK w/o FFTW and built RTK again. rtkfdk worked fine.

-          I?ve also repeated ?rtkramp+CUDA? with this rtk version and the error was same as above.

 

In conclusion, my FFTW seems to affect CUDA-based fdk reconstruction only.

But I do need FFTW for the phase extraction. What should I do?

 

Thanks.

 

Yang

 

 

-----Original Message-----
From: simon.rit at gmail.com <mailto:simon.rit at gmail.com>  [mailto:simon.rit at gmail.com <mailto:simon.rit at gmail.com> ] On Behalf Of Simon Rit
Sent: Wednesday, November 11, 2015 4:16 PM
To: Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> >
Cc: rtk-users at openrtk.org <mailto:rtk-users at openrtk.org> 
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

I didn't manage to reproduce the two problems on linux with the same ITK version.

For point 1, did you copy itkMacro.h by hand? Because I don't see how replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW? It looks like a ramp filter issue. Can you try rtkramp --path projPath --regexp .*.his, with and without --hardware cuda? Maybe you can provide your geometry file in case it's a specific geometric issue.

Simon

 

On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park < <mailto:theday79 at gmail.com> theday79 at gmail.com> wrote:

> Hi all,

> 

> 

> 

> I?ve updated rtk with the up-to-date revision and have encountered a 

> couple of problems.

> 

> 

> 

> 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled

> rtkCudaUtilities.hcu. It was solved by a minor fetching:

> 

> #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu

> 

> 

> 

> 2.       Output of rtkfdk with CUDA was not the same as before. It was very

> blurry as seen in the attached image.

> 

> a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.

> 

> 

> 

> 

> 

> I?m using VS2013 with win7, itk4.8.1.

> 

> 

> 

> The command line I used was :

> 

> rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his 

> --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware 

> cuda --pad 1 --hann 5 --hannY 5

> 

> 

> 

> Does anyone have any idea about this?

> 

> 

> 

> Thanks.

> 

> 

> 

> Yang

> 

> 

> 

> 

> _______________________________________________

> Rtk-users mailing list

>  <mailto: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/20151116/e77c2f96/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151116/e77c2f96/attachment.png>

From simon.rit at creatis.insa-lyon.fr  Mon Nov 16 10:07:46 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Mon, 16 Nov 2015 16:07:46 +0100
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
 <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
Message-ID: <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>

Hi,
Thanks. It's really weird... When you run the tests with FFTW (compiling
the "test" target), do they fail?
Can you provide your geometry file? It might be specific to this geometry.
Thanks again for looking into this issue, we'll find what's the problem.
Simon

On Mon, Nov 16, 2015 at 3:54 PM, Yang K Park <theday79 at gmail.com> wrote:

> Hi Simon,
>
>
>
> Sorry for the late response.
>
>
>
> As you suggested, I?ve tried rtkramp+CUDA with only one projection and it
> was successfully done for both w/ FFTW and w/o FFTW.
>
> (Two results were exactly same.)
>
>
>
> Regarding  the CUDA version, I?m using v6.5.
>
>
>
> Thanks a lot for the help!
>
>
>
> Yang
>
>
>
>
>
> *From:* simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of *Simon
> Rit
> *Sent:* Thursday, November 12, 2015 5:59 PM
>
> *To:* Yang K Park <theday79 at gmail.com>
> *Cc:* rtk-users at openrtk.org
> *Subject:* Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
> update
>
>
>
> Hi,
>
> Ok. Can you try rtkramp with only one projection? Then you shouldn't
> encounter this regions issue (that should be solved one day but that's a
> different story).
>
> Can you also indicate which version of CUDA you're using?
>
> FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft for
> the FFT of the projections. So if they are not in the same format, you're
> in trouble and that might be the issue here... The weird part is that I
> didn't reproduce this problem on linux (with and without FFTW) but it might
> be a CUDA version difference. I'll give it another try tomorrow when you
> provide the CUDA version.
>
> Thanks again for reporting the issue,
> Simon
>
>
>
> On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com> wrote:
>
> Hi Simon,
>
>
>
> Thanks for the advice. The current RTK was compiled with FFTW to use the
> phase extraction feature from Amsterdam shroud.
>
>
>
> Regarding your suggestions,
>
>
>
> 1)      rtkramp w/ or w/o CUDA:
>
> (command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda
> --output Ramp_wCUDA.mha? )
>
>
>
> Then, I have encountered following error.
>
> ?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that
> input requested and buffered regions are equal.?
>
>
>
>
>
> Without CUDA, it was successfully done.
>
>
>
> 2)      I?ve re-compiled *ITK w/o FFTW* and built RTK again. r*tkfdk
> worked fine.*
>
> -          I?ve also repeated ?rtkramp+CUDA? with this rtk version and
> the error was same as above.
>
>
>
> In conclusion, my *FFTW seems to affect CUDA-based fdk reconstruction
> only*.
>
> But I do need FFTW for the phase extraction. What should I do?
>
>
>
> Thanks.
>
>
>
> Yang
>
>
>
>
>
> -----Original Message-----
> From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon
> Rit
> Sent: Wednesday, November 11, 2015 4:16 PM
> To: Yang K Park <theday79 at gmail.com>
> Cc: rtk-users at openrtk.org
> Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
> update
>
>
>
> Hi,
>
> I didn't manage to reproduce the two problems on linux with the same ITK
> version.
>
> For point 1, did you copy itkMacro.h by hand? Because I don't see how
> replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the
> same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW?
> It looks like a ramp filter issue. Can you try rtkramp --path projPath
> --regexp .*.his, with and without --hardware cuda? Maybe you can provide
> your geometry file in case it's a specific geometric issue.
>
> Simon
>
>
>
> On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
>
> > Hi all,
>
> >
>
> >
>
> >
>
> > I?ve updated rtk with the up-to-date revision and have encountered a
>
> > couple of problems.
>
> >
>
> >
>
> >
>
> > 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
>
> > rtkCudaUtilities.hcu. It was solved by a minor fetching:
>
> >
>
> > #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>
> >
>
> >
>
> >
>
> > 2.       Output of rtkfdk with CUDA was not the same as before. It was
> very
>
> > blurry as seen in the attached image.
>
> >
>
> > a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > I?m using VS2013 with win7, itk4.8.1.
>
> >
>
> >
>
> >
>
> > The command line I used was :
>
> >
>
> > rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his
>
> > --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware
>
> > cuda --pad 1 --hann 5 --hannY 5
>
> >
>
> >
>
> >
>
> > Does anyone have any idea about this?
>
> >
>
> >
>
> >
>
> > Thanks.
>
> >
>
> >
>
> >
>
> > Yang
>
> >
>
> >
>
> >
>
> >
>
> > _______________________________________________
>
> > 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/20151116/38acfca5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151116/38acfca5/attachment-0001.png>

From theday79 at gmail.com  Mon Nov 16 10:47:43 2015
From: theday79 at gmail.com (Yang-Kyun Park)
Date: Mon, 16 Nov 2015 10:47:43 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
 <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
 <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>
Message-ID: <CAJM7=xjBjx=FzLazWJWqJbV5d45zGi2U71NKejm9HxKhJ0-xLQ@mail.gmail.com>

Hi Simon,

For better understanding, I'm attaching the problematic case including
projection files, geometry file(xml) and reconstructed images.(please find
the GDrive links. The file size is ~800 MB)
This is phantom data and there is no patient information in it.

Regarding the fftw library, I'm using [fftw-3.3.4-dll64].

By the way, I found another clue. When I've tried it with a head phantom
image (full-fan, ~ 190 projections), there was no problem. Is there any
possibility that DDF and parker short filter play some roles on this issue?

Feel free to let me know if further data is needed.

Thanks!

Yang

?
 FFTW_issue.zip
<https://drive.google.com/file/d/0BxuP3mON9V-qbVdQd0luc1lIb2M/view?usp=drive_web>
?

On Mon, Nov 16, 2015 at 10:07 AM, Simon Rit <simon.rit at creatis.insa-lyon.fr>
wrote:

> Hi,
> Thanks. It's really weird... When you run the tests with FFTW (compiling
> the "test" target), do they fail?
> Can you provide your geometry file? It might be specific to this geometry.
> Thanks again for looking into this issue, we'll find what's the problem.
> Simon
>
> On Mon, Nov 16, 2015 at 3:54 PM, Yang K Park <theday79 at gmail.com> wrote:
>
>> Hi Simon,
>>
>>
>>
>> Sorry for the late response.
>>
>>
>>
>> As you suggested, I?ve tried rtkramp+CUDA with only one projection and it
>> was successfully done for both w/ FFTW and w/o FFTW.
>>
>> (Two results were exactly same.)
>>
>>
>>
>> Regarding  the CUDA version, I?m using v6.5.
>>
>>
>>
>> Thanks a lot for the help!
>>
>>
>>
>> Yang
>>
>>
>>
>>
>>
>> *From:* simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of *Simon
>> Rit
>> *Sent:* Thursday, November 12, 2015 5:59 PM
>>
>> *To:* Yang K Park <theday79 at gmail.com>
>> *Cc:* rtk-users at openrtk.org
>> *Subject:* Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
>> update
>>
>>
>>
>> Hi,
>>
>> Ok. Can you try rtkramp with only one projection? Then you shouldn't
>> encounter this regions issue (that should be solved one day but that's a
>> different story).
>>
>> Can you also indicate which version of CUDA you're using?
>>
>> FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft
>> for the FFT of the projections. So if they are not in the same format,
>> you're in trouble and that might be the issue here... The weird part is
>> that I didn't reproduce this problem on linux (with and without FFTW) but
>> it might be a CUDA version difference. I'll give it another try tomorrow
>> when you provide the CUDA version.
>>
>> Thanks again for reporting the issue,
>> Simon
>>
>>
>>
>> On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com> wrote:
>>
>> Hi Simon,
>>
>>
>>
>> Thanks for the advice. The current RTK was compiled with FFTW to use the
>> phase extraction feature from Amsterdam shroud.
>>
>>
>>
>> Regarding your suggestions,
>>
>>
>>
>> 1)      rtkramp w/ or w/o CUDA:
>>
>> (command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda
>> --output Ramp_wCUDA.mha? )
>>
>>
>>
>> Then, I have encountered following error.
>>
>> ?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that
>> input requested and buffered regions are equal.?
>>
>>
>>
>>
>>
>> Without CUDA, it was successfully done.
>>
>>
>>
>> 2)      I?ve re-compiled *ITK w/o FFTW* and built RTK again. r*tkfdk
>> worked fine.*
>>
>> -          I?ve also repeated ?rtkramp+CUDA? with this rtk version and
>> the error was same as above.
>>
>>
>>
>> In conclusion, my *FFTW seems to affect CUDA-based fdk reconstruction
>> only*.
>>
>> But I do need FFTW for the phase extraction. What should I do?
>>
>>
>>
>> Thanks.
>>
>>
>>
>> Yang
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of
>> Simon Rit
>> Sent: Wednesday, November 11, 2015 4:16 PM
>> To: Yang K Park <theday79 at gmail.com>
>> Cc: rtk-users at openrtk.org
>> Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
>> update
>>
>>
>>
>> Hi,
>>
>> I didn't manage to reproduce the two problems on linux with the same ITK
>> version.
>>
>> For point 1, did you copy itkMacro.h by hand? Because I don't see how
>> replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the
>> same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW?
>> It looks like a ramp filter issue. Can you try rtkramp --path projPath
>> --regexp .*.his, with and without --hardware cuda? Maybe you can provide
>> your geometry file in case it's a specific geometric issue.
>>
>> Simon
>>
>>
>>
>> On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
>>
>> > Hi all,
>>
>> >
>>
>> >
>>
>> >
>>
>> > I?ve updated rtk with the up-to-date revision and have encountered a
>>
>> > couple of problems.
>>
>> >
>>
>> >
>>
>> >
>>
>> > 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
>>
>> > rtkCudaUtilities.hcu. It was solved by a minor fetching:
>>
>> >
>>
>> > #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>>
>> >
>>
>> >
>>
>> >
>>
>> > 2.       Output of rtkfdk with CUDA was not the same as before. It was
>> very
>>
>> > blurry as seen in the attached image.
>>
>> >
>>
>> > a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>
>> > I?m using VS2013 with win7, itk4.8.1.
>>
>> >
>>
>> >
>>
>> >
>>
>> > The command line I used was :
>>
>> >
>>
>> > rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his
>>
>> > --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware
>>
>> > cuda --pad 1 --hann 5 --hannY 5
>>
>> >
>>
>> >
>>
>> >
>>
>> > Does anyone have any idea about this?
>>
>> >
>>
>> >
>>
>> >
>>
>> > Thanks.
>>
>> >
>>
>> >
>>
>> >
>>
>> > Yang
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>
>> > _______________________________________________
>>
>> > 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/20151116/90d2c5a0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151116/90d2c5a0/attachment-0001.png>

From simon.rit at creatis.insa-lyon.fr  Fri Nov 20 11:28:22 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Fri, 20 Nov 2015 17:28:22 +0100
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAJM7=xjBjx=FzLazWJWqJbV5d45zGi2U71NKejm9HxKhJ0-xLQ@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
 <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
 <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>
 <CAJM7=xjBjx=FzLazWJWqJbV5d45zGi2U71NKejm9HxKhJ0-xLQ@mail.gmail.com>
Message-ID: <CAF0oig027_u_9gb8bnwT1w9jr3epZ0hkd9Mt73qK5heUq_kCkg@mail.gmail.com>

Hi Yang,
Thanks a lot for sharing the data. I have good news. I could reproduce the
bug and I have solutions. First, about your dataset: it's a huge dataset
and the hannY requires zero padding in both x and y. Because of this, cufft
has to take the 2D FFT of projection subsets that are 4095x2048x16. Quite
big!
When I ran it on my cuda 7.0, I immediately got:

itk::ExceptionObject (0x8b9cb30)
Location: "void CUDA_fft_convolution(const int3&, const int2&, float*,
cufftComplex*)"
File: /home/srit/src/rtk/rtk/code/rtkCudaFFTConvolutionImageFilter.cu
Line: 97
Description: itk::ERROR: CUFFT ERROR #2

i.e., a GPU alloc issue, even if I have the largest possible memory on a
nvidia desktop computer. Then, I ran it with cuda 6.5 and I got no error
message but a result similar to yours.
Conclusions:
- if you add the option --subsetsize 1 to your rtkfdk command line, that
should reconstruct correctly
- if you upgrade cuda, you should get an understandable error message,
- I don't think I'm going to look for a solution because the pb is probably
in cufft but if someone is willing to, be my guest!
Simon

On Mon, Nov 16, 2015 at 4:47 PM, Yang-Kyun Park <theday79 at gmail.com> wrote:

> Hi Simon,
>
> For better understanding, I'm attaching the problematic case including
> projection files, geometry file(xml) and reconstructed images.(please find
> the GDrive links. The file size is ~800 MB)
> This is phantom data and there is no patient information in it.
>
> Regarding the fftw library, I'm using [fftw-3.3.4-dll64].
>
> By the way, I found another clue. When I've tried it with a head phantom
> image (full-fan, ~ 190 projections), there was no problem. Is there any
> possibility that DDF and parker short filter play some roles on this issue?
>
> Feel free to let me know if further data is needed.
>
> Thanks!
>
> Yang
>
> ?
>  FFTW_issue.zip
> <https://drive.google.com/file/d/0BxuP3mON9V-qbVdQd0luc1lIb2M/view?usp=drive_web>
> ?
>
> On Mon, Nov 16, 2015 at 10:07 AM, Simon Rit <
> simon.rit at creatis.insa-lyon.fr> wrote:
>
>> Hi,
>> Thanks. It's really weird... When you run the tests with FFTW (compiling
>> the "test" target), do they fail?
>> Can you provide your geometry file? It might be specific to this geometry.
>> Thanks again for looking into this issue, we'll find what's the problem.
>> Simon
>>
>> On Mon, Nov 16, 2015 at 3:54 PM, Yang K Park <theday79 at gmail.com> wrote:
>>
>>> Hi Simon,
>>>
>>>
>>>
>>> Sorry for the late response.
>>>
>>>
>>>
>>> As you suggested, I?ve tried rtkramp+CUDA with only one projection and
>>> it was successfully done for both w/ FFTW and w/o FFTW.
>>>
>>> (Two results were exactly same.)
>>>
>>>
>>>
>>> Regarding  the CUDA version, I?m using v6.5.
>>>
>>>
>>>
>>> Thanks a lot for the help!
>>>
>>>
>>>
>>> Yang
>>>
>>>
>>>
>>>
>>>
>>> *From:* simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of *Simon
>>> Rit
>>> *Sent:* Thursday, November 12, 2015 5:59 PM
>>>
>>> *To:* Yang K Park <theday79 at gmail.com>
>>> *Cc:* rtk-users at openrtk.org
>>> *Subject:* Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
>>> update
>>>
>>>
>>>
>>> Hi,
>>>
>>> Ok. Can you try rtkramp with only one projection? Then you shouldn't
>>> encounter this regions issue (that should be solved one day but that's a
>>> different story).
>>>
>>> Can you also indicate which version of CUDA you're using?
>>>
>>> FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft
>>> for the FFT of the projections. So if they are not in the same format,
>>> you're in trouble and that might be the issue here... The weird part is
>>> that I didn't reproduce this problem on linux (with and without FFTW) but
>>> it might be a CUDA version difference. I'll give it another try tomorrow
>>> when you provide the CUDA version.
>>>
>>> Thanks again for reporting the issue,
>>> Simon
>>>
>>>
>>>
>>> On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com>
>>> wrote:
>>>
>>> Hi Simon,
>>>
>>>
>>>
>>> Thanks for the advice. The current RTK was compiled with FFTW to use the
>>> phase extraction feature from Amsterdam shroud.
>>>
>>>
>>>
>>> Regarding your suggestions,
>>>
>>>
>>>
>>> 1)      rtkramp w/ or w/o CUDA:
>>>
>>> (command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda
>>> --output Ramp_wCUDA.mha? )
>>>
>>>
>>>
>>> Then, I have encountered following error.
>>>
>>> ?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that
>>> input requested and buffered regions are equal.?
>>>
>>>
>>>
>>>
>>>
>>> Without CUDA, it was successfully done.
>>>
>>>
>>>
>>> 2)      I?ve re-compiled *ITK w/o FFTW* and built RTK again. r*tkfdk
>>> worked fine.*
>>>
>>> -          I?ve also repeated ?rtkramp+CUDA? with this rtk version and
>>> the error was same as above.
>>>
>>>
>>>
>>> In conclusion, my *FFTW seems to affect CUDA-based fdk reconstruction
>>> only*.
>>>
>>> But I do need FFTW for the phase extraction. What should I do?
>>>
>>>
>>>
>>> Thanks.
>>>
>>>
>>>
>>> Yang
>>>
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of
>>> Simon Rit
>>> Sent: Wednesday, November 11, 2015 4:16 PM
>>> To: Yang K Park <theday79 at gmail.com>
>>> Cc: rtk-users at openrtk.org
>>> Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
>>> update
>>>
>>>
>>>
>>> Hi,
>>>
>>> I didn't manage to reproduce the two problems on linux with the same ITK
>>> version.
>>>
>>> For point 1, did you copy itkMacro.h by hand? Because I don't see how
>>> replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the
>>> same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW?
>>> It looks like a ramp filter issue. Can you try rtkramp --path projPath
>>> --regexp .*.his, with and without --hardware cuda? Maybe you can provide
>>> your geometry file in case it's a specific geometric issue.
>>>
>>> Simon
>>>
>>>
>>>
>>> On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
>>>
>>> > Hi all,
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > I?ve updated rtk with the up-to-date revision and have encountered a
>>>
>>> > couple of problems.
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
>>>
>>> > rtkCudaUtilities.hcu. It was solved by a minor fetching:
>>>
>>> >
>>>
>>> > #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > 2.       Output of rtkfdk with CUDA was not the same as before. It was
>>> very
>>>
>>> > blurry as seen in the attached image.
>>>
>>> >
>>>
>>> > a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > I?m using VS2013 with win7, itk4.8.1.
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > The command line I used was :
>>>
>>> >
>>>
>>> > rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his
>>>
>>> > --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware
>>>
>>> > cuda --pad 1 --hann 5 --hannY 5
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > Does anyone have any idea about this?
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > Thanks.
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > Yang
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > _______________________________________________
>>>
>>> > 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/20151120/4e6c0e1e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151120/4e6c0e1e/attachment-0001.png>

From theday79 at gmail.com  Fri Nov 20 12:36:51 2015
From: theday79 at gmail.com (Yang K Park)
Date: Fri, 20 Nov 2015 12:36:51 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAF0oig027_u_9gb8bnwT1w9jr3epZ0hkd9Mt73qK5heUq_kCkg@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
 <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
 <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>
 <CAJM7=xjBjx=FzLazWJWqJbV5d45zGi2U71NKejm9HxKhJ0-xLQ@mail.gmail.com>
 <CAF0oig027_u_9gb8bnwT1w9jr3epZ0hkd9Mt73qK5heUq_kCkg@mail.gmail.com>
Message-ID: <000901d123ba$0ae3de50$20ab9af0$@gmail.com>

Hi Simon,

 

That sounds great! Thanks a lot for your hard work.

As you said, now I can reconstruct it successfully with --subsetsize option.

 

I think the only concern left is the elongated reconstruction time.

I?ve measured it for the same phantom image with different ?subsetsize? values as well as w/o FFTW compiling.

I just report it for your information.

 

1)      w/o FFTW  : 21.4 s

2)      w/ FFTW & --subsetsize 1: 89 s

3)      w/ FFTW & --subsetsize 2: 77 s

4)      w/ FFTW & --subsetsize 4: 65 s

5)      w/ FFTW & --subsetsize 6: 51 s

6)      w/ FFTW & --subsetsize 7: (Error-graphic card seemed to be freezed)

7)      w/ FFTW & --subsetsize 8: (Error-?itk::ERROR: CUFFT ERROR #2 in rtkCudaFFTConvolutionImageFilter.cu?)

 

Of course, the difference was coming from the Ramp filter.

Therefore, I?m going to use [--subsetsize 6] for my system and will update CUDA version soon!

 

Thanks.

 

Yang

 

 

From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit
Sent: Friday, November 20, 2015 11:28 AM
To: Yang-Kyun Park <theday79 at gmail.com>
Cc: rtk-users at openrtk.org
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi Yang,
Thanks a lot for sharing the data. I have good news. I could reproduce the bug and I have solutions. First, about your dataset: it's a huge dataset and the hannY requires zero padding in both x and y. Because of this, cufft has to take the 2D FFT of projection subsets that are 4095x2048x16. Quite big!

When I ran it on my cuda 7.0, I immediately got:

itk::ExceptionObject (0x8b9cb30)
Location: "void CUDA_fft_convolution(const int3&, const int2&, float*, cufftComplex*)" 
File: /home/srit/src/rtk/rtk/code/rtkCudaFFTConvolutionImageFilter.cu
Line: 97
Description: itk::ERROR: CUFFT ERROR #2

i.e., a GPU alloc issue, even if I have the largest possible memory on a nvidia desktop computer. Then, I ran it with cuda 6.5 and I got no error message but a result similar to yours.

Conclusions:

- if you add the option --subsetsize 1 to your rtkfdk command line, that should reconstruct correctly

- if you upgrade cuda, you should get an understandable error message,

- I don't think I'm going to look for a solution because the pb is probably in cufft but if someone is willing to, be my guest!

Simon

 

On Mon, Nov 16, 2015 at 4:47 PM, Yang-Kyun Park <theday79 at gmail.com <mailto:theday79 at gmail.com> > wrote:

Hi Simon,

 

For better understanding, I'm attaching the problematic case including projection files, geometry file(xml) and reconstructed images.(please find the GDrive links. The file size is ~800 MB)

This is phantom data and there is no patient information in it.

 

Regarding the fftw library, I'm using [fftw-3.3.4-dll64].

 

By the way, I found another clue. When I've tried it with a head phantom image (full-fan, ~ 190 projections), there was no problem. Is there any possibility that DDF and parker short filter play some roles on this issue?

 

Feel free to let me know if further data is needed.

 

Thanks!

 

Yang

 

?

 <https://drive.google.com/file/d/0BxuP3mON9V-qbVdQd0luc1lIb2M/view?usp=drive_web>  FFTW_issue.zip

?

 

On Mon, Nov 16, 2015 at 10:07 AM, Simon Rit <simon.rit at creatis.insa-lyon.fr <mailto:simon.rit at creatis.insa-lyon.fr> > wrote:

Hi,

Thanks. It's really weird... When you run the tests with FFTW (compiling the "test" target), do they fail?
Can you provide your geometry file? It might be specific to this geometry.

Thanks again for looking into this issue, we'll find what's the problem.

Simon

 

On Mon, Nov 16, 2015 at 3:54 PM, Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> > wrote:

Hi Simon,

 

Sorry for the late response.

 

As you suggested, I?ve tried rtkramp+CUDA with only one projection and it was successfully done for both w/ FFTW and w/o FFTW.

(Two results were exactly same.)

 

Regarding  the CUDA version, I?m using v6.5.

 

Thanks a lot for the help!

 

Yang

 

 

From: simon.rit at gmail.com <mailto:simon.rit at gmail.com>  [mailto:simon.rit at gmail.com <mailto:simon.rit at gmail.com> ] On Behalf Of Simon Rit
Sent: Thursday, November 12, 2015 5:59 PM


To: Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> >
Cc: rtk-users at openrtk.org <mailto:rtk-users at openrtk.org> 
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

Ok. Can you try rtkramp with only one projection? Then you shouldn't encounter this regions issue (that should be solved one day but that's a different story). 

Can you also indicate which version of CUDA you're using?

FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft for the FFT of the projections. So if they are not in the same format, you're in trouble and that might be the issue here... The weird part is that I didn't reproduce this problem on linux (with and without FFTW) but it might be a CUDA version difference. I'll give it another try tomorrow when you provide the CUDA version.

Thanks again for reporting the issue,
Simon

 

On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> > wrote:

Hi Simon,

 

Thanks for the advice. The current RTK was compiled with FFTW to use the phase extraction feature from Amsterdam shroud.

 

Regarding your suggestions,

 

1)      rtkramp w/ or w/o CUDA:

(command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda --output Ramp_wCUDA.mha? )

 

Then, I have encountered following error.

?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that input requested and buffered regions are equal.?

 



 

Without CUDA, it was successfully done.

 

2)      I?ve re-compiled ITK w/o FFTW and built RTK again. rtkfdk worked fine.

-          I?ve also repeated ?rtkramp+CUDA? with this rtk version and the error was same as above.

 

In conclusion, my FFTW seems to affect CUDA-based fdk reconstruction only.

But I do need FFTW for the phase extraction. What should I do?

 

Thanks.

 

Yang

 

 

-----Original Message-----
From: simon.rit at gmail.com <mailto:simon.rit at gmail.com>  [mailto:simon.rit at gmail.com <mailto:simon.rit at gmail.com> ] On Behalf Of Simon Rit
Sent: Wednesday, November 11, 2015 4:16 PM
To: Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> >
Cc: rtk-users at openrtk.org <mailto:rtk-users at openrtk.org> 
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

I didn't manage to reproduce the two problems on linux with the same ITK version.

For point 1, did you copy itkMacro.h by hand? Because I don't see how replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW? It looks like a ramp filter issue. Can you try rtkramp --path projPath --regexp .*.his, with and without --hardware cuda? Maybe you can provide your geometry file in case it's a specific geometric issue.

Simon

 

On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park < <mailto:theday79 at gmail.com> theday79 at gmail.com> wrote:

> Hi all,

> 

> 

> 

> I?ve updated rtk with the up-to-date revision and have encountered a 

> couple of problems.

> 

> 

> 

> 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled

> rtkCudaUtilities.hcu. It was solved by a minor fetching:

> 

> #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu

> 

> 

> 

> 2.       Output of rtkfdk with CUDA was not the same as before. It was very

> blurry as seen in the attached image.

> 

> a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.

> 

> 

> 

> 

> 

> I?m using VS2013 with win7, itk4.8.1.

> 

> 

> 

> The command line I used was :

> 

> rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his 

> --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware 

> cuda --pad 1 --hann 5 --hannY 5

> 

> 

> 

> Does anyone have any idea about this?

> 

> 

> 

> Thanks.

> 

> 

> 

> Yang

> 

> 

> 

> 

> _______________________________________________

> Rtk-users mailing list

>  <mailto: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/20151120/0d98ace1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151120/0d98ace1/attachment-0001.png>

From simon.rit at creatis.insa-lyon.fr  Wed Nov 25 02:36:44 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Wed, 25 Nov 2015 08:36:44 +0100
Subject: [Rtk-users] Compiling Problem
In-Reply-To: <040e01d125c7$83648e60$8a2dab20$@126.com>
References: <040e01d125c7$83648e60$8a2dab20$@126.com>
Message-ID: <5655650C.1040500@creatis.insa-lyon.fr>

Hi,
Please use the mailing list. I don't know where does the linking problem 
come from and it seems to work on our side:
http://my.cdash.org/index.php?project=RTK
Have you tried disabling CUDA?
Simon

On 23/11/2015 09:18, Freyman li wrote:
>
> Dear Simon,
>
> Recently I configured the RTK tool and suffer some problems. After set 
> up the itk tool and cuda, I compiled the rtk application but 
> encountered two errors attached to the email(jpg format)
>
> CUDA and ITK environment are tested successfully. My compile tool is 
> Visual studio 2012(64bit) and CUDA version is v6.5.
>
> Can you tell me how to deal with it and I am looking forward to hear 
> you again.
>
> Thank you!
>
> Best Regards
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151125/285f7f3c/attachment.html>

From theday79 at gmail.com  Wed Nov 25 12:38:52 2015
From: theday79 at gmail.com (Yang K Park)
Date: Wed, 25 Nov 2015 12:38:52 -0500
Subject: [Rtk-users] Compiling Problem
In-Reply-To: <5655650C.1040500@creatis.insa-lyon.fr>
References: <040e01d125c7$83648e60$8a2dab20$@126.com>
 <5655650C.1040500@creatis.insa-lyon.fr>
Message-ID: <003d01d127a8$27a52b60$76ef8220$@gmail.com>

Hi Freyman,

 

I think your setting is much similar to mine, since I have compiled RTK with
VS2013 and CUDA v6.5 several times. Can you post those error messages again
so that I can see?

Yang

 

 

From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of
Simon Rit
Sent: Wednesday, November 25, 2015 2:37 AM
To: Freyman li <lihanwei_1500 at 126.com>
Cc: rtk-users at openrtk.org
Subject: Re: [Rtk-users] Compiling Problem

 

Hi,
Please use the mailing list. I don't know where does the linking problem
come from and it seems to work on our side:
http://my.cdash.org/index.php?project=RTK
Have you tried disabling CUDA?
Simon

On 23/11/2015 09:18, Freyman li wrote:

Dear Simon,

 

Recently I configured the RTK tool and suffer some problems. After set up
the itk tool and cuda, I compiled the rtk application but encountered two
errors attached to the email(jpg format)

CUDA and ITK environment are tested successfully. My compile tool is Visual
studio 2012(64bit) and CUDA version is v6.5.

Can you tell me how to deal with it and I am looking forward to hear you
again.

Thank you!

 

Best Regards

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151125/984feb50/attachment.html>

From bioniloofar at gmail.com  Mon Nov 30 06:06:41 2015
From: bioniloofar at gmail.com (niloufar teyfouri)
Date: Mon, 30 Nov 2015 14:36:41 +0330
Subject: [Rtk-users] ElectaReconstruction
Message-ID: <CALChM12F4PuiLvgENg3Yyn7E+uZ7iPJ+GiY04z7VQ-90AS83EA@mail.gmail.com>

I ran the application of Electa Reconstruction implemented by you with
RTK. But after debugging I was encountered with the message of
"--output' ('-o') option required". Could you please help me for running
this example and the other ones?
I don't know any thing about the texts in the gray boxes mentioned at
each link related to examples of RTK.
For example in the link of
http://wiki.openrtk.org/index.php/RTK/Examples/ElektaReconstruction
how I should use gengetopt for the instructions below?


2. Run the application to convert Elekta's geometry into RTKs (DICOM_UID
is contained in the subfolder name of the his files):

  rtkelektasynergygeometry \
    --image_db IMAGE.DBF \
    --frame_db FRAME.DBF \
    --dicom_uid 1.3.46.423632.135428.1351013645.166 \
    -o elektaGeometry

I would be appreciate if one could answer my question.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151130/b11ad4e2/attachment.html>

From cyril.mory at uclouvain.be  Mon Nov 30 09:30:48 2015
From: cyril.mory at uclouvain.be (Cyril Mory)
Date: Mon, 30 Nov 2015 15:30:48 +0100
Subject: [Rtk-users] ElectaReconstruction
In-Reply-To: <CALChM12F4PuiLvgENg3Yyn7E+uZ7iPJ+GiY04z7VQ-90AS83EA@mail.gmail.com>
References: <CALChM12F4PuiLvgENg3Yyn7E+uZ7iPJ+GiY04z7VQ-90AS83EA@mail.gmail.com>
Message-ID: <565C5D98.1000309@uclouvain.be>

Hi, and welcome to RTK,

Gengetopt is the piece of software that parses the command line 
arguments in all RTK applications. You do not have to "use" it. You just 
need to give correct arguments on the command line.

The message "--output' ('-o') option required" means what it says : you 
need to provide the name of the file in which you want to store the 
geometry information generated by the application 
rtkelektasynergygeometry. If you just copy-pasted the command you found 
on the wiki, then something went wrong during the copy-paste. Try to run 
the following :

rtkelektasynergygeometry --image_db IMAGE.DBF --frame_db FRAME.DBF 
--dicom_uid 1.3.46.423632.135428.1351013645.166 -o elektaGeometry

I just removed the '\' and the useless spaces. You can do the same for 
all other command line examples and it should work.

Let us know if you keep encountering trouble.
Cyril


Le 30/11/2015 12:06, niloufar teyfouri a ?crit :
>
> I ran the application of Electa Reconstruction implemented by you with
> RTK. But after debugging I was encountered with the message of
> "--output' ('-o') option required". Could you please help me for running
> this example and the other ones?
> I don't know any thing about the texts in the gray boxes mentioned at
> each link related to examples of RTK.
> For example in the link of
> http://wiki.openrtk.org/index.php/RTK/Examples/ElektaReconstruction
> how I should use gengetopt for the instructions below?
>
>
> 2. Run the application to convert Elekta's geometry into RTKs (DICOM_UID
> is contained in the subfolder name of the his files):
>
> rtkelektasynergygeometry \
> --image_db IMAGE.DBF \
> --frame_db FRAME.DBF \
> --dicom_uid 1.3.46.423632.135428.1351013645.166 \
>     -o elektaGeometry
>
> I would be appreciate if one could answer my question.
>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151130/66741755/attachment.html>

From j.mason at ed.ac.uk  Mon Nov 30 11:29:27 2015
From: j.mason at ed.ac.uk (Jonathan Mason)
Date: Mon, 30 Nov 2015 16:29:27 +0000
Subject: [Rtk-users] Preprocessing
Message-ID: <565C7967.4000401@ed.ac.uk>

Good afternoon RTK users,

I have access to "raw data" from a Varian OBI scanner, and have
experimented with RTK for performing its reconstruction. However, it is
not really "raw" in the sense that the coefficients are proportional to
the photon flux recorded at a given sensor, but is instead proportional
to the Hounsfield attenuation along that path. With this data, it means
that one can reconstruct using FDK and other iterative techniques, which
assume a linear model, but the connection to the underlying physics is
abstract.

The problem I then have when trying to develop reconstruction
techniques, is that I do not know whether I am really correcting for
physical distortions or just correcting for Varian's preprocessing,
which has been finely tuned for its own FDK method.

My question is whether anybody has dug into the steps that manufacturers
such as Varian or Elekta perform to arrive at these projection images?
And if they think that if reverse engineered, could provide a richer set
of information to facilitate advanced strategies.

Best wishes,

Jonathan Mason

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


From simon.rit at creatis.insa-lyon.fr  Mon Nov 30 12:44:03 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Mon, 30 Nov 2015 18:44:03 +0100
Subject: [Rtk-users] ElectaReconstruction
In-Reply-To: <565C5D98.1000309@uclouvain.be>
References: <CALChM12F4PuiLvgENg3Yyn7E+uZ7iPJ+GiY04z7VQ-90AS83EA@mail.gmail.com>
 <565C5D98.1000309@uclouvain.be>
Message-ID: <CAF0oig2Zg96AZaRn9w9=F+LnLnyteTn5zS1rLguQ8WXiYhnnYg@mail.gmail.com>

Hi,
I think Cyril is right, it's not possible to use backslashes to put a
command line on several line with Windows command line. Can you confirm
this? If you confirm, we will correct the wiki.
Thanks,
Simon

On Mon, Nov 30, 2015 at 3:30 PM, Cyril Mory <cyril.mory at uclouvain.be> wrote:

> Hi, and welcome to RTK,
>
> Gengetopt is the piece of software that parses the command line arguments
> in all RTK applications. You do not have to "use" it. You just need to give
> correct arguments on the command line.
>
> The message "--output' ('-o') option required" means what it says : you
> need to provide the name of the file in which you want to store the
> geometry information generated by the application rtkelektasynergygeometry.
> If you just copy-pasted the command you found on the wiki, then something
> went wrong during the copy-paste. Try to run the following :
>
> rtkelektasynergygeometry --image_db IMAGE.DBF --frame_db FRAME.DBF
> --dicom_uid 1.3.46.423632.135428.1351013645.166 -o elektaGeometry
>
> I just removed the '\' and the useless spaces. You can do the same for all
> other command line examples and it should work.
>
> Let us know if you keep encountering trouble.
> Cyril
>
>
>
> Le 30/11/2015 12:06, niloufar teyfouri a ?crit :
>
>
> I ran the application of Electa Reconstruction implemented by you with
> RTK. But after debugging I was encountered with the message of
> "--output' ('-o') option required". Could you please help me for running
> this example and the other ones?
> I don't know any thing about the texts in the gray boxes mentioned at
> each link related to examples of RTK.
> For example in the link of
> http://wiki.openrtk.org/index.php/RTK/Examples/ElektaReconstruction
> how I should use gengetopt for the instructions below?
>
>
> 2. Run the application to convert Elekta's geometry into RTKs (DICOM_UID
> is contained in the subfolder name of the his files):
>
>   rtkelektasynergygeometry \
>     --image_db IMAGE.DBF \
>     --frame_db FRAME.DBF \
>     --dicom_uid 1.3.46.423632.135428.1351013645.166 \
>     -o elektaGeometry
>
> I would be appreciate if one could answer my question.
>
>
> _______________________________________________
> Rtk-users mailing listRtk-users at public.kitware.comhttp://public.kitware.com/mailman/listinfo/rtk-users
>
>
>
>
> ------------------------------
> [image: Avast logo] <https://www.avast.com/antivirus>
>
> L'absence de virus dans ce courrier ?lectronique a ?t? v?rifi?e par le
> logiciel antivirus Avast.
> www.avast.com <https://www.avast.com/antivirus>
>
>
> _______________________________________________
> 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/20151130/6d6dd6aa/attachment.html>

From wuchao04 at gmail.com  Mon Nov 30 13:50:06 2015
From: wuchao04 at gmail.com (Chao Wu)
Date: Mon, 30 Nov 2015 19:50:06 +0100
Subject: [Rtk-users] Preprocessing
In-Reply-To: <565C7967.4000401@ed.ac.uk>
References: <565C7967.4000401@ed.ac.uk>
Message-ID: <CAH+sHrUFov5f=8h4-ePhC2xLraM3BxA9r12yfXdM3rrKPeqCBg@mail.gmail.com>

Hi Jonathan,

I do not quite understand your problem.
I think most information can be retrieved by the relationship between flux
(I) and attenuation (u):
I = I0 * exp (- integral(u * dL) )
Of course there are other effects like beam hardening and scattering
involved but this model is the basic.

Regards,
Chao

2015-11-30 17:29 GMT+01:00 Jonathan Mason <j.mason at ed.ac.uk>:

> Good afternoon RTK users,
>
> I have access to "raw data" from a Varian OBI scanner, and have
> experimented with RTK for performing its reconstruction. However, it is
> not really "raw" in the sense that the coefficients are proportional to
> the photon flux recorded at a given sensor, but is instead proportional
> to the Hounsfield attenuation along that path. With this data, it means
> that one can reconstruct using FDK and other iterative techniques, which
> assume a linear model, but the connection to the underlying physics is
> abstract.
>
> The problem I then have when trying to develop reconstruction
> techniques, is that I do not know whether I am really correcting for
> physical distortions or just correcting for Varian's preprocessing,
> which has been finely tuned for its own FDK method.
>
> My question is whether anybody has dug into the steps that manufacturers
> such as Varian or Elekta perform to arrive at these projection images?
> And if they think that if reverse engineered, could provide a richer set
> of information to facilitate advanced strategies.
>
> Best wishes,
>
> Jonathan Mason
>
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
> _______________________________________________
> 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/20151130/ccb833fe/attachment.html>

From mdupont at cppm.in2p3.fr  Sun Nov  1 12:41:49 2015
From: mdupont at cppm.in2p3.fr (Mathieu Dupont)
Date: Sun, 01 Nov 2015 18:41:49 +0100
Subject: [Rtk-users] question about rtkDraw*ImageFilter
In-Reply-To: <56334CF2.8070902@cppm.in2p3.fr>
References: <5630EE01.5070900@cppm.in2p3.fr>
 <CAF0oig279ZWGJMFnJdXaPiYLPponadz_J-PVKt2z3iHiTRQ_gg@mail.gmail.com>
 <56334CF2.8070902@cppm.in2p3.fr>
Message-ID: <1539144.WPSdtJ8lhZ@marabunta>

Hello Simon, 

I started to implement what I suggested : 

https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawImageFilter.h
and 
https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawCylinderImageFilter.h

rtk::DrawCylinderImageFilter derives from rtk::DrawImageFilter and specializes 
it (by defaulting the template parameter TSpatialObject with 
DrawCylinderSpatialObject). 

By default, DrawCylinderImageFilter uses Add2 for filling output image (to be 
backward compatible (all tests pass)). I created Discard (I did not find 
equivalent in itk) functor in order to do what I wanted in my first email.  

I just implemented DrawCylinderImageFilter, the others will follow. 

What do you think about it ?

Le vendredi 30 octobre 2015, 11:56:50 Mathieu Dupont a ?crit :
> Hi,
> 
> In case of your first solution, you can not chain several
> Draw*ImageFilters. For example, if you want to create small cylinders in
> a big cylinder.
> 
> Your second solution is better.
> 
> One another solution can be a thing like itk:SpatialObject but more
> simpler. An rtk::SpatialObject which one function (isInside(point)). We
> create a rtkDrawImageFilter class and implement ThreadedGenerateData
> like this :
> 
> DrawImageFilter<InImage, OutImage, rtkSpatialObject,
> rtkFillFunctor>::ThreadedGenerateData(const OutputImageRegionType&
> outputRegionForThread,                 ThreadIdType itkNotUsed(threadId)
> {
> ...
> 
>   while( !itOut.IsAtEnd() )
>      {
>      this->GetInput()->TransformIndexToPhysicalPoint(itOut.GetIndex(),
> point);
> 
>     if(m_rtkSpatialObject.isInside(point)
>       itOut.Set(m_rtkFillFunctor(density, itIn.Get());
> ...
> }
> 
> 
> DrawConeImageFilter class can be a child of this new DrawImageFilter
> (with new methods like setAngle, SetRadius which will adjust the
> rtkConeSpatialObject)
> 
> This solution suppress duplicated code in
> Draw*ImageFilter::ThreadedGenerateData and makes easier implementation
> of another type of filling.
> 
> On 28/10/2015 20:52, Simon Rit wrote:
> > Hi Mathieu,
> > Thanks for pointing this out. I agree that it might not be the best
> > solution, yet one could argue that you could simply create a constant
> > image with 0 to do what you'd like from the current implementation. My
> > main problem is that I just tried to do what you suggest and some tests
> > then fail... which shows the obvious, it's not a backward compatible
> > change. I see two solutions:
> > - keep it as is and you use ConstantImageFilter + we remove useless add
> > filters,
> > - a more complex but maybe more elegant solution: add a third template
> > parameter for the operation that would allow the user to do what he'd
> > like in a functor. That's what's done with filters that derive from
> > itk::UnaryImageFilter
> > <http://www.itk.org/Doxygen/html/classitk_1_1UnaryFunctorImageFilter.html>
> > .
> > The default would be itk::Add2 but we could find or implement another
> > one that simply discards the pixel value.
> > What do you think?
> > Simon
> > 
> > PS: looking in the code, I just found that rtk::DrawConeImageFilter is
> > not consistent with the others, it was always setting to 0 outside...
> > that's been fixed!
> > 
> > On Wed, Oct 28, 2015 at 4:47 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr
> > 
> > <mailto:mdupont at cppm.in2p3.fr>> wrote:
> >     Hello everyone,
> >     
> >     I have a question/suggestion about the set of rtkDraw*ImageFilter.
> >     This filter are written as additive filters: for example, in
> >     rtkDrawEllipsoidImageFilter.txx, we can find
> >     
> >     for(..)
> >     
> >       itOut.Set( ellipsoid.density + itIn.Get() )
> >     
> >     instead of
> >     
> >     for(..)
> >     itOut.Set( ellipsoid.density )
> >     
> >     
> >     I think it can be more flexible the second option, because we can
> >     always associate Draw*ImageFilter and itkAddImageFilter to get an
> >     additive filter.
> >     
> >     Moreover, the  rtkDrawGeometricPhantomImageFilter class already uses
> >     itkAddImageFilter in order to have additive filters (which is
> >     redundant in current situation).
> >     
> >     What do you think ?
> >     
> >     
> >     
> >     
> >     
> >     Regards
> >     
> >     
> >     
> >     _______________________________________________
> >     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


From gnthibault at gmail.com  Mon Nov  2 08:08:42 2015
From: gnthibault at gmail.com (Notargiacomo Thibault)
Date: Mon, 2 Nov 2015 14:08:42 +0100
Subject: [Rtk-users] Problem with rtkGgoFunctions when importing series of
	images
Message-ID: <CAP+mR7Zw7WmRmEgVUTamNhS6m4S6ORvWFjRu1EANViPRJ7jtuQ@mail.gmail.com>

I recently experienced the following problem, when importing multiple tif
files inside a directory using itk::ImageSeriesReader:

[...]
code/rtkGgoFunctions.h: In instantiation of ?void
rtk::SetProjectionsReaderFromGgo(typename TProjectionsReaderType::Pointer,
const TArgsInfo&)
[...]
code/rtkGgoFunctions.h:121:61: error: no type named
?OutputImageDirectionType? in ?class
itk::ImageSeriesReader<itk::Image<short unsigned int, 3u> >?
   typename TProjectionsReaderType::OutputImageDirectionType direction;
[...]

It seems that, a new functionality added in rtkGgoFunctions.h (19/05/2015),
allowing to directly modify input images properties through command line,
like geometry (direction vector), assumes that the input image type defines
OutputImageDirectionType, but in the case of itk::ImageSeriesReader, it
does not.

Is this considered as a regression, or should the
SetProjectionsReaderFromGgo function be used with specific input image type
?

Thank you in advance for your help.

Kind regards

Thibault Notargiacomo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151102/6cad3583/attachment-0002.html>

From simon.rit at creatis.insa-lyon.fr  Mon Nov  2 08:58:24 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Mon, 2 Nov 2015 14:58:24 +0100
Subject: [Rtk-users] Problem with rtkGgoFunctions when importing series
	of images
In-Reply-To: <CAP+mR7Zw7WmRmEgVUTamNhS6m4S6ORvWFjRu1EANViPRJ7jtuQ@mail.gmail.com>
References: <CAP+mR7Zw7WmRmEgVUTamNhS6m4S6ORvWFjRu1EANViPRJ7jtuQ@mail.gmail.com>
Message-ID: <CAF0oig2bAidO4JR7pa_PUxOQm-X7JrEz8=ybGX3bskYJM9YRAQ@mail.gmail.com>

Hi Thibault,
SetProjectionsReaderFromGgo is a macro designed for the
rtk::ProjectionsReader
<http://www.openrtk.org/Doxygen/classrtk_1_1ProjectionsReader.html>, I'm
not surprised that it does not work with the itk::ImageSeriesReader. It's
not about the image type but about the filter type... We use this macro to
set many parameters specific to the rtk::ProjectionsReader
<http://www.openrtk.org/Doxygen/classrtk_1_1ProjectionsReader.html>. Since
a while, I have made have a common rtkinputprojections_section.ggo
<https://github.com/SimonRit/RTK/blob/master/applications/rtkinputprojections_section.ggo>
file for all the applications that use the rtk::ProjectionsReader.
If you don't want to use the rtk::ProjectionsReader but
itk::ImageSeriesReader (e.g., because it does a lot of automatic processing
that you don't want), you'll have to write your own code to set it up.
I hope this clarifies things.
Simon

On Mon, Nov 2, 2015 at 2:08 PM, Notargiacomo Thibault <gnthibault at gmail.com>
wrote:

> I recently experienced the following problem, when importing multiple tif
> files inside a directory using itk::ImageSeriesReader:
>
> [...]
> code/rtkGgoFunctions.h: In instantiation of ?void
> rtk::SetProjectionsReaderFromGgo(typename TProjectionsReaderType::Pointer,
> const TArgsInfo&)
> [...]
> code/rtkGgoFunctions.h:121:61: error: no type named
> ?OutputImageDirectionType? in ?class
> itk::ImageSeriesReader<itk::Image<short unsigned int, 3u> >?
>    typename TProjectionsReaderType::OutputImageDirectionType direction;
> [...]
>
> It seems that, a new functionality added in rtkGgoFunctions.h
> (19/05/2015), allowing to directly modify input images properties through
> command line, like geometry (direction vector), assumes that the input
> image type defines OutputImageDirectionType, but in the case of
> itk::ImageSeriesReader, it does not.
>
> Is this considered as a regression, or should the
> SetProjectionsReaderFromGgo function be used with specific input image type
> ?
>
> Thank you in advance for your help.
>
> Kind regards
>
> Thibault Notargiacomo
>
> _______________________________________________
> 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/20151102/ee7e2c17/attachment-0002.html>

From simon.rit at creatis.insa-lyon.fr  Wed Nov  4 16:38:18 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Wed, 4 Nov 2015 22:38:18 +0100
Subject: [Rtk-users] question about rtkDraw*ImageFilter
In-Reply-To: <1539144.WPSdtJ8lhZ@marabunta>
References: <5630EE01.5070900@cppm.in2p3.fr>
 <CAF0oig279ZWGJMFnJdXaPiYLPponadz_J-PVKt2z3iHiTRQ_gg@mail.gmail.com>
 <56334CF2.8070902@cppm.in2p3.fr> <1539144.WPSdtJ8lhZ@marabunta>
Message-ID: <CAF0oig3jBsfoadM_k6SYvOMwikOCNFmH19J7m1YJZx-RU0y+5g@mail.gmail.com>

Hi Mathieu,
Sorry, I'm very busy these days. I had a first quick look. Why not, it
looks a bit complicated but good. I would have a few things I would change
style wise, e.g., move DrawCylinderSpatialObject to
DrawCylinderImageFilter, create a common DrawQuadricSpatialObject that
would all have the same IsInside function, make DrawSpatialObjectpurely
virtual by not defining
IsInside etc. but those are details I can correct myself. Do you want to
finish what you started and I work from there or should I finish everything?
Simon

On Sun, Nov 1, 2015 at 6:41 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr>
wrote:

> Hello Simon,
>
> I started to implement what I suggested :
>
>
> https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawImageFilter.h
> and
>
> https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawCylinderImageFilter.h
>
> rtk::DrawCylinderImageFilter derives from rtk::DrawImageFilter and
> specializes
> it (by defaulting the template parameter TSpatialObject with
> DrawCylinderSpatialObject).
>
> By default, DrawCylinderImageFilter uses Add2 for filling output image (to
> be
> backward compatible (all tests pass)). I created Discard (I did not find
> equivalent in itk) functor in order to do what I wanted in my first email.
>
> I just implemented DrawCylinderImageFilter, the others will follow.
>
> What do you think about it ?
>
> Le vendredi 30 octobre 2015, 11:56:50 Mathieu Dupont a ?crit :
> > Hi,
> >
> > In case of your first solution, you can not chain several
> > Draw*ImageFilters. For example, if you want to create small cylinders in
> > a big cylinder.
> >
> > Your second solution is better.
> >
> > One another solution can be a thing like itk:SpatialObject but more
> > simpler. An rtk::SpatialObject which one function (isInside(point)). We
> > create a rtkDrawImageFilter class and implement ThreadedGenerateData
> > like this :
> >
> > DrawImageFilter<InImage, OutImage, rtkSpatialObject,
> > rtkFillFunctor>::ThreadedGenerateData(const OutputImageRegionType&
> > outputRegionForThread,                 ThreadIdType itkNotUsed(threadId)
> > {
> > ...
> >
> >   while( !itOut.IsAtEnd() )
> >      {
> >      this->GetInput()->TransformIndexToPhysicalPoint(itOut.GetIndex(),
> > point);
> >
> >     if(m_rtkSpatialObject.isInside(point)
> >       itOut.Set(m_rtkFillFunctor(density, itIn.Get());
> > ...
> > }
> >
> >
> > DrawConeImageFilter class can be a child of this new DrawImageFilter
> > (with new methods like setAngle, SetRadius which will adjust the
> > rtkConeSpatialObject)
> >
> > This solution suppress duplicated code in
> > Draw*ImageFilter::ThreadedGenerateData and makes easier implementation
> > of another type of filling.
> >
> > On 28/10/2015 20:52, Simon Rit wrote:
> > > Hi Mathieu,
> > > Thanks for pointing this out. I agree that it might not be the best
> > > solution, yet one could argue that you could simply create a constant
> > > image with 0 to do what you'd like from the current implementation. My
> > > main problem is that I just tried to do what you suggest and some tests
> > > then fail... which shows the obvious, it's not a backward compatible
> > > change. I see two solutions:
> > > - keep it as is and you use ConstantImageFilter + we remove useless add
> > > filters,
> > > - a more complex but maybe more elegant solution: add a third template
> > > parameter for the operation that would allow the user to do what he'd
> > > like in a functor. That's what's done with filters that derive from
> > > itk::UnaryImageFilter
> > > <
> http://www.itk.org/Doxygen/html/classitk_1_1UnaryFunctorImageFilter.html>
> > > .
> > > The default would be itk::Add2 but we could find or implement another
> > > one that simply discards the pixel value.
> > > What do you think?
> > > Simon
> > >
> > > PS: looking in the code, I just found that rtk::DrawConeImageFilter is
> > > not consistent with the others, it was always setting to 0 outside...
> > > that's been fixed!
> > >
> > > On Wed, Oct 28, 2015 at 4:47 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr
> > >
> > > <mailto:mdupont at cppm.in2p3.fr>> wrote:
> > >     Hello everyone,
> > >
> > >     I have a question/suggestion about the set of rtkDraw*ImageFilter.
> > >     This filter are written as additive filters: for example, in
> > >     rtkDrawEllipsoidImageFilter.txx, we can find
> > >
> > >     for(..)
> > >
> > >       itOut.Set( ellipsoid.density + itIn.Get() )
> > >
> > >     instead of
> > >
> > >     for(..)
> > >     itOut.Set( ellipsoid.density )
> > >
> > >
> > >     I think it can be more flexible the second option, because we can
> > >     always associate Draw*ImageFilter and itkAddImageFilter to get an
> > >     additive filter.
> > >
> > >     Moreover, the  rtkDrawGeometricPhantomImageFilter class already
> uses
> > >     itkAddImageFilter in order to have additive filters (which is
> > >     redundant in current situation).
> > >
> > >     What do you think ?
> > >
> > >
> > >
> > >
> > >
> > >     Regards
> > >
> > >
> > >
> > >     _______________________________________________
> > >     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/20151104/46314d97/attachment-0002.html>

From mdupont at cppm.in2p3.fr  Mon Nov  9 14:35:47 2015
From: mdupont at cppm.in2p3.fr (Mathieu Dupont)
Date: Mon, 09 Nov 2015 20:35:47 +0100
Subject: [Rtk-users] question about rtkDraw*ImageFilter
In-Reply-To: <CAF0oig3jBsfoadM_k6SYvOMwikOCNFmH19J7m1YJZx-RU0y+5g@mail.gmail.com>
References: <5630EE01.5070900@cppm.in2p3.fr> <1539144.WPSdtJ8lhZ@marabunta>
 <CAF0oig3jBsfoadM_k6SYvOMwikOCNFmH19J7m1YJZx-RU0y+5g@mail.gmail.com>
Message-ID: <5634494.U9CmFl2V79@marabunta>

hi, 

i will do this during this week and try to implement your remarks. 


Le mercredi 4 novembre 2015, 22:38:18 Simon Rit a ?crit :
> Hi Mathieu,
> Sorry, I'm very busy these days. I had a first quick look. Why not, it
> looks a bit complicated but good. I would have a few things I would change
> style wise, e.g., move DrawCylinderSpatialObject to
> DrawCylinderImageFilter, create a common DrawQuadricSpatialObject that
> would all have the same IsInside function, make DrawSpatialObjectpurely
> virtual by not defining
> IsInside etc. but those are details I can correct myself. Do you want to
> finish what you started and I work from there or should I finish everything?
> Simon
> 
> On Sun, Nov 1, 2015 at 6:41 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr>
> 
> wrote:
> > Hello Simon,
> > 
> > I started to implement what I suggested :
> > 
> > 
> > https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawImag
> > eFilter.h and
> > 
> > https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawCyli
> > nderImageFilter.h
> > 
> > rtk::DrawCylinderImageFilter derives from rtk::DrawImageFilter and
> > specializes
> > it (by defaulting the template parameter TSpatialObject with
> > DrawCylinderSpatialObject).
> > 
> > By default, DrawCylinderImageFilter uses Add2 for filling output image (to
> > be
> > backward compatible (all tests pass)). I created Discard (I did not find
> > equivalent in itk) functor in order to do what I wanted in my first email.
> > 
> > I just implemented DrawCylinderImageFilter, the others will follow.
> > 
> > What do you think about it ?
> > 
> > Le vendredi 30 octobre 2015, 11:56:50 Mathieu Dupont a ?crit :
> > > Hi,
> > > 
> > > In case of your first solution, you can not chain several
> > > Draw*ImageFilters. For example, if you want to create small cylinders in
> > > a big cylinder.
> > > 
> > > Your second solution is better.
> > > 
> > > One another solution can be a thing like itk:SpatialObject but more
> > > simpler. An rtk::SpatialObject which one function (isInside(point)). We
> > > create a rtkDrawImageFilter class and implement ThreadedGenerateData
> > > like this :
> > > 
> > > DrawImageFilter<InImage, OutImage, rtkSpatialObject,
> > > rtkFillFunctor>::ThreadedGenerateData(const OutputImageRegionType&
> > > outputRegionForThread,                 ThreadIdType itkNotUsed(threadId)
> > > {
> > > ...
> > > 
> > >   while( !itOut.IsAtEnd() )
> > >   
> > >      {
> > >      this->GetInput()->TransformIndexToPhysicalPoint(itOut.GetIndex(),
> > > 
> > > point);
> > > 
> > >     if(m_rtkSpatialObject.isInside(point)
> > >     
> > >       itOut.Set(m_rtkFillFunctor(density, itIn.Get());
> > > 
> > > ...
> > > }
> > > 
> > > 
> > > DrawConeImageFilter class can be a child of this new DrawImageFilter
> > > (with new methods like setAngle, SetRadius which will adjust the
> > > rtkConeSpatialObject)
> > > 
> > > This solution suppress duplicated code in
> > > Draw*ImageFilter::ThreadedGenerateData and makes easier implementation
> > > of another type of filling.
> > > 
> > > On 28/10/2015 20:52, Simon Rit wrote:
> > > > Hi Mathieu,
> > > > Thanks for pointing this out. I agree that it might not be the best
> > > > solution, yet one could argue that you could simply create a constant
> > > > image with 0 to do what you'd like from the current implementation. My
> > > > main problem is that I just tried to do what you suggest and some
> > > > tests
> > > > then fail... which shows the obvious, it's not a backward compatible
> > > > change. I see two solutions:
> > > > - keep it as is and you use ConstantImageFilter + we remove useless
> > > > add
> > > > filters,
> > > > - a more complex but maybe more elegant solution: add a third template
> > > > parameter for the operation that would allow the user to do what he'd
> > > > like in a functor. That's what's done with filters that derive from
> > > > itk::UnaryImageFilter
> > > > <
> > 
> > http://www.itk.org/Doxygen/html/classitk_1_1UnaryFunctorImageFilter.html>
> > 
> > > > .
> > > > The default would be itk::Add2 but we could find or implement another
> > > > one that simply discards the pixel value.
> > > > What do you think?
> > > > Simon
> > > > 
> > > > PS: looking in the code, I just found that rtk::DrawConeImageFilter is
> > > > not consistent with the others, it was always setting to 0 outside...
> > > > that's been fixed!
> > > > 
> > > > On Wed, Oct 28, 2015 at 4:47 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr
> > > > 
> > > > <mailto:mdupont at cppm.in2p3.fr>> wrote:
> > > >     Hello everyone,
> > > >     
> > > >     I have a question/suggestion about the set of rtkDraw*ImageFilter.
> > > >     This filter are written as additive filters: for example, in
> > > >     rtkDrawEllipsoidImageFilter.txx, we can find
> > > >     
> > > >     for(..)
> > > >     
> > > >       itOut.Set( ellipsoid.density + itIn.Get() )
> > > >     
> > > >     instead of
> > > >     
> > > >     for(..)
> > > >     itOut.Set( ellipsoid.density )
> > > >     
> > > >     
> > > >     I think it can be more flexible the second option, because we can
> > > >     always associate Draw*ImageFilter and itkAddImageFilter to get an
> > > >     additive filter.
> > > >     
> > > >     Moreover, the  rtkDrawGeometricPhantomImageFilter class already
> > 
> > uses
> > 
> > > >     itkAddImageFilter in order to have additive filters (which is
> > > >     redundant in current situation).
> > > >     
> > > >     What do you think ?
> > > >     
> > > >     
> > > >     
> > > >     
> > > >     
> > > >     Regards
> > > >     
> > > >     
> > > >     
> > > >     _______________________________________________
> > > >     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


From gnthibault at gmail.com  Tue Nov 10 07:39:46 2015
From: gnthibault at gmail.com (Notargiacomo Thibault)
Date: Tue, 10 Nov 2015 13:39:46 +0100
Subject: [Rtk-users] Understanding projection matrices management in
	rtkCudaBackProjectionImageFilter
Message-ID: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>

Hi all,

I am currently trying to use the "AddProjectionInRadians" method from the
ThreeDCircularProjectionGeometry class in RTK to import my geometry.

First things first, I would like to know if the information on this pdf are
still valid: http://www.openrtk.org/Doxygen/geometry.pdf

Because I used them to deduce the source offset and Projection offset from
my own matrix decomposition.

Notice that I don't want to use geometric informations coming from the
projection images themselves, so their geometric origin is assumed to be
(0,0,0) in my case.

In order to check if my geometry import method is correct, I print out one
of the intermediate form of the projection matrix used in the
backprojection process, in order to check if it is the same as in my own
implementation.

To do so, I print out one of the intermediate matrix that is generated in
rtkCudaBackProjectionImageFilter while launching a SART reconstruction for
instance.

I was surpised by the fact that, the matrix allowing the transformation
from 2D geometric world to 2D image index world, namely matrixIdxProj in
rtkCudaBackProjectionImageFilte.cxx
<http://www.openrtk.org/Doxygen/rtkCudaBackProjectionImageFilter_8cxx_source.html>
is not always the same along the reconstruction process ?

Here is the line that generates the matrix I don't understand:

for(unsigned int i=0; i<2; i++)
 //SR: 0.5 for 2D texture
  matrixIdxProj[i][2] =
-1*(this->GetInput(1)->GetBufferedRegion().GetIndex()[i])+0.5;

What I understand here, is that, we are generating a 2D translation matrix
embedded in a 3*3 matrix that allows to take into account two things
related to the 2D projection:

-If the internal behaviour of the imageContainer, allows buffering of only
a part of the image, beginning at index (i,j), this information will be
embeded in the projection matrix

-the ITK floating point addressing definition seems to differ from the one
from cuda (and openCV):
When I take a look at this page
<http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#texture-fetching>
I understand that the floating point indexing (0.5,0.5) in Cuda points to
the center of the pixel (0,0) hence a linear contribution of 100%, while it
seems that we must add a translation of (0.5,0.5) to the ITK geometric
framework in order to get the same behaviour.

In practice matrixIdxProj is based on a 3*3 identity matrix, where the
inner 2D translation (ie 2 first term of the last column) in my case are:
-in X, a random number between 10 and 150 plus 0.5
-in Y: always 0.5

I understand the 0.5 part, but why is there always a 0 offset in Y but a
random offset in X remains a mystery to me.

At first, I believed that each projection was splitted into multiple part,
each having a different X and Y offset.
But reconstructing using only one projection generates only one
backprojection operation, with a non zero offset in X, 123 in my case, for
an image of size 780 in X.

Do you think there is something wrong whith the values of matrixIdxProjI am
experiencing ?

Thank you in advance.

Kind regards

Thibault Notargiacomo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151110/fbd3fb46/attachment-0002.html>

From simon.rit at creatis.insa-lyon.fr  Tue Nov 10 08:21:29 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Tue, 10 Nov 2015 14:21:29 +0100
Subject: [Rtk-users] Understanding projection matrices management in
	rtkCudaBackProjectionImageFilter
In-Reply-To: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>
References: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>
Message-ID: <CAF0oig3muuH+1=eLZ66DJ22QcnsSrUKzRFS4RzDRvDJXNxAVXg@mail.gmail.com>

Hi Thibault,
You started digging in the code so that gets complicated. First thing
first, yes, the link you provide is still valid.
The offset in X is not random but computed in
BackProjectionImageFilter::GenerateInputRequestedRegion
<https://github.com/SimonRit/RTK/blob/master/code/rtkBackProjectionImageFilter.txx>.
The idea is that we request only the part of the projections we need to do
the backprojection. This optimizes the streaming (we only read from disk
what we need). If you use a huge volume (the test I'd suggest to validate
that I'm correct and there is nothing wrong with your code), then you'll
need the full projection and you will always get 0 in X as in Y. If you use
a small volume and do a computation projection per projection, you will get
a varying index depending on your input volume and the geometry for that
projection.
I think you understood the rest pretty well. Does that make sense or am I
missing something else?
Simon

On Tue, Nov 10, 2015 at 1:39 PM, Notargiacomo Thibault <gnthibault at gmail.com
> wrote:

> Hi all,
>
> I am currently trying to use the "AddProjectionInRadians" method from the
> ThreeDCircularProjectionGeometry class in RTK to import my geometry.
>
> First things first, I would like to know if the information on this pdf
> are still valid: http://www.openrtk.org/Doxygen/geometry.pdf
>
> Because I used them to deduce the source offset and Projection offset from
> my own matrix decomposition.
>
> Notice that I don't want to use geometric informations coming from the
> projection images themselves, so their geometric origin is assumed to be
> (0,0,0) in my case.
>
> In order to check if my geometry import method is correct, I print out one
> of the intermediate form of the projection matrix used in the
> backprojection process, in order to check if it is the same as in my own
> implementation.
>
> To do so, I print out one of the intermediate matrix that is generated in
> rtkCudaBackProjectionImageFilter while launching a SART reconstruction for
> instance.
>
> I was surpised by the fact that, the matrix allowing the transformation
> from 2D geometric world to 2D image index world, namely matrixIdxProj in
> rtkCudaBackProjectionImageFilte.cxx
> <http://www.openrtk.org/Doxygen/rtkCudaBackProjectionImageFilter_8cxx_source.html>
> is not always the same along the reconstruction process ?
>
> Here is the line that generates the matrix I don't understand:
>
> for(unsigned int i=0; i<2; i++)
>  //SR: 0.5 for 2D texture
>   matrixIdxProj[i][2] =
> -1*(this->GetInput(1)->GetBufferedRegion().GetIndex()[i])+0.5;
>
> What I understand here, is that, we are generating a 2D translation matrix
> embedded in a 3*3 matrix that allows to take into account two things
> related to the 2D projection:
>
> -If the internal behaviour of the imageContainer, allows buffering of only
> a part of the image, beginning at index (i,j), this information will be
> embeded in the projection matrix
>
> -the ITK floating point addressing definition seems to differ from the one
> from cuda (and openCV):
> When I take a look at this page
> <http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#texture-fetching>
> I understand that the floating point indexing (0.5,0.5) in Cuda points to
> the center of the pixel (0,0) hence a linear contribution of 100%, while it
> seems that we must add a translation of (0.5,0.5) to the ITK geometric
> framework in order to get the same behaviour.
>
> In practice matrixIdxProj is based on a 3*3 identity matrix, where the
> inner 2D translation (ie 2 first term of the last column) in my case are:
> -in X, a random number between 10 and 150 plus 0.5
> -in Y: always 0.5
>
> I understand the 0.5 part, but why is there always a 0 offset in Y but a
> random offset in X remains a mystery to me.
>
> At first, I believed that each projection was splitted into multiple part,
> each having a different X and Y offset.
> But reconstructing using only one projection generates only one
> backprojection operation, with a non zero offset in X, 123 in my case, for
> an image of size 780 in X.
>
> Do you think there is something wrong whith the values of matrixIdxProjI
> am experiencing ?
>
> Thank you in advance.
>
> Kind regards
>
> Thibault Notargiacomo
>
> _______________________________________________
> 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/20151110/8b9b86e6/attachment-0002.html>

From simon.rit at creatis.insa-lyon.fr  Tue Nov 10 09:03:52 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Tue, 10 Nov 2015 15:03:52 +0100
Subject: [Rtk-users] Understanding projection matrices management in
	rtkCudaBackProjectionImageFilter
In-Reply-To: <CAP+mR7ZLJV8V5dMOW_jgM5G2-kCZhy8o0tB19685LGo-1bxLUg@mail.gmail.com>
References: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>
 <CAF0oig3muuH+1=eLZ66DJ22QcnsSrUKzRFS4RzDRvDJXNxAVXg@mail.gmail.com>
 <CAP+mR7ZLJV8V5dMOW_jgM5G2-kCZhy8o0tB19685LGo-1bxLUg@mail.gmail.com>
Message-ID: <CAF0oig3fALRnZNCJ53+TsSjBm7raRC_mqahWEU6x+D+zxwOnVQ@mail.gmail.com>

A small correction: it's actually the amount of data pre-processed (read
from disk + all the processing before backprojection) but that should
change nothing to what is backprojected.
I remembered something that can help you: you may want to run
UpdateLargestPossibleRegion() to the projections (input 1 of the
BackProjectImageFilter) before backprojection to avoid this and make things
clearer instead of using a large volume as I was suggesting before.
Simon

On Tue, Nov 10, 2015 at 2:34 PM, Notargiacomo Thibault <gnthibault at gmail.com
> wrote:

> Ok, using geometric information to reduce the amount of data to be
> backprojected is pretty clever ;)
> This explains the "random" index I was asking about in my previous
> question, I now know what it is used for and continue my debugging process.
>
> Kind regards
>
> Thibault Notargiacomo
>
> 2015-11-10 14:21 GMT+01:00 Simon Rit <simon.rit at creatis.insa-lyon.fr>:
>
>> Hi Thibault,
>> You started digging in the code so that gets complicated. First thing
>> first, yes, the link you provide is still valid.
>> The offset in X is not random but computed in
>> BackProjectionImageFilter::GenerateInputRequestedRegion
>> <https://github.com/SimonRit/RTK/blob/master/code/rtkBackProjectionImageFilter.txx>.
>> The idea is that we request only the part of the projections we need to do
>> the backprojection. This optimizes the streaming (we only read from disk
>> what we need). If you use a huge volume (the test I'd suggest to validate
>> that I'm correct and there is nothing wrong with your code), then you'll
>> need the full projection and you will always get 0 in X as in Y. If you use
>> a small volume and do a computation projection per projection, you will get
>> a varying index depending on your input volume and the geometry for that
>> projection.
>> I think you understood the rest pretty well. Does that make sense or am I
>> missing something else?
>> Simon
>>
>> On Tue, Nov 10, 2015 at 1:39 PM, Notargiacomo Thibault <
>> gnthibault at gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> I am currently trying to use the "AddProjectionInRadians" method from
>>> the ThreeDCircularProjectionGeometry class in RTK to import my geometry.
>>>
>>> First things first, I would like to know if the information on this pdf
>>> are still valid: http://www.openrtk.org/Doxygen/geometry.pdf
>>>
>>> Because I used them to deduce the source offset and Projection offset
>>> from my own matrix decomposition.
>>>
>>> Notice that I don't want to use geometric informations coming from the
>>> projection images themselves, so their geometric origin is assumed to be
>>> (0,0,0) in my case.
>>>
>>> In order to check if my geometry import method is correct, I print out
>>> one of the intermediate form of the projection matrix used in the
>>> backprojection process, in order to check if it is the same as in my own
>>> implementation.
>>>
>>> To do so, I print out one of the intermediate matrix that is generated
>>> in rtkCudaBackProjectionImageFilter while launching a SART reconstruction
>>> for instance.
>>>
>>> I was surpised by the fact that, the matrix allowing the transformation
>>> from 2D geometric world to 2D image index world, namely matrixIdxProj in
>>> rtkCudaBackProjectionImageFilte.cxx
>>> <http://www.openrtk.org/Doxygen/rtkCudaBackProjectionImageFilter_8cxx_source.html>
>>> is not always the same along the reconstruction process ?
>>>
>>> Here is the line that generates the matrix I don't understand:
>>>
>>> for(unsigned int i=0; i<2; i++)
>>>  //SR: 0.5 for 2D texture
>>>   matrixIdxProj[i][2] =
>>> -1*(this->GetInput(1)->GetBufferedRegion().GetIndex()[i])+0.5;
>>>
>>> What I understand here, is that, we are generating a 2D translation
>>> matrix embedded in a 3*3 matrix that allows to take into account two things
>>> related to the 2D projection:
>>>
>>> -If the internal behaviour of the imageContainer, allows buffering of
>>> only a part of the image, beginning at index (i,j), this information will
>>> be embeded in the projection matrix
>>>
>>> -the ITK floating point addressing definition seems to differ from the
>>> one from cuda (and openCV):
>>> When I take a look at this page
>>> <http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#texture-fetching>
>>> I understand that the floating point indexing (0.5,0.5) in Cuda points to
>>> the center of the pixel (0,0) hence a linear contribution of 100%, while it
>>> seems that we must add a translation of (0.5,0.5) to the ITK geometric
>>> framework in order to get the same behaviour.
>>>
>>> In practice matrixIdxProj is based on a 3*3 identity matrix, where the
>>> inner 2D translation (ie 2 first term of the last column) in my case are:
>>> -in X, a random number between 10 and 150 plus 0.5
>>> -in Y: always 0.5
>>>
>>> I understand the 0.5 part, but why is there always a 0 offset in Y but a
>>> random offset in X remains a mystery to me.
>>>
>>> At first, I believed that each projection was splitted into multiple
>>> part, each having a different X and Y offset.
>>> But reconstructing using only one projection generates only one
>>> backprojection operation, with a non zero offset in X, 123 in my case, for
>>> an image of size 780 in X.
>>>
>>> Do you think there is something wrong whith the values of matrixIdxProjI
>>> am experiencing ?
>>>
>>> Thank you in advance.
>>>
>>> Kind regards
>>>
>>> Thibault Notargiacomo
>>>
>>> _______________________________________________
>>> 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/20151110/d8913dc3/attachment-0002.html>

From simon.rit at creatis.insa-lyon.fr  Tue Nov 10 11:21:29 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Tue, 10 Nov 2015 17:21:29 +0100
Subject: [Rtk-users] Understanding projection matrices management in
	rtkCudaBackProjectionImageFilter
In-Reply-To: <CAP+mR7ZKqnbUyRHyHkti=3sZd2dEw-OUV6oqsqcga55=tcQ9OQ@mail.gmail.com>
References: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>
 <CAF0oig3muuH+1=eLZ66DJ22QcnsSrUKzRFS4RzDRvDJXNxAVXg@mail.gmail.com>
 <CAP+mR7ZLJV8V5dMOW_jgM5G2-kCZhy8o0tB19685LGo-1bxLUg@mail.gmail.com>
 <CAF0oig3fALRnZNCJ53+TsSjBm7raRC_mqahWEU6x+D+zxwOnVQ@mail.gmail.com>
 <CAP+mR7ZKqnbUyRHyHkti=3sZd2dEw-OUV6oqsqcga55=tcQ9OQ@mail.gmail.com>
Message-ID: <CAF0oig12pRGBfgiCQMCwTG7zX_3vz87AEWhTQ4EYaVbH_m0t5Q@mail.gmail.com>

Your welcome (I cc the mailing list for info).
Simon

On Tue, Nov 10, 2015 at 5:03 PM, Notargiacomo Thibault <gnthibault at gmail.com
> wrote:

> I replaced the original Update by the "UpdateLargestPossibleRegion" to the
> divideFilter in SART (I bypassed displacedDetectorFilter for now) and it
> work as expected, I have now a "clean" matProjIdx.
>
> Thank you for your help !
>
> 2015-11-10 15:03 GMT+01:00 Simon Rit <simon.rit at creatis.insa-lyon.fr>:
>
>> A small correction: it's actually the amount of data pre-processed (read
>> from disk + all the processing before backprojection) but that should
>> change nothing to what is backprojected.
>> I remembered something that can help you: you may want to run
>> UpdateLargestPossibleRegion() to the projections (input 1 of the
>> BackProjectImageFilter) before backprojection to avoid this and make things
>> clearer instead of using a large volume as I was suggesting before.
>> Simon
>>
>> On Tue, Nov 10, 2015 at 2:34 PM, Notargiacomo Thibault <
>> gnthibault at gmail.com> wrote:
>>
>>> Ok, using geometric information to reduce the amount of data to be
>>> backprojected is pretty clever ;)
>>> This explains the "random" index I was asking about in my previous
>>> question, I now know what it is used for and continue my debugging process.
>>>
>>> Kind regards
>>>
>>> Thibault Notargiacomo
>>>
>>> 2015-11-10 14:21 GMT+01:00 Simon Rit <simon.rit at creatis.insa-lyon.fr>:
>>>
>>>> Hi Thibault,
>>>> You started digging in the code so that gets complicated. First thing
>>>> first, yes, the link you provide is still valid.
>>>> The offset in X is not random but computed in
>>>> BackProjectionImageFilter::GenerateInputRequestedRegion
>>>> <https://github.com/SimonRit/RTK/blob/master/code/rtkBackProjectionImageFilter.txx>.
>>>> The idea is that we request only the part of the projections we need to do
>>>> the backprojection. This optimizes the streaming (we only read from disk
>>>> what we need). If you use a huge volume (the test I'd suggest to validate
>>>> that I'm correct and there is nothing wrong with your code), then you'll
>>>> need the full projection and you will always get 0 in X as in Y. If you use
>>>> a small volume and do a computation projection per projection, you will get
>>>> a varying index depending on your input volume and the geometry for that
>>>> projection.
>>>> I think you understood the rest pretty well. Does that make sense or am
>>>> I missing something else?
>>>> Simon
>>>>
>>>> On Tue, Nov 10, 2015 at 1:39 PM, Notargiacomo Thibault <
>>>> gnthibault at gmail.com> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I am currently trying to use the "AddProjectionInRadians" method from
>>>>> the ThreeDCircularProjectionGeometry class in RTK to import my geometry.
>>>>>
>>>>> First things first, I would like to know if the information on this
>>>>> pdf are still valid: http://www.openrtk.org/Doxygen/geometry.pdf
>>>>>
>>>>> Because I used them to deduce the source offset and Projection offset
>>>>> from my own matrix decomposition.
>>>>>
>>>>> Notice that I don't want to use geometric informations coming from the
>>>>> projection images themselves, so their geometric origin is assumed to be
>>>>> (0,0,0) in my case.
>>>>>
>>>>> In order to check if my geometry import method is correct, I print out
>>>>> one of the intermediate form of the projection matrix used in the
>>>>> backprojection process, in order to check if it is the same as in my own
>>>>> implementation.
>>>>>
>>>>> To do so, I print out one of the intermediate matrix that is generated
>>>>> in rtkCudaBackProjectionImageFilter while launching a SART reconstruction
>>>>> for instance.
>>>>>
>>>>> I was surpised by the fact that, the matrix allowing the
>>>>> transformation from 2D geometric world to 2D image index world, namely
>>>>> matrixIdxProj in rtkCudaBackProjectionImageFilte.cxx
>>>>> <http://www.openrtk.org/Doxygen/rtkCudaBackProjectionImageFilter_8cxx_source.html>
>>>>> is not always the same along the reconstruction process ?
>>>>>
>>>>> Here is the line that generates the matrix I don't understand:
>>>>>
>>>>> for(unsigned int i=0; i<2; i++)
>>>>>  //SR: 0.5 for 2D texture
>>>>>   matrixIdxProj[i][2] =
>>>>> -1*(this->GetInput(1)->GetBufferedRegion().GetIndex()[i])+0.5;
>>>>>
>>>>> What I understand here, is that, we are generating a 2D translation
>>>>> matrix embedded in a 3*3 matrix that allows to take into account two things
>>>>> related to the 2D projection:
>>>>>
>>>>> -If the internal behaviour of the imageContainer, allows buffering of
>>>>> only a part of the image, beginning at index (i,j), this information will
>>>>> be embeded in the projection matrix
>>>>>
>>>>> -the ITK floating point addressing definition seems to differ from the
>>>>> one from cuda (and openCV):
>>>>> When I take a look at this page
>>>>> <http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#texture-fetching>
>>>>> I understand that the floating point indexing (0.5,0.5) in Cuda points to
>>>>> the center of the pixel (0,0) hence a linear contribution of 100%, while it
>>>>> seems that we must add a translation of (0.5,0.5) to the ITK geometric
>>>>> framework in order to get the same behaviour.
>>>>>
>>>>> In practice matrixIdxProj is based on a 3*3 identity matrix, where
>>>>> the inner 2D translation (ie 2 first term of the last column) in my case
>>>>> are:
>>>>> -in X, a random number between 10 and 150 plus 0.5
>>>>> -in Y: always 0.5
>>>>>
>>>>> I understand the 0.5 part, but why is there always a 0 offset in Y but
>>>>> a random offset in X remains a mystery to me.
>>>>>
>>>>> At first, I believed that each projection was splitted into multiple
>>>>> part, each having a different X and Y offset.
>>>>> But reconstructing using only one projection generates only one
>>>>> backprojection operation, with a non zero offset in X, 123 in my case, for
>>>>> an image of size 780 in X.
>>>>>
>>>>> Do you think there is something wrong whith the values of matrixIdxProjI
>>>>> am experiencing ?
>>>>>
>>>>> Thank you in advance.
>>>>>
>>>>> Kind regards
>>>>>
>>>>> Thibault Notargiacomo
>>>>>
>>>>> _______________________________________________
>>>>> 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/20151110/b7eba683/attachment-0002.html>

From theday79 at gmail.com  Wed Nov 11 13:50:45 2015
From: theday79 at gmail.com (Yang K Park)
Date: Wed, 11 Nov 2015 13:50:45 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after  a recent update
Message-ID: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>

Hi all,

 

I?ve updated rtk with the up-to-date revision and have encountered a couple of problems.

 

1.       Compile error: RTK couldn?t find itkMacro.h while it compiled rtkCudaUtilities.hcu. It was solved by a minor fetching:

#include <itkMacro.h>   --> #include "itkMacro.h" in rtkCudaUtilities.hcu

 

2.       Output of rtkfdk with CUDA was not the same as before. It was very blurry as seen in the attached image.

a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.

 

 

I?m using VS2013 with win7, itk4.8.1.

 

The command line I used was :

rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware cuda --pad 1 --hann 5 --hannY 5

 

Does anyone have any idea about this?

 

Thanks.

 

Yang

 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151111/b1c7df5f/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 16577 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151111/b1c7df5f/attachment-0002.png>

From simon.rit at creatis.insa-lyon.fr  Wed Nov 11 16:15:49 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Wed, 11 Nov 2015 22:15:49 +0100
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
Message-ID: <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>

Hi,
I didn't manage to reproduce the two problems on linux with the same
ITK version.
For point 1, did you copy itkMacro.h by hand? Because I don't see how
replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not
in the same folder as rtkCudaUtilities.hcu
For point 2, no clue. Do you use FFTW? It looks like a ramp filter
issue. Can you try rtkramp --path projPath --regexp .*.his, with and
without --hardware cuda? Maybe you can provide your geometry file in
case it's a specific geometric issue.
Simon

On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
> Hi all,
>
>
>
> I?ve updated rtk with the up-to-date revision and have encountered a couple
> of problems.
>
>
>
> 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
> rtkCudaUtilities.hcu. It was solved by a minor fetching:
>
> #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>
>
>
> 2.       Output of rtkfdk with CUDA was not the same as before. It was very
> blurry as seen in the attached image.
>
> a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>
>
>
>
>
> I?m using VS2013 with win7, itk4.8.1.
>
>
>
> The command line I used was :
>
> rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his --output
> output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware cuda --pad 1
> --hann 5 --hannY 5
>
>
>
> Does anyone have any idea about this?
>
>
>
> Thanks.
>
>
>
> Yang
>
>
>
>
> _______________________________________________
> Rtk-users mailing list
> Rtk-users at public.kitware.com
> http://public.kitware.com/mailman/listinfo/rtk-users
>


From theday79 at gmail.com  Thu Nov 12 17:39:38 2015
From: theday79 at gmail.com (Yang K Park)
Date: Thu, 12 Nov 2015 17:39:38 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
Message-ID: <000001d11d9b$04142320$0c3c6960$@gmail.com>

Hi Simon,

 

Thanks for the advice. The current RTK was compiled with FFTW to use the phase extraction feature from Amsterdam shroud.

 

Regarding your suggestions,

 

1)      rtkramp w/ or w/o CUDA:

(command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda --output Ramp_wCUDA.mha? )

 

Then, I have encountered following error.

?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that input requested and buffered regions are equal.?

 



 

Without CUDA, it was successfully done.

 

2)      I?ve re-compiled ITK w/o FFTW and built RTK again. rtkfdk worked fine.

-          I?ve also repeated ?rtkramp+CUDA? with this rtk version and the error was same as above.

 

In conclusion, my FFTW seems to affect CUDA-based fdk reconstruction only.

But I do need FFTW for the phase extraction. What should I do?

 

Thanks.

 

Yang

 

 

-----Original Message-----
From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit
Sent: Wednesday, November 11, 2015 4:16 PM
To: Yang K Park <theday79 at gmail.com>
Cc: rtk-users at openrtk.org
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

I didn't manage to reproduce the two problems on linux with the same ITK version.

For point 1, did you copy itkMacro.h by hand? Because I don't see how replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW? It looks like a ramp filter issue. Can you try rtkramp --path projPath --regexp .*.his, with and without --hardware cuda? Maybe you can provide your geometry file in case it's a specific geometric issue.

Simon

 

On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park < <mailto:theday79 at gmail.com> theday79 at gmail.com> wrote:

> Hi all,

> 

> 

> 

> I?ve updated rtk with the up-to-date revision and have encountered a 

> couple of problems.

> 

> 

> 

> 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled

> rtkCudaUtilities.hcu. It was solved by a minor fetching:

> 

> #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu

> 

> 

> 

> 2.       Output of rtkfdk with CUDA was not the same as before. It was very

> blurry as seen in the attached image.

> 

> a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.

> 

> 

> 

> 

> 

> I?m using VS2013 with win7, itk4.8.1.

> 

> 

> 

> The command line I used was :

> 

> rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his 

> --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware 

> cuda --pad 1 --hann 5 --hannY 5

> 

> 

> 

> Does anyone have any idea about this?

> 

> 

> 

> Thanks.

> 

> 

> 

> Yang

> 

> 

> 

> 

> _______________________________________________

> Rtk-users mailing list

>  <mailto: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/20151112/4e0825dc/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151112/4e0825dc/attachment-0002.png>

From simon.rit at creatis.insa-lyon.fr  Thu Nov 12 17:58:42 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Thu, 12 Nov 2015 23:58:42 +0100
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <000001d11d9b$04142320$0c3c6960$@gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
Message-ID: <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>

Hi,
Ok. Can you try rtkramp with only one projection? Then you shouldn't
encounter this regions issue (that should be solved one day but that's a
different story).
Can you also indicate which version of CUDA you're using?
FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft for
the FFT of the projections. So if they are not in the same format, you're
in trouble and that might be the issue here... The weird part is that I
didn't reproduce this problem on linux (with and without FFTW) but it might
be a CUDA version difference. I'll give it another try tomorrow when you
provide the CUDA version.
Thanks again for reporting the issue,
Simon

On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com> wrote:

> Hi Simon,
>
>
>
> Thanks for the advice. The current RTK was compiled with FFTW to use the
> phase extraction feature from Amsterdam shroud.
>
>
>
> Regarding your suggestions,
>
>
>
> 1)      rtkramp w/ or w/o CUDA:
>
> (command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda
> --output Ramp_wCUDA.mha? )
>
>
>
> Then, I have encountered following error.
>
> ?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that
> input requested and buffered regions are equal.?
>
>
>
>
>
> Without CUDA, it was successfully done.
>
>
>
> 2)      I?ve re-compiled *ITK w/o FFTW* and built RTK again. r*tkfdk
> worked fine.*
>
> -          I?ve also repeated ?rtkramp+CUDA? with this rtk version and
> the error was same as above.
>
>
>
> In conclusion, my *FFTW seems to affect CUDA-based fdk reconstruction
> only*.
>
> But I do need FFTW for the phase extraction. What should I do?
>
>
>
> Thanks.
>
>
>
> Yang
>
>
>
>
>
> -----Original Message-----
> From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon
> Rit
> Sent: Wednesday, November 11, 2015 4:16 PM
> To: Yang K Park <theday79 at gmail.com>
> Cc: rtk-users at openrtk.org
> Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
> update
>
>
>
> Hi,
>
> I didn't manage to reproduce the two problems on linux with the same ITK
> version.
>
> For point 1, did you copy itkMacro.h by hand? Because I don't see how
> replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the
> same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW?
> It looks like a ramp filter issue. Can you try rtkramp --path projPath
> --regexp .*.his, with and without --hardware cuda? Maybe you can provide
> your geometry file in case it's a specific geometric issue.
>
> Simon
>
>
>
> On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
>
> > Hi all,
>
> >
>
> >
>
> >
>
> > I?ve updated rtk with the up-to-date revision and have encountered a
>
> > couple of problems.
>
> >
>
> >
>
> >
>
> > 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
>
> > rtkCudaUtilities.hcu. It was solved by a minor fetching:
>
> >
>
> > #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>
> >
>
> >
>
> >
>
> > 2.       Output of rtkfdk with CUDA was not the same as before. It was
> very
>
> > blurry as seen in the attached image.
>
> >
>
> > a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > I?m using VS2013 with win7, itk4.8.1.
>
> >
>
> >
>
> >
>
> > The command line I used was :
>
> >
>
> > rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his
>
> > --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware
>
> > cuda --pad 1 --hann 5 --hannY 5
>
> >
>
> >
>
> >
>
> > Does anyone have any idea about this?
>
> >
>
> >
>
> >
>
> > Thanks.
>
> >
>
> >
>
> >
>
> > Yang
>
> >
>
> >
>
> >
>
> >
>
> > _______________________________________________
>
> > 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/20151112/e7c15ff8/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151112/e7c15ff8/attachment-0002.png>

From theday79 at gmail.com  Mon Nov 16 09:54:01 2015
From: theday79 at gmail.com (Yang K Park)
Date: Mon, 16 Nov 2015 09:54:01 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
Message-ID: <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>

Hi Simon,

 

Sorry for the late response.

 

As you suggested, I?ve tried rtkramp+CUDA with only one projection and it was successfully done for both w/ FFTW and w/o FFTW.

(Two results were exactly same.)

 

Regarding  the CUDA version, I?m using v6.5.

 

Thanks a lot for the help!

 

Yang

 

 

From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit
Sent: Thursday, November 12, 2015 5:59 PM
To: Yang K Park <theday79 at gmail.com>
Cc: rtk-users at openrtk.org
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

Ok. Can you try rtkramp with only one projection? Then you shouldn't encounter this regions issue (that should be solved one day but that's a different story). 

Can you also indicate which version of CUDA you're using?

FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft for the FFT of the projections. So if they are not in the same format, you're in trouble and that might be the issue here... The weird part is that I didn't reproduce this problem on linux (with and without FFTW) but it might be a CUDA version difference. I'll give it another try tomorrow when you provide the CUDA version.

Thanks again for reporting the issue,
Simon

 

On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> > wrote:

Hi Simon,

 

Thanks for the advice. The current RTK was compiled with FFTW to use the phase extraction feature from Amsterdam shroud.

 

Regarding your suggestions,

 

1)      rtkramp w/ or w/o CUDA:

(command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda --output Ramp_wCUDA.mha? )

 

Then, I have encountered following error.

?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that input requested and buffered regions are equal.?

 



 

Without CUDA, it was successfully done.

 

2)      I?ve re-compiled ITK w/o FFTW and built RTK again. rtkfdk worked fine.

-          I?ve also repeated ?rtkramp+CUDA? with this rtk version and the error was same as above.

 

In conclusion, my FFTW seems to affect CUDA-based fdk reconstruction only.

But I do need FFTW for the phase extraction. What should I do?

 

Thanks.

 

Yang

 

 

-----Original Message-----
From: simon.rit at gmail.com <mailto:simon.rit at gmail.com>  [mailto:simon.rit at gmail.com <mailto:simon.rit at gmail.com> ] On Behalf Of Simon Rit
Sent: Wednesday, November 11, 2015 4:16 PM
To: Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> >
Cc: rtk-users at openrtk.org <mailto:rtk-users at openrtk.org> 
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

I didn't manage to reproduce the two problems on linux with the same ITK version.

For point 1, did you copy itkMacro.h by hand? Because I don't see how replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW? It looks like a ramp filter issue. Can you try rtkramp --path projPath --regexp .*.his, with and without --hardware cuda? Maybe you can provide your geometry file in case it's a specific geometric issue.

Simon

 

On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park < <mailto:theday79 at gmail.com> theday79 at gmail.com> wrote:

> Hi all,

> 

> 

> 

> I?ve updated rtk with the up-to-date revision and have encountered a 

> couple of problems.

> 

> 

> 

> 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled

> rtkCudaUtilities.hcu. It was solved by a minor fetching:

> 

> #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu

> 

> 

> 

> 2.       Output of rtkfdk with CUDA was not the same as before. It was very

> blurry as seen in the attached image.

> 

> a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.

> 

> 

> 

> 

> 

> I?m using VS2013 with win7, itk4.8.1.

> 

> 

> 

> The command line I used was :

> 

> rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his 

> --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware 

> cuda --pad 1 --hann 5 --hannY 5

> 

> 

> 

> Does anyone have any idea about this?

> 

> 

> 

> Thanks.

> 

> 

> 

> Yang

> 

> 

> 

> 

> _______________________________________________

> Rtk-users mailing list

>  <mailto: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/20151116/e77c2f96/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151116/e77c2f96/attachment-0002.png>

From simon.rit at creatis.insa-lyon.fr  Mon Nov 16 10:07:46 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Mon, 16 Nov 2015 16:07:46 +0100
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
 <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
Message-ID: <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>

Hi,
Thanks. It's really weird... When you run the tests with FFTW (compiling
the "test" target), do they fail?
Can you provide your geometry file? It might be specific to this geometry.
Thanks again for looking into this issue, we'll find what's the problem.
Simon

On Mon, Nov 16, 2015 at 3:54 PM, Yang K Park <theday79 at gmail.com> wrote:

> Hi Simon,
>
>
>
> Sorry for the late response.
>
>
>
> As you suggested, I?ve tried rtkramp+CUDA with only one projection and it
> was successfully done for both w/ FFTW and w/o FFTW.
>
> (Two results were exactly same.)
>
>
>
> Regarding  the CUDA version, I?m using v6.5.
>
>
>
> Thanks a lot for the help!
>
>
>
> Yang
>
>
>
>
>
> *From:* simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of *Simon
> Rit
> *Sent:* Thursday, November 12, 2015 5:59 PM
>
> *To:* Yang K Park <theday79 at gmail.com>
> *Cc:* rtk-users at openrtk.org
> *Subject:* Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
> update
>
>
>
> Hi,
>
> Ok. Can you try rtkramp with only one projection? Then you shouldn't
> encounter this regions issue (that should be solved one day but that's a
> different story).
>
> Can you also indicate which version of CUDA you're using?
>
> FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft for
> the FFT of the projections. So if they are not in the same format, you're
> in trouble and that might be the issue here... The weird part is that I
> didn't reproduce this problem on linux (with and without FFTW) but it might
> be a CUDA version difference. I'll give it another try tomorrow when you
> provide the CUDA version.
>
> Thanks again for reporting the issue,
> Simon
>
>
>
> On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com> wrote:
>
> Hi Simon,
>
>
>
> Thanks for the advice. The current RTK was compiled with FFTW to use the
> phase extraction feature from Amsterdam shroud.
>
>
>
> Regarding your suggestions,
>
>
>
> 1)      rtkramp w/ or w/o CUDA:
>
> (command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda
> --output Ramp_wCUDA.mha? )
>
>
>
> Then, I have encountered following error.
>
> ?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that
> input requested and buffered regions are equal.?
>
>
>
>
>
> Without CUDA, it was successfully done.
>
>
>
> 2)      I?ve re-compiled *ITK w/o FFTW* and built RTK again. r*tkfdk
> worked fine.*
>
> -          I?ve also repeated ?rtkramp+CUDA? with this rtk version and
> the error was same as above.
>
>
>
> In conclusion, my *FFTW seems to affect CUDA-based fdk reconstruction
> only*.
>
> But I do need FFTW for the phase extraction. What should I do?
>
>
>
> Thanks.
>
>
>
> Yang
>
>
>
>
>
> -----Original Message-----
> From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon
> Rit
> Sent: Wednesday, November 11, 2015 4:16 PM
> To: Yang K Park <theday79 at gmail.com>
> Cc: rtk-users at openrtk.org
> Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
> update
>
>
>
> Hi,
>
> I didn't manage to reproduce the two problems on linux with the same ITK
> version.
>
> For point 1, did you copy itkMacro.h by hand? Because I don't see how
> replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the
> same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW?
> It looks like a ramp filter issue. Can you try rtkramp --path projPath
> --regexp .*.his, with and without --hardware cuda? Maybe you can provide
> your geometry file in case it's a specific geometric issue.
>
> Simon
>
>
>
> On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
>
> > Hi all,
>
> >
>
> >
>
> >
>
> > I?ve updated rtk with the up-to-date revision and have encountered a
>
> > couple of problems.
>
> >
>
> >
>
> >
>
> > 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
>
> > rtkCudaUtilities.hcu. It was solved by a minor fetching:
>
> >
>
> > #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>
> >
>
> >
>
> >
>
> > 2.       Output of rtkfdk with CUDA was not the same as before. It was
> very
>
> > blurry as seen in the attached image.
>
> >
>
> > a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > I?m using VS2013 with win7, itk4.8.1.
>
> >
>
> >
>
> >
>
> > The command line I used was :
>
> >
>
> > rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his
>
> > --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware
>
> > cuda --pad 1 --hann 5 --hannY 5
>
> >
>
> >
>
> >
>
> > Does anyone have any idea about this?
>
> >
>
> >
>
> >
>
> > Thanks.
>
> >
>
> >
>
> >
>
> > Yang
>
> >
>
> >
>
> >
>
> >
>
> > _______________________________________________
>
> > 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/20151116/38acfca5/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151116/38acfca5/attachment-0002.png>

From theday79 at gmail.com  Mon Nov 16 10:47:43 2015
From: theday79 at gmail.com (Yang-Kyun Park)
Date: Mon, 16 Nov 2015 10:47:43 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
 <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
 <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>
Message-ID: <CAJM7=xjBjx=FzLazWJWqJbV5d45zGi2U71NKejm9HxKhJ0-xLQ@mail.gmail.com>

Hi Simon,

For better understanding, I'm attaching the problematic case including
projection files, geometry file(xml) and reconstructed images.(please find
the GDrive links. The file size is ~800 MB)
This is phantom data and there is no patient information in it.

Regarding the fftw library, I'm using [fftw-3.3.4-dll64].

By the way, I found another clue. When I've tried it with a head phantom
image (full-fan, ~ 190 projections), there was no problem. Is there any
possibility that DDF and parker short filter play some roles on this issue?

Feel free to let me know if further data is needed.

Thanks!

Yang

?
 FFTW_issue.zip
<https://drive.google.com/file/d/0BxuP3mON9V-qbVdQd0luc1lIb2M/view?usp=drive_web>
?

On Mon, Nov 16, 2015 at 10:07 AM, Simon Rit <simon.rit at creatis.insa-lyon.fr>
wrote:

> Hi,
> Thanks. It's really weird... When you run the tests with FFTW (compiling
> the "test" target), do they fail?
> Can you provide your geometry file? It might be specific to this geometry.
> Thanks again for looking into this issue, we'll find what's the problem.
> Simon
>
> On Mon, Nov 16, 2015 at 3:54 PM, Yang K Park <theday79 at gmail.com> wrote:
>
>> Hi Simon,
>>
>>
>>
>> Sorry for the late response.
>>
>>
>>
>> As you suggested, I?ve tried rtkramp+CUDA with only one projection and it
>> was successfully done for both w/ FFTW and w/o FFTW.
>>
>> (Two results were exactly same.)
>>
>>
>>
>> Regarding  the CUDA version, I?m using v6.5.
>>
>>
>>
>> Thanks a lot for the help!
>>
>>
>>
>> Yang
>>
>>
>>
>>
>>
>> *From:* simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of *Simon
>> Rit
>> *Sent:* Thursday, November 12, 2015 5:59 PM
>>
>> *To:* Yang K Park <theday79 at gmail.com>
>> *Cc:* rtk-users at openrtk.org
>> *Subject:* Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
>> update
>>
>>
>>
>> Hi,
>>
>> Ok. Can you try rtkramp with only one projection? Then you shouldn't
>> encounter this regions issue (that should be solved one day but that's a
>> different story).
>>
>> Can you also indicate which version of CUDA you're using?
>>
>> FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft
>> for the FFT of the projections. So if they are not in the same format,
>> you're in trouble and that might be the issue here... The weird part is
>> that I didn't reproduce this problem on linux (with and without FFTW) but
>> it might be a CUDA version difference. I'll give it another try tomorrow
>> when you provide the CUDA version.
>>
>> Thanks again for reporting the issue,
>> Simon
>>
>>
>>
>> On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com> wrote:
>>
>> Hi Simon,
>>
>>
>>
>> Thanks for the advice. The current RTK was compiled with FFTW to use the
>> phase extraction feature from Amsterdam shroud.
>>
>>
>>
>> Regarding your suggestions,
>>
>>
>>
>> 1)      rtkramp w/ or w/o CUDA:
>>
>> (command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda
>> --output Ramp_wCUDA.mha? )
>>
>>
>>
>> Then, I have encountered following error.
>>
>> ?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that
>> input requested and buffered regions are equal.?
>>
>>
>>
>>
>>
>> Without CUDA, it was successfully done.
>>
>>
>>
>> 2)      I?ve re-compiled *ITK w/o FFTW* and built RTK again. r*tkfdk
>> worked fine.*
>>
>> -          I?ve also repeated ?rtkramp+CUDA? with this rtk version and
>> the error was same as above.
>>
>>
>>
>> In conclusion, my *FFTW seems to affect CUDA-based fdk reconstruction
>> only*.
>>
>> But I do need FFTW for the phase extraction. What should I do?
>>
>>
>>
>> Thanks.
>>
>>
>>
>> Yang
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of
>> Simon Rit
>> Sent: Wednesday, November 11, 2015 4:16 PM
>> To: Yang K Park <theday79 at gmail.com>
>> Cc: rtk-users at openrtk.org
>> Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
>> update
>>
>>
>>
>> Hi,
>>
>> I didn't manage to reproduce the two problems on linux with the same ITK
>> version.
>>
>> For point 1, did you copy itkMacro.h by hand? Because I don't see how
>> replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the
>> same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW?
>> It looks like a ramp filter issue. Can you try rtkramp --path projPath
>> --regexp .*.his, with and without --hardware cuda? Maybe you can provide
>> your geometry file in case it's a specific geometric issue.
>>
>> Simon
>>
>>
>>
>> On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
>>
>> > Hi all,
>>
>> >
>>
>> >
>>
>> >
>>
>> > I?ve updated rtk with the up-to-date revision and have encountered a
>>
>> > couple of problems.
>>
>> >
>>
>> >
>>
>> >
>>
>> > 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
>>
>> > rtkCudaUtilities.hcu. It was solved by a minor fetching:
>>
>> >
>>
>> > #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>>
>> >
>>
>> >
>>
>> >
>>
>> > 2.       Output of rtkfdk with CUDA was not the same as before. It was
>> very
>>
>> > blurry as seen in the attached image.
>>
>> >
>>
>> > a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>
>> > I?m using VS2013 with win7, itk4.8.1.
>>
>> >
>>
>> >
>>
>> >
>>
>> > The command line I used was :
>>
>> >
>>
>> > rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his
>>
>> > --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware
>>
>> > cuda --pad 1 --hann 5 --hannY 5
>>
>> >
>>
>> >
>>
>> >
>>
>> > Does anyone have any idea about this?
>>
>> >
>>
>> >
>>
>> >
>>
>> > Thanks.
>>
>> >
>>
>> >
>>
>> >
>>
>> > Yang
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>
>> > _______________________________________________
>>
>> > 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/20151116/90d2c5a0/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151116/90d2c5a0/attachment-0002.png>

From simon.rit at creatis.insa-lyon.fr  Fri Nov 20 11:28:22 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Fri, 20 Nov 2015 17:28:22 +0100
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAJM7=xjBjx=FzLazWJWqJbV5d45zGi2U71NKejm9HxKhJ0-xLQ@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
 <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
 <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>
 <CAJM7=xjBjx=FzLazWJWqJbV5d45zGi2U71NKejm9HxKhJ0-xLQ@mail.gmail.com>
Message-ID: <CAF0oig027_u_9gb8bnwT1w9jr3epZ0hkd9Mt73qK5heUq_kCkg@mail.gmail.com>

Hi Yang,
Thanks a lot for sharing the data. I have good news. I could reproduce the
bug and I have solutions. First, about your dataset: it's a huge dataset
and the hannY requires zero padding in both x and y. Because of this, cufft
has to take the 2D FFT of projection subsets that are 4095x2048x16. Quite
big!
When I ran it on my cuda 7.0, I immediately got:

itk::ExceptionObject (0x8b9cb30)
Location: "void CUDA_fft_convolution(const int3&, const int2&, float*,
cufftComplex*)"
File: /home/srit/src/rtk/rtk/code/rtkCudaFFTConvolutionImageFilter.cu
Line: 97
Description: itk::ERROR: CUFFT ERROR #2

i.e., a GPU alloc issue, even if I have the largest possible memory on a
nvidia desktop computer. Then, I ran it with cuda 6.5 and I got no error
message but a result similar to yours.
Conclusions:
- if you add the option --subsetsize 1 to your rtkfdk command line, that
should reconstruct correctly
- if you upgrade cuda, you should get an understandable error message,
- I don't think I'm going to look for a solution because the pb is probably
in cufft but if someone is willing to, be my guest!
Simon

On Mon, Nov 16, 2015 at 4:47 PM, Yang-Kyun Park <theday79 at gmail.com> wrote:

> Hi Simon,
>
> For better understanding, I'm attaching the problematic case including
> projection files, geometry file(xml) and reconstructed images.(please find
> the GDrive links. The file size is ~800 MB)
> This is phantom data and there is no patient information in it.
>
> Regarding the fftw library, I'm using [fftw-3.3.4-dll64].
>
> By the way, I found another clue. When I've tried it with a head phantom
> image (full-fan, ~ 190 projections), there was no problem. Is there any
> possibility that DDF and parker short filter play some roles on this issue?
>
> Feel free to let me know if further data is needed.
>
> Thanks!
>
> Yang
>
> ?
>  FFTW_issue.zip
> <https://drive.google.com/file/d/0BxuP3mON9V-qbVdQd0luc1lIb2M/view?usp=drive_web>
> ?
>
> On Mon, Nov 16, 2015 at 10:07 AM, Simon Rit <
> simon.rit at creatis.insa-lyon.fr> wrote:
>
>> Hi,
>> Thanks. It's really weird... When you run the tests with FFTW (compiling
>> the "test" target), do they fail?
>> Can you provide your geometry file? It might be specific to this geometry.
>> Thanks again for looking into this issue, we'll find what's the problem.
>> Simon
>>
>> On Mon, Nov 16, 2015 at 3:54 PM, Yang K Park <theday79 at gmail.com> wrote:
>>
>>> Hi Simon,
>>>
>>>
>>>
>>> Sorry for the late response.
>>>
>>>
>>>
>>> As you suggested, I?ve tried rtkramp+CUDA with only one projection and
>>> it was successfully done for both w/ FFTW and w/o FFTW.
>>>
>>> (Two results were exactly same.)
>>>
>>>
>>>
>>> Regarding  the CUDA version, I?m using v6.5.
>>>
>>>
>>>
>>> Thanks a lot for the help!
>>>
>>>
>>>
>>> Yang
>>>
>>>
>>>
>>>
>>>
>>> *From:* simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of *Simon
>>> Rit
>>> *Sent:* Thursday, November 12, 2015 5:59 PM
>>>
>>> *To:* Yang K Park <theday79 at gmail.com>
>>> *Cc:* rtk-users at openrtk.org
>>> *Subject:* Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
>>> update
>>>
>>>
>>>
>>> Hi,
>>>
>>> Ok. Can you try rtkramp with only one projection? Then you shouldn't
>>> encounter this regions issue (that should be solved one day but that's a
>>> different story).
>>>
>>> Can you also indicate which version of CUDA you're using?
>>>
>>> FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft
>>> for the FFT of the projections. So if they are not in the same format,
>>> you're in trouble and that might be the issue here... The weird part is
>>> that I didn't reproduce this problem on linux (with and without FFTW) but
>>> it might be a CUDA version difference. I'll give it another try tomorrow
>>> when you provide the CUDA version.
>>>
>>> Thanks again for reporting the issue,
>>> Simon
>>>
>>>
>>>
>>> On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com>
>>> wrote:
>>>
>>> Hi Simon,
>>>
>>>
>>>
>>> Thanks for the advice. The current RTK was compiled with FFTW to use the
>>> phase extraction feature from Amsterdam shroud.
>>>
>>>
>>>
>>> Regarding your suggestions,
>>>
>>>
>>>
>>> 1)      rtkramp w/ or w/o CUDA:
>>>
>>> (command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda
>>> --output Ramp_wCUDA.mha? )
>>>
>>>
>>>
>>> Then, I have encountered following error.
>>>
>>> ?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that
>>> input requested and buffered regions are equal.?
>>>
>>>
>>>
>>>
>>>
>>> Without CUDA, it was successfully done.
>>>
>>>
>>>
>>> 2)      I?ve re-compiled *ITK w/o FFTW* and built RTK again. r*tkfdk
>>> worked fine.*
>>>
>>> -          I?ve also repeated ?rtkramp+CUDA? with this rtk version and
>>> the error was same as above.
>>>
>>>
>>>
>>> In conclusion, my *FFTW seems to affect CUDA-based fdk reconstruction
>>> only*.
>>>
>>> But I do need FFTW for the phase extraction. What should I do?
>>>
>>>
>>>
>>> Thanks.
>>>
>>>
>>>
>>> Yang
>>>
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of
>>> Simon Rit
>>> Sent: Wednesday, November 11, 2015 4:16 PM
>>> To: Yang K Park <theday79 at gmail.com>
>>> Cc: rtk-users at openrtk.org
>>> Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
>>> update
>>>
>>>
>>>
>>> Hi,
>>>
>>> I didn't manage to reproduce the two problems on linux with the same ITK
>>> version.
>>>
>>> For point 1, did you copy itkMacro.h by hand? Because I don't see how
>>> replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the
>>> same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW?
>>> It looks like a ramp filter issue. Can you try rtkramp --path projPath
>>> --regexp .*.his, with and without --hardware cuda? Maybe you can provide
>>> your geometry file in case it's a specific geometric issue.
>>>
>>> Simon
>>>
>>>
>>>
>>> On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
>>>
>>> > Hi all,
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > I?ve updated rtk with the up-to-date revision and have encountered a
>>>
>>> > couple of problems.
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
>>>
>>> > rtkCudaUtilities.hcu. It was solved by a minor fetching:
>>>
>>> >
>>>
>>> > #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > 2.       Output of rtkfdk with CUDA was not the same as before. It was
>>> very
>>>
>>> > blurry as seen in the attached image.
>>>
>>> >
>>>
>>> > a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > I?m using VS2013 with win7, itk4.8.1.
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > The command line I used was :
>>>
>>> >
>>>
>>> > rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his
>>>
>>> > --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware
>>>
>>> > cuda --pad 1 --hann 5 --hannY 5
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > Does anyone have any idea about this?
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > Thanks.
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > Yang
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > _______________________________________________
>>>
>>> > 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/20151120/4e6c0e1e/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151120/4e6c0e1e/attachment-0002.png>

From theday79 at gmail.com  Fri Nov 20 12:36:51 2015
From: theday79 at gmail.com (Yang K Park)
Date: Fri, 20 Nov 2015 12:36:51 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAF0oig027_u_9gb8bnwT1w9jr3epZ0hkd9Mt73qK5heUq_kCkg@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
 <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
 <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>
 <CAJM7=xjBjx=FzLazWJWqJbV5d45zGi2U71NKejm9HxKhJ0-xLQ@mail.gmail.com>
 <CAF0oig027_u_9gb8bnwT1w9jr3epZ0hkd9Mt73qK5heUq_kCkg@mail.gmail.com>
Message-ID: <000901d123ba$0ae3de50$20ab9af0$@gmail.com>

Hi Simon,

 

That sounds great! Thanks a lot for your hard work.

As you said, now I can reconstruct it successfully with --subsetsize option.

 

I think the only concern left is the elongated reconstruction time.

I?ve measured it for the same phantom image with different ?subsetsize? values as well as w/o FFTW compiling.

I just report it for your information.

 

1)      w/o FFTW  : 21.4 s

2)      w/ FFTW & --subsetsize 1: 89 s

3)      w/ FFTW & --subsetsize 2: 77 s

4)      w/ FFTW & --subsetsize 4: 65 s

5)      w/ FFTW & --subsetsize 6: 51 s

6)      w/ FFTW & --subsetsize 7: (Error-graphic card seemed to be freezed)

7)      w/ FFTW & --subsetsize 8: (Error-?itk::ERROR: CUFFT ERROR #2 in rtkCudaFFTConvolutionImageFilter.cu?)

 

Of course, the difference was coming from the Ramp filter.

Therefore, I?m going to use [--subsetsize 6] for my system and will update CUDA version soon!

 

Thanks.

 

Yang

 

 

From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit
Sent: Friday, November 20, 2015 11:28 AM
To: Yang-Kyun Park <theday79 at gmail.com>
Cc: rtk-users at openrtk.org
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi Yang,
Thanks a lot for sharing the data. I have good news. I could reproduce the bug and I have solutions. First, about your dataset: it's a huge dataset and the hannY requires zero padding in both x and y. Because of this, cufft has to take the 2D FFT of projection subsets that are 4095x2048x16. Quite big!

When I ran it on my cuda 7.0, I immediately got:

itk::ExceptionObject (0x8b9cb30)
Location: "void CUDA_fft_convolution(const int3&, const int2&, float*, cufftComplex*)" 
File: /home/srit/src/rtk/rtk/code/rtkCudaFFTConvolutionImageFilter.cu
Line: 97
Description: itk::ERROR: CUFFT ERROR #2

i.e., a GPU alloc issue, even if I have the largest possible memory on a nvidia desktop computer. Then, I ran it with cuda 6.5 and I got no error message but a result similar to yours.

Conclusions:

- if you add the option --subsetsize 1 to your rtkfdk command line, that should reconstruct correctly

- if you upgrade cuda, you should get an understandable error message,

- I don't think I'm going to look for a solution because the pb is probably in cufft but if someone is willing to, be my guest!

Simon

 

On Mon, Nov 16, 2015 at 4:47 PM, Yang-Kyun Park <theday79 at gmail.com <mailto:theday79 at gmail.com> > wrote:

Hi Simon,

 

For better understanding, I'm attaching the problematic case including projection files, geometry file(xml) and reconstructed images.(please find the GDrive links. The file size is ~800 MB)

This is phantom data and there is no patient information in it.

 

Regarding the fftw library, I'm using [fftw-3.3.4-dll64].

 

By the way, I found another clue. When I've tried it with a head phantom image (full-fan, ~ 190 projections), there was no problem. Is there any possibility that DDF and parker short filter play some roles on this issue?

 

Feel free to let me know if further data is needed.

 

Thanks!

 

Yang

 

?

 <https://drive.google.com/file/d/0BxuP3mON9V-qbVdQd0luc1lIb2M/view?usp=drive_web>  FFTW_issue.zip

?

 

On Mon, Nov 16, 2015 at 10:07 AM, Simon Rit <simon.rit at creatis.insa-lyon.fr <mailto:simon.rit at creatis.insa-lyon.fr> > wrote:

Hi,

Thanks. It's really weird... When you run the tests with FFTW (compiling the "test" target), do they fail?
Can you provide your geometry file? It might be specific to this geometry.

Thanks again for looking into this issue, we'll find what's the problem.

Simon

 

On Mon, Nov 16, 2015 at 3:54 PM, Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> > wrote:

Hi Simon,

 

Sorry for the late response.

 

As you suggested, I?ve tried rtkramp+CUDA with only one projection and it was successfully done for both w/ FFTW and w/o FFTW.

(Two results were exactly same.)

 

Regarding  the CUDA version, I?m using v6.5.

 

Thanks a lot for the help!

 

Yang

 

 

From: simon.rit at gmail.com <mailto:simon.rit at gmail.com>  [mailto:simon.rit at gmail.com <mailto:simon.rit at gmail.com> ] On Behalf Of Simon Rit
Sent: Thursday, November 12, 2015 5:59 PM


To: Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> >
Cc: rtk-users at openrtk.org <mailto:rtk-users at openrtk.org> 
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

Ok. Can you try rtkramp with only one projection? Then you shouldn't encounter this regions issue (that should be solved one day but that's a different story). 

Can you also indicate which version of CUDA you're using?

FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft for the FFT of the projections. So if they are not in the same format, you're in trouble and that might be the issue here... The weird part is that I didn't reproduce this problem on linux (with and without FFTW) but it might be a CUDA version difference. I'll give it another try tomorrow when you provide the CUDA version.

Thanks again for reporting the issue,
Simon

 

On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> > wrote:

Hi Simon,

 

Thanks for the advice. The current RTK was compiled with FFTW to use the phase extraction feature from Amsterdam shroud.

 

Regarding your suggestions,

 

1)      rtkramp w/ or w/o CUDA:

(command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda --output Ramp_wCUDA.mha? )

 

Then, I have encountered following error.

?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that input requested and buffered regions are equal.?

 



 

Without CUDA, it was successfully done.

 

2)      I?ve re-compiled ITK w/o FFTW and built RTK again. rtkfdk worked fine.

-          I?ve also repeated ?rtkramp+CUDA? with this rtk version and the error was same as above.

 

In conclusion, my FFTW seems to affect CUDA-based fdk reconstruction only.

But I do need FFTW for the phase extraction. What should I do?

 

Thanks.

 

Yang

 

 

-----Original Message-----
From: simon.rit at gmail.com <mailto:simon.rit at gmail.com>  [mailto:simon.rit at gmail.com <mailto:simon.rit at gmail.com> ] On Behalf Of Simon Rit
Sent: Wednesday, November 11, 2015 4:16 PM
To: Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> >
Cc: rtk-users at openrtk.org <mailto:rtk-users at openrtk.org> 
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

I didn't manage to reproduce the two problems on linux with the same ITK version.

For point 1, did you copy itkMacro.h by hand? Because I don't see how replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW? It looks like a ramp filter issue. Can you try rtkramp --path projPath --regexp .*.his, with and without --hardware cuda? Maybe you can provide your geometry file in case it's a specific geometric issue.

Simon

 

On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park < <mailto:theday79 at gmail.com> theday79 at gmail.com> wrote:

> Hi all,

> 

> 

> 

> I?ve updated rtk with the up-to-date revision and have encountered a 

> couple of problems.

> 

> 

> 

> 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled

> rtkCudaUtilities.hcu. It was solved by a minor fetching:

> 

> #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu

> 

> 

> 

> 2.       Output of rtkfdk with CUDA was not the same as before. It was very

> blurry as seen in the attached image.

> 

> a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.

> 

> 

> 

> 

> 

> I?m using VS2013 with win7, itk4.8.1.

> 

> 

> 

> The command line I used was :

> 

> rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his 

> --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware 

> cuda --pad 1 --hann 5 --hannY 5

> 

> 

> 

> Does anyone have any idea about this?

> 

> 

> 

> Thanks.

> 

> 

> 

> Yang

> 

> 

> 

> 

> _______________________________________________

> Rtk-users mailing list

>  <mailto: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/20151120/0d98ace1/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151120/0d98ace1/attachment-0002.png>

From simon.rit at creatis.insa-lyon.fr  Wed Nov 25 02:36:44 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Wed, 25 Nov 2015 08:36:44 +0100
Subject: [Rtk-users] Compiling Problem
In-Reply-To: <040e01d125c7$83648e60$8a2dab20$@126.com>
References: <040e01d125c7$83648e60$8a2dab20$@126.com>
Message-ID: <5655650C.1040500@creatis.insa-lyon.fr>

Hi,
Please use the mailing list. I don't know where does the linking problem 
come from and it seems to work on our side:
http://my.cdash.org/index.php?project=RTK
Have you tried disabling CUDA?
Simon

On 23/11/2015 09:18, Freyman li wrote:
>
> Dear Simon,
>
> Recently I configured the RTK tool and suffer some problems. After set 
> up the itk tool and cuda, I compiled the rtk application but 
> encountered two errors attached to the email(jpg format)
>
> CUDA and ITK environment are tested successfully. My compile tool is 
> Visual studio 2012(64bit) and CUDA version is v6.5.
>
> Can you tell me how to deal with it and I am looking forward to hear 
> you again.
>
> Thank you!
>
> Best Regards
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151125/285f7f3c/attachment-0002.html>

From theday79 at gmail.com  Wed Nov 25 12:38:52 2015
From: theday79 at gmail.com (Yang K Park)
Date: Wed, 25 Nov 2015 12:38:52 -0500
Subject: [Rtk-users] Compiling Problem
In-Reply-To: <5655650C.1040500@creatis.insa-lyon.fr>
References: <040e01d125c7$83648e60$8a2dab20$@126.com>
 <5655650C.1040500@creatis.insa-lyon.fr>
Message-ID: <003d01d127a8$27a52b60$76ef8220$@gmail.com>

Hi Freyman,

 

I think your setting is much similar to mine, since I have compiled RTK with
VS2013 and CUDA v6.5 several times. Can you post those error messages again
so that I can see?

Yang

 

 

From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of
Simon Rit
Sent: Wednesday, November 25, 2015 2:37 AM
To: Freyman li <lihanwei_1500 at 126.com>
Cc: rtk-users at openrtk.org
Subject: Re: [Rtk-users] Compiling Problem

 

Hi,
Please use the mailing list. I don't know where does the linking problem
come from and it seems to work on our side:
http://my.cdash.org/index.php?project=RTK
Have you tried disabling CUDA?
Simon

On 23/11/2015 09:18, Freyman li wrote:

Dear Simon,

 

Recently I configured the RTK tool and suffer some problems. After set up
the itk tool and cuda, I compiled the rtk application but encountered two
errors attached to the email(jpg format)

CUDA and ITK environment are tested successfully. My compile tool is Visual
studio 2012(64bit) and CUDA version is v6.5.

Can you tell me how to deal with it and I am looking forward to hear you
again.

Thank you!

 

Best Regards

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151125/984feb50/attachment-0002.html>

From bioniloofar at gmail.com  Mon Nov 30 06:06:41 2015
From: bioniloofar at gmail.com (niloufar teyfouri)
Date: Mon, 30 Nov 2015 14:36:41 +0330
Subject: [Rtk-users] ElectaReconstruction
Message-ID: <CALChM12F4PuiLvgENg3Yyn7E+uZ7iPJ+GiY04z7VQ-90AS83EA@mail.gmail.com>

I ran the application of Electa Reconstruction implemented by you with
RTK. But after debugging I was encountered with the message of
"--output' ('-o') option required". Could you please help me for running
this example and the other ones?
I don't know any thing about the texts in the gray boxes mentioned at
each link related to examples of RTK.
For example in the link of
http://wiki.openrtk.org/index.php/RTK/Examples/ElektaReconstruction
how I should use gengetopt for the instructions below?


2. Run the application to convert Elekta's geometry into RTKs (DICOM_UID
is contained in the subfolder name of the his files):

  rtkelektasynergygeometry \
    --image_db IMAGE.DBF \
    --frame_db FRAME.DBF \
    --dicom_uid 1.3.46.423632.135428.1351013645.166 \
    -o elektaGeometry

I would be appreciate if one could answer my question.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151130/b11ad4e2/attachment-0002.html>

From cyril.mory at uclouvain.be  Mon Nov 30 09:30:48 2015
From: cyril.mory at uclouvain.be (Cyril Mory)
Date: Mon, 30 Nov 2015 15:30:48 +0100
Subject: [Rtk-users] ElectaReconstruction
In-Reply-To: <CALChM12F4PuiLvgENg3Yyn7E+uZ7iPJ+GiY04z7VQ-90AS83EA@mail.gmail.com>
References: <CALChM12F4PuiLvgENg3Yyn7E+uZ7iPJ+GiY04z7VQ-90AS83EA@mail.gmail.com>
Message-ID: <565C5D98.1000309@uclouvain.be>

Hi, and welcome to RTK,

Gengetopt is the piece of software that parses the command line 
arguments in all RTK applications. You do not have to "use" it. You just 
need to give correct arguments on the command line.

The message "--output' ('-o') option required" means what it says : you 
need to provide the name of the file in which you want to store the 
geometry information generated by the application 
rtkelektasynergygeometry. If you just copy-pasted the command you found 
on the wiki, then something went wrong during the copy-paste. Try to run 
the following :

rtkelektasynergygeometry --image_db IMAGE.DBF --frame_db FRAME.DBF 
--dicom_uid 1.3.46.423632.135428.1351013645.166 -o elektaGeometry

I just removed the '\' and the useless spaces. You can do the same for 
all other command line examples and it should work.

Let us know if you keep encountering trouble.
Cyril


Le 30/11/2015 12:06, niloufar teyfouri a ?crit :
>
> I ran the application of Electa Reconstruction implemented by you with
> RTK. But after debugging I was encountered with the message of
> "--output' ('-o') option required". Could you please help me for running
> this example and the other ones?
> I don't know any thing about the texts in the gray boxes mentioned at
> each link related to examples of RTK.
> For example in the link of
> http://wiki.openrtk.org/index.php/RTK/Examples/ElektaReconstruction
> how I should use gengetopt for the instructions below?
>
>
> 2. Run the application to convert Elekta's geometry into RTKs (DICOM_UID
> is contained in the subfolder name of the his files):
>
> rtkelektasynergygeometry \
> --image_db IMAGE.DBF \
> --frame_db FRAME.DBF \
> --dicom_uid 1.3.46.423632.135428.1351013645.166 \
>     -o elektaGeometry
>
> I would be appreciate if one could answer my question.
>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151130/66741755/attachment-0002.html>

From j.mason at ed.ac.uk  Mon Nov 30 11:29:27 2015
From: j.mason at ed.ac.uk (Jonathan Mason)
Date: Mon, 30 Nov 2015 16:29:27 +0000
Subject: [Rtk-users] Preprocessing
Message-ID: <565C7967.4000401@ed.ac.uk>

Good afternoon RTK users,

I have access to "raw data" from a Varian OBI scanner, and have
experimented with RTK for performing its reconstruction. However, it is
not really "raw" in the sense that the coefficients are proportional to
the photon flux recorded at a given sensor, but is instead proportional
to the Hounsfield attenuation along that path. With this data, it means
that one can reconstruct using FDK and other iterative techniques, which
assume a linear model, but the connection to the underlying physics is
abstract.

The problem I then have when trying to develop reconstruction
techniques, is that I do not know whether I am really correcting for
physical distortions or just correcting for Varian's preprocessing,
which has been finely tuned for its own FDK method.

My question is whether anybody has dug into the steps that manufacturers
such as Varian or Elekta perform to arrive at these projection images?
And if they think that if reverse engineered, could provide a richer set
of information to facilitate advanced strategies.

Best wishes,

Jonathan Mason

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.



From simon.rit at creatis.insa-lyon.fr  Mon Nov 30 12:44:03 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Mon, 30 Nov 2015 18:44:03 +0100
Subject: [Rtk-users] ElectaReconstruction
In-Reply-To: <565C5D98.1000309@uclouvain.be>
References: <CALChM12F4PuiLvgENg3Yyn7E+uZ7iPJ+GiY04z7VQ-90AS83EA@mail.gmail.com>
 <565C5D98.1000309@uclouvain.be>
Message-ID: <CAF0oig2Zg96AZaRn9w9=F+LnLnyteTn5zS1rLguQ8WXiYhnnYg@mail.gmail.com>

Hi,
I think Cyril is right, it's not possible to use backslashes to put a
command line on several line with Windows command line. Can you confirm
this? If you confirm, we will correct the wiki.
Thanks,
Simon

On Mon, Nov 30, 2015 at 3:30 PM, Cyril Mory <cyril.mory at uclouvain.be> wrote:

> Hi, and welcome to RTK,
>
> Gengetopt is the piece of software that parses the command line arguments
> in all RTK applications. You do not have to "use" it. You just need to give
> correct arguments on the command line.
>
> The message "--output' ('-o') option required" means what it says : you
> need to provide the name of the file in which you want to store the
> geometry information generated by the application rtkelektasynergygeometry.
> If you just copy-pasted the command you found on the wiki, then something
> went wrong during the copy-paste. Try to run the following :
>
> rtkelektasynergygeometry --image_db IMAGE.DBF --frame_db FRAME.DBF
> --dicom_uid 1.3.46.423632.135428.1351013645.166 -o elektaGeometry
>
> I just removed the '\' and the useless spaces. You can do the same for all
> other command line examples and it should work.
>
> Let us know if you keep encountering trouble.
> Cyril
>
>
>
> Le 30/11/2015 12:06, niloufar teyfouri a ?crit :
>
>
> I ran the application of Electa Reconstruction implemented by you with
> RTK. But after debugging I was encountered with the message of
> "--output' ('-o') option required". Could you please help me for running
> this example and the other ones?
> I don't know any thing about the texts in the gray boxes mentioned at
> each link related to examples of RTK.
> For example in the link of
> http://wiki.openrtk.org/index.php/RTK/Examples/ElektaReconstruction
> how I should use gengetopt for the instructions below?
>
>
> 2. Run the application to convert Elekta's geometry into RTKs (DICOM_UID
> is contained in the subfolder name of the his files):
>
>   rtkelektasynergygeometry \
>     --image_db IMAGE.DBF \
>     --frame_db FRAME.DBF \
>     --dicom_uid 1.3.46.423632.135428.1351013645.166 \
>     -o elektaGeometry
>
> I would be appreciate if one could answer my question.
>
>
> _______________________________________________
> Rtk-users mailing listRtk-users at public.kitware.comhttp://public.kitware.com/mailman/listinfo/rtk-users
>
>
>
>
> ------------------------------
> [image: Avast logo] <https://www.avast.com/antivirus>
>
> L'absence de virus dans ce courrier ?lectronique a ?t? v?rifi?e par le
> logiciel antivirus Avast.
> www.avast.com <https://www.avast.com/antivirus>
>
>
> _______________________________________________
> 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/20151130/6d6dd6aa/attachment-0002.html>

From wuchao04 at gmail.com  Mon Nov 30 13:50:06 2015
From: wuchao04 at gmail.com (Chao Wu)
Date: Mon, 30 Nov 2015 19:50:06 +0100
Subject: [Rtk-users] Preprocessing
In-Reply-To: <565C7967.4000401@ed.ac.uk>
References: <565C7967.4000401@ed.ac.uk>
Message-ID: <CAH+sHrUFov5f=8h4-ePhC2xLraM3BxA9r12yfXdM3rrKPeqCBg@mail.gmail.com>

Hi Jonathan,

I do not quite understand your problem.
I think most information can be retrieved by the relationship between flux
(I) and attenuation (u):
I = I0 * exp (- integral(u * dL) )
Of course there are other effects like beam hardening and scattering
involved but this model is the basic.

Regards,
Chao

2015-11-30 17:29 GMT+01:00 Jonathan Mason <j.mason at ed.ac.uk>:

> Good afternoon RTK users,
>
> I have access to "raw data" from a Varian OBI scanner, and have
> experimented with RTK for performing its reconstruction. However, it is
> not really "raw" in the sense that the coefficients are proportional to
> the photon flux recorded at a given sensor, but is instead proportional
> to the Hounsfield attenuation along that path. With this data, it means
> that one can reconstruct using FDK and other iterative techniques, which
> assume a linear model, but the connection to the underlying physics is
> abstract.
>
> The problem I then have when trying to develop reconstruction
> techniques, is that I do not know whether I am really correcting for
> physical distortions or just correcting for Varian's preprocessing,
> which has been finely tuned for its own FDK method.
>
> My question is whether anybody has dug into the steps that manufacturers
> such as Varian or Elekta perform to arrive at these projection images?
> And if they think that if reverse engineered, could provide a richer set
> of information to facilitate advanced strategies.
>
> Best wishes,
>
> Jonathan Mason
>
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
> _______________________________________________
> 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/20151130/ccb833fe/attachment-0002.html>

From mdupont at cppm.in2p3.fr  Sun Nov  1 12:41:49 2015
From: mdupont at cppm.in2p3.fr (Mathieu Dupont)
Date: Sun, 01 Nov 2015 18:41:49 +0100
Subject: [Rtk-users] question about rtkDraw*ImageFilter
In-Reply-To: <56334CF2.8070902@cppm.in2p3.fr>
References: <5630EE01.5070900@cppm.in2p3.fr>
 <CAF0oig279ZWGJMFnJdXaPiYLPponadz_J-PVKt2z3iHiTRQ_gg@mail.gmail.com>
 <56334CF2.8070902@cppm.in2p3.fr>
Message-ID: <1539144.WPSdtJ8lhZ@marabunta>

Hello Simon, 

I started to implement what I suggested : 

https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawImageFilter.h
and 
https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawCylinderImageFilter.h

rtk::DrawCylinderImageFilter derives from rtk::DrawImageFilter and specializes 
it (by defaulting the template parameter TSpatialObject with 
DrawCylinderSpatialObject). 

By default, DrawCylinderImageFilter uses Add2 for filling output image (to be 
backward compatible (all tests pass)). I created Discard (I did not find 
equivalent in itk) functor in order to do what I wanted in my first email.  

I just implemented DrawCylinderImageFilter, the others will follow. 

What do you think about it ?

Le vendredi 30 octobre 2015, 11:56:50 Mathieu Dupont a ?crit :
> Hi,
> 
> In case of your first solution, you can not chain several
> Draw*ImageFilters. For example, if you want to create small cylinders in
> a big cylinder.
> 
> Your second solution is better.
> 
> One another solution can be a thing like itk:SpatialObject but more
> simpler. An rtk::SpatialObject which one function (isInside(point)). We
> create a rtkDrawImageFilter class and implement ThreadedGenerateData
> like this :
> 
> DrawImageFilter<InImage, OutImage, rtkSpatialObject,
> rtkFillFunctor>::ThreadedGenerateData(const OutputImageRegionType&
> outputRegionForThread,                 ThreadIdType itkNotUsed(threadId)
> {
> ...
> 
>   while( !itOut.IsAtEnd() )
>      {
>      this->GetInput()->TransformIndexToPhysicalPoint(itOut.GetIndex(),
> point);
> 
>     if(m_rtkSpatialObject.isInside(point)
>       itOut.Set(m_rtkFillFunctor(density, itIn.Get());
> ...
> }
> 
> 
> DrawConeImageFilter class can be a child of this new DrawImageFilter
> (with new methods like setAngle, SetRadius which will adjust the
> rtkConeSpatialObject)
> 
> This solution suppress duplicated code in
> Draw*ImageFilter::ThreadedGenerateData and makes easier implementation
> of another type of filling.
> 
> On 28/10/2015 20:52, Simon Rit wrote:
> > Hi Mathieu,
> > Thanks for pointing this out. I agree that it might not be the best
> > solution, yet one could argue that you could simply create a constant
> > image with 0 to do what you'd like from the current implementation. My
> > main problem is that I just tried to do what you suggest and some tests
> > then fail... which shows the obvious, it's not a backward compatible
> > change. I see two solutions:
> > - keep it as is and you use ConstantImageFilter + we remove useless add
> > filters,
> > - a more complex but maybe more elegant solution: add a third template
> > parameter for the operation that would allow the user to do what he'd
> > like in a functor. That's what's done with filters that derive from
> > itk::UnaryImageFilter
> > <http://www.itk.org/Doxygen/html/classitk_1_1UnaryFunctorImageFilter.html>
> > .
> > The default would be itk::Add2 but we could find or implement another
> > one that simply discards the pixel value.
> > What do you think?
> > Simon
> > 
> > PS: looking in the code, I just found that rtk::DrawConeImageFilter is
> > not consistent with the others, it was always setting to 0 outside...
> > that's been fixed!
> > 
> > On Wed, Oct 28, 2015 at 4:47 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr
> > 
> > <mailto:mdupont at cppm.in2p3.fr>> wrote:
> >     Hello everyone,
> >     
> >     I have a question/suggestion about the set of rtkDraw*ImageFilter.
> >     This filter are written as additive filters: for example, in
> >     rtkDrawEllipsoidImageFilter.txx, we can find
> >     
> >     for(..)
> >     
> >       itOut.Set( ellipsoid.density + itIn.Get() )
> >     
> >     instead of
> >     
> >     for(..)
> >     itOut.Set( ellipsoid.density )
> >     
> >     
> >     I think it can be more flexible the second option, because we can
> >     always associate Draw*ImageFilter and itkAddImageFilter to get an
> >     additive filter.
> >     
> >     Moreover, the  rtkDrawGeometricPhantomImageFilter class already uses
> >     itkAddImageFilter in order to have additive filters (which is
> >     redundant in current situation).
> >     
> >     What do you think ?
> >     
> >     
> >     
> >     
> >     
> >     Regards
> >     
> >     
> >     
> >     _______________________________________________
> >     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


From gnthibault at gmail.com  Mon Nov  2 08:08:42 2015
From: gnthibault at gmail.com (Notargiacomo Thibault)
Date: Mon, 2 Nov 2015 14:08:42 +0100
Subject: [Rtk-users] Problem with rtkGgoFunctions when importing series of
	images
Message-ID: <CAP+mR7Zw7WmRmEgVUTamNhS6m4S6ORvWFjRu1EANViPRJ7jtuQ@mail.gmail.com>

I recently experienced the following problem, when importing multiple tif
files inside a directory using itk::ImageSeriesReader:

[...]
code/rtkGgoFunctions.h: In instantiation of ?void
rtk::SetProjectionsReaderFromGgo(typename TProjectionsReaderType::Pointer,
const TArgsInfo&)
[...]
code/rtkGgoFunctions.h:121:61: error: no type named
?OutputImageDirectionType? in ?class
itk::ImageSeriesReader<itk::Image<short unsigned int, 3u> >?
   typename TProjectionsReaderType::OutputImageDirectionType direction;
[...]

It seems that, a new functionality added in rtkGgoFunctions.h (19/05/2015),
allowing to directly modify input images properties through command line,
like geometry (direction vector), assumes that the input image type defines
OutputImageDirectionType, but in the case of itk::ImageSeriesReader, it
does not.

Is this considered as a regression, or should the
SetProjectionsReaderFromGgo function be used with specific input image type
?

Thank you in advance for your help.

Kind regards

Thibault Notargiacomo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151102/6cad3583/attachment-0003.html>

From simon.rit at creatis.insa-lyon.fr  Mon Nov  2 08:58:24 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Mon, 2 Nov 2015 14:58:24 +0100
Subject: [Rtk-users] Problem with rtkGgoFunctions when importing series
	of images
In-Reply-To: <CAP+mR7Zw7WmRmEgVUTamNhS6m4S6ORvWFjRu1EANViPRJ7jtuQ@mail.gmail.com>
References: <CAP+mR7Zw7WmRmEgVUTamNhS6m4S6ORvWFjRu1EANViPRJ7jtuQ@mail.gmail.com>
Message-ID: <CAF0oig2bAidO4JR7pa_PUxOQm-X7JrEz8=ybGX3bskYJM9YRAQ@mail.gmail.com>

Hi Thibault,
SetProjectionsReaderFromGgo is a macro designed for the
rtk::ProjectionsReader
<http://www.openrtk.org/Doxygen/classrtk_1_1ProjectionsReader.html>, I'm
not surprised that it does not work with the itk::ImageSeriesReader. It's
not about the image type but about the filter type... We use this macro to
set many parameters specific to the rtk::ProjectionsReader
<http://www.openrtk.org/Doxygen/classrtk_1_1ProjectionsReader.html>. Since
a while, I have made have a common rtkinputprojections_section.ggo
<https://github.com/SimonRit/RTK/blob/master/applications/rtkinputprojections_section.ggo>
file for all the applications that use the rtk::ProjectionsReader.
If you don't want to use the rtk::ProjectionsReader but
itk::ImageSeriesReader (e.g., because it does a lot of automatic processing
that you don't want), you'll have to write your own code to set it up.
I hope this clarifies things.
Simon

On Mon, Nov 2, 2015 at 2:08 PM, Notargiacomo Thibault <gnthibault at gmail.com>
wrote:

> I recently experienced the following problem, when importing multiple tif
> files inside a directory using itk::ImageSeriesReader:
>
> [...]
> code/rtkGgoFunctions.h: In instantiation of ?void
> rtk::SetProjectionsReaderFromGgo(typename TProjectionsReaderType::Pointer,
> const TArgsInfo&)
> [...]
> code/rtkGgoFunctions.h:121:61: error: no type named
> ?OutputImageDirectionType? in ?class
> itk::ImageSeriesReader<itk::Image<short unsigned int, 3u> >?
>    typename TProjectionsReaderType::OutputImageDirectionType direction;
> [...]
>
> It seems that, a new functionality added in rtkGgoFunctions.h
> (19/05/2015), allowing to directly modify input images properties through
> command line, like geometry (direction vector), assumes that the input
> image type defines OutputImageDirectionType, but in the case of
> itk::ImageSeriesReader, it does not.
>
> Is this considered as a regression, or should the
> SetProjectionsReaderFromGgo function be used with specific input image type
> ?
>
> Thank you in advance for your help.
>
> Kind regards
>
> Thibault Notargiacomo
>
> _______________________________________________
> 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/20151102/ee7e2c17/attachment-0003.html>

From simon.rit at creatis.insa-lyon.fr  Wed Nov  4 16:38:18 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Wed, 4 Nov 2015 22:38:18 +0100
Subject: [Rtk-users] question about rtkDraw*ImageFilter
In-Reply-To: <1539144.WPSdtJ8lhZ@marabunta>
References: <5630EE01.5070900@cppm.in2p3.fr>
 <CAF0oig279ZWGJMFnJdXaPiYLPponadz_J-PVKt2z3iHiTRQ_gg@mail.gmail.com>
 <56334CF2.8070902@cppm.in2p3.fr> <1539144.WPSdtJ8lhZ@marabunta>
Message-ID: <CAF0oig3jBsfoadM_k6SYvOMwikOCNFmH19J7m1YJZx-RU0y+5g@mail.gmail.com>

Hi Mathieu,
Sorry, I'm very busy these days. I had a first quick look. Why not, it
looks a bit complicated but good. I would have a few things I would change
style wise, e.g., move DrawCylinderSpatialObject to
DrawCylinderImageFilter, create a common DrawQuadricSpatialObject that
would all have the same IsInside function, make DrawSpatialObjectpurely
virtual by not defining
IsInside etc. but those are details I can correct myself. Do you want to
finish what you started and I work from there or should I finish everything?
Simon

On Sun, Nov 1, 2015 at 6:41 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr>
wrote:

> Hello Simon,
>
> I started to implement what I suggested :
>
>
> https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawImageFilter.h
> and
>
> https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawCylinderImageFilter.h
>
> rtk::DrawCylinderImageFilter derives from rtk::DrawImageFilter and
> specializes
> it (by defaulting the template parameter TSpatialObject with
> DrawCylinderSpatialObject).
>
> By default, DrawCylinderImageFilter uses Add2 for filling output image (to
> be
> backward compatible (all tests pass)). I created Discard (I did not find
> equivalent in itk) functor in order to do what I wanted in my first email.
>
> I just implemented DrawCylinderImageFilter, the others will follow.
>
> What do you think about it ?
>
> Le vendredi 30 octobre 2015, 11:56:50 Mathieu Dupont a ?crit :
> > Hi,
> >
> > In case of your first solution, you can not chain several
> > Draw*ImageFilters. For example, if you want to create small cylinders in
> > a big cylinder.
> >
> > Your second solution is better.
> >
> > One another solution can be a thing like itk:SpatialObject but more
> > simpler. An rtk::SpatialObject which one function (isInside(point)). We
> > create a rtkDrawImageFilter class and implement ThreadedGenerateData
> > like this :
> >
> > DrawImageFilter<InImage, OutImage, rtkSpatialObject,
> > rtkFillFunctor>::ThreadedGenerateData(const OutputImageRegionType&
> > outputRegionForThread,                 ThreadIdType itkNotUsed(threadId)
> > {
> > ...
> >
> >   while( !itOut.IsAtEnd() )
> >      {
> >      this->GetInput()->TransformIndexToPhysicalPoint(itOut.GetIndex(),
> > point);
> >
> >     if(m_rtkSpatialObject.isInside(point)
> >       itOut.Set(m_rtkFillFunctor(density, itIn.Get());
> > ...
> > }
> >
> >
> > DrawConeImageFilter class can be a child of this new DrawImageFilter
> > (with new methods like setAngle, SetRadius which will adjust the
> > rtkConeSpatialObject)
> >
> > This solution suppress duplicated code in
> > Draw*ImageFilter::ThreadedGenerateData and makes easier implementation
> > of another type of filling.
> >
> > On 28/10/2015 20:52, Simon Rit wrote:
> > > Hi Mathieu,
> > > Thanks for pointing this out. I agree that it might not be the best
> > > solution, yet one could argue that you could simply create a constant
> > > image with 0 to do what you'd like from the current implementation. My
> > > main problem is that I just tried to do what you suggest and some tests
> > > then fail... which shows the obvious, it's not a backward compatible
> > > change. I see two solutions:
> > > - keep it as is and you use ConstantImageFilter + we remove useless add
> > > filters,
> > > - a more complex but maybe more elegant solution: add a third template
> > > parameter for the operation that would allow the user to do what he'd
> > > like in a functor. That's what's done with filters that derive from
> > > itk::UnaryImageFilter
> > > <
> http://www.itk.org/Doxygen/html/classitk_1_1UnaryFunctorImageFilter.html>
> > > .
> > > The default would be itk::Add2 but we could find or implement another
> > > one that simply discards the pixel value.
> > > What do you think?
> > > Simon
> > >
> > > PS: looking in the code, I just found that rtk::DrawConeImageFilter is
> > > not consistent with the others, it was always setting to 0 outside...
> > > that's been fixed!
> > >
> > > On Wed, Oct 28, 2015 at 4:47 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr
> > >
> > > <mailto:mdupont at cppm.in2p3.fr>> wrote:
> > >     Hello everyone,
> > >
> > >     I have a question/suggestion about the set of rtkDraw*ImageFilter.
> > >     This filter are written as additive filters: for example, in
> > >     rtkDrawEllipsoidImageFilter.txx, we can find
> > >
> > >     for(..)
> > >
> > >       itOut.Set( ellipsoid.density + itIn.Get() )
> > >
> > >     instead of
> > >
> > >     for(..)
> > >     itOut.Set( ellipsoid.density )
> > >
> > >
> > >     I think it can be more flexible the second option, because we can
> > >     always associate Draw*ImageFilter and itkAddImageFilter to get an
> > >     additive filter.
> > >
> > >     Moreover, the  rtkDrawGeometricPhantomImageFilter class already
> uses
> > >     itkAddImageFilter in order to have additive filters (which is
> > >     redundant in current situation).
> > >
> > >     What do you think ?
> > >
> > >
> > >
> > >
> > >
> > >     Regards
> > >
> > >
> > >
> > >     _______________________________________________
> > >     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/20151104/46314d97/attachment-0003.html>

From mdupont at cppm.in2p3.fr  Mon Nov  9 14:35:47 2015
From: mdupont at cppm.in2p3.fr (Mathieu Dupont)
Date: Mon, 09 Nov 2015 20:35:47 +0100
Subject: [Rtk-users] question about rtkDraw*ImageFilter
In-Reply-To: <CAF0oig3jBsfoadM_k6SYvOMwikOCNFmH19J7m1YJZx-RU0y+5g@mail.gmail.com>
References: <5630EE01.5070900@cppm.in2p3.fr> <1539144.WPSdtJ8lhZ@marabunta>
 <CAF0oig3jBsfoadM_k6SYvOMwikOCNFmH19J7m1YJZx-RU0y+5g@mail.gmail.com>
Message-ID: <5634494.U9CmFl2V79@marabunta>

hi, 

i will do this during this week and try to implement your remarks. 


Le mercredi 4 novembre 2015, 22:38:18 Simon Rit a ?crit :
> Hi Mathieu,
> Sorry, I'm very busy these days. I had a first quick look. Why not, it
> looks a bit complicated but good. I would have a few things I would change
> style wise, e.g., move DrawCylinderSpatialObject to
> DrawCylinderImageFilter, create a common DrawQuadricSpatialObject that
> would all have the same IsInside function, make DrawSpatialObjectpurely
> virtual by not defining
> IsInside etc. but those are details I can correct myself. Do you want to
> finish what you started and I work from there or should I finish everything?
> Simon
> 
> On Sun, Nov 1, 2015 at 6:41 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr>
> 
> wrote:
> > Hello Simon,
> > 
> > I started to implement what I suggested :
> > 
> > 
> > https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawImag
> > eFilter.h and
> > 
> > https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawCyli
> > nderImageFilter.h
> > 
> > rtk::DrawCylinderImageFilter derives from rtk::DrawImageFilter and
> > specializes
> > it (by defaulting the template parameter TSpatialObject with
> > DrawCylinderSpatialObject).
> > 
> > By default, DrawCylinderImageFilter uses Add2 for filling output image (to
> > be
> > backward compatible (all tests pass)). I created Discard (I did not find
> > equivalent in itk) functor in order to do what I wanted in my first email.
> > 
> > I just implemented DrawCylinderImageFilter, the others will follow.
> > 
> > What do you think about it ?
> > 
> > Le vendredi 30 octobre 2015, 11:56:50 Mathieu Dupont a ?crit :
> > > Hi,
> > > 
> > > In case of your first solution, you can not chain several
> > > Draw*ImageFilters. For example, if you want to create small cylinders in
> > > a big cylinder.
> > > 
> > > Your second solution is better.
> > > 
> > > One another solution can be a thing like itk:SpatialObject but more
> > > simpler. An rtk::SpatialObject which one function (isInside(point)). We
> > > create a rtkDrawImageFilter class and implement ThreadedGenerateData
> > > like this :
> > > 
> > > DrawImageFilter<InImage, OutImage, rtkSpatialObject,
> > > rtkFillFunctor>::ThreadedGenerateData(const OutputImageRegionType&
> > > outputRegionForThread,                 ThreadIdType itkNotUsed(threadId)
> > > {
> > > ...
> > > 
> > >   while( !itOut.IsAtEnd() )
> > >   
> > >      {
> > >      this->GetInput()->TransformIndexToPhysicalPoint(itOut.GetIndex(),
> > > 
> > > point);
> > > 
> > >     if(m_rtkSpatialObject.isInside(point)
> > >     
> > >       itOut.Set(m_rtkFillFunctor(density, itIn.Get());
> > > 
> > > ...
> > > }
> > > 
> > > 
> > > DrawConeImageFilter class can be a child of this new DrawImageFilter
> > > (with new methods like setAngle, SetRadius which will adjust the
> > > rtkConeSpatialObject)
> > > 
> > > This solution suppress duplicated code in
> > > Draw*ImageFilter::ThreadedGenerateData and makes easier implementation
> > > of another type of filling.
> > > 
> > > On 28/10/2015 20:52, Simon Rit wrote:
> > > > Hi Mathieu,
> > > > Thanks for pointing this out. I agree that it might not be the best
> > > > solution, yet one could argue that you could simply create a constant
> > > > image with 0 to do what you'd like from the current implementation. My
> > > > main problem is that I just tried to do what you suggest and some
> > > > tests
> > > > then fail... which shows the obvious, it's not a backward compatible
> > > > change. I see two solutions:
> > > > - keep it as is and you use ConstantImageFilter + we remove useless
> > > > add
> > > > filters,
> > > > - a more complex but maybe more elegant solution: add a third template
> > > > parameter for the operation that would allow the user to do what he'd
> > > > like in a functor. That's what's done with filters that derive from
> > > > itk::UnaryImageFilter
> > > > <
> > 
> > http://www.itk.org/Doxygen/html/classitk_1_1UnaryFunctorImageFilter.html>
> > 
> > > > .
> > > > The default would be itk::Add2 but we could find or implement another
> > > > one that simply discards the pixel value.
> > > > What do you think?
> > > > Simon
> > > > 
> > > > PS: looking in the code, I just found that rtk::DrawConeImageFilter is
> > > > not consistent with the others, it was always setting to 0 outside...
> > > > that's been fixed!
> > > > 
> > > > On Wed, Oct 28, 2015 at 4:47 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr
> > > > 
> > > > <mailto:mdupont at cppm.in2p3.fr>> wrote:
> > > >     Hello everyone,
> > > >     
> > > >     I have a question/suggestion about the set of rtkDraw*ImageFilter.
> > > >     This filter are written as additive filters: for example, in
> > > >     rtkDrawEllipsoidImageFilter.txx, we can find
> > > >     
> > > >     for(..)
> > > >     
> > > >       itOut.Set( ellipsoid.density + itIn.Get() )
> > > >     
> > > >     instead of
> > > >     
> > > >     for(..)
> > > >     itOut.Set( ellipsoid.density )
> > > >     
> > > >     
> > > >     I think it can be more flexible the second option, because we can
> > > >     always associate Draw*ImageFilter and itkAddImageFilter to get an
> > > >     additive filter.
> > > >     
> > > >     Moreover, the  rtkDrawGeometricPhantomImageFilter class already
> > 
> > uses
> > 
> > > >     itkAddImageFilter in order to have additive filters (which is
> > > >     redundant in current situation).
> > > >     
> > > >     What do you think ?
> > > >     
> > > >     
> > > >     
> > > >     
> > > >     
> > > >     Regards
> > > >     
> > > >     
> > > >     
> > > >     _______________________________________________
> > > >     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


From gnthibault at gmail.com  Tue Nov 10 07:39:46 2015
From: gnthibault at gmail.com (Notargiacomo Thibault)
Date: Tue, 10 Nov 2015 13:39:46 +0100
Subject: [Rtk-users] Understanding projection matrices management in
	rtkCudaBackProjectionImageFilter
Message-ID: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>

Hi all,

I am currently trying to use the "AddProjectionInRadians" method from the
ThreeDCircularProjectionGeometry class in RTK to import my geometry.

First things first, I would like to know if the information on this pdf are
still valid: http://www.openrtk.org/Doxygen/geometry.pdf

Because I used them to deduce the source offset and Projection offset from
my own matrix decomposition.

Notice that I don't want to use geometric informations coming from the
projection images themselves, so their geometric origin is assumed to be
(0,0,0) in my case.

In order to check if my geometry import method is correct, I print out one
of the intermediate form of the projection matrix used in the
backprojection process, in order to check if it is the same as in my own
implementation.

To do so, I print out one of the intermediate matrix that is generated in
rtkCudaBackProjectionImageFilter while launching a SART reconstruction for
instance.

I was surpised by the fact that, the matrix allowing the transformation
from 2D geometric world to 2D image index world, namely matrixIdxProj in
rtkCudaBackProjectionImageFilte.cxx
<http://www.openrtk.org/Doxygen/rtkCudaBackProjectionImageFilter_8cxx_source.html>
is not always the same along the reconstruction process ?

Here is the line that generates the matrix I don't understand:

for(unsigned int i=0; i<2; i++)
 //SR: 0.5 for 2D texture
  matrixIdxProj[i][2] =
-1*(this->GetInput(1)->GetBufferedRegion().GetIndex()[i])+0.5;

What I understand here, is that, we are generating a 2D translation matrix
embedded in a 3*3 matrix that allows to take into account two things
related to the 2D projection:

-If the internal behaviour of the imageContainer, allows buffering of only
a part of the image, beginning at index (i,j), this information will be
embeded in the projection matrix

-the ITK floating point addressing definition seems to differ from the one
from cuda (and openCV):
When I take a look at this page
<http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#texture-fetching>
I understand that the floating point indexing (0.5,0.5) in Cuda points to
the center of the pixel (0,0) hence a linear contribution of 100%, while it
seems that we must add a translation of (0.5,0.5) to the ITK geometric
framework in order to get the same behaviour.

In practice matrixIdxProj is based on a 3*3 identity matrix, where the
inner 2D translation (ie 2 first term of the last column) in my case are:
-in X, a random number between 10 and 150 plus 0.5
-in Y: always 0.5

I understand the 0.5 part, but why is there always a 0 offset in Y but a
random offset in X remains a mystery to me.

At first, I believed that each projection was splitted into multiple part,
each having a different X and Y offset.
But reconstructing using only one projection generates only one
backprojection operation, with a non zero offset in X, 123 in my case, for
an image of size 780 in X.

Do you think there is something wrong whith the values of matrixIdxProjI am
experiencing ?

Thank you in advance.

Kind regards

Thibault Notargiacomo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151110/fbd3fb46/attachment-0003.html>

From simon.rit at creatis.insa-lyon.fr  Tue Nov 10 08:21:29 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Tue, 10 Nov 2015 14:21:29 +0100
Subject: [Rtk-users] Understanding projection matrices management in
	rtkCudaBackProjectionImageFilter
In-Reply-To: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>
References: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>
Message-ID: <CAF0oig3muuH+1=eLZ66DJ22QcnsSrUKzRFS4RzDRvDJXNxAVXg@mail.gmail.com>

Hi Thibault,
You started digging in the code so that gets complicated. First thing
first, yes, the link you provide is still valid.
The offset in X is not random but computed in
BackProjectionImageFilter::GenerateInputRequestedRegion
<https://github.com/SimonRit/RTK/blob/master/code/rtkBackProjectionImageFilter.txx>.
The idea is that we request only the part of the projections we need to do
the backprojection. This optimizes the streaming (we only read from disk
what we need). If you use a huge volume (the test I'd suggest to validate
that I'm correct and there is nothing wrong with your code), then you'll
need the full projection and you will always get 0 in X as in Y. If you use
a small volume and do a computation projection per projection, you will get
a varying index depending on your input volume and the geometry for that
projection.
I think you understood the rest pretty well. Does that make sense or am I
missing something else?
Simon

On Tue, Nov 10, 2015 at 1:39 PM, Notargiacomo Thibault <gnthibault at gmail.com
> wrote:

> Hi all,
>
> I am currently trying to use the "AddProjectionInRadians" method from the
> ThreeDCircularProjectionGeometry class in RTK to import my geometry.
>
> First things first, I would like to know if the information on this pdf
> are still valid: http://www.openrtk.org/Doxygen/geometry.pdf
>
> Because I used them to deduce the source offset and Projection offset from
> my own matrix decomposition.
>
> Notice that I don't want to use geometric informations coming from the
> projection images themselves, so their geometric origin is assumed to be
> (0,0,0) in my case.
>
> In order to check if my geometry import method is correct, I print out one
> of the intermediate form of the projection matrix used in the
> backprojection process, in order to check if it is the same as in my own
> implementation.
>
> To do so, I print out one of the intermediate matrix that is generated in
> rtkCudaBackProjectionImageFilter while launching a SART reconstruction for
> instance.
>
> I was surpised by the fact that, the matrix allowing the transformation
> from 2D geometric world to 2D image index world, namely matrixIdxProj in
> rtkCudaBackProjectionImageFilte.cxx
> <http://www.openrtk.org/Doxygen/rtkCudaBackProjectionImageFilter_8cxx_source.html>
> is not always the same along the reconstruction process ?
>
> Here is the line that generates the matrix I don't understand:
>
> for(unsigned int i=0; i<2; i++)
>  //SR: 0.5 for 2D texture
>   matrixIdxProj[i][2] =
> -1*(this->GetInput(1)->GetBufferedRegion().GetIndex()[i])+0.5;
>
> What I understand here, is that, we are generating a 2D translation matrix
> embedded in a 3*3 matrix that allows to take into account two things
> related to the 2D projection:
>
> -If the internal behaviour of the imageContainer, allows buffering of only
> a part of the image, beginning at index (i,j), this information will be
> embeded in the projection matrix
>
> -the ITK floating point addressing definition seems to differ from the one
> from cuda (and openCV):
> When I take a look at this page
> <http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#texture-fetching>
> I understand that the floating point indexing (0.5,0.5) in Cuda points to
> the center of the pixel (0,0) hence a linear contribution of 100%, while it
> seems that we must add a translation of (0.5,0.5) to the ITK geometric
> framework in order to get the same behaviour.
>
> In practice matrixIdxProj is based on a 3*3 identity matrix, where the
> inner 2D translation (ie 2 first term of the last column) in my case are:
> -in X, a random number between 10 and 150 plus 0.5
> -in Y: always 0.5
>
> I understand the 0.5 part, but why is there always a 0 offset in Y but a
> random offset in X remains a mystery to me.
>
> At first, I believed that each projection was splitted into multiple part,
> each having a different X and Y offset.
> But reconstructing using only one projection generates only one
> backprojection operation, with a non zero offset in X, 123 in my case, for
> an image of size 780 in X.
>
> Do you think there is something wrong whith the values of matrixIdxProjI
> am experiencing ?
>
> Thank you in advance.
>
> Kind regards
>
> Thibault Notargiacomo
>
> _______________________________________________
> 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/20151110/8b9b86e6/attachment-0003.html>

From simon.rit at creatis.insa-lyon.fr  Tue Nov 10 09:03:52 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Tue, 10 Nov 2015 15:03:52 +0100
Subject: [Rtk-users] Understanding projection matrices management in
	rtkCudaBackProjectionImageFilter
In-Reply-To: <CAP+mR7ZLJV8V5dMOW_jgM5G2-kCZhy8o0tB19685LGo-1bxLUg@mail.gmail.com>
References: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>
 <CAF0oig3muuH+1=eLZ66DJ22QcnsSrUKzRFS4RzDRvDJXNxAVXg@mail.gmail.com>
 <CAP+mR7ZLJV8V5dMOW_jgM5G2-kCZhy8o0tB19685LGo-1bxLUg@mail.gmail.com>
Message-ID: <CAF0oig3fALRnZNCJ53+TsSjBm7raRC_mqahWEU6x+D+zxwOnVQ@mail.gmail.com>

A small correction: it's actually the amount of data pre-processed (read
from disk + all the processing before backprojection) but that should
change nothing to what is backprojected.
I remembered something that can help you: you may want to run
UpdateLargestPossibleRegion() to the projections (input 1 of the
BackProjectImageFilter) before backprojection to avoid this and make things
clearer instead of using a large volume as I was suggesting before.
Simon

On Tue, Nov 10, 2015 at 2:34 PM, Notargiacomo Thibault <gnthibault at gmail.com
> wrote:

> Ok, using geometric information to reduce the amount of data to be
> backprojected is pretty clever ;)
> This explains the "random" index I was asking about in my previous
> question, I now know what it is used for and continue my debugging process.
>
> Kind regards
>
> Thibault Notargiacomo
>
> 2015-11-10 14:21 GMT+01:00 Simon Rit <simon.rit at creatis.insa-lyon.fr>:
>
>> Hi Thibault,
>> You started digging in the code so that gets complicated. First thing
>> first, yes, the link you provide is still valid.
>> The offset in X is not random but computed in
>> BackProjectionImageFilter::GenerateInputRequestedRegion
>> <https://github.com/SimonRit/RTK/blob/master/code/rtkBackProjectionImageFilter.txx>.
>> The idea is that we request only the part of the projections we need to do
>> the backprojection. This optimizes the streaming (we only read from disk
>> what we need). If you use a huge volume (the test I'd suggest to validate
>> that I'm correct and there is nothing wrong with your code), then you'll
>> need the full projection and you will always get 0 in X as in Y. If you use
>> a small volume and do a computation projection per projection, you will get
>> a varying index depending on your input volume and the geometry for that
>> projection.
>> I think you understood the rest pretty well. Does that make sense or am I
>> missing something else?
>> Simon
>>
>> On Tue, Nov 10, 2015 at 1:39 PM, Notargiacomo Thibault <
>> gnthibault at gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> I am currently trying to use the "AddProjectionInRadians" method from
>>> the ThreeDCircularProjectionGeometry class in RTK to import my geometry.
>>>
>>> First things first, I would like to know if the information on this pdf
>>> are still valid: http://www.openrtk.org/Doxygen/geometry.pdf
>>>
>>> Because I used them to deduce the source offset and Projection offset
>>> from my own matrix decomposition.
>>>
>>> Notice that I don't want to use geometric informations coming from the
>>> projection images themselves, so their geometric origin is assumed to be
>>> (0,0,0) in my case.
>>>
>>> In order to check if my geometry import method is correct, I print out
>>> one of the intermediate form of the projection matrix used in the
>>> backprojection process, in order to check if it is the same as in my own
>>> implementation.
>>>
>>> To do so, I print out one of the intermediate matrix that is generated
>>> in rtkCudaBackProjectionImageFilter while launching a SART reconstruction
>>> for instance.
>>>
>>> I was surpised by the fact that, the matrix allowing the transformation
>>> from 2D geometric world to 2D image index world, namely matrixIdxProj in
>>> rtkCudaBackProjectionImageFilte.cxx
>>> <http://www.openrtk.org/Doxygen/rtkCudaBackProjectionImageFilter_8cxx_source.html>
>>> is not always the same along the reconstruction process ?
>>>
>>> Here is the line that generates the matrix I don't understand:
>>>
>>> for(unsigned int i=0; i<2; i++)
>>>  //SR: 0.5 for 2D texture
>>>   matrixIdxProj[i][2] =
>>> -1*(this->GetInput(1)->GetBufferedRegion().GetIndex()[i])+0.5;
>>>
>>> What I understand here, is that, we are generating a 2D translation
>>> matrix embedded in a 3*3 matrix that allows to take into account two things
>>> related to the 2D projection:
>>>
>>> -If the internal behaviour of the imageContainer, allows buffering of
>>> only a part of the image, beginning at index (i,j), this information will
>>> be embeded in the projection matrix
>>>
>>> -the ITK floating point addressing definition seems to differ from the
>>> one from cuda (and openCV):
>>> When I take a look at this page
>>> <http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#texture-fetching>
>>> I understand that the floating point indexing (0.5,0.5) in Cuda points to
>>> the center of the pixel (0,0) hence a linear contribution of 100%, while it
>>> seems that we must add a translation of (0.5,0.5) to the ITK geometric
>>> framework in order to get the same behaviour.
>>>
>>> In practice matrixIdxProj is based on a 3*3 identity matrix, where the
>>> inner 2D translation (ie 2 first term of the last column) in my case are:
>>> -in X, a random number between 10 and 150 plus 0.5
>>> -in Y: always 0.5
>>>
>>> I understand the 0.5 part, but why is there always a 0 offset in Y but a
>>> random offset in X remains a mystery to me.
>>>
>>> At first, I believed that each projection was splitted into multiple
>>> part, each having a different X and Y offset.
>>> But reconstructing using only one projection generates only one
>>> backprojection operation, with a non zero offset in X, 123 in my case, for
>>> an image of size 780 in X.
>>>
>>> Do you think there is something wrong whith the values of matrixIdxProjI
>>> am experiencing ?
>>>
>>> Thank you in advance.
>>>
>>> Kind regards
>>>
>>> Thibault Notargiacomo
>>>
>>> _______________________________________________
>>> 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/20151110/d8913dc3/attachment-0003.html>

From simon.rit at creatis.insa-lyon.fr  Tue Nov 10 11:21:29 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Tue, 10 Nov 2015 17:21:29 +0100
Subject: [Rtk-users] Understanding projection matrices management in
	rtkCudaBackProjectionImageFilter
In-Reply-To: <CAP+mR7ZKqnbUyRHyHkti=3sZd2dEw-OUV6oqsqcga55=tcQ9OQ@mail.gmail.com>
References: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>
 <CAF0oig3muuH+1=eLZ66DJ22QcnsSrUKzRFS4RzDRvDJXNxAVXg@mail.gmail.com>
 <CAP+mR7ZLJV8V5dMOW_jgM5G2-kCZhy8o0tB19685LGo-1bxLUg@mail.gmail.com>
 <CAF0oig3fALRnZNCJ53+TsSjBm7raRC_mqahWEU6x+D+zxwOnVQ@mail.gmail.com>
 <CAP+mR7ZKqnbUyRHyHkti=3sZd2dEw-OUV6oqsqcga55=tcQ9OQ@mail.gmail.com>
Message-ID: <CAF0oig12pRGBfgiCQMCwTG7zX_3vz87AEWhTQ4EYaVbH_m0t5Q@mail.gmail.com>

Your welcome (I cc the mailing list for info).
Simon

On Tue, Nov 10, 2015 at 5:03 PM, Notargiacomo Thibault <gnthibault at gmail.com
> wrote:

> I replaced the original Update by the "UpdateLargestPossibleRegion" to the
> divideFilter in SART (I bypassed displacedDetectorFilter for now) and it
> work as expected, I have now a "clean" matProjIdx.
>
> Thank you for your help !
>
> 2015-11-10 15:03 GMT+01:00 Simon Rit <simon.rit at creatis.insa-lyon.fr>:
>
>> A small correction: it's actually the amount of data pre-processed (read
>> from disk + all the processing before backprojection) but that should
>> change nothing to what is backprojected.
>> I remembered something that can help you: you may want to run
>> UpdateLargestPossibleRegion() to the projections (input 1 of the
>> BackProjectImageFilter) before backprojection to avoid this and make things
>> clearer instead of using a large volume as I was suggesting before.
>> Simon
>>
>> On Tue, Nov 10, 2015 at 2:34 PM, Notargiacomo Thibault <
>> gnthibault at gmail.com> wrote:
>>
>>> Ok, using geometric information to reduce the amount of data to be
>>> backprojected is pretty clever ;)
>>> This explains the "random" index I was asking about in my previous
>>> question, I now know what it is used for and continue my debugging process.
>>>
>>> Kind regards
>>>
>>> Thibault Notargiacomo
>>>
>>> 2015-11-10 14:21 GMT+01:00 Simon Rit <simon.rit at creatis.insa-lyon.fr>:
>>>
>>>> Hi Thibault,
>>>> You started digging in the code so that gets complicated. First thing
>>>> first, yes, the link you provide is still valid.
>>>> The offset in X is not random but computed in
>>>> BackProjectionImageFilter::GenerateInputRequestedRegion
>>>> <https://github.com/SimonRit/RTK/blob/master/code/rtkBackProjectionImageFilter.txx>.
>>>> The idea is that we request only the part of the projections we need to do
>>>> the backprojection. This optimizes the streaming (we only read from disk
>>>> what we need). If you use a huge volume (the test I'd suggest to validate
>>>> that I'm correct and there is nothing wrong with your code), then you'll
>>>> need the full projection and you will always get 0 in X as in Y. If you use
>>>> a small volume and do a computation projection per projection, you will get
>>>> a varying index depending on your input volume and the geometry for that
>>>> projection.
>>>> I think you understood the rest pretty well. Does that make sense or am
>>>> I missing something else?
>>>> Simon
>>>>
>>>> On Tue, Nov 10, 2015 at 1:39 PM, Notargiacomo Thibault <
>>>> gnthibault at gmail.com> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I am currently trying to use the "AddProjectionInRadians" method from
>>>>> the ThreeDCircularProjectionGeometry class in RTK to import my geometry.
>>>>>
>>>>> First things first, I would like to know if the information on this
>>>>> pdf are still valid: http://www.openrtk.org/Doxygen/geometry.pdf
>>>>>
>>>>> Because I used them to deduce the source offset and Projection offset
>>>>> from my own matrix decomposition.
>>>>>
>>>>> Notice that I don't want to use geometric informations coming from the
>>>>> projection images themselves, so their geometric origin is assumed to be
>>>>> (0,0,0) in my case.
>>>>>
>>>>> In order to check if my geometry import method is correct, I print out
>>>>> one of the intermediate form of the projection matrix used in the
>>>>> backprojection process, in order to check if it is the same as in my own
>>>>> implementation.
>>>>>
>>>>> To do so, I print out one of the intermediate matrix that is generated
>>>>> in rtkCudaBackProjectionImageFilter while launching a SART reconstruction
>>>>> for instance.
>>>>>
>>>>> I was surpised by the fact that, the matrix allowing the
>>>>> transformation from 2D geometric world to 2D image index world, namely
>>>>> matrixIdxProj in rtkCudaBackProjectionImageFilte.cxx
>>>>> <http://www.openrtk.org/Doxygen/rtkCudaBackProjectionImageFilter_8cxx_source.html>
>>>>> is not always the same along the reconstruction process ?
>>>>>
>>>>> Here is the line that generates the matrix I don't understand:
>>>>>
>>>>> for(unsigned int i=0; i<2; i++)
>>>>>  //SR: 0.5 for 2D texture
>>>>>   matrixIdxProj[i][2] =
>>>>> -1*(this->GetInput(1)->GetBufferedRegion().GetIndex()[i])+0.5;
>>>>>
>>>>> What I understand here, is that, we are generating a 2D translation
>>>>> matrix embedded in a 3*3 matrix that allows to take into account two things
>>>>> related to the 2D projection:
>>>>>
>>>>> -If the internal behaviour of the imageContainer, allows buffering of
>>>>> only a part of the image, beginning at index (i,j), this information will
>>>>> be embeded in the projection matrix
>>>>>
>>>>> -the ITK floating point addressing definition seems to differ from the
>>>>> one from cuda (and openCV):
>>>>> When I take a look at this page
>>>>> <http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#texture-fetching>
>>>>> I understand that the floating point indexing (0.5,0.5) in Cuda points to
>>>>> the center of the pixel (0,0) hence a linear contribution of 100%, while it
>>>>> seems that we must add a translation of (0.5,0.5) to the ITK geometric
>>>>> framework in order to get the same behaviour.
>>>>>
>>>>> In practice matrixIdxProj is based on a 3*3 identity matrix, where
>>>>> the inner 2D translation (ie 2 first term of the last column) in my case
>>>>> are:
>>>>> -in X, a random number between 10 and 150 plus 0.5
>>>>> -in Y: always 0.5
>>>>>
>>>>> I understand the 0.5 part, but why is there always a 0 offset in Y but
>>>>> a random offset in X remains a mystery to me.
>>>>>
>>>>> At first, I believed that each projection was splitted into multiple
>>>>> part, each having a different X and Y offset.
>>>>> But reconstructing using only one projection generates only one
>>>>> backprojection operation, with a non zero offset in X, 123 in my case, for
>>>>> an image of size 780 in X.
>>>>>
>>>>> Do you think there is something wrong whith the values of matrixIdxProjI
>>>>> am experiencing ?
>>>>>
>>>>> Thank you in advance.
>>>>>
>>>>> Kind regards
>>>>>
>>>>> Thibault Notargiacomo
>>>>>
>>>>> _______________________________________________
>>>>> 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/20151110/b7eba683/attachment-0003.html>

From theday79 at gmail.com  Wed Nov 11 13:50:45 2015
From: theday79 at gmail.com (Yang K Park)
Date: Wed, 11 Nov 2015 13:50:45 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after  a recent update
Message-ID: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>

Hi all,

 

I?ve updated rtk with the up-to-date revision and have encountered a couple of problems.

 

1.       Compile error: RTK couldn?t find itkMacro.h while it compiled rtkCudaUtilities.hcu. It was solved by a minor fetching:

#include <itkMacro.h>   --> #include "itkMacro.h" in rtkCudaUtilities.hcu

 

2.       Output of rtkfdk with CUDA was not the same as before. It was very blurry as seen in the attached image.

a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.

 

 

I?m using VS2013 with win7, itk4.8.1.

 

The command line I used was :

rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware cuda --pad 1 --hann 5 --hannY 5

 

Does anyone have any idea about this?

 

Thanks.

 

Yang

 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151111/b1c7df5f/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 16577 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151111/b1c7df5f/attachment-0003.png>

From simon.rit at creatis.insa-lyon.fr  Wed Nov 11 16:15:49 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Wed, 11 Nov 2015 22:15:49 +0100
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
Message-ID: <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>

Hi,
I didn't manage to reproduce the two problems on linux with the same
ITK version.
For point 1, did you copy itkMacro.h by hand? Because I don't see how
replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not
in the same folder as rtkCudaUtilities.hcu
For point 2, no clue. Do you use FFTW? It looks like a ramp filter
issue. Can you try rtkramp --path projPath --regexp .*.his, with and
without --hardware cuda? Maybe you can provide your geometry file in
case it's a specific geometric issue.
Simon

On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
> Hi all,
>
>
>
> I?ve updated rtk with the up-to-date revision and have encountered a couple
> of problems.
>
>
>
> 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
> rtkCudaUtilities.hcu. It was solved by a minor fetching:
>
> #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>
>
>
> 2.       Output of rtkfdk with CUDA was not the same as before. It was very
> blurry as seen in the attached image.
>
> a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>
>
>
>
>
> I?m using VS2013 with win7, itk4.8.1.
>
>
>
> The command line I used was :
>
> rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his --output
> output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware cuda --pad 1
> --hann 5 --hannY 5
>
>
>
> Does anyone have any idea about this?
>
>
>
> Thanks.
>
>
>
> Yang
>
>
>
>
> _______________________________________________
> Rtk-users mailing list
> Rtk-users at public.kitware.com
> http://public.kitware.com/mailman/listinfo/rtk-users
>


From theday79 at gmail.com  Thu Nov 12 17:39:38 2015
From: theday79 at gmail.com (Yang K Park)
Date: Thu, 12 Nov 2015 17:39:38 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
Message-ID: <000001d11d9b$04142320$0c3c6960$@gmail.com>

Hi Simon,

 

Thanks for the advice. The current RTK was compiled with FFTW to use the phase extraction feature from Amsterdam shroud.

 

Regarding your suggestions,

 

1)      rtkramp w/ or w/o CUDA:

(command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda --output Ramp_wCUDA.mha? )

 

Then, I have encountered following error.

?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that input requested and buffered regions are equal.?

 



 

Without CUDA, it was successfully done.

 

2)      I?ve re-compiled ITK w/o FFTW and built RTK again. rtkfdk worked fine.

-          I?ve also repeated ?rtkramp+CUDA? with this rtk version and the error was same as above.

 

In conclusion, my FFTW seems to affect CUDA-based fdk reconstruction only.

But I do need FFTW for the phase extraction. What should I do?

 

Thanks.

 

Yang

 

 

-----Original Message-----
From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit
Sent: Wednesday, November 11, 2015 4:16 PM
To: Yang K Park <theday79 at gmail.com>
Cc: rtk-users at openrtk.org
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

I didn't manage to reproduce the two problems on linux with the same ITK version.

For point 1, did you copy itkMacro.h by hand? Because I don't see how replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW? It looks like a ramp filter issue. Can you try rtkramp --path projPath --regexp .*.his, with and without --hardware cuda? Maybe you can provide your geometry file in case it's a specific geometric issue.

Simon

 

On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park < <mailto:theday79 at gmail.com> theday79 at gmail.com> wrote:

> Hi all,

> 

> 

> 

> I?ve updated rtk with the up-to-date revision and have encountered a 

> couple of problems.

> 

> 

> 

> 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled

> rtkCudaUtilities.hcu. It was solved by a minor fetching:

> 

> #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu

> 

> 

> 

> 2.       Output of rtkfdk with CUDA was not the same as before. It was very

> blurry as seen in the attached image.

> 

> a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.

> 

> 

> 

> 

> 

> I?m using VS2013 with win7, itk4.8.1.

> 

> 

> 

> The command line I used was :

> 

> rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his 

> --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware 

> cuda --pad 1 --hann 5 --hannY 5

> 

> 

> 

> Does anyone have any idea about this?

> 

> 

> 

> Thanks.

> 

> 

> 

> Yang

> 

> 

> 

> 

> _______________________________________________

> Rtk-users mailing list

>  <mailto: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/20151112/4e0825dc/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151112/4e0825dc/attachment-0003.png>

From simon.rit at creatis.insa-lyon.fr  Thu Nov 12 17:58:42 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Thu, 12 Nov 2015 23:58:42 +0100
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <000001d11d9b$04142320$0c3c6960$@gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
Message-ID: <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>

Hi,
Ok. Can you try rtkramp with only one projection? Then you shouldn't
encounter this regions issue (that should be solved one day but that's a
different story).
Can you also indicate which version of CUDA you're using?
FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft for
the FFT of the projections. So if they are not in the same format, you're
in trouble and that might be the issue here... The weird part is that I
didn't reproduce this problem on linux (with and without FFTW) but it might
be a CUDA version difference. I'll give it another try tomorrow when you
provide the CUDA version.
Thanks again for reporting the issue,
Simon

On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com> wrote:

> Hi Simon,
>
>
>
> Thanks for the advice. The current RTK was compiled with FFTW to use the
> phase extraction feature from Amsterdam shroud.
>
>
>
> Regarding your suggestions,
>
>
>
> 1)      rtkramp w/ or w/o CUDA:
>
> (command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda
> --output Ramp_wCUDA.mha? )
>
>
>
> Then, I have encountered following error.
>
> ?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that
> input requested and buffered regions are equal.?
>
>
>
>
>
> Without CUDA, it was successfully done.
>
>
>
> 2)      I?ve re-compiled *ITK w/o FFTW* and built RTK again. r*tkfdk
> worked fine.*
>
> -          I?ve also repeated ?rtkramp+CUDA? with this rtk version and
> the error was same as above.
>
>
>
> In conclusion, my *FFTW seems to affect CUDA-based fdk reconstruction
> only*.
>
> But I do need FFTW for the phase extraction. What should I do?
>
>
>
> Thanks.
>
>
>
> Yang
>
>
>
>
>
> -----Original Message-----
> From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon
> Rit
> Sent: Wednesday, November 11, 2015 4:16 PM
> To: Yang K Park <theday79 at gmail.com>
> Cc: rtk-users at openrtk.org
> Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
> update
>
>
>
> Hi,
>
> I didn't manage to reproduce the two problems on linux with the same ITK
> version.
>
> For point 1, did you copy itkMacro.h by hand? Because I don't see how
> replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the
> same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW?
> It looks like a ramp filter issue. Can you try rtkramp --path projPath
> --regexp .*.his, with and without --hardware cuda? Maybe you can provide
> your geometry file in case it's a specific geometric issue.
>
> Simon
>
>
>
> On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
>
> > Hi all,
>
> >
>
> >
>
> >
>
> > I?ve updated rtk with the up-to-date revision and have encountered a
>
> > couple of problems.
>
> >
>
> >
>
> >
>
> > 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
>
> > rtkCudaUtilities.hcu. It was solved by a minor fetching:
>
> >
>
> > #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>
> >
>
> >
>
> >
>
> > 2.       Output of rtkfdk with CUDA was not the same as before. It was
> very
>
> > blurry as seen in the attached image.
>
> >
>
> > a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > I?m using VS2013 with win7, itk4.8.1.
>
> >
>
> >
>
> >
>
> > The command line I used was :
>
> >
>
> > rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his
>
> > --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware
>
> > cuda --pad 1 --hann 5 --hannY 5
>
> >
>
> >
>
> >
>
> > Does anyone have any idea about this?
>
> >
>
> >
>
> >
>
> > Thanks.
>
> >
>
> >
>
> >
>
> > Yang
>
> >
>
> >
>
> >
>
> >
>
> > _______________________________________________
>
> > 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/20151112/e7c15ff8/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151112/e7c15ff8/attachment-0003.png>

From theday79 at gmail.com  Mon Nov 16 09:54:01 2015
From: theday79 at gmail.com (Yang K Park)
Date: Mon, 16 Nov 2015 09:54:01 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
Message-ID: <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>

Hi Simon,

 

Sorry for the late response.

 

As you suggested, I?ve tried rtkramp+CUDA with only one projection and it was successfully done for both w/ FFTW and w/o FFTW.

(Two results were exactly same.)

 

Regarding  the CUDA version, I?m using v6.5.

 

Thanks a lot for the help!

 

Yang

 

 

From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit
Sent: Thursday, November 12, 2015 5:59 PM
To: Yang K Park <theday79 at gmail.com>
Cc: rtk-users at openrtk.org
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

Ok. Can you try rtkramp with only one projection? Then you shouldn't encounter this regions issue (that should be solved one day but that's a different story). 

Can you also indicate which version of CUDA you're using?

FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft for the FFT of the projections. So if they are not in the same format, you're in trouble and that might be the issue here... The weird part is that I didn't reproduce this problem on linux (with and without FFTW) but it might be a CUDA version difference. I'll give it another try tomorrow when you provide the CUDA version.

Thanks again for reporting the issue,
Simon

 

On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> > wrote:

Hi Simon,

 

Thanks for the advice. The current RTK was compiled with FFTW to use the phase extraction feature from Amsterdam shroud.

 

Regarding your suggestions,

 

1)      rtkramp w/ or w/o CUDA:

(command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda --output Ramp_wCUDA.mha? )

 

Then, I have encountered following error.

?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that input requested and buffered regions are equal.?

 



 

Without CUDA, it was successfully done.

 

2)      I?ve re-compiled ITK w/o FFTW and built RTK again. rtkfdk worked fine.

-          I?ve also repeated ?rtkramp+CUDA? with this rtk version and the error was same as above.

 

In conclusion, my FFTW seems to affect CUDA-based fdk reconstruction only.

But I do need FFTW for the phase extraction. What should I do?

 

Thanks.

 

Yang

 

 

-----Original Message-----
From: simon.rit at gmail.com <mailto:simon.rit at gmail.com>  [mailto:simon.rit at gmail.com <mailto:simon.rit at gmail.com> ] On Behalf Of Simon Rit
Sent: Wednesday, November 11, 2015 4:16 PM
To: Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> >
Cc: rtk-users at openrtk.org <mailto:rtk-users at openrtk.org> 
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

I didn't manage to reproduce the two problems on linux with the same ITK version.

For point 1, did you copy itkMacro.h by hand? Because I don't see how replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW? It looks like a ramp filter issue. Can you try rtkramp --path projPath --regexp .*.his, with and without --hardware cuda? Maybe you can provide your geometry file in case it's a specific geometric issue.

Simon

 

On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park < <mailto:theday79 at gmail.com> theday79 at gmail.com> wrote:

> Hi all,

> 

> 

> 

> I?ve updated rtk with the up-to-date revision and have encountered a 

> couple of problems.

> 

> 

> 

> 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled

> rtkCudaUtilities.hcu. It was solved by a minor fetching:

> 

> #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu

> 

> 

> 

> 2.       Output of rtkfdk with CUDA was not the same as before. It was very

> blurry as seen in the attached image.

> 

> a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.

> 

> 

> 

> 

> 

> I?m using VS2013 with win7, itk4.8.1.

> 

> 

> 

> The command line I used was :

> 

> rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his 

> --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware 

> cuda --pad 1 --hann 5 --hannY 5

> 

> 

> 

> Does anyone have any idea about this?

> 

> 

> 

> Thanks.

> 

> 

> 

> Yang

> 

> 

> 

> 

> _______________________________________________

> Rtk-users mailing list

>  <mailto: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/20151116/e77c2f96/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151116/e77c2f96/attachment-0003.png>

From simon.rit at creatis.insa-lyon.fr  Mon Nov 16 10:07:46 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Mon, 16 Nov 2015 16:07:46 +0100
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
 <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
Message-ID: <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>

Hi,
Thanks. It's really weird... When you run the tests with FFTW (compiling
the "test" target), do they fail?
Can you provide your geometry file? It might be specific to this geometry.
Thanks again for looking into this issue, we'll find what's the problem.
Simon

On Mon, Nov 16, 2015 at 3:54 PM, Yang K Park <theday79 at gmail.com> wrote:

> Hi Simon,
>
>
>
> Sorry for the late response.
>
>
>
> As you suggested, I?ve tried rtkramp+CUDA with only one projection and it
> was successfully done for both w/ FFTW and w/o FFTW.
>
> (Two results were exactly same.)
>
>
>
> Regarding  the CUDA version, I?m using v6.5.
>
>
>
> Thanks a lot for the help!
>
>
>
> Yang
>
>
>
>
>
> *From:* simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of *Simon
> Rit
> *Sent:* Thursday, November 12, 2015 5:59 PM
>
> *To:* Yang K Park <theday79 at gmail.com>
> *Cc:* rtk-users at openrtk.org
> *Subject:* Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
> update
>
>
>
> Hi,
>
> Ok. Can you try rtkramp with only one projection? Then you shouldn't
> encounter this regions issue (that should be solved one day but that's a
> different story).
>
> Can you also indicate which version of CUDA you're using?
>
> FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft for
> the FFT of the projections. So if they are not in the same format, you're
> in trouble and that might be the issue here... The weird part is that I
> didn't reproduce this problem on linux (with and without FFTW) but it might
> be a CUDA version difference. I'll give it another try tomorrow when you
> provide the CUDA version.
>
> Thanks again for reporting the issue,
> Simon
>
>
>
> On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com> wrote:
>
> Hi Simon,
>
>
>
> Thanks for the advice. The current RTK was compiled with FFTW to use the
> phase extraction feature from Amsterdam shroud.
>
>
>
> Regarding your suggestions,
>
>
>
> 1)      rtkramp w/ or w/o CUDA:
>
> (command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda
> --output Ramp_wCUDA.mha? )
>
>
>
> Then, I have encountered following error.
>
> ?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that
> input requested and buffered regions are equal.?
>
>
>
>
>
> Without CUDA, it was successfully done.
>
>
>
> 2)      I?ve re-compiled *ITK w/o FFTW* and built RTK again. r*tkfdk
> worked fine.*
>
> -          I?ve also repeated ?rtkramp+CUDA? with this rtk version and
> the error was same as above.
>
>
>
> In conclusion, my *FFTW seems to affect CUDA-based fdk reconstruction
> only*.
>
> But I do need FFTW for the phase extraction. What should I do?
>
>
>
> Thanks.
>
>
>
> Yang
>
>
>
>
>
> -----Original Message-----
> From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon
> Rit
> Sent: Wednesday, November 11, 2015 4:16 PM
> To: Yang K Park <theday79 at gmail.com>
> Cc: rtk-users at openrtk.org
> Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
> update
>
>
>
> Hi,
>
> I didn't manage to reproduce the two problems on linux with the same ITK
> version.
>
> For point 1, did you copy itkMacro.h by hand? Because I don't see how
> replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the
> same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW?
> It looks like a ramp filter issue. Can you try rtkramp --path projPath
> --regexp .*.his, with and without --hardware cuda? Maybe you can provide
> your geometry file in case it's a specific geometric issue.
>
> Simon
>
>
>
> On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
>
> > Hi all,
>
> >
>
> >
>
> >
>
> > I?ve updated rtk with the up-to-date revision and have encountered a
>
> > couple of problems.
>
> >
>
> >
>
> >
>
> > 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
>
> > rtkCudaUtilities.hcu. It was solved by a minor fetching:
>
> >
>
> > #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>
> >
>
> >
>
> >
>
> > 2.       Output of rtkfdk with CUDA was not the same as before. It was
> very
>
> > blurry as seen in the attached image.
>
> >
>
> > a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > I?m using VS2013 with win7, itk4.8.1.
>
> >
>
> >
>
> >
>
> > The command line I used was :
>
> >
>
> > rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his
>
> > --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware
>
> > cuda --pad 1 --hann 5 --hannY 5
>
> >
>
> >
>
> >
>
> > Does anyone have any idea about this?
>
> >
>
> >
>
> >
>
> > Thanks.
>
> >
>
> >
>
> >
>
> > Yang
>
> >
>
> >
>
> >
>
> >
>
> > _______________________________________________
>
> > 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/20151116/38acfca5/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151116/38acfca5/attachment-0003.png>

From theday79 at gmail.com  Mon Nov 16 10:47:43 2015
From: theday79 at gmail.com (Yang-Kyun Park)
Date: Mon, 16 Nov 2015 10:47:43 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
 <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
 <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>
Message-ID: <CAJM7=xjBjx=FzLazWJWqJbV5d45zGi2U71NKejm9HxKhJ0-xLQ@mail.gmail.com>

Hi Simon,

For better understanding, I'm attaching the problematic case including
projection files, geometry file(xml) and reconstructed images.(please find
the GDrive links. The file size is ~800 MB)
This is phantom data and there is no patient information in it.

Regarding the fftw library, I'm using [fftw-3.3.4-dll64].

By the way, I found another clue. When I've tried it with a head phantom
image (full-fan, ~ 190 projections), there was no problem. Is there any
possibility that DDF and parker short filter play some roles on this issue?

Feel free to let me know if further data is needed.

Thanks!

Yang

?
 FFTW_issue.zip
<https://drive.google.com/file/d/0BxuP3mON9V-qbVdQd0luc1lIb2M/view?usp=drive_web>
?

On Mon, Nov 16, 2015 at 10:07 AM, Simon Rit <simon.rit at creatis.insa-lyon.fr>
wrote:

> Hi,
> Thanks. It's really weird... When you run the tests with FFTW (compiling
> the "test" target), do they fail?
> Can you provide your geometry file? It might be specific to this geometry.
> Thanks again for looking into this issue, we'll find what's the problem.
> Simon
>
> On Mon, Nov 16, 2015 at 3:54 PM, Yang K Park <theday79 at gmail.com> wrote:
>
>> Hi Simon,
>>
>>
>>
>> Sorry for the late response.
>>
>>
>>
>> As you suggested, I?ve tried rtkramp+CUDA with only one projection and it
>> was successfully done for both w/ FFTW and w/o FFTW.
>>
>> (Two results were exactly same.)
>>
>>
>>
>> Regarding  the CUDA version, I?m using v6.5.
>>
>>
>>
>> Thanks a lot for the help!
>>
>>
>>
>> Yang
>>
>>
>>
>>
>>
>> *From:* simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of *Simon
>> Rit
>> *Sent:* Thursday, November 12, 2015 5:59 PM
>>
>> *To:* Yang K Park <theday79 at gmail.com>
>> *Cc:* rtk-users at openrtk.org
>> *Subject:* Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
>> update
>>
>>
>>
>> Hi,
>>
>> Ok. Can you try rtkramp with only one projection? Then you shouldn't
>> encounter this regions issue (that should be solved one day but that's a
>> different story).
>>
>> Can you also indicate which version of CUDA you're using?
>>
>> FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft
>> for the FFT of the projections. So if they are not in the same format,
>> you're in trouble and that might be the issue here... The weird part is
>> that I didn't reproduce this problem on linux (with and without FFTW) but
>> it might be a CUDA version difference. I'll give it another try tomorrow
>> when you provide the CUDA version.
>>
>> Thanks again for reporting the issue,
>> Simon
>>
>>
>>
>> On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com> wrote:
>>
>> Hi Simon,
>>
>>
>>
>> Thanks for the advice. The current RTK was compiled with FFTW to use the
>> phase extraction feature from Amsterdam shroud.
>>
>>
>>
>> Regarding your suggestions,
>>
>>
>>
>> 1)      rtkramp w/ or w/o CUDA:
>>
>> (command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda
>> --output Ramp_wCUDA.mha? )
>>
>>
>>
>> Then, I have encountered following error.
>>
>> ?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that
>> input requested and buffered regions are equal.?
>>
>>
>>
>>
>>
>> Without CUDA, it was successfully done.
>>
>>
>>
>> 2)      I?ve re-compiled *ITK w/o FFTW* and built RTK again. r*tkfdk
>> worked fine.*
>>
>> -          I?ve also repeated ?rtkramp+CUDA? with this rtk version and
>> the error was same as above.
>>
>>
>>
>> In conclusion, my *FFTW seems to affect CUDA-based fdk reconstruction
>> only*.
>>
>> But I do need FFTW for the phase extraction. What should I do?
>>
>>
>>
>> Thanks.
>>
>>
>>
>> Yang
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of
>> Simon Rit
>> Sent: Wednesday, November 11, 2015 4:16 PM
>> To: Yang K Park <theday79 at gmail.com>
>> Cc: rtk-users at openrtk.org
>> Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
>> update
>>
>>
>>
>> Hi,
>>
>> I didn't manage to reproduce the two problems on linux with the same ITK
>> version.
>>
>> For point 1, did you copy itkMacro.h by hand? Because I don't see how
>> replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the
>> same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW?
>> It looks like a ramp filter issue. Can you try rtkramp --path projPath
>> --regexp .*.his, with and without --hardware cuda? Maybe you can provide
>> your geometry file in case it's a specific geometric issue.
>>
>> Simon
>>
>>
>>
>> On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
>>
>> > Hi all,
>>
>> >
>>
>> >
>>
>> >
>>
>> > I?ve updated rtk with the up-to-date revision and have encountered a
>>
>> > couple of problems.
>>
>> >
>>
>> >
>>
>> >
>>
>> > 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
>>
>> > rtkCudaUtilities.hcu. It was solved by a minor fetching:
>>
>> >
>>
>> > #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>>
>> >
>>
>> >
>>
>> >
>>
>> > 2.       Output of rtkfdk with CUDA was not the same as before. It was
>> very
>>
>> > blurry as seen in the attached image.
>>
>> >
>>
>> > a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>
>> > I?m using VS2013 with win7, itk4.8.1.
>>
>> >
>>
>> >
>>
>> >
>>
>> > The command line I used was :
>>
>> >
>>
>> > rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his
>>
>> > --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware
>>
>> > cuda --pad 1 --hann 5 --hannY 5
>>
>> >
>>
>> >
>>
>> >
>>
>> > Does anyone have any idea about this?
>>
>> >
>>
>> >
>>
>> >
>>
>> > Thanks.
>>
>> >
>>
>> >
>>
>> >
>>
>> > Yang
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>
>> > _______________________________________________
>>
>> > 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/20151116/90d2c5a0/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151116/90d2c5a0/attachment-0003.png>

From simon.rit at creatis.insa-lyon.fr  Fri Nov 20 11:28:22 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Fri, 20 Nov 2015 17:28:22 +0100
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAJM7=xjBjx=FzLazWJWqJbV5d45zGi2U71NKejm9HxKhJ0-xLQ@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
 <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
 <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>
 <CAJM7=xjBjx=FzLazWJWqJbV5d45zGi2U71NKejm9HxKhJ0-xLQ@mail.gmail.com>
Message-ID: <CAF0oig027_u_9gb8bnwT1w9jr3epZ0hkd9Mt73qK5heUq_kCkg@mail.gmail.com>

Hi Yang,
Thanks a lot for sharing the data. I have good news. I could reproduce the
bug and I have solutions. First, about your dataset: it's a huge dataset
and the hannY requires zero padding in both x and y. Because of this, cufft
has to take the 2D FFT of projection subsets that are 4095x2048x16. Quite
big!
When I ran it on my cuda 7.0, I immediately got:

itk::ExceptionObject (0x8b9cb30)
Location: "void CUDA_fft_convolution(const int3&, const int2&, float*,
cufftComplex*)"
File: /home/srit/src/rtk/rtk/code/rtkCudaFFTConvolutionImageFilter.cu
Line: 97
Description: itk::ERROR: CUFFT ERROR #2

i.e., a GPU alloc issue, even if I have the largest possible memory on a
nvidia desktop computer. Then, I ran it with cuda 6.5 and I got no error
message but a result similar to yours.
Conclusions:
- if you add the option --subsetsize 1 to your rtkfdk command line, that
should reconstruct correctly
- if you upgrade cuda, you should get an understandable error message,
- I don't think I'm going to look for a solution because the pb is probably
in cufft but if someone is willing to, be my guest!
Simon

On Mon, Nov 16, 2015 at 4:47 PM, Yang-Kyun Park <theday79 at gmail.com> wrote:

> Hi Simon,
>
> For better understanding, I'm attaching the problematic case including
> projection files, geometry file(xml) and reconstructed images.(please find
> the GDrive links. The file size is ~800 MB)
> This is phantom data and there is no patient information in it.
>
> Regarding the fftw library, I'm using [fftw-3.3.4-dll64].
>
> By the way, I found another clue. When I've tried it with a head phantom
> image (full-fan, ~ 190 projections), there was no problem. Is there any
> possibility that DDF and parker short filter play some roles on this issue?
>
> Feel free to let me know if further data is needed.
>
> Thanks!
>
> Yang
>
> ?
>  FFTW_issue.zip
> <https://drive.google.com/file/d/0BxuP3mON9V-qbVdQd0luc1lIb2M/view?usp=drive_web>
> ?
>
> On Mon, Nov 16, 2015 at 10:07 AM, Simon Rit <
> simon.rit at creatis.insa-lyon.fr> wrote:
>
>> Hi,
>> Thanks. It's really weird... When you run the tests with FFTW (compiling
>> the "test" target), do they fail?
>> Can you provide your geometry file? It might be specific to this geometry.
>> Thanks again for looking into this issue, we'll find what's the problem.
>> Simon
>>
>> On Mon, Nov 16, 2015 at 3:54 PM, Yang K Park <theday79 at gmail.com> wrote:
>>
>>> Hi Simon,
>>>
>>>
>>>
>>> Sorry for the late response.
>>>
>>>
>>>
>>> As you suggested, I?ve tried rtkramp+CUDA with only one projection and
>>> it was successfully done for both w/ FFTW and w/o FFTW.
>>>
>>> (Two results were exactly same.)
>>>
>>>
>>>
>>> Regarding  the CUDA version, I?m using v6.5.
>>>
>>>
>>>
>>> Thanks a lot for the help!
>>>
>>>
>>>
>>> Yang
>>>
>>>
>>>
>>>
>>>
>>> *From:* simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of *Simon
>>> Rit
>>> *Sent:* Thursday, November 12, 2015 5:59 PM
>>>
>>> *To:* Yang K Park <theday79 at gmail.com>
>>> *Cc:* rtk-users at openrtk.org
>>> *Subject:* Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
>>> update
>>>
>>>
>>>
>>> Hi,
>>>
>>> Ok. Can you try rtkramp with only one projection? Then you shouldn't
>>> encounter this regions issue (that should be solved one day but that's a
>>> different story).
>>>
>>> Can you also indicate which version of CUDA you're using?
>>>
>>> FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft
>>> for the FFT of the projections. So if they are not in the same format,
>>> you're in trouble and that might be the issue here... The weird part is
>>> that I didn't reproduce this problem on linux (with and without FFTW) but
>>> it might be a CUDA version difference. I'll give it another try tomorrow
>>> when you provide the CUDA version.
>>>
>>> Thanks again for reporting the issue,
>>> Simon
>>>
>>>
>>>
>>> On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com>
>>> wrote:
>>>
>>> Hi Simon,
>>>
>>>
>>>
>>> Thanks for the advice. The current RTK was compiled with FFTW to use the
>>> phase extraction feature from Amsterdam shroud.
>>>
>>>
>>>
>>> Regarding your suggestions,
>>>
>>>
>>>
>>> 1)      rtkramp w/ or w/o CUDA:
>>>
>>> (command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda
>>> --output Ramp_wCUDA.mha? )
>>>
>>>
>>>
>>> Then, I have encountered following error.
>>>
>>> ?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that
>>> input requested and buffered regions are equal.?
>>>
>>>
>>>
>>>
>>>
>>> Without CUDA, it was successfully done.
>>>
>>>
>>>
>>> 2)      I?ve re-compiled *ITK w/o FFTW* and built RTK again. r*tkfdk
>>> worked fine.*
>>>
>>> -          I?ve also repeated ?rtkramp+CUDA? with this rtk version and
>>> the error was same as above.
>>>
>>>
>>>
>>> In conclusion, my *FFTW seems to affect CUDA-based fdk reconstruction
>>> only*.
>>>
>>> But I do need FFTW for the phase extraction. What should I do?
>>>
>>>
>>>
>>> Thanks.
>>>
>>>
>>>
>>> Yang
>>>
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of
>>> Simon Rit
>>> Sent: Wednesday, November 11, 2015 4:16 PM
>>> To: Yang K Park <theday79 at gmail.com>
>>> Cc: rtk-users at openrtk.org
>>> Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
>>> update
>>>
>>>
>>>
>>> Hi,
>>>
>>> I didn't manage to reproduce the two problems on linux with the same ITK
>>> version.
>>>
>>> For point 1, did you copy itkMacro.h by hand? Because I don't see how
>>> replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the
>>> same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW?
>>> It looks like a ramp filter issue. Can you try rtkramp --path projPath
>>> --regexp .*.his, with and without --hardware cuda? Maybe you can provide
>>> your geometry file in case it's a specific geometric issue.
>>>
>>> Simon
>>>
>>>
>>>
>>> On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
>>>
>>> > Hi all,
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > I?ve updated rtk with the up-to-date revision and have encountered a
>>>
>>> > couple of problems.
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
>>>
>>> > rtkCudaUtilities.hcu. It was solved by a minor fetching:
>>>
>>> >
>>>
>>> > #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > 2.       Output of rtkfdk with CUDA was not the same as before. It was
>>> very
>>>
>>> > blurry as seen in the attached image.
>>>
>>> >
>>>
>>> > a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > I?m using VS2013 with win7, itk4.8.1.
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > The command line I used was :
>>>
>>> >
>>>
>>> > rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his
>>>
>>> > --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware
>>>
>>> > cuda --pad 1 --hann 5 --hannY 5
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > Does anyone have any idea about this?
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > Thanks.
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > Yang
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > _______________________________________________
>>>
>>> > 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/20151120/4e6c0e1e/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151120/4e6c0e1e/attachment-0003.png>

From theday79 at gmail.com  Fri Nov 20 12:36:51 2015
From: theday79 at gmail.com (Yang K Park)
Date: Fri, 20 Nov 2015 12:36:51 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAF0oig027_u_9gb8bnwT1w9jr3epZ0hkd9Mt73qK5heUq_kCkg@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
 <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
 <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>
 <CAJM7=xjBjx=FzLazWJWqJbV5d45zGi2U71NKejm9HxKhJ0-xLQ@mail.gmail.com>
 <CAF0oig027_u_9gb8bnwT1w9jr3epZ0hkd9Mt73qK5heUq_kCkg@mail.gmail.com>
Message-ID: <000901d123ba$0ae3de50$20ab9af0$@gmail.com>

Hi Simon,

 

That sounds great! Thanks a lot for your hard work.

As you said, now I can reconstruct it successfully with --subsetsize option.

 

I think the only concern left is the elongated reconstruction time.

I?ve measured it for the same phantom image with different ?subsetsize? values as well as w/o FFTW compiling.

I just report it for your information.

 

1)      w/o FFTW  : 21.4 s

2)      w/ FFTW & --subsetsize 1: 89 s

3)      w/ FFTW & --subsetsize 2: 77 s

4)      w/ FFTW & --subsetsize 4: 65 s

5)      w/ FFTW & --subsetsize 6: 51 s

6)      w/ FFTW & --subsetsize 7: (Error-graphic card seemed to be freezed)

7)      w/ FFTW & --subsetsize 8: (Error-?itk::ERROR: CUFFT ERROR #2 in rtkCudaFFTConvolutionImageFilter.cu?)

 

Of course, the difference was coming from the Ramp filter.

Therefore, I?m going to use [--subsetsize 6] for my system and will update CUDA version soon!

 

Thanks.

 

Yang

 

 

From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit
Sent: Friday, November 20, 2015 11:28 AM
To: Yang-Kyun Park <theday79 at gmail.com>
Cc: rtk-users at openrtk.org
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi Yang,
Thanks a lot for sharing the data. I have good news. I could reproduce the bug and I have solutions. First, about your dataset: it's a huge dataset and the hannY requires zero padding in both x and y. Because of this, cufft has to take the 2D FFT of projection subsets that are 4095x2048x16. Quite big!

When I ran it on my cuda 7.0, I immediately got:

itk::ExceptionObject (0x8b9cb30)
Location: "void CUDA_fft_convolution(const int3&, const int2&, float*, cufftComplex*)" 
File: /home/srit/src/rtk/rtk/code/rtkCudaFFTConvolutionImageFilter.cu
Line: 97
Description: itk::ERROR: CUFFT ERROR #2

i.e., a GPU alloc issue, even if I have the largest possible memory on a nvidia desktop computer. Then, I ran it with cuda 6.5 and I got no error message but a result similar to yours.

Conclusions:

- if you add the option --subsetsize 1 to your rtkfdk command line, that should reconstruct correctly

- if you upgrade cuda, you should get an understandable error message,

- I don't think I'm going to look for a solution because the pb is probably in cufft but if someone is willing to, be my guest!

Simon

 

On Mon, Nov 16, 2015 at 4:47 PM, Yang-Kyun Park <theday79 at gmail.com <mailto:theday79 at gmail.com> > wrote:

Hi Simon,

 

For better understanding, I'm attaching the problematic case including projection files, geometry file(xml) and reconstructed images.(please find the GDrive links. The file size is ~800 MB)

This is phantom data and there is no patient information in it.

 

Regarding the fftw library, I'm using [fftw-3.3.4-dll64].

 

By the way, I found another clue. When I've tried it with a head phantom image (full-fan, ~ 190 projections), there was no problem. Is there any possibility that DDF and parker short filter play some roles on this issue?

 

Feel free to let me know if further data is needed.

 

Thanks!

 

Yang

 

?

 <https://drive.google.com/file/d/0BxuP3mON9V-qbVdQd0luc1lIb2M/view?usp=drive_web>  FFTW_issue.zip

?

 

On Mon, Nov 16, 2015 at 10:07 AM, Simon Rit <simon.rit at creatis.insa-lyon.fr <mailto:simon.rit at creatis.insa-lyon.fr> > wrote:

Hi,

Thanks. It's really weird... When you run the tests with FFTW (compiling the "test" target), do they fail?
Can you provide your geometry file? It might be specific to this geometry.

Thanks again for looking into this issue, we'll find what's the problem.

Simon

 

On Mon, Nov 16, 2015 at 3:54 PM, Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> > wrote:

Hi Simon,

 

Sorry for the late response.

 

As you suggested, I?ve tried rtkramp+CUDA with only one projection and it was successfully done for both w/ FFTW and w/o FFTW.

(Two results were exactly same.)

 

Regarding  the CUDA version, I?m using v6.5.

 

Thanks a lot for the help!

 

Yang

 

 

From: simon.rit at gmail.com <mailto:simon.rit at gmail.com>  [mailto:simon.rit at gmail.com <mailto:simon.rit at gmail.com> ] On Behalf Of Simon Rit
Sent: Thursday, November 12, 2015 5:59 PM


To: Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> >
Cc: rtk-users at openrtk.org <mailto:rtk-users at openrtk.org> 
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

Ok. Can you try rtkramp with only one projection? Then you shouldn't encounter this regions issue (that should be solved one day but that's a different story). 

Can you also indicate which version of CUDA you're using?

FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft for the FFT of the projections. So if they are not in the same format, you're in trouble and that might be the issue here... The weird part is that I didn't reproduce this problem on linux (with and without FFTW) but it might be a CUDA version difference. I'll give it another try tomorrow when you provide the CUDA version.

Thanks again for reporting the issue,
Simon

 

On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> > wrote:

Hi Simon,

 

Thanks for the advice. The current RTK was compiled with FFTW to use the phase extraction feature from Amsterdam shroud.

 

Regarding your suggestions,

 

1)      rtkramp w/ or w/o CUDA:

(command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda --output Ramp_wCUDA.mha? )

 

Then, I have encountered following error.

?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that input requested and buffered regions are equal.?

 



 

Without CUDA, it was successfully done.

 

2)      I?ve re-compiled ITK w/o FFTW and built RTK again. rtkfdk worked fine.

-          I?ve also repeated ?rtkramp+CUDA? with this rtk version and the error was same as above.

 

In conclusion, my FFTW seems to affect CUDA-based fdk reconstruction only.

But I do need FFTW for the phase extraction. What should I do?

 

Thanks.

 

Yang

 

 

-----Original Message-----
From: simon.rit at gmail.com <mailto:simon.rit at gmail.com>  [mailto:simon.rit at gmail.com <mailto:simon.rit at gmail.com> ] On Behalf Of Simon Rit
Sent: Wednesday, November 11, 2015 4:16 PM
To: Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> >
Cc: rtk-users at openrtk.org <mailto:rtk-users at openrtk.org> 
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

I didn't manage to reproduce the two problems on linux with the same ITK version.

For point 1, did you copy itkMacro.h by hand? Because I don't see how replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW? It looks like a ramp filter issue. Can you try rtkramp --path projPath --regexp .*.his, with and without --hardware cuda? Maybe you can provide your geometry file in case it's a specific geometric issue.

Simon

 

On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park < <mailto:theday79 at gmail.com> theday79 at gmail.com> wrote:

> Hi all,

> 

> 

> 

> I?ve updated rtk with the up-to-date revision and have encountered a 

> couple of problems.

> 

> 

> 

> 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled

> rtkCudaUtilities.hcu. It was solved by a minor fetching:

> 

> #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu

> 

> 

> 

> 2.       Output of rtkfdk with CUDA was not the same as before. It was very

> blurry as seen in the attached image.

> 

> a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.

> 

> 

> 

> 

> 

> I?m using VS2013 with win7, itk4.8.1.

> 

> 

> 

> The command line I used was :

> 

> rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his 

> --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware 

> cuda --pad 1 --hann 5 --hannY 5

> 

> 

> 

> Does anyone have any idea about this?

> 

> 

> 

> Thanks.

> 

> 

> 

> Yang

> 

> 

> 

> 

> _______________________________________________

> Rtk-users mailing list

>  <mailto: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/20151120/0d98ace1/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151120/0d98ace1/attachment-0003.png>

From simon.rit at creatis.insa-lyon.fr  Wed Nov 25 02:36:44 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Wed, 25 Nov 2015 08:36:44 +0100
Subject: [Rtk-users] Compiling Problem
In-Reply-To: <040e01d125c7$83648e60$8a2dab20$@126.com>
References: <040e01d125c7$83648e60$8a2dab20$@126.com>
Message-ID: <5655650C.1040500@creatis.insa-lyon.fr>

Hi,
Please use the mailing list. I don't know where does the linking problem 
come from and it seems to work on our side:
http://my.cdash.org/index.php?project=RTK
Have you tried disabling CUDA?
Simon

On 23/11/2015 09:18, Freyman li wrote:
>
> Dear Simon,
>
> Recently I configured the RTK tool and suffer some problems. After set 
> up the itk tool and cuda, I compiled the rtk application but 
> encountered two errors attached to the email(jpg format)
>
> CUDA and ITK environment are tested successfully. My compile tool is 
> Visual studio 2012(64bit) and CUDA version is v6.5.
>
> Can you tell me how to deal with it and I am looking forward to hear 
> you again.
>
> Thank you!
>
> Best Regards
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151125/285f7f3c/attachment-0003.html>

From theday79 at gmail.com  Wed Nov 25 12:38:52 2015
From: theday79 at gmail.com (Yang K Park)
Date: Wed, 25 Nov 2015 12:38:52 -0500
Subject: [Rtk-users] Compiling Problem
In-Reply-To: <5655650C.1040500@creatis.insa-lyon.fr>
References: <040e01d125c7$83648e60$8a2dab20$@126.com>
 <5655650C.1040500@creatis.insa-lyon.fr>
Message-ID: <003d01d127a8$27a52b60$76ef8220$@gmail.com>

Hi Freyman,

 

I think your setting is much similar to mine, since I have compiled RTK with
VS2013 and CUDA v6.5 several times. Can you post those error messages again
so that I can see?

Yang

 

 

From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of
Simon Rit
Sent: Wednesday, November 25, 2015 2:37 AM
To: Freyman li <lihanwei_1500 at 126.com>
Cc: rtk-users at openrtk.org
Subject: Re: [Rtk-users] Compiling Problem

 

Hi,
Please use the mailing list. I don't know where does the linking problem
come from and it seems to work on our side:
http://my.cdash.org/index.php?project=RTK
Have you tried disabling CUDA?
Simon

On 23/11/2015 09:18, Freyman li wrote:

Dear Simon,

 

Recently I configured the RTK tool and suffer some problems. After set up
the itk tool and cuda, I compiled the rtk application but encountered two
errors attached to the email(jpg format)

CUDA and ITK environment are tested successfully. My compile tool is Visual
studio 2012(64bit) and CUDA version is v6.5.

Can you tell me how to deal with it and I am looking forward to hear you
again.

Thank you!

 

Best Regards

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151125/984feb50/attachment-0003.html>

From bioniloofar at gmail.com  Mon Nov 30 06:06:41 2015
From: bioniloofar at gmail.com (niloufar teyfouri)
Date: Mon, 30 Nov 2015 14:36:41 +0330
Subject: [Rtk-users] ElectaReconstruction
Message-ID: <CALChM12F4PuiLvgENg3Yyn7E+uZ7iPJ+GiY04z7VQ-90AS83EA@mail.gmail.com>

I ran the application of Electa Reconstruction implemented by you with
RTK. But after debugging I was encountered with the message of
"--output' ('-o') option required". Could you please help me for running
this example and the other ones?
I don't know any thing about the texts in the gray boxes mentioned at
each link related to examples of RTK.
For example in the link of
http://wiki.openrtk.org/index.php/RTK/Examples/ElektaReconstruction
how I should use gengetopt for the instructions below?


2. Run the application to convert Elekta's geometry into RTKs (DICOM_UID
is contained in the subfolder name of the his files):

  rtkelektasynergygeometry \
    --image_db IMAGE.DBF \
    --frame_db FRAME.DBF \
    --dicom_uid 1.3.46.423632.135428.1351013645.166 \
    -o elektaGeometry

I would be appreciate if one could answer my question.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151130/b11ad4e2/attachment-0003.html>

From cyril.mory at uclouvain.be  Mon Nov 30 09:30:48 2015
From: cyril.mory at uclouvain.be (Cyril Mory)
Date: Mon, 30 Nov 2015 15:30:48 +0100
Subject: [Rtk-users] ElectaReconstruction
In-Reply-To: <CALChM12F4PuiLvgENg3Yyn7E+uZ7iPJ+GiY04z7VQ-90AS83EA@mail.gmail.com>
References: <CALChM12F4PuiLvgENg3Yyn7E+uZ7iPJ+GiY04z7VQ-90AS83EA@mail.gmail.com>
Message-ID: <565C5D98.1000309@uclouvain.be>

Hi, and welcome to RTK,

Gengetopt is the piece of software that parses the command line 
arguments in all RTK applications. You do not have to "use" it. You just 
need to give correct arguments on the command line.

The message "--output' ('-o') option required" means what it says : you 
need to provide the name of the file in which you want to store the 
geometry information generated by the application 
rtkelektasynergygeometry. If you just copy-pasted the command you found 
on the wiki, then something went wrong during the copy-paste. Try to run 
the following :

rtkelektasynergygeometry --image_db IMAGE.DBF --frame_db FRAME.DBF 
--dicom_uid 1.3.46.423632.135428.1351013645.166 -o elektaGeometry

I just removed the '\' and the useless spaces. You can do the same for 
all other command line examples and it should work.

Let us know if you keep encountering trouble.
Cyril


Le 30/11/2015 12:06, niloufar teyfouri a ?crit :
>
> I ran the application of Electa Reconstruction implemented by you with
> RTK. But after debugging I was encountered with the message of
> "--output' ('-o') option required". Could you please help me for running
> this example and the other ones?
> I don't know any thing about the texts in the gray boxes mentioned at
> each link related to examples of RTK.
> For example in the link of
> http://wiki.openrtk.org/index.php/RTK/Examples/ElektaReconstruction
> how I should use gengetopt for the instructions below?
>
>
> 2. Run the application to convert Elekta's geometry into RTKs (DICOM_UID
> is contained in the subfolder name of the his files):
>
> rtkelektasynergygeometry \
> --image_db IMAGE.DBF \
> --frame_db FRAME.DBF \
> --dicom_uid 1.3.46.423632.135428.1351013645.166 \
>     -o elektaGeometry
>
> I would be appreciate if one could answer my question.
>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151130/66741755/attachment-0003.html>

From j.mason at ed.ac.uk  Mon Nov 30 11:29:27 2015
From: j.mason at ed.ac.uk (Jonathan Mason)
Date: Mon, 30 Nov 2015 16:29:27 +0000
Subject: [Rtk-users] Preprocessing
Message-ID: <565C7967.4000401@ed.ac.uk>

Good afternoon RTK users,

I have access to "raw data" from a Varian OBI scanner, and have
experimented with RTK for performing its reconstruction. However, it is
not really "raw" in the sense that the coefficients are proportional to
the photon flux recorded at a given sensor, but is instead proportional
to the Hounsfield attenuation along that path. With this data, it means
that one can reconstruct using FDK and other iterative techniques, which
assume a linear model, but the connection to the underlying physics is
abstract.

The problem I then have when trying to develop reconstruction
techniques, is that I do not know whether I am really correcting for
physical distortions or just correcting for Varian's preprocessing,
which has been finely tuned for its own FDK method.

My question is whether anybody has dug into the steps that manufacturers
such as Varian or Elekta perform to arrive at these projection images?
And if they think that if reverse engineered, could provide a richer set
of information to facilitate advanced strategies.

Best wishes,

Jonathan Mason

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.



From simon.rit at creatis.insa-lyon.fr  Mon Nov 30 12:44:03 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Mon, 30 Nov 2015 18:44:03 +0100
Subject: [Rtk-users] ElectaReconstruction
In-Reply-To: <565C5D98.1000309@uclouvain.be>
References: <CALChM12F4PuiLvgENg3Yyn7E+uZ7iPJ+GiY04z7VQ-90AS83EA@mail.gmail.com>
 <565C5D98.1000309@uclouvain.be>
Message-ID: <CAF0oig2Zg96AZaRn9w9=F+LnLnyteTn5zS1rLguQ8WXiYhnnYg@mail.gmail.com>

Hi,
I think Cyril is right, it's not possible to use backslashes to put a
command line on several line with Windows command line. Can you confirm
this? If you confirm, we will correct the wiki.
Thanks,
Simon

On Mon, Nov 30, 2015 at 3:30 PM, Cyril Mory <cyril.mory at uclouvain.be> wrote:

> Hi, and welcome to RTK,
>
> Gengetopt is the piece of software that parses the command line arguments
> in all RTK applications. You do not have to "use" it. You just need to give
> correct arguments on the command line.
>
> The message "--output' ('-o') option required" means what it says : you
> need to provide the name of the file in which you want to store the
> geometry information generated by the application rtkelektasynergygeometry.
> If you just copy-pasted the command you found on the wiki, then something
> went wrong during the copy-paste. Try to run the following :
>
> rtkelektasynergygeometry --image_db IMAGE.DBF --frame_db FRAME.DBF
> --dicom_uid 1.3.46.423632.135428.1351013645.166 -o elektaGeometry
>
> I just removed the '\' and the useless spaces. You can do the same for all
> other command line examples and it should work.
>
> Let us know if you keep encountering trouble.
> Cyril
>
>
>
> Le 30/11/2015 12:06, niloufar teyfouri a ?crit :
>
>
> I ran the application of Electa Reconstruction implemented by you with
> RTK. But after debugging I was encountered with the message of
> "--output' ('-o') option required". Could you please help me for running
> this example and the other ones?
> I don't know any thing about the texts in the gray boxes mentioned at
> each link related to examples of RTK.
> For example in the link of
> http://wiki.openrtk.org/index.php/RTK/Examples/ElektaReconstruction
> how I should use gengetopt for the instructions below?
>
>
> 2. Run the application to convert Elekta's geometry into RTKs (DICOM_UID
> is contained in the subfolder name of the his files):
>
>   rtkelektasynergygeometry \
>     --image_db IMAGE.DBF \
>     --frame_db FRAME.DBF \
>     --dicom_uid 1.3.46.423632.135428.1351013645.166 \
>     -o elektaGeometry
>
> I would be appreciate if one could answer my question.
>
>
> _______________________________________________
> Rtk-users mailing listRtk-users at public.kitware.comhttp://public.kitware.com/mailman/listinfo/rtk-users
>
>
>
>
> ------------------------------
> [image: Avast logo] <https://www.avast.com/antivirus>
>
> L'absence de virus dans ce courrier ?lectronique a ?t? v?rifi?e par le
> logiciel antivirus Avast.
> www.avast.com <https://www.avast.com/antivirus>
>
>
> _______________________________________________
> 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/20151130/6d6dd6aa/attachment-0003.html>

From wuchao04 at gmail.com  Mon Nov 30 13:50:06 2015
From: wuchao04 at gmail.com (Chao Wu)
Date: Mon, 30 Nov 2015 19:50:06 +0100
Subject: [Rtk-users] Preprocessing
In-Reply-To: <565C7967.4000401@ed.ac.uk>
References: <565C7967.4000401@ed.ac.uk>
Message-ID: <CAH+sHrUFov5f=8h4-ePhC2xLraM3BxA9r12yfXdM3rrKPeqCBg@mail.gmail.com>

Hi Jonathan,

I do not quite understand your problem.
I think most information can be retrieved by the relationship between flux
(I) and attenuation (u):
I = I0 * exp (- integral(u * dL) )
Of course there are other effects like beam hardening and scattering
involved but this model is the basic.

Regards,
Chao

2015-11-30 17:29 GMT+01:00 Jonathan Mason <j.mason at ed.ac.uk>:

> Good afternoon RTK users,
>
> I have access to "raw data" from a Varian OBI scanner, and have
> experimented with RTK for performing its reconstruction. However, it is
> not really "raw" in the sense that the coefficients are proportional to
> the photon flux recorded at a given sensor, but is instead proportional
> to the Hounsfield attenuation along that path. With this data, it means
> that one can reconstruct using FDK and other iterative techniques, which
> assume a linear model, but the connection to the underlying physics is
> abstract.
>
> The problem I then have when trying to develop reconstruction
> techniques, is that I do not know whether I am really correcting for
> physical distortions or just correcting for Varian's preprocessing,
> which has been finely tuned for its own FDK method.
>
> My question is whether anybody has dug into the steps that manufacturers
> such as Varian or Elekta perform to arrive at these projection images?
> And if they think that if reverse engineered, could provide a richer set
> of information to facilitate advanced strategies.
>
> Best wishes,
>
> Jonathan Mason
>
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
> _______________________________________________
> 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/20151130/ccb833fe/attachment-0003.html>

From mdupont at cppm.in2p3.fr  Sun Nov  1 12:41:49 2015
From: mdupont at cppm.in2p3.fr (Mathieu Dupont)
Date: Sun, 01 Nov 2015 18:41:49 +0100
Subject: [Rtk-users] question about rtkDraw*ImageFilter
In-Reply-To: <56334CF2.8070902@cppm.in2p3.fr>
References: <5630EE01.5070900@cppm.in2p3.fr>
 <CAF0oig279ZWGJMFnJdXaPiYLPponadz_J-PVKt2z3iHiTRQ_gg@mail.gmail.com>
 <56334CF2.8070902@cppm.in2p3.fr>
Message-ID: <1539144.WPSdtJ8lhZ@marabunta>

Hello Simon, 

I started to implement what I suggested : 

https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawImageFilter.h
and 
https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawCylinderImageFilter.h

rtk::DrawCylinderImageFilter derives from rtk::DrawImageFilter and specializes 
it (by defaulting the template parameter TSpatialObject with 
DrawCylinderSpatialObject). 

By default, DrawCylinderImageFilter uses Add2 for filling output image (to be 
backward compatible (all tests pass)). I created Discard (I did not find 
equivalent in itk) functor in order to do what I wanted in my first email.  

I just implemented DrawCylinderImageFilter, the others will follow. 

What do you think about it ?

Le vendredi 30 octobre 2015, 11:56:50 Mathieu Dupont a ?crit :
> Hi,
> 
> In case of your first solution, you can not chain several
> Draw*ImageFilters. For example, if you want to create small cylinders in
> a big cylinder.
> 
> Your second solution is better.
> 
> One another solution can be a thing like itk:SpatialObject but more
> simpler. An rtk::SpatialObject which one function (isInside(point)). We
> create a rtkDrawImageFilter class and implement ThreadedGenerateData
> like this :
> 
> DrawImageFilter<InImage, OutImage, rtkSpatialObject,
> rtkFillFunctor>::ThreadedGenerateData(const OutputImageRegionType&
> outputRegionForThread,                 ThreadIdType itkNotUsed(threadId)
> {
> ...
> 
>   while( !itOut.IsAtEnd() )
>      {
>      this->GetInput()->TransformIndexToPhysicalPoint(itOut.GetIndex(),
> point);
> 
>     if(m_rtkSpatialObject.isInside(point)
>       itOut.Set(m_rtkFillFunctor(density, itIn.Get());
> ...
> }
> 
> 
> DrawConeImageFilter class can be a child of this new DrawImageFilter
> (with new methods like setAngle, SetRadius which will adjust the
> rtkConeSpatialObject)
> 
> This solution suppress duplicated code in
> Draw*ImageFilter::ThreadedGenerateData and makes easier implementation
> of another type of filling.
> 
> On 28/10/2015 20:52, Simon Rit wrote:
> > Hi Mathieu,
> > Thanks for pointing this out. I agree that it might not be the best
> > solution, yet one could argue that you could simply create a constant
> > image with 0 to do what you'd like from the current implementation. My
> > main problem is that I just tried to do what you suggest and some tests
> > then fail... which shows the obvious, it's not a backward compatible
> > change. I see two solutions:
> > - keep it as is and you use ConstantImageFilter + we remove useless add
> > filters,
> > - a more complex but maybe more elegant solution: add a third template
> > parameter for the operation that would allow the user to do what he'd
> > like in a functor. That's what's done with filters that derive from
> > itk::UnaryImageFilter
> > <http://www.itk.org/Doxygen/html/classitk_1_1UnaryFunctorImageFilter.html>
> > .
> > The default would be itk::Add2 but we could find or implement another
> > one that simply discards the pixel value.
> > What do you think?
> > Simon
> > 
> > PS: looking in the code, I just found that rtk::DrawConeImageFilter is
> > not consistent with the others, it was always setting to 0 outside...
> > that's been fixed!
> > 
> > On Wed, Oct 28, 2015 at 4:47 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr
> > 
> > <mailto:mdupont at cppm.in2p3.fr>> wrote:
> >     Hello everyone,
> >     
> >     I have a question/suggestion about the set of rtkDraw*ImageFilter.
> >     This filter are written as additive filters: for example, in
> >     rtkDrawEllipsoidImageFilter.txx, we can find
> >     
> >     for(..)
> >     
> >       itOut.Set( ellipsoid.density + itIn.Get() )
> >     
> >     instead of
> >     
> >     for(..)
> >     itOut.Set( ellipsoid.density )
> >     
> >     
> >     I think it can be more flexible the second option, because we can
> >     always associate Draw*ImageFilter and itkAddImageFilter to get an
> >     additive filter.
> >     
> >     Moreover, the  rtkDrawGeometricPhantomImageFilter class already uses
> >     itkAddImageFilter in order to have additive filters (which is
> >     redundant in current situation).
> >     
> >     What do you think ?
> >     
> >     
> >     
> >     
> >     
> >     Regards
> >     
> >     
> >     
> >     _______________________________________________
> >     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


From gnthibault at gmail.com  Mon Nov  2 08:08:42 2015
From: gnthibault at gmail.com (Notargiacomo Thibault)
Date: Mon, 2 Nov 2015 14:08:42 +0100
Subject: [Rtk-users] Problem with rtkGgoFunctions when importing series of
	images
Message-ID: <CAP+mR7Zw7WmRmEgVUTamNhS6m4S6ORvWFjRu1EANViPRJ7jtuQ@mail.gmail.com>

I recently experienced the following problem, when importing multiple tif
files inside a directory using itk::ImageSeriesReader:

[...]
code/rtkGgoFunctions.h: In instantiation of ?void
rtk::SetProjectionsReaderFromGgo(typename TProjectionsReaderType::Pointer,
const TArgsInfo&)
[...]
code/rtkGgoFunctions.h:121:61: error: no type named
?OutputImageDirectionType? in ?class
itk::ImageSeriesReader<itk::Image<short unsigned int, 3u> >?
   typename TProjectionsReaderType::OutputImageDirectionType direction;
[...]

It seems that, a new functionality added in rtkGgoFunctions.h (19/05/2015),
allowing to directly modify input images properties through command line,
like geometry (direction vector), assumes that the input image type defines
OutputImageDirectionType, but in the case of itk::ImageSeriesReader, it
does not.

Is this considered as a regression, or should the
SetProjectionsReaderFromGgo function be used with specific input image type
?

Thank you in advance for your help.

Kind regards

Thibault Notargiacomo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151102/6cad3583/attachment-0004.html>

From simon.rit at creatis.insa-lyon.fr  Mon Nov  2 08:58:24 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Mon, 2 Nov 2015 14:58:24 +0100
Subject: [Rtk-users] Problem with rtkGgoFunctions when importing series
	of images
In-Reply-To: <CAP+mR7Zw7WmRmEgVUTamNhS6m4S6ORvWFjRu1EANViPRJ7jtuQ@mail.gmail.com>
References: <CAP+mR7Zw7WmRmEgVUTamNhS6m4S6ORvWFjRu1EANViPRJ7jtuQ@mail.gmail.com>
Message-ID: <CAF0oig2bAidO4JR7pa_PUxOQm-X7JrEz8=ybGX3bskYJM9YRAQ@mail.gmail.com>

Hi Thibault,
SetProjectionsReaderFromGgo is a macro designed for the
rtk::ProjectionsReader
<http://www.openrtk.org/Doxygen/classrtk_1_1ProjectionsReader.html>, I'm
not surprised that it does not work with the itk::ImageSeriesReader. It's
not about the image type but about the filter type... We use this macro to
set many parameters specific to the rtk::ProjectionsReader
<http://www.openrtk.org/Doxygen/classrtk_1_1ProjectionsReader.html>. Since
a while, I have made have a common rtkinputprojections_section.ggo
<https://github.com/SimonRit/RTK/blob/master/applications/rtkinputprojections_section.ggo>
file for all the applications that use the rtk::ProjectionsReader.
If you don't want to use the rtk::ProjectionsReader but
itk::ImageSeriesReader (e.g., because it does a lot of automatic processing
that you don't want), you'll have to write your own code to set it up.
I hope this clarifies things.
Simon

On Mon, Nov 2, 2015 at 2:08 PM, Notargiacomo Thibault <gnthibault at gmail.com>
wrote:

> I recently experienced the following problem, when importing multiple tif
> files inside a directory using itk::ImageSeriesReader:
>
> [...]
> code/rtkGgoFunctions.h: In instantiation of ?void
> rtk::SetProjectionsReaderFromGgo(typename TProjectionsReaderType::Pointer,
> const TArgsInfo&)
> [...]
> code/rtkGgoFunctions.h:121:61: error: no type named
> ?OutputImageDirectionType? in ?class
> itk::ImageSeriesReader<itk::Image<short unsigned int, 3u> >?
>    typename TProjectionsReaderType::OutputImageDirectionType direction;
> [...]
>
> It seems that, a new functionality added in rtkGgoFunctions.h
> (19/05/2015), allowing to directly modify input images properties through
> command line, like geometry (direction vector), assumes that the input
> image type defines OutputImageDirectionType, but in the case of
> itk::ImageSeriesReader, it does not.
>
> Is this considered as a regression, or should the
> SetProjectionsReaderFromGgo function be used with specific input image type
> ?
>
> Thank you in advance for your help.
>
> Kind regards
>
> Thibault Notargiacomo
>
> _______________________________________________
> 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/20151102/ee7e2c17/attachment-0004.html>

From simon.rit at creatis.insa-lyon.fr  Wed Nov  4 16:38:18 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Wed, 4 Nov 2015 22:38:18 +0100
Subject: [Rtk-users] question about rtkDraw*ImageFilter
In-Reply-To: <1539144.WPSdtJ8lhZ@marabunta>
References: <5630EE01.5070900@cppm.in2p3.fr>
 <CAF0oig279ZWGJMFnJdXaPiYLPponadz_J-PVKt2z3iHiTRQ_gg@mail.gmail.com>
 <56334CF2.8070902@cppm.in2p3.fr> <1539144.WPSdtJ8lhZ@marabunta>
Message-ID: <CAF0oig3jBsfoadM_k6SYvOMwikOCNFmH19J7m1YJZx-RU0y+5g@mail.gmail.com>

Hi Mathieu,
Sorry, I'm very busy these days. I had a first quick look. Why not, it
looks a bit complicated but good. I would have a few things I would change
style wise, e.g., move DrawCylinderSpatialObject to
DrawCylinderImageFilter, create a common DrawQuadricSpatialObject that
would all have the same IsInside function, make DrawSpatialObjectpurely
virtual by not defining
IsInside etc. but those are details I can correct myself. Do you want to
finish what you started and I work from there or should I finish everything?
Simon

On Sun, Nov 1, 2015 at 6:41 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr>
wrote:

> Hello Simon,
>
> I started to implement what I suggested :
>
>
> https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawImageFilter.h
> and
>
> https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawCylinderImageFilter.h
>
> rtk::DrawCylinderImageFilter derives from rtk::DrawImageFilter and
> specializes
> it (by defaulting the template parameter TSpatialObject with
> DrawCylinderSpatialObject).
>
> By default, DrawCylinderImageFilter uses Add2 for filling output image (to
> be
> backward compatible (all tests pass)). I created Discard (I did not find
> equivalent in itk) functor in order to do what I wanted in my first email.
>
> I just implemented DrawCylinderImageFilter, the others will follow.
>
> What do you think about it ?
>
> Le vendredi 30 octobre 2015, 11:56:50 Mathieu Dupont a ?crit :
> > Hi,
> >
> > In case of your first solution, you can not chain several
> > Draw*ImageFilters. For example, if you want to create small cylinders in
> > a big cylinder.
> >
> > Your second solution is better.
> >
> > One another solution can be a thing like itk:SpatialObject but more
> > simpler. An rtk::SpatialObject which one function (isInside(point)). We
> > create a rtkDrawImageFilter class and implement ThreadedGenerateData
> > like this :
> >
> > DrawImageFilter<InImage, OutImage, rtkSpatialObject,
> > rtkFillFunctor>::ThreadedGenerateData(const OutputImageRegionType&
> > outputRegionForThread,                 ThreadIdType itkNotUsed(threadId)
> > {
> > ...
> >
> >   while( !itOut.IsAtEnd() )
> >      {
> >      this->GetInput()->TransformIndexToPhysicalPoint(itOut.GetIndex(),
> > point);
> >
> >     if(m_rtkSpatialObject.isInside(point)
> >       itOut.Set(m_rtkFillFunctor(density, itIn.Get());
> > ...
> > }
> >
> >
> > DrawConeImageFilter class can be a child of this new DrawImageFilter
> > (with new methods like setAngle, SetRadius which will adjust the
> > rtkConeSpatialObject)
> >
> > This solution suppress duplicated code in
> > Draw*ImageFilter::ThreadedGenerateData and makes easier implementation
> > of another type of filling.
> >
> > On 28/10/2015 20:52, Simon Rit wrote:
> > > Hi Mathieu,
> > > Thanks for pointing this out. I agree that it might not be the best
> > > solution, yet one could argue that you could simply create a constant
> > > image with 0 to do what you'd like from the current implementation. My
> > > main problem is that I just tried to do what you suggest and some tests
> > > then fail... which shows the obvious, it's not a backward compatible
> > > change. I see two solutions:
> > > - keep it as is and you use ConstantImageFilter + we remove useless add
> > > filters,
> > > - a more complex but maybe more elegant solution: add a third template
> > > parameter for the operation that would allow the user to do what he'd
> > > like in a functor. That's what's done with filters that derive from
> > > itk::UnaryImageFilter
> > > <
> http://www.itk.org/Doxygen/html/classitk_1_1UnaryFunctorImageFilter.html>
> > > .
> > > The default would be itk::Add2 but we could find or implement another
> > > one that simply discards the pixel value.
> > > What do you think?
> > > Simon
> > >
> > > PS: looking in the code, I just found that rtk::DrawConeImageFilter is
> > > not consistent with the others, it was always setting to 0 outside...
> > > that's been fixed!
> > >
> > > On Wed, Oct 28, 2015 at 4:47 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr
> > >
> > > <mailto:mdupont at cppm.in2p3.fr>> wrote:
> > >     Hello everyone,
> > >
> > >     I have a question/suggestion about the set of rtkDraw*ImageFilter.
> > >     This filter are written as additive filters: for example, in
> > >     rtkDrawEllipsoidImageFilter.txx, we can find
> > >
> > >     for(..)
> > >
> > >       itOut.Set( ellipsoid.density + itIn.Get() )
> > >
> > >     instead of
> > >
> > >     for(..)
> > >     itOut.Set( ellipsoid.density )
> > >
> > >
> > >     I think it can be more flexible the second option, because we can
> > >     always associate Draw*ImageFilter and itkAddImageFilter to get an
> > >     additive filter.
> > >
> > >     Moreover, the  rtkDrawGeometricPhantomImageFilter class already
> uses
> > >     itkAddImageFilter in order to have additive filters (which is
> > >     redundant in current situation).
> > >
> > >     What do you think ?
> > >
> > >
> > >
> > >
> > >
> > >     Regards
> > >
> > >
> > >
> > >     _______________________________________________
> > >     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/20151104/46314d97/attachment-0004.html>

From mdupont at cppm.in2p3.fr  Mon Nov  9 14:35:47 2015
From: mdupont at cppm.in2p3.fr (Mathieu Dupont)
Date: Mon, 09 Nov 2015 20:35:47 +0100
Subject: [Rtk-users] question about rtkDraw*ImageFilter
In-Reply-To: <CAF0oig3jBsfoadM_k6SYvOMwikOCNFmH19J7m1YJZx-RU0y+5g@mail.gmail.com>
References: <5630EE01.5070900@cppm.in2p3.fr> <1539144.WPSdtJ8lhZ@marabunta>
 <CAF0oig3jBsfoadM_k6SYvOMwikOCNFmH19J7m1YJZx-RU0y+5g@mail.gmail.com>
Message-ID: <5634494.U9CmFl2V79@marabunta>

hi, 

i will do this during this week and try to implement your remarks. 


Le mercredi 4 novembre 2015, 22:38:18 Simon Rit a ?crit :
> Hi Mathieu,
> Sorry, I'm very busy these days. I had a first quick look. Why not, it
> looks a bit complicated but good. I would have a few things I would change
> style wise, e.g., move DrawCylinderSpatialObject to
> DrawCylinderImageFilter, create a common DrawQuadricSpatialObject that
> would all have the same IsInside function, make DrawSpatialObjectpurely
> virtual by not defining
> IsInside etc. but those are details I can correct myself. Do you want to
> finish what you started and I work from there or should I finish everything?
> Simon
> 
> On Sun, Nov 1, 2015 at 6:41 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr>
> 
> wrote:
> > Hello Simon,
> > 
> > I started to implement what I suggested :
> > 
> > 
> > https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawImag
> > eFilter.h and
> > 
> > https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawCyli
> > nderImageFilter.h
> > 
> > rtk::DrawCylinderImageFilter derives from rtk::DrawImageFilter and
> > specializes
> > it (by defaulting the template parameter TSpatialObject with
> > DrawCylinderSpatialObject).
> > 
> > By default, DrawCylinderImageFilter uses Add2 for filling output image (to
> > be
> > backward compatible (all tests pass)). I created Discard (I did not find
> > equivalent in itk) functor in order to do what I wanted in my first email.
> > 
> > I just implemented DrawCylinderImageFilter, the others will follow.
> > 
> > What do you think about it ?
> > 
> > Le vendredi 30 octobre 2015, 11:56:50 Mathieu Dupont a ?crit :
> > > Hi,
> > > 
> > > In case of your first solution, you can not chain several
> > > Draw*ImageFilters. For example, if you want to create small cylinders in
> > > a big cylinder.
> > > 
> > > Your second solution is better.
> > > 
> > > One another solution can be a thing like itk:SpatialObject but more
> > > simpler. An rtk::SpatialObject which one function (isInside(point)). We
> > > create a rtkDrawImageFilter class and implement ThreadedGenerateData
> > > like this :
> > > 
> > > DrawImageFilter<InImage, OutImage, rtkSpatialObject,
> > > rtkFillFunctor>::ThreadedGenerateData(const OutputImageRegionType&
> > > outputRegionForThread,                 ThreadIdType itkNotUsed(threadId)
> > > {
> > > ...
> > > 
> > >   while( !itOut.IsAtEnd() )
> > >   
> > >      {
> > >      this->GetInput()->TransformIndexToPhysicalPoint(itOut.GetIndex(),
> > > 
> > > point);
> > > 
> > >     if(m_rtkSpatialObject.isInside(point)
> > >     
> > >       itOut.Set(m_rtkFillFunctor(density, itIn.Get());
> > > 
> > > ...
> > > }
> > > 
> > > 
> > > DrawConeImageFilter class can be a child of this new DrawImageFilter
> > > (with new methods like setAngle, SetRadius which will adjust the
> > > rtkConeSpatialObject)
> > > 
> > > This solution suppress duplicated code in
> > > Draw*ImageFilter::ThreadedGenerateData and makes easier implementation
> > > of another type of filling.
> > > 
> > > On 28/10/2015 20:52, Simon Rit wrote:
> > > > Hi Mathieu,
> > > > Thanks for pointing this out. I agree that it might not be the best
> > > > solution, yet one could argue that you could simply create a constant
> > > > image with 0 to do what you'd like from the current implementation. My
> > > > main problem is that I just tried to do what you suggest and some
> > > > tests
> > > > then fail... which shows the obvious, it's not a backward compatible
> > > > change. I see two solutions:
> > > > - keep it as is and you use ConstantImageFilter + we remove useless
> > > > add
> > > > filters,
> > > > - a more complex but maybe more elegant solution: add a third template
> > > > parameter for the operation that would allow the user to do what he'd
> > > > like in a functor. That's what's done with filters that derive from
> > > > itk::UnaryImageFilter
> > > > <
> > 
> > http://www.itk.org/Doxygen/html/classitk_1_1UnaryFunctorImageFilter.html>
> > 
> > > > .
> > > > The default would be itk::Add2 but we could find or implement another
> > > > one that simply discards the pixel value.
> > > > What do you think?
> > > > Simon
> > > > 
> > > > PS: looking in the code, I just found that rtk::DrawConeImageFilter is
> > > > not consistent with the others, it was always setting to 0 outside...
> > > > that's been fixed!
> > > > 
> > > > On Wed, Oct 28, 2015 at 4:47 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr
> > > > 
> > > > <mailto:mdupont at cppm.in2p3.fr>> wrote:
> > > >     Hello everyone,
> > > >     
> > > >     I have a question/suggestion about the set of rtkDraw*ImageFilter.
> > > >     This filter are written as additive filters: for example, in
> > > >     rtkDrawEllipsoidImageFilter.txx, we can find
> > > >     
> > > >     for(..)
> > > >     
> > > >       itOut.Set( ellipsoid.density + itIn.Get() )
> > > >     
> > > >     instead of
> > > >     
> > > >     for(..)
> > > >     itOut.Set( ellipsoid.density )
> > > >     
> > > >     
> > > >     I think it can be more flexible the second option, because we can
> > > >     always associate Draw*ImageFilter and itkAddImageFilter to get an
> > > >     additive filter.
> > > >     
> > > >     Moreover, the  rtkDrawGeometricPhantomImageFilter class already
> > 
> > uses
> > 
> > > >     itkAddImageFilter in order to have additive filters (which is
> > > >     redundant in current situation).
> > > >     
> > > >     What do you think ?
> > > >     
> > > >     
> > > >     
> > > >     
> > > >     
> > > >     Regards
> > > >     
> > > >     
> > > >     
> > > >     _______________________________________________
> > > >     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


From gnthibault at gmail.com  Tue Nov 10 07:39:46 2015
From: gnthibault at gmail.com (Notargiacomo Thibault)
Date: Tue, 10 Nov 2015 13:39:46 +0100
Subject: [Rtk-users] Understanding projection matrices management in
	rtkCudaBackProjectionImageFilter
Message-ID: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>

Hi all,

I am currently trying to use the "AddProjectionInRadians" method from the
ThreeDCircularProjectionGeometry class in RTK to import my geometry.

First things first, I would like to know if the information on this pdf are
still valid: http://www.openrtk.org/Doxygen/geometry.pdf

Because I used them to deduce the source offset and Projection offset from
my own matrix decomposition.

Notice that I don't want to use geometric informations coming from the
projection images themselves, so their geometric origin is assumed to be
(0,0,0) in my case.

In order to check if my geometry import method is correct, I print out one
of the intermediate form of the projection matrix used in the
backprojection process, in order to check if it is the same as in my own
implementation.

To do so, I print out one of the intermediate matrix that is generated in
rtkCudaBackProjectionImageFilter while launching a SART reconstruction for
instance.

I was surpised by the fact that, the matrix allowing the transformation
from 2D geometric world to 2D image index world, namely matrixIdxProj in
rtkCudaBackProjectionImageFilte.cxx
<http://www.openrtk.org/Doxygen/rtkCudaBackProjectionImageFilter_8cxx_source.html>
is not always the same along the reconstruction process ?

Here is the line that generates the matrix I don't understand:

for(unsigned int i=0; i<2; i++)
 //SR: 0.5 for 2D texture
  matrixIdxProj[i][2] =
-1*(this->GetInput(1)->GetBufferedRegion().GetIndex()[i])+0.5;

What I understand here, is that, we are generating a 2D translation matrix
embedded in a 3*3 matrix that allows to take into account two things
related to the 2D projection:

-If the internal behaviour of the imageContainer, allows buffering of only
a part of the image, beginning at index (i,j), this information will be
embeded in the projection matrix

-the ITK floating point addressing definition seems to differ from the one
from cuda (and openCV):
When I take a look at this page
<http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#texture-fetching>
I understand that the floating point indexing (0.5,0.5) in Cuda points to
the center of the pixel (0,0) hence a linear contribution of 100%, while it
seems that we must add a translation of (0.5,0.5) to the ITK geometric
framework in order to get the same behaviour.

In practice matrixIdxProj is based on a 3*3 identity matrix, where the
inner 2D translation (ie 2 first term of the last column) in my case are:
-in X, a random number between 10 and 150 plus 0.5
-in Y: always 0.5

I understand the 0.5 part, but why is there always a 0 offset in Y but a
random offset in X remains a mystery to me.

At first, I believed that each projection was splitted into multiple part,
each having a different X and Y offset.
But reconstructing using only one projection generates only one
backprojection operation, with a non zero offset in X, 123 in my case, for
an image of size 780 in X.

Do you think there is something wrong whith the values of matrixIdxProjI am
experiencing ?

Thank you in advance.

Kind regards

Thibault Notargiacomo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151110/fbd3fb46/attachment-0004.html>

From simon.rit at creatis.insa-lyon.fr  Tue Nov 10 08:21:29 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Tue, 10 Nov 2015 14:21:29 +0100
Subject: [Rtk-users] Understanding projection matrices management in
	rtkCudaBackProjectionImageFilter
In-Reply-To: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>
References: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>
Message-ID: <CAF0oig3muuH+1=eLZ66DJ22QcnsSrUKzRFS4RzDRvDJXNxAVXg@mail.gmail.com>

Hi Thibault,
You started digging in the code so that gets complicated. First thing
first, yes, the link you provide is still valid.
The offset in X is not random but computed in
BackProjectionImageFilter::GenerateInputRequestedRegion
<https://github.com/SimonRit/RTK/blob/master/code/rtkBackProjectionImageFilter.txx>.
The idea is that we request only the part of the projections we need to do
the backprojection. This optimizes the streaming (we only read from disk
what we need). If you use a huge volume (the test I'd suggest to validate
that I'm correct and there is nothing wrong with your code), then you'll
need the full projection and you will always get 0 in X as in Y. If you use
a small volume and do a computation projection per projection, you will get
a varying index depending on your input volume and the geometry for that
projection.
I think you understood the rest pretty well. Does that make sense or am I
missing something else?
Simon

On Tue, Nov 10, 2015 at 1:39 PM, Notargiacomo Thibault <gnthibault at gmail.com
> wrote:

> Hi all,
>
> I am currently trying to use the "AddProjectionInRadians" method from the
> ThreeDCircularProjectionGeometry class in RTK to import my geometry.
>
> First things first, I would like to know if the information on this pdf
> are still valid: http://www.openrtk.org/Doxygen/geometry.pdf
>
> Because I used them to deduce the source offset and Projection offset from
> my own matrix decomposition.
>
> Notice that I don't want to use geometric informations coming from the
> projection images themselves, so their geometric origin is assumed to be
> (0,0,0) in my case.
>
> In order to check if my geometry import method is correct, I print out one
> of the intermediate form of the projection matrix used in the
> backprojection process, in order to check if it is the same as in my own
> implementation.
>
> To do so, I print out one of the intermediate matrix that is generated in
> rtkCudaBackProjectionImageFilter while launching a SART reconstruction for
> instance.
>
> I was surpised by the fact that, the matrix allowing the transformation
> from 2D geometric world to 2D image index world, namely matrixIdxProj in
> rtkCudaBackProjectionImageFilte.cxx
> <http://www.openrtk.org/Doxygen/rtkCudaBackProjectionImageFilter_8cxx_source.html>
> is not always the same along the reconstruction process ?
>
> Here is the line that generates the matrix I don't understand:
>
> for(unsigned int i=0; i<2; i++)
>  //SR: 0.5 for 2D texture
>   matrixIdxProj[i][2] =
> -1*(this->GetInput(1)->GetBufferedRegion().GetIndex()[i])+0.5;
>
> What I understand here, is that, we are generating a 2D translation matrix
> embedded in a 3*3 matrix that allows to take into account two things
> related to the 2D projection:
>
> -If the internal behaviour of the imageContainer, allows buffering of only
> a part of the image, beginning at index (i,j), this information will be
> embeded in the projection matrix
>
> -the ITK floating point addressing definition seems to differ from the one
> from cuda (and openCV):
> When I take a look at this page
> <http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#texture-fetching>
> I understand that the floating point indexing (0.5,0.5) in Cuda points to
> the center of the pixel (0,0) hence a linear contribution of 100%, while it
> seems that we must add a translation of (0.5,0.5) to the ITK geometric
> framework in order to get the same behaviour.
>
> In practice matrixIdxProj is based on a 3*3 identity matrix, where the
> inner 2D translation (ie 2 first term of the last column) in my case are:
> -in X, a random number between 10 and 150 plus 0.5
> -in Y: always 0.5
>
> I understand the 0.5 part, but why is there always a 0 offset in Y but a
> random offset in X remains a mystery to me.
>
> At first, I believed that each projection was splitted into multiple part,
> each having a different X and Y offset.
> But reconstructing using only one projection generates only one
> backprojection operation, with a non zero offset in X, 123 in my case, for
> an image of size 780 in X.
>
> Do you think there is something wrong whith the values of matrixIdxProjI
> am experiencing ?
>
> Thank you in advance.
>
> Kind regards
>
> Thibault Notargiacomo
>
> _______________________________________________
> 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/20151110/8b9b86e6/attachment-0004.html>

From simon.rit at creatis.insa-lyon.fr  Tue Nov 10 09:03:52 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Tue, 10 Nov 2015 15:03:52 +0100
Subject: [Rtk-users] Understanding projection matrices management in
	rtkCudaBackProjectionImageFilter
In-Reply-To: <CAP+mR7ZLJV8V5dMOW_jgM5G2-kCZhy8o0tB19685LGo-1bxLUg@mail.gmail.com>
References: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>
 <CAF0oig3muuH+1=eLZ66DJ22QcnsSrUKzRFS4RzDRvDJXNxAVXg@mail.gmail.com>
 <CAP+mR7ZLJV8V5dMOW_jgM5G2-kCZhy8o0tB19685LGo-1bxLUg@mail.gmail.com>
Message-ID: <CAF0oig3fALRnZNCJ53+TsSjBm7raRC_mqahWEU6x+D+zxwOnVQ@mail.gmail.com>

A small correction: it's actually the amount of data pre-processed (read
from disk + all the processing before backprojection) but that should
change nothing to what is backprojected.
I remembered something that can help you: you may want to run
UpdateLargestPossibleRegion() to the projections (input 1 of the
BackProjectImageFilter) before backprojection to avoid this and make things
clearer instead of using a large volume as I was suggesting before.
Simon

On Tue, Nov 10, 2015 at 2:34 PM, Notargiacomo Thibault <gnthibault at gmail.com
> wrote:

> Ok, using geometric information to reduce the amount of data to be
> backprojected is pretty clever ;)
> This explains the "random" index I was asking about in my previous
> question, I now know what it is used for and continue my debugging process.
>
> Kind regards
>
> Thibault Notargiacomo
>
> 2015-11-10 14:21 GMT+01:00 Simon Rit <simon.rit at creatis.insa-lyon.fr>:
>
>> Hi Thibault,
>> You started digging in the code so that gets complicated. First thing
>> first, yes, the link you provide is still valid.
>> The offset in X is not random but computed in
>> BackProjectionImageFilter::GenerateInputRequestedRegion
>> <https://github.com/SimonRit/RTK/blob/master/code/rtkBackProjectionImageFilter.txx>.
>> The idea is that we request only the part of the projections we need to do
>> the backprojection. This optimizes the streaming (we only read from disk
>> what we need). If you use a huge volume (the test I'd suggest to validate
>> that I'm correct and there is nothing wrong with your code), then you'll
>> need the full projection and you will always get 0 in X as in Y. If you use
>> a small volume and do a computation projection per projection, you will get
>> a varying index depending on your input volume and the geometry for that
>> projection.
>> I think you understood the rest pretty well. Does that make sense or am I
>> missing something else?
>> Simon
>>
>> On Tue, Nov 10, 2015 at 1:39 PM, Notargiacomo Thibault <
>> gnthibault at gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> I am currently trying to use the "AddProjectionInRadians" method from
>>> the ThreeDCircularProjectionGeometry class in RTK to import my geometry.
>>>
>>> First things first, I would like to know if the information on this pdf
>>> are still valid: http://www.openrtk.org/Doxygen/geometry.pdf
>>>
>>> Because I used them to deduce the source offset and Projection offset
>>> from my own matrix decomposition.
>>>
>>> Notice that I don't want to use geometric informations coming from the
>>> projection images themselves, so their geometric origin is assumed to be
>>> (0,0,0) in my case.
>>>
>>> In order to check if my geometry import method is correct, I print out
>>> one of the intermediate form of the projection matrix used in the
>>> backprojection process, in order to check if it is the same as in my own
>>> implementation.
>>>
>>> To do so, I print out one of the intermediate matrix that is generated
>>> in rtkCudaBackProjectionImageFilter while launching a SART reconstruction
>>> for instance.
>>>
>>> I was surpised by the fact that, the matrix allowing the transformation
>>> from 2D geometric world to 2D image index world, namely matrixIdxProj in
>>> rtkCudaBackProjectionImageFilte.cxx
>>> <http://www.openrtk.org/Doxygen/rtkCudaBackProjectionImageFilter_8cxx_source.html>
>>> is not always the same along the reconstruction process ?
>>>
>>> Here is the line that generates the matrix I don't understand:
>>>
>>> for(unsigned int i=0; i<2; i++)
>>>  //SR: 0.5 for 2D texture
>>>   matrixIdxProj[i][2] =
>>> -1*(this->GetInput(1)->GetBufferedRegion().GetIndex()[i])+0.5;
>>>
>>> What I understand here, is that, we are generating a 2D translation
>>> matrix embedded in a 3*3 matrix that allows to take into account two things
>>> related to the 2D projection:
>>>
>>> -If the internal behaviour of the imageContainer, allows buffering of
>>> only a part of the image, beginning at index (i,j), this information will
>>> be embeded in the projection matrix
>>>
>>> -the ITK floating point addressing definition seems to differ from the
>>> one from cuda (and openCV):
>>> When I take a look at this page
>>> <http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#texture-fetching>
>>> I understand that the floating point indexing (0.5,0.5) in Cuda points to
>>> the center of the pixel (0,0) hence a linear contribution of 100%, while it
>>> seems that we must add a translation of (0.5,0.5) to the ITK geometric
>>> framework in order to get the same behaviour.
>>>
>>> In practice matrixIdxProj is based on a 3*3 identity matrix, where the
>>> inner 2D translation (ie 2 first term of the last column) in my case are:
>>> -in X, a random number between 10 and 150 plus 0.5
>>> -in Y: always 0.5
>>>
>>> I understand the 0.5 part, but why is there always a 0 offset in Y but a
>>> random offset in X remains a mystery to me.
>>>
>>> At first, I believed that each projection was splitted into multiple
>>> part, each having a different X and Y offset.
>>> But reconstructing using only one projection generates only one
>>> backprojection operation, with a non zero offset in X, 123 in my case, for
>>> an image of size 780 in X.
>>>
>>> Do you think there is something wrong whith the values of matrixIdxProjI
>>> am experiencing ?
>>>
>>> Thank you in advance.
>>>
>>> Kind regards
>>>
>>> Thibault Notargiacomo
>>>
>>> _______________________________________________
>>> 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/20151110/d8913dc3/attachment-0004.html>

From simon.rit at creatis.insa-lyon.fr  Tue Nov 10 11:21:29 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Tue, 10 Nov 2015 17:21:29 +0100
Subject: [Rtk-users] Understanding projection matrices management in
	rtkCudaBackProjectionImageFilter
In-Reply-To: <CAP+mR7ZKqnbUyRHyHkti=3sZd2dEw-OUV6oqsqcga55=tcQ9OQ@mail.gmail.com>
References: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>
 <CAF0oig3muuH+1=eLZ66DJ22QcnsSrUKzRFS4RzDRvDJXNxAVXg@mail.gmail.com>
 <CAP+mR7ZLJV8V5dMOW_jgM5G2-kCZhy8o0tB19685LGo-1bxLUg@mail.gmail.com>
 <CAF0oig3fALRnZNCJ53+TsSjBm7raRC_mqahWEU6x+D+zxwOnVQ@mail.gmail.com>
 <CAP+mR7ZKqnbUyRHyHkti=3sZd2dEw-OUV6oqsqcga55=tcQ9OQ@mail.gmail.com>
Message-ID: <CAF0oig12pRGBfgiCQMCwTG7zX_3vz87AEWhTQ4EYaVbH_m0t5Q@mail.gmail.com>

Your welcome (I cc the mailing list for info).
Simon

On Tue, Nov 10, 2015 at 5:03 PM, Notargiacomo Thibault <gnthibault at gmail.com
> wrote:

> I replaced the original Update by the "UpdateLargestPossibleRegion" to the
> divideFilter in SART (I bypassed displacedDetectorFilter for now) and it
> work as expected, I have now a "clean" matProjIdx.
>
> Thank you for your help !
>
> 2015-11-10 15:03 GMT+01:00 Simon Rit <simon.rit at creatis.insa-lyon.fr>:
>
>> A small correction: it's actually the amount of data pre-processed (read
>> from disk + all the processing before backprojection) but that should
>> change nothing to what is backprojected.
>> I remembered something that can help you: you may want to run
>> UpdateLargestPossibleRegion() to the projections (input 1 of the
>> BackProjectImageFilter) before backprojection to avoid this and make things
>> clearer instead of using a large volume as I was suggesting before.
>> Simon
>>
>> On Tue, Nov 10, 2015 at 2:34 PM, Notargiacomo Thibault <
>> gnthibault at gmail.com> wrote:
>>
>>> Ok, using geometric information to reduce the amount of data to be
>>> backprojected is pretty clever ;)
>>> This explains the "random" index I was asking about in my previous
>>> question, I now know what it is used for and continue my debugging process.
>>>
>>> Kind regards
>>>
>>> Thibault Notargiacomo
>>>
>>> 2015-11-10 14:21 GMT+01:00 Simon Rit <simon.rit at creatis.insa-lyon.fr>:
>>>
>>>> Hi Thibault,
>>>> You started digging in the code so that gets complicated. First thing
>>>> first, yes, the link you provide is still valid.
>>>> The offset in X is not random but computed in
>>>> BackProjectionImageFilter::GenerateInputRequestedRegion
>>>> <https://github.com/SimonRit/RTK/blob/master/code/rtkBackProjectionImageFilter.txx>.
>>>> The idea is that we request only the part of the projections we need to do
>>>> the backprojection. This optimizes the streaming (we only read from disk
>>>> what we need). If you use a huge volume (the test I'd suggest to validate
>>>> that I'm correct and there is nothing wrong with your code), then you'll
>>>> need the full projection and you will always get 0 in X as in Y. If you use
>>>> a small volume and do a computation projection per projection, you will get
>>>> a varying index depending on your input volume and the geometry for that
>>>> projection.
>>>> I think you understood the rest pretty well. Does that make sense or am
>>>> I missing something else?
>>>> Simon
>>>>
>>>> On Tue, Nov 10, 2015 at 1:39 PM, Notargiacomo Thibault <
>>>> gnthibault at gmail.com> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I am currently trying to use the "AddProjectionInRadians" method from
>>>>> the ThreeDCircularProjectionGeometry class in RTK to import my geometry.
>>>>>
>>>>> First things first, I would like to know if the information on this
>>>>> pdf are still valid: http://www.openrtk.org/Doxygen/geometry.pdf
>>>>>
>>>>> Because I used them to deduce the source offset and Projection offset
>>>>> from my own matrix decomposition.
>>>>>
>>>>> Notice that I don't want to use geometric informations coming from the
>>>>> projection images themselves, so their geometric origin is assumed to be
>>>>> (0,0,0) in my case.
>>>>>
>>>>> In order to check if my geometry import method is correct, I print out
>>>>> one of the intermediate form of the projection matrix used in the
>>>>> backprojection process, in order to check if it is the same as in my own
>>>>> implementation.
>>>>>
>>>>> To do so, I print out one of the intermediate matrix that is generated
>>>>> in rtkCudaBackProjectionImageFilter while launching a SART reconstruction
>>>>> for instance.
>>>>>
>>>>> I was surpised by the fact that, the matrix allowing the
>>>>> transformation from 2D geometric world to 2D image index world, namely
>>>>> matrixIdxProj in rtkCudaBackProjectionImageFilte.cxx
>>>>> <http://www.openrtk.org/Doxygen/rtkCudaBackProjectionImageFilter_8cxx_source.html>
>>>>> is not always the same along the reconstruction process ?
>>>>>
>>>>> Here is the line that generates the matrix I don't understand:
>>>>>
>>>>> for(unsigned int i=0; i<2; i++)
>>>>>  //SR: 0.5 for 2D texture
>>>>>   matrixIdxProj[i][2] =
>>>>> -1*(this->GetInput(1)->GetBufferedRegion().GetIndex()[i])+0.5;
>>>>>
>>>>> What I understand here, is that, we are generating a 2D translation
>>>>> matrix embedded in a 3*3 matrix that allows to take into account two things
>>>>> related to the 2D projection:
>>>>>
>>>>> -If the internal behaviour of the imageContainer, allows buffering of
>>>>> only a part of the image, beginning at index (i,j), this information will
>>>>> be embeded in the projection matrix
>>>>>
>>>>> -the ITK floating point addressing definition seems to differ from the
>>>>> one from cuda (and openCV):
>>>>> When I take a look at this page
>>>>> <http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#texture-fetching>
>>>>> I understand that the floating point indexing (0.5,0.5) in Cuda points to
>>>>> the center of the pixel (0,0) hence a linear contribution of 100%, while it
>>>>> seems that we must add a translation of (0.5,0.5) to the ITK geometric
>>>>> framework in order to get the same behaviour.
>>>>>
>>>>> In practice matrixIdxProj is based on a 3*3 identity matrix, where
>>>>> the inner 2D translation (ie 2 first term of the last column) in my case
>>>>> are:
>>>>> -in X, a random number between 10 and 150 plus 0.5
>>>>> -in Y: always 0.5
>>>>>
>>>>> I understand the 0.5 part, but why is there always a 0 offset in Y but
>>>>> a random offset in X remains a mystery to me.
>>>>>
>>>>> At first, I believed that each projection was splitted into multiple
>>>>> part, each having a different X and Y offset.
>>>>> But reconstructing using only one projection generates only one
>>>>> backprojection operation, with a non zero offset in X, 123 in my case, for
>>>>> an image of size 780 in X.
>>>>>
>>>>> Do you think there is something wrong whith the values of matrixIdxProjI
>>>>> am experiencing ?
>>>>>
>>>>> Thank you in advance.
>>>>>
>>>>> Kind regards
>>>>>
>>>>> Thibault Notargiacomo
>>>>>
>>>>> _______________________________________________
>>>>> 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/20151110/b7eba683/attachment-0004.html>

From theday79 at gmail.com  Wed Nov 11 13:50:45 2015
From: theday79 at gmail.com (Yang K Park)
Date: Wed, 11 Nov 2015 13:50:45 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after  a recent update
Message-ID: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>

Hi all,

 

I?ve updated rtk with the up-to-date revision and have encountered a couple of problems.

 

1.       Compile error: RTK couldn?t find itkMacro.h while it compiled rtkCudaUtilities.hcu. It was solved by a minor fetching:

#include <itkMacro.h>   --> #include "itkMacro.h" in rtkCudaUtilities.hcu

 

2.       Output of rtkfdk with CUDA was not the same as before. It was very blurry as seen in the attached image.

a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.

 

 

I?m using VS2013 with win7, itk4.8.1.

 

The command line I used was :

rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware cuda --pad 1 --hann 5 --hannY 5

 

Does anyone have any idea about this?

 

Thanks.

 

Yang

 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151111/b1c7df5f/attachment-0004.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 16577 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151111/b1c7df5f/attachment-0004.png>

From simon.rit at creatis.insa-lyon.fr  Wed Nov 11 16:15:49 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Wed, 11 Nov 2015 22:15:49 +0100
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
Message-ID: <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>

Hi,
I didn't manage to reproduce the two problems on linux with the same
ITK version.
For point 1, did you copy itkMacro.h by hand? Because I don't see how
replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not
in the same folder as rtkCudaUtilities.hcu
For point 2, no clue. Do you use FFTW? It looks like a ramp filter
issue. Can you try rtkramp --path projPath --regexp .*.his, with and
without --hardware cuda? Maybe you can provide your geometry file in
case it's a specific geometric issue.
Simon

On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
> Hi all,
>
>
>
> I?ve updated rtk with the up-to-date revision and have encountered a couple
> of problems.
>
>
>
> 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
> rtkCudaUtilities.hcu. It was solved by a minor fetching:
>
> #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>
>
>
> 2.       Output of rtkfdk with CUDA was not the same as before. It was very
> blurry as seen in the attached image.
>
> a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>
>
>
>
>
> I?m using VS2013 with win7, itk4.8.1.
>
>
>
> The command line I used was :
>
> rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his --output
> output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware cuda --pad 1
> --hann 5 --hannY 5
>
>
>
> Does anyone have any idea about this?
>
>
>
> Thanks.
>
>
>
> Yang
>
>
>
>
> _______________________________________________
> Rtk-users mailing list
> Rtk-users at public.kitware.com
> http://public.kitware.com/mailman/listinfo/rtk-users
>


From theday79 at gmail.com  Thu Nov 12 17:39:38 2015
From: theday79 at gmail.com (Yang K Park)
Date: Thu, 12 Nov 2015 17:39:38 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
Message-ID: <000001d11d9b$04142320$0c3c6960$@gmail.com>

Hi Simon,

 

Thanks for the advice. The current RTK was compiled with FFTW to use the phase extraction feature from Amsterdam shroud.

 

Regarding your suggestions,

 

1)      rtkramp w/ or w/o CUDA:

(command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda --output Ramp_wCUDA.mha? )

 

Then, I have encountered following error.

?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that input requested and buffered regions are equal.?

 



 

Without CUDA, it was successfully done.

 

2)      I?ve re-compiled ITK w/o FFTW and built RTK again. rtkfdk worked fine.

-          I?ve also repeated ?rtkramp+CUDA? with this rtk version and the error was same as above.

 

In conclusion, my FFTW seems to affect CUDA-based fdk reconstruction only.

But I do need FFTW for the phase extraction. What should I do?

 

Thanks.

 

Yang

 

 

-----Original Message-----
From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit
Sent: Wednesday, November 11, 2015 4:16 PM
To: Yang K Park <theday79 at gmail.com>
Cc: rtk-users at openrtk.org
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

I didn't manage to reproduce the two problems on linux with the same ITK version.

For point 1, did you copy itkMacro.h by hand? Because I don't see how replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW? It looks like a ramp filter issue. Can you try rtkramp --path projPath --regexp .*.his, with and without --hardware cuda? Maybe you can provide your geometry file in case it's a specific geometric issue.

Simon

 

On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park < <mailto:theday79 at gmail.com> theday79 at gmail.com> wrote:

> Hi all,

> 

> 

> 

> I?ve updated rtk with the up-to-date revision and have encountered a 

> couple of problems.

> 

> 

> 

> 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled

> rtkCudaUtilities.hcu. It was solved by a minor fetching:

> 

> #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu

> 

> 

> 

> 2.       Output of rtkfdk with CUDA was not the same as before. It was very

> blurry as seen in the attached image.

> 

> a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.

> 

> 

> 

> 

> 

> I?m using VS2013 with win7, itk4.8.1.

> 

> 

> 

> The command line I used was :

> 

> rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his 

> --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware 

> cuda --pad 1 --hann 5 --hannY 5

> 

> 

> 

> Does anyone have any idea about this?

> 

> 

> 

> Thanks.

> 

> 

> 

> Yang

> 

> 

> 

> 

> _______________________________________________

> Rtk-users mailing list

>  <mailto: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/20151112/4e0825dc/attachment-0004.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151112/4e0825dc/attachment-0004.png>

From simon.rit at creatis.insa-lyon.fr  Thu Nov 12 17:58:42 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Thu, 12 Nov 2015 23:58:42 +0100
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <000001d11d9b$04142320$0c3c6960$@gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
Message-ID: <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>

Hi,
Ok. Can you try rtkramp with only one projection? Then you shouldn't
encounter this regions issue (that should be solved one day but that's a
different story).
Can you also indicate which version of CUDA you're using?
FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft for
the FFT of the projections. So if they are not in the same format, you're
in trouble and that might be the issue here... The weird part is that I
didn't reproduce this problem on linux (with and without FFTW) but it might
be a CUDA version difference. I'll give it another try tomorrow when you
provide the CUDA version.
Thanks again for reporting the issue,
Simon

On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com> wrote:

> Hi Simon,
>
>
>
> Thanks for the advice. The current RTK was compiled with FFTW to use the
> phase extraction feature from Amsterdam shroud.
>
>
>
> Regarding your suggestions,
>
>
>
> 1)      rtkramp w/ or w/o CUDA:
>
> (command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda
> --output Ramp_wCUDA.mha? )
>
>
>
> Then, I have encountered following error.
>
> ?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that
> input requested and buffered regions are equal.?
>
>
>
>
>
> Without CUDA, it was successfully done.
>
>
>
> 2)      I?ve re-compiled *ITK w/o FFTW* and built RTK again. r*tkfdk
> worked fine.*
>
> -          I?ve also repeated ?rtkramp+CUDA? with this rtk version and
> the error was same as above.
>
>
>
> In conclusion, my *FFTW seems to affect CUDA-based fdk reconstruction
> only*.
>
> But I do need FFTW for the phase extraction. What should I do?
>
>
>
> Thanks.
>
>
>
> Yang
>
>
>
>
>
> -----Original Message-----
> From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon
> Rit
> Sent: Wednesday, November 11, 2015 4:16 PM
> To: Yang K Park <theday79 at gmail.com>
> Cc: rtk-users at openrtk.org
> Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
> update
>
>
>
> Hi,
>
> I didn't manage to reproduce the two problems on linux with the same ITK
> version.
>
> For point 1, did you copy itkMacro.h by hand? Because I don't see how
> replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the
> same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW?
> It looks like a ramp filter issue. Can you try rtkramp --path projPath
> --regexp .*.his, with and without --hardware cuda? Maybe you can provide
> your geometry file in case it's a specific geometric issue.
>
> Simon
>
>
>
> On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
>
> > Hi all,
>
> >
>
> >
>
> >
>
> > I?ve updated rtk with the up-to-date revision and have encountered a
>
> > couple of problems.
>
> >
>
> >
>
> >
>
> > 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
>
> > rtkCudaUtilities.hcu. It was solved by a minor fetching:
>
> >
>
> > #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>
> >
>
> >
>
> >
>
> > 2.       Output of rtkfdk with CUDA was not the same as before. It was
> very
>
> > blurry as seen in the attached image.
>
> >
>
> > a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > I?m using VS2013 with win7, itk4.8.1.
>
> >
>
> >
>
> >
>
> > The command line I used was :
>
> >
>
> > rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his
>
> > --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware
>
> > cuda --pad 1 --hann 5 --hannY 5
>
> >
>
> >
>
> >
>
> > Does anyone have any idea about this?
>
> >
>
> >
>
> >
>
> > Thanks.
>
> >
>
> >
>
> >
>
> > Yang
>
> >
>
> >
>
> >
>
> >
>
> > _______________________________________________
>
> > 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/20151112/e7c15ff8/attachment-0004.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151112/e7c15ff8/attachment-0004.png>

From theday79 at gmail.com  Mon Nov 16 09:54:01 2015
From: theday79 at gmail.com (Yang K Park)
Date: Mon, 16 Nov 2015 09:54:01 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
Message-ID: <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>

Hi Simon,

 

Sorry for the late response.

 

As you suggested, I?ve tried rtkramp+CUDA with only one projection and it was successfully done for both w/ FFTW and w/o FFTW.

(Two results were exactly same.)

 

Regarding  the CUDA version, I?m using v6.5.

 

Thanks a lot for the help!

 

Yang

 

 

From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit
Sent: Thursday, November 12, 2015 5:59 PM
To: Yang K Park <theday79 at gmail.com>
Cc: rtk-users at openrtk.org
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

Ok. Can you try rtkramp with only one projection? Then you shouldn't encounter this regions issue (that should be solved one day but that's a different story). 

Can you also indicate which version of CUDA you're using?

FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft for the FFT of the projections. So if they are not in the same format, you're in trouble and that might be the issue here... The weird part is that I didn't reproduce this problem on linux (with and without FFTW) but it might be a CUDA version difference. I'll give it another try tomorrow when you provide the CUDA version.

Thanks again for reporting the issue,
Simon

 

On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> > wrote:

Hi Simon,

 

Thanks for the advice. The current RTK was compiled with FFTW to use the phase extraction feature from Amsterdam shroud.

 

Regarding your suggestions,

 

1)      rtkramp w/ or w/o CUDA:

(command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda --output Ramp_wCUDA.mha? )

 

Then, I have encountered following error.

?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that input requested and buffered regions are equal.?

 



 

Without CUDA, it was successfully done.

 

2)      I?ve re-compiled ITK w/o FFTW and built RTK again. rtkfdk worked fine.

-          I?ve also repeated ?rtkramp+CUDA? with this rtk version and the error was same as above.

 

In conclusion, my FFTW seems to affect CUDA-based fdk reconstruction only.

But I do need FFTW for the phase extraction. What should I do?

 

Thanks.

 

Yang

 

 

-----Original Message-----
From: simon.rit at gmail.com <mailto:simon.rit at gmail.com>  [mailto:simon.rit at gmail.com <mailto:simon.rit at gmail.com> ] On Behalf Of Simon Rit
Sent: Wednesday, November 11, 2015 4:16 PM
To: Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> >
Cc: rtk-users at openrtk.org <mailto:rtk-users at openrtk.org> 
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

I didn't manage to reproduce the two problems on linux with the same ITK version.

For point 1, did you copy itkMacro.h by hand? Because I don't see how replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW? It looks like a ramp filter issue. Can you try rtkramp --path projPath --regexp .*.his, with and without --hardware cuda? Maybe you can provide your geometry file in case it's a specific geometric issue.

Simon

 

On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park < <mailto:theday79 at gmail.com> theday79 at gmail.com> wrote:

> Hi all,

> 

> 

> 

> I?ve updated rtk with the up-to-date revision and have encountered a 

> couple of problems.

> 

> 

> 

> 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled

> rtkCudaUtilities.hcu. It was solved by a minor fetching:

> 

> #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu

> 

> 

> 

> 2.       Output of rtkfdk with CUDA was not the same as before. It was very

> blurry as seen in the attached image.

> 

> a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.

> 

> 

> 

> 

> 

> I?m using VS2013 with win7, itk4.8.1.

> 

> 

> 

> The command line I used was :

> 

> rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his 

> --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware 

> cuda --pad 1 --hann 5 --hannY 5

> 

> 

> 

> Does anyone have any idea about this?

> 

> 

> 

> Thanks.

> 

> 

> 

> Yang

> 

> 

> 

> 

> _______________________________________________

> Rtk-users mailing list

>  <mailto: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/20151116/e77c2f96/attachment-0004.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151116/e77c2f96/attachment-0004.png>

From simon.rit at creatis.insa-lyon.fr  Mon Nov 16 10:07:46 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Mon, 16 Nov 2015 16:07:46 +0100
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
 <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
Message-ID: <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>

Hi,
Thanks. It's really weird... When you run the tests with FFTW (compiling
the "test" target), do they fail?
Can you provide your geometry file? It might be specific to this geometry.
Thanks again for looking into this issue, we'll find what's the problem.
Simon

On Mon, Nov 16, 2015 at 3:54 PM, Yang K Park <theday79 at gmail.com> wrote:

> Hi Simon,
>
>
>
> Sorry for the late response.
>
>
>
> As you suggested, I?ve tried rtkramp+CUDA with only one projection and it
> was successfully done for both w/ FFTW and w/o FFTW.
>
> (Two results were exactly same.)
>
>
>
> Regarding  the CUDA version, I?m using v6.5.
>
>
>
> Thanks a lot for the help!
>
>
>
> Yang
>
>
>
>
>
> *From:* simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of *Simon
> Rit
> *Sent:* Thursday, November 12, 2015 5:59 PM
>
> *To:* Yang K Park <theday79 at gmail.com>
> *Cc:* rtk-users at openrtk.org
> *Subject:* Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
> update
>
>
>
> Hi,
>
> Ok. Can you try rtkramp with only one projection? Then you shouldn't
> encounter this regions issue (that should be solved one day but that's a
> different story).
>
> Can you also indicate which version of CUDA you're using?
>
> FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft for
> the FFT of the projections. So if they are not in the same format, you're
> in trouble and that might be the issue here... The weird part is that I
> didn't reproduce this problem on linux (with and without FFTW) but it might
> be a CUDA version difference. I'll give it another try tomorrow when you
> provide the CUDA version.
>
> Thanks again for reporting the issue,
> Simon
>
>
>
> On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com> wrote:
>
> Hi Simon,
>
>
>
> Thanks for the advice. The current RTK was compiled with FFTW to use the
> phase extraction feature from Amsterdam shroud.
>
>
>
> Regarding your suggestions,
>
>
>
> 1)      rtkramp w/ or w/o CUDA:
>
> (command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda
> --output Ramp_wCUDA.mha? )
>
>
>
> Then, I have encountered following error.
>
> ?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that
> input requested and buffered regions are equal.?
>
>
>
>
>
> Without CUDA, it was successfully done.
>
>
>
> 2)      I?ve re-compiled *ITK w/o FFTW* and built RTK again. r*tkfdk
> worked fine.*
>
> -          I?ve also repeated ?rtkramp+CUDA? with this rtk version and
> the error was same as above.
>
>
>
> In conclusion, my *FFTW seems to affect CUDA-based fdk reconstruction
> only*.
>
> But I do need FFTW for the phase extraction. What should I do?
>
>
>
> Thanks.
>
>
>
> Yang
>
>
>
>
>
> -----Original Message-----
> From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon
> Rit
> Sent: Wednesday, November 11, 2015 4:16 PM
> To: Yang K Park <theday79 at gmail.com>
> Cc: rtk-users at openrtk.org
> Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
> update
>
>
>
> Hi,
>
> I didn't manage to reproduce the two problems on linux with the same ITK
> version.
>
> For point 1, did you copy itkMacro.h by hand? Because I don't see how
> replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the
> same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW?
> It looks like a ramp filter issue. Can you try rtkramp --path projPath
> --regexp .*.his, with and without --hardware cuda? Maybe you can provide
> your geometry file in case it's a specific geometric issue.
>
> Simon
>
>
>
> On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
>
> > Hi all,
>
> >
>
> >
>
> >
>
> > I?ve updated rtk with the up-to-date revision and have encountered a
>
> > couple of problems.
>
> >
>
> >
>
> >
>
> > 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
>
> > rtkCudaUtilities.hcu. It was solved by a minor fetching:
>
> >
>
> > #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>
> >
>
> >
>
> >
>
> > 2.       Output of rtkfdk with CUDA was not the same as before. It was
> very
>
> > blurry as seen in the attached image.
>
> >
>
> > a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > I?m using VS2013 with win7, itk4.8.1.
>
> >
>
> >
>
> >
>
> > The command line I used was :
>
> >
>
> > rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his
>
> > --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware
>
> > cuda --pad 1 --hann 5 --hannY 5
>
> >
>
> >
>
> >
>
> > Does anyone have any idea about this?
>
> >
>
> >
>
> >
>
> > Thanks.
>
> >
>
> >
>
> >
>
> > Yang
>
> >
>
> >
>
> >
>
> >
>
> > _______________________________________________
>
> > 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/20151116/38acfca5/attachment-0004.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151116/38acfca5/attachment-0004.png>

From theday79 at gmail.com  Mon Nov 16 10:47:43 2015
From: theday79 at gmail.com (Yang-Kyun Park)
Date: Mon, 16 Nov 2015 10:47:43 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
 <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
 <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>
Message-ID: <CAJM7=xjBjx=FzLazWJWqJbV5d45zGi2U71NKejm9HxKhJ0-xLQ@mail.gmail.com>

Hi Simon,

For better understanding, I'm attaching the problematic case including
projection files, geometry file(xml) and reconstructed images.(please find
the GDrive links. The file size is ~800 MB)
This is phantom data and there is no patient information in it.

Regarding the fftw library, I'm using [fftw-3.3.4-dll64].

By the way, I found another clue. When I've tried it with a head phantom
image (full-fan, ~ 190 projections), there was no problem. Is there any
possibility that DDF and parker short filter play some roles on this issue?

Feel free to let me know if further data is needed.

Thanks!

Yang

?
 FFTW_issue.zip
<https://drive.google.com/file/d/0BxuP3mON9V-qbVdQd0luc1lIb2M/view?usp=drive_web>
?

On Mon, Nov 16, 2015 at 10:07 AM, Simon Rit <simon.rit at creatis.insa-lyon.fr>
wrote:

> Hi,
> Thanks. It's really weird... When you run the tests with FFTW (compiling
> the "test" target), do they fail?
> Can you provide your geometry file? It might be specific to this geometry.
> Thanks again for looking into this issue, we'll find what's the problem.
> Simon
>
> On Mon, Nov 16, 2015 at 3:54 PM, Yang K Park <theday79 at gmail.com> wrote:
>
>> Hi Simon,
>>
>>
>>
>> Sorry for the late response.
>>
>>
>>
>> As you suggested, I?ve tried rtkramp+CUDA with only one projection and it
>> was successfully done for both w/ FFTW and w/o FFTW.
>>
>> (Two results were exactly same.)
>>
>>
>>
>> Regarding  the CUDA version, I?m using v6.5.
>>
>>
>>
>> Thanks a lot for the help!
>>
>>
>>
>> Yang
>>
>>
>>
>>
>>
>> *From:* simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of *Simon
>> Rit
>> *Sent:* Thursday, November 12, 2015 5:59 PM
>>
>> *To:* Yang K Park <theday79 at gmail.com>
>> *Cc:* rtk-users at openrtk.org
>> *Subject:* Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
>> update
>>
>>
>>
>> Hi,
>>
>> Ok. Can you try rtkramp with only one projection? Then you shouldn't
>> encounter this regions issue (that should be solved one day but that's a
>> different story).
>>
>> Can you also indicate which version of CUDA you're using?
>>
>> FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft
>> for the FFT of the projections. So if they are not in the same format,
>> you're in trouble and that might be the issue here... The weird part is
>> that I didn't reproduce this problem on linux (with and without FFTW) but
>> it might be a CUDA version difference. I'll give it another try tomorrow
>> when you provide the CUDA version.
>>
>> Thanks again for reporting the issue,
>> Simon
>>
>>
>>
>> On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com> wrote:
>>
>> Hi Simon,
>>
>>
>>
>> Thanks for the advice. The current RTK was compiled with FFTW to use the
>> phase extraction feature from Amsterdam shroud.
>>
>>
>>
>> Regarding your suggestions,
>>
>>
>>
>> 1)      rtkramp w/ or w/o CUDA:
>>
>> (command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda
>> --output Ramp_wCUDA.mha? )
>>
>>
>>
>> Then, I have encountered following error.
>>
>> ?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that
>> input requested and buffered regions are equal.?
>>
>>
>>
>>
>>
>> Without CUDA, it was successfully done.
>>
>>
>>
>> 2)      I?ve re-compiled *ITK w/o FFTW* and built RTK again. r*tkfdk
>> worked fine.*
>>
>> -          I?ve also repeated ?rtkramp+CUDA? with this rtk version and
>> the error was same as above.
>>
>>
>>
>> In conclusion, my *FFTW seems to affect CUDA-based fdk reconstruction
>> only*.
>>
>> But I do need FFTW for the phase extraction. What should I do?
>>
>>
>>
>> Thanks.
>>
>>
>>
>> Yang
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of
>> Simon Rit
>> Sent: Wednesday, November 11, 2015 4:16 PM
>> To: Yang K Park <theday79 at gmail.com>
>> Cc: rtk-users at openrtk.org
>> Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
>> update
>>
>>
>>
>> Hi,
>>
>> I didn't manage to reproduce the two problems on linux with the same ITK
>> version.
>>
>> For point 1, did you copy itkMacro.h by hand? Because I don't see how
>> replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the
>> same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW?
>> It looks like a ramp filter issue. Can you try rtkramp --path projPath
>> --regexp .*.his, with and without --hardware cuda? Maybe you can provide
>> your geometry file in case it's a specific geometric issue.
>>
>> Simon
>>
>>
>>
>> On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
>>
>> > Hi all,
>>
>> >
>>
>> >
>>
>> >
>>
>> > I?ve updated rtk with the up-to-date revision and have encountered a
>>
>> > couple of problems.
>>
>> >
>>
>> >
>>
>> >
>>
>> > 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
>>
>> > rtkCudaUtilities.hcu. It was solved by a minor fetching:
>>
>> >
>>
>> > #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>>
>> >
>>
>> >
>>
>> >
>>
>> > 2.       Output of rtkfdk with CUDA was not the same as before. It was
>> very
>>
>> > blurry as seen in the attached image.
>>
>> >
>>
>> > a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>
>> > I?m using VS2013 with win7, itk4.8.1.
>>
>> >
>>
>> >
>>
>> >
>>
>> > The command line I used was :
>>
>> >
>>
>> > rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his
>>
>> > --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware
>>
>> > cuda --pad 1 --hann 5 --hannY 5
>>
>> >
>>
>> >
>>
>> >
>>
>> > Does anyone have any idea about this?
>>
>> >
>>
>> >
>>
>> >
>>
>> > Thanks.
>>
>> >
>>
>> >
>>
>> >
>>
>> > Yang
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>
>> > _______________________________________________
>>
>> > 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/20151116/90d2c5a0/attachment-0004.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151116/90d2c5a0/attachment-0004.png>

From simon.rit at creatis.insa-lyon.fr  Fri Nov 20 11:28:22 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Fri, 20 Nov 2015 17:28:22 +0100
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAJM7=xjBjx=FzLazWJWqJbV5d45zGi2U71NKejm9HxKhJ0-xLQ@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
 <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
 <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>
 <CAJM7=xjBjx=FzLazWJWqJbV5d45zGi2U71NKejm9HxKhJ0-xLQ@mail.gmail.com>
Message-ID: <CAF0oig027_u_9gb8bnwT1w9jr3epZ0hkd9Mt73qK5heUq_kCkg@mail.gmail.com>

Hi Yang,
Thanks a lot for sharing the data. I have good news. I could reproduce the
bug and I have solutions. First, about your dataset: it's a huge dataset
and the hannY requires zero padding in both x and y. Because of this, cufft
has to take the 2D FFT of projection subsets that are 4095x2048x16. Quite
big!
When I ran it on my cuda 7.0, I immediately got:

itk::ExceptionObject (0x8b9cb30)
Location: "void CUDA_fft_convolution(const int3&, const int2&, float*,
cufftComplex*)"
File: /home/srit/src/rtk/rtk/code/rtkCudaFFTConvolutionImageFilter.cu
Line: 97
Description: itk::ERROR: CUFFT ERROR #2

i.e., a GPU alloc issue, even if I have the largest possible memory on a
nvidia desktop computer. Then, I ran it with cuda 6.5 and I got no error
message but a result similar to yours.
Conclusions:
- if you add the option --subsetsize 1 to your rtkfdk command line, that
should reconstruct correctly
- if you upgrade cuda, you should get an understandable error message,
- I don't think I'm going to look for a solution because the pb is probably
in cufft but if someone is willing to, be my guest!
Simon

On Mon, Nov 16, 2015 at 4:47 PM, Yang-Kyun Park <theday79 at gmail.com> wrote:

> Hi Simon,
>
> For better understanding, I'm attaching the problematic case including
> projection files, geometry file(xml) and reconstructed images.(please find
> the GDrive links. The file size is ~800 MB)
> This is phantom data and there is no patient information in it.
>
> Regarding the fftw library, I'm using [fftw-3.3.4-dll64].
>
> By the way, I found another clue. When I've tried it with a head phantom
> image (full-fan, ~ 190 projections), there was no problem. Is there any
> possibility that DDF and parker short filter play some roles on this issue?
>
> Feel free to let me know if further data is needed.
>
> Thanks!
>
> Yang
>
> ?
>  FFTW_issue.zip
> <https://drive.google.com/file/d/0BxuP3mON9V-qbVdQd0luc1lIb2M/view?usp=drive_web>
> ?
>
> On Mon, Nov 16, 2015 at 10:07 AM, Simon Rit <
> simon.rit at creatis.insa-lyon.fr> wrote:
>
>> Hi,
>> Thanks. It's really weird... When you run the tests with FFTW (compiling
>> the "test" target), do they fail?
>> Can you provide your geometry file? It might be specific to this geometry.
>> Thanks again for looking into this issue, we'll find what's the problem.
>> Simon
>>
>> On Mon, Nov 16, 2015 at 3:54 PM, Yang K Park <theday79 at gmail.com> wrote:
>>
>>> Hi Simon,
>>>
>>>
>>>
>>> Sorry for the late response.
>>>
>>>
>>>
>>> As you suggested, I?ve tried rtkramp+CUDA with only one projection and
>>> it was successfully done for both w/ FFTW and w/o FFTW.
>>>
>>> (Two results were exactly same.)
>>>
>>>
>>>
>>> Regarding  the CUDA version, I?m using v6.5.
>>>
>>>
>>>
>>> Thanks a lot for the help!
>>>
>>>
>>>
>>> Yang
>>>
>>>
>>>
>>>
>>>
>>> *From:* simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of *Simon
>>> Rit
>>> *Sent:* Thursday, November 12, 2015 5:59 PM
>>>
>>> *To:* Yang K Park <theday79 at gmail.com>
>>> *Cc:* rtk-users at openrtk.org
>>> *Subject:* Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
>>> update
>>>
>>>
>>>
>>> Hi,
>>>
>>> Ok. Can you try rtkramp with only one projection? Then you shouldn't
>>> encounter this regions issue (that should be solved one day but that's a
>>> different story).
>>>
>>> Can you also indicate which version of CUDA you're using?
>>>
>>> FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft
>>> for the FFT of the projections. So if they are not in the same format,
>>> you're in trouble and that might be the issue here... The weird part is
>>> that I didn't reproduce this problem on linux (with and without FFTW) but
>>> it might be a CUDA version difference. I'll give it another try tomorrow
>>> when you provide the CUDA version.
>>>
>>> Thanks again for reporting the issue,
>>> Simon
>>>
>>>
>>>
>>> On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com>
>>> wrote:
>>>
>>> Hi Simon,
>>>
>>>
>>>
>>> Thanks for the advice. The current RTK was compiled with FFTW to use the
>>> phase extraction feature from Amsterdam shroud.
>>>
>>>
>>>
>>> Regarding your suggestions,
>>>
>>>
>>>
>>> 1)      rtkramp w/ or w/o CUDA:
>>>
>>> (command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda
>>> --output Ramp_wCUDA.mha? )
>>>
>>>
>>>
>>> Then, I have encountered following error.
>>>
>>> ?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that
>>> input requested and buffered regions are equal.?
>>>
>>>
>>>
>>>
>>>
>>> Without CUDA, it was successfully done.
>>>
>>>
>>>
>>> 2)      I?ve re-compiled *ITK w/o FFTW* and built RTK again. r*tkfdk
>>> worked fine.*
>>>
>>> -          I?ve also repeated ?rtkramp+CUDA? with this rtk version and
>>> the error was same as above.
>>>
>>>
>>>
>>> In conclusion, my *FFTW seems to affect CUDA-based fdk reconstruction
>>> only*.
>>>
>>> But I do need FFTW for the phase extraction. What should I do?
>>>
>>>
>>>
>>> Thanks.
>>>
>>>
>>>
>>> Yang
>>>
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of
>>> Simon Rit
>>> Sent: Wednesday, November 11, 2015 4:16 PM
>>> To: Yang K Park <theday79 at gmail.com>
>>> Cc: rtk-users at openrtk.org
>>> Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
>>> update
>>>
>>>
>>>
>>> Hi,
>>>
>>> I didn't manage to reproduce the two problems on linux with the same ITK
>>> version.
>>>
>>> For point 1, did you copy itkMacro.h by hand? Because I don't see how
>>> replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the
>>> same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW?
>>> It looks like a ramp filter issue. Can you try rtkramp --path projPath
>>> --regexp .*.his, with and without --hardware cuda? Maybe you can provide
>>> your geometry file in case it's a specific geometric issue.
>>>
>>> Simon
>>>
>>>
>>>
>>> On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
>>>
>>> > Hi all,
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > I?ve updated rtk with the up-to-date revision and have encountered a
>>>
>>> > couple of problems.
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
>>>
>>> > rtkCudaUtilities.hcu. It was solved by a minor fetching:
>>>
>>> >
>>>
>>> > #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > 2.       Output of rtkfdk with CUDA was not the same as before. It was
>>> very
>>>
>>> > blurry as seen in the attached image.
>>>
>>> >
>>>
>>> > a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > I?m using VS2013 with win7, itk4.8.1.
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > The command line I used was :
>>>
>>> >
>>>
>>> > rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his
>>>
>>> > --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware
>>>
>>> > cuda --pad 1 --hann 5 --hannY 5
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > Does anyone have any idea about this?
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > Thanks.
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > Yang
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > _______________________________________________
>>>
>>> > 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/20151120/4e6c0e1e/attachment-0004.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151120/4e6c0e1e/attachment-0004.png>

From theday79 at gmail.com  Fri Nov 20 12:36:51 2015
From: theday79 at gmail.com (Yang K Park)
Date: Fri, 20 Nov 2015 12:36:51 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAF0oig027_u_9gb8bnwT1w9jr3epZ0hkd9Mt73qK5heUq_kCkg@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
 <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
 <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>
 <CAJM7=xjBjx=FzLazWJWqJbV5d45zGi2U71NKejm9HxKhJ0-xLQ@mail.gmail.com>
 <CAF0oig027_u_9gb8bnwT1w9jr3epZ0hkd9Mt73qK5heUq_kCkg@mail.gmail.com>
Message-ID: <000901d123ba$0ae3de50$20ab9af0$@gmail.com>

Hi Simon,

 

That sounds great! Thanks a lot for your hard work.

As you said, now I can reconstruct it successfully with --subsetsize option.

 

I think the only concern left is the elongated reconstruction time.

I?ve measured it for the same phantom image with different ?subsetsize? values as well as w/o FFTW compiling.

I just report it for your information.

 

1)      w/o FFTW  : 21.4 s

2)      w/ FFTW & --subsetsize 1: 89 s

3)      w/ FFTW & --subsetsize 2: 77 s

4)      w/ FFTW & --subsetsize 4: 65 s

5)      w/ FFTW & --subsetsize 6: 51 s

6)      w/ FFTW & --subsetsize 7: (Error-graphic card seemed to be freezed)

7)      w/ FFTW & --subsetsize 8: (Error-?itk::ERROR: CUFFT ERROR #2 in rtkCudaFFTConvolutionImageFilter.cu?)

 

Of course, the difference was coming from the Ramp filter.

Therefore, I?m going to use [--subsetsize 6] for my system and will update CUDA version soon!

 

Thanks.

 

Yang

 

 

From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit
Sent: Friday, November 20, 2015 11:28 AM
To: Yang-Kyun Park <theday79 at gmail.com>
Cc: rtk-users at openrtk.org
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi Yang,
Thanks a lot for sharing the data. I have good news. I could reproduce the bug and I have solutions. First, about your dataset: it's a huge dataset and the hannY requires zero padding in both x and y. Because of this, cufft has to take the 2D FFT of projection subsets that are 4095x2048x16. Quite big!

When I ran it on my cuda 7.0, I immediately got:

itk::ExceptionObject (0x8b9cb30)
Location: "void CUDA_fft_convolution(const int3&, const int2&, float*, cufftComplex*)" 
File: /home/srit/src/rtk/rtk/code/rtkCudaFFTConvolutionImageFilter.cu
Line: 97
Description: itk::ERROR: CUFFT ERROR #2

i.e., a GPU alloc issue, even if I have the largest possible memory on a nvidia desktop computer. Then, I ran it with cuda 6.5 and I got no error message but a result similar to yours.

Conclusions:

- if you add the option --subsetsize 1 to your rtkfdk command line, that should reconstruct correctly

- if you upgrade cuda, you should get an understandable error message,

- I don't think I'm going to look for a solution because the pb is probably in cufft but if someone is willing to, be my guest!

Simon

 

On Mon, Nov 16, 2015 at 4:47 PM, Yang-Kyun Park <theday79 at gmail.com <mailto:theday79 at gmail.com> > wrote:

Hi Simon,

 

For better understanding, I'm attaching the problematic case including projection files, geometry file(xml) and reconstructed images.(please find the GDrive links. The file size is ~800 MB)

This is phantom data and there is no patient information in it.

 

Regarding the fftw library, I'm using [fftw-3.3.4-dll64].

 

By the way, I found another clue. When I've tried it with a head phantom image (full-fan, ~ 190 projections), there was no problem. Is there any possibility that DDF and parker short filter play some roles on this issue?

 

Feel free to let me know if further data is needed.

 

Thanks!

 

Yang

 

?

 <https://drive.google.com/file/d/0BxuP3mON9V-qbVdQd0luc1lIb2M/view?usp=drive_web>  FFTW_issue.zip

?

 

On Mon, Nov 16, 2015 at 10:07 AM, Simon Rit <simon.rit at creatis.insa-lyon.fr <mailto:simon.rit at creatis.insa-lyon.fr> > wrote:

Hi,

Thanks. It's really weird... When you run the tests with FFTW (compiling the "test" target), do they fail?
Can you provide your geometry file? It might be specific to this geometry.

Thanks again for looking into this issue, we'll find what's the problem.

Simon

 

On Mon, Nov 16, 2015 at 3:54 PM, Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> > wrote:

Hi Simon,

 

Sorry for the late response.

 

As you suggested, I?ve tried rtkramp+CUDA with only one projection and it was successfully done for both w/ FFTW and w/o FFTW.

(Two results were exactly same.)

 

Regarding  the CUDA version, I?m using v6.5.

 

Thanks a lot for the help!

 

Yang

 

 

From: simon.rit at gmail.com <mailto:simon.rit at gmail.com>  [mailto:simon.rit at gmail.com <mailto:simon.rit at gmail.com> ] On Behalf Of Simon Rit
Sent: Thursday, November 12, 2015 5:59 PM


To: Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> >
Cc: rtk-users at openrtk.org <mailto:rtk-users at openrtk.org> 
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

Ok. Can you try rtkramp with only one projection? Then you shouldn't encounter this regions issue (that should be solved one day but that's a different story). 

Can you also indicate which version of CUDA you're using?

FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft for the FFT of the projections. So if they are not in the same format, you're in trouble and that might be the issue here... The weird part is that I didn't reproduce this problem on linux (with and without FFTW) but it might be a CUDA version difference. I'll give it another try tomorrow when you provide the CUDA version.

Thanks again for reporting the issue,
Simon

 

On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> > wrote:

Hi Simon,

 

Thanks for the advice. The current RTK was compiled with FFTW to use the phase extraction feature from Amsterdam shroud.

 

Regarding your suggestions,

 

1)      rtkramp w/ or w/o CUDA:

(command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda --output Ramp_wCUDA.mha? )

 

Then, I have encountered following error.

?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that input requested and buffered regions are equal.?

 



 

Without CUDA, it was successfully done.

 

2)      I?ve re-compiled ITK w/o FFTW and built RTK again. rtkfdk worked fine.

-          I?ve also repeated ?rtkramp+CUDA? with this rtk version and the error was same as above.

 

In conclusion, my FFTW seems to affect CUDA-based fdk reconstruction only.

But I do need FFTW for the phase extraction. What should I do?

 

Thanks.

 

Yang

 

 

-----Original Message-----
From: simon.rit at gmail.com <mailto:simon.rit at gmail.com>  [mailto:simon.rit at gmail.com <mailto:simon.rit at gmail.com> ] On Behalf Of Simon Rit
Sent: Wednesday, November 11, 2015 4:16 PM
To: Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> >
Cc: rtk-users at openrtk.org <mailto:rtk-users at openrtk.org> 
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

I didn't manage to reproduce the two problems on linux with the same ITK version.

For point 1, did you copy itkMacro.h by hand? Because I don't see how replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW? It looks like a ramp filter issue. Can you try rtkramp --path projPath --regexp .*.his, with and without --hardware cuda? Maybe you can provide your geometry file in case it's a specific geometric issue.

Simon

 

On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park < <mailto:theday79 at gmail.com> theday79 at gmail.com> wrote:

> Hi all,

> 

> 

> 

> I?ve updated rtk with the up-to-date revision and have encountered a 

> couple of problems.

> 

> 

> 

> 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled

> rtkCudaUtilities.hcu. It was solved by a minor fetching:

> 

> #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu

> 

> 

> 

> 2.       Output of rtkfdk with CUDA was not the same as before. It was very

> blurry as seen in the attached image.

> 

> a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.

> 

> 

> 

> 

> 

> I?m using VS2013 with win7, itk4.8.1.

> 

> 

> 

> The command line I used was :

> 

> rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his 

> --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware 

> cuda --pad 1 --hann 5 --hannY 5

> 

> 

> 

> Does anyone have any idea about this?

> 

> 

> 

> Thanks.

> 

> 

> 

> Yang

> 

> 

> 

> 

> _______________________________________________

> Rtk-users mailing list

>  <mailto: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/20151120/0d98ace1/attachment-0004.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151120/0d98ace1/attachment-0004.png>

From simon.rit at creatis.insa-lyon.fr  Wed Nov 25 02:36:44 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Wed, 25 Nov 2015 08:36:44 +0100
Subject: [Rtk-users] Compiling Problem
In-Reply-To: <040e01d125c7$83648e60$8a2dab20$@126.com>
References: <040e01d125c7$83648e60$8a2dab20$@126.com>
Message-ID: <5655650C.1040500@creatis.insa-lyon.fr>

Hi,
Please use the mailing list. I don't know where does the linking problem 
come from and it seems to work on our side:
http://my.cdash.org/index.php?project=RTK
Have you tried disabling CUDA?
Simon

On 23/11/2015 09:18, Freyman li wrote:
>
> Dear Simon,
>
> Recently I configured the RTK tool and suffer some problems. After set 
> up the itk tool and cuda, I compiled the rtk application but 
> encountered two errors attached to the email(jpg format)
>
> CUDA and ITK environment are tested successfully. My compile tool is 
> Visual studio 2012(64bit) and CUDA version is v6.5.
>
> Can you tell me how to deal with it and I am looking forward to hear 
> you again.
>
> Thank you!
>
> Best Regards
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151125/285f7f3c/attachment-0004.html>

From theday79 at gmail.com  Wed Nov 25 12:38:52 2015
From: theday79 at gmail.com (Yang K Park)
Date: Wed, 25 Nov 2015 12:38:52 -0500
Subject: [Rtk-users] Compiling Problem
In-Reply-To: <5655650C.1040500@creatis.insa-lyon.fr>
References: <040e01d125c7$83648e60$8a2dab20$@126.com>
 <5655650C.1040500@creatis.insa-lyon.fr>
Message-ID: <003d01d127a8$27a52b60$76ef8220$@gmail.com>

Hi Freyman,

 

I think your setting is much similar to mine, since I have compiled RTK with
VS2013 and CUDA v6.5 several times. Can you post those error messages again
so that I can see?

Yang

 

 

From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of
Simon Rit
Sent: Wednesday, November 25, 2015 2:37 AM
To: Freyman li <lihanwei_1500 at 126.com>
Cc: rtk-users at openrtk.org
Subject: Re: [Rtk-users] Compiling Problem

 

Hi,
Please use the mailing list. I don't know where does the linking problem
come from and it seems to work on our side:
http://my.cdash.org/index.php?project=RTK
Have you tried disabling CUDA?
Simon

On 23/11/2015 09:18, Freyman li wrote:

Dear Simon,

 

Recently I configured the RTK tool and suffer some problems. After set up
the itk tool and cuda, I compiled the rtk application but encountered two
errors attached to the email(jpg format)

CUDA and ITK environment are tested successfully. My compile tool is Visual
studio 2012(64bit) and CUDA version is v6.5.

Can you tell me how to deal with it and I am looking forward to hear you
again.

Thank you!

 

Best Regards

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151125/984feb50/attachment-0004.html>

From bioniloofar at gmail.com  Mon Nov 30 06:06:41 2015
From: bioniloofar at gmail.com (niloufar teyfouri)
Date: Mon, 30 Nov 2015 14:36:41 +0330
Subject: [Rtk-users] ElectaReconstruction
Message-ID: <CALChM12F4PuiLvgENg3Yyn7E+uZ7iPJ+GiY04z7VQ-90AS83EA@mail.gmail.com>

I ran the application of Electa Reconstruction implemented by you with
RTK. But after debugging I was encountered with the message of
"--output' ('-o') option required". Could you please help me for running
this example and the other ones?
I don't know any thing about the texts in the gray boxes mentioned at
each link related to examples of RTK.
For example in the link of
http://wiki.openrtk.org/index.php/RTK/Examples/ElektaReconstruction
how I should use gengetopt for the instructions below?


2. Run the application to convert Elekta's geometry into RTKs (DICOM_UID
is contained in the subfolder name of the his files):

  rtkelektasynergygeometry \
    --image_db IMAGE.DBF \
    --frame_db FRAME.DBF \
    --dicom_uid 1.3.46.423632.135428.1351013645.166 \
    -o elektaGeometry

I would be appreciate if one could answer my question.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151130/b11ad4e2/attachment-0004.html>

From cyril.mory at uclouvain.be  Mon Nov 30 09:30:48 2015
From: cyril.mory at uclouvain.be (Cyril Mory)
Date: Mon, 30 Nov 2015 15:30:48 +0100
Subject: [Rtk-users] ElectaReconstruction
In-Reply-To: <CALChM12F4PuiLvgENg3Yyn7E+uZ7iPJ+GiY04z7VQ-90AS83EA@mail.gmail.com>
References: <CALChM12F4PuiLvgENg3Yyn7E+uZ7iPJ+GiY04z7VQ-90AS83EA@mail.gmail.com>
Message-ID: <565C5D98.1000309@uclouvain.be>

Hi, and welcome to RTK,

Gengetopt is the piece of software that parses the command line 
arguments in all RTK applications. You do not have to "use" it. You just 
need to give correct arguments on the command line.

The message "--output' ('-o') option required" means what it says : you 
need to provide the name of the file in which you want to store the 
geometry information generated by the application 
rtkelektasynergygeometry. If you just copy-pasted the command you found 
on the wiki, then something went wrong during the copy-paste. Try to run 
the following :

rtkelektasynergygeometry --image_db IMAGE.DBF --frame_db FRAME.DBF 
--dicom_uid 1.3.46.423632.135428.1351013645.166 -o elektaGeometry

I just removed the '\' and the useless spaces. You can do the same for 
all other command line examples and it should work.

Let us know if you keep encountering trouble.
Cyril


Le 30/11/2015 12:06, niloufar teyfouri a ?crit :
>
> I ran the application of Electa Reconstruction implemented by you with
> RTK. But after debugging I was encountered with the message of
> "--output' ('-o') option required". Could you please help me for running
> this example and the other ones?
> I don't know any thing about the texts in the gray boxes mentioned at
> each link related to examples of RTK.
> For example in the link of
> http://wiki.openrtk.org/index.php/RTK/Examples/ElektaReconstruction
> how I should use gengetopt for the instructions below?
>
>
> 2. Run the application to convert Elekta's geometry into RTKs (DICOM_UID
> is contained in the subfolder name of the his files):
>
> rtkelektasynergygeometry \
> --image_db IMAGE.DBF \
> --frame_db FRAME.DBF \
> --dicom_uid 1.3.46.423632.135428.1351013645.166 \
>     -o elektaGeometry
>
> I would be appreciate if one could answer my question.
>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151130/66741755/attachment-0004.html>

From j.mason at ed.ac.uk  Mon Nov 30 11:29:27 2015
From: j.mason at ed.ac.uk (Jonathan Mason)
Date: Mon, 30 Nov 2015 16:29:27 +0000
Subject: [Rtk-users] Preprocessing
Message-ID: <565C7967.4000401@ed.ac.uk>

Good afternoon RTK users,

I have access to "raw data" from a Varian OBI scanner, and have
experimented with RTK for performing its reconstruction. However, it is
not really "raw" in the sense that the coefficients are proportional to
the photon flux recorded at a given sensor, but is instead proportional
to the Hounsfield attenuation along that path. With this data, it means
that one can reconstruct using FDK and other iterative techniques, which
assume a linear model, but the connection to the underlying physics is
abstract.

The problem I then have when trying to develop reconstruction
techniques, is that I do not know whether I am really correcting for
physical distortions or just correcting for Varian's preprocessing,
which has been finely tuned for its own FDK method.

My question is whether anybody has dug into the steps that manufacturers
such as Varian or Elekta perform to arrive at these projection images?
And if they think that if reverse engineered, could provide a richer set
of information to facilitate advanced strategies.

Best wishes,

Jonathan Mason

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.



From simon.rit at creatis.insa-lyon.fr  Mon Nov 30 12:44:03 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Mon, 30 Nov 2015 18:44:03 +0100
Subject: [Rtk-users] ElectaReconstruction
In-Reply-To: <565C5D98.1000309@uclouvain.be>
References: <CALChM12F4PuiLvgENg3Yyn7E+uZ7iPJ+GiY04z7VQ-90AS83EA@mail.gmail.com>
 <565C5D98.1000309@uclouvain.be>
Message-ID: <CAF0oig2Zg96AZaRn9w9=F+LnLnyteTn5zS1rLguQ8WXiYhnnYg@mail.gmail.com>

Hi,
I think Cyril is right, it's not possible to use backslashes to put a
command line on several line with Windows command line. Can you confirm
this? If you confirm, we will correct the wiki.
Thanks,
Simon

On Mon, Nov 30, 2015 at 3:30 PM, Cyril Mory <cyril.mory at uclouvain.be> wrote:

> Hi, and welcome to RTK,
>
> Gengetopt is the piece of software that parses the command line arguments
> in all RTK applications. You do not have to "use" it. You just need to give
> correct arguments on the command line.
>
> The message "--output' ('-o') option required" means what it says : you
> need to provide the name of the file in which you want to store the
> geometry information generated by the application rtkelektasynergygeometry.
> If you just copy-pasted the command you found on the wiki, then something
> went wrong during the copy-paste. Try to run the following :
>
> rtkelektasynergygeometry --image_db IMAGE.DBF --frame_db FRAME.DBF
> --dicom_uid 1.3.46.423632.135428.1351013645.166 -o elektaGeometry
>
> I just removed the '\' and the useless spaces. You can do the same for all
> other command line examples and it should work.
>
> Let us know if you keep encountering trouble.
> Cyril
>
>
>
> Le 30/11/2015 12:06, niloufar teyfouri a ?crit :
>
>
> I ran the application of Electa Reconstruction implemented by you with
> RTK. But after debugging I was encountered with the message of
> "--output' ('-o') option required". Could you please help me for running
> this example and the other ones?
> I don't know any thing about the texts in the gray boxes mentioned at
> each link related to examples of RTK.
> For example in the link of
> http://wiki.openrtk.org/index.php/RTK/Examples/ElektaReconstruction
> how I should use gengetopt for the instructions below?
>
>
> 2. Run the application to convert Elekta's geometry into RTKs (DICOM_UID
> is contained in the subfolder name of the his files):
>
>   rtkelektasynergygeometry \
>     --image_db IMAGE.DBF \
>     --frame_db FRAME.DBF \
>     --dicom_uid 1.3.46.423632.135428.1351013645.166 \
>     -o elektaGeometry
>
> I would be appreciate if one could answer my question.
>
>
> _______________________________________________
> Rtk-users mailing listRtk-users at public.kitware.comhttp://public.kitware.com/mailman/listinfo/rtk-users
>
>
>
>
> ------------------------------
> [image: Avast logo] <https://www.avast.com/antivirus>
>
> L'absence de virus dans ce courrier ?lectronique a ?t? v?rifi?e par le
> logiciel antivirus Avast.
> www.avast.com <https://www.avast.com/antivirus>
>
>
> _______________________________________________
> 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/20151130/6d6dd6aa/attachment-0004.html>

From wuchao04 at gmail.com  Mon Nov 30 13:50:06 2015
From: wuchao04 at gmail.com (Chao Wu)
Date: Mon, 30 Nov 2015 19:50:06 +0100
Subject: [Rtk-users] Preprocessing
In-Reply-To: <565C7967.4000401@ed.ac.uk>
References: <565C7967.4000401@ed.ac.uk>
Message-ID: <CAH+sHrUFov5f=8h4-ePhC2xLraM3BxA9r12yfXdM3rrKPeqCBg@mail.gmail.com>

Hi Jonathan,

I do not quite understand your problem.
I think most information can be retrieved by the relationship between flux
(I) and attenuation (u):
I = I0 * exp (- integral(u * dL) )
Of course there are other effects like beam hardening and scattering
involved but this model is the basic.

Regards,
Chao

2015-11-30 17:29 GMT+01:00 Jonathan Mason <j.mason at ed.ac.uk>:

> Good afternoon RTK users,
>
> I have access to "raw data" from a Varian OBI scanner, and have
> experimented with RTK for performing its reconstruction. However, it is
> not really "raw" in the sense that the coefficients are proportional to
> the photon flux recorded at a given sensor, but is instead proportional
> to the Hounsfield attenuation along that path. With this data, it means
> that one can reconstruct using FDK and other iterative techniques, which
> assume a linear model, but the connection to the underlying physics is
> abstract.
>
> The problem I then have when trying to develop reconstruction
> techniques, is that I do not know whether I am really correcting for
> physical distortions or just correcting for Varian's preprocessing,
> which has been finely tuned for its own FDK method.
>
> My question is whether anybody has dug into the steps that manufacturers
> such as Varian or Elekta perform to arrive at these projection images?
> And if they think that if reverse engineered, could provide a richer set
> of information to facilitate advanced strategies.
>
> Best wishes,
>
> Jonathan Mason
>
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
> _______________________________________________
> 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/20151130/ccb833fe/attachment-0004.html>

From mdupont at cppm.in2p3.fr  Sun Nov  1 12:41:49 2015
From: mdupont at cppm.in2p3.fr (Mathieu Dupont)
Date: Sun, 01 Nov 2015 18:41:49 +0100
Subject: [Rtk-users] question about rtkDraw*ImageFilter
In-Reply-To: <56334CF2.8070902@cppm.in2p3.fr>
References: <5630EE01.5070900@cppm.in2p3.fr>
 <CAF0oig279ZWGJMFnJdXaPiYLPponadz_J-PVKt2z3iHiTRQ_gg@mail.gmail.com>
 <56334CF2.8070902@cppm.in2p3.fr>
Message-ID: <1539144.WPSdtJ8lhZ@marabunta>

Hello Simon, 

I started to implement what I suggested : 

https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawImageFilter.h
and 
https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawCylinderImageFilter.h

rtk::DrawCylinderImageFilter derives from rtk::DrawImageFilter and specializes 
it (by defaulting the template parameter TSpatialObject with 
DrawCylinderSpatialObject). 

By default, DrawCylinderImageFilter uses Add2 for filling output image (to be 
backward compatible (all tests pass)). I created Discard (I did not find 
equivalent in itk) functor in order to do what I wanted in my first email.  

I just implemented DrawCylinderImageFilter, the others will follow. 

What do you think about it ?

Le vendredi 30 octobre 2015, 11:56:50 Mathieu Dupont a ?crit :
> Hi,
> 
> In case of your first solution, you can not chain several
> Draw*ImageFilters. For example, if you want to create small cylinders in
> a big cylinder.
> 
> Your second solution is better.
> 
> One another solution can be a thing like itk:SpatialObject but more
> simpler. An rtk::SpatialObject which one function (isInside(point)). We
> create a rtkDrawImageFilter class and implement ThreadedGenerateData
> like this :
> 
> DrawImageFilter<InImage, OutImage, rtkSpatialObject,
> rtkFillFunctor>::ThreadedGenerateData(const OutputImageRegionType&
> outputRegionForThread,                 ThreadIdType itkNotUsed(threadId)
> {
> ...
> 
>   while( !itOut.IsAtEnd() )
>      {
>      this->GetInput()->TransformIndexToPhysicalPoint(itOut.GetIndex(),
> point);
> 
>     if(m_rtkSpatialObject.isInside(point)
>       itOut.Set(m_rtkFillFunctor(density, itIn.Get());
> ...
> }
> 
> 
> DrawConeImageFilter class can be a child of this new DrawImageFilter
> (with new methods like setAngle, SetRadius which will adjust the
> rtkConeSpatialObject)
> 
> This solution suppress duplicated code in
> Draw*ImageFilter::ThreadedGenerateData and makes easier implementation
> of another type of filling.
> 
> On 28/10/2015 20:52, Simon Rit wrote:
> > Hi Mathieu,
> > Thanks for pointing this out. I agree that it might not be the best
> > solution, yet one could argue that you could simply create a constant
> > image with 0 to do what you'd like from the current implementation. My
> > main problem is that I just tried to do what you suggest and some tests
> > then fail... which shows the obvious, it's not a backward compatible
> > change. I see two solutions:
> > - keep it as is and you use ConstantImageFilter + we remove useless add
> > filters,
> > - a more complex but maybe more elegant solution: add a third template
> > parameter for the operation that would allow the user to do what he'd
> > like in a functor. That's what's done with filters that derive from
> > itk::UnaryImageFilter
> > <http://www.itk.org/Doxygen/html/classitk_1_1UnaryFunctorImageFilter.html>
> > .
> > The default would be itk::Add2 but we could find or implement another
> > one that simply discards the pixel value.
> > What do you think?
> > Simon
> > 
> > PS: looking in the code, I just found that rtk::DrawConeImageFilter is
> > not consistent with the others, it was always setting to 0 outside...
> > that's been fixed!
> > 
> > On Wed, Oct 28, 2015 at 4:47 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr
> > 
> > <mailto:mdupont at cppm.in2p3.fr>> wrote:
> >     Hello everyone,
> >     
> >     I have a question/suggestion about the set of rtkDraw*ImageFilter.
> >     This filter are written as additive filters: for example, in
> >     rtkDrawEllipsoidImageFilter.txx, we can find
> >     
> >     for(..)
> >     
> >       itOut.Set( ellipsoid.density + itIn.Get() )
> >     
> >     instead of
> >     
> >     for(..)
> >     itOut.Set( ellipsoid.density )
> >     
> >     
> >     I think it can be more flexible the second option, because we can
> >     always associate Draw*ImageFilter and itkAddImageFilter to get an
> >     additive filter.
> >     
> >     Moreover, the  rtkDrawGeometricPhantomImageFilter class already uses
> >     itkAddImageFilter in order to have additive filters (which is
> >     redundant in current situation).
> >     
> >     What do you think ?
> >     
> >     
> >     
> >     
> >     
> >     Regards
> >     
> >     
> >     
> >     _______________________________________________
> >     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


From gnthibault at gmail.com  Mon Nov  2 08:08:42 2015
From: gnthibault at gmail.com (Notargiacomo Thibault)
Date: Mon, 2 Nov 2015 14:08:42 +0100
Subject: [Rtk-users] Problem with rtkGgoFunctions when importing series of
	images
Message-ID: <CAP+mR7Zw7WmRmEgVUTamNhS6m4S6ORvWFjRu1EANViPRJ7jtuQ@mail.gmail.com>

I recently experienced the following problem, when importing multiple tif
files inside a directory using itk::ImageSeriesReader:

[...]
code/rtkGgoFunctions.h: In instantiation of ?void
rtk::SetProjectionsReaderFromGgo(typename TProjectionsReaderType::Pointer,
const TArgsInfo&)
[...]
code/rtkGgoFunctions.h:121:61: error: no type named
?OutputImageDirectionType? in ?class
itk::ImageSeriesReader<itk::Image<short unsigned int, 3u> >?
   typename TProjectionsReaderType::OutputImageDirectionType direction;
[...]

It seems that, a new functionality added in rtkGgoFunctions.h (19/05/2015),
allowing to directly modify input images properties through command line,
like geometry (direction vector), assumes that the input image type defines
OutputImageDirectionType, but in the case of itk::ImageSeriesReader, it
does not.

Is this considered as a regression, or should the
SetProjectionsReaderFromGgo function be used with specific input image type
?

Thank you in advance for your help.

Kind regards

Thibault Notargiacomo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151102/6cad3583/attachment-0005.html>

From simon.rit at creatis.insa-lyon.fr  Mon Nov  2 08:58:24 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Mon, 2 Nov 2015 14:58:24 +0100
Subject: [Rtk-users] Problem with rtkGgoFunctions when importing series
	of images
In-Reply-To: <CAP+mR7Zw7WmRmEgVUTamNhS6m4S6ORvWFjRu1EANViPRJ7jtuQ@mail.gmail.com>
References: <CAP+mR7Zw7WmRmEgVUTamNhS6m4S6ORvWFjRu1EANViPRJ7jtuQ@mail.gmail.com>
Message-ID: <CAF0oig2bAidO4JR7pa_PUxOQm-X7JrEz8=ybGX3bskYJM9YRAQ@mail.gmail.com>

Hi Thibault,
SetProjectionsReaderFromGgo is a macro designed for the
rtk::ProjectionsReader
<http://www.openrtk.org/Doxygen/classrtk_1_1ProjectionsReader.html>, I'm
not surprised that it does not work with the itk::ImageSeriesReader. It's
not about the image type but about the filter type... We use this macro to
set many parameters specific to the rtk::ProjectionsReader
<http://www.openrtk.org/Doxygen/classrtk_1_1ProjectionsReader.html>. Since
a while, I have made have a common rtkinputprojections_section.ggo
<https://github.com/SimonRit/RTK/blob/master/applications/rtkinputprojections_section.ggo>
file for all the applications that use the rtk::ProjectionsReader.
If you don't want to use the rtk::ProjectionsReader but
itk::ImageSeriesReader (e.g., because it does a lot of automatic processing
that you don't want), you'll have to write your own code to set it up.
I hope this clarifies things.
Simon

On Mon, Nov 2, 2015 at 2:08 PM, Notargiacomo Thibault <gnthibault at gmail.com>
wrote:

> I recently experienced the following problem, when importing multiple tif
> files inside a directory using itk::ImageSeriesReader:
>
> [...]
> code/rtkGgoFunctions.h: In instantiation of ?void
> rtk::SetProjectionsReaderFromGgo(typename TProjectionsReaderType::Pointer,
> const TArgsInfo&)
> [...]
> code/rtkGgoFunctions.h:121:61: error: no type named
> ?OutputImageDirectionType? in ?class
> itk::ImageSeriesReader<itk::Image<short unsigned int, 3u> >?
>    typename TProjectionsReaderType::OutputImageDirectionType direction;
> [...]
>
> It seems that, a new functionality added in rtkGgoFunctions.h
> (19/05/2015), allowing to directly modify input images properties through
> command line, like geometry (direction vector), assumes that the input
> image type defines OutputImageDirectionType, but in the case of
> itk::ImageSeriesReader, it does not.
>
> Is this considered as a regression, or should the
> SetProjectionsReaderFromGgo function be used with specific input image type
> ?
>
> Thank you in advance for your help.
>
> Kind regards
>
> Thibault Notargiacomo
>
> _______________________________________________
> 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/20151102/ee7e2c17/attachment-0005.html>

From simon.rit at creatis.insa-lyon.fr  Wed Nov  4 16:38:18 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Wed, 4 Nov 2015 22:38:18 +0100
Subject: [Rtk-users] question about rtkDraw*ImageFilter
In-Reply-To: <1539144.WPSdtJ8lhZ@marabunta>
References: <5630EE01.5070900@cppm.in2p3.fr>
 <CAF0oig279ZWGJMFnJdXaPiYLPponadz_J-PVKt2z3iHiTRQ_gg@mail.gmail.com>
 <56334CF2.8070902@cppm.in2p3.fr> <1539144.WPSdtJ8lhZ@marabunta>
Message-ID: <CAF0oig3jBsfoadM_k6SYvOMwikOCNFmH19J7m1YJZx-RU0y+5g@mail.gmail.com>

Hi Mathieu,
Sorry, I'm very busy these days. I had a first quick look. Why not, it
looks a bit complicated but good. I would have a few things I would change
style wise, e.g., move DrawCylinderSpatialObject to
DrawCylinderImageFilter, create a common DrawQuadricSpatialObject that
would all have the same IsInside function, make DrawSpatialObjectpurely
virtual by not defining
IsInside etc. but those are details I can correct myself. Do you want to
finish what you started and I work from there or should I finish everything?
Simon

On Sun, Nov 1, 2015 at 6:41 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr>
wrote:

> Hello Simon,
>
> I started to implement what I suggested :
>
>
> https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawImageFilter.h
> and
>
> https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawCylinderImageFilter.h
>
> rtk::DrawCylinderImageFilter derives from rtk::DrawImageFilter and
> specializes
> it (by defaulting the template parameter TSpatialObject with
> DrawCylinderSpatialObject).
>
> By default, DrawCylinderImageFilter uses Add2 for filling output image (to
> be
> backward compatible (all tests pass)). I created Discard (I did not find
> equivalent in itk) functor in order to do what I wanted in my first email.
>
> I just implemented DrawCylinderImageFilter, the others will follow.
>
> What do you think about it ?
>
> Le vendredi 30 octobre 2015, 11:56:50 Mathieu Dupont a ?crit :
> > Hi,
> >
> > In case of your first solution, you can not chain several
> > Draw*ImageFilters. For example, if you want to create small cylinders in
> > a big cylinder.
> >
> > Your second solution is better.
> >
> > One another solution can be a thing like itk:SpatialObject but more
> > simpler. An rtk::SpatialObject which one function (isInside(point)). We
> > create a rtkDrawImageFilter class and implement ThreadedGenerateData
> > like this :
> >
> > DrawImageFilter<InImage, OutImage, rtkSpatialObject,
> > rtkFillFunctor>::ThreadedGenerateData(const OutputImageRegionType&
> > outputRegionForThread,                 ThreadIdType itkNotUsed(threadId)
> > {
> > ...
> >
> >   while( !itOut.IsAtEnd() )
> >      {
> >      this->GetInput()->TransformIndexToPhysicalPoint(itOut.GetIndex(),
> > point);
> >
> >     if(m_rtkSpatialObject.isInside(point)
> >       itOut.Set(m_rtkFillFunctor(density, itIn.Get());
> > ...
> > }
> >
> >
> > DrawConeImageFilter class can be a child of this new DrawImageFilter
> > (with new methods like setAngle, SetRadius which will adjust the
> > rtkConeSpatialObject)
> >
> > This solution suppress duplicated code in
> > Draw*ImageFilter::ThreadedGenerateData and makes easier implementation
> > of another type of filling.
> >
> > On 28/10/2015 20:52, Simon Rit wrote:
> > > Hi Mathieu,
> > > Thanks for pointing this out. I agree that it might not be the best
> > > solution, yet one could argue that you could simply create a constant
> > > image with 0 to do what you'd like from the current implementation. My
> > > main problem is that I just tried to do what you suggest and some tests
> > > then fail... which shows the obvious, it's not a backward compatible
> > > change. I see two solutions:
> > > - keep it as is and you use ConstantImageFilter + we remove useless add
> > > filters,
> > > - a more complex but maybe more elegant solution: add a third template
> > > parameter for the operation that would allow the user to do what he'd
> > > like in a functor. That's what's done with filters that derive from
> > > itk::UnaryImageFilter
> > > <
> http://www.itk.org/Doxygen/html/classitk_1_1UnaryFunctorImageFilter.html>
> > > .
> > > The default would be itk::Add2 but we could find or implement another
> > > one that simply discards the pixel value.
> > > What do you think?
> > > Simon
> > >
> > > PS: looking in the code, I just found that rtk::DrawConeImageFilter is
> > > not consistent with the others, it was always setting to 0 outside...
> > > that's been fixed!
> > >
> > > On Wed, Oct 28, 2015 at 4:47 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr
> > >
> > > <mailto:mdupont at cppm.in2p3.fr>> wrote:
> > >     Hello everyone,
> > >
> > >     I have a question/suggestion about the set of rtkDraw*ImageFilter.
> > >     This filter are written as additive filters: for example, in
> > >     rtkDrawEllipsoidImageFilter.txx, we can find
> > >
> > >     for(..)
> > >
> > >       itOut.Set( ellipsoid.density + itIn.Get() )
> > >
> > >     instead of
> > >
> > >     for(..)
> > >     itOut.Set( ellipsoid.density )
> > >
> > >
> > >     I think it can be more flexible the second option, because we can
> > >     always associate Draw*ImageFilter and itkAddImageFilter to get an
> > >     additive filter.
> > >
> > >     Moreover, the  rtkDrawGeometricPhantomImageFilter class already
> uses
> > >     itkAddImageFilter in order to have additive filters (which is
> > >     redundant in current situation).
> > >
> > >     What do you think ?
> > >
> > >
> > >
> > >
> > >
> > >     Regards
> > >
> > >
> > >
> > >     _______________________________________________
> > >     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/20151104/46314d97/attachment-0005.html>

From mdupont at cppm.in2p3.fr  Mon Nov  9 14:35:47 2015
From: mdupont at cppm.in2p3.fr (Mathieu Dupont)
Date: Mon, 09 Nov 2015 20:35:47 +0100
Subject: [Rtk-users] question about rtkDraw*ImageFilter
In-Reply-To: <CAF0oig3jBsfoadM_k6SYvOMwikOCNFmH19J7m1YJZx-RU0y+5g@mail.gmail.com>
References: <5630EE01.5070900@cppm.in2p3.fr> <1539144.WPSdtJ8lhZ@marabunta>
 <CAF0oig3jBsfoadM_k6SYvOMwikOCNFmH19J7m1YJZx-RU0y+5g@mail.gmail.com>
Message-ID: <5634494.U9CmFl2V79@marabunta>

hi, 

i will do this during this week and try to implement your remarks. 


Le mercredi 4 novembre 2015, 22:38:18 Simon Rit a ?crit :
> Hi Mathieu,
> Sorry, I'm very busy these days. I had a first quick look. Why not, it
> looks a bit complicated but good. I would have a few things I would change
> style wise, e.g., move DrawCylinderSpatialObject to
> DrawCylinderImageFilter, create a common DrawQuadricSpatialObject that
> would all have the same IsInside function, make DrawSpatialObjectpurely
> virtual by not defining
> IsInside etc. but those are details I can correct myself. Do you want to
> finish what you started and I work from there or should I finish everything?
> Simon
> 
> On Sun, Nov 1, 2015 at 6:41 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr>
> 
> wrote:
> > Hello Simon,
> > 
> > I started to implement what I suggested :
> > 
> > 
> > https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawImag
> > eFilter.h and
> > 
> > https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawCyli
> > nderImageFilter.h
> > 
> > rtk::DrawCylinderImageFilter derives from rtk::DrawImageFilter and
> > specializes
> > it (by defaulting the template parameter TSpatialObject with
> > DrawCylinderSpatialObject).
> > 
> > By default, DrawCylinderImageFilter uses Add2 for filling output image (to
> > be
> > backward compatible (all tests pass)). I created Discard (I did not find
> > equivalent in itk) functor in order to do what I wanted in my first email.
> > 
> > I just implemented DrawCylinderImageFilter, the others will follow.
> > 
> > What do you think about it ?
> > 
> > Le vendredi 30 octobre 2015, 11:56:50 Mathieu Dupont a ?crit :
> > > Hi,
> > > 
> > > In case of your first solution, you can not chain several
> > > Draw*ImageFilters. For example, if you want to create small cylinders in
> > > a big cylinder.
> > > 
> > > Your second solution is better.
> > > 
> > > One another solution can be a thing like itk:SpatialObject but more
> > > simpler. An rtk::SpatialObject which one function (isInside(point)). We
> > > create a rtkDrawImageFilter class and implement ThreadedGenerateData
> > > like this :
> > > 
> > > DrawImageFilter<InImage, OutImage, rtkSpatialObject,
> > > rtkFillFunctor>::ThreadedGenerateData(const OutputImageRegionType&
> > > outputRegionForThread,                 ThreadIdType itkNotUsed(threadId)
> > > {
> > > ...
> > > 
> > >   while( !itOut.IsAtEnd() )
> > >   
> > >      {
> > >      this->GetInput()->TransformIndexToPhysicalPoint(itOut.GetIndex(),
> > > 
> > > point);
> > > 
> > >     if(m_rtkSpatialObject.isInside(point)
> > >     
> > >       itOut.Set(m_rtkFillFunctor(density, itIn.Get());
> > > 
> > > ...
> > > }
> > > 
> > > 
> > > DrawConeImageFilter class can be a child of this new DrawImageFilter
> > > (with new methods like setAngle, SetRadius which will adjust the
> > > rtkConeSpatialObject)
> > > 
> > > This solution suppress duplicated code in
> > > Draw*ImageFilter::ThreadedGenerateData and makes easier implementation
> > > of another type of filling.
> > > 
> > > On 28/10/2015 20:52, Simon Rit wrote:
> > > > Hi Mathieu,
> > > > Thanks for pointing this out. I agree that it might not be the best
> > > > solution, yet one could argue that you could simply create a constant
> > > > image with 0 to do what you'd like from the current implementation. My
> > > > main problem is that I just tried to do what you suggest and some
> > > > tests
> > > > then fail... which shows the obvious, it's not a backward compatible
> > > > change. I see two solutions:
> > > > - keep it as is and you use ConstantImageFilter + we remove useless
> > > > add
> > > > filters,
> > > > - a more complex but maybe more elegant solution: add a third template
> > > > parameter for the operation that would allow the user to do what he'd
> > > > like in a functor. That's what's done with filters that derive from
> > > > itk::UnaryImageFilter
> > > > <
> > 
> > http://www.itk.org/Doxygen/html/classitk_1_1UnaryFunctorImageFilter.html>
> > 
> > > > .
> > > > The default would be itk::Add2 but we could find or implement another
> > > > one that simply discards the pixel value.
> > > > What do you think?
> > > > Simon
> > > > 
> > > > PS: looking in the code, I just found that rtk::DrawConeImageFilter is
> > > > not consistent with the others, it was always setting to 0 outside...
> > > > that's been fixed!
> > > > 
> > > > On Wed, Oct 28, 2015 at 4:47 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr
> > > > 
> > > > <mailto:mdupont at cppm.in2p3.fr>> wrote:
> > > >     Hello everyone,
> > > >     
> > > >     I have a question/suggestion about the set of rtkDraw*ImageFilter.
> > > >     This filter are written as additive filters: for example, in
> > > >     rtkDrawEllipsoidImageFilter.txx, we can find
> > > >     
> > > >     for(..)
> > > >     
> > > >       itOut.Set( ellipsoid.density + itIn.Get() )
> > > >     
> > > >     instead of
> > > >     
> > > >     for(..)
> > > >     itOut.Set( ellipsoid.density )
> > > >     
> > > >     
> > > >     I think it can be more flexible the second option, because we can
> > > >     always associate Draw*ImageFilter and itkAddImageFilter to get an
> > > >     additive filter.
> > > >     
> > > >     Moreover, the  rtkDrawGeometricPhantomImageFilter class already
> > 
> > uses
> > 
> > > >     itkAddImageFilter in order to have additive filters (which is
> > > >     redundant in current situation).
> > > >     
> > > >     What do you think ?
> > > >     
> > > >     
> > > >     
> > > >     
> > > >     
> > > >     Regards
> > > >     
> > > >     
> > > >     
> > > >     _______________________________________________
> > > >     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


From gnthibault at gmail.com  Tue Nov 10 07:39:46 2015
From: gnthibault at gmail.com (Notargiacomo Thibault)
Date: Tue, 10 Nov 2015 13:39:46 +0100
Subject: [Rtk-users] Understanding projection matrices management in
	rtkCudaBackProjectionImageFilter
Message-ID: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>

Hi all,

I am currently trying to use the "AddProjectionInRadians" method from the
ThreeDCircularProjectionGeometry class in RTK to import my geometry.

First things first, I would like to know if the information on this pdf are
still valid: http://www.openrtk.org/Doxygen/geometry.pdf

Because I used them to deduce the source offset and Projection offset from
my own matrix decomposition.

Notice that I don't want to use geometric informations coming from the
projection images themselves, so their geometric origin is assumed to be
(0,0,0) in my case.

In order to check if my geometry import method is correct, I print out one
of the intermediate form of the projection matrix used in the
backprojection process, in order to check if it is the same as in my own
implementation.

To do so, I print out one of the intermediate matrix that is generated in
rtkCudaBackProjectionImageFilter while launching a SART reconstruction for
instance.

I was surpised by the fact that, the matrix allowing the transformation
from 2D geometric world to 2D image index world, namely matrixIdxProj in
rtkCudaBackProjectionImageFilte.cxx
<http://www.openrtk.org/Doxygen/rtkCudaBackProjectionImageFilter_8cxx_source.html>
is not always the same along the reconstruction process ?

Here is the line that generates the matrix I don't understand:

for(unsigned int i=0; i<2; i++)
 //SR: 0.5 for 2D texture
  matrixIdxProj[i][2] =
-1*(this->GetInput(1)->GetBufferedRegion().GetIndex()[i])+0.5;

What I understand here, is that, we are generating a 2D translation matrix
embedded in a 3*3 matrix that allows to take into account two things
related to the 2D projection:

-If the internal behaviour of the imageContainer, allows buffering of only
a part of the image, beginning at index (i,j), this information will be
embeded in the projection matrix

-the ITK floating point addressing definition seems to differ from the one
from cuda (and openCV):
When I take a look at this page
<http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#texture-fetching>
I understand that the floating point indexing (0.5,0.5) in Cuda points to
the center of the pixel (0,0) hence a linear contribution of 100%, while it
seems that we must add a translation of (0.5,0.5) to the ITK geometric
framework in order to get the same behaviour.

In practice matrixIdxProj is based on a 3*3 identity matrix, where the
inner 2D translation (ie 2 first term of the last column) in my case are:
-in X, a random number between 10 and 150 plus 0.5
-in Y: always 0.5

I understand the 0.5 part, but why is there always a 0 offset in Y but a
random offset in X remains a mystery to me.

At first, I believed that each projection was splitted into multiple part,
each having a different X and Y offset.
But reconstructing using only one projection generates only one
backprojection operation, with a non zero offset in X, 123 in my case, for
an image of size 780 in X.

Do you think there is something wrong whith the values of matrixIdxProjI am
experiencing ?

Thank you in advance.

Kind regards

Thibault Notargiacomo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151110/fbd3fb46/attachment-0005.html>

From simon.rit at creatis.insa-lyon.fr  Tue Nov 10 08:21:29 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Tue, 10 Nov 2015 14:21:29 +0100
Subject: [Rtk-users] Understanding projection matrices management in
	rtkCudaBackProjectionImageFilter
In-Reply-To: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>
References: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>
Message-ID: <CAF0oig3muuH+1=eLZ66DJ22QcnsSrUKzRFS4RzDRvDJXNxAVXg@mail.gmail.com>

Hi Thibault,
You started digging in the code so that gets complicated. First thing
first, yes, the link you provide is still valid.
The offset in X is not random but computed in
BackProjectionImageFilter::GenerateInputRequestedRegion
<https://github.com/SimonRit/RTK/blob/master/code/rtkBackProjectionImageFilter.txx>.
The idea is that we request only the part of the projections we need to do
the backprojection. This optimizes the streaming (we only read from disk
what we need). If you use a huge volume (the test I'd suggest to validate
that I'm correct and there is nothing wrong with your code), then you'll
need the full projection and you will always get 0 in X as in Y. If you use
a small volume and do a computation projection per projection, you will get
a varying index depending on your input volume and the geometry for that
projection.
I think you understood the rest pretty well. Does that make sense or am I
missing something else?
Simon

On Tue, Nov 10, 2015 at 1:39 PM, Notargiacomo Thibault <gnthibault at gmail.com
> wrote:

> Hi all,
>
> I am currently trying to use the "AddProjectionInRadians" method from the
> ThreeDCircularProjectionGeometry class in RTK to import my geometry.
>
> First things first, I would like to know if the information on this pdf
> are still valid: http://www.openrtk.org/Doxygen/geometry.pdf
>
> Because I used them to deduce the source offset and Projection offset from
> my own matrix decomposition.
>
> Notice that I don't want to use geometric informations coming from the
> projection images themselves, so their geometric origin is assumed to be
> (0,0,0) in my case.
>
> In order to check if my geometry import method is correct, I print out one
> of the intermediate form of the projection matrix used in the
> backprojection process, in order to check if it is the same as in my own
> implementation.
>
> To do so, I print out one of the intermediate matrix that is generated in
> rtkCudaBackProjectionImageFilter while launching a SART reconstruction for
> instance.
>
> I was surpised by the fact that, the matrix allowing the transformation
> from 2D geometric world to 2D image index world, namely matrixIdxProj in
> rtkCudaBackProjectionImageFilte.cxx
> <http://www.openrtk.org/Doxygen/rtkCudaBackProjectionImageFilter_8cxx_source.html>
> is not always the same along the reconstruction process ?
>
> Here is the line that generates the matrix I don't understand:
>
> for(unsigned int i=0; i<2; i++)
>  //SR: 0.5 for 2D texture
>   matrixIdxProj[i][2] =
> -1*(this->GetInput(1)->GetBufferedRegion().GetIndex()[i])+0.5;
>
> What I understand here, is that, we are generating a 2D translation matrix
> embedded in a 3*3 matrix that allows to take into account two things
> related to the 2D projection:
>
> -If the internal behaviour of the imageContainer, allows buffering of only
> a part of the image, beginning at index (i,j), this information will be
> embeded in the projection matrix
>
> -the ITK floating point addressing definition seems to differ from the one
> from cuda (and openCV):
> When I take a look at this page
> <http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#texture-fetching>
> I understand that the floating point indexing (0.5,0.5) in Cuda points to
> the center of the pixel (0,0) hence a linear contribution of 100%, while it
> seems that we must add a translation of (0.5,0.5) to the ITK geometric
> framework in order to get the same behaviour.
>
> In practice matrixIdxProj is based on a 3*3 identity matrix, where the
> inner 2D translation (ie 2 first term of the last column) in my case are:
> -in X, a random number between 10 and 150 plus 0.5
> -in Y: always 0.5
>
> I understand the 0.5 part, but why is there always a 0 offset in Y but a
> random offset in X remains a mystery to me.
>
> At first, I believed that each projection was splitted into multiple part,
> each having a different X and Y offset.
> But reconstructing using only one projection generates only one
> backprojection operation, with a non zero offset in X, 123 in my case, for
> an image of size 780 in X.
>
> Do you think there is something wrong whith the values of matrixIdxProjI
> am experiencing ?
>
> Thank you in advance.
>
> Kind regards
>
> Thibault Notargiacomo
>
> _______________________________________________
> 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/20151110/8b9b86e6/attachment-0005.html>

From simon.rit at creatis.insa-lyon.fr  Tue Nov 10 09:03:52 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Tue, 10 Nov 2015 15:03:52 +0100
Subject: [Rtk-users] Understanding projection matrices management in
	rtkCudaBackProjectionImageFilter
In-Reply-To: <CAP+mR7ZLJV8V5dMOW_jgM5G2-kCZhy8o0tB19685LGo-1bxLUg@mail.gmail.com>
References: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>
 <CAF0oig3muuH+1=eLZ66DJ22QcnsSrUKzRFS4RzDRvDJXNxAVXg@mail.gmail.com>
 <CAP+mR7ZLJV8V5dMOW_jgM5G2-kCZhy8o0tB19685LGo-1bxLUg@mail.gmail.com>
Message-ID: <CAF0oig3fALRnZNCJ53+TsSjBm7raRC_mqahWEU6x+D+zxwOnVQ@mail.gmail.com>

A small correction: it's actually the amount of data pre-processed (read
from disk + all the processing before backprojection) but that should
change nothing to what is backprojected.
I remembered something that can help you: you may want to run
UpdateLargestPossibleRegion() to the projections (input 1 of the
BackProjectImageFilter) before backprojection to avoid this and make things
clearer instead of using a large volume as I was suggesting before.
Simon

On Tue, Nov 10, 2015 at 2:34 PM, Notargiacomo Thibault <gnthibault at gmail.com
> wrote:

> Ok, using geometric information to reduce the amount of data to be
> backprojected is pretty clever ;)
> This explains the "random" index I was asking about in my previous
> question, I now know what it is used for and continue my debugging process.
>
> Kind regards
>
> Thibault Notargiacomo
>
> 2015-11-10 14:21 GMT+01:00 Simon Rit <simon.rit at creatis.insa-lyon.fr>:
>
>> Hi Thibault,
>> You started digging in the code so that gets complicated. First thing
>> first, yes, the link you provide is still valid.
>> The offset in X is not random but computed in
>> BackProjectionImageFilter::GenerateInputRequestedRegion
>> <https://github.com/SimonRit/RTK/blob/master/code/rtkBackProjectionImageFilter.txx>.
>> The idea is that we request only the part of the projections we need to do
>> the backprojection. This optimizes the streaming (we only read from disk
>> what we need). If you use a huge volume (the test I'd suggest to validate
>> that I'm correct and there is nothing wrong with your code), then you'll
>> need the full projection and you will always get 0 in X as in Y. If you use
>> a small volume and do a computation projection per projection, you will get
>> a varying index depending on your input volume and the geometry for that
>> projection.
>> I think you understood the rest pretty well. Does that make sense or am I
>> missing something else?
>> Simon
>>
>> On Tue, Nov 10, 2015 at 1:39 PM, Notargiacomo Thibault <
>> gnthibault at gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> I am currently trying to use the "AddProjectionInRadians" method from
>>> the ThreeDCircularProjectionGeometry class in RTK to import my geometry.
>>>
>>> First things first, I would like to know if the information on this pdf
>>> are still valid: http://www.openrtk.org/Doxygen/geometry.pdf
>>>
>>> Because I used them to deduce the source offset and Projection offset
>>> from my own matrix decomposition.
>>>
>>> Notice that I don't want to use geometric informations coming from the
>>> projection images themselves, so their geometric origin is assumed to be
>>> (0,0,0) in my case.
>>>
>>> In order to check if my geometry import method is correct, I print out
>>> one of the intermediate form of the projection matrix used in the
>>> backprojection process, in order to check if it is the same as in my own
>>> implementation.
>>>
>>> To do so, I print out one of the intermediate matrix that is generated
>>> in rtkCudaBackProjectionImageFilter while launching a SART reconstruction
>>> for instance.
>>>
>>> I was surpised by the fact that, the matrix allowing the transformation
>>> from 2D geometric world to 2D image index world, namely matrixIdxProj in
>>> rtkCudaBackProjectionImageFilte.cxx
>>> <http://www.openrtk.org/Doxygen/rtkCudaBackProjectionImageFilter_8cxx_source.html>
>>> is not always the same along the reconstruction process ?
>>>
>>> Here is the line that generates the matrix I don't understand:
>>>
>>> for(unsigned int i=0; i<2; i++)
>>>  //SR: 0.5 for 2D texture
>>>   matrixIdxProj[i][2] =
>>> -1*(this->GetInput(1)->GetBufferedRegion().GetIndex()[i])+0.5;
>>>
>>> What I understand here, is that, we are generating a 2D translation
>>> matrix embedded in a 3*3 matrix that allows to take into account two things
>>> related to the 2D projection:
>>>
>>> -If the internal behaviour of the imageContainer, allows buffering of
>>> only a part of the image, beginning at index (i,j), this information will
>>> be embeded in the projection matrix
>>>
>>> -the ITK floating point addressing definition seems to differ from the
>>> one from cuda (and openCV):
>>> When I take a look at this page
>>> <http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#texture-fetching>
>>> I understand that the floating point indexing (0.5,0.5) in Cuda points to
>>> the center of the pixel (0,0) hence a linear contribution of 100%, while it
>>> seems that we must add a translation of (0.5,0.5) to the ITK geometric
>>> framework in order to get the same behaviour.
>>>
>>> In practice matrixIdxProj is based on a 3*3 identity matrix, where the
>>> inner 2D translation (ie 2 first term of the last column) in my case are:
>>> -in X, a random number between 10 and 150 plus 0.5
>>> -in Y: always 0.5
>>>
>>> I understand the 0.5 part, but why is there always a 0 offset in Y but a
>>> random offset in X remains a mystery to me.
>>>
>>> At first, I believed that each projection was splitted into multiple
>>> part, each having a different X and Y offset.
>>> But reconstructing using only one projection generates only one
>>> backprojection operation, with a non zero offset in X, 123 in my case, for
>>> an image of size 780 in X.
>>>
>>> Do you think there is something wrong whith the values of matrixIdxProjI
>>> am experiencing ?
>>>
>>> Thank you in advance.
>>>
>>> Kind regards
>>>
>>> Thibault Notargiacomo
>>>
>>> _______________________________________________
>>> 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/20151110/d8913dc3/attachment-0005.html>

From simon.rit at creatis.insa-lyon.fr  Tue Nov 10 11:21:29 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Tue, 10 Nov 2015 17:21:29 +0100
Subject: [Rtk-users] Understanding projection matrices management in
	rtkCudaBackProjectionImageFilter
In-Reply-To: <CAP+mR7ZKqnbUyRHyHkti=3sZd2dEw-OUV6oqsqcga55=tcQ9OQ@mail.gmail.com>
References: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>
 <CAF0oig3muuH+1=eLZ66DJ22QcnsSrUKzRFS4RzDRvDJXNxAVXg@mail.gmail.com>
 <CAP+mR7ZLJV8V5dMOW_jgM5G2-kCZhy8o0tB19685LGo-1bxLUg@mail.gmail.com>
 <CAF0oig3fALRnZNCJ53+TsSjBm7raRC_mqahWEU6x+D+zxwOnVQ@mail.gmail.com>
 <CAP+mR7ZKqnbUyRHyHkti=3sZd2dEw-OUV6oqsqcga55=tcQ9OQ@mail.gmail.com>
Message-ID: <CAF0oig12pRGBfgiCQMCwTG7zX_3vz87AEWhTQ4EYaVbH_m0t5Q@mail.gmail.com>

Your welcome (I cc the mailing list for info).
Simon

On Tue, Nov 10, 2015 at 5:03 PM, Notargiacomo Thibault <gnthibault at gmail.com
> wrote:

> I replaced the original Update by the "UpdateLargestPossibleRegion" to the
> divideFilter in SART (I bypassed displacedDetectorFilter for now) and it
> work as expected, I have now a "clean" matProjIdx.
>
> Thank you for your help !
>
> 2015-11-10 15:03 GMT+01:00 Simon Rit <simon.rit at creatis.insa-lyon.fr>:
>
>> A small correction: it's actually the amount of data pre-processed (read
>> from disk + all the processing before backprojection) but that should
>> change nothing to what is backprojected.
>> I remembered something that can help you: you may want to run
>> UpdateLargestPossibleRegion() to the projections (input 1 of the
>> BackProjectImageFilter) before backprojection to avoid this and make things
>> clearer instead of using a large volume as I was suggesting before.
>> Simon
>>
>> On Tue, Nov 10, 2015 at 2:34 PM, Notargiacomo Thibault <
>> gnthibault at gmail.com> wrote:
>>
>>> Ok, using geometric information to reduce the amount of data to be
>>> backprojected is pretty clever ;)
>>> This explains the "random" index I was asking about in my previous
>>> question, I now know what it is used for and continue my debugging process.
>>>
>>> Kind regards
>>>
>>> Thibault Notargiacomo
>>>
>>> 2015-11-10 14:21 GMT+01:00 Simon Rit <simon.rit at creatis.insa-lyon.fr>:
>>>
>>>> Hi Thibault,
>>>> You started digging in the code so that gets complicated. First thing
>>>> first, yes, the link you provide is still valid.
>>>> The offset in X is not random but computed in
>>>> BackProjectionImageFilter::GenerateInputRequestedRegion
>>>> <https://github.com/SimonRit/RTK/blob/master/code/rtkBackProjectionImageFilter.txx>.
>>>> The idea is that we request only the part of the projections we need to do
>>>> the backprojection. This optimizes the streaming (we only read from disk
>>>> what we need). If you use a huge volume (the test I'd suggest to validate
>>>> that I'm correct and there is nothing wrong with your code), then you'll
>>>> need the full projection and you will always get 0 in X as in Y. If you use
>>>> a small volume and do a computation projection per projection, you will get
>>>> a varying index depending on your input volume and the geometry for that
>>>> projection.
>>>> I think you understood the rest pretty well. Does that make sense or am
>>>> I missing something else?
>>>> Simon
>>>>
>>>> On Tue, Nov 10, 2015 at 1:39 PM, Notargiacomo Thibault <
>>>> gnthibault at gmail.com> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I am currently trying to use the "AddProjectionInRadians" method from
>>>>> the ThreeDCircularProjectionGeometry class in RTK to import my geometry.
>>>>>
>>>>> First things first, I would like to know if the information on this
>>>>> pdf are still valid: http://www.openrtk.org/Doxygen/geometry.pdf
>>>>>
>>>>> Because I used them to deduce the source offset and Projection offset
>>>>> from my own matrix decomposition.
>>>>>
>>>>> Notice that I don't want to use geometric informations coming from the
>>>>> projection images themselves, so their geometric origin is assumed to be
>>>>> (0,0,0) in my case.
>>>>>
>>>>> In order to check if my geometry import method is correct, I print out
>>>>> one of the intermediate form of the projection matrix used in the
>>>>> backprojection process, in order to check if it is the same as in my own
>>>>> implementation.
>>>>>
>>>>> To do so, I print out one of the intermediate matrix that is generated
>>>>> in rtkCudaBackProjectionImageFilter while launching a SART reconstruction
>>>>> for instance.
>>>>>
>>>>> I was surpised by the fact that, the matrix allowing the
>>>>> transformation from 2D geometric world to 2D image index world, namely
>>>>> matrixIdxProj in rtkCudaBackProjectionImageFilte.cxx
>>>>> <http://www.openrtk.org/Doxygen/rtkCudaBackProjectionImageFilter_8cxx_source.html>
>>>>> is not always the same along the reconstruction process ?
>>>>>
>>>>> Here is the line that generates the matrix I don't understand:
>>>>>
>>>>> for(unsigned int i=0; i<2; i++)
>>>>>  //SR: 0.5 for 2D texture
>>>>>   matrixIdxProj[i][2] =
>>>>> -1*(this->GetInput(1)->GetBufferedRegion().GetIndex()[i])+0.5;
>>>>>
>>>>> What I understand here, is that, we are generating a 2D translation
>>>>> matrix embedded in a 3*3 matrix that allows to take into account two things
>>>>> related to the 2D projection:
>>>>>
>>>>> -If the internal behaviour of the imageContainer, allows buffering of
>>>>> only a part of the image, beginning at index (i,j), this information will
>>>>> be embeded in the projection matrix
>>>>>
>>>>> -the ITK floating point addressing definition seems to differ from the
>>>>> one from cuda (and openCV):
>>>>> When I take a look at this page
>>>>> <http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#texture-fetching>
>>>>> I understand that the floating point indexing (0.5,0.5) in Cuda points to
>>>>> the center of the pixel (0,0) hence a linear contribution of 100%, while it
>>>>> seems that we must add a translation of (0.5,0.5) to the ITK geometric
>>>>> framework in order to get the same behaviour.
>>>>>
>>>>> In practice matrixIdxProj is based on a 3*3 identity matrix, where
>>>>> the inner 2D translation (ie 2 first term of the last column) in my case
>>>>> are:
>>>>> -in X, a random number between 10 and 150 plus 0.5
>>>>> -in Y: always 0.5
>>>>>
>>>>> I understand the 0.5 part, but why is there always a 0 offset in Y but
>>>>> a random offset in X remains a mystery to me.
>>>>>
>>>>> At first, I believed that each projection was splitted into multiple
>>>>> part, each having a different X and Y offset.
>>>>> But reconstructing using only one projection generates only one
>>>>> backprojection operation, with a non zero offset in X, 123 in my case, for
>>>>> an image of size 780 in X.
>>>>>
>>>>> Do you think there is something wrong whith the values of matrixIdxProjI
>>>>> am experiencing ?
>>>>>
>>>>> Thank you in advance.
>>>>>
>>>>> Kind regards
>>>>>
>>>>> Thibault Notargiacomo
>>>>>
>>>>> _______________________________________________
>>>>> 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/20151110/b7eba683/attachment-0005.html>

From theday79 at gmail.com  Wed Nov 11 13:50:45 2015
From: theday79 at gmail.com (Yang K Park)
Date: Wed, 11 Nov 2015 13:50:45 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after  a recent update
Message-ID: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>

Hi all,

 

I?ve updated rtk with the up-to-date revision and have encountered a couple of problems.

 

1.       Compile error: RTK couldn?t find itkMacro.h while it compiled rtkCudaUtilities.hcu. It was solved by a minor fetching:

#include <itkMacro.h>   --> #include "itkMacro.h" in rtkCudaUtilities.hcu

 

2.       Output of rtkfdk with CUDA was not the same as before. It was very blurry as seen in the attached image.

a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.

 

 

I?m using VS2013 with win7, itk4.8.1.

 

The command line I used was :

rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware cuda --pad 1 --hann 5 --hannY 5

 

Does anyone have any idea about this?

 

Thanks.

 

Yang

 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151111/b1c7df5f/attachment-0005.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 16577 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151111/b1c7df5f/attachment-0005.png>

From simon.rit at creatis.insa-lyon.fr  Wed Nov 11 16:15:49 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Wed, 11 Nov 2015 22:15:49 +0100
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
Message-ID: <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>

Hi,
I didn't manage to reproduce the two problems on linux with the same
ITK version.
For point 1, did you copy itkMacro.h by hand? Because I don't see how
replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not
in the same folder as rtkCudaUtilities.hcu
For point 2, no clue. Do you use FFTW? It looks like a ramp filter
issue. Can you try rtkramp --path projPath --regexp .*.his, with and
without --hardware cuda? Maybe you can provide your geometry file in
case it's a specific geometric issue.
Simon

On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
> Hi all,
>
>
>
> I?ve updated rtk with the up-to-date revision and have encountered a couple
> of problems.
>
>
>
> 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
> rtkCudaUtilities.hcu. It was solved by a minor fetching:
>
> #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>
>
>
> 2.       Output of rtkfdk with CUDA was not the same as before. It was very
> blurry as seen in the attached image.
>
> a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>
>
>
>
>
> I?m using VS2013 with win7, itk4.8.1.
>
>
>
> The command line I used was :
>
> rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his --output
> output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware cuda --pad 1
> --hann 5 --hannY 5
>
>
>
> Does anyone have any idea about this?
>
>
>
> Thanks.
>
>
>
> Yang
>
>
>
>
> _______________________________________________
> Rtk-users mailing list
> Rtk-users at public.kitware.com
> http://public.kitware.com/mailman/listinfo/rtk-users
>


From theday79 at gmail.com  Thu Nov 12 17:39:38 2015
From: theday79 at gmail.com (Yang K Park)
Date: Thu, 12 Nov 2015 17:39:38 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
Message-ID: <000001d11d9b$04142320$0c3c6960$@gmail.com>

Hi Simon,

 

Thanks for the advice. The current RTK was compiled with FFTW to use the phase extraction feature from Amsterdam shroud.

 

Regarding your suggestions,

 

1)      rtkramp w/ or w/o CUDA:

(command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda --output Ramp_wCUDA.mha? )

 

Then, I have encountered following error.

?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that input requested and buffered regions are equal.?

 



 

Without CUDA, it was successfully done.

 

2)      I?ve re-compiled ITK w/o FFTW and built RTK again. rtkfdk worked fine.

-          I?ve also repeated ?rtkramp+CUDA? with this rtk version and the error was same as above.

 

In conclusion, my FFTW seems to affect CUDA-based fdk reconstruction only.

But I do need FFTW for the phase extraction. What should I do?

 

Thanks.

 

Yang

 

 

-----Original Message-----
From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit
Sent: Wednesday, November 11, 2015 4:16 PM
To: Yang K Park <theday79 at gmail.com>
Cc: rtk-users at openrtk.org
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

I didn't manage to reproduce the two problems on linux with the same ITK version.

For point 1, did you copy itkMacro.h by hand? Because I don't see how replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW? It looks like a ramp filter issue. Can you try rtkramp --path projPath --regexp .*.his, with and without --hardware cuda? Maybe you can provide your geometry file in case it's a specific geometric issue.

Simon

 

On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park < <mailto:theday79 at gmail.com> theday79 at gmail.com> wrote:

> Hi all,

> 

> 

> 

> I?ve updated rtk with the up-to-date revision and have encountered a 

> couple of problems.

> 

> 

> 

> 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled

> rtkCudaUtilities.hcu. It was solved by a minor fetching:

> 

> #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu

> 

> 

> 

> 2.       Output of rtkfdk with CUDA was not the same as before. It was very

> blurry as seen in the attached image.

> 

> a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.

> 

> 

> 

> 

> 

> I?m using VS2013 with win7, itk4.8.1.

> 

> 

> 

> The command line I used was :

> 

> rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his 

> --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware 

> cuda --pad 1 --hann 5 --hannY 5

> 

> 

> 

> Does anyone have any idea about this?

> 

> 

> 

> Thanks.

> 

> 

> 

> Yang

> 

> 

> 

> 

> _______________________________________________

> Rtk-users mailing list

>  <mailto: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/20151112/4e0825dc/attachment-0005.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151112/4e0825dc/attachment-0005.png>

From simon.rit at creatis.insa-lyon.fr  Thu Nov 12 17:58:42 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Thu, 12 Nov 2015 23:58:42 +0100
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <000001d11d9b$04142320$0c3c6960$@gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
Message-ID: <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>

Hi,
Ok. Can you try rtkramp with only one projection? Then you shouldn't
encounter this regions issue (that should be solved one day but that's a
different story).
Can you also indicate which version of CUDA you're using?
FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft for
the FFT of the projections. So if they are not in the same format, you're
in trouble and that might be the issue here... The weird part is that I
didn't reproduce this problem on linux (with and without FFTW) but it might
be a CUDA version difference. I'll give it another try tomorrow when you
provide the CUDA version.
Thanks again for reporting the issue,
Simon

On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com> wrote:

> Hi Simon,
>
>
>
> Thanks for the advice. The current RTK was compiled with FFTW to use the
> phase extraction feature from Amsterdam shroud.
>
>
>
> Regarding your suggestions,
>
>
>
> 1)      rtkramp w/ or w/o CUDA:
>
> (command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda
> --output Ramp_wCUDA.mha? )
>
>
>
> Then, I have encountered following error.
>
> ?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that
> input requested and buffered regions are equal.?
>
>
>
>
>
> Without CUDA, it was successfully done.
>
>
>
> 2)      I?ve re-compiled *ITK w/o FFTW* and built RTK again. r*tkfdk
> worked fine.*
>
> -          I?ve also repeated ?rtkramp+CUDA? with this rtk version and
> the error was same as above.
>
>
>
> In conclusion, my *FFTW seems to affect CUDA-based fdk reconstruction
> only*.
>
> But I do need FFTW for the phase extraction. What should I do?
>
>
>
> Thanks.
>
>
>
> Yang
>
>
>
>
>
> -----Original Message-----
> From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon
> Rit
> Sent: Wednesday, November 11, 2015 4:16 PM
> To: Yang K Park <theday79 at gmail.com>
> Cc: rtk-users at openrtk.org
> Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
> update
>
>
>
> Hi,
>
> I didn't manage to reproduce the two problems on linux with the same ITK
> version.
>
> For point 1, did you copy itkMacro.h by hand? Because I don't see how
> replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the
> same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW?
> It looks like a ramp filter issue. Can you try rtkramp --path projPath
> --regexp .*.his, with and without --hardware cuda? Maybe you can provide
> your geometry file in case it's a specific geometric issue.
>
> Simon
>
>
>
> On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
>
> > Hi all,
>
> >
>
> >
>
> >
>
> > I?ve updated rtk with the up-to-date revision and have encountered a
>
> > couple of problems.
>
> >
>
> >
>
> >
>
> > 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
>
> > rtkCudaUtilities.hcu. It was solved by a minor fetching:
>
> >
>
> > #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>
> >
>
> >
>
> >
>
> > 2.       Output of rtkfdk with CUDA was not the same as before. It was
> very
>
> > blurry as seen in the attached image.
>
> >
>
> > a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > I?m using VS2013 with win7, itk4.8.1.
>
> >
>
> >
>
> >
>
> > The command line I used was :
>
> >
>
> > rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his
>
> > --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware
>
> > cuda --pad 1 --hann 5 --hannY 5
>
> >
>
> >
>
> >
>
> > Does anyone have any idea about this?
>
> >
>
> >
>
> >
>
> > Thanks.
>
> >
>
> >
>
> >
>
> > Yang
>
> >
>
> >
>
> >
>
> >
>
> > _______________________________________________
>
> > 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/20151112/e7c15ff8/attachment-0005.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151112/e7c15ff8/attachment-0005.png>

From theday79 at gmail.com  Mon Nov 16 09:54:01 2015
From: theday79 at gmail.com (Yang K Park)
Date: Mon, 16 Nov 2015 09:54:01 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
Message-ID: <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>

Hi Simon,

 

Sorry for the late response.

 

As you suggested, I?ve tried rtkramp+CUDA with only one projection and it was successfully done for both w/ FFTW and w/o FFTW.

(Two results were exactly same.)

 

Regarding  the CUDA version, I?m using v6.5.

 

Thanks a lot for the help!

 

Yang

 

 

From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit
Sent: Thursday, November 12, 2015 5:59 PM
To: Yang K Park <theday79 at gmail.com>
Cc: rtk-users at openrtk.org
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

Ok. Can you try rtkramp with only one projection? Then you shouldn't encounter this regions issue (that should be solved one day but that's a different story). 

Can you also indicate which version of CUDA you're using?

FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft for the FFT of the projections. So if they are not in the same format, you're in trouble and that might be the issue here... The weird part is that I didn't reproduce this problem on linux (with and without FFTW) but it might be a CUDA version difference. I'll give it another try tomorrow when you provide the CUDA version.

Thanks again for reporting the issue,
Simon

 

On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> > wrote:

Hi Simon,

 

Thanks for the advice. The current RTK was compiled with FFTW to use the phase extraction feature from Amsterdam shroud.

 

Regarding your suggestions,

 

1)      rtkramp w/ or w/o CUDA:

(command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda --output Ramp_wCUDA.mha? )

 

Then, I have encountered following error.

?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that input requested and buffered regions are equal.?

 



 

Without CUDA, it was successfully done.

 

2)      I?ve re-compiled ITK w/o FFTW and built RTK again. rtkfdk worked fine.

-          I?ve also repeated ?rtkramp+CUDA? with this rtk version and the error was same as above.

 

In conclusion, my FFTW seems to affect CUDA-based fdk reconstruction only.

But I do need FFTW for the phase extraction. What should I do?

 

Thanks.

 

Yang

 

 

-----Original Message-----
From: simon.rit at gmail.com <mailto:simon.rit at gmail.com>  [mailto:simon.rit at gmail.com <mailto:simon.rit at gmail.com> ] On Behalf Of Simon Rit
Sent: Wednesday, November 11, 2015 4:16 PM
To: Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> >
Cc: rtk-users at openrtk.org <mailto:rtk-users at openrtk.org> 
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

I didn't manage to reproduce the two problems on linux with the same ITK version.

For point 1, did you copy itkMacro.h by hand? Because I don't see how replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW? It looks like a ramp filter issue. Can you try rtkramp --path projPath --regexp .*.his, with and without --hardware cuda? Maybe you can provide your geometry file in case it's a specific geometric issue.

Simon

 

On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park < <mailto:theday79 at gmail.com> theday79 at gmail.com> wrote:

> Hi all,

> 

> 

> 

> I?ve updated rtk with the up-to-date revision and have encountered a 

> couple of problems.

> 

> 

> 

> 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled

> rtkCudaUtilities.hcu. It was solved by a minor fetching:

> 

> #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu

> 

> 

> 

> 2.       Output of rtkfdk with CUDA was not the same as before. It was very

> blurry as seen in the attached image.

> 

> a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.

> 

> 

> 

> 

> 

> I?m using VS2013 with win7, itk4.8.1.

> 

> 

> 

> The command line I used was :

> 

> rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his 

> --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware 

> cuda --pad 1 --hann 5 --hannY 5

> 

> 

> 

> Does anyone have any idea about this?

> 

> 

> 

> Thanks.

> 

> 

> 

> Yang

> 

> 

> 

> 

> _______________________________________________

> Rtk-users mailing list

>  <mailto: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/20151116/e77c2f96/attachment-0005.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151116/e77c2f96/attachment-0005.png>

From simon.rit at creatis.insa-lyon.fr  Mon Nov 16 10:07:46 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Mon, 16 Nov 2015 16:07:46 +0100
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
 <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
Message-ID: <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>

Hi,
Thanks. It's really weird... When you run the tests with FFTW (compiling
the "test" target), do they fail?
Can you provide your geometry file? It might be specific to this geometry.
Thanks again for looking into this issue, we'll find what's the problem.
Simon

On Mon, Nov 16, 2015 at 3:54 PM, Yang K Park <theday79 at gmail.com> wrote:

> Hi Simon,
>
>
>
> Sorry for the late response.
>
>
>
> As you suggested, I?ve tried rtkramp+CUDA with only one projection and it
> was successfully done for both w/ FFTW and w/o FFTW.
>
> (Two results were exactly same.)
>
>
>
> Regarding  the CUDA version, I?m using v6.5.
>
>
>
> Thanks a lot for the help!
>
>
>
> Yang
>
>
>
>
>
> *From:* simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of *Simon
> Rit
> *Sent:* Thursday, November 12, 2015 5:59 PM
>
> *To:* Yang K Park <theday79 at gmail.com>
> *Cc:* rtk-users at openrtk.org
> *Subject:* Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
> update
>
>
>
> Hi,
>
> Ok. Can you try rtkramp with only one projection? Then you shouldn't
> encounter this regions issue (that should be solved one day but that's a
> different story).
>
> Can you also indicate which version of CUDA you're using?
>
> FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft for
> the FFT of the projections. So if they are not in the same format, you're
> in trouble and that might be the issue here... The weird part is that I
> didn't reproduce this problem on linux (with and without FFTW) but it might
> be a CUDA version difference. I'll give it another try tomorrow when you
> provide the CUDA version.
>
> Thanks again for reporting the issue,
> Simon
>
>
>
> On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com> wrote:
>
> Hi Simon,
>
>
>
> Thanks for the advice. The current RTK was compiled with FFTW to use the
> phase extraction feature from Amsterdam shroud.
>
>
>
> Regarding your suggestions,
>
>
>
> 1)      rtkramp w/ or w/o CUDA:
>
> (command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda
> --output Ramp_wCUDA.mha? )
>
>
>
> Then, I have encountered following error.
>
> ?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that
> input requested and buffered regions are equal.?
>
>
>
>
>
> Without CUDA, it was successfully done.
>
>
>
> 2)      I?ve re-compiled *ITK w/o FFTW* and built RTK again. r*tkfdk
> worked fine.*
>
> -          I?ve also repeated ?rtkramp+CUDA? with this rtk version and
> the error was same as above.
>
>
>
> In conclusion, my *FFTW seems to affect CUDA-based fdk reconstruction
> only*.
>
> But I do need FFTW for the phase extraction. What should I do?
>
>
>
> Thanks.
>
>
>
> Yang
>
>
>
>
>
> -----Original Message-----
> From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon
> Rit
> Sent: Wednesday, November 11, 2015 4:16 PM
> To: Yang K Park <theday79 at gmail.com>
> Cc: rtk-users at openrtk.org
> Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
> update
>
>
>
> Hi,
>
> I didn't manage to reproduce the two problems on linux with the same ITK
> version.
>
> For point 1, did you copy itkMacro.h by hand? Because I don't see how
> replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the
> same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW?
> It looks like a ramp filter issue. Can you try rtkramp --path projPath
> --regexp .*.his, with and without --hardware cuda? Maybe you can provide
> your geometry file in case it's a specific geometric issue.
>
> Simon
>
>
>
> On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
>
> > Hi all,
>
> >
>
> >
>
> >
>
> > I?ve updated rtk with the up-to-date revision and have encountered a
>
> > couple of problems.
>
> >
>
> >
>
> >
>
> > 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
>
> > rtkCudaUtilities.hcu. It was solved by a minor fetching:
>
> >
>
> > #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>
> >
>
> >
>
> >
>
> > 2.       Output of rtkfdk with CUDA was not the same as before. It was
> very
>
> > blurry as seen in the attached image.
>
> >
>
> > a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > I?m using VS2013 with win7, itk4.8.1.
>
> >
>
> >
>
> >
>
> > The command line I used was :
>
> >
>
> > rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his
>
> > --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware
>
> > cuda --pad 1 --hann 5 --hannY 5
>
> >
>
> >
>
> >
>
> > Does anyone have any idea about this?
>
> >
>
> >
>
> >
>
> > Thanks.
>
> >
>
> >
>
> >
>
> > Yang
>
> >
>
> >
>
> >
>
> >
>
> > _______________________________________________
>
> > 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/20151116/38acfca5/attachment-0005.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151116/38acfca5/attachment-0005.png>

From theday79 at gmail.com  Mon Nov 16 10:47:43 2015
From: theday79 at gmail.com (Yang-Kyun Park)
Date: Mon, 16 Nov 2015 10:47:43 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
 <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
 <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>
Message-ID: <CAJM7=xjBjx=FzLazWJWqJbV5d45zGi2U71NKejm9HxKhJ0-xLQ@mail.gmail.com>

Hi Simon,

For better understanding, I'm attaching the problematic case including
projection files, geometry file(xml) and reconstructed images.(please find
the GDrive links. The file size is ~800 MB)
This is phantom data and there is no patient information in it.

Regarding the fftw library, I'm using [fftw-3.3.4-dll64].

By the way, I found another clue. When I've tried it with a head phantom
image (full-fan, ~ 190 projections), there was no problem. Is there any
possibility that DDF and parker short filter play some roles on this issue?

Feel free to let me know if further data is needed.

Thanks!

Yang

?
 FFTW_issue.zip
<https://drive.google.com/file/d/0BxuP3mON9V-qbVdQd0luc1lIb2M/view?usp=drive_web>
?

On Mon, Nov 16, 2015 at 10:07 AM, Simon Rit <simon.rit at creatis.insa-lyon.fr>
wrote:

> Hi,
> Thanks. It's really weird... When you run the tests with FFTW (compiling
> the "test" target), do they fail?
> Can you provide your geometry file? It might be specific to this geometry.
> Thanks again for looking into this issue, we'll find what's the problem.
> Simon
>
> On Mon, Nov 16, 2015 at 3:54 PM, Yang K Park <theday79 at gmail.com> wrote:
>
>> Hi Simon,
>>
>>
>>
>> Sorry for the late response.
>>
>>
>>
>> As you suggested, I?ve tried rtkramp+CUDA with only one projection and it
>> was successfully done for both w/ FFTW and w/o FFTW.
>>
>> (Two results were exactly same.)
>>
>>
>>
>> Regarding  the CUDA version, I?m using v6.5.
>>
>>
>>
>> Thanks a lot for the help!
>>
>>
>>
>> Yang
>>
>>
>>
>>
>>
>> *From:* simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of *Simon
>> Rit
>> *Sent:* Thursday, November 12, 2015 5:59 PM
>>
>> *To:* Yang K Park <theday79 at gmail.com>
>> *Cc:* rtk-users at openrtk.org
>> *Subject:* Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
>> update
>>
>>
>>
>> Hi,
>>
>> Ok. Can you try rtkramp with only one projection? Then you shouldn't
>> encounter this regions issue (that should be solved one day but that's a
>> different story).
>>
>> Can you also indicate which version of CUDA you're using?
>>
>> FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft
>> for the FFT of the projections. So if they are not in the same format,
>> you're in trouble and that might be the issue here... The weird part is
>> that I didn't reproduce this problem on linux (with and without FFTW) but
>> it might be a CUDA version difference. I'll give it another try tomorrow
>> when you provide the CUDA version.
>>
>> Thanks again for reporting the issue,
>> Simon
>>
>>
>>
>> On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com> wrote:
>>
>> Hi Simon,
>>
>>
>>
>> Thanks for the advice. The current RTK was compiled with FFTW to use the
>> phase extraction feature from Amsterdam shroud.
>>
>>
>>
>> Regarding your suggestions,
>>
>>
>>
>> 1)      rtkramp w/ or w/o CUDA:
>>
>> (command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda
>> --output Ramp_wCUDA.mha? )
>>
>>
>>
>> Then, I have encountered following error.
>>
>> ?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that
>> input requested and buffered regions are equal.?
>>
>>
>>
>>
>>
>> Without CUDA, it was successfully done.
>>
>>
>>
>> 2)      I?ve re-compiled *ITK w/o FFTW* and built RTK again. r*tkfdk
>> worked fine.*
>>
>> -          I?ve also repeated ?rtkramp+CUDA? with this rtk version and
>> the error was same as above.
>>
>>
>>
>> In conclusion, my *FFTW seems to affect CUDA-based fdk reconstruction
>> only*.
>>
>> But I do need FFTW for the phase extraction. What should I do?
>>
>>
>>
>> Thanks.
>>
>>
>>
>> Yang
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of
>> Simon Rit
>> Sent: Wednesday, November 11, 2015 4:16 PM
>> To: Yang K Park <theday79 at gmail.com>
>> Cc: rtk-users at openrtk.org
>> Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
>> update
>>
>>
>>
>> Hi,
>>
>> I didn't manage to reproduce the two problems on linux with the same ITK
>> version.
>>
>> For point 1, did you copy itkMacro.h by hand? Because I don't see how
>> replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the
>> same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW?
>> It looks like a ramp filter issue. Can you try rtkramp --path projPath
>> --regexp .*.his, with and without --hardware cuda? Maybe you can provide
>> your geometry file in case it's a specific geometric issue.
>>
>> Simon
>>
>>
>>
>> On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
>>
>> > Hi all,
>>
>> >
>>
>> >
>>
>> >
>>
>> > I?ve updated rtk with the up-to-date revision and have encountered a
>>
>> > couple of problems.
>>
>> >
>>
>> >
>>
>> >
>>
>> > 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
>>
>> > rtkCudaUtilities.hcu. It was solved by a minor fetching:
>>
>> >
>>
>> > #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>>
>> >
>>
>> >
>>
>> >
>>
>> > 2.       Output of rtkfdk with CUDA was not the same as before. It was
>> very
>>
>> > blurry as seen in the attached image.
>>
>> >
>>
>> > a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>
>> > I?m using VS2013 with win7, itk4.8.1.
>>
>> >
>>
>> >
>>
>> >
>>
>> > The command line I used was :
>>
>> >
>>
>> > rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his
>>
>> > --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware
>>
>> > cuda --pad 1 --hann 5 --hannY 5
>>
>> >
>>
>> >
>>
>> >
>>
>> > Does anyone have any idea about this?
>>
>> >
>>
>> >
>>
>> >
>>
>> > Thanks.
>>
>> >
>>
>> >
>>
>> >
>>
>> > Yang
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>
>> > _______________________________________________
>>
>> > 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/20151116/90d2c5a0/attachment-0005.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151116/90d2c5a0/attachment-0005.png>

From simon.rit at creatis.insa-lyon.fr  Fri Nov 20 11:28:22 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Fri, 20 Nov 2015 17:28:22 +0100
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAJM7=xjBjx=FzLazWJWqJbV5d45zGi2U71NKejm9HxKhJ0-xLQ@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
 <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
 <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>
 <CAJM7=xjBjx=FzLazWJWqJbV5d45zGi2U71NKejm9HxKhJ0-xLQ@mail.gmail.com>
Message-ID: <CAF0oig027_u_9gb8bnwT1w9jr3epZ0hkd9Mt73qK5heUq_kCkg@mail.gmail.com>

Hi Yang,
Thanks a lot for sharing the data. I have good news. I could reproduce the
bug and I have solutions. First, about your dataset: it's a huge dataset
and the hannY requires zero padding in both x and y. Because of this, cufft
has to take the 2D FFT of projection subsets that are 4095x2048x16. Quite
big!
When I ran it on my cuda 7.0, I immediately got:

itk::ExceptionObject (0x8b9cb30)
Location: "void CUDA_fft_convolution(const int3&, const int2&, float*,
cufftComplex*)"
File: /home/srit/src/rtk/rtk/code/rtkCudaFFTConvolutionImageFilter.cu
Line: 97
Description: itk::ERROR: CUFFT ERROR #2

i.e., a GPU alloc issue, even if I have the largest possible memory on a
nvidia desktop computer. Then, I ran it with cuda 6.5 and I got no error
message but a result similar to yours.
Conclusions:
- if you add the option --subsetsize 1 to your rtkfdk command line, that
should reconstruct correctly
- if you upgrade cuda, you should get an understandable error message,
- I don't think I'm going to look for a solution because the pb is probably
in cufft but if someone is willing to, be my guest!
Simon

On Mon, Nov 16, 2015 at 4:47 PM, Yang-Kyun Park <theday79 at gmail.com> wrote:

> Hi Simon,
>
> For better understanding, I'm attaching the problematic case including
> projection files, geometry file(xml) and reconstructed images.(please find
> the GDrive links. The file size is ~800 MB)
> This is phantom data and there is no patient information in it.
>
> Regarding the fftw library, I'm using [fftw-3.3.4-dll64].
>
> By the way, I found another clue. When I've tried it with a head phantom
> image (full-fan, ~ 190 projections), there was no problem. Is there any
> possibility that DDF and parker short filter play some roles on this issue?
>
> Feel free to let me know if further data is needed.
>
> Thanks!
>
> Yang
>
> ?
>  FFTW_issue.zip
> <https://drive.google.com/file/d/0BxuP3mON9V-qbVdQd0luc1lIb2M/view?usp=drive_web>
> ?
>
> On Mon, Nov 16, 2015 at 10:07 AM, Simon Rit <
> simon.rit at creatis.insa-lyon.fr> wrote:
>
>> Hi,
>> Thanks. It's really weird... When you run the tests with FFTW (compiling
>> the "test" target), do they fail?
>> Can you provide your geometry file? It might be specific to this geometry.
>> Thanks again for looking into this issue, we'll find what's the problem.
>> Simon
>>
>> On Mon, Nov 16, 2015 at 3:54 PM, Yang K Park <theday79 at gmail.com> wrote:
>>
>>> Hi Simon,
>>>
>>>
>>>
>>> Sorry for the late response.
>>>
>>>
>>>
>>> As you suggested, I?ve tried rtkramp+CUDA with only one projection and
>>> it was successfully done for both w/ FFTW and w/o FFTW.
>>>
>>> (Two results were exactly same.)
>>>
>>>
>>>
>>> Regarding  the CUDA version, I?m using v6.5.
>>>
>>>
>>>
>>> Thanks a lot for the help!
>>>
>>>
>>>
>>> Yang
>>>
>>>
>>>
>>>
>>>
>>> *From:* simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of *Simon
>>> Rit
>>> *Sent:* Thursday, November 12, 2015 5:59 PM
>>>
>>> *To:* Yang K Park <theday79 at gmail.com>
>>> *Cc:* rtk-users at openrtk.org
>>> *Subject:* Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
>>> update
>>>
>>>
>>>
>>> Hi,
>>>
>>> Ok. Can you try rtkramp with only one projection? Then you shouldn't
>>> encounter this regions issue (that should be solved one day but that's a
>>> different story).
>>>
>>> Can you also indicate which version of CUDA you're using?
>>>
>>> FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft
>>> for the FFT of the projections. So if they are not in the same format,
>>> you're in trouble and that might be the issue here... The weird part is
>>> that I didn't reproduce this problem on linux (with and without FFTW) but
>>> it might be a CUDA version difference. I'll give it another try tomorrow
>>> when you provide the CUDA version.
>>>
>>> Thanks again for reporting the issue,
>>> Simon
>>>
>>>
>>>
>>> On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com>
>>> wrote:
>>>
>>> Hi Simon,
>>>
>>>
>>>
>>> Thanks for the advice. The current RTK was compiled with FFTW to use the
>>> phase extraction feature from Amsterdam shroud.
>>>
>>>
>>>
>>> Regarding your suggestions,
>>>
>>>
>>>
>>> 1)      rtkramp w/ or w/o CUDA:
>>>
>>> (command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda
>>> --output Ramp_wCUDA.mha? )
>>>
>>>
>>>
>>> Then, I have encountered following error.
>>>
>>> ?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that
>>> input requested and buffered regions are equal.?
>>>
>>>
>>>
>>>
>>>
>>> Without CUDA, it was successfully done.
>>>
>>>
>>>
>>> 2)      I?ve re-compiled *ITK w/o FFTW* and built RTK again. r*tkfdk
>>> worked fine.*
>>>
>>> -          I?ve also repeated ?rtkramp+CUDA? with this rtk version and
>>> the error was same as above.
>>>
>>>
>>>
>>> In conclusion, my *FFTW seems to affect CUDA-based fdk reconstruction
>>> only*.
>>>
>>> But I do need FFTW for the phase extraction. What should I do?
>>>
>>>
>>>
>>> Thanks.
>>>
>>>
>>>
>>> Yang
>>>
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of
>>> Simon Rit
>>> Sent: Wednesday, November 11, 2015 4:16 PM
>>> To: Yang K Park <theday79 at gmail.com>
>>> Cc: rtk-users at openrtk.org
>>> Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
>>> update
>>>
>>>
>>>
>>> Hi,
>>>
>>> I didn't manage to reproduce the two problems on linux with the same ITK
>>> version.
>>>
>>> For point 1, did you copy itkMacro.h by hand? Because I don't see how
>>> replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the
>>> same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW?
>>> It looks like a ramp filter issue. Can you try rtkramp --path projPath
>>> --regexp .*.his, with and without --hardware cuda? Maybe you can provide
>>> your geometry file in case it's a specific geometric issue.
>>>
>>> Simon
>>>
>>>
>>>
>>> On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
>>>
>>> > Hi all,
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > I?ve updated rtk with the up-to-date revision and have encountered a
>>>
>>> > couple of problems.
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
>>>
>>> > rtkCudaUtilities.hcu. It was solved by a minor fetching:
>>>
>>> >
>>>
>>> > #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > 2.       Output of rtkfdk with CUDA was not the same as before. It was
>>> very
>>>
>>> > blurry as seen in the attached image.
>>>
>>> >
>>>
>>> > a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > I?m using VS2013 with win7, itk4.8.1.
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > The command line I used was :
>>>
>>> >
>>>
>>> > rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his
>>>
>>> > --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware
>>>
>>> > cuda --pad 1 --hann 5 --hannY 5
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > Does anyone have any idea about this?
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > Thanks.
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > Yang
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > _______________________________________________
>>>
>>> > 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/20151120/4e6c0e1e/attachment-0005.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151120/4e6c0e1e/attachment-0005.png>

From theday79 at gmail.com  Fri Nov 20 12:36:51 2015
From: theday79 at gmail.com (Yang K Park)
Date: Fri, 20 Nov 2015 12:36:51 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAF0oig027_u_9gb8bnwT1w9jr3epZ0hkd9Mt73qK5heUq_kCkg@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
 <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
 <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>
 <CAJM7=xjBjx=FzLazWJWqJbV5d45zGi2U71NKejm9HxKhJ0-xLQ@mail.gmail.com>
 <CAF0oig027_u_9gb8bnwT1w9jr3epZ0hkd9Mt73qK5heUq_kCkg@mail.gmail.com>
Message-ID: <000901d123ba$0ae3de50$20ab9af0$@gmail.com>

Hi Simon,

 

That sounds great! Thanks a lot for your hard work.

As you said, now I can reconstruct it successfully with --subsetsize option.

 

I think the only concern left is the elongated reconstruction time.

I?ve measured it for the same phantom image with different ?subsetsize? values as well as w/o FFTW compiling.

I just report it for your information.

 

1)      w/o FFTW  : 21.4 s

2)      w/ FFTW & --subsetsize 1: 89 s

3)      w/ FFTW & --subsetsize 2: 77 s

4)      w/ FFTW & --subsetsize 4: 65 s

5)      w/ FFTW & --subsetsize 6: 51 s

6)      w/ FFTW & --subsetsize 7: (Error-graphic card seemed to be freezed)

7)      w/ FFTW & --subsetsize 8: (Error-?itk::ERROR: CUFFT ERROR #2 in rtkCudaFFTConvolutionImageFilter.cu?)

 

Of course, the difference was coming from the Ramp filter.

Therefore, I?m going to use [--subsetsize 6] for my system and will update CUDA version soon!

 

Thanks.

 

Yang

 

 

From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit
Sent: Friday, November 20, 2015 11:28 AM
To: Yang-Kyun Park <theday79 at gmail.com>
Cc: rtk-users at openrtk.org
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi Yang,
Thanks a lot for sharing the data. I have good news. I could reproduce the bug and I have solutions. First, about your dataset: it's a huge dataset and the hannY requires zero padding in both x and y. Because of this, cufft has to take the 2D FFT of projection subsets that are 4095x2048x16. Quite big!

When I ran it on my cuda 7.0, I immediately got:

itk::ExceptionObject (0x8b9cb30)
Location: "void CUDA_fft_convolution(const int3&, const int2&, float*, cufftComplex*)" 
File: /home/srit/src/rtk/rtk/code/rtkCudaFFTConvolutionImageFilter.cu
Line: 97
Description: itk::ERROR: CUFFT ERROR #2

i.e., a GPU alloc issue, even if I have the largest possible memory on a nvidia desktop computer. Then, I ran it with cuda 6.5 and I got no error message but a result similar to yours.

Conclusions:

- if you add the option --subsetsize 1 to your rtkfdk command line, that should reconstruct correctly

- if you upgrade cuda, you should get an understandable error message,

- I don't think I'm going to look for a solution because the pb is probably in cufft but if someone is willing to, be my guest!

Simon

 

On Mon, Nov 16, 2015 at 4:47 PM, Yang-Kyun Park <theday79 at gmail.com <mailto:theday79 at gmail.com> > wrote:

Hi Simon,

 

For better understanding, I'm attaching the problematic case including projection files, geometry file(xml) and reconstructed images.(please find the GDrive links. The file size is ~800 MB)

This is phantom data and there is no patient information in it.

 

Regarding the fftw library, I'm using [fftw-3.3.4-dll64].

 

By the way, I found another clue. When I've tried it with a head phantom image (full-fan, ~ 190 projections), there was no problem. Is there any possibility that DDF and parker short filter play some roles on this issue?

 

Feel free to let me know if further data is needed.

 

Thanks!

 

Yang

 

?

 <https://drive.google.com/file/d/0BxuP3mON9V-qbVdQd0luc1lIb2M/view?usp=drive_web>  FFTW_issue.zip

?

 

On Mon, Nov 16, 2015 at 10:07 AM, Simon Rit <simon.rit at creatis.insa-lyon.fr <mailto:simon.rit at creatis.insa-lyon.fr> > wrote:

Hi,

Thanks. It's really weird... When you run the tests with FFTW (compiling the "test" target), do they fail?
Can you provide your geometry file? It might be specific to this geometry.

Thanks again for looking into this issue, we'll find what's the problem.

Simon

 

On Mon, Nov 16, 2015 at 3:54 PM, Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> > wrote:

Hi Simon,

 

Sorry for the late response.

 

As you suggested, I?ve tried rtkramp+CUDA with only one projection and it was successfully done for both w/ FFTW and w/o FFTW.

(Two results were exactly same.)

 

Regarding  the CUDA version, I?m using v6.5.

 

Thanks a lot for the help!

 

Yang

 

 

From: simon.rit at gmail.com <mailto:simon.rit at gmail.com>  [mailto:simon.rit at gmail.com <mailto:simon.rit at gmail.com> ] On Behalf Of Simon Rit
Sent: Thursday, November 12, 2015 5:59 PM


To: Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> >
Cc: rtk-users at openrtk.org <mailto:rtk-users at openrtk.org> 
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

Ok. Can you try rtkramp with only one projection? Then you shouldn't encounter this regions issue (that should be solved one day but that's a different story). 

Can you also indicate which version of CUDA you're using?

FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft for the FFT of the projections. So if they are not in the same format, you're in trouble and that might be the issue here... The weird part is that I didn't reproduce this problem on linux (with and without FFTW) but it might be a CUDA version difference. I'll give it another try tomorrow when you provide the CUDA version.

Thanks again for reporting the issue,
Simon

 

On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> > wrote:

Hi Simon,

 

Thanks for the advice. The current RTK was compiled with FFTW to use the phase extraction feature from Amsterdam shroud.

 

Regarding your suggestions,

 

1)      rtkramp w/ or w/o CUDA:

(command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda --output Ramp_wCUDA.mha? )

 

Then, I have encountered following error.

?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that input requested and buffered regions are equal.?

 



 

Without CUDA, it was successfully done.

 

2)      I?ve re-compiled ITK w/o FFTW and built RTK again. rtkfdk worked fine.

-          I?ve also repeated ?rtkramp+CUDA? with this rtk version and the error was same as above.

 

In conclusion, my FFTW seems to affect CUDA-based fdk reconstruction only.

But I do need FFTW for the phase extraction. What should I do?

 

Thanks.

 

Yang

 

 

-----Original Message-----
From: simon.rit at gmail.com <mailto:simon.rit at gmail.com>  [mailto:simon.rit at gmail.com <mailto:simon.rit at gmail.com> ] On Behalf Of Simon Rit
Sent: Wednesday, November 11, 2015 4:16 PM
To: Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> >
Cc: rtk-users at openrtk.org <mailto:rtk-users at openrtk.org> 
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

I didn't manage to reproduce the two problems on linux with the same ITK version.

For point 1, did you copy itkMacro.h by hand? Because I don't see how replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW? It looks like a ramp filter issue. Can you try rtkramp --path projPath --regexp .*.his, with and without --hardware cuda? Maybe you can provide your geometry file in case it's a specific geometric issue.

Simon

 

On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park < <mailto:theday79 at gmail.com> theday79 at gmail.com> wrote:

> Hi all,

> 

> 

> 

> I?ve updated rtk with the up-to-date revision and have encountered a 

> couple of problems.

> 

> 

> 

> 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled

> rtkCudaUtilities.hcu. It was solved by a minor fetching:

> 

> #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu

> 

> 

> 

> 2.       Output of rtkfdk with CUDA was not the same as before. It was very

> blurry as seen in the attached image.

> 

> a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.

> 

> 

> 

> 

> 

> I?m using VS2013 with win7, itk4.8.1.

> 

> 

> 

> The command line I used was :

> 

> rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his 

> --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware 

> cuda --pad 1 --hann 5 --hannY 5

> 

> 

> 

> Does anyone have any idea about this?

> 

> 

> 

> Thanks.

> 

> 

> 

> Yang

> 

> 

> 

> 

> _______________________________________________

> Rtk-users mailing list

>  <mailto: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/20151120/0d98ace1/attachment-0005.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151120/0d98ace1/attachment-0005.png>

From simon.rit at creatis.insa-lyon.fr  Wed Nov 25 02:36:44 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Wed, 25 Nov 2015 08:36:44 +0100
Subject: [Rtk-users] Compiling Problem
In-Reply-To: <040e01d125c7$83648e60$8a2dab20$@126.com>
References: <040e01d125c7$83648e60$8a2dab20$@126.com>
Message-ID: <5655650C.1040500@creatis.insa-lyon.fr>

Hi,
Please use the mailing list. I don't know where does the linking problem 
come from and it seems to work on our side:
http://my.cdash.org/index.php?project=RTK
Have you tried disabling CUDA?
Simon

On 23/11/2015 09:18, Freyman li wrote:
>
> Dear Simon,
>
> Recently I configured the RTK tool and suffer some problems. After set 
> up the itk tool and cuda, I compiled the rtk application but 
> encountered two errors attached to the email(jpg format)
>
> CUDA and ITK environment are tested successfully. My compile tool is 
> Visual studio 2012(64bit) and CUDA version is v6.5.
>
> Can you tell me how to deal with it and I am looking forward to hear 
> you again.
>
> Thank you!
>
> Best Regards
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151125/285f7f3c/attachment-0005.html>

From theday79 at gmail.com  Wed Nov 25 12:38:52 2015
From: theday79 at gmail.com (Yang K Park)
Date: Wed, 25 Nov 2015 12:38:52 -0500
Subject: [Rtk-users] Compiling Problem
In-Reply-To: <5655650C.1040500@creatis.insa-lyon.fr>
References: <040e01d125c7$83648e60$8a2dab20$@126.com>
 <5655650C.1040500@creatis.insa-lyon.fr>
Message-ID: <003d01d127a8$27a52b60$76ef8220$@gmail.com>

Hi Freyman,

 

I think your setting is much similar to mine, since I have compiled RTK with
VS2013 and CUDA v6.5 several times. Can you post those error messages again
so that I can see?

Yang

 

 

From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of
Simon Rit
Sent: Wednesday, November 25, 2015 2:37 AM
To: Freyman li <lihanwei_1500 at 126.com>
Cc: rtk-users at openrtk.org
Subject: Re: [Rtk-users] Compiling Problem

 

Hi,
Please use the mailing list. I don't know where does the linking problem
come from and it seems to work on our side:
http://my.cdash.org/index.php?project=RTK
Have you tried disabling CUDA?
Simon

On 23/11/2015 09:18, Freyman li wrote:

Dear Simon,

 

Recently I configured the RTK tool and suffer some problems. After set up
the itk tool and cuda, I compiled the rtk application but encountered two
errors attached to the email(jpg format)

CUDA and ITK environment are tested successfully. My compile tool is Visual
studio 2012(64bit) and CUDA version is v6.5.

Can you tell me how to deal with it and I am looking forward to hear you
again.

Thank you!

 

Best Regards

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151125/984feb50/attachment-0005.html>

From bioniloofar at gmail.com  Mon Nov 30 06:06:41 2015
From: bioniloofar at gmail.com (niloufar teyfouri)
Date: Mon, 30 Nov 2015 14:36:41 +0330
Subject: [Rtk-users] ElectaReconstruction
Message-ID: <CALChM12F4PuiLvgENg3Yyn7E+uZ7iPJ+GiY04z7VQ-90AS83EA@mail.gmail.com>

I ran the application of Electa Reconstruction implemented by you with
RTK. But after debugging I was encountered with the message of
"--output' ('-o') option required". Could you please help me for running
this example and the other ones?
I don't know any thing about the texts in the gray boxes mentioned at
each link related to examples of RTK.
For example in the link of
http://wiki.openrtk.org/index.php/RTK/Examples/ElektaReconstruction
how I should use gengetopt for the instructions below?


2. Run the application to convert Elekta's geometry into RTKs (DICOM_UID
is contained in the subfolder name of the his files):

  rtkelektasynergygeometry \
    --image_db IMAGE.DBF \
    --frame_db FRAME.DBF \
    --dicom_uid 1.3.46.423632.135428.1351013645.166 \
    -o elektaGeometry

I would be appreciate if one could answer my question.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151130/b11ad4e2/attachment-0005.html>

From cyril.mory at uclouvain.be  Mon Nov 30 09:30:48 2015
From: cyril.mory at uclouvain.be (Cyril Mory)
Date: Mon, 30 Nov 2015 15:30:48 +0100
Subject: [Rtk-users] ElectaReconstruction
In-Reply-To: <CALChM12F4PuiLvgENg3Yyn7E+uZ7iPJ+GiY04z7VQ-90AS83EA@mail.gmail.com>
References: <CALChM12F4PuiLvgENg3Yyn7E+uZ7iPJ+GiY04z7VQ-90AS83EA@mail.gmail.com>
Message-ID: <565C5D98.1000309@uclouvain.be>

Hi, and welcome to RTK,

Gengetopt is the piece of software that parses the command line 
arguments in all RTK applications. You do not have to "use" it. You just 
need to give correct arguments on the command line.

The message "--output' ('-o') option required" means what it says : you 
need to provide the name of the file in which you want to store the 
geometry information generated by the application 
rtkelektasynergygeometry. If you just copy-pasted the command you found 
on the wiki, then something went wrong during the copy-paste. Try to run 
the following :

rtkelektasynergygeometry --image_db IMAGE.DBF --frame_db FRAME.DBF 
--dicom_uid 1.3.46.423632.135428.1351013645.166 -o elektaGeometry

I just removed the '\' and the useless spaces. You can do the same for 
all other command line examples and it should work.

Let us know if you keep encountering trouble.
Cyril


Le 30/11/2015 12:06, niloufar teyfouri a ?crit :
>
> I ran the application of Electa Reconstruction implemented by you with
> RTK. But after debugging I was encountered with the message of
> "--output' ('-o') option required". Could you please help me for running
> this example and the other ones?
> I don't know any thing about the texts in the gray boxes mentioned at
> each link related to examples of RTK.
> For example in the link of
> http://wiki.openrtk.org/index.php/RTK/Examples/ElektaReconstruction
> how I should use gengetopt for the instructions below?
>
>
> 2. Run the application to convert Elekta's geometry into RTKs (DICOM_UID
> is contained in the subfolder name of the his files):
>
> rtkelektasynergygeometry \
> --image_db IMAGE.DBF \
> --frame_db FRAME.DBF \
> --dicom_uid 1.3.46.423632.135428.1351013645.166 \
>     -o elektaGeometry
>
> I would be appreciate if one could answer my question.
>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151130/66741755/attachment-0005.html>

From j.mason at ed.ac.uk  Mon Nov 30 11:29:27 2015
From: j.mason at ed.ac.uk (Jonathan Mason)
Date: Mon, 30 Nov 2015 16:29:27 +0000
Subject: [Rtk-users] Preprocessing
Message-ID: <565C7967.4000401@ed.ac.uk>

Good afternoon RTK users,

I have access to "raw data" from a Varian OBI scanner, and have
experimented with RTK for performing its reconstruction. However, it is
not really "raw" in the sense that the coefficients are proportional to
the photon flux recorded at a given sensor, but is instead proportional
to the Hounsfield attenuation along that path. With this data, it means
that one can reconstruct using FDK and other iterative techniques, which
assume a linear model, but the connection to the underlying physics is
abstract.

The problem I then have when trying to develop reconstruction
techniques, is that I do not know whether I am really correcting for
physical distortions or just correcting for Varian's preprocessing,
which has been finely tuned for its own FDK method.

My question is whether anybody has dug into the steps that manufacturers
such as Varian or Elekta perform to arrive at these projection images?
And if they think that if reverse engineered, could provide a richer set
of information to facilitate advanced strategies.

Best wishes,

Jonathan Mason

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.



From simon.rit at creatis.insa-lyon.fr  Mon Nov 30 12:44:03 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Mon, 30 Nov 2015 18:44:03 +0100
Subject: [Rtk-users] ElectaReconstruction
In-Reply-To: <565C5D98.1000309@uclouvain.be>
References: <CALChM12F4PuiLvgENg3Yyn7E+uZ7iPJ+GiY04z7VQ-90AS83EA@mail.gmail.com>
 <565C5D98.1000309@uclouvain.be>
Message-ID: <CAF0oig2Zg96AZaRn9w9=F+LnLnyteTn5zS1rLguQ8WXiYhnnYg@mail.gmail.com>

Hi,
I think Cyril is right, it's not possible to use backslashes to put a
command line on several line with Windows command line. Can you confirm
this? If you confirm, we will correct the wiki.
Thanks,
Simon

On Mon, Nov 30, 2015 at 3:30 PM, Cyril Mory <cyril.mory at uclouvain.be> wrote:

> Hi, and welcome to RTK,
>
> Gengetopt is the piece of software that parses the command line arguments
> in all RTK applications. You do not have to "use" it. You just need to give
> correct arguments on the command line.
>
> The message "--output' ('-o') option required" means what it says : you
> need to provide the name of the file in which you want to store the
> geometry information generated by the application rtkelektasynergygeometry.
> If you just copy-pasted the command you found on the wiki, then something
> went wrong during the copy-paste. Try to run the following :
>
> rtkelektasynergygeometry --image_db IMAGE.DBF --frame_db FRAME.DBF
> --dicom_uid 1.3.46.423632.135428.1351013645.166 -o elektaGeometry
>
> I just removed the '\' and the useless spaces. You can do the same for all
> other command line examples and it should work.
>
> Let us know if you keep encountering trouble.
> Cyril
>
>
>
> Le 30/11/2015 12:06, niloufar teyfouri a ?crit :
>
>
> I ran the application of Electa Reconstruction implemented by you with
> RTK. But after debugging I was encountered with the message of
> "--output' ('-o') option required". Could you please help me for running
> this example and the other ones?
> I don't know any thing about the texts in the gray boxes mentioned at
> each link related to examples of RTK.
> For example in the link of
> http://wiki.openrtk.org/index.php/RTK/Examples/ElektaReconstruction
> how I should use gengetopt for the instructions below?
>
>
> 2. Run the application to convert Elekta's geometry into RTKs (DICOM_UID
> is contained in the subfolder name of the his files):
>
>   rtkelektasynergygeometry \
>     --image_db IMAGE.DBF \
>     --frame_db FRAME.DBF \
>     --dicom_uid 1.3.46.423632.135428.1351013645.166 \
>     -o elektaGeometry
>
> I would be appreciate if one could answer my question.
>
>
> _______________________________________________
> Rtk-users mailing listRtk-users at public.kitware.comhttp://public.kitware.com/mailman/listinfo/rtk-users
>
>
>
>
> ------------------------------
> [image: Avast logo] <https://www.avast.com/antivirus>
>
> L'absence de virus dans ce courrier ?lectronique a ?t? v?rifi?e par le
> logiciel antivirus Avast.
> www.avast.com <https://www.avast.com/antivirus>
>
>
> _______________________________________________
> 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/20151130/6d6dd6aa/attachment-0005.html>

From wuchao04 at gmail.com  Mon Nov 30 13:50:06 2015
From: wuchao04 at gmail.com (Chao Wu)
Date: Mon, 30 Nov 2015 19:50:06 +0100
Subject: [Rtk-users] Preprocessing
In-Reply-To: <565C7967.4000401@ed.ac.uk>
References: <565C7967.4000401@ed.ac.uk>
Message-ID: <CAH+sHrUFov5f=8h4-ePhC2xLraM3BxA9r12yfXdM3rrKPeqCBg@mail.gmail.com>

Hi Jonathan,

I do not quite understand your problem.
I think most information can be retrieved by the relationship between flux
(I) and attenuation (u):
I = I0 * exp (- integral(u * dL) )
Of course there are other effects like beam hardening and scattering
involved but this model is the basic.

Regards,
Chao

2015-11-30 17:29 GMT+01:00 Jonathan Mason <j.mason at ed.ac.uk>:

> Good afternoon RTK users,
>
> I have access to "raw data" from a Varian OBI scanner, and have
> experimented with RTK for performing its reconstruction. However, it is
> not really "raw" in the sense that the coefficients are proportional to
> the photon flux recorded at a given sensor, but is instead proportional
> to the Hounsfield attenuation along that path. With this data, it means
> that one can reconstruct using FDK and other iterative techniques, which
> assume a linear model, but the connection to the underlying physics is
> abstract.
>
> The problem I then have when trying to develop reconstruction
> techniques, is that I do not know whether I am really correcting for
> physical distortions or just correcting for Varian's preprocessing,
> which has been finely tuned for its own FDK method.
>
> My question is whether anybody has dug into the steps that manufacturers
> such as Varian or Elekta perform to arrive at these projection images?
> And if they think that if reverse engineered, could provide a richer set
> of information to facilitate advanced strategies.
>
> Best wishes,
>
> Jonathan Mason
>
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
> _______________________________________________
> 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/20151130/ccb833fe/attachment-0005.html>

From mdupont at cppm.in2p3.fr  Sun Nov  1 12:41:49 2015
From: mdupont at cppm.in2p3.fr (Mathieu Dupont)
Date: Sun, 01 Nov 2015 18:41:49 +0100
Subject: [Rtk-users] question about rtkDraw*ImageFilter
In-Reply-To: <56334CF2.8070902@cppm.in2p3.fr>
References: <5630EE01.5070900@cppm.in2p3.fr>
 <CAF0oig279ZWGJMFnJdXaPiYLPponadz_J-PVKt2z3iHiTRQ_gg@mail.gmail.com>
 <56334CF2.8070902@cppm.in2p3.fr>
Message-ID: <1539144.WPSdtJ8lhZ@marabunta>

Hello Simon, 

I started to implement what I suggested : 

https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawImageFilter.h
and 
https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawCylinderImageFilter.h

rtk::DrawCylinderImageFilter derives from rtk::DrawImageFilter and specializes 
it (by defaulting the template parameter TSpatialObject with 
DrawCylinderSpatialObject). 

By default, DrawCylinderImageFilter uses Add2 for filling output image (to be 
backward compatible (all tests pass)). I created Discard (I did not find 
equivalent in itk) functor in order to do what I wanted in my first email.  

I just implemented DrawCylinderImageFilter, the others will follow. 

What do you think about it ?

Le vendredi 30 octobre 2015, 11:56:50 Mathieu Dupont a ?crit :
> Hi,
> 
> In case of your first solution, you can not chain several
> Draw*ImageFilters. For example, if you want to create small cylinders in
> a big cylinder.
> 
> Your second solution is better.
> 
> One another solution can be a thing like itk:SpatialObject but more
> simpler. An rtk::SpatialObject which one function (isInside(point)). We
> create a rtkDrawImageFilter class and implement ThreadedGenerateData
> like this :
> 
> DrawImageFilter<InImage, OutImage, rtkSpatialObject,
> rtkFillFunctor>::ThreadedGenerateData(const OutputImageRegionType&
> outputRegionForThread,                 ThreadIdType itkNotUsed(threadId)
> {
> ...
> 
>   while( !itOut.IsAtEnd() )
>      {
>      this->GetInput()->TransformIndexToPhysicalPoint(itOut.GetIndex(),
> point);
> 
>     if(m_rtkSpatialObject.isInside(point)
>       itOut.Set(m_rtkFillFunctor(density, itIn.Get());
> ...
> }
> 
> 
> DrawConeImageFilter class can be a child of this new DrawImageFilter
> (with new methods like setAngle, SetRadius which will adjust the
> rtkConeSpatialObject)
> 
> This solution suppress duplicated code in
> Draw*ImageFilter::ThreadedGenerateData and makes easier implementation
> of another type of filling.
> 
> On 28/10/2015 20:52, Simon Rit wrote:
> > Hi Mathieu,
> > Thanks for pointing this out. I agree that it might not be the best
> > solution, yet one could argue that you could simply create a constant
> > image with 0 to do what you'd like from the current implementation. My
> > main problem is that I just tried to do what you suggest and some tests
> > then fail... which shows the obvious, it's not a backward compatible
> > change. I see two solutions:
> > - keep it as is and you use ConstantImageFilter + we remove useless add
> > filters,
> > - a more complex but maybe more elegant solution: add a third template
> > parameter for the operation that would allow the user to do what he'd
> > like in a functor. That's what's done with filters that derive from
> > itk::UnaryImageFilter
> > <http://www.itk.org/Doxygen/html/classitk_1_1UnaryFunctorImageFilter.html>
> > .
> > The default would be itk::Add2 but we could find or implement another
> > one that simply discards the pixel value.
> > What do you think?
> > Simon
> > 
> > PS: looking in the code, I just found that rtk::DrawConeImageFilter is
> > not consistent with the others, it was always setting to 0 outside...
> > that's been fixed!
> > 
> > On Wed, Oct 28, 2015 at 4:47 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr
> > 
> > <mailto:mdupont at cppm.in2p3.fr>> wrote:
> >     Hello everyone,
> >     
> >     I have a question/suggestion about the set of rtkDraw*ImageFilter.
> >     This filter are written as additive filters: for example, in
> >     rtkDrawEllipsoidImageFilter.txx, we can find
> >     
> >     for(..)
> >     
> >       itOut.Set( ellipsoid.density + itIn.Get() )
> >     
> >     instead of
> >     
> >     for(..)
> >     itOut.Set( ellipsoid.density )
> >     
> >     
> >     I think it can be more flexible the second option, because we can
> >     always associate Draw*ImageFilter and itkAddImageFilter to get an
> >     additive filter.
> >     
> >     Moreover, the  rtkDrawGeometricPhantomImageFilter class already uses
> >     itkAddImageFilter in order to have additive filters (which is
> >     redundant in current situation).
> >     
> >     What do you think ?
> >     
> >     
> >     
> >     
> >     
> >     Regards
> >     
> >     
> >     
> >     _______________________________________________
> >     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


From gnthibault at gmail.com  Mon Nov  2 08:08:42 2015
From: gnthibault at gmail.com (Notargiacomo Thibault)
Date: Mon, 2 Nov 2015 14:08:42 +0100
Subject: [Rtk-users] Problem with rtkGgoFunctions when importing series of
	images
Message-ID: <CAP+mR7Zw7WmRmEgVUTamNhS6m4S6ORvWFjRu1EANViPRJ7jtuQ@mail.gmail.com>

I recently experienced the following problem, when importing multiple tif
files inside a directory using itk::ImageSeriesReader:

[...]
code/rtkGgoFunctions.h: In instantiation of ?void
rtk::SetProjectionsReaderFromGgo(typename TProjectionsReaderType::Pointer,
const TArgsInfo&)
[...]
code/rtkGgoFunctions.h:121:61: error: no type named
?OutputImageDirectionType? in ?class
itk::ImageSeriesReader<itk::Image<short unsigned int, 3u> >?
   typename TProjectionsReaderType::OutputImageDirectionType direction;
[...]

It seems that, a new functionality added in rtkGgoFunctions.h (19/05/2015),
allowing to directly modify input images properties through command line,
like geometry (direction vector), assumes that the input image type defines
OutputImageDirectionType, but in the case of itk::ImageSeriesReader, it
does not.

Is this considered as a regression, or should the
SetProjectionsReaderFromGgo function be used with specific input image type
?

Thank you in advance for your help.

Kind regards

Thibault Notargiacomo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151102/6cad3583/attachment-0006.html>

From simon.rit at creatis.insa-lyon.fr  Mon Nov  2 08:58:24 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Mon, 2 Nov 2015 14:58:24 +0100
Subject: [Rtk-users] Problem with rtkGgoFunctions when importing series
	of images
In-Reply-To: <CAP+mR7Zw7WmRmEgVUTamNhS6m4S6ORvWFjRu1EANViPRJ7jtuQ@mail.gmail.com>
References: <CAP+mR7Zw7WmRmEgVUTamNhS6m4S6ORvWFjRu1EANViPRJ7jtuQ@mail.gmail.com>
Message-ID: <CAF0oig2bAidO4JR7pa_PUxOQm-X7JrEz8=ybGX3bskYJM9YRAQ@mail.gmail.com>

Hi Thibault,
SetProjectionsReaderFromGgo is a macro designed for the
rtk::ProjectionsReader
<http://www.openrtk.org/Doxygen/classrtk_1_1ProjectionsReader.html>, I'm
not surprised that it does not work with the itk::ImageSeriesReader. It's
not about the image type but about the filter type... We use this macro to
set many parameters specific to the rtk::ProjectionsReader
<http://www.openrtk.org/Doxygen/classrtk_1_1ProjectionsReader.html>. Since
a while, I have made have a common rtkinputprojections_section.ggo
<https://github.com/SimonRit/RTK/blob/master/applications/rtkinputprojections_section.ggo>
file for all the applications that use the rtk::ProjectionsReader.
If you don't want to use the rtk::ProjectionsReader but
itk::ImageSeriesReader (e.g., because it does a lot of automatic processing
that you don't want), you'll have to write your own code to set it up.
I hope this clarifies things.
Simon

On Mon, Nov 2, 2015 at 2:08 PM, Notargiacomo Thibault <gnthibault at gmail.com>
wrote:

> I recently experienced the following problem, when importing multiple tif
> files inside a directory using itk::ImageSeriesReader:
>
> [...]
> code/rtkGgoFunctions.h: In instantiation of ?void
> rtk::SetProjectionsReaderFromGgo(typename TProjectionsReaderType::Pointer,
> const TArgsInfo&)
> [...]
> code/rtkGgoFunctions.h:121:61: error: no type named
> ?OutputImageDirectionType? in ?class
> itk::ImageSeriesReader<itk::Image<short unsigned int, 3u> >?
>    typename TProjectionsReaderType::OutputImageDirectionType direction;
> [...]
>
> It seems that, a new functionality added in rtkGgoFunctions.h
> (19/05/2015), allowing to directly modify input images properties through
> command line, like geometry (direction vector), assumes that the input
> image type defines OutputImageDirectionType, but in the case of
> itk::ImageSeriesReader, it does not.
>
> Is this considered as a regression, or should the
> SetProjectionsReaderFromGgo function be used with specific input image type
> ?
>
> Thank you in advance for your help.
>
> Kind regards
>
> Thibault Notargiacomo
>
> _______________________________________________
> 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/20151102/ee7e2c17/attachment-0006.html>

From simon.rit at creatis.insa-lyon.fr  Wed Nov  4 16:38:18 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Wed, 4 Nov 2015 22:38:18 +0100
Subject: [Rtk-users] question about rtkDraw*ImageFilter
In-Reply-To: <1539144.WPSdtJ8lhZ@marabunta>
References: <5630EE01.5070900@cppm.in2p3.fr>
 <CAF0oig279ZWGJMFnJdXaPiYLPponadz_J-PVKt2z3iHiTRQ_gg@mail.gmail.com>
 <56334CF2.8070902@cppm.in2p3.fr> <1539144.WPSdtJ8lhZ@marabunta>
Message-ID: <CAF0oig3jBsfoadM_k6SYvOMwikOCNFmH19J7m1YJZx-RU0y+5g@mail.gmail.com>

Hi Mathieu,
Sorry, I'm very busy these days. I had a first quick look. Why not, it
looks a bit complicated but good. I would have a few things I would change
style wise, e.g., move DrawCylinderSpatialObject to
DrawCylinderImageFilter, create a common DrawQuadricSpatialObject that
would all have the same IsInside function, make DrawSpatialObjectpurely
virtual by not defining
IsInside etc. but those are details I can correct myself. Do you want to
finish what you started and I work from there or should I finish everything?
Simon

On Sun, Nov 1, 2015 at 6:41 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr>
wrote:

> Hello Simon,
>
> I started to implement what I suggested :
>
>
> https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawImageFilter.h
> and
>
> https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawCylinderImageFilter.h
>
> rtk::DrawCylinderImageFilter derives from rtk::DrawImageFilter and
> specializes
> it (by defaulting the template parameter TSpatialObject with
> DrawCylinderSpatialObject).
>
> By default, DrawCylinderImageFilter uses Add2 for filling output image (to
> be
> backward compatible (all tests pass)). I created Discard (I did not find
> equivalent in itk) functor in order to do what I wanted in my first email.
>
> I just implemented DrawCylinderImageFilter, the others will follow.
>
> What do you think about it ?
>
> Le vendredi 30 octobre 2015, 11:56:50 Mathieu Dupont a ?crit :
> > Hi,
> >
> > In case of your first solution, you can not chain several
> > Draw*ImageFilters. For example, if you want to create small cylinders in
> > a big cylinder.
> >
> > Your second solution is better.
> >
> > One another solution can be a thing like itk:SpatialObject but more
> > simpler. An rtk::SpatialObject which one function (isInside(point)). We
> > create a rtkDrawImageFilter class and implement ThreadedGenerateData
> > like this :
> >
> > DrawImageFilter<InImage, OutImage, rtkSpatialObject,
> > rtkFillFunctor>::ThreadedGenerateData(const OutputImageRegionType&
> > outputRegionForThread,                 ThreadIdType itkNotUsed(threadId)
> > {
> > ...
> >
> >   while( !itOut.IsAtEnd() )
> >      {
> >      this->GetInput()->TransformIndexToPhysicalPoint(itOut.GetIndex(),
> > point);
> >
> >     if(m_rtkSpatialObject.isInside(point)
> >       itOut.Set(m_rtkFillFunctor(density, itIn.Get());
> > ...
> > }
> >
> >
> > DrawConeImageFilter class can be a child of this new DrawImageFilter
> > (with new methods like setAngle, SetRadius which will adjust the
> > rtkConeSpatialObject)
> >
> > This solution suppress duplicated code in
> > Draw*ImageFilter::ThreadedGenerateData and makes easier implementation
> > of another type of filling.
> >
> > On 28/10/2015 20:52, Simon Rit wrote:
> > > Hi Mathieu,
> > > Thanks for pointing this out. I agree that it might not be the best
> > > solution, yet one could argue that you could simply create a constant
> > > image with 0 to do what you'd like from the current implementation. My
> > > main problem is that I just tried to do what you suggest and some tests
> > > then fail... which shows the obvious, it's not a backward compatible
> > > change. I see two solutions:
> > > - keep it as is and you use ConstantImageFilter + we remove useless add
> > > filters,
> > > - a more complex but maybe more elegant solution: add a third template
> > > parameter for the operation that would allow the user to do what he'd
> > > like in a functor. That's what's done with filters that derive from
> > > itk::UnaryImageFilter
> > > <
> http://www.itk.org/Doxygen/html/classitk_1_1UnaryFunctorImageFilter.html>
> > > .
> > > The default would be itk::Add2 but we could find or implement another
> > > one that simply discards the pixel value.
> > > What do you think?
> > > Simon
> > >
> > > PS: looking in the code, I just found that rtk::DrawConeImageFilter is
> > > not consistent with the others, it was always setting to 0 outside...
> > > that's been fixed!
> > >
> > > On Wed, Oct 28, 2015 at 4:47 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr
> > >
> > > <mailto:mdupont at cppm.in2p3.fr>> wrote:
> > >     Hello everyone,
> > >
> > >     I have a question/suggestion about the set of rtkDraw*ImageFilter.
> > >     This filter are written as additive filters: for example, in
> > >     rtkDrawEllipsoidImageFilter.txx, we can find
> > >
> > >     for(..)
> > >
> > >       itOut.Set( ellipsoid.density + itIn.Get() )
> > >
> > >     instead of
> > >
> > >     for(..)
> > >     itOut.Set( ellipsoid.density )
> > >
> > >
> > >     I think it can be more flexible the second option, because we can
> > >     always associate Draw*ImageFilter and itkAddImageFilter to get an
> > >     additive filter.
> > >
> > >     Moreover, the  rtkDrawGeometricPhantomImageFilter class already
> uses
> > >     itkAddImageFilter in order to have additive filters (which is
> > >     redundant in current situation).
> > >
> > >     What do you think ?
> > >
> > >
> > >
> > >
> > >
> > >     Regards
> > >
> > >
> > >
> > >     _______________________________________________
> > >     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/20151104/46314d97/attachment-0006.html>

From mdupont at cppm.in2p3.fr  Mon Nov  9 14:35:47 2015
From: mdupont at cppm.in2p3.fr (Mathieu Dupont)
Date: Mon, 09 Nov 2015 20:35:47 +0100
Subject: [Rtk-users] question about rtkDraw*ImageFilter
In-Reply-To: <CAF0oig3jBsfoadM_k6SYvOMwikOCNFmH19J7m1YJZx-RU0y+5g@mail.gmail.com>
References: <5630EE01.5070900@cppm.in2p3.fr> <1539144.WPSdtJ8lhZ@marabunta>
 <CAF0oig3jBsfoadM_k6SYvOMwikOCNFmH19J7m1YJZx-RU0y+5g@mail.gmail.com>
Message-ID: <5634494.U9CmFl2V79@marabunta>

hi, 

i will do this during this week and try to implement your remarks. 


Le mercredi 4 novembre 2015, 22:38:18 Simon Rit a ?crit :
> Hi Mathieu,
> Sorry, I'm very busy these days. I had a first quick look. Why not, it
> looks a bit complicated but good. I would have a few things I would change
> style wise, e.g., move DrawCylinderSpatialObject to
> DrawCylinderImageFilter, create a common DrawQuadricSpatialObject that
> would all have the same IsInside function, make DrawSpatialObjectpurely
> virtual by not defining
> IsInside etc. but those are details I can correct myself. Do you want to
> finish what you started and I work from there or should I finish everything?
> Simon
> 
> On Sun, Nov 1, 2015 at 6:41 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr>
> 
> wrote:
> > Hello Simon,
> > 
> > I started to implement what I suggested :
> > 
> > 
> > https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawImag
> > eFilter.h and
> > 
> > https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawCyli
> > nderImageFilter.h
> > 
> > rtk::DrawCylinderImageFilter derives from rtk::DrawImageFilter and
> > specializes
> > it (by defaulting the template parameter TSpatialObject with
> > DrawCylinderSpatialObject).
> > 
> > By default, DrawCylinderImageFilter uses Add2 for filling output image (to
> > be
> > backward compatible (all tests pass)). I created Discard (I did not find
> > equivalent in itk) functor in order to do what I wanted in my first email.
> > 
> > I just implemented DrawCylinderImageFilter, the others will follow.
> > 
> > What do you think about it ?
> > 
> > Le vendredi 30 octobre 2015, 11:56:50 Mathieu Dupont a ?crit :
> > > Hi,
> > > 
> > > In case of your first solution, you can not chain several
> > > Draw*ImageFilters. For example, if you want to create small cylinders in
> > > a big cylinder.
> > > 
> > > Your second solution is better.
> > > 
> > > One another solution can be a thing like itk:SpatialObject but more
> > > simpler. An rtk::SpatialObject which one function (isInside(point)). We
> > > create a rtkDrawImageFilter class and implement ThreadedGenerateData
> > > like this :
> > > 
> > > DrawImageFilter<InImage, OutImage, rtkSpatialObject,
> > > rtkFillFunctor>::ThreadedGenerateData(const OutputImageRegionType&
> > > outputRegionForThread,                 ThreadIdType itkNotUsed(threadId)
> > > {
> > > ...
> > > 
> > >   while( !itOut.IsAtEnd() )
> > >   
> > >      {
> > >      this->GetInput()->TransformIndexToPhysicalPoint(itOut.GetIndex(),
> > > 
> > > point);
> > > 
> > >     if(m_rtkSpatialObject.isInside(point)
> > >     
> > >       itOut.Set(m_rtkFillFunctor(density, itIn.Get());
> > > 
> > > ...
> > > }
> > > 
> > > 
> > > DrawConeImageFilter class can be a child of this new DrawImageFilter
> > > (with new methods like setAngle, SetRadius which will adjust the
> > > rtkConeSpatialObject)
> > > 
> > > This solution suppress duplicated code in
> > > Draw*ImageFilter::ThreadedGenerateData and makes easier implementation
> > > of another type of filling.
> > > 
> > > On 28/10/2015 20:52, Simon Rit wrote:
> > > > Hi Mathieu,
> > > > Thanks for pointing this out. I agree that it might not be the best
> > > > solution, yet one could argue that you could simply create a constant
> > > > image with 0 to do what you'd like from the current implementation. My
> > > > main problem is that I just tried to do what you suggest and some
> > > > tests
> > > > then fail... which shows the obvious, it's not a backward compatible
> > > > change. I see two solutions:
> > > > - keep it as is and you use ConstantImageFilter + we remove useless
> > > > add
> > > > filters,
> > > > - a more complex but maybe more elegant solution: add a third template
> > > > parameter for the operation that would allow the user to do what he'd
> > > > like in a functor. That's what's done with filters that derive from
> > > > itk::UnaryImageFilter
> > > > <
> > 
> > http://www.itk.org/Doxygen/html/classitk_1_1UnaryFunctorImageFilter.html>
> > 
> > > > .
> > > > The default would be itk::Add2 but we could find or implement another
> > > > one that simply discards the pixel value.
> > > > What do you think?
> > > > Simon
> > > > 
> > > > PS: looking in the code, I just found that rtk::DrawConeImageFilter is
> > > > not consistent with the others, it was always setting to 0 outside...
> > > > that's been fixed!
> > > > 
> > > > On Wed, Oct 28, 2015 at 4:47 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr
> > > > 
> > > > <mailto:mdupont at cppm.in2p3.fr>> wrote:
> > > >     Hello everyone,
> > > >     
> > > >     I have a question/suggestion about the set of rtkDraw*ImageFilter.
> > > >     This filter are written as additive filters: for example, in
> > > >     rtkDrawEllipsoidImageFilter.txx, we can find
> > > >     
> > > >     for(..)
> > > >     
> > > >       itOut.Set( ellipsoid.density + itIn.Get() )
> > > >     
> > > >     instead of
> > > >     
> > > >     for(..)
> > > >     itOut.Set( ellipsoid.density )
> > > >     
> > > >     
> > > >     I think it can be more flexible the second option, because we can
> > > >     always associate Draw*ImageFilter and itkAddImageFilter to get an
> > > >     additive filter.
> > > >     
> > > >     Moreover, the  rtkDrawGeometricPhantomImageFilter class already
> > 
> > uses
> > 
> > > >     itkAddImageFilter in order to have additive filters (which is
> > > >     redundant in current situation).
> > > >     
> > > >     What do you think ?
> > > >     
> > > >     
> > > >     
> > > >     
> > > >     
> > > >     Regards
> > > >     
> > > >     
> > > >     
> > > >     _______________________________________________
> > > >     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


From gnthibault at gmail.com  Tue Nov 10 07:39:46 2015
From: gnthibault at gmail.com (Notargiacomo Thibault)
Date: Tue, 10 Nov 2015 13:39:46 +0100
Subject: [Rtk-users] Understanding projection matrices management in
	rtkCudaBackProjectionImageFilter
Message-ID: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>

Hi all,

I am currently trying to use the "AddProjectionInRadians" method from the
ThreeDCircularProjectionGeometry class in RTK to import my geometry.

First things first, I would like to know if the information on this pdf are
still valid: http://www.openrtk.org/Doxygen/geometry.pdf

Because I used them to deduce the source offset and Projection offset from
my own matrix decomposition.

Notice that I don't want to use geometric informations coming from the
projection images themselves, so their geometric origin is assumed to be
(0,0,0) in my case.

In order to check if my geometry import method is correct, I print out one
of the intermediate form of the projection matrix used in the
backprojection process, in order to check if it is the same as in my own
implementation.

To do so, I print out one of the intermediate matrix that is generated in
rtkCudaBackProjectionImageFilter while launching a SART reconstruction for
instance.

I was surpised by the fact that, the matrix allowing the transformation
from 2D geometric world to 2D image index world, namely matrixIdxProj in
rtkCudaBackProjectionImageFilte.cxx
<http://www.openrtk.org/Doxygen/rtkCudaBackProjectionImageFilter_8cxx_source.html>
is not always the same along the reconstruction process ?

Here is the line that generates the matrix I don't understand:

for(unsigned int i=0; i<2; i++)
 //SR: 0.5 for 2D texture
  matrixIdxProj[i][2] =
-1*(this->GetInput(1)->GetBufferedRegion().GetIndex()[i])+0.5;

What I understand here, is that, we are generating a 2D translation matrix
embedded in a 3*3 matrix that allows to take into account two things
related to the 2D projection:

-If the internal behaviour of the imageContainer, allows buffering of only
a part of the image, beginning at index (i,j), this information will be
embeded in the projection matrix

-the ITK floating point addressing definition seems to differ from the one
from cuda (and openCV):
When I take a look at this page
<http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#texture-fetching>
I understand that the floating point indexing (0.5,0.5) in Cuda points to
the center of the pixel (0,0) hence a linear contribution of 100%, while it
seems that we must add a translation of (0.5,0.5) to the ITK geometric
framework in order to get the same behaviour.

In practice matrixIdxProj is based on a 3*3 identity matrix, where the
inner 2D translation (ie 2 first term of the last column) in my case are:
-in X, a random number between 10 and 150 plus 0.5
-in Y: always 0.5

I understand the 0.5 part, but why is there always a 0 offset in Y but a
random offset in X remains a mystery to me.

At first, I believed that each projection was splitted into multiple part,
each having a different X and Y offset.
But reconstructing using only one projection generates only one
backprojection operation, with a non zero offset in X, 123 in my case, for
an image of size 780 in X.

Do you think there is something wrong whith the values of matrixIdxProjI am
experiencing ?

Thank you in advance.

Kind regards

Thibault Notargiacomo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151110/fbd3fb46/attachment-0006.html>

From simon.rit at creatis.insa-lyon.fr  Tue Nov 10 08:21:29 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Tue, 10 Nov 2015 14:21:29 +0100
Subject: [Rtk-users] Understanding projection matrices management in
	rtkCudaBackProjectionImageFilter
In-Reply-To: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>
References: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>
Message-ID: <CAF0oig3muuH+1=eLZ66DJ22QcnsSrUKzRFS4RzDRvDJXNxAVXg@mail.gmail.com>

Hi Thibault,
You started digging in the code so that gets complicated. First thing
first, yes, the link you provide is still valid.
The offset in X is not random but computed in
BackProjectionImageFilter::GenerateInputRequestedRegion
<https://github.com/SimonRit/RTK/blob/master/code/rtkBackProjectionImageFilter.txx>.
The idea is that we request only the part of the projections we need to do
the backprojection. This optimizes the streaming (we only read from disk
what we need). If you use a huge volume (the test I'd suggest to validate
that I'm correct and there is nothing wrong with your code), then you'll
need the full projection and you will always get 0 in X as in Y. If you use
a small volume and do a computation projection per projection, you will get
a varying index depending on your input volume and the geometry for that
projection.
I think you understood the rest pretty well. Does that make sense or am I
missing something else?
Simon

On Tue, Nov 10, 2015 at 1:39 PM, Notargiacomo Thibault <gnthibault at gmail.com
> wrote:

> Hi all,
>
> I am currently trying to use the "AddProjectionInRadians" method from the
> ThreeDCircularProjectionGeometry class in RTK to import my geometry.
>
> First things first, I would like to know if the information on this pdf
> are still valid: http://www.openrtk.org/Doxygen/geometry.pdf
>
> Because I used them to deduce the source offset and Projection offset from
> my own matrix decomposition.
>
> Notice that I don't want to use geometric informations coming from the
> projection images themselves, so their geometric origin is assumed to be
> (0,0,0) in my case.
>
> In order to check if my geometry import method is correct, I print out one
> of the intermediate form of the projection matrix used in the
> backprojection process, in order to check if it is the same as in my own
> implementation.
>
> To do so, I print out one of the intermediate matrix that is generated in
> rtkCudaBackProjectionImageFilter while launching a SART reconstruction for
> instance.
>
> I was surpised by the fact that, the matrix allowing the transformation
> from 2D geometric world to 2D image index world, namely matrixIdxProj in
> rtkCudaBackProjectionImageFilte.cxx
> <http://www.openrtk.org/Doxygen/rtkCudaBackProjectionImageFilter_8cxx_source.html>
> is not always the same along the reconstruction process ?
>
> Here is the line that generates the matrix I don't understand:
>
> for(unsigned int i=0; i<2; i++)
>  //SR: 0.5 for 2D texture
>   matrixIdxProj[i][2] =
> -1*(this->GetInput(1)->GetBufferedRegion().GetIndex()[i])+0.5;
>
> What I understand here, is that, we are generating a 2D translation matrix
> embedded in a 3*3 matrix that allows to take into account two things
> related to the 2D projection:
>
> -If the internal behaviour of the imageContainer, allows buffering of only
> a part of the image, beginning at index (i,j), this information will be
> embeded in the projection matrix
>
> -the ITK floating point addressing definition seems to differ from the one
> from cuda (and openCV):
> When I take a look at this page
> <http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#texture-fetching>
> I understand that the floating point indexing (0.5,0.5) in Cuda points to
> the center of the pixel (0,0) hence a linear contribution of 100%, while it
> seems that we must add a translation of (0.5,0.5) to the ITK geometric
> framework in order to get the same behaviour.
>
> In practice matrixIdxProj is based on a 3*3 identity matrix, where the
> inner 2D translation (ie 2 first term of the last column) in my case are:
> -in X, a random number between 10 and 150 plus 0.5
> -in Y: always 0.5
>
> I understand the 0.5 part, but why is there always a 0 offset in Y but a
> random offset in X remains a mystery to me.
>
> At first, I believed that each projection was splitted into multiple part,
> each having a different X and Y offset.
> But reconstructing using only one projection generates only one
> backprojection operation, with a non zero offset in X, 123 in my case, for
> an image of size 780 in X.
>
> Do you think there is something wrong whith the values of matrixIdxProjI
> am experiencing ?
>
> Thank you in advance.
>
> Kind regards
>
> Thibault Notargiacomo
>
> _______________________________________________
> 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/20151110/8b9b86e6/attachment-0006.html>

From simon.rit at creatis.insa-lyon.fr  Tue Nov 10 09:03:52 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Tue, 10 Nov 2015 15:03:52 +0100
Subject: [Rtk-users] Understanding projection matrices management in
	rtkCudaBackProjectionImageFilter
In-Reply-To: <CAP+mR7ZLJV8V5dMOW_jgM5G2-kCZhy8o0tB19685LGo-1bxLUg@mail.gmail.com>
References: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>
 <CAF0oig3muuH+1=eLZ66DJ22QcnsSrUKzRFS4RzDRvDJXNxAVXg@mail.gmail.com>
 <CAP+mR7ZLJV8V5dMOW_jgM5G2-kCZhy8o0tB19685LGo-1bxLUg@mail.gmail.com>
Message-ID: <CAF0oig3fALRnZNCJ53+TsSjBm7raRC_mqahWEU6x+D+zxwOnVQ@mail.gmail.com>

A small correction: it's actually the amount of data pre-processed (read
from disk + all the processing before backprojection) but that should
change nothing to what is backprojected.
I remembered something that can help you: you may want to run
UpdateLargestPossibleRegion() to the projections (input 1 of the
BackProjectImageFilter) before backprojection to avoid this and make things
clearer instead of using a large volume as I was suggesting before.
Simon

On Tue, Nov 10, 2015 at 2:34 PM, Notargiacomo Thibault <gnthibault at gmail.com
> wrote:

> Ok, using geometric information to reduce the amount of data to be
> backprojected is pretty clever ;)
> This explains the "random" index I was asking about in my previous
> question, I now know what it is used for and continue my debugging process.
>
> Kind regards
>
> Thibault Notargiacomo
>
> 2015-11-10 14:21 GMT+01:00 Simon Rit <simon.rit at creatis.insa-lyon.fr>:
>
>> Hi Thibault,
>> You started digging in the code so that gets complicated. First thing
>> first, yes, the link you provide is still valid.
>> The offset in X is not random but computed in
>> BackProjectionImageFilter::GenerateInputRequestedRegion
>> <https://github.com/SimonRit/RTK/blob/master/code/rtkBackProjectionImageFilter.txx>.
>> The idea is that we request only the part of the projections we need to do
>> the backprojection. This optimizes the streaming (we only read from disk
>> what we need). If you use a huge volume (the test I'd suggest to validate
>> that I'm correct and there is nothing wrong with your code), then you'll
>> need the full projection and you will always get 0 in X as in Y. If you use
>> a small volume and do a computation projection per projection, you will get
>> a varying index depending on your input volume and the geometry for that
>> projection.
>> I think you understood the rest pretty well. Does that make sense or am I
>> missing something else?
>> Simon
>>
>> On Tue, Nov 10, 2015 at 1:39 PM, Notargiacomo Thibault <
>> gnthibault at gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> I am currently trying to use the "AddProjectionInRadians" method from
>>> the ThreeDCircularProjectionGeometry class in RTK to import my geometry.
>>>
>>> First things first, I would like to know if the information on this pdf
>>> are still valid: http://www.openrtk.org/Doxygen/geometry.pdf
>>>
>>> Because I used them to deduce the source offset and Projection offset
>>> from my own matrix decomposition.
>>>
>>> Notice that I don't want to use geometric informations coming from the
>>> projection images themselves, so their geometric origin is assumed to be
>>> (0,0,0) in my case.
>>>
>>> In order to check if my geometry import method is correct, I print out
>>> one of the intermediate form of the projection matrix used in the
>>> backprojection process, in order to check if it is the same as in my own
>>> implementation.
>>>
>>> To do so, I print out one of the intermediate matrix that is generated
>>> in rtkCudaBackProjectionImageFilter while launching a SART reconstruction
>>> for instance.
>>>
>>> I was surpised by the fact that, the matrix allowing the transformation
>>> from 2D geometric world to 2D image index world, namely matrixIdxProj in
>>> rtkCudaBackProjectionImageFilte.cxx
>>> <http://www.openrtk.org/Doxygen/rtkCudaBackProjectionImageFilter_8cxx_source.html>
>>> is not always the same along the reconstruction process ?
>>>
>>> Here is the line that generates the matrix I don't understand:
>>>
>>> for(unsigned int i=0; i<2; i++)
>>>  //SR: 0.5 for 2D texture
>>>   matrixIdxProj[i][2] =
>>> -1*(this->GetInput(1)->GetBufferedRegion().GetIndex()[i])+0.5;
>>>
>>> What I understand here, is that, we are generating a 2D translation
>>> matrix embedded in a 3*3 matrix that allows to take into account two things
>>> related to the 2D projection:
>>>
>>> -If the internal behaviour of the imageContainer, allows buffering of
>>> only a part of the image, beginning at index (i,j), this information will
>>> be embeded in the projection matrix
>>>
>>> -the ITK floating point addressing definition seems to differ from the
>>> one from cuda (and openCV):
>>> When I take a look at this page
>>> <http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#texture-fetching>
>>> I understand that the floating point indexing (0.5,0.5) in Cuda points to
>>> the center of the pixel (0,0) hence a linear contribution of 100%, while it
>>> seems that we must add a translation of (0.5,0.5) to the ITK geometric
>>> framework in order to get the same behaviour.
>>>
>>> In practice matrixIdxProj is based on a 3*3 identity matrix, where the
>>> inner 2D translation (ie 2 first term of the last column) in my case are:
>>> -in X, a random number between 10 and 150 plus 0.5
>>> -in Y: always 0.5
>>>
>>> I understand the 0.5 part, but why is there always a 0 offset in Y but a
>>> random offset in X remains a mystery to me.
>>>
>>> At first, I believed that each projection was splitted into multiple
>>> part, each having a different X and Y offset.
>>> But reconstructing using only one projection generates only one
>>> backprojection operation, with a non zero offset in X, 123 in my case, for
>>> an image of size 780 in X.
>>>
>>> Do you think there is something wrong whith the values of matrixIdxProjI
>>> am experiencing ?
>>>
>>> Thank you in advance.
>>>
>>> Kind regards
>>>
>>> Thibault Notargiacomo
>>>
>>> _______________________________________________
>>> 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/20151110/d8913dc3/attachment-0006.html>

From simon.rit at creatis.insa-lyon.fr  Tue Nov 10 11:21:29 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Tue, 10 Nov 2015 17:21:29 +0100
Subject: [Rtk-users] Understanding projection matrices management in
	rtkCudaBackProjectionImageFilter
In-Reply-To: <CAP+mR7ZKqnbUyRHyHkti=3sZd2dEw-OUV6oqsqcga55=tcQ9OQ@mail.gmail.com>
References: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>
 <CAF0oig3muuH+1=eLZ66DJ22QcnsSrUKzRFS4RzDRvDJXNxAVXg@mail.gmail.com>
 <CAP+mR7ZLJV8V5dMOW_jgM5G2-kCZhy8o0tB19685LGo-1bxLUg@mail.gmail.com>
 <CAF0oig3fALRnZNCJ53+TsSjBm7raRC_mqahWEU6x+D+zxwOnVQ@mail.gmail.com>
 <CAP+mR7ZKqnbUyRHyHkti=3sZd2dEw-OUV6oqsqcga55=tcQ9OQ@mail.gmail.com>
Message-ID: <CAF0oig12pRGBfgiCQMCwTG7zX_3vz87AEWhTQ4EYaVbH_m0t5Q@mail.gmail.com>

Your welcome (I cc the mailing list for info).
Simon

On Tue, Nov 10, 2015 at 5:03 PM, Notargiacomo Thibault <gnthibault at gmail.com
> wrote:

> I replaced the original Update by the "UpdateLargestPossibleRegion" to the
> divideFilter in SART (I bypassed displacedDetectorFilter for now) and it
> work as expected, I have now a "clean" matProjIdx.
>
> Thank you for your help !
>
> 2015-11-10 15:03 GMT+01:00 Simon Rit <simon.rit at creatis.insa-lyon.fr>:
>
>> A small correction: it's actually the amount of data pre-processed (read
>> from disk + all the processing before backprojection) but that should
>> change nothing to what is backprojected.
>> I remembered something that can help you: you may want to run
>> UpdateLargestPossibleRegion() to the projections (input 1 of the
>> BackProjectImageFilter) before backprojection to avoid this and make things
>> clearer instead of using a large volume as I was suggesting before.
>> Simon
>>
>> On Tue, Nov 10, 2015 at 2:34 PM, Notargiacomo Thibault <
>> gnthibault at gmail.com> wrote:
>>
>>> Ok, using geometric information to reduce the amount of data to be
>>> backprojected is pretty clever ;)
>>> This explains the "random" index I was asking about in my previous
>>> question, I now know what it is used for and continue my debugging process.
>>>
>>> Kind regards
>>>
>>> Thibault Notargiacomo
>>>
>>> 2015-11-10 14:21 GMT+01:00 Simon Rit <simon.rit at creatis.insa-lyon.fr>:
>>>
>>>> Hi Thibault,
>>>> You started digging in the code so that gets complicated. First thing
>>>> first, yes, the link you provide is still valid.
>>>> The offset in X is not random but computed in
>>>> BackProjectionImageFilter::GenerateInputRequestedRegion
>>>> <https://github.com/SimonRit/RTK/blob/master/code/rtkBackProjectionImageFilter.txx>.
>>>> The idea is that we request only the part of the projections we need to do
>>>> the backprojection. This optimizes the streaming (we only read from disk
>>>> what we need). If you use a huge volume (the test I'd suggest to validate
>>>> that I'm correct and there is nothing wrong with your code), then you'll
>>>> need the full projection and you will always get 0 in X as in Y. If you use
>>>> a small volume and do a computation projection per projection, you will get
>>>> a varying index depending on your input volume and the geometry for that
>>>> projection.
>>>> I think you understood the rest pretty well. Does that make sense or am
>>>> I missing something else?
>>>> Simon
>>>>
>>>> On Tue, Nov 10, 2015 at 1:39 PM, Notargiacomo Thibault <
>>>> gnthibault at gmail.com> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I am currently trying to use the "AddProjectionInRadians" method from
>>>>> the ThreeDCircularProjectionGeometry class in RTK to import my geometry.
>>>>>
>>>>> First things first, I would like to know if the information on this
>>>>> pdf are still valid: http://www.openrtk.org/Doxygen/geometry.pdf
>>>>>
>>>>> Because I used them to deduce the source offset and Projection offset
>>>>> from my own matrix decomposition.
>>>>>
>>>>> Notice that I don't want to use geometric informations coming from the
>>>>> projection images themselves, so their geometric origin is assumed to be
>>>>> (0,0,0) in my case.
>>>>>
>>>>> In order to check if my geometry import method is correct, I print out
>>>>> one of the intermediate form of the projection matrix used in the
>>>>> backprojection process, in order to check if it is the same as in my own
>>>>> implementation.
>>>>>
>>>>> To do so, I print out one of the intermediate matrix that is generated
>>>>> in rtkCudaBackProjectionImageFilter while launching a SART reconstruction
>>>>> for instance.
>>>>>
>>>>> I was surpised by the fact that, the matrix allowing the
>>>>> transformation from 2D geometric world to 2D image index world, namely
>>>>> matrixIdxProj in rtkCudaBackProjectionImageFilte.cxx
>>>>> <http://www.openrtk.org/Doxygen/rtkCudaBackProjectionImageFilter_8cxx_source.html>
>>>>> is not always the same along the reconstruction process ?
>>>>>
>>>>> Here is the line that generates the matrix I don't understand:
>>>>>
>>>>> for(unsigned int i=0; i<2; i++)
>>>>>  //SR: 0.5 for 2D texture
>>>>>   matrixIdxProj[i][2] =
>>>>> -1*(this->GetInput(1)->GetBufferedRegion().GetIndex()[i])+0.5;
>>>>>
>>>>> What I understand here, is that, we are generating a 2D translation
>>>>> matrix embedded in a 3*3 matrix that allows to take into account two things
>>>>> related to the 2D projection:
>>>>>
>>>>> -If the internal behaviour of the imageContainer, allows buffering of
>>>>> only a part of the image, beginning at index (i,j), this information will
>>>>> be embeded in the projection matrix
>>>>>
>>>>> -the ITK floating point addressing definition seems to differ from the
>>>>> one from cuda (and openCV):
>>>>> When I take a look at this page
>>>>> <http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#texture-fetching>
>>>>> I understand that the floating point indexing (0.5,0.5) in Cuda points to
>>>>> the center of the pixel (0,0) hence a linear contribution of 100%, while it
>>>>> seems that we must add a translation of (0.5,0.5) to the ITK geometric
>>>>> framework in order to get the same behaviour.
>>>>>
>>>>> In practice matrixIdxProj is based on a 3*3 identity matrix, where
>>>>> the inner 2D translation (ie 2 first term of the last column) in my case
>>>>> are:
>>>>> -in X, a random number between 10 and 150 plus 0.5
>>>>> -in Y: always 0.5
>>>>>
>>>>> I understand the 0.5 part, but why is there always a 0 offset in Y but
>>>>> a random offset in X remains a mystery to me.
>>>>>
>>>>> At first, I believed that each projection was splitted into multiple
>>>>> part, each having a different X and Y offset.
>>>>> But reconstructing using only one projection generates only one
>>>>> backprojection operation, with a non zero offset in X, 123 in my case, for
>>>>> an image of size 780 in X.
>>>>>
>>>>> Do you think there is something wrong whith the values of matrixIdxProjI
>>>>> am experiencing ?
>>>>>
>>>>> Thank you in advance.
>>>>>
>>>>> Kind regards
>>>>>
>>>>> Thibault Notargiacomo
>>>>>
>>>>> _______________________________________________
>>>>> 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/20151110/b7eba683/attachment-0006.html>

From theday79 at gmail.com  Wed Nov 11 13:50:45 2015
From: theday79 at gmail.com (Yang K Park)
Date: Wed, 11 Nov 2015 13:50:45 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after  a recent update
Message-ID: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>

Hi all,

 

I?ve updated rtk with the up-to-date revision and have encountered a couple of problems.

 

1.       Compile error: RTK couldn?t find itkMacro.h while it compiled rtkCudaUtilities.hcu. It was solved by a minor fetching:

#include <itkMacro.h>   --> #include "itkMacro.h" in rtkCudaUtilities.hcu

 

2.       Output of rtkfdk with CUDA was not the same as before. It was very blurry as seen in the attached image.

a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.

 

 

I?m using VS2013 with win7, itk4.8.1.

 

The command line I used was :

rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware cuda --pad 1 --hann 5 --hannY 5

 

Does anyone have any idea about this?

 

Thanks.

 

Yang

 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151111/b1c7df5f/attachment-0006.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 16577 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151111/b1c7df5f/attachment-0006.png>

From simon.rit at creatis.insa-lyon.fr  Wed Nov 11 16:15:49 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Wed, 11 Nov 2015 22:15:49 +0100
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
Message-ID: <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>

Hi,
I didn't manage to reproduce the two problems on linux with the same
ITK version.
For point 1, did you copy itkMacro.h by hand? Because I don't see how
replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not
in the same folder as rtkCudaUtilities.hcu
For point 2, no clue. Do you use FFTW? It looks like a ramp filter
issue. Can you try rtkramp --path projPath --regexp .*.his, with and
without --hardware cuda? Maybe you can provide your geometry file in
case it's a specific geometric issue.
Simon

On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
> Hi all,
>
>
>
> I?ve updated rtk with the up-to-date revision and have encountered a couple
> of problems.
>
>
>
> 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
> rtkCudaUtilities.hcu. It was solved by a minor fetching:
>
> #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>
>
>
> 2.       Output of rtkfdk with CUDA was not the same as before. It was very
> blurry as seen in the attached image.
>
> a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>
>
>
>
>
> I?m using VS2013 with win7, itk4.8.1.
>
>
>
> The command line I used was :
>
> rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his --output
> output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware cuda --pad 1
> --hann 5 --hannY 5
>
>
>
> Does anyone have any idea about this?
>
>
>
> Thanks.
>
>
>
> Yang
>
>
>
>
> _______________________________________________
> Rtk-users mailing list
> Rtk-users at public.kitware.com
> http://public.kitware.com/mailman/listinfo/rtk-users
>


From theday79 at gmail.com  Thu Nov 12 17:39:38 2015
From: theday79 at gmail.com (Yang K Park)
Date: Thu, 12 Nov 2015 17:39:38 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
Message-ID: <000001d11d9b$04142320$0c3c6960$@gmail.com>

Hi Simon,

 

Thanks for the advice. The current RTK was compiled with FFTW to use the phase extraction feature from Amsterdam shroud.

 

Regarding your suggestions,

 

1)      rtkramp w/ or w/o CUDA:

(command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda --output Ramp_wCUDA.mha? )

 

Then, I have encountered following error.

?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that input requested and buffered regions are equal.?

 



 

Without CUDA, it was successfully done.

 

2)      I?ve re-compiled ITK w/o FFTW and built RTK again. rtkfdk worked fine.

-          I?ve also repeated ?rtkramp+CUDA? with this rtk version and the error was same as above.

 

In conclusion, my FFTW seems to affect CUDA-based fdk reconstruction only.

But I do need FFTW for the phase extraction. What should I do?

 

Thanks.

 

Yang

 

 

-----Original Message-----
From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit
Sent: Wednesday, November 11, 2015 4:16 PM
To: Yang K Park <theday79 at gmail.com>
Cc: rtk-users at openrtk.org
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

I didn't manage to reproduce the two problems on linux with the same ITK version.

For point 1, did you copy itkMacro.h by hand? Because I don't see how replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW? It looks like a ramp filter issue. Can you try rtkramp --path projPath --regexp .*.his, with and without --hardware cuda? Maybe you can provide your geometry file in case it's a specific geometric issue.

Simon

 

On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park < <mailto:theday79 at gmail.com> theday79 at gmail.com> wrote:

> Hi all,

> 

> 

> 

> I?ve updated rtk with the up-to-date revision and have encountered a 

> couple of problems.

> 

> 

> 

> 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled

> rtkCudaUtilities.hcu. It was solved by a minor fetching:

> 

> #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu

> 

> 

> 

> 2.       Output of rtkfdk with CUDA was not the same as before. It was very

> blurry as seen in the attached image.

> 

> a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.

> 

> 

> 

> 

> 

> I?m using VS2013 with win7, itk4.8.1.

> 

> 

> 

> The command line I used was :

> 

> rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his 

> --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware 

> cuda --pad 1 --hann 5 --hannY 5

> 

> 

> 

> Does anyone have any idea about this?

> 

> 

> 

> Thanks.

> 

> 

> 

> Yang

> 

> 

> 

> 

> _______________________________________________

> Rtk-users mailing list

>  <mailto: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/20151112/4e0825dc/attachment-0006.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151112/4e0825dc/attachment-0006.png>

From simon.rit at creatis.insa-lyon.fr  Thu Nov 12 17:58:42 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Thu, 12 Nov 2015 23:58:42 +0100
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <000001d11d9b$04142320$0c3c6960$@gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
Message-ID: <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>

Hi,
Ok. Can you try rtkramp with only one projection? Then you shouldn't
encounter this regions issue (that should be solved one day but that's a
different story).
Can you also indicate which version of CUDA you're using?
FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft for
the FFT of the projections. So if they are not in the same format, you're
in trouble and that might be the issue here... The weird part is that I
didn't reproduce this problem on linux (with and without FFTW) but it might
be a CUDA version difference. I'll give it another try tomorrow when you
provide the CUDA version.
Thanks again for reporting the issue,
Simon

On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com> wrote:

> Hi Simon,
>
>
>
> Thanks for the advice. The current RTK was compiled with FFTW to use the
> phase extraction feature from Amsterdam shroud.
>
>
>
> Regarding your suggestions,
>
>
>
> 1)      rtkramp w/ or w/o CUDA:
>
> (command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda
> --output Ramp_wCUDA.mha? )
>
>
>
> Then, I have encountered following error.
>
> ?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that
> input requested and buffered regions are equal.?
>
>
>
>
>
> Without CUDA, it was successfully done.
>
>
>
> 2)      I?ve re-compiled *ITK w/o FFTW* and built RTK again. r*tkfdk
> worked fine.*
>
> -          I?ve also repeated ?rtkramp+CUDA? with this rtk version and
> the error was same as above.
>
>
>
> In conclusion, my *FFTW seems to affect CUDA-based fdk reconstruction
> only*.
>
> But I do need FFTW for the phase extraction. What should I do?
>
>
>
> Thanks.
>
>
>
> Yang
>
>
>
>
>
> -----Original Message-----
> From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon
> Rit
> Sent: Wednesday, November 11, 2015 4:16 PM
> To: Yang K Park <theday79 at gmail.com>
> Cc: rtk-users at openrtk.org
> Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
> update
>
>
>
> Hi,
>
> I didn't manage to reproduce the two problems on linux with the same ITK
> version.
>
> For point 1, did you copy itkMacro.h by hand? Because I don't see how
> replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the
> same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW?
> It looks like a ramp filter issue. Can you try rtkramp --path projPath
> --regexp .*.his, with and without --hardware cuda? Maybe you can provide
> your geometry file in case it's a specific geometric issue.
>
> Simon
>
>
>
> On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
>
> > Hi all,
>
> >
>
> >
>
> >
>
> > I?ve updated rtk with the up-to-date revision and have encountered a
>
> > couple of problems.
>
> >
>
> >
>
> >
>
> > 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
>
> > rtkCudaUtilities.hcu. It was solved by a minor fetching:
>
> >
>
> > #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>
> >
>
> >
>
> >
>
> > 2.       Output of rtkfdk with CUDA was not the same as before. It was
> very
>
> > blurry as seen in the attached image.
>
> >
>
> > a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > I?m using VS2013 with win7, itk4.8.1.
>
> >
>
> >
>
> >
>
> > The command line I used was :
>
> >
>
> > rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his
>
> > --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware
>
> > cuda --pad 1 --hann 5 --hannY 5
>
> >
>
> >
>
> >
>
> > Does anyone have any idea about this?
>
> >
>
> >
>
> >
>
> > Thanks.
>
> >
>
> >
>
> >
>
> > Yang
>
> >
>
> >
>
> >
>
> >
>
> > _______________________________________________
>
> > 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/20151112/e7c15ff8/attachment-0006.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151112/e7c15ff8/attachment-0006.png>

From theday79 at gmail.com  Mon Nov 16 09:54:01 2015
From: theday79 at gmail.com (Yang K Park)
Date: Mon, 16 Nov 2015 09:54:01 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
Message-ID: <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>

Hi Simon,

 

Sorry for the late response.

 

As you suggested, I?ve tried rtkramp+CUDA with only one projection and it was successfully done for both w/ FFTW and w/o FFTW.

(Two results were exactly same.)

 

Regarding  the CUDA version, I?m using v6.5.

 

Thanks a lot for the help!

 

Yang

 

 

From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit
Sent: Thursday, November 12, 2015 5:59 PM
To: Yang K Park <theday79 at gmail.com>
Cc: rtk-users at openrtk.org
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

Ok. Can you try rtkramp with only one projection? Then you shouldn't encounter this regions issue (that should be solved one day but that's a different story). 

Can you also indicate which version of CUDA you're using?

FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft for the FFT of the projections. So if they are not in the same format, you're in trouble and that might be the issue here... The weird part is that I didn't reproduce this problem on linux (with and without FFTW) but it might be a CUDA version difference. I'll give it another try tomorrow when you provide the CUDA version.

Thanks again for reporting the issue,
Simon

 

On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> > wrote:

Hi Simon,

 

Thanks for the advice. The current RTK was compiled with FFTW to use the phase extraction feature from Amsterdam shroud.

 

Regarding your suggestions,

 

1)      rtkramp w/ or w/o CUDA:

(command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda --output Ramp_wCUDA.mha? )

 

Then, I have encountered following error.

?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that input requested and buffered regions are equal.?

 



 

Without CUDA, it was successfully done.

 

2)      I?ve re-compiled ITK w/o FFTW and built RTK again. rtkfdk worked fine.

-          I?ve also repeated ?rtkramp+CUDA? with this rtk version and the error was same as above.

 

In conclusion, my FFTW seems to affect CUDA-based fdk reconstruction only.

But I do need FFTW for the phase extraction. What should I do?

 

Thanks.

 

Yang

 

 

-----Original Message-----
From: simon.rit at gmail.com <mailto:simon.rit at gmail.com>  [mailto:simon.rit at gmail.com <mailto:simon.rit at gmail.com> ] On Behalf Of Simon Rit
Sent: Wednesday, November 11, 2015 4:16 PM
To: Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> >
Cc: rtk-users at openrtk.org <mailto:rtk-users at openrtk.org> 
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

I didn't manage to reproduce the two problems on linux with the same ITK version.

For point 1, did you copy itkMacro.h by hand? Because I don't see how replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW? It looks like a ramp filter issue. Can you try rtkramp --path projPath --regexp .*.his, with and without --hardware cuda? Maybe you can provide your geometry file in case it's a specific geometric issue.

Simon

 

On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park < <mailto:theday79 at gmail.com> theday79 at gmail.com> wrote:

> Hi all,

> 

> 

> 

> I?ve updated rtk with the up-to-date revision and have encountered a 

> couple of problems.

> 

> 

> 

> 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled

> rtkCudaUtilities.hcu. It was solved by a minor fetching:

> 

> #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu

> 

> 

> 

> 2.       Output of rtkfdk with CUDA was not the same as before. It was very

> blurry as seen in the attached image.

> 

> a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.

> 

> 

> 

> 

> 

> I?m using VS2013 with win7, itk4.8.1.

> 

> 

> 

> The command line I used was :

> 

> rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his 

> --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware 

> cuda --pad 1 --hann 5 --hannY 5

> 

> 

> 

> Does anyone have any idea about this?

> 

> 

> 

> Thanks.

> 

> 

> 

> Yang

> 

> 

> 

> 

> _______________________________________________

> Rtk-users mailing list

>  <mailto: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/20151116/e77c2f96/attachment-0006.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151116/e77c2f96/attachment-0006.png>

From simon.rit at creatis.insa-lyon.fr  Mon Nov 16 10:07:46 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Mon, 16 Nov 2015 16:07:46 +0100
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
 <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
Message-ID: <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>

Hi,
Thanks. It's really weird... When you run the tests with FFTW (compiling
the "test" target), do they fail?
Can you provide your geometry file? It might be specific to this geometry.
Thanks again for looking into this issue, we'll find what's the problem.
Simon

On Mon, Nov 16, 2015 at 3:54 PM, Yang K Park <theday79 at gmail.com> wrote:

> Hi Simon,
>
>
>
> Sorry for the late response.
>
>
>
> As you suggested, I?ve tried rtkramp+CUDA with only one projection and it
> was successfully done for both w/ FFTW and w/o FFTW.
>
> (Two results were exactly same.)
>
>
>
> Regarding  the CUDA version, I?m using v6.5.
>
>
>
> Thanks a lot for the help!
>
>
>
> Yang
>
>
>
>
>
> *From:* simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of *Simon
> Rit
> *Sent:* Thursday, November 12, 2015 5:59 PM
>
> *To:* Yang K Park <theday79 at gmail.com>
> *Cc:* rtk-users at openrtk.org
> *Subject:* Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
> update
>
>
>
> Hi,
>
> Ok. Can you try rtkramp with only one projection? Then you shouldn't
> encounter this regions issue (that should be solved one day but that's a
> different story).
>
> Can you also indicate which version of CUDA you're using?
>
> FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft for
> the FFT of the projections. So if they are not in the same format, you're
> in trouble and that might be the issue here... The weird part is that I
> didn't reproduce this problem on linux (with and without FFTW) but it might
> be a CUDA version difference. I'll give it another try tomorrow when you
> provide the CUDA version.
>
> Thanks again for reporting the issue,
> Simon
>
>
>
> On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com> wrote:
>
> Hi Simon,
>
>
>
> Thanks for the advice. The current RTK was compiled with FFTW to use the
> phase extraction feature from Amsterdam shroud.
>
>
>
> Regarding your suggestions,
>
>
>
> 1)      rtkramp w/ or w/o CUDA:
>
> (command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda
> --output Ramp_wCUDA.mha? )
>
>
>
> Then, I have encountered following error.
>
> ?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that
> input requested and buffered regions are equal.?
>
>
>
>
>
> Without CUDA, it was successfully done.
>
>
>
> 2)      I?ve re-compiled *ITK w/o FFTW* and built RTK again. r*tkfdk
> worked fine.*
>
> -          I?ve also repeated ?rtkramp+CUDA? with this rtk version and
> the error was same as above.
>
>
>
> In conclusion, my *FFTW seems to affect CUDA-based fdk reconstruction
> only*.
>
> But I do need FFTW for the phase extraction. What should I do?
>
>
>
> Thanks.
>
>
>
> Yang
>
>
>
>
>
> -----Original Message-----
> From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon
> Rit
> Sent: Wednesday, November 11, 2015 4:16 PM
> To: Yang K Park <theday79 at gmail.com>
> Cc: rtk-users at openrtk.org
> Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
> update
>
>
>
> Hi,
>
> I didn't manage to reproduce the two problems on linux with the same ITK
> version.
>
> For point 1, did you copy itkMacro.h by hand? Because I don't see how
> replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the
> same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW?
> It looks like a ramp filter issue. Can you try rtkramp --path projPath
> --regexp .*.his, with and without --hardware cuda? Maybe you can provide
> your geometry file in case it's a specific geometric issue.
>
> Simon
>
>
>
> On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
>
> > Hi all,
>
> >
>
> >
>
> >
>
> > I?ve updated rtk with the up-to-date revision and have encountered a
>
> > couple of problems.
>
> >
>
> >
>
> >
>
> > 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
>
> > rtkCudaUtilities.hcu. It was solved by a minor fetching:
>
> >
>
> > #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>
> >
>
> >
>
> >
>
> > 2.       Output of rtkfdk with CUDA was not the same as before. It was
> very
>
> > blurry as seen in the attached image.
>
> >
>
> > a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > I?m using VS2013 with win7, itk4.8.1.
>
> >
>
> >
>
> >
>
> > The command line I used was :
>
> >
>
> > rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his
>
> > --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware
>
> > cuda --pad 1 --hann 5 --hannY 5
>
> >
>
> >
>
> >
>
> > Does anyone have any idea about this?
>
> >
>
> >
>
> >
>
> > Thanks.
>
> >
>
> >
>
> >
>
> > Yang
>
> >
>
> >
>
> >
>
> >
>
> > _______________________________________________
>
> > 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/20151116/38acfca5/attachment-0006.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151116/38acfca5/attachment-0006.png>

From theday79 at gmail.com  Mon Nov 16 10:47:43 2015
From: theday79 at gmail.com (Yang-Kyun Park)
Date: Mon, 16 Nov 2015 10:47:43 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
 <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
 <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>
Message-ID: <CAJM7=xjBjx=FzLazWJWqJbV5d45zGi2U71NKejm9HxKhJ0-xLQ@mail.gmail.com>

Hi Simon,

For better understanding, I'm attaching the problematic case including
projection files, geometry file(xml) and reconstructed images.(please find
the GDrive links. The file size is ~800 MB)
This is phantom data and there is no patient information in it.

Regarding the fftw library, I'm using [fftw-3.3.4-dll64].

By the way, I found another clue. When I've tried it with a head phantom
image (full-fan, ~ 190 projections), there was no problem. Is there any
possibility that DDF and parker short filter play some roles on this issue?

Feel free to let me know if further data is needed.

Thanks!

Yang

?
 FFTW_issue.zip
<https://drive.google.com/file/d/0BxuP3mON9V-qbVdQd0luc1lIb2M/view?usp=drive_web>
?

On Mon, Nov 16, 2015 at 10:07 AM, Simon Rit <simon.rit at creatis.insa-lyon.fr>
wrote:

> Hi,
> Thanks. It's really weird... When you run the tests with FFTW (compiling
> the "test" target), do they fail?
> Can you provide your geometry file? It might be specific to this geometry.
> Thanks again for looking into this issue, we'll find what's the problem.
> Simon
>
> On Mon, Nov 16, 2015 at 3:54 PM, Yang K Park <theday79 at gmail.com> wrote:
>
>> Hi Simon,
>>
>>
>>
>> Sorry for the late response.
>>
>>
>>
>> As you suggested, I?ve tried rtkramp+CUDA with only one projection and it
>> was successfully done for both w/ FFTW and w/o FFTW.
>>
>> (Two results were exactly same.)
>>
>>
>>
>> Regarding  the CUDA version, I?m using v6.5.
>>
>>
>>
>> Thanks a lot for the help!
>>
>>
>>
>> Yang
>>
>>
>>
>>
>>
>> *From:* simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of *Simon
>> Rit
>> *Sent:* Thursday, November 12, 2015 5:59 PM
>>
>> *To:* Yang K Park <theday79 at gmail.com>
>> *Cc:* rtk-users at openrtk.org
>> *Subject:* Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
>> update
>>
>>
>>
>> Hi,
>>
>> Ok. Can you try rtkramp with only one projection? Then you shouldn't
>> encounter this regions issue (that should be solved one day but that's a
>> different story).
>>
>> Can you also indicate which version of CUDA you're using?
>>
>> FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft
>> for the FFT of the projections. So if they are not in the same format,
>> you're in trouble and that might be the issue here... The weird part is
>> that I didn't reproduce this problem on linux (with and without FFTW) but
>> it might be a CUDA version difference. I'll give it another try tomorrow
>> when you provide the CUDA version.
>>
>> Thanks again for reporting the issue,
>> Simon
>>
>>
>>
>> On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com> wrote:
>>
>> Hi Simon,
>>
>>
>>
>> Thanks for the advice. The current RTK was compiled with FFTW to use the
>> phase extraction feature from Amsterdam shroud.
>>
>>
>>
>> Regarding your suggestions,
>>
>>
>>
>> 1)      rtkramp w/ or w/o CUDA:
>>
>> (command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda
>> --output Ramp_wCUDA.mha? )
>>
>>
>>
>> Then, I have encountered following error.
>>
>> ?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that
>> input requested and buffered regions are equal.?
>>
>>
>>
>>
>>
>> Without CUDA, it was successfully done.
>>
>>
>>
>> 2)      I?ve re-compiled *ITK w/o FFTW* and built RTK again. r*tkfdk
>> worked fine.*
>>
>> -          I?ve also repeated ?rtkramp+CUDA? with this rtk version and
>> the error was same as above.
>>
>>
>>
>> In conclusion, my *FFTW seems to affect CUDA-based fdk reconstruction
>> only*.
>>
>> But I do need FFTW for the phase extraction. What should I do?
>>
>>
>>
>> Thanks.
>>
>>
>>
>> Yang
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of
>> Simon Rit
>> Sent: Wednesday, November 11, 2015 4:16 PM
>> To: Yang K Park <theday79 at gmail.com>
>> Cc: rtk-users at openrtk.org
>> Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
>> update
>>
>>
>>
>> Hi,
>>
>> I didn't manage to reproduce the two problems on linux with the same ITK
>> version.
>>
>> For point 1, did you copy itkMacro.h by hand? Because I don't see how
>> replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the
>> same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW?
>> It looks like a ramp filter issue. Can you try rtkramp --path projPath
>> --regexp .*.his, with and without --hardware cuda? Maybe you can provide
>> your geometry file in case it's a specific geometric issue.
>>
>> Simon
>>
>>
>>
>> On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
>>
>> > Hi all,
>>
>> >
>>
>> >
>>
>> >
>>
>> > I?ve updated rtk with the up-to-date revision and have encountered a
>>
>> > couple of problems.
>>
>> >
>>
>> >
>>
>> >
>>
>> > 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
>>
>> > rtkCudaUtilities.hcu. It was solved by a minor fetching:
>>
>> >
>>
>> > #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>>
>> >
>>
>> >
>>
>> >
>>
>> > 2.       Output of rtkfdk with CUDA was not the same as before. It was
>> very
>>
>> > blurry as seen in the attached image.
>>
>> >
>>
>> > a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>
>> > I?m using VS2013 with win7, itk4.8.1.
>>
>> >
>>
>> >
>>
>> >
>>
>> > The command line I used was :
>>
>> >
>>
>> > rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his
>>
>> > --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware
>>
>> > cuda --pad 1 --hann 5 --hannY 5
>>
>> >
>>
>> >
>>
>> >
>>
>> > Does anyone have any idea about this?
>>
>> >
>>
>> >
>>
>> >
>>
>> > Thanks.
>>
>> >
>>
>> >
>>
>> >
>>
>> > Yang
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>
>> > _______________________________________________
>>
>> > 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/20151116/90d2c5a0/attachment-0006.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151116/90d2c5a0/attachment-0006.png>

From simon.rit at creatis.insa-lyon.fr  Fri Nov 20 11:28:22 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Fri, 20 Nov 2015 17:28:22 +0100
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAJM7=xjBjx=FzLazWJWqJbV5d45zGi2U71NKejm9HxKhJ0-xLQ@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
 <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
 <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>
 <CAJM7=xjBjx=FzLazWJWqJbV5d45zGi2U71NKejm9HxKhJ0-xLQ@mail.gmail.com>
Message-ID: <CAF0oig027_u_9gb8bnwT1w9jr3epZ0hkd9Mt73qK5heUq_kCkg@mail.gmail.com>

Hi Yang,
Thanks a lot for sharing the data. I have good news. I could reproduce the
bug and I have solutions. First, about your dataset: it's a huge dataset
and the hannY requires zero padding in both x and y. Because of this, cufft
has to take the 2D FFT of projection subsets that are 4095x2048x16. Quite
big!
When I ran it on my cuda 7.0, I immediately got:

itk::ExceptionObject (0x8b9cb30)
Location: "void CUDA_fft_convolution(const int3&, const int2&, float*,
cufftComplex*)"
File: /home/srit/src/rtk/rtk/code/rtkCudaFFTConvolutionImageFilter.cu
Line: 97
Description: itk::ERROR: CUFFT ERROR #2

i.e., a GPU alloc issue, even if I have the largest possible memory on a
nvidia desktop computer. Then, I ran it with cuda 6.5 and I got no error
message but a result similar to yours.
Conclusions:
- if you add the option --subsetsize 1 to your rtkfdk command line, that
should reconstruct correctly
- if you upgrade cuda, you should get an understandable error message,
- I don't think I'm going to look for a solution because the pb is probably
in cufft but if someone is willing to, be my guest!
Simon

On Mon, Nov 16, 2015 at 4:47 PM, Yang-Kyun Park <theday79 at gmail.com> wrote:

> Hi Simon,
>
> For better understanding, I'm attaching the problematic case including
> projection files, geometry file(xml) and reconstructed images.(please find
> the GDrive links. The file size is ~800 MB)
> This is phantom data and there is no patient information in it.
>
> Regarding the fftw library, I'm using [fftw-3.3.4-dll64].
>
> By the way, I found another clue. When I've tried it with a head phantom
> image (full-fan, ~ 190 projections), there was no problem. Is there any
> possibility that DDF and parker short filter play some roles on this issue?
>
> Feel free to let me know if further data is needed.
>
> Thanks!
>
> Yang
>
> ?
>  FFTW_issue.zip
> <https://drive.google.com/file/d/0BxuP3mON9V-qbVdQd0luc1lIb2M/view?usp=drive_web>
> ?
>
> On Mon, Nov 16, 2015 at 10:07 AM, Simon Rit <
> simon.rit at creatis.insa-lyon.fr> wrote:
>
>> Hi,
>> Thanks. It's really weird... When you run the tests with FFTW (compiling
>> the "test" target), do they fail?
>> Can you provide your geometry file? It might be specific to this geometry.
>> Thanks again for looking into this issue, we'll find what's the problem.
>> Simon
>>
>> On Mon, Nov 16, 2015 at 3:54 PM, Yang K Park <theday79 at gmail.com> wrote:
>>
>>> Hi Simon,
>>>
>>>
>>>
>>> Sorry for the late response.
>>>
>>>
>>>
>>> As you suggested, I?ve tried rtkramp+CUDA with only one projection and
>>> it was successfully done for both w/ FFTW and w/o FFTW.
>>>
>>> (Two results were exactly same.)
>>>
>>>
>>>
>>> Regarding  the CUDA version, I?m using v6.5.
>>>
>>>
>>>
>>> Thanks a lot for the help!
>>>
>>>
>>>
>>> Yang
>>>
>>>
>>>
>>>
>>>
>>> *From:* simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of *Simon
>>> Rit
>>> *Sent:* Thursday, November 12, 2015 5:59 PM
>>>
>>> *To:* Yang K Park <theday79 at gmail.com>
>>> *Cc:* rtk-users at openrtk.org
>>> *Subject:* Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
>>> update
>>>
>>>
>>>
>>> Hi,
>>>
>>> Ok. Can you try rtkramp with only one projection? Then you shouldn't
>>> encounter this regions issue (that should be solved one day but that's a
>>> different story).
>>>
>>> Can you also indicate which version of CUDA you're using?
>>>
>>> FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft
>>> for the FFT of the projections. So if they are not in the same format,
>>> you're in trouble and that might be the issue here... The weird part is
>>> that I didn't reproduce this problem on linux (with and without FFTW) but
>>> it might be a CUDA version difference. I'll give it another try tomorrow
>>> when you provide the CUDA version.
>>>
>>> Thanks again for reporting the issue,
>>> Simon
>>>
>>>
>>>
>>> On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com>
>>> wrote:
>>>
>>> Hi Simon,
>>>
>>>
>>>
>>> Thanks for the advice. The current RTK was compiled with FFTW to use the
>>> phase extraction feature from Amsterdam shroud.
>>>
>>>
>>>
>>> Regarding your suggestions,
>>>
>>>
>>>
>>> 1)      rtkramp w/ or w/o CUDA:
>>>
>>> (command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda
>>> --output Ramp_wCUDA.mha? )
>>>
>>>
>>>
>>> Then, I have encountered following error.
>>>
>>> ?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that
>>> input requested and buffered regions are equal.?
>>>
>>>
>>>
>>>
>>>
>>> Without CUDA, it was successfully done.
>>>
>>>
>>>
>>> 2)      I?ve re-compiled *ITK w/o FFTW* and built RTK again. r*tkfdk
>>> worked fine.*
>>>
>>> -          I?ve also repeated ?rtkramp+CUDA? with this rtk version and
>>> the error was same as above.
>>>
>>>
>>>
>>> In conclusion, my *FFTW seems to affect CUDA-based fdk reconstruction
>>> only*.
>>>
>>> But I do need FFTW for the phase extraction. What should I do?
>>>
>>>
>>>
>>> Thanks.
>>>
>>>
>>>
>>> Yang
>>>
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of
>>> Simon Rit
>>> Sent: Wednesday, November 11, 2015 4:16 PM
>>> To: Yang K Park <theday79 at gmail.com>
>>> Cc: rtk-users at openrtk.org
>>> Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
>>> update
>>>
>>>
>>>
>>> Hi,
>>>
>>> I didn't manage to reproduce the two problems on linux with the same ITK
>>> version.
>>>
>>> For point 1, did you copy itkMacro.h by hand? Because I don't see how
>>> replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the
>>> same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW?
>>> It looks like a ramp filter issue. Can you try rtkramp --path projPath
>>> --regexp .*.his, with and without --hardware cuda? Maybe you can provide
>>> your geometry file in case it's a specific geometric issue.
>>>
>>> Simon
>>>
>>>
>>>
>>> On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
>>>
>>> > Hi all,
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > I?ve updated rtk with the up-to-date revision and have encountered a
>>>
>>> > couple of problems.
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
>>>
>>> > rtkCudaUtilities.hcu. It was solved by a minor fetching:
>>>
>>> >
>>>
>>> > #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > 2.       Output of rtkfdk with CUDA was not the same as before. It was
>>> very
>>>
>>> > blurry as seen in the attached image.
>>>
>>> >
>>>
>>> > a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > I?m using VS2013 with win7, itk4.8.1.
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > The command line I used was :
>>>
>>> >
>>>
>>> > rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his
>>>
>>> > --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware
>>>
>>> > cuda --pad 1 --hann 5 --hannY 5
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > Does anyone have any idea about this?
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > Thanks.
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > Yang
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > _______________________________________________
>>>
>>> > 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/20151120/4e6c0e1e/attachment-0006.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151120/4e6c0e1e/attachment-0006.png>

From theday79 at gmail.com  Fri Nov 20 12:36:51 2015
From: theday79 at gmail.com (Yang K Park)
Date: Fri, 20 Nov 2015 12:36:51 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAF0oig027_u_9gb8bnwT1w9jr3epZ0hkd9Mt73qK5heUq_kCkg@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
 <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
 <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>
 <CAJM7=xjBjx=FzLazWJWqJbV5d45zGi2U71NKejm9HxKhJ0-xLQ@mail.gmail.com>
 <CAF0oig027_u_9gb8bnwT1w9jr3epZ0hkd9Mt73qK5heUq_kCkg@mail.gmail.com>
Message-ID: <000901d123ba$0ae3de50$20ab9af0$@gmail.com>

Hi Simon,

 

That sounds great! Thanks a lot for your hard work.

As you said, now I can reconstruct it successfully with --subsetsize option.

 

I think the only concern left is the elongated reconstruction time.

I?ve measured it for the same phantom image with different ?subsetsize? values as well as w/o FFTW compiling.

I just report it for your information.

 

1)      w/o FFTW  : 21.4 s

2)      w/ FFTW & --subsetsize 1: 89 s

3)      w/ FFTW & --subsetsize 2: 77 s

4)      w/ FFTW & --subsetsize 4: 65 s

5)      w/ FFTW & --subsetsize 6: 51 s

6)      w/ FFTW & --subsetsize 7: (Error-graphic card seemed to be freezed)

7)      w/ FFTW & --subsetsize 8: (Error-?itk::ERROR: CUFFT ERROR #2 in rtkCudaFFTConvolutionImageFilter.cu?)

 

Of course, the difference was coming from the Ramp filter.

Therefore, I?m going to use [--subsetsize 6] for my system and will update CUDA version soon!

 

Thanks.

 

Yang

 

 

From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit
Sent: Friday, November 20, 2015 11:28 AM
To: Yang-Kyun Park <theday79 at gmail.com>
Cc: rtk-users at openrtk.org
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi Yang,
Thanks a lot for sharing the data. I have good news. I could reproduce the bug and I have solutions. First, about your dataset: it's a huge dataset and the hannY requires zero padding in both x and y. Because of this, cufft has to take the 2D FFT of projection subsets that are 4095x2048x16. Quite big!

When I ran it on my cuda 7.0, I immediately got:

itk::ExceptionObject (0x8b9cb30)
Location: "void CUDA_fft_convolution(const int3&, const int2&, float*, cufftComplex*)" 
File: /home/srit/src/rtk/rtk/code/rtkCudaFFTConvolutionImageFilter.cu
Line: 97
Description: itk::ERROR: CUFFT ERROR #2

i.e., a GPU alloc issue, even if I have the largest possible memory on a nvidia desktop computer. Then, I ran it with cuda 6.5 and I got no error message but a result similar to yours.

Conclusions:

- if you add the option --subsetsize 1 to your rtkfdk command line, that should reconstruct correctly

- if you upgrade cuda, you should get an understandable error message,

- I don't think I'm going to look for a solution because the pb is probably in cufft but if someone is willing to, be my guest!

Simon

 

On Mon, Nov 16, 2015 at 4:47 PM, Yang-Kyun Park <theday79 at gmail.com <mailto:theday79 at gmail.com> > wrote:

Hi Simon,

 

For better understanding, I'm attaching the problematic case including projection files, geometry file(xml) and reconstructed images.(please find the GDrive links. The file size is ~800 MB)

This is phantom data and there is no patient information in it.

 

Regarding the fftw library, I'm using [fftw-3.3.4-dll64].

 

By the way, I found another clue. When I've tried it with a head phantom image (full-fan, ~ 190 projections), there was no problem. Is there any possibility that DDF and parker short filter play some roles on this issue?

 

Feel free to let me know if further data is needed.

 

Thanks!

 

Yang

 

?

 <https://drive.google.com/file/d/0BxuP3mON9V-qbVdQd0luc1lIb2M/view?usp=drive_web>  FFTW_issue.zip

?

 

On Mon, Nov 16, 2015 at 10:07 AM, Simon Rit <simon.rit at creatis.insa-lyon.fr <mailto:simon.rit at creatis.insa-lyon.fr> > wrote:

Hi,

Thanks. It's really weird... When you run the tests with FFTW (compiling the "test" target), do they fail?
Can you provide your geometry file? It might be specific to this geometry.

Thanks again for looking into this issue, we'll find what's the problem.

Simon

 

On Mon, Nov 16, 2015 at 3:54 PM, Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> > wrote:

Hi Simon,

 

Sorry for the late response.

 

As you suggested, I?ve tried rtkramp+CUDA with only one projection and it was successfully done for both w/ FFTW and w/o FFTW.

(Two results were exactly same.)

 

Regarding  the CUDA version, I?m using v6.5.

 

Thanks a lot for the help!

 

Yang

 

 

From: simon.rit at gmail.com <mailto:simon.rit at gmail.com>  [mailto:simon.rit at gmail.com <mailto:simon.rit at gmail.com> ] On Behalf Of Simon Rit
Sent: Thursday, November 12, 2015 5:59 PM


To: Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> >
Cc: rtk-users at openrtk.org <mailto:rtk-users at openrtk.org> 
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

Ok. Can you try rtkramp with only one projection? Then you shouldn't encounter this regions issue (that should be solved one day but that's a different story). 

Can you also indicate which version of CUDA you're using?

FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft for the FFT of the projections. So if they are not in the same format, you're in trouble and that might be the issue here... The weird part is that I didn't reproduce this problem on linux (with and without FFTW) but it might be a CUDA version difference. I'll give it another try tomorrow when you provide the CUDA version.

Thanks again for reporting the issue,
Simon

 

On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> > wrote:

Hi Simon,

 

Thanks for the advice. The current RTK was compiled with FFTW to use the phase extraction feature from Amsterdam shroud.

 

Regarding your suggestions,

 

1)      rtkramp w/ or w/o CUDA:

(command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda --output Ramp_wCUDA.mha? )

 

Then, I have encountered following error.

?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that input requested and buffered regions are equal.?

 



 

Without CUDA, it was successfully done.

 

2)      I?ve re-compiled ITK w/o FFTW and built RTK again. rtkfdk worked fine.

-          I?ve also repeated ?rtkramp+CUDA? with this rtk version and the error was same as above.

 

In conclusion, my FFTW seems to affect CUDA-based fdk reconstruction only.

But I do need FFTW for the phase extraction. What should I do?

 

Thanks.

 

Yang

 

 

-----Original Message-----
From: simon.rit at gmail.com <mailto:simon.rit at gmail.com>  [mailto:simon.rit at gmail.com <mailto:simon.rit at gmail.com> ] On Behalf Of Simon Rit
Sent: Wednesday, November 11, 2015 4:16 PM
To: Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> >
Cc: rtk-users at openrtk.org <mailto:rtk-users at openrtk.org> 
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

I didn't manage to reproduce the two problems on linux with the same ITK version.

For point 1, did you copy itkMacro.h by hand? Because I don't see how replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW? It looks like a ramp filter issue. Can you try rtkramp --path projPath --regexp .*.his, with and without --hardware cuda? Maybe you can provide your geometry file in case it's a specific geometric issue.

Simon

 

On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park < <mailto:theday79 at gmail.com> theday79 at gmail.com> wrote:

> Hi all,

> 

> 

> 

> I?ve updated rtk with the up-to-date revision and have encountered a 

> couple of problems.

> 

> 

> 

> 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled

> rtkCudaUtilities.hcu. It was solved by a minor fetching:

> 

> #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu

> 

> 

> 

> 2.       Output of rtkfdk with CUDA was not the same as before. It was very

> blurry as seen in the attached image.

> 

> a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.

> 

> 

> 

> 

> 

> I?m using VS2013 with win7, itk4.8.1.

> 

> 

> 

> The command line I used was :

> 

> rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his 

> --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware 

> cuda --pad 1 --hann 5 --hannY 5

> 

> 

> 

> Does anyone have any idea about this?

> 

> 

> 

> Thanks.

> 

> 

> 

> Yang

> 

> 

> 

> 

> _______________________________________________

> Rtk-users mailing list

>  <mailto: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/20151120/0d98ace1/attachment-0006.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151120/0d98ace1/attachment-0006.png>

From simon.rit at creatis.insa-lyon.fr  Wed Nov 25 02:36:44 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Wed, 25 Nov 2015 08:36:44 +0100
Subject: [Rtk-users] Compiling Problem
In-Reply-To: <040e01d125c7$83648e60$8a2dab20$@126.com>
References: <040e01d125c7$83648e60$8a2dab20$@126.com>
Message-ID: <5655650C.1040500@creatis.insa-lyon.fr>

Hi,
Please use the mailing list. I don't know where does the linking problem 
come from and it seems to work on our side:
http://my.cdash.org/index.php?project=RTK
Have you tried disabling CUDA?
Simon

On 23/11/2015 09:18, Freyman li wrote:
>
> Dear Simon,
>
> Recently I configured the RTK tool and suffer some problems. After set 
> up the itk tool and cuda, I compiled the rtk application but 
> encountered two errors attached to the email(jpg format)
>
> CUDA and ITK environment are tested successfully. My compile tool is 
> Visual studio 2012(64bit) and CUDA version is v6.5.
>
> Can you tell me how to deal with it and I am looking forward to hear 
> you again.
>
> Thank you!
>
> Best Regards
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151125/285f7f3c/attachment-0006.html>

From theday79 at gmail.com  Wed Nov 25 12:38:52 2015
From: theday79 at gmail.com (Yang K Park)
Date: Wed, 25 Nov 2015 12:38:52 -0500
Subject: [Rtk-users] Compiling Problem
In-Reply-To: <5655650C.1040500@creatis.insa-lyon.fr>
References: <040e01d125c7$83648e60$8a2dab20$@126.com>
 <5655650C.1040500@creatis.insa-lyon.fr>
Message-ID: <003d01d127a8$27a52b60$76ef8220$@gmail.com>

Hi Freyman,

 

I think your setting is much similar to mine, since I have compiled RTK with
VS2013 and CUDA v6.5 several times. Can you post those error messages again
so that I can see?

Yang

 

 

From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of
Simon Rit
Sent: Wednesday, November 25, 2015 2:37 AM
To: Freyman li <lihanwei_1500 at 126.com>
Cc: rtk-users at openrtk.org
Subject: Re: [Rtk-users] Compiling Problem

 

Hi,
Please use the mailing list. I don't know where does the linking problem
come from and it seems to work on our side:
http://my.cdash.org/index.php?project=RTK
Have you tried disabling CUDA?
Simon

On 23/11/2015 09:18, Freyman li wrote:

Dear Simon,

 

Recently I configured the RTK tool and suffer some problems. After set up
the itk tool and cuda, I compiled the rtk application but encountered two
errors attached to the email(jpg format)

CUDA and ITK environment are tested successfully. My compile tool is Visual
studio 2012(64bit) and CUDA version is v6.5.

Can you tell me how to deal with it and I am looking forward to hear you
again.

Thank you!

 

Best Regards

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151125/984feb50/attachment-0006.html>

From bioniloofar at gmail.com  Mon Nov 30 06:06:41 2015
From: bioniloofar at gmail.com (niloufar teyfouri)
Date: Mon, 30 Nov 2015 14:36:41 +0330
Subject: [Rtk-users] ElectaReconstruction
Message-ID: <CALChM12F4PuiLvgENg3Yyn7E+uZ7iPJ+GiY04z7VQ-90AS83EA@mail.gmail.com>

I ran the application of Electa Reconstruction implemented by you with
RTK. But after debugging I was encountered with the message of
"--output' ('-o') option required". Could you please help me for running
this example and the other ones?
I don't know any thing about the texts in the gray boxes mentioned at
each link related to examples of RTK.
For example in the link of
http://wiki.openrtk.org/index.php/RTK/Examples/ElektaReconstruction
how I should use gengetopt for the instructions below?


2. Run the application to convert Elekta's geometry into RTKs (DICOM_UID
is contained in the subfolder name of the his files):

  rtkelektasynergygeometry \
    --image_db IMAGE.DBF \
    --frame_db FRAME.DBF \
    --dicom_uid 1.3.46.423632.135428.1351013645.166 \
    -o elektaGeometry

I would be appreciate if one could answer my question.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151130/b11ad4e2/attachment-0006.html>

From cyril.mory at uclouvain.be  Mon Nov 30 09:30:48 2015
From: cyril.mory at uclouvain.be (Cyril Mory)
Date: Mon, 30 Nov 2015 15:30:48 +0100
Subject: [Rtk-users] ElectaReconstruction
In-Reply-To: <CALChM12F4PuiLvgENg3Yyn7E+uZ7iPJ+GiY04z7VQ-90AS83EA@mail.gmail.com>
References: <CALChM12F4PuiLvgENg3Yyn7E+uZ7iPJ+GiY04z7VQ-90AS83EA@mail.gmail.com>
Message-ID: <565C5D98.1000309@uclouvain.be>

Hi, and welcome to RTK,

Gengetopt is the piece of software that parses the command line 
arguments in all RTK applications. You do not have to "use" it. You just 
need to give correct arguments on the command line.

The message "--output' ('-o') option required" means what it says : you 
need to provide the name of the file in which you want to store the 
geometry information generated by the application 
rtkelektasynergygeometry. If you just copy-pasted the command you found 
on the wiki, then something went wrong during the copy-paste. Try to run 
the following :

rtkelektasynergygeometry --image_db IMAGE.DBF --frame_db FRAME.DBF 
--dicom_uid 1.3.46.423632.135428.1351013645.166 -o elektaGeometry

I just removed the '\' and the useless spaces. You can do the same for 
all other command line examples and it should work.

Let us know if you keep encountering trouble.
Cyril


Le 30/11/2015 12:06, niloufar teyfouri a ?crit :
>
> I ran the application of Electa Reconstruction implemented by you with
> RTK. But after debugging I was encountered with the message of
> "--output' ('-o') option required". Could you please help me for running
> this example and the other ones?
> I don't know any thing about the texts in the gray boxes mentioned at
> each link related to examples of RTK.
> For example in the link of
> http://wiki.openrtk.org/index.php/RTK/Examples/ElektaReconstruction
> how I should use gengetopt for the instructions below?
>
>
> 2. Run the application to convert Elekta's geometry into RTKs (DICOM_UID
> is contained in the subfolder name of the his files):
>
> rtkelektasynergygeometry \
> --image_db IMAGE.DBF \
> --frame_db FRAME.DBF \
> --dicom_uid 1.3.46.423632.135428.1351013645.166 \
>     -o elektaGeometry
>
> I would be appreciate if one could answer my question.
>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151130/66741755/attachment-0006.html>

From j.mason at ed.ac.uk  Mon Nov 30 11:29:27 2015
From: j.mason at ed.ac.uk (Jonathan Mason)
Date: Mon, 30 Nov 2015 16:29:27 +0000
Subject: [Rtk-users] Preprocessing
Message-ID: <565C7967.4000401@ed.ac.uk>

Good afternoon RTK users,

I have access to "raw data" from a Varian OBI scanner, and have
experimented with RTK for performing its reconstruction. However, it is
not really "raw" in the sense that the coefficients are proportional to
the photon flux recorded at a given sensor, but is instead proportional
to the Hounsfield attenuation along that path. With this data, it means
that one can reconstruct using FDK and other iterative techniques, which
assume a linear model, but the connection to the underlying physics is
abstract.

The problem I then have when trying to develop reconstruction
techniques, is that I do not know whether I am really correcting for
physical distortions or just correcting for Varian's preprocessing,
which has been finely tuned for its own FDK method.

My question is whether anybody has dug into the steps that manufacturers
such as Varian or Elekta perform to arrive at these projection images?
And if they think that if reverse engineered, could provide a richer set
of information to facilitate advanced strategies.

Best wishes,

Jonathan Mason

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.



From simon.rit at creatis.insa-lyon.fr  Mon Nov 30 12:44:03 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Mon, 30 Nov 2015 18:44:03 +0100
Subject: [Rtk-users] ElectaReconstruction
In-Reply-To: <565C5D98.1000309@uclouvain.be>
References: <CALChM12F4PuiLvgENg3Yyn7E+uZ7iPJ+GiY04z7VQ-90AS83EA@mail.gmail.com>
 <565C5D98.1000309@uclouvain.be>
Message-ID: <CAF0oig2Zg96AZaRn9w9=F+LnLnyteTn5zS1rLguQ8WXiYhnnYg@mail.gmail.com>

Hi,
I think Cyril is right, it's not possible to use backslashes to put a
command line on several line with Windows command line. Can you confirm
this? If you confirm, we will correct the wiki.
Thanks,
Simon

On Mon, Nov 30, 2015 at 3:30 PM, Cyril Mory <cyril.mory at uclouvain.be> wrote:

> Hi, and welcome to RTK,
>
> Gengetopt is the piece of software that parses the command line arguments
> in all RTK applications. You do not have to "use" it. You just need to give
> correct arguments on the command line.
>
> The message "--output' ('-o') option required" means what it says : you
> need to provide the name of the file in which you want to store the
> geometry information generated by the application rtkelektasynergygeometry.
> If you just copy-pasted the command you found on the wiki, then something
> went wrong during the copy-paste. Try to run the following :
>
> rtkelektasynergygeometry --image_db IMAGE.DBF --frame_db FRAME.DBF
> --dicom_uid 1.3.46.423632.135428.1351013645.166 -o elektaGeometry
>
> I just removed the '\' and the useless spaces. You can do the same for all
> other command line examples and it should work.
>
> Let us know if you keep encountering trouble.
> Cyril
>
>
>
> Le 30/11/2015 12:06, niloufar teyfouri a ?crit :
>
>
> I ran the application of Electa Reconstruction implemented by you with
> RTK. But after debugging I was encountered with the message of
> "--output' ('-o') option required". Could you please help me for running
> this example and the other ones?
> I don't know any thing about the texts in the gray boxes mentioned at
> each link related to examples of RTK.
> For example in the link of
> http://wiki.openrtk.org/index.php/RTK/Examples/ElektaReconstruction
> how I should use gengetopt for the instructions below?
>
>
> 2. Run the application to convert Elekta's geometry into RTKs (DICOM_UID
> is contained in the subfolder name of the his files):
>
>   rtkelektasynergygeometry \
>     --image_db IMAGE.DBF \
>     --frame_db FRAME.DBF \
>     --dicom_uid 1.3.46.423632.135428.1351013645.166 \
>     -o elektaGeometry
>
> I would be appreciate if one could answer my question.
>
>
> _______________________________________________
> Rtk-users mailing listRtk-users at public.kitware.comhttp://public.kitware.com/mailman/listinfo/rtk-users
>
>
>
>
> ------------------------------
> [image: Avast logo] <https://www.avast.com/antivirus>
>
> L'absence de virus dans ce courrier ?lectronique a ?t? v?rifi?e par le
> logiciel antivirus Avast.
> www.avast.com <https://www.avast.com/antivirus>
>
>
> _______________________________________________
> 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/20151130/6d6dd6aa/attachment-0006.html>

From wuchao04 at gmail.com  Mon Nov 30 13:50:06 2015
From: wuchao04 at gmail.com (Chao Wu)
Date: Mon, 30 Nov 2015 19:50:06 +0100
Subject: [Rtk-users] Preprocessing
In-Reply-To: <565C7967.4000401@ed.ac.uk>
References: <565C7967.4000401@ed.ac.uk>
Message-ID: <CAH+sHrUFov5f=8h4-ePhC2xLraM3BxA9r12yfXdM3rrKPeqCBg@mail.gmail.com>

Hi Jonathan,

I do not quite understand your problem.
I think most information can be retrieved by the relationship between flux
(I) and attenuation (u):
I = I0 * exp (- integral(u * dL) )
Of course there are other effects like beam hardening and scattering
involved but this model is the basic.

Regards,
Chao

2015-11-30 17:29 GMT+01:00 Jonathan Mason <j.mason at ed.ac.uk>:

> Good afternoon RTK users,
>
> I have access to "raw data" from a Varian OBI scanner, and have
> experimented with RTK for performing its reconstruction. However, it is
> not really "raw" in the sense that the coefficients are proportional to
> the photon flux recorded at a given sensor, but is instead proportional
> to the Hounsfield attenuation along that path. With this data, it means
> that one can reconstruct using FDK and other iterative techniques, which
> assume a linear model, but the connection to the underlying physics is
> abstract.
>
> The problem I then have when trying to develop reconstruction
> techniques, is that I do not know whether I am really correcting for
> physical distortions or just correcting for Varian's preprocessing,
> which has been finely tuned for its own FDK method.
>
> My question is whether anybody has dug into the steps that manufacturers
> such as Varian or Elekta perform to arrive at these projection images?
> And if they think that if reverse engineered, could provide a richer set
> of information to facilitate advanced strategies.
>
> Best wishes,
>
> Jonathan Mason
>
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
> _______________________________________________
> 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/20151130/ccb833fe/attachment-0006.html>

From mdupont at cppm.in2p3.fr  Sun Nov  1 12:41:49 2015
From: mdupont at cppm.in2p3.fr (Mathieu Dupont)
Date: Sun, 01 Nov 2015 18:41:49 +0100
Subject: [Rtk-users] question about rtkDraw*ImageFilter
In-Reply-To: <56334CF2.8070902@cppm.in2p3.fr>
References: <5630EE01.5070900@cppm.in2p3.fr>
 <CAF0oig279ZWGJMFnJdXaPiYLPponadz_J-PVKt2z3iHiTRQ_gg@mail.gmail.com>
 <56334CF2.8070902@cppm.in2p3.fr>
Message-ID: <1539144.WPSdtJ8lhZ@marabunta>

Hello Simon, 

I started to implement what I suggested : 

https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawImageFilter.h
and 
https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawCylinderImageFilter.h

rtk::DrawCylinderImageFilter derives from rtk::DrawImageFilter and specializes 
it (by defaulting the template parameter TSpatialObject with 
DrawCylinderSpatialObject). 

By default, DrawCylinderImageFilter uses Add2 for filling output image (to be 
backward compatible (all tests pass)). I created Discard (I did not find 
equivalent in itk) functor in order to do what I wanted in my first email.  

I just implemented DrawCylinderImageFilter, the others will follow. 

What do you think about it ?

Le vendredi 30 octobre 2015, 11:56:50 Mathieu Dupont a ?crit :
> Hi,
> 
> In case of your first solution, you can not chain several
> Draw*ImageFilters. For example, if you want to create small cylinders in
> a big cylinder.
> 
> Your second solution is better.
> 
> One another solution can be a thing like itk:SpatialObject but more
> simpler. An rtk::SpatialObject which one function (isInside(point)). We
> create a rtkDrawImageFilter class and implement ThreadedGenerateData
> like this :
> 
> DrawImageFilter<InImage, OutImage, rtkSpatialObject,
> rtkFillFunctor>::ThreadedGenerateData(const OutputImageRegionType&
> outputRegionForThread,                 ThreadIdType itkNotUsed(threadId)
> {
> ...
> 
>   while( !itOut.IsAtEnd() )
>      {
>      this->GetInput()->TransformIndexToPhysicalPoint(itOut.GetIndex(),
> point);
> 
>     if(m_rtkSpatialObject.isInside(point)
>       itOut.Set(m_rtkFillFunctor(density, itIn.Get());
> ...
> }
> 
> 
> DrawConeImageFilter class can be a child of this new DrawImageFilter
> (with new methods like setAngle, SetRadius which will adjust the
> rtkConeSpatialObject)
> 
> This solution suppress duplicated code in
> Draw*ImageFilter::ThreadedGenerateData and makes easier implementation
> of another type of filling.
> 
> On 28/10/2015 20:52, Simon Rit wrote:
> > Hi Mathieu,
> > Thanks for pointing this out. I agree that it might not be the best
> > solution, yet one could argue that you could simply create a constant
> > image with 0 to do what you'd like from the current implementation. My
> > main problem is that I just tried to do what you suggest and some tests
> > then fail... which shows the obvious, it's not a backward compatible
> > change. I see two solutions:
> > - keep it as is and you use ConstantImageFilter + we remove useless add
> > filters,
> > - a more complex but maybe more elegant solution: add a third template
> > parameter for the operation that would allow the user to do what he'd
> > like in a functor. That's what's done with filters that derive from
> > itk::UnaryImageFilter
> > <http://www.itk.org/Doxygen/html/classitk_1_1UnaryFunctorImageFilter.html>
> > .
> > The default would be itk::Add2 but we could find or implement another
> > one that simply discards the pixel value.
> > What do you think?
> > Simon
> > 
> > PS: looking in the code, I just found that rtk::DrawConeImageFilter is
> > not consistent with the others, it was always setting to 0 outside...
> > that's been fixed!
> > 
> > On Wed, Oct 28, 2015 at 4:47 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr
> > 
> > <mailto:mdupont at cppm.in2p3.fr>> wrote:
> >     Hello everyone,
> >     
> >     I have a question/suggestion about the set of rtkDraw*ImageFilter.
> >     This filter are written as additive filters: for example, in
> >     rtkDrawEllipsoidImageFilter.txx, we can find
> >     
> >     for(..)
> >     
> >       itOut.Set( ellipsoid.density + itIn.Get() )
> >     
> >     instead of
> >     
> >     for(..)
> >     itOut.Set( ellipsoid.density )
> >     
> >     
> >     I think it can be more flexible the second option, because we can
> >     always associate Draw*ImageFilter and itkAddImageFilter to get an
> >     additive filter.
> >     
> >     Moreover, the  rtkDrawGeometricPhantomImageFilter class already uses
> >     itkAddImageFilter in order to have additive filters (which is
> >     redundant in current situation).
> >     
> >     What do you think ?
> >     
> >     
> >     
> >     
> >     
> >     Regards
> >     
> >     
> >     
> >     _______________________________________________
> >     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


From gnthibault at gmail.com  Mon Nov  2 08:08:42 2015
From: gnthibault at gmail.com (Notargiacomo Thibault)
Date: Mon, 2 Nov 2015 14:08:42 +0100
Subject: [Rtk-users] Problem with rtkGgoFunctions when importing series of
	images
Message-ID: <CAP+mR7Zw7WmRmEgVUTamNhS6m4S6ORvWFjRu1EANViPRJ7jtuQ@mail.gmail.com>

I recently experienced the following problem, when importing multiple tif
files inside a directory using itk::ImageSeriesReader:

[...]
code/rtkGgoFunctions.h: In instantiation of ?void
rtk::SetProjectionsReaderFromGgo(typename TProjectionsReaderType::Pointer,
const TArgsInfo&)
[...]
code/rtkGgoFunctions.h:121:61: error: no type named
?OutputImageDirectionType? in ?class
itk::ImageSeriesReader<itk::Image<short unsigned int, 3u> >?
   typename TProjectionsReaderType::OutputImageDirectionType direction;
[...]

It seems that, a new functionality added in rtkGgoFunctions.h (19/05/2015),
allowing to directly modify input images properties through command line,
like geometry (direction vector), assumes that the input image type defines
OutputImageDirectionType, but in the case of itk::ImageSeriesReader, it
does not.

Is this considered as a regression, or should the
SetProjectionsReaderFromGgo function be used with specific input image type
?

Thank you in advance for your help.

Kind regards

Thibault Notargiacomo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151102/6cad3583/attachment-0007.html>

From simon.rit at creatis.insa-lyon.fr  Mon Nov  2 08:58:24 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Mon, 2 Nov 2015 14:58:24 +0100
Subject: [Rtk-users] Problem with rtkGgoFunctions when importing series
	of images
In-Reply-To: <CAP+mR7Zw7WmRmEgVUTamNhS6m4S6ORvWFjRu1EANViPRJ7jtuQ@mail.gmail.com>
References: <CAP+mR7Zw7WmRmEgVUTamNhS6m4S6ORvWFjRu1EANViPRJ7jtuQ@mail.gmail.com>
Message-ID: <CAF0oig2bAidO4JR7pa_PUxOQm-X7JrEz8=ybGX3bskYJM9YRAQ@mail.gmail.com>

Hi Thibault,
SetProjectionsReaderFromGgo is a macro designed for the
rtk::ProjectionsReader
<http://www.openrtk.org/Doxygen/classrtk_1_1ProjectionsReader.html>, I'm
not surprised that it does not work with the itk::ImageSeriesReader. It's
not about the image type but about the filter type... We use this macro to
set many parameters specific to the rtk::ProjectionsReader
<http://www.openrtk.org/Doxygen/classrtk_1_1ProjectionsReader.html>. Since
a while, I have made have a common rtkinputprojections_section.ggo
<https://github.com/SimonRit/RTK/blob/master/applications/rtkinputprojections_section.ggo>
file for all the applications that use the rtk::ProjectionsReader.
If you don't want to use the rtk::ProjectionsReader but
itk::ImageSeriesReader (e.g., because it does a lot of automatic processing
that you don't want), you'll have to write your own code to set it up.
I hope this clarifies things.
Simon

On Mon, Nov 2, 2015 at 2:08 PM, Notargiacomo Thibault <gnthibault at gmail.com>
wrote:

> I recently experienced the following problem, when importing multiple tif
> files inside a directory using itk::ImageSeriesReader:
>
> [...]
> code/rtkGgoFunctions.h: In instantiation of ?void
> rtk::SetProjectionsReaderFromGgo(typename TProjectionsReaderType::Pointer,
> const TArgsInfo&)
> [...]
> code/rtkGgoFunctions.h:121:61: error: no type named
> ?OutputImageDirectionType? in ?class
> itk::ImageSeriesReader<itk::Image<short unsigned int, 3u> >?
>    typename TProjectionsReaderType::OutputImageDirectionType direction;
> [...]
>
> It seems that, a new functionality added in rtkGgoFunctions.h
> (19/05/2015), allowing to directly modify input images properties through
> command line, like geometry (direction vector), assumes that the input
> image type defines OutputImageDirectionType, but in the case of
> itk::ImageSeriesReader, it does not.
>
> Is this considered as a regression, or should the
> SetProjectionsReaderFromGgo function be used with specific input image type
> ?
>
> Thank you in advance for your help.
>
> Kind regards
>
> Thibault Notargiacomo
>
> _______________________________________________
> 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/20151102/ee7e2c17/attachment-0007.html>

From simon.rit at creatis.insa-lyon.fr  Wed Nov  4 16:38:18 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Wed, 4 Nov 2015 22:38:18 +0100
Subject: [Rtk-users] question about rtkDraw*ImageFilter
In-Reply-To: <1539144.WPSdtJ8lhZ@marabunta>
References: <5630EE01.5070900@cppm.in2p3.fr>
 <CAF0oig279ZWGJMFnJdXaPiYLPponadz_J-PVKt2z3iHiTRQ_gg@mail.gmail.com>
 <56334CF2.8070902@cppm.in2p3.fr> <1539144.WPSdtJ8lhZ@marabunta>
Message-ID: <CAF0oig3jBsfoadM_k6SYvOMwikOCNFmH19J7m1YJZx-RU0y+5g@mail.gmail.com>

Hi Mathieu,
Sorry, I'm very busy these days. I had a first quick look. Why not, it
looks a bit complicated but good. I would have a few things I would change
style wise, e.g., move DrawCylinderSpatialObject to
DrawCylinderImageFilter, create a common DrawQuadricSpatialObject that
would all have the same IsInside function, make DrawSpatialObjectpurely
virtual by not defining
IsInside etc. but those are details I can correct myself. Do you want to
finish what you started and I work from there or should I finish everything?
Simon

On Sun, Nov 1, 2015 at 6:41 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr>
wrote:

> Hello Simon,
>
> I started to implement what I suggested :
>
>
> https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawImageFilter.h
> and
>
> https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawCylinderImageFilter.h
>
> rtk::DrawCylinderImageFilter derives from rtk::DrawImageFilter and
> specializes
> it (by defaulting the template parameter TSpatialObject with
> DrawCylinderSpatialObject).
>
> By default, DrawCylinderImageFilter uses Add2 for filling output image (to
> be
> backward compatible (all tests pass)). I created Discard (I did not find
> equivalent in itk) functor in order to do what I wanted in my first email.
>
> I just implemented DrawCylinderImageFilter, the others will follow.
>
> What do you think about it ?
>
> Le vendredi 30 octobre 2015, 11:56:50 Mathieu Dupont a ?crit :
> > Hi,
> >
> > In case of your first solution, you can not chain several
> > Draw*ImageFilters. For example, if you want to create small cylinders in
> > a big cylinder.
> >
> > Your second solution is better.
> >
> > One another solution can be a thing like itk:SpatialObject but more
> > simpler. An rtk::SpatialObject which one function (isInside(point)). We
> > create a rtkDrawImageFilter class and implement ThreadedGenerateData
> > like this :
> >
> > DrawImageFilter<InImage, OutImage, rtkSpatialObject,
> > rtkFillFunctor>::ThreadedGenerateData(const OutputImageRegionType&
> > outputRegionForThread,                 ThreadIdType itkNotUsed(threadId)
> > {
> > ...
> >
> >   while( !itOut.IsAtEnd() )
> >      {
> >      this->GetInput()->TransformIndexToPhysicalPoint(itOut.GetIndex(),
> > point);
> >
> >     if(m_rtkSpatialObject.isInside(point)
> >       itOut.Set(m_rtkFillFunctor(density, itIn.Get());
> > ...
> > }
> >
> >
> > DrawConeImageFilter class can be a child of this new DrawImageFilter
> > (with new methods like setAngle, SetRadius which will adjust the
> > rtkConeSpatialObject)
> >
> > This solution suppress duplicated code in
> > Draw*ImageFilter::ThreadedGenerateData and makes easier implementation
> > of another type of filling.
> >
> > On 28/10/2015 20:52, Simon Rit wrote:
> > > Hi Mathieu,
> > > Thanks for pointing this out. I agree that it might not be the best
> > > solution, yet one could argue that you could simply create a constant
> > > image with 0 to do what you'd like from the current implementation. My
> > > main problem is that I just tried to do what you suggest and some tests
> > > then fail... which shows the obvious, it's not a backward compatible
> > > change. I see two solutions:
> > > - keep it as is and you use ConstantImageFilter + we remove useless add
> > > filters,
> > > - a more complex but maybe more elegant solution: add a third template
> > > parameter for the operation that would allow the user to do what he'd
> > > like in a functor. That's what's done with filters that derive from
> > > itk::UnaryImageFilter
> > > <
> http://www.itk.org/Doxygen/html/classitk_1_1UnaryFunctorImageFilter.html>
> > > .
> > > The default would be itk::Add2 but we could find or implement another
> > > one that simply discards the pixel value.
> > > What do you think?
> > > Simon
> > >
> > > PS: looking in the code, I just found that rtk::DrawConeImageFilter is
> > > not consistent with the others, it was always setting to 0 outside...
> > > that's been fixed!
> > >
> > > On Wed, Oct 28, 2015 at 4:47 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr
> > >
> > > <mailto:mdupont at cppm.in2p3.fr>> wrote:
> > >     Hello everyone,
> > >
> > >     I have a question/suggestion about the set of rtkDraw*ImageFilter.
> > >     This filter are written as additive filters: for example, in
> > >     rtkDrawEllipsoidImageFilter.txx, we can find
> > >
> > >     for(..)
> > >
> > >       itOut.Set( ellipsoid.density + itIn.Get() )
> > >
> > >     instead of
> > >
> > >     for(..)
> > >     itOut.Set( ellipsoid.density )
> > >
> > >
> > >     I think it can be more flexible the second option, because we can
> > >     always associate Draw*ImageFilter and itkAddImageFilter to get an
> > >     additive filter.
> > >
> > >     Moreover, the  rtkDrawGeometricPhantomImageFilter class already
> uses
> > >     itkAddImageFilter in order to have additive filters (which is
> > >     redundant in current situation).
> > >
> > >     What do you think ?
> > >
> > >
> > >
> > >
> > >
> > >     Regards
> > >
> > >
> > >
> > >     _______________________________________________
> > >     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/20151104/46314d97/attachment-0007.html>

From mdupont at cppm.in2p3.fr  Mon Nov  9 14:35:47 2015
From: mdupont at cppm.in2p3.fr (Mathieu Dupont)
Date: Mon, 09 Nov 2015 20:35:47 +0100
Subject: [Rtk-users] question about rtkDraw*ImageFilter
In-Reply-To: <CAF0oig3jBsfoadM_k6SYvOMwikOCNFmH19J7m1YJZx-RU0y+5g@mail.gmail.com>
References: <5630EE01.5070900@cppm.in2p3.fr> <1539144.WPSdtJ8lhZ@marabunta>
 <CAF0oig3jBsfoadM_k6SYvOMwikOCNFmH19J7m1YJZx-RU0y+5g@mail.gmail.com>
Message-ID: <5634494.U9CmFl2V79@marabunta>

hi, 

i will do this during this week and try to implement your remarks. 


Le mercredi 4 novembre 2015, 22:38:18 Simon Rit a ?crit :
> Hi Mathieu,
> Sorry, I'm very busy these days. I had a first quick look. Why not, it
> looks a bit complicated but good. I would have a few things I would change
> style wise, e.g., move DrawCylinderSpatialObject to
> DrawCylinderImageFilter, create a common DrawQuadricSpatialObject that
> would all have the same IsInside function, make DrawSpatialObjectpurely
> virtual by not defining
> IsInside etc. but those are details I can correct myself. Do you want to
> finish what you started and I work from there or should I finish everything?
> Simon
> 
> On Sun, Nov 1, 2015 at 6:41 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr>
> 
> wrote:
> > Hello Simon,
> > 
> > I started to implement what I suggested :
> > 
> > 
> > https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawImag
> > eFilter.h and
> > 
> > https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawCyli
> > nderImageFilter.h
> > 
> > rtk::DrawCylinderImageFilter derives from rtk::DrawImageFilter and
> > specializes
> > it (by defaulting the template parameter TSpatialObject with
> > DrawCylinderSpatialObject).
> > 
> > By default, DrawCylinderImageFilter uses Add2 for filling output image (to
> > be
> > backward compatible (all tests pass)). I created Discard (I did not find
> > equivalent in itk) functor in order to do what I wanted in my first email.
> > 
> > I just implemented DrawCylinderImageFilter, the others will follow.
> > 
> > What do you think about it ?
> > 
> > Le vendredi 30 octobre 2015, 11:56:50 Mathieu Dupont a ?crit :
> > > Hi,
> > > 
> > > In case of your first solution, you can not chain several
> > > Draw*ImageFilters. For example, if you want to create small cylinders in
> > > a big cylinder.
> > > 
> > > Your second solution is better.
> > > 
> > > One another solution can be a thing like itk:SpatialObject but more
> > > simpler. An rtk::SpatialObject which one function (isInside(point)). We
> > > create a rtkDrawImageFilter class and implement ThreadedGenerateData
> > > like this :
> > > 
> > > DrawImageFilter<InImage, OutImage, rtkSpatialObject,
> > > rtkFillFunctor>::ThreadedGenerateData(const OutputImageRegionType&
> > > outputRegionForThread,                 ThreadIdType itkNotUsed(threadId)
> > > {
> > > ...
> > > 
> > >   while( !itOut.IsAtEnd() )
> > >   
> > >      {
> > >      this->GetInput()->TransformIndexToPhysicalPoint(itOut.GetIndex(),
> > > 
> > > point);
> > > 
> > >     if(m_rtkSpatialObject.isInside(point)
> > >     
> > >       itOut.Set(m_rtkFillFunctor(density, itIn.Get());
> > > 
> > > ...
> > > }
> > > 
> > > 
> > > DrawConeImageFilter class can be a child of this new DrawImageFilter
> > > (with new methods like setAngle, SetRadius which will adjust the
> > > rtkConeSpatialObject)
> > > 
> > > This solution suppress duplicated code in
> > > Draw*ImageFilter::ThreadedGenerateData and makes easier implementation
> > > of another type of filling.
> > > 
> > > On 28/10/2015 20:52, Simon Rit wrote:
> > > > Hi Mathieu,
> > > > Thanks for pointing this out. I agree that it might not be the best
> > > > solution, yet one could argue that you could simply create a constant
> > > > image with 0 to do what you'd like from the current implementation. My
> > > > main problem is that I just tried to do what you suggest and some
> > > > tests
> > > > then fail... which shows the obvious, it's not a backward compatible
> > > > change. I see two solutions:
> > > > - keep it as is and you use ConstantImageFilter + we remove useless
> > > > add
> > > > filters,
> > > > - a more complex but maybe more elegant solution: add a third template
> > > > parameter for the operation that would allow the user to do what he'd
> > > > like in a functor. That's what's done with filters that derive from
> > > > itk::UnaryImageFilter
> > > > <
> > 
> > http://www.itk.org/Doxygen/html/classitk_1_1UnaryFunctorImageFilter.html>
> > 
> > > > .
> > > > The default would be itk::Add2 but we could find or implement another
> > > > one that simply discards the pixel value.
> > > > What do you think?
> > > > Simon
> > > > 
> > > > PS: looking in the code, I just found that rtk::DrawConeImageFilter is
> > > > not consistent with the others, it was always setting to 0 outside...
> > > > that's been fixed!
> > > > 
> > > > On Wed, Oct 28, 2015 at 4:47 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr
> > > > 
> > > > <mailto:mdupont at cppm.in2p3.fr>> wrote:
> > > >     Hello everyone,
> > > >     
> > > >     I have a question/suggestion about the set of rtkDraw*ImageFilter.
> > > >     This filter are written as additive filters: for example, in
> > > >     rtkDrawEllipsoidImageFilter.txx, we can find
> > > >     
> > > >     for(..)
> > > >     
> > > >       itOut.Set( ellipsoid.density + itIn.Get() )
> > > >     
> > > >     instead of
> > > >     
> > > >     for(..)
> > > >     itOut.Set( ellipsoid.density )
> > > >     
> > > >     
> > > >     I think it can be more flexible the second option, because we can
> > > >     always associate Draw*ImageFilter and itkAddImageFilter to get an
> > > >     additive filter.
> > > >     
> > > >     Moreover, the  rtkDrawGeometricPhantomImageFilter class already
> > 
> > uses
> > 
> > > >     itkAddImageFilter in order to have additive filters (which is
> > > >     redundant in current situation).
> > > >     
> > > >     What do you think ?
> > > >     
> > > >     
> > > >     
> > > >     
> > > >     
> > > >     Regards
> > > >     
> > > >     
> > > >     
> > > >     _______________________________________________
> > > >     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


From gnthibault at gmail.com  Tue Nov 10 07:39:46 2015
From: gnthibault at gmail.com (Notargiacomo Thibault)
Date: Tue, 10 Nov 2015 13:39:46 +0100
Subject: [Rtk-users] Understanding projection matrices management in
	rtkCudaBackProjectionImageFilter
Message-ID: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>

Hi all,

I am currently trying to use the "AddProjectionInRadians" method from the
ThreeDCircularProjectionGeometry class in RTK to import my geometry.

First things first, I would like to know if the information on this pdf are
still valid: http://www.openrtk.org/Doxygen/geometry.pdf

Because I used them to deduce the source offset and Projection offset from
my own matrix decomposition.

Notice that I don't want to use geometric informations coming from the
projection images themselves, so their geometric origin is assumed to be
(0,0,0) in my case.

In order to check if my geometry import method is correct, I print out one
of the intermediate form of the projection matrix used in the
backprojection process, in order to check if it is the same as in my own
implementation.

To do so, I print out one of the intermediate matrix that is generated in
rtkCudaBackProjectionImageFilter while launching a SART reconstruction for
instance.

I was surpised by the fact that, the matrix allowing the transformation
from 2D geometric world to 2D image index world, namely matrixIdxProj in
rtkCudaBackProjectionImageFilte.cxx
<http://www.openrtk.org/Doxygen/rtkCudaBackProjectionImageFilter_8cxx_source.html>
is not always the same along the reconstruction process ?

Here is the line that generates the matrix I don't understand:

for(unsigned int i=0; i<2; i++)
 //SR: 0.5 for 2D texture
  matrixIdxProj[i][2] =
-1*(this->GetInput(1)->GetBufferedRegion().GetIndex()[i])+0.5;

What I understand here, is that, we are generating a 2D translation matrix
embedded in a 3*3 matrix that allows to take into account two things
related to the 2D projection:

-If the internal behaviour of the imageContainer, allows buffering of only
a part of the image, beginning at index (i,j), this information will be
embeded in the projection matrix

-the ITK floating point addressing definition seems to differ from the one
from cuda (and openCV):
When I take a look at this page
<http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#texture-fetching>
I understand that the floating point indexing (0.5,0.5) in Cuda points to
the center of the pixel (0,0) hence a linear contribution of 100%, while it
seems that we must add a translation of (0.5,0.5) to the ITK geometric
framework in order to get the same behaviour.

In practice matrixIdxProj is based on a 3*3 identity matrix, where the
inner 2D translation (ie 2 first term of the last column) in my case are:
-in X, a random number between 10 and 150 plus 0.5
-in Y: always 0.5

I understand the 0.5 part, but why is there always a 0 offset in Y but a
random offset in X remains a mystery to me.

At first, I believed that each projection was splitted into multiple part,
each having a different X and Y offset.
But reconstructing using only one projection generates only one
backprojection operation, with a non zero offset in X, 123 in my case, for
an image of size 780 in X.

Do you think there is something wrong whith the values of matrixIdxProjI am
experiencing ?

Thank you in advance.

Kind regards

Thibault Notargiacomo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151110/fbd3fb46/attachment-0007.html>

From simon.rit at creatis.insa-lyon.fr  Tue Nov 10 08:21:29 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Tue, 10 Nov 2015 14:21:29 +0100
Subject: [Rtk-users] Understanding projection matrices management in
	rtkCudaBackProjectionImageFilter
In-Reply-To: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>
References: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>
Message-ID: <CAF0oig3muuH+1=eLZ66DJ22QcnsSrUKzRFS4RzDRvDJXNxAVXg@mail.gmail.com>

Hi Thibault,
You started digging in the code so that gets complicated. First thing
first, yes, the link you provide is still valid.
The offset in X is not random but computed in
BackProjectionImageFilter::GenerateInputRequestedRegion
<https://github.com/SimonRit/RTK/blob/master/code/rtkBackProjectionImageFilter.txx>.
The idea is that we request only the part of the projections we need to do
the backprojection. This optimizes the streaming (we only read from disk
what we need). If you use a huge volume (the test I'd suggest to validate
that I'm correct and there is nothing wrong with your code), then you'll
need the full projection and you will always get 0 in X as in Y. If you use
a small volume and do a computation projection per projection, you will get
a varying index depending on your input volume and the geometry for that
projection.
I think you understood the rest pretty well. Does that make sense or am I
missing something else?
Simon

On Tue, Nov 10, 2015 at 1:39 PM, Notargiacomo Thibault <gnthibault at gmail.com
> wrote:

> Hi all,
>
> I am currently trying to use the "AddProjectionInRadians" method from the
> ThreeDCircularProjectionGeometry class in RTK to import my geometry.
>
> First things first, I would like to know if the information on this pdf
> are still valid: http://www.openrtk.org/Doxygen/geometry.pdf
>
> Because I used them to deduce the source offset and Projection offset from
> my own matrix decomposition.
>
> Notice that I don't want to use geometric informations coming from the
> projection images themselves, so their geometric origin is assumed to be
> (0,0,0) in my case.
>
> In order to check if my geometry import method is correct, I print out one
> of the intermediate form of the projection matrix used in the
> backprojection process, in order to check if it is the same as in my own
> implementation.
>
> To do so, I print out one of the intermediate matrix that is generated in
> rtkCudaBackProjectionImageFilter while launching a SART reconstruction for
> instance.
>
> I was surpised by the fact that, the matrix allowing the transformation
> from 2D geometric world to 2D image index world, namely matrixIdxProj in
> rtkCudaBackProjectionImageFilte.cxx
> <http://www.openrtk.org/Doxygen/rtkCudaBackProjectionImageFilter_8cxx_source.html>
> is not always the same along the reconstruction process ?
>
> Here is the line that generates the matrix I don't understand:
>
> for(unsigned int i=0; i<2; i++)
>  //SR: 0.5 for 2D texture
>   matrixIdxProj[i][2] =
> -1*(this->GetInput(1)->GetBufferedRegion().GetIndex()[i])+0.5;
>
> What I understand here, is that, we are generating a 2D translation matrix
> embedded in a 3*3 matrix that allows to take into account two things
> related to the 2D projection:
>
> -If the internal behaviour of the imageContainer, allows buffering of only
> a part of the image, beginning at index (i,j), this information will be
> embeded in the projection matrix
>
> -the ITK floating point addressing definition seems to differ from the one
> from cuda (and openCV):
> When I take a look at this page
> <http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#texture-fetching>
> I understand that the floating point indexing (0.5,0.5) in Cuda points to
> the center of the pixel (0,0) hence a linear contribution of 100%, while it
> seems that we must add a translation of (0.5,0.5) to the ITK geometric
> framework in order to get the same behaviour.
>
> In practice matrixIdxProj is based on a 3*3 identity matrix, where the
> inner 2D translation (ie 2 first term of the last column) in my case are:
> -in X, a random number between 10 and 150 plus 0.5
> -in Y: always 0.5
>
> I understand the 0.5 part, but why is there always a 0 offset in Y but a
> random offset in X remains a mystery to me.
>
> At first, I believed that each projection was splitted into multiple part,
> each having a different X and Y offset.
> But reconstructing using only one projection generates only one
> backprojection operation, with a non zero offset in X, 123 in my case, for
> an image of size 780 in X.
>
> Do you think there is something wrong whith the values of matrixIdxProjI
> am experiencing ?
>
> Thank you in advance.
>
> Kind regards
>
> Thibault Notargiacomo
>
> _______________________________________________
> 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/20151110/8b9b86e6/attachment-0007.html>

From simon.rit at creatis.insa-lyon.fr  Tue Nov 10 09:03:52 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Tue, 10 Nov 2015 15:03:52 +0100
Subject: [Rtk-users] Understanding projection matrices management in
	rtkCudaBackProjectionImageFilter
In-Reply-To: <CAP+mR7ZLJV8V5dMOW_jgM5G2-kCZhy8o0tB19685LGo-1bxLUg@mail.gmail.com>
References: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>
 <CAF0oig3muuH+1=eLZ66DJ22QcnsSrUKzRFS4RzDRvDJXNxAVXg@mail.gmail.com>
 <CAP+mR7ZLJV8V5dMOW_jgM5G2-kCZhy8o0tB19685LGo-1bxLUg@mail.gmail.com>
Message-ID: <CAF0oig3fALRnZNCJ53+TsSjBm7raRC_mqahWEU6x+D+zxwOnVQ@mail.gmail.com>

A small correction: it's actually the amount of data pre-processed (read
from disk + all the processing before backprojection) but that should
change nothing to what is backprojected.
I remembered something that can help you: you may want to run
UpdateLargestPossibleRegion() to the projections (input 1 of the
BackProjectImageFilter) before backprojection to avoid this and make things
clearer instead of using a large volume as I was suggesting before.
Simon

On Tue, Nov 10, 2015 at 2:34 PM, Notargiacomo Thibault <gnthibault at gmail.com
> wrote:

> Ok, using geometric information to reduce the amount of data to be
> backprojected is pretty clever ;)
> This explains the "random" index I was asking about in my previous
> question, I now know what it is used for and continue my debugging process.
>
> Kind regards
>
> Thibault Notargiacomo
>
> 2015-11-10 14:21 GMT+01:00 Simon Rit <simon.rit at creatis.insa-lyon.fr>:
>
>> Hi Thibault,
>> You started digging in the code so that gets complicated. First thing
>> first, yes, the link you provide is still valid.
>> The offset in X is not random but computed in
>> BackProjectionImageFilter::GenerateInputRequestedRegion
>> <https://github.com/SimonRit/RTK/blob/master/code/rtkBackProjectionImageFilter.txx>.
>> The idea is that we request only the part of the projections we need to do
>> the backprojection. This optimizes the streaming (we only read from disk
>> what we need). If you use a huge volume (the test I'd suggest to validate
>> that I'm correct and there is nothing wrong with your code), then you'll
>> need the full projection and you will always get 0 in X as in Y. If you use
>> a small volume and do a computation projection per projection, you will get
>> a varying index depending on your input volume and the geometry for that
>> projection.
>> I think you understood the rest pretty well. Does that make sense or am I
>> missing something else?
>> Simon
>>
>> On Tue, Nov 10, 2015 at 1:39 PM, Notargiacomo Thibault <
>> gnthibault at gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> I am currently trying to use the "AddProjectionInRadians" method from
>>> the ThreeDCircularProjectionGeometry class in RTK to import my geometry.
>>>
>>> First things first, I would like to know if the information on this pdf
>>> are still valid: http://www.openrtk.org/Doxygen/geometry.pdf
>>>
>>> Because I used them to deduce the source offset and Projection offset
>>> from my own matrix decomposition.
>>>
>>> Notice that I don't want to use geometric informations coming from the
>>> projection images themselves, so their geometric origin is assumed to be
>>> (0,0,0) in my case.
>>>
>>> In order to check if my geometry import method is correct, I print out
>>> one of the intermediate form of the projection matrix used in the
>>> backprojection process, in order to check if it is the same as in my own
>>> implementation.
>>>
>>> To do so, I print out one of the intermediate matrix that is generated
>>> in rtkCudaBackProjectionImageFilter while launching a SART reconstruction
>>> for instance.
>>>
>>> I was surpised by the fact that, the matrix allowing the transformation
>>> from 2D geometric world to 2D image index world, namely matrixIdxProj in
>>> rtkCudaBackProjectionImageFilte.cxx
>>> <http://www.openrtk.org/Doxygen/rtkCudaBackProjectionImageFilter_8cxx_source.html>
>>> is not always the same along the reconstruction process ?
>>>
>>> Here is the line that generates the matrix I don't understand:
>>>
>>> for(unsigned int i=0; i<2; i++)
>>>  //SR: 0.5 for 2D texture
>>>   matrixIdxProj[i][2] =
>>> -1*(this->GetInput(1)->GetBufferedRegion().GetIndex()[i])+0.5;
>>>
>>> What I understand here, is that, we are generating a 2D translation
>>> matrix embedded in a 3*3 matrix that allows to take into account two things
>>> related to the 2D projection:
>>>
>>> -If the internal behaviour of the imageContainer, allows buffering of
>>> only a part of the image, beginning at index (i,j), this information will
>>> be embeded in the projection matrix
>>>
>>> -the ITK floating point addressing definition seems to differ from the
>>> one from cuda (and openCV):
>>> When I take a look at this page
>>> <http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#texture-fetching>
>>> I understand that the floating point indexing (0.5,0.5) in Cuda points to
>>> the center of the pixel (0,0) hence a linear contribution of 100%, while it
>>> seems that we must add a translation of (0.5,0.5) to the ITK geometric
>>> framework in order to get the same behaviour.
>>>
>>> In practice matrixIdxProj is based on a 3*3 identity matrix, where the
>>> inner 2D translation (ie 2 first term of the last column) in my case are:
>>> -in X, a random number between 10 and 150 plus 0.5
>>> -in Y: always 0.5
>>>
>>> I understand the 0.5 part, but why is there always a 0 offset in Y but a
>>> random offset in X remains a mystery to me.
>>>
>>> At first, I believed that each projection was splitted into multiple
>>> part, each having a different X and Y offset.
>>> But reconstructing using only one projection generates only one
>>> backprojection operation, with a non zero offset in X, 123 in my case, for
>>> an image of size 780 in X.
>>>
>>> Do you think there is something wrong whith the values of matrixIdxProjI
>>> am experiencing ?
>>>
>>> Thank you in advance.
>>>
>>> Kind regards
>>>
>>> Thibault Notargiacomo
>>>
>>> _______________________________________________
>>> 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/20151110/d8913dc3/attachment-0007.html>

From simon.rit at creatis.insa-lyon.fr  Tue Nov 10 11:21:29 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Tue, 10 Nov 2015 17:21:29 +0100
Subject: [Rtk-users] Understanding projection matrices management in
	rtkCudaBackProjectionImageFilter
In-Reply-To: <CAP+mR7ZKqnbUyRHyHkti=3sZd2dEw-OUV6oqsqcga55=tcQ9OQ@mail.gmail.com>
References: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>
 <CAF0oig3muuH+1=eLZ66DJ22QcnsSrUKzRFS4RzDRvDJXNxAVXg@mail.gmail.com>
 <CAP+mR7ZLJV8V5dMOW_jgM5G2-kCZhy8o0tB19685LGo-1bxLUg@mail.gmail.com>
 <CAF0oig3fALRnZNCJ53+TsSjBm7raRC_mqahWEU6x+D+zxwOnVQ@mail.gmail.com>
 <CAP+mR7ZKqnbUyRHyHkti=3sZd2dEw-OUV6oqsqcga55=tcQ9OQ@mail.gmail.com>
Message-ID: <CAF0oig12pRGBfgiCQMCwTG7zX_3vz87AEWhTQ4EYaVbH_m0t5Q@mail.gmail.com>

Your welcome (I cc the mailing list for info).
Simon

On Tue, Nov 10, 2015 at 5:03 PM, Notargiacomo Thibault <gnthibault at gmail.com
> wrote:

> I replaced the original Update by the "UpdateLargestPossibleRegion" to the
> divideFilter in SART (I bypassed displacedDetectorFilter for now) and it
> work as expected, I have now a "clean" matProjIdx.
>
> Thank you for your help !
>
> 2015-11-10 15:03 GMT+01:00 Simon Rit <simon.rit at creatis.insa-lyon.fr>:
>
>> A small correction: it's actually the amount of data pre-processed (read
>> from disk + all the processing before backprojection) but that should
>> change nothing to what is backprojected.
>> I remembered something that can help you: you may want to run
>> UpdateLargestPossibleRegion() to the projections (input 1 of the
>> BackProjectImageFilter) before backprojection to avoid this and make things
>> clearer instead of using a large volume as I was suggesting before.
>> Simon
>>
>> On Tue, Nov 10, 2015 at 2:34 PM, Notargiacomo Thibault <
>> gnthibault at gmail.com> wrote:
>>
>>> Ok, using geometric information to reduce the amount of data to be
>>> backprojected is pretty clever ;)
>>> This explains the "random" index I was asking about in my previous
>>> question, I now know what it is used for and continue my debugging process.
>>>
>>> Kind regards
>>>
>>> Thibault Notargiacomo
>>>
>>> 2015-11-10 14:21 GMT+01:00 Simon Rit <simon.rit at creatis.insa-lyon.fr>:
>>>
>>>> Hi Thibault,
>>>> You started digging in the code so that gets complicated. First thing
>>>> first, yes, the link you provide is still valid.
>>>> The offset in X is not random but computed in
>>>> BackProjectionImageFilter::GenerateInputRequestedRegion
>>>> <https://github.com/SimonRit/RTK/blob/master/code/rtkBackProjectionImageFilter.txx>.
>>>> The idea is that we request only the part of the projections we need to do
>>>> the backprojection. This optimizes the streaming (we only read from disk
>>>> what we need). If you use a huge volume (the test I'd suggest to validate
>>>> that I'm correct and there is nothing wrong with your code), then you'll
>>>> need the full projection and you will always get 0 in X as in Y. If you use
>>>> a small volume and do a computation projection per projection, you will get
>>>> a varying index depending on your input volume and the geometry for that
>>>> projection.
>>>> I think you understood the rest pretty well. Does that make sense or am
>>>> I missing something else?
>>>> Simon
>>>>
>>>> On Tue, Nov 10, 2015 at 1:39 PM, Notargiacomo Thibault <
>>>> gnthibault at gmail.com> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I am currently trying to use the "AddProjectionInRadians" method from
>>>>> the ThreeDCircularProjectionGeometry class in RTK to import my geometry.
>>>>>
>>>>> First things first, I would like to know if the information on this
>>>>> pdf are still valid: http://www.openrtk.org/Doxygen/geometry.pdf
>>>>>
>>>>> Because I used them to deduce the source offset and Projection offset
>>>>> from my own matrix decomposition.
>>>>>
>>>>> Notice that I don't want to use geometric informations coming from the
>>>>> projection images themselves, so their geometric origin is assumed to be
>>>>> (0,0,0) in my case.
>>>>>
>>>>> In order to check if my geometry import method is correct, I print out
>>>>> one of the intermediate form of the projection matrix used in the
>>>>> backprojection process, in order to check if it is the same as in my own
>>>>> implementation.
>>>>>
>>>>> To do so, I print out one of the intermediate matrix that is generated
>>>>> in rtkCudaBackProjectionImageFilter while launching a SART reconstruction
>>>>> for instance.
>>>>>
>>>>> I was surpised by the fact that, the matrix allowing the
>>>>> transformation from 2D geometric world to 2D image index world, namely
>>>>> matrixIdxProj in rtkCudaBackProjectionImageFilte.cxx
>>>>> <http://www.openrtk.org/Doxygen/rtkCudaBackProjectionImageFilter_8cxx_source.html>
>>>>> is not always the same along the reconstruction process ?
>>>>>
>>>>> Here is the line that generates the matrix I don't understand:
>>>>>
>>>>> for(unsigned int i=0; i<2; i++)
>>>>>  //SR: 0.5 for 2D texture
>>>>>   matrixIdxProj[i][2] =
>>>>> -1*(this->GetInput(1)->GetBufferedRegion().GetIndex()[i])+0.5;
>>>>>
>>>>> What I understand here, is that, we are generating a 2D translation
>>>>> matrix embedded in a 3*3 matrix that allows to take into account two things
>>>>> related to the 2D projection:
>>>>>
>>>>> -If the internal behaviour of the imageContainer, allows buffering of
>>>>> only a part of the image, beginning at index (i,j), this information will
>>>>> be embeded in the projection matrix
>>>>>
>>>>> -the ITK floating point addressing definition seems to differ from the
>>>>> one from cuda (and openCV):
>>>>> When I take a look at this page
>>>>> <http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#texture-fetching>
>>>>> I understand that the floating point indexing (0.5,0.5) in Cuda points to
>>>>> the center of the pixel (0,0) hence a linear contribution of 100%, while it
>>>>> seems that we must add a translation of (0.5,0.5) to the ITK geometric
>>>>> framework in order to get the same behaviour.
>>>>>
>>>>> In practice matrixIdxProj is based on a 3*3 identity matrix, where
>>>>> the inner 2D translation (ie 2 first term of the last column) in my case
>>>>> are:
>>>>> -in X, a random number between 10 and 150 plus 0.5
>>>>> -in Y: always 0.5
>>>>>
>>>>> I understand the 0.5 part, but why is there always a 0 offset in Y but
>>>>> a random offset in X remains a mystery to me.
>>>>>
>>>>> At first, I believed that each projection was splitted into multiple
>>>>> part, each having a different X and Y offset.
>>>>> But reconstructing using only one projection generates only one
>>>>> backprojection operation, with a non zero offset in X, 123 in my case, for
>>>>> an image of size 780 in X.
>>>>>
>>>>> Do you think there is something wrong whith the values of matrixIdxProjI
>>>>> am experiencing ?
>>>>>
>>>>> Thank you in advance.
>>>>>
>>>>> Kind regards
>>>>>
>>>>> Thibault Notargiacomo
>>>>>
>>>>> _______________________________________________
>>>>> 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/20151110/b7eba683/attachment-0007.html>

From theday79 at gmail.com  Wed Nov 11 13:50:45 2015
From: theday79 at gmail.com (Yang K Park)
Date: Wed, 11 Nov 2015 13:50:45 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after  a recent update
Message-ID: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>

Hi all,

 

I?ve updated rtk with the up-to-date revision and have encountered a couple of problems.

 

1.       Compile error: RTK couldn?t find itkMacro.h while it compiled rtkCudaUtilities.hcu. It was solved by a minor fetching:

#include <itkMacro.h>   --> #include "itkMacro.h" in rtkCudaUtilities.hcu

 

2.       Output of rtkfdk with CUDA was not the same as before. It was very blurry as seen in the attached image.

a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.

 

 

I?m using VS2013 with win7, itk4.8.1.

 

The command line I used was :

rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware cuda --pad 1 --hann 5 --hannY 5

 

Does anyone have any idea about this?

 

Thanks.

 

Yang

 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151111/b1c7df5f/attachment-0007.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 16577 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151111/b1c7df5f/attachment-0007.png>

From simon.rit at creatis.insa-lyon.fr  Wed Nov 11 16:15:49 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Wed, 11 Nov 2015 22:15:49 +0100
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
Message-ID: <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>

Hi,
I didn't manage to reproduce the two problems on linux with the same
ITK version.
For point 1, did you copy itkMacro.h by hand? Because I don't see how
replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not
in the same folder as rtkCudaUtilities.hcu
For point 2, no clue. Do you use FFTW? It looks like a ramp filter
issue. Can you try rtkramp --path projPath --regexp .*.his, with and
without --hardware cuda? Maybe you can provide your geometry file in
case it's a specific geometric issue.
Simon

On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
> Hi all,
>
>
>
> I?ve updated rtk with the up-to-date revision and have encountered a couple
> of problems.
>
>
>
> 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
> rtkCudaUtilities.hcu. It was solved by a minor fetching:
>
> #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>
>
>
> 2.       Output of rtkfdk with CUDA was not the same as before. It was very
> blurry as seen in the attached image.
>
> a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>
>
>
>
>
> I?m using VS2013 with win7, itk4.8.1.
>
>
>
> The command line I used was :
>
> rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his --output
> output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware cuda --pad 1
> --hann 5 --hannY 5
>
>
>
> Does anyone have any idea about this?
>
>
>
> Thanks.
>
>
>
> Yang
>
>
>
>
> _______________________________________________
> Rtk-users mailing list
> Rtk-users at public.kitware.com
> http://public.kitware.com/mailman/listinfo/rtk-users
>


From theday79 at gmail.com  Thu Nov 12 17:39:38 2015
From: theday79 at gmail.com (Yang K Park)
Date: Thu, 12 Nov 2015 17:39:38 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
Message-ID: <000001d11d9b$04142320$0c3c6960$@gmail.com>

Hi Simon,

 

Thanks for the advice. The current RTK was compiled with FFTW to use the phase extraction feature from Amsterdam shroud.

 

Regarding your suggestions,

 

1)      rtkramp w/ or w/o CUDA:

(command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda --output Ramp_wCUDA.mha? )

 

Then, I have encountered following error.

?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that input requested and buffered regions are equal.?

 



 

Without CUDA, it was successfully done.

 

2)      I?ve re-compiled ITK w/o FFTW and built RTK again. rtkfdk worked fine.

-          I?ve also repeated ?rtkramp+CUDA? with this rtk version and the error was same as above.

 

In conclusion, my FFTW seems to affect CUDA-based fdk reconstruction only.

But I do need FFTW for the phase extraction. What should I do?

 

Thanks.

 

Yang

 

 

-----Original Message-----
From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit
Sent: Wednesday, November 11, 2015 4:16 PM
To: Yang K Park <theday79 at gmail.com>
Cc: rtk-users at openrtk.org
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

I didn't manage to reproduce the two problems on linux with the same ITK version.

For point 1, did you copy itkMacro.h by hand? Because I don't see how replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW? It looks like a ramp filter issue. Can you try rtkramp --path projPath --regexp .*.his, with and without --hardware cuda? Maybe you can provide your geometry file in case it's a specific geometric issue.

Simon

 

On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park < <mailto:theday79 at gmail.com> theday79 at gmail.com> wrote:

> Hi all,

> 

> 

> 

> I?ve updated rtk with the up-to-date revision and have encountered a 

> couple of problems.

> 

> 

> 

> 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled

> rtkCudaUtilities.hcu. It was solved by a minor fetching:

> 

> #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu

> 

> 

> 

> 2.       Output of rtkfdk with CUDA was not the same as before. It was very

> blurry as seen in the attached image.

> 

> a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.

> 

> 

> 

> 

> 

> I?m using VS2013 with win7, itk4.8.1.

> 

> 

> 

> The command line I used was :

> 

> rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his 

> --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware 

> cuda --pad 1 --hann 5 --hannY 5

> 

> 

> 

> Does anyone have any idea about this?

> 

> 

> 

> Thanks.

> 

> 

> 

> Yang

> 

> 

> 

> 

> _______________________________________________

> Rtk-users mailing list

>  <mailto: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/20151112/4e0825dc/attachment-0007.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151112/4e0825dc/attachment-0007.png>

From simon.rit at creatis.insa-lyon.fr  Thu Nov 12 17:58:42 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Thu, 12 Nov 2015 23:58:42 +0100
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <000001d11d9b$04142320$0c3c6960$@gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
Message-ID: <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>

Hi,
Ok. Can you try rtkramp with only one projection? Then you shouldn't
encounter this regions issue (that should be solved one day but that's a
different story).
Can you also indicate which version of CUDA you're using?
FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft for
the FFT of the projections. So if they are not in the same format, you're
in trouble and that might be the issue here... The weird part is that I
didn't reproduce this problem on linux (with and without FFTW) but it might
be a CUDA version difference. I'll give it another try tomorrow when you
provide the CUDA version.
Thanks again for reporting the issue,
Simon

On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com> wrote:

> Hi Simon,
>
>
>
> Thanks for the advice. The current RTK was compiled with FFTW to use the
> phase extraction feature from Amsterdam shroud.
>
>
>
> Regarding your suggestions,
>
>
>
> 1)      rtkramp w/ or w/o CUDA:
>
> (command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda
> --output Ramp_wCUDA.mha? )
>
>
>
> Then, I have encountered following error.
>
> ?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that
> input requested and buffered regions are equal.?
>
>
>
>
>
> Without CUDA, it was successfully done.
>
>
>
> 2)      I?ve re-compiled *ITK w/o FFTW* and built RTK again. r*tkfdk
> worked fine.*
>
> -          I?ve also repeated ?rtkramp+CUDA? with this rtk version and
> the error was same as above.
>
>
>
> In conclusion, my *FFTW seems to affect CUDA-based fdk reconstruction
> only*.
>
> But I do need FFTW for the phase extraction. What should I do?
>
>
>
> Thanks.
>
>
>
> Yang
>
>
>
>
>
> -----Original Message-----
> From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon
> Rit
> Sent: Wednesday, November 11, 2015 4:16 PM
> To: Yang K Park <theday79 at gmail.com>
> Cc: rtk-users at openrtk.org
> Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
> update
>
>
>
> Hi,
>
> I didn't manage to reproduce the two problems on linux with the same ITK
> version.
>
> For point 1, did you copy itkMacro.h by hand? Because I don't see how
> replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the
> same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW?
> It looks like a ramp filter issue. Can you try rtkramp --path projPath
> --regexp .*.his, with and without --hardware cuda? Maybe you can provide
> your geometry file in case it's a specific geometric issue.
>
> Simon
>
>
>
> On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
>
> > Hi all,
>
> >
>
> >
>
> >
>
> > I?ve updated rtk with the up-to-date revision and have encountered a
>
> > couple of problems.
>
> >
>
> >
>
> >
>
> > 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
>
> > rtkCudaUtilities.hcu. It was solved by a minor fetching:
>
> >
>
> > #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>
> >
>
> >
>
> >
>
> > 2.       Output of rtkfdk with CUDA was not the same as before. It was
> very
>
> > blurry as seen in the attached image.
>
> >
>
> > a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > I?m using VS2013 with win7, itk4.8.1.
>
> >
>
> >
>
> >
>
> > The command line I used was :
>
> >
>
> > rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his
>
> > --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware
>
> > cuda --pad 1 --hann 5 --hannY 5
>
> >
>
> >
>
> >
>
> > Does anyone have any idea about this?
>
> >
>
> >
>
> >
>
> > Thanks.
>
> >
>
> >
>
> >
>
> > Yang
>
> >
>
> >
>
> >
>
> >
>
> > _______________________________________________
>
> > 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/20151112/e7c15ff8/attachment-0007.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151112/e7c15ff8/attachment-0007.png>

From theday79 at gmail.com  Mon Nov 16 09:54:01 2015
From: theday79 at gmail.com (Yang K Park)
Date: Mon, 16 Nov 2015 09:54:01 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
Message-ID: <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>

Hi Simon,

 

Sorry for the late response.

 

As you suggested, I?ve tried rtkramp+CUDA with only one projection and it was successfully done for both w/ FFTW and w/o FFTW.

(Two results were exactly same.)

 

Regarding  the CUDA version, I?m using v6.5.

 

Thanks a lot for the help!

 

Yang

 

 

From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit
Sent: Thursday, November 12, 2015 5:59 PM
To: Yang K Park <theday79 at gmail.com>
Cc: rtk-users at openrtk.org
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

Ok. Can you try rtkramp with only one projection? Then you shouldn't encounter this regions issue (that should be solved one day but that's a different story). 

Can you also indicate which version of CUDA you're using?

FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft for the FFT of the projections. So if they are not in the same format, you're in trouble and that might be the issue here... The weird part is that I didn't reproduce this problem on linux (with and without FFTW) but it might be a CUDA version difference. I'll give it another try tomorrow when you provide the CUDA version.

Thanks again for reporting the issue,
Simon

 

On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> > wrote:

Hi Simon,

 

Thanks for the advice. The current RTK was compiled with FFTW to use the phase extraction feature from Amsterdam shroud.

 

Regarding your suggestions,

 

1)      rtkramp w/ or w/o CUDA:

(command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda --output Ramp_wCUDA.mha? )

 

Then, I have encountered following error.

?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that input requested and buffered regions are equal.?

 



 

Without CUDA, it was successfully done.

 

2)      I?ve re-compiled ITK w/o FFTW and built RTK again. rtkfdk worked fine.

-          I?ve also repeated ?rtkramp+CUDA? with this rtk version and the error was same as above.

 

In conclusion, my FFTW seems to affect CUDA-based fdk reconstruction only.

But I do need FFTW for the phase extraction. What should I do?

 

Thanks.

 

Yang

 

 

-----Original Message-----
From: simon.rit at gmail.com <mailto:simon.rit at gmail.com>  [mailto:simon.rit at gmail.com <mailto:simon.rit at gmail.com> ] On Behalf Of Simon Rit
Sent: Wednesday, November 11, 2015 4:16 PM
To: Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> >
Cc: rtk-users at openrtk.org <mailto:rtk-users at openrtk.org> 
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

I didn't manage to reproduce the two problems on linux with the same ITK version.

For point 1, did you copy itkMacro.h by hand? Because I don't see how replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW? It looks like a ramp filter issue. Can you try rtkramp --path projPath --regexp .*.his, with and without --hardware cuda? Maybe you can provide your geometry file in case it's a specific geometric issue.

Simon

 

On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park < <mailto:theday79 at gmail.com> theday79 at gmail.com> wrote:

> Hi all,

> 

> 

> 

> I?ve updated rtk with the up-to-date revision and have encountered a 

> couple of problems.

> 

> 

> 

> 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled

> rtkCudaUtilities.hcu. It was solved by a minor fetching:

> 

> #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu

> 

> 

> 

> 2.       Output of rtkfdk with CUDA was not the same as before. It was very

> blurry as seen in the attached image.

> 

> a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.

> 

> 

> 

> 

> 

> I?m using VS2013 with win7, itk4.8.1.

> 

> 

> 

> The command line I used was :

> 

> rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his 

> --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware 

> cuda --pad 1 --hann 5 --hannY 5

> 

> 

> 

> Does anyone have any idea about this?

> 

> 

> 

> Thanks.

> 

> 

> 

> Yang

> 

> 

> 

> 

> _______________________________________________

> Rtk-users mailing list

>  <mailto: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/20151116/e77c2f96/attachment-0007.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151116/e77c2f96/attachment-0007.png>

From simon.rit at creatis.insa-lyon.fr  Mon Nov 16 10:07:46 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Mon, 16 Nov 2015 16:07:46 +0100
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
 <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
Message-ID: <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>

Hi,
Thanks. It's really weird... When you run the tests with FFTW (compiling
the "test" target), do they fail?
Can you provide your geometry file? It might be specific to this geometry.
Thanks again for looking into this issue, we'll find what's the problem.
Simon

On Mon, Nov 16, 2015 at 3:54 PM, Yang K Park <theday79 at gmail.com> wrote:

> Hi Simon,
>
>
>
> Sorry for the late response.
>
>
>
> As you suggested, I?ve tried rtkramp+CUDA with only one projection and it
> was successfully done for both w/ FFTW and w/o FFTW.
>
> (Two results were exactly same.)
>
>
>
> Regarding  the CUDA version, I?m using v6.5.
>
>
>
> Thanks a lot for the help!
>
>
>
> Yang
>
>
>
>
>
> *From:* simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of *Simon
> Rit
> *Sent:* Thursday, November 12, 2015 5:59 PM
>
> *To:* Yang K Park <theday79 at gmail.com>
> *Cc:* rtk-users at openrtk.org
> *Subject:* Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
> update
>
>
>
> Hi,
>
> Ok. Can you try rtkramp with only one projection? Then you shouldn't
> encounter this regions issue (that should be solved one day but that's a
> different story).
>
> Can you also indicate which version of CUDA you're using?
>
> FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft for
> the FFT of the projections. So if they are not in the same format, you're
> in trouble and that might be the issue here... The weird part is that I
> didn't reproduce this problem on linux (with and without FFTW) but it might
> be a CUDA version difference. I'll give it another try tomorrow when you
> provide the CUDA version.
>
> Thanks again for reporting the issue,
> Simon
>
>
>
> On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com> wrote:
>
> Hi Simon,
>
>
>
> Thanks for the advice. The current RTK was compiled with FFTW to use the
> phase extraction feature from Amsterdam shroud.
>
>
>
> Regarding your suggestions,
>
>
>
> 1)      rtkramp w/ or w/o CUDA:
>
> (command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda
> --output Ramp_wCUDA.mha? )
>
>
>
> Then, I have encountered following error.
>
> ?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that
> input requested and buffered regions are equal.?
>
>
>
>
>
> Without CUDA, it was successfully done.
>
>
>
> 2)      I?ve re-compiled *ITK w/o FFTW* and built RTK again. r*tkfdk
> worked fine.*
>
> -          I?ve also repeated ?rtkramp+CUDA? with this rtk version and
> the error was same as above.
>
>
>
> In conclusion, my *FFTW seems to affect CUDA-based fdk reconstruction
> only*.
>
> But I do need FFTW for the phase extraction. What should I do?
>
>
>
> Thanks.
>
>
>
> Yang
>
>
>
>
>
> -----Original Message-----
> From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon
> Rit
> Sent: Wednesday, November 11, 2015 4:16 PM
> To: Yang K Park <theday79 at gmail.com>
> Cc: rtk-users at openrtk.org
> Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
> update
>
>
>
> Hi,
>
> I didn't manage to reproduce the two problems on linux with the same ITK
> version.
>
> For point 1, did you copy itkMacro.h by hand? Because I don't see how
> replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the
> same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW?
> It looks like a ramp filter issue. Can you try rtkramp --path projPath
> --regexp .*.his, with and without --hardware cuda? Maybe you can provide
> your geometry file in case it's a specific geometric issue.
>
> Simon
>
>
>
> On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
>
> > Hi all,
>
> >
>
> >
>
> >
>
> > I?ve updated rtk with the up-to-date revision and have encountered a
>
> > couple of problems.
>
> >
>
> >
>
> >
>
> > 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
>
> > rtkCudaUtilities.hcu. It was solved by a minor fetching:
>
> >
>
> > #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>
> >
>
> >
>
> >
>
> > 2.       Output of rtkfdk with CUDA was not the same as before. It was
> very
>
> > blurry as seen in the attached image.
>
> >
>
> > a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > I?m using VS2013 with win7, itk4.8.1.
>
> >
>
> >
>
> >
>
> > The command line I used was :
>
> >
>
> > rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his
>
> > --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware
>
> > cuda --pad 1 --hann 5 --hannY 5
>
> >
>
> >
>
> >
>
> > Does anyone have any idea about this?
>
> >
>
> >
>
> >
>
> > Thanks.
>
> >
>
> >
>
> >
>
> > Yang
>
> >
>
> >
>
> >
>
> >
>
> > _______________________________________________
>
> > 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/20151116/38acfca5/attachment-0007.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151116/38acfca5/attachment-0007.png>

From theday79 at gmail.com  Mon Nov 16 10:47:43 2015
From: theday79 at gmail.com (Yang-Kyun Park)
Date: Mon, 16 Nov 2015 10:47:43 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
 <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
 <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>
Message-ID: <CAJM7=xjBjx=FzLazWJWqJbV5d45zGi2U71NKejm9HxKhJ0-xLQ@mail.gmail.com>

Hi Simon,

For better understanding, I'm attaching the problematic case including
projection files, geometry file(xml) and reconstructed images.(please find
the GDrive links. The file size is ~800 MB)
This is phantom data and there is no patient information in it.

Regarding the fftw library, I'm using [fftw-3.3.4-dll64].

By the way, I found another clue. When I've tried it with a head phantom
image (full-fan, ~ 190 projections), there was no problem. Is there any
possibility that DDF and parker short filter play some roles on this issue?

Feel free to let me know if further data is needed.

Thanks!

Yang

?
 FFTW_issue.zip
<https://drive.google.com/file/d/0BxuP3mON9V-qbVdQd0luc1lIb2M/view?usp=drive_web>
?

On Mon, Nov 16, 2015 at 10:07 AM, Simon Rit <simon.rit at creatis.insa-lyon.fr>
wrote:

> Hi,
> Thanks. It's really weird... When you run the tests with FFTW (compiling
> the "test" target), do they fail?
> Can you provide your geometry file? It might be specific to this geometry.
> Thanks again for looking into this issue, we'll find what's the problem.
> Simon
>
> On Mon, Nov 16, 2015 at 3:54 PM, Yang K Park <theday79 at gmail.com> wrote:
>
>> Hi Simon,
>>
>>
>>
>> Sorry for the late response.
>>
>>
>>
>> As you suggested, I?ve tried rtkramp+CUDA with only one projection and it
>> was successfully done for both w/ FFTW and w/o FFTW.
>>
>> (Two results were exactly same.)
>>
>>
>>
>> Regarding  the CUDA version, I?m using v6.5.
>>
>>
>>
>> Thanks a lot for the help!
>>
>>
>>
>> Yang
>>
>>
>>
>>
>>
>> *From:* simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of *Simon
>> Rit
>> *Sent:* Thursday, November 12, 2015 5:59 PM
>>
>> *To:* Yang K Park <theday79 at gmail.com>
>> *Cc:* rtk-users at openrtk.org
>> *Subject:* Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
>> update
>>
>>
>>
>> Hi,
>>
>> Ok. Can you try rtkramp with only one projection? Then you shouldn't
>> encounter this regions issue (that should be solved one day but that's a
>> different story).
>>
>> Can you also indicate which version of CUDA you're using?
>>
>> FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft
>> for the FFT of the projections. So if they are not in the same format,
>> you're in trouble and that might be the issue here... The weird part is
>> that I didn't reproduce this problem on linux (with and without FFTW) but
>> it might be a CUDA version difference. I'll give it another try tomorrow
>> when you provide the CUDA version.
>>
>> Thanks again for reporting the issue,
>> Simon
>>
>>
>>
>> On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com> wrote:
>>
>> Hi Simon,
>>
>>
>>
>> Thanks for the advice. The current RTK was compiled with FFTW to use the
>> phase extraction feature from Amsterdam shroud.
>>
>>
>>
>> Regarding your suggestions,
>>
>>
>>
>> 1)      rtkramp w/ or w/o CUDA:
>>
>> (command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda
>> --output Ramp_wCUDA.mha? )
>>
>>
>>
>> Then, I have encountered following error.
>>
>> ?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that
>> input requested and buffered regions are equal.?
>>
>>
>>
>>
>>
>> Without CUDA, it was successfully done.
>>
>>
>>
>> 2)      I?ve re-compiled *ITK w/o FFTW* and built RTK again. r*tkfdk
>> worked fine.*
>>
>> -          I?ve also repeated ?rtkramp+CUDA? with this rtk version and
>> the error was same as above.
>>
>>
>>
>> In conclusion, my *FFTW seems to affect CUDA-based fdk reconstruction
>> only*.
>>
>> But I do need FFTW for the phase extraction. What should I do?
>>
>>
>>
>> Thanks.
>>
>>
>>
>> Yang
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of
>> Simon Rit
>> Sent: Wednesday, November 11, 2015 4:16 PM
>> To: Yang K Park <theday79 at gmail.com>
>> Cc: rtk-users at openrtk.org
>> Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
>> update
>>
>>
>>
>> Hi,
>>
>> I didn't manage to reproduce the two problems on linux with the same ITK
>> version.
>>
>> For point 1, did you copy itkMacro.h by hand? Because I don't see how
>> replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the
>> same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW?
>> It looks like a ramp filter issue. Can you try rtkramp --path projPath
>> --regexp .*.his, with and without --hardware cuda? Maybe you can provide
>> your geometry file in case it's a specific geometric issue.
>>
>> Simon
>>
>>
>>
>> On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
>>
>> > Hi all,
>>
>> >
>>
>> >
>>
>> >
>>
>> > I?ve updated rtk with the up-to-date revision and have encountered a
>>
>> > couple of problems.
>>
>> >
>>
>> >
>>
>> >
>>
>> > 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
>>
>> > rtkCudaUtilities.hcu. It was solved by a minor fetching:
>>
>> >
>>
>> > #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>>
>> >
>>
>> >
>>
>> >
>>
>> > 2.       Output of rtkfdk with CUDA was not the same as before. It was
>> very
>>
>> > blurry as seen in the attached image.
>>
>> >
>>
>> > a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>
>> > I?m using VS2013 with win7, itk4.8.1.
>>
>> >
>>
>> >
>>
>> >
>>
>> > The command line I used was :
>>
>> >
>>
>> > rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his
>>
>> > --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware
>>
>> > cuda --pad 1 --hann 5 --hannY 5
>>
>> >
>>
>> >
>>
>> >
>>
>> > Does anyone have any idea about this?
>>
>> >
>>
>> >
>>
>> >
>>
>> > Thanks.
>>
>> >
>>
>> >
>>
>> >
>>
>> > Yang
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>
>> > _______________________________________________
>>
>> > 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/20151116/90d2c5a0/attachment-0007.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151116/90d2c5a0/attachment-0007.png>

From simon.rit at creatis.insa-lyon.fr  Fri Nov 20 11:28:22 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Fri, 20 Nov 2015 17:28:22 +0100
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAJM7=xjBjx=FzLazWJWqJbV5d45zGi2U71NKejm9HxKhJ0-xLQ@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
 <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
 <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>
 <CAJM7=xjBjx=FzLazWJWqJbV5d45zGi2U71NKejm9HxKhJ0-xLQ@mail.gmail.com>
Message-ID: <CAF0oig027_u_9gb8bnwT1w9jr3epZ0hkd9Mt73qK5heUq_kCkg@mail.gmail.com>

Hi Yang,
Thanks a lot for sharing the data. I have good news. I could reproduce the
bug and I have solutions. First, about your dataset: it's a huge dataset
and the hannY requires zero padding in both x and y. Because of this, cufft
has to take the 2D FFT of projection subsets that are 4095x2048x16. Quite
big!
When I ran it on my cuda 7.0, I immediately got:

itk::ExceptionObject (0x8b9cb30)
Location: "void CUDA_fft_convolution(const int3&, const int2&, float*,
cufftComplex*)"
File: /home/srit/src/rtk/rtk/code/rtkCudaFFTConvolutionImageFilter.cu
Line: 97
Description: itk::ERROR: CUFFT ERROR #2

i.e., a GPU alloc issue, even if I have the largest possible memory on a
nvidia desktop computer. Then, I ran it with cuda 6.5 and I got no error
message but a result similar to yours.
Conclusions:
- if you add the option --subsetsize 1 to your rtkfdk command line, that
should reconstruct correctly
- if you upgrade cuda, you should get an understandable error message,
- I don't think I'm going to look for a solution because the pb is probably
in cufft but if someone is willing to, be my guest!
Simon

On Mon, Nov 16, 2015 at 4:47 PM, Yang-Kyun Park <theday79 at gmail.com> wrote:

> Hi Simon,
>
> For better understanding, I'm attaching the problematic case including
> projection files, geometry file(xml) and reconstructed images.(please find
> the GDrive links. The file size is ~800 MB)
> This is phantom data and there is no patient information in it.
>
> Regarding the fftw library, I'm using [fftw-3.3.4-dll64].
>
> By the way, I found another clue. When I've tried it with a head phantom
> image (full-fan, ~ 190 projections), there was no problem. Is there any
> possibility that DDF and parker short filter play some roles on this issue?
>
> Feel free to let me know if further data is needed.
>
> Thanks!
>
> Yang
>
> ?
>  FFTW_issue.zip
> <https://drive.google.com/file/d/0BxuP3mON9V-qbVdQd0luc1lIb2M/view?usp=drive_web>
> ?
>
> On Mon, Nov 16, 2015 at 10:07 AM, Simon Rit <
> simon.rit at creatis.insa-lyon.fr> wrote:
>
>> Hi,
>> Thanks. It's really weird... When you run the tests with FFTW (compiling
>> the "test" target), do they fail?
>> Can you provide your geometry file? It might be specific to this geometry.
>> Thanks again for looking into this issue, we'll find what's the problem.
>> Simon
>>
>> On Mon, Nov 16, 2015 at 3:54 PM, Yang K Park <theday79 at gmail.com> wrote:
>>
>>> Hi Simon,
>>>
>>>
>>>
>>> Sorry for the late response.
>>>
>>>
>>>
>>> As you suggested, I?ve tried rtkramp+CUDA with only one projection and
>>> it was successfully done for both w/ FFTW and w/o FFTW.
>>>
>>> (Two results were exactly same.)
>>>
>>>
>>>
>>> Regarding  the CUDA version, I?m using v6.5.
>>>
>>>
>>>
>>> Thanks a lot for the help!
>>>
>>>
>>>
>>> Yang
>>>
>>>
>>>
>>>
>>>
>>> *From:* simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of *Simon
>>> Rit
>>> *Sent:* Thursday, November 12, 2015 5:59 PM
>>>
>>> *To:* Yang K Park <theday79 at gmail.com>
>>> *Cc:* rtk-users at openrtk.org
>>> *Subject:* Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
>>> update
>>>
>>>
>>>
>>> Hi,
>>>
>>> Ok. Can you try rtkramp with only one projection? Then you shouldn't
>>> encounter this regions issue (that should be solved one day but that's a
>>> different story).
>>>
>>> Can you also indicate which version of CUDA you're using?
>>>
>>> FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft
>>> for the FFT of the projections. So if they are not in the same format,
>>> you're in trouble and that might be the issue here... The weird part is
>>> that I didn't reproduce this problem on linux (with and without FFTW) but
>>> it might be a CUDA version difference. I'll give it another try tomorrow
>>> when you provide the CUDA version.
>>>
>>> Thanks again for reporting the issue,
>>> Simon
>>>
>>>
>>>
>>> On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com>
>>> wrote:
>>>
>>> Hi Simon,
>>>
>>>
>>>
>>> Thanks for the advice. The current RTK was compiled with FFTW to use the
>>> phase extraction feature from Amsterdam shroud.
>>>
>>>
>>>
>>> Regarding your suggestions,
>>>
>>>
>>>
>>> 1)      rtkramp w/ or w/o CUDA:
>>>
>>> (command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda
>>> --output Ramp_wCUDA.mha? )
>>>
>>>
>>>
>>> Then, I have encountered following error.
>>>
>>> ?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that
>>> input requested and buffered regions are equal.?
>>>
>>>
>>>
>>>
>>>
>>> Without CUDA, it was successfully done.
>>>
>>>
>>>
>>> 2)      I?ve re-compiled *ITK w/o FFTW* and built RTK again. r*tkfdk
>>> worked fine.*
>>>
>>> -          I?ve also repeated ?rtkramp+CUDA? with this rtk version and
>>> the error was same as above.
>>>
>>>
>>>
>>> In conclusion, my *FFTW seems to affect CUDA-based fdk reconstruction
>>> only*.
>>>
>>> But I do need FFTW for the phase extraction. What should I do?
>>>
>>>
>>>
>>> Thanks.
>>>
>>>
>>>
>>> Yang
>>>
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of
>>> Simon Rit
>>> Sent: Wednesday, November 11, 2015 4:16 PM
>>> To: Yang K Park <theday79 at gmail.com>
>>> Cc: rtk-users at openrtk.org
>>> Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
>>> update
>>>
>>>
>>>
>>> Hi,
>>>
>>> I didn't manage to reproduce the two problems on linux with the same ITK
>>> version.
>>>
>>> For point 1, did you copy itkMacro.h by hand? Because I don't see how
>>> replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the
>>> same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW?
>>> It looks like a ramp filter issue. Can you try rtkramp --path projPath
>>> --regexp .*.his, with and without --hardware cuda? Maybe you can provide
>>> your geometry file in case it's a specific geometric issue.
>>>
>>> Simon
>>>
>>>
>>>
>>> On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
>>>
>>> > Hi all,
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > I?ve updated rtk with the up-to-date revision and have encountered a
>>>
>>> > couple of problems.
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
>>>
>>> > rtkCudaUtilities.hcu. It was solved by a minor fetching:
>>>
>>> >
>>>
>>> > #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > 2.       Output of rtkfdk with CUDA was not the same as before. It was
>>> very
>>>
>>> > blurry as seen in the attached image.
>>>
>>> >
>>>
>>> > a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > I?m using VS2013 with win7, itk4.8.1.
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > The command line I used was :
>>>
>>> >
>>>
>>> > rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his
>>>
>>> > --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware
>>>
>>> > cuda --pad 1 --hann 5 --hannY 5
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > Does anyone have any idea about this?
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > Thanks.
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > Yang
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > _______________________________________________
>>>
>>> > 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/20151120/4e6c0e1e/attachment-0007.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151120/4e6c0e1e/attachment-0007.png>

From theday79 at gmail.com  Fri Nov 20 12:36:51 2015
From: theday79 at gmail.com (Yang K Park)
Date: Fri, 20 Nov 2015 12:36:51 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAF0oig027_u_9gb8bnwT1w9jr3epZ0hkd9Mt73qK5heUq_kCkg@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
 <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
 <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>
 <CAJM7=xjBjx=FzLazWJWqJbV5d45zGi2U71NKejm9HxKhJ0-xLQ@mail.gmail.com>
 <CAF0oig027_u_9gb8bnwT1w9jr3epZ0hkd9Mt73qK5heUq_kCkg@mail.gmail.com>
Message-ID: <000901d123ba$0ae3de50$20ab9af0$@gmail.com>

Hi Simon,

 

That sounds great! Thanks a lot for your hard work.

As you said, now I can reconstruct it successfully with --subsetsize option.

 

I think the only concern left is the elongated reconstruction time.

I?ve measured it for the same phantom image with different ?subsetsize? values as well as w/o FFTW compiling.

I just report it for your information.

 

1)      w/o FFTW  : 21.4 s

2)      w/ FFTW & --subsetsize 1: 89 s

3)      w/ FFTW & --subsetsize 2: 77 s

4)      w/ FFTW & --subsetsize 4: 65 s

5)      w/ FFTW & --subsetsize 6: 51 s

6)      w/ FFTW & --subsetsize 7: (Error-graphic card seemed to be freezed)

7)      w/ FFTW & --subsetsize 8: (Error-?itk::ERROR: CUFFT ERROR #2 in rtkCudaFFTConvolutionImageFilter.cu?)

 

Of course, the difference was coming from the Ramp filter.

Therefore, I?m going to use [--subsetsize 6] for my system and will update CUDA version soon!

 

Thanks.

 

Yang

 

 

From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit
Sent: Friday, November 20, 2015 11:28 AM
To: Yang-Kyun Park <theday79 at gmail.com>
Cc: rtk-users at openrtk.org
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi Yang,
Thanks a lot for sharing the data. I have good news. I could reproduce the bug and I have solutions. First, about your dataset: it's a huge dataset and the hannY requires zero padding in both x and y. Because of this, cufft has to take the 2D FFT of projection subsets that are 4095x2048x16. Quite big!

When I ran it on my cuda 7.0, I immediately got:

itk::ExceptionObject (0x8b9cb30)
Location: "void CUDA_fft_convolution(const int3&, const int2&, float*, cufftComplex*)" 
File: /home/srit/src/rtk/rtk/code/rtkCudaFFTConvolutionImageFilter.cu
Line: 97
Description: itk::ERROR: CUFFT ERROR #2

i.e., a GPU alloc issue, even if I have the largest possible memory on a nvidia desktop computer. Then, I ran it with cuda 6.5 and I got no error message but a result similar to yours.

Conclusions:

- if you add the option --subsetsize 1 to your rtkfdk command line, that should reconstruct correctly

- if you upgrade cuda, you should get an understandable error message,

- I don't think I'm going to look for a solution because the pb is probably in cufft but if someone is willing to, be my guest!

Simon

 

On Mon, Nov 16, 2015 at 4:47 PM, Yang-Kyun Park <theday79 at gmail.com <mailto:theday79 at gmail.com> > wrote:

Hi Simon,

 

For better understanding, I'm attaching the problematic case including projection files, geometry file(xml) and reconstructed images.(please find the GDrive links. The file size is ~800 MB)

This is phantom data and there is no patient information in it.

 

Regarding the fftw library, I'm using [fftw-3.3.4-dll64].

 

By the way, I found another clue. When I've tried it with a head phantom image (full-fan, ~ 190 projections), there was no problem. Is there any possibility that DDF and parker short filter play some roles on this issue?

 

Feel free to let me know if further data is needed.

 

Thanks!

 

Yang

 

?

 <https://drive.google.com/file/d/0BxuP3mON9V-qbVdQd0luc1lIb2M/view?usp=drive_web>  FFTW_issue.zip

?

 

On Mon, Nov 16, 2015 at 10:07 AM, Simon Rit <simon.rit at creatis.insa-lyon.fr <mailto:simon.rit at creatis.insa-lyon.fr> > wrote:

Hi,

Thanks. It's really weird... When you run the tests with FFTW (compiling the "test" target), do they fail?
Can you provide your geometry file? It might be specific to this geometry.

Thanks again for looking into this issue, we'll find what's the problem.

Simon

 

On Mon, Nov 16, 2015 at 3:54 PM, Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> > wrote:

Hi Simon,

 

Sorry for the late response.

 

As you suggested, I?ve tried rtkramp+CUDA with only one projection and it was successfully done for both w/ FFTW and w/o FFTW.

(Two results were exactly same.)

 

Regarding  the CUDA version, I?m using v6.5.

 

Thanks a lot for the help!

 

Yang

 

 

From: simon.rit at gmail.com <mailto:simon.rit at gmail.com>  [mailto:simon.rit at gmail.com <mailto:simon.rit at gmail.com> ] On Behalf Of Simon Rit
Sent: Thursday, November 12, 2015 5:59 PM


To: Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> >
Cc: rtk-users at openrtk.org <mailto:rtk-users at openrtk.org> 
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

Ok. Can you try rtkramp with only one projection? Then you shouldn't encounter this regions issue (that should be solved one day but that's a different story). 

Can you also indicate which version of CUDA you're using?

FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft for the FFT of the projections. So if they are not in the same format, you're in trouble and that might be the issue here... The weird part is that I didn't reproduce this problem on linux (with and without FFTW) but it might be a CUDA version difference. I'll give it another try tomorrow when you provide the CUDA version.

Thanks again for reporting the issue,
Simon

 

On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> > wrote:

Hi Simon,

 

Thanks for the advice. The current RTK was compiled with FFTW to use the phase extraction feature from Amsterdam shroud.

 

Regarding your suggestions,

 

1)      rtkramp w/ or w/o CUDA:

(command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda --output Ramp_wCUDA.mha? )

 

Then, I have encountered following error.

?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that input requested and buffered regions are equal.?

 



 

Without CUDA, it was successfully done.

 

2)      I?ve re-compiled ITK w/o FFTW and built RTK again. rtkfdk worked fine.

-          I?ve also repeated ?rtkramp+CUDA? with this rtk version and the error was same as above.

 

In conclusion, my FFTW seems to affect CUDA-based fdk reconstruction only.

But I do need FFTW for the phase extraction. What should I do?

 

Thanks.

 

Yang

 

 

-----Original Message-----
From: simon.rit at gmail.com <mailto:simon.rit at gmail.com>  [mailto:simon.rit at gmail.com <mailto:simon.rit at gmail.com> ] On Behalf Of Simon Rit
Sent: Wednesday, November 11, 2015 4:16 PM
To: Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> >
Cc: rtk-users at openrtk.org <mailto:rtk-users at openrtk.org> 
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

I didn't manage to reproduce the two problems on linux with the same ITK version.

For point 1, did you copy itkMacro.h by hand? Because I don't see how replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW? It looks like a ramp filter issue. Can you try rtkramp --path projPath --regexp .*.his, with and without --hardware cuda? Maybe you can provide your geometry file in case it's a specific geometric issue.

Simon

 

On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park < <mailto:theday79 at gmail.com> theday79 at gmail.com> wrote:

> Hi all,

> 

> 

> 

> I?ve updated rtk with the up-to-date revision and have encountered a 

> couple of problems.

> 

> 

> 

> 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled

> rtkCudaUtilities.hcu. It was solved by a minor fetching:

> 

> #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu

> 

> 

> 

> 2.       Output of rtkfdk with CUDA was not the same as before. It was very

> blurry as seen in the attached image.

> 

> a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.

> 

> 

> 

> 

> 

> I?m using VS2013 with win7, itk4.8.1.

> 

> 

> 

> The command line I used was :

> 

> rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his 

> --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware 

> cuda --pad 1 --hann 5 --hannY 5

> 

> 

> 

> Does anyone have any idea about this?

> 

> 

> 

> Thanks.

> 

> 

> 

> Yang

> 

> 

> 

> 

> _______________________________________________

> Rtk-users mailing list

>  <mailto: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/20151120/0d98ace1/attachment-0007.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151120/0d98ace1/attachment-0007.png>

From simon.rit at creatis.insa-lyon.fr  Wed Nov 25 02:36:44 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Wed, 25 Nov 2015 08:36:44 +0100
Subject: [Rtk-users] Compiling Problem
In-Reply-To: <040e01d125c7$83648e60$8a2dab20$@126.com>
References: <040e01d125c7$83648e60$8a2dab20$@126.com>
Message-ID: <5655650C.1040500@creatis.insa-lyon.fr>

Hi,
Please use the mailing list. I don't know where does the linking problem 
come from and it seems to work on our side:
http://my.cdash.org/index.php?project=RTK
Have you tried disabling CUDA?
Simon

On 23/11/2015 09:18, Freyman li wrote:
>
> Dear Simon,
>
> Recently I configured the RTK tool and suffer some problems. After set 
> up the itk tool and cuda, I compiled the rtk application but 
> encountered two errors attached to the email(jpg format)
>
> CUDA and ITK environment are tested successfully. My compile tool is 
> Visual studio 2012(64bit) and CUDA version is v6.5.
>
> Can you tell me how to deal with it and I am looking forward to hear 
> you again.
>
> Thank you!
>
> Best Regards
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151125/285f7f3c/attachment-0007.html>

From theday79 at gmail.com  Wed Nov 25 12:38:52 2015
From: theday79 at gmail.com (Yang K Park)
Date: Wed, 25 Nov 2015 12:38:52 -0500
Subject: [Rtk-users] Compiling Problem
In-Reply-To: <5655650C.1040500@creatis.insa-lyon.fr>
References: <040e01d125c7$83648e60$8a2dab20$@126.com>
 <5655650C.1040500@creatis.insa-lyon.fr>
Message-ID: <003d01d127a8$27a52b60$76ef8220$@gmail.com>

Hi Freyman,

 

I think your setting is much similar to mine, since I have compiled RTK with
VS2013 and CUDA v6.5 several times. Can you post those error messages again
so that I can see?

Yang

 

 

From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of
Simon Rit
Sent: Wednesday, November 25, 2015 2:37 AM
To: Freyman li <lihanwei_1500 at 126.com>
Cc: rtk-users at openrtk.org
Subject: Re: [Rtk-users] Compiling Problem

 

Hi,
Please use the mailing list. I don't know where does the linking problem
come from and it seems to work on our side:
http://my.cdash.org/index.php?project=RTK
Have you tried disabling CUDA?
Simon

On 23/11/2015 09:18, Freyman li wrote:

Dear Simon,

 

Recently I configured the RTK tool and suffer some problems. After set up
the itk tool and cuda, I compiled the rtk application but encountered two
errors attached to the email(jpg format)

CUDA and ITK environment are tested successfully. My compile tool is Visual
studio 2012(64bit) and CUDA version is v6.5.

Can you tell me how to deal with it and I am looking forward to hear you
again.

Thank you!

 

Best Regards

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151125/984feb50/attachment-0007.html>

From bioniloofar at gmail.com  Mon Nov 30 06:06:41 2015
From: bioniloofar at gmail.com (niloufar teyfouri)
Date: Mon, 30 Nov 2015 14:36:41 +0330
Subject: [Rtk-users] ElectaReconstruction
Message-ID: <CALChM12F4PuiLvgENg3Yyn7E+uZ7iPJ+GiY04z7VQ-90AS83EA@mail.gmail.com>

I ran the application of Electa Reconstruction implemented by you with
RTK. But after debugging I was encountered with the message of
"--output' ('-o') option required". Could you please help me for running
this example and the other ones?
I don't know any thing about the texts in the gray boxes mentioned at
each link related to examples of RTK.
For example in the link of
http://wiki.openrtk.org/index.php/RTK/Examples/ElektaReconstruction
how I should use gengetopt for the instructions below?


2. Run the application to convert Elekta's geometry into RTKs (DICOM_UID
is contained in the subfolder name of the his files):

  rtkelektasynergygeometry \
    --image_db IMAGE.DBF \
    --frame_db FRAME.DBF \
    --dicom_uid 1.3.46.423632.135428.1351013645.166 \
    -o elektaGeometry

I would be appreciate if one could answer my question.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151130/b11ad4e2/attachment-0007.html>

From cyril.mory at uclouvain.be  Mon Nov 30 09:30:48 2015
From: cyril.mory at uclouvain.be (Cyril Mory)
Date: Mon, 30 Nov 2015 15:30:48 +0100
Subject: [Rtk-users] ElectaReconstruction
In-Reply-To: <CALChM12F4PuiLvgENg3Yyn7E+uZ7iPJ+GiY04z7VQ-90AS83EA@mail.gmail.com>
References: <CALChM12F4PuiLvgENg3Yyn7E+uZ7iPJ+GiY04z7VQ-90AS83EA@mail.gmail.com>
Message-ID: <565C5D98.1000309@uclouvain.be>

Hi, and welcome to RTK,

Gengetopt is the piece of software that parses the command line 
arguments in all RTK applications. You do not have to "use" it. You just 
need to give correct arguments on the command line.

The message "--output' ('-o') option required" means what it says : you 
need to provide the name of the file in which you want to store the 
geometry information generated by the application 
rtkelektasynergygeometry. If you just copy-pasted the command you found 
on the wiki, then something went wrong during the copy-paste. Try to run 
the following :

rtkelektasynergygeometry --image_db IMAGE.DBF --frame_db FRAME.DBF 
--dicom_uid 1.3.46.423632.135428.1351013645.166 -o elektaGeometry

I just removed the '\' and the useless spaces. You can do the same for 
all other command line examples and it should work.

Let us know if you keep encountering trouble.
Cyril


Le 30/11/2015 12:06, niloufar teyfouri a ?crit :
>
> I ran the application of Electa Reconstruction implemented by you with
> RTK. But after debugging I was encountered with the message of
> "--output' ('-o') option required". Could you please help me for running
> this example and the other ones?
> I don't know any thing about the texts in the gray boxes mentioned at
> each link related to examples of RTK.
> For example in the link of
> http://wiki.openrtk.org/index.php/RTK/Examples/ElektaReconstruction
> how I should use gengetopt for the instructions below?
>
>
> 2. Run the application to convert Elekta's geometry into RTKs (DICOM_UID
> is contained in the subfolder name of the his files):
>
> rtkelektasynergygeometry \
> --image_db IMAGE.DBF \
> --frame_db FRAME.DBF \
> --dicom_uid 1.3.46.423632.135428.1351013645.166 \
>     -o elektaGeometry
>
> I would be appreciate if one could answer my question.
>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151130/66741755/attachment-0007.html>

From j.mason at ed.ac.uk  Mon Nov 30 11:29:27 2015
From: j.mason at ed.ac.uk (Jonathan Mason)
Date: Mon, 30 Nov 2015 16:29:27 +0000
Subject: [Rtk-users] Preprocessing
Message-ID: <565C7967.4000401@ed.ac.uk>

Good afternoon RTK users,

I have access to "raw data" from a Varian OBI scanner, and have
experimented with RTK for performing its reconstruction. However, it is
not really "raw" in the sense that the coefficients are proportional to
the photon flux recorded at a given sensor, but is instead proportional
to the Hounsfield attenuation along that path. With this data, it means
that one can reconstruct using FDK and other iterative techniques, which
assume a linear model, but the connection to the underlying physics is
abstract.

The problem I then have when trying to develop reconstruction
techniques, is that I do not know whether I am really correcting for
physical distortions or just correcting for Varian's preprocessing,
which has been finely tuned for its own FDK method.

My question is whether anybody has dug into the steps that manufacturers
such as Varian or Elekta perform to arrive at these projection images?
And if they think that if reverse engineered, could provide a richer set
of information to facilitate advanced strategies.

Best wishes,

Jonathan Mason

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.



From simon.rit at creatis.insa-lyon.fr  Mon Nov 30 12:44:03 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Mon, 30 Nov 2015 18:44:03 +0100
Subject: [Rtk-users] ElectaReconstruction
In-Reply-To: <565C5D98.1000309@uclouvain.be>
References: <CALChM12F4PuiLvgENg3Yyn7E+uZ7iPJ+GiY04z7VQ-90AS83EA@mail.gmail.com>
 <565C5D98.1000309@uclouvain.be>
Message-ID: <CAF0oig2Zg96AZaRn9w9=F+LnLnyteTn5zS1rLguQ8WXiYhnnYg@mail.gmail.com>

Hi,
I think Cyril is right, it's not possible to use backslashes to put a
command line on several line with Windows command line. Can you confirm
this? If you confirm, we will correct the wiki.
Thanks,
Simon

On Mon, Nov 30, 2015 at 3:30 PM, Cyril Mory <cyril.mory at uclouvain.be> wrote:

> Hi, and welcome to RTK,
>
> Gengetopt is the piece of software that parses the command line arguments
> in all RTK applications. You do not have to "use" it. You just need to give
> correct arguments on the command line.
>
> The message "--output' ('-o') option required" means what it says : you
> need to provide the name of the file in which you want to store the
> geometry information generated by the application rtkelektasynergygeometry.
> If you just copy-pasted the command you found on the wiki, then something
> went wrong during the copy-paste. Try to run the following :
>
> rtkelektasynergygeometry --image_db IMAGE.DBF --frame_db FRAME.DBF
> --dicom_uid 1.3.46.423632.135428.1351013645.166 -o elektaGeometry
>
> I just removed the '\' and the useless spaces. You can do the same for all
> other command line examples and it should work.
>
> Let us know if you keep encountering trouble.
> Cyril
>
>
>
> Le 30/11/2015 12:06, niloufar teyfouri a ?crit :
>
>
> I ran the application of Electa Reconstruction implemented by you with
> RTK. But after debugging I was encountered with the message of
> "--output' ('-o') option required". Could you please help me for running
> this example and the other ones?
> I don't know any thing about the texts in the gray boxes mentioned at
> each link related to examples of RTK.
> For example in the link of
> http://wiki.openrtk.org/index.php/RTK/Examples/ElektaReconstruction
> how I should use gengetopt for the instructions below?
>
>
> 2. Run the application to convert Elekta's geometry into RTKs (DICOM_UID
> is contained in the subfolder name of the his files):
>
>   rtkelektasynergygeometry \
>     --image_db IMAGE.DBF \
>     --frame_db FRAME.DBF \
>     --dicom_uid 1.3.46.423632.135428.1351013645.166 \
>     -o elektaGeometry
>
> I would be appreciate if one could answer my question.
>
>
> _______________________________________________
> Rtk-users mailing listRtk-users at public.kitware.comhttp://public.kitware.com/mailman/listinfo/rtk-users
>
>
>
>
> ------------------------------
> [image: Avast logo] <https://www.avast.com/antivirus>
>
> L'absence de virus dans ce courrier ?lectronique a ?t? v?rifi?e par le
> logiciel antivirus Avast.
> www.avast.com <https://www.avast.com/antivirus>
>
>
> _______________________________________________
> 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/20151130/6d6dd6aa/attachment-0007.html>

From wuchao04 at gmail.com  Mon Nov 30 13:50:06 2015
From: wuchao04 at gmail.com (Chao Wu)
Date: Mon, 30 Nov 2015 19:50:06 +0100
Subject: [Rtk-users] Preprocessing
In-Reply-To: <565C7967.4000401@ed.ac.uk>
References: <565C7967.4000401@ed.ac.uk>
Message-ID: <CAH+sHrUFov5f=8h4-ePhC2xLraM3BxA9r12yfXdM3rrKPeqCBg@mail.gmail.com>

Hi Jonathan,

I do not quite understand your problem.
I think most information can be retrieved by the relationship between flux
(I) and attenuation (u):
I = I0 * exp (- integral(u * dL) )
Of course there are other effects like beam hardening and scattering
involved but this model is the basic.

Regards,
Chao

2015-11-30 17:29 GMT+01:00 Jonathan Mason <j.mason at ed.ac.uk>:

> Good afternoon RTK users,
>
> I have access to "raw data" from a Varian OBI scanner, and have
> experimented with RTK for performing its reconstruction. However, it is
> not really "raw" in the sense that the coefficients are proportional to
> the photon flux recorded at a given sensor, but is instead proportional
> to the Hounsfield attenuation along that path. With this data, it means
> that one can reconstruct using FDK and other iterative techniques, which
> assume a linear model, but the connection to the underlying physics is
> abstract.
>
> The problem I then have when trying to develop reconstruction
> techniques, is that I do not know whether I am really correcting for
> physical distortions or just correcting for Varian's preprocessing,
> which has been finely tuned for its own FDK method.
>
> My question is whether anybody has dug into the steps that manufacturers
> such as Varian or Elekta perform to arrive at these projection images?
> And if they think that if reverse engineered, could provide a richer set
> of information to facilitate advanced strategies.
>
> Best wishes,
>
> Jonathan Mason
>
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
> _______________________________________________
> 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/20151130/ccb833fe/attachment-0007.html>

From mdupont at cppm.in2p3.fr  Sun Nov  1 12:41:49 2015
From: mdupont at cppm.in2p3.fr (Mathieu Dupont)
Date: Sun, 01 Nov 2015 18:41:49 +0100
Subject: [Rtk-users] question about rtkDraw*ImageFilter
In-Reply-To: <56334CF2.8070902@cppm.in2p3.fr>
References: <5630EE01.5070900@cppm.in2p3.fr>
 <CAF0oig279ZWGJMFnJdXaPiYLPponadz_J-PVKt2z3iHiTRQ_gg@mail.gmail.com>
 <56334CF2.8070902@cppm.in2p3.fr>
Message-ID: <1539144.WPSdtJ8lhZ@marabunta>

Hello Simon, 

I started to implement what I suggested : 

https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawImageFilter.h
and 
https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawCylinderImageFilter.h

rtk::DrawCylinderImageFilter derives from rtk::DrawImageFilter and specializes 
it (by defaulting the template parameter TSpatialObject with 
DrawCylinderSpatialObject). 

By default, DrawCylinderImageFilter uses Add2 for filling output image (to be 
backward compatible (all tests pass)). I created Discard (I did not find 
equivalent in itk) functor in order to do what I wanted in my first email.  

I just implemented DrawCylinderImageFilter, the others will follow. 

What do you think about it ?

Le vendredi 30 octobre 2015, 11:56:50 Mathieu Dupont a ?crit :
> Hi,
> 
> In case of your first solution, you can not chain several
> Draw*ImageFilters. For example, if you want to create small cylinders in
> a big cylinder.
> 
> Your second solution is better.
> 
> One another solution can be a thing like itk:SpatialObject but more
> simpler. An rtk::SpatialObject which one function (isInside(point)). We
> create a rtkDrawImageFilter class and implement ThreadedGenerateData
> like this :
> 
> DrawImageFilter<InImage, OutImage, rtkSpatialObject,
> rtkFillFunctor>::ThreadedGenerateData(const OutputImageRegionType&
> outputRegionForThread,                 ThreadIdType itkNotUsed(threadId)
> {
> ...
> 
>   while( !itOut.IsAtEnd() )
>      {
>      this->GetInput()->TransformIndexToPhysicalPoint(itOut.GetIndex(),
> point);
> 
>     if(m_rtkSpatialObject.isInside(point)
>       itOut.Set(m_rtkFillFunctor(density, itIn.Get());
> ...
> }
> 
> 
> DrawConeImageFilter class can be a child of this new DrawImageFilter
> (with new methods like setAngle, SetRadius which will adjust the
> rtkConeSpatialObject)
> 
> This solution suppress duplicated code in
> Draw*ImageFilter::ThreadedGenerateData and makes easier implementation
> of another type of filling.
> 
> On 28/10/2015 20:52, Simon Rit wrote:
> > Hi Mathieu,
> > Thanks for pointing this out. I agree that it might not be the best
> > solution, yet one could argue that you could simply create a constant
> > image with 0 to do what you'd like from the current implementation. My
> > main problem is that I just tried to do what you suggest and some tests
> > then fail... which shows the obvious, it's not a backward compatible
> > change. I see two solutions:
> > - keep it as is and you use ConstantImageFilter + we remove useless add
> > filters,
> > - a more complex but maybe more elegant solution: add a third template
> > parameter for the operation that would allow the user to do what he'd
> > like in a functor. That's what's done with filters that derive from
> > itk::UnaryImageFilter
> > <http://www.itk.org/Doxygen/html/classitk_1_1UnaryFunctorImageFilter.html>
> > .
> > The default would be itk::Add2 but we could find or implement another
> > one that simply discards the pixel value.
> > What do you think?
> > Simon
> > 
> > PS: looking in the code, I just found that rtk::DrawConeImageFilter is
> > not consistent with the others, it was always setting to 0 outside...
> > that's been fixed!
> > 
> > On Wed, Oct 28, 2015 at 4:47 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr
> > 
> > <mailto:mdupont at cppm.in2p3.fr>> wrote:
> >     Hello everyone,
> >     
> >     I have a question/suggestion about the set of rtkDraw*ImageFilter.
> >     This filter are written as additive filters: for example, in
> >     rtkDrawEllipsoidImageFilter.txx, we can find
> >     
> >     for(..)
> >     
> >       itOut.Set( ellipsoid.density + itIn.Get() )
> >     
> >     instead of
> >     
> >     for(..)
> >     itOut.Set( ellipsoid.density )
> >     
> >     
> >     I think it can be more flexible the second option, because we can
> >     always associate Draw*ImageFilter and itkAddImageFilter to get an
> >     additive filter.
> >     
> >     Moreover, the  rtkDrawGeometricPhantomImageFilter class already uses
> >     itkAddImageFilter in order to have additive filters (which is
> >     redundant in current situation).
> >     
> >     What do you think ?
> >     
> >     
> >     
> >     
> >     
> >     Regards
> >     
> >     
> >     
> >     _______________________________________________
> >     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


From gnthibault at gmail.com  Mon Nov  2 08:08:42 2015
From: gnthibault at gmail.com (Notargiacomo Thibault)
Date: Mon, 2 Nov 2015 14:08:42 +0100
Subject: [Rtk-users] Problem with rtkGgoFunctions when importing series of
	images
Message-ID: <CAP+mR7Zw7WmRmEgVUTamNhS6m4S6ORvWFjRu1EANViPRJ7jtuQ@mail.gmail.com>

I recently experienced the following problem, when importing multiple tif
files inside a directory using itk::ImageSeriesReader:

[...]
code/rtkGgoFunctions.h: In instantiation of ?void
rtk::SetProjectionsReaderFromGgo(typename TProjectionsReaderType::Pointer,
const TArgsInfo&)
[...]
code/rtkGgoFunctions.h:121:61: error: no type named
?OutputImageDirectionType? in ?class
itk::ImageSeriesReader<itk::Image<short unsigned int, 3u> >?
   typename TProjectionsReaderType::OutputImageDirectionType direction;
[...]

It seems that, a new functionality added in rtkGgoFunctions.h (19/05/2015),
allowing to directly modify input images properties through command line,
like geometry (direction vector), assumes that the input image type defines
OutputImageDirectionType, but in the case of itk::ImageSeriesReader, it
does not.

Is this considered as a regression, or should the
SetProjectionsReaderFromGgo function be used with specific input image type
?

Thank you in advance for your help.

Kind regards

Thibault Notargiacomo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151102/6cad3583/attachment-0008.html>

From simon.rit at creatis.insa-lyon.fr  Mon Nov  2 08:58:24 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Mon, 2 Nov 2015 14:58:24 +0100
Subject: [Rtk-users] Problem with rtkGgoFunctions when importing series
	of images
In-Reply-To: <CAP+mR7Zw7WmRmEgVUTamNhS6m4S6ORvWFjRu1EANViPRJ7jtuQ@mail.gmail.com>
References: <CAP+mR7Zw7WmRmEgVUTamNhS6m4S6ORvWFjRu1EANViPRJ7jtuQ@mail.gmail.com>
Message-ID: <CAF0oig2bAidO4JR7pa_PUxOQm-X7JrEz8=ybGX3bskYJM9YRAQ@mail.gmail.com>

Hi Thibault,
SetProjectionsReaderFromGgo is a macro designed for the
rtk::ProjectionsReader
<http://www.openrtk.org/Doxygen/classrtk_1_1ProjectionsReader.html>, I'm
not surprised that it does not work with the itk::ImageSeriesReader. It's
not about the image type but about the filter type... We use this macro to
set many parameters specific to the rtk::ProjectionsReader
<http://www.openrtk.org/Doxygen/classrtk_1_1ProjectionsReader.html>. Since
a while, I have made have a common rtkinputprojections_section.ggo
<https://github.com/SimonRit/RTK/blob/master/applications/rtkinputprojections_section.ggo>
file for all the applications that use the rtk::ProjectionsReader.
If you don't want to use the rtk::ProjectionsReader but
itk::ImageSeriesReader (e.g., because it does a lot of automatic processing
that you don't want), you'll have to write your own code to set it up.
I hope this clarifies things.
Simon

On Mon, Nov 2, 2015 at 2:08 PM, Notargiacomo Thibault <gnthibault at gmail.com>
wrote:

> I recently experienced the following problem, when importing multiple tif
> files inside a directory using itk::ImageSeriesReader:
>
> [...]
> code/rtkGgoFunctions.h: In instantiation of ?void
> rtk::SetProjectionsReaderFromGgo(typename TProjectionsReaderType::Pointer,
> const TArgsInfo&)
> [...]
> code/rtkGgoFunctions.h:121:61: error: no type named
> ?OutputImageDirectionType? in ?class
> itk::ImageSeriesReader<itk::Image<short unsigned int, 3u> >?
>    typename TProjectionsReaderType::OutputImageDirectionType direction;
> [...]
>
> It seems that, a new functionality added in rtkGgoFunctions.h
> (19/05/2015), allowing to directly modify input images properties through
> command line, like geometry (direction vector), assumes that the input
> image type defines OutputImageDirectionType, but in the case of
> itk::ImageSeriesReader, it does not.
>
> Is this considered as a regression, or should the
> SetProjectionsReaderFromGgo function be used with specific input image type
> ?
>
> Thank you in advance for your help.
>
> Kind regards
>
> Thibault Notargiacomo
>
> _______________________________________________
> 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/20151102/ee7e2c17/attachment-0008.html>

From simon.rit at creatis.insa-lyon.fr  Wed Nov  4 16:38:18 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Wed, 4 Nov 2015 22:38:18 +0100
Subject: [Rtk-users] question about rtkDraw*ImageFilter
In-Reply-To: <1539144.WPSdtJ8lhZ@marabunta>
References: <5630EE01.5070900@cppm.in2p3.fr>
 <CAF0oig279ZWGJMFnJdXaPiYLPponadz_J-PVKt2z3iHiTRQ_gg@mail.gmail.com>
 <56334CF2.8070902@cppm.in2p3.fr> <1539144.WPSdtJ8lhZ@marabunta>
Message-ID: <CAF0oig3jBsfoadM_k6SYvOMwikOCNFmH19J7m1YJZx-RU0y+5g@mail.gmail.com>

Hi Mathieu,
Sorry, I'm very busy these days. I had a first quick look. Why not, it
looks a bit complicated but good. I would have a few things I would change
style wise, e.g., move DrawCylinderSpatialObject to
DrawCylinderImageFilter, create a common DrawQuadricSpatialObject that
would all have the same IsInside function, make DrawSpatialObjectpurely
virtual by not defining
IsInside etc. but those are details I can correct myself. Do you want to
finish what you started and I work from there or should I finish everything?
Simon

On Sun, Nov 1, 2015 at 6:41 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr>
wrote:

> Hello Simon,
>
> I started to implement what I suggested :
>
>
> https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawImageFilter.h
> and
>
> https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawCylinderImageFilter.h
>
> rtk::DrawCylinderImageFilter derives from rtk::DrawImageFilter and
> specializes
> it (by defaulting the template parameter TSpatialObject with
> DrawCylinderSpatialObject).
>
> By default, DrawCylinderImageFilter uses Add2 for filling output image (to
> be
> backward compatible (all tests pass)). I created Discard (I did not find
> equivalent in itk) functor in order to do what I wanted in my first email.
>
> I just implemented DrawCylinderImageFilter, the others will follow.
>
> What do you think about it ?
>
> Le vendredi 30 octobre 2015, 11:56:50 Mathieu Dupont a ?crit :
> > Hi,
> >
> > In case of your first solution, you can not chain several
> > Draw*ImageFilters. For example, if you want to create small cylinders in
> > a big cylinder.
> >
> > Your second solution is better.
> >
> > One another solution can be a thing like itk:SpatialObject but more
> > simpler. An rtk::SpatialObject which one function (isInside(point)). We
> > create a rtkDrawImageFilter class and implement ThreadedGenerateData
> > like this :
> >
> > DrawImageFilter<InImage, OutImage, rtkSpatialObject,
> > rtkFillFunctor>::ThreadedGenerateData(const OutputImageRegionType&
> > outputRegionForThread,                 ThreadIdType itkNotUsed(threadId)
> > {
> > ...
> >
> >   while( !itOut.IsAtEnd() )
> >      {
> >      this->GetInput()->TransformIndexToPhysicalPoint(itOut.GetIndex(),
> > point);
> >
> >     if(m_rtkSpatialObject.isInside(point)
> >       itOut.Set(m_rtkFillFunctor(density, itIn.Get());
> > ...
> > }
> >
> >
> > DrawConeImageFilter class can be a child of this new DrawImageFilter
> > (with new methods like setAngle, SetRadius which will adjust the
> > rtkConeSpatialObject)
> >
> > This solution suppress duplicated code in
> > Draw*ImageFilter::ThreadedGenerateData and makes easier implementation
> > of another type of filling.
> >
> > On 28/10/2015 20:52, Simon Rit wrote:
> > > Hi Mathieu,
> > > Thanks for pointing this out. I agree that it might not be the best
> > > solution, yet one could argue that you could simply create a constant
> > > image with 0 to do what you'd like from the current implementation. My
> > > main problem is that I just tried to do what you suggest and some tests
> > > then fail... which shows the obvious, it's not a backward compatible
> > > change. I see two solutions:
> > > - keep it as is and you use ConstantImageFilter + we remove useless add
> > > filters,
> > > - a more complex but maybe more elegant solution: add a third template
> > > parameter for the operation that would allow the user to do what he'd
> > > like in a functor. That's what's done with filters that derive from
> > > itk::UnaryImageFilter
> > > <
> http://www.itk.org/Doxygen/html/classitk_1_1UnaryFunctorImageFilter.html>
> > > .
> > > The default would be itk::Add2 but we could find or implement another
> > > one that simply discards the pixel value.
> > > What do you think?
> > > Simon
> > >
> > > PS: looking in the code, I just found that rtk::DrawConeImageFilter is
> > > not consistent with the others, it was always setting to 0 outside...
> > > that's been fixed!
> > >
> > > On Wed, Oct 28, 2015 at 4:47 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr
> > >
> > > <mailto:mdupont at cppm.in2p3.fr>> wrote:
> > >     Hello everyone,
> > >
> > >     I have a question/suggestion about the set of rtkDraw*ImageFilter.
> > >     This filter are written as additive filters: for example, in
> > >     rtkDrawEllipsoidImageFilter.txx, we can find
> > >
> > >     for(..)
> > >
> > >       itOut.Set( ellipsoid.density + itIn.Get() )
> > >
> > >     instead of
> > >
> > >     for(..)
> > >     itOut.Set( ellipsoid.density )
> > >
> > >
> > >     I think it can be more flexible the second option, because we can
> > >     always associate Draw*ImageFilter and itkAddImageFilter to get an
> > >     additive filter.
> > >
> > >     Moreover, the  rtkDrawGeometricPhantomImageFilter class already
> uses
> > >     itkAddImageFilter in order to have additive filters (which is
> > >     redundant in current situation).
> > >
> > >     What do you think ?
> > >
> > >
> > >
> > >
> > >
> > >     Regards
> > >
> > >
> > >
> > >     _______________________________________________
> > >     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/20151104/46314d97/attachment-0008.html>

From mdupont at cppm.in2p3.fr  Mon Nov  9 14:35:47 2015
From: mdupont at cppm.in2p3.fr (Mathieu Dupont)
Date: Mon, 09 Nov 2015 20:35:47 +0100
Subject: [Rtk-users] question about rtkDraw*ImageFilter
In-Reply-To: <CAF0oig3jBsfoadM_k6SYvOMwikOCNFmH19J7m1YJZx-RU0y+5g@mail.gmail.com>
References: <5630EE01.5070900@cppm.in2p3.fr> <1539144.WPSdtJ8lhZ@marabunta>
 <CAF0oig3jBsfoadM_k6SYvOMwikOCNFmH19J7m1YJZx-RU0y+5g@mail.gmail.com>
Message-ID: <5634494.U9CmFl2V79@marabunta>

hi, 

i will do this during this week and try to implement your remarks. 


Le mercredi 4 novembre 2015, 22:38:18 Simon Rit a ?crit :
> Hi Mathieu,
> Sorry, I'm very busy these days. I had a first quick look. Why not, it
> looks a bit complicated but good. I would have a few things I would change
> style wise, e.g., move DrawCylinderSpatialObject to
> DrawCylinderImageFilter, create a common DrawQuadricSpatialObject that
> would all have the same IsInside function, make DrawSpatialObjectpurely
> virtual by not defining
> IsInside etc. but those are details I can correct myself. Do you want to
> finish what you started and I work from there or should I finish everything?
> Simon
> 
> On Sun, Nov 1, 2015 at 6:41 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr>
> 
> wrote:
> > Hello Simon,
> > 
> > I started to implement what I suggested :
> > 
> > 
> > https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawImag
> > eFilter.h and
> > 
> > https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawCyli
> > nderImageFilter.h
> > 
> > rtk::DrawCylinderImageFilter derives from rtk::DrawImageFilter and
> > specializes
> > it (by defaulting the template parameter TSpatialObject with
> > DrawCylinderSpatialObject).
> > 
> > By default, DrawCylinderImageFilter uses Add2 for filling output image (to
> > be
> > backward compatible (all tests pass)). I created Discard (I did not find
> > equivalent in itk) functor in order to do what I wanted in my first email.
> > 
> > I just implemented DrawCylinderImageFilter, the others will follow.
> > 
> > What do you think about it ?
> > 
> > Le vendredi 30 octobre 2015, 11:56:50 Mathieu Dupont a ?crit :
> > > Hi,
> > > 
> > > In case of your first solution, you can not chain several
> > > Draw*ImageFilters. For example, if you want to create small cylinders in
> > > a big cylinder.
> > > 
> > > Your second solution is better.
> > > 
> > > One another solution can be a thing like itk:SpatialObject but more
> > > simpler. An rtk::SpatialObject which one function (isInside(point)). We
> > > create a rtkDrawImageFilter class and implement ThreadedGenerateData
> > > like this :
> > > 
> > > DrawImageFilter<InImage, OutImage, rtkSpatialObject,
> > > rtkFillFunctor>::ThreadedGenerateData(const OutputImageRegionType&
> > > outputRegionForThread,                 ThreadIdType itkNotUsed(threadId)
> > > {
> > > ...
> > > 
> > >   while( !itOut.IsAtEnd() )
> > >   
> > >      {
> > >      this->GetInput()->TransformIndexToPhysicalPoint(itOut.GetIndex(),
> > > 
> > > point);
> > > 
> > >     if(m_rtkSpatialObject.isInside(point)
> > >     
> > >       itOut.Set(m_rtkFillFunctor(density, itIn.Get());
> > > 
> > > ...
> > > }
> > > 
> > > 
> > > DrawConeImageFilter class can be a child of this new DrawImageFilter
> > > (with new methods like setAngle, SetRadius which will adjust the
> > > rtkConeSpatialObject)
> > > 
> > > This solution suppress duplicated code in
> > > Draw*ImageFilter::ThreadedGenerateData and makes easier implementation
> > > of another type of filling.
> > > 
> > > On 28/10/2015 20:52, Simon Rit wrote:
> > > > Hi Mathieu,
> > > > Thanks for pointing this out. I agree that it might not be the best
> > > > solution, yet one could argue that you could simply create a constant
> > > > image with 0 to do what you'd like from the current implementation. My
> > > > main problem is that I just tried to do what you suggest and some
> > > > tests
> > > > then fail... which shows the obvious, it's not a backward compatible
> > > > change. I see two solutions:
> > > > - keep it as is and you use ConstantImageFilter + we remove useless
> > > > add
> > > > filters,
> > > > - a more complex but maybe more elegant solution: add a third template
> > > > parameter for the operation that would allow the user to do what he'd
> > > > like in a functor. That's what's done with filters that derive from
> > > > itk::UnaryImageFilter
> > > > <
> > 
> > http://www.itk.org/Doxygen/html/classitk_1_1UnaryFunctorImageFilter.html>
> > 
> > > > .
> > > > The default would be itk::Add2 but we could find or implement another
> > > > one that simply discards the pixel value.
> > > > What do you think?
> > > > Simon
> > > > 
> > > > PS: looking in the code, I just found that rtk::DrawConeImageFilter is
> > > > not consistent with the others, it was always setting to 0 outside...
> > > > that's been fixed!
> > > > 
> > > > On Wed, Oct 28, 2015 at 4:47 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr
> > > > 
> > > > <mailto:mdupont at cppm.in2p3.fr>> wrote:
> > > >     Hello everyone,
> > > >     
> > > >     I have a question/suggestion about the set of rtkDraw*ImageFilter.
> > > >     This filter are written as additive filters: for example, in
> > > >     rtkDrawEllipsoidImageFilter.txx, we can find
> > > >     
> > > >     for(..)
> > > >     
> > > >       itOut.Set( ellipsoid.density + itIn.Get() )
> > > >     
> > > >     instead of
> > > >     
> > > >     for(..)
> > > >     itOut.Set( ellipsoid.density )
> > > >     
> > > >     
> > > >     I think it can be more flexible the second option, because we can
> > > >     always associate Draw*ImageFilter and itkAddImageFilter to get an
> > > >     additive filter.
> > > >     
> > > >     Moreover, the  rtkDrawGeometricPhantomImageFilter class already
> > 
> > uses
> > 
> > > >     itkAddImageFilter in order to have additive filters (which is
> > > >     redundant in current situation).
> > > >     
> > > >     What do you think ?
> > > >     
> > > >     
> > > >     
> > > >     
> > > >     
> > > >     Regards
> > > >     
> > > >     
> > > >     
> > > >     _______________________________________________
> > > >     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


From gnthibault at gmail.com  Tue Nov 10 07:39:46 2015
From: gnthibault at gmail.com (Notargiacomo Thibault)
Date: Tue, 10 Nov 2015 13:39:46 +0100
Subject: [Rtk-users] Understanding projection matrices management in
	rtkCudaBackProjectionImageFilter
Message-ID: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>

Hi all,

I am currently trying to use the "AddProjectionInRadians" method from the
ThreeDCircularProjectionGeometry class in RTK to import my geometry.

First things first, I would like to know if the information on this pdf are
still valid: http://www.openrtk.org/Doxygen/geometry.pdf

Because I used them to deduce the source offset and Projection offset from
my own matrix decomposition.

Notice that I don't want to use geometric informations coming from the
projection images themselves, so their geometric origin is assumed to be
(0,0,0) in my case.

In order to check if my geometry import method is correct, I print out one
of the intermediate form of the projection matrix used in the
backprojection process, in order to check if it is the same as in my own
implementation.

To do so, I print out one of the intermediate matrix that is generated in
rtkCudaBackProjectionImageFilter while launching a SART reconstruction for
instance.

I was surpised by the fact that, the matrix allowing the transformation
from 2D geometric world to 2D image index world, namely matrixIdxProj in
rtkCudaBackProjectionImageFilte.cxx
<http://www.openrtk.org/Doxygen/rtkCudaBackProjectionImageFilter_8cxx_source.html>
is not always the same along the reconstruction process ?

Here is the line that generates the matrix I don't understand:

for(unsigned int i=0; i<2; i++)
 //SR: 0.5 for 2D texture
  matrixIdxProj[i][2] =
-1*(this->GetInput(1)->GetBufferedRegion().GetIndex()[i])+0.5;

What I understand here, is that, we are generating a 2D translation matrix
embedded in a 3*3 matrix that allows to take into account two things
related to the 2D projection:

-If the internal behaviour of the imageContainer, allows buffering of only
a part of the image, beginning at index (i,j), this information will be
embeded in the projection matrix

-the ITK floating point addressing definition seems to differ from the one
from cuda (and openCV):
When I take a look at this page
<http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#texture-fetching>
I understand that the floating point indexing (0.5,0.5) in Cuda points to
the center of the pixel (0,0) hence a linear contribution of 100%, while it
seems that we must add a translation of (0.5,0.5) to the ITK geometric
framework in order to get the same behaviour.

In practice matrixIdxProj is based on a 3*3 identity matrix, where the
inner 2D translation (ie 2 first term of the last column) in my case are:
-in X, a random number between 10 and 150 plus 0.5
-in Y: always 0.5

I understand the 0.5 part, but why is there always a 0 offset in Y but a
random offset in X remains a mystery to me.

At first, I believed that each projection was splitted into multiple part,
each having a different X and Y offset.
But reconstructing using only one projection generates only one
backprojection operation, with a non zero offset in X, 123 in my case, for
an image of size 780 in X.

Do you think there is something wrong whith the values of matrixIdxProjI am
experiencing ?

Thank you in advance.

Kind regards

Thibault Notargiacomo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151110/fbd3fb46/attachment-0008.html>

From simon.rit at creatis.insa-lyon.fr  Tue Nov 10 08:21:29 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Tue, 10 Nov 2015 14:21:29 +0100
Subject: [Rtk-users] Understanding projection matrices management in
	rtkCudaBackProjectionImageFilter
In-Reply-To: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>
References: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>
Message-ID: <CAF0oig3muuH+1=eLZ66DJ22QcnsSrUKzRFS4RzDRvDJXNxAVXg@mail.gmail.com>

Hi Thibault,
You started digging in the code so that gets complicated. First thing
first, yes, the link you provide is still valid.
The offset in X is not random but computed in
BackProjectionImageFilter::GenerateInputRequestedRegion
<https://github.com/SimonRit/RTK/blob/master/code/rtkBackProjectionImageFilter.txx>.
The idea is that we request only the part of the projections we need to do
the backprojection. This optimizes the streaming (we only read from disk
what we need). If you use a huge volume (the test I'd suggest to validate
that I'm correct and there is nothing wrong with your code), then you'll
need the full projection and you will always get 0 in X as in Y. If you use
a small volume and do a computation projection per projection, you will get
a varying index depending on your input volume and the geometry for that
projection.
I think you understood the rest pretty well. Does that make sense or am I
missing something else?
Simon

On Tue, Nov 10, 2015 at 1:39 PM, Notargiacomo Thibault <gnthibault at gmail.com
> wrote:

> Hi all,
>
> I am currently trying to use the "AddProjectionInRadians" method from the
> ThreeDCircularProjectionGeometry class in RTK to import my geometry.
>
> First things first, I would like to know if the information on this pdf
> are still valid: http://www.openrtk.org/Doxygen/geometry.pdf
>
> Because I used them to deduce the source offset and Projection offset from
> my own matrix decomposition.
>
> Notice that I don't want to use geometric informations coming from the
> projection images themselves, so their geometric origin is assumed to be
> (0,0,0) in my case.
>
> In order to check if my geometry import method is correct, I print out one
> of the intermediate form of the projection matrix used in the
> backprojection process, in order to check if it is the same as in my own
> implementation.
>
> To do so, I print out one of the intermediate matrix that is generated in
> rtkCudaBackProjectionImageFilter while launching a SART reconstruction for
> instance.
>
> I was surpised by the fact that, the matrix allowing the transformation
> from 2D geometric world to 2D image index world, namely matrixIdxProj in
> rtkCudaBackProjectionImageFilte.cxx
> <http://www.openrtk.org/Doxygen/rtkCudaBackProjectionImageFilter_8cxx_source.html>
> is not always the same along the reconstruction process ?
>
> Here is the line that generates the matrix I don't understand:
>
> for(unsigned int i=0; i<2; i++)
>  //SR: 0.5 for 2D texture
>   matrixIdxProj[i][2] =
> -1*(this->GetInput(1)->GetBufferedRegion().GetIndex()[i])+0.5;
>
> What I understand here, is that, we are generating a 2D translation matrix
> embedded in a 3*3 matrix that allows to take into account two things
> related to the 2D projection:
>
> -If the internal behaviour of the imageContainer, allows buffering of only
> a part of the image, beginning at index (i,j), this information will be
> embeded in the projection matrix
>
> -the ITK floating point addressing definition seems to differ from the one
> from cuda (and openCV):
> When I take a look at this page
> <http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#texture-fetching>
> I understand that the floating point indexing (0.5,0.5) in Cuda points to
> the center of the pixel (0,0) hence a linear contribution of 100%, while it
> seems that we must add a translation of (0.5,0.5) to the ITK geometric
> framework in order to get the same behaviour.
>
> In practice matrixIdxProj is based on a 3*3 identity matrix, where the
> inner 2D translation (ie 2 first term of the last column) in my case are:
> -in X, a random number between 10 and 150 plus 0.5
> -in Y: always 0.5
>
> I understand the 0.5 part, but why is there always a 0 offset in Y but a
> random offset in X remains a mystery to me.
>
> At first, I believed that each projection was splitted into multiple part,
> each having a different X and Y offset.
> But reconstructing using only one projection generates only one
> backprojection operation, with a non zero offset in X, 123 in my case, for
> an image of size 780 in X.
>
> Do you think there is something wrong whith the values of matrixIdxProjI
> am experiencing ?
>
> Thank you in advance.
>
> Kind regards
>
> Thibault Notargiacomo
>
> _______________________________________________
> 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/20151110/8b9b86e6/attachment-0008.html>

From simon.rit at creatis.insa-lyon.fr  Tue Nov 10 09:03:52 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Tue, 10 Nov 2015 15:03:52 +0100
Subject: [Rtk-users] Understanding projection matrices management in
	rtkCudaBackProjectionImageFilter
In-Reply-To: <CAP+mR7ZLJV8V5dMOW_jgM5G2-kCZhy8o0tB19685LGo-1bxLUg@mail.gmail.com>
References: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>
 <CAF0oig3muuH+1=eLZ66DJ22QcnsSrUKzRFS4RzDRvDJXNxAVXg@mail.gmail.com>
 <CAP+mR7ZLJV8V5dMOW_jgM5G2-kCZhy8o0tB19685LGo-1bxLUg@mail.gmail.com>
Message-ID: <CAF0oig3fALRnZNCJ53+TsSjBm7raRC_mqahWEU6x+D+zxwOnVQ@mail.gmail.com>

A small correction: it's actually the amount of data pre-processed (read
from disk + all the processing before backprojection) but that should
change nothing to what is backprojected.
I remembered something that can help you: you may want to run
UpdateLargestPossibleRegion() to the projections (input 1 of the
BackProjectImageFilter) before backprojection to avoid this and make things
clearer instead of using a large volume as I was suggesting before.
Simon

On Tue, Nov 10, 2015 at 2:34 PM, Notargiacomo Thibault <gnthibault at gmail.com
> wrote:

> Ok, using geometric information to reduce the amount of data to be
> backprojected is pretty clever ;)
> This explains the "random" index I was asking about in my previous
> question, I now know what it is used for and continue my debugging process.
>
> Kind regards
>
> Thibault Notargiacomo
>
> 2015-11-10 14:21 GMT+01:00 Simon Rit <simon.rit at creatis.insa-lyon.fr>:
>
>> Hi Thibault,
>> You started digging in the code so that gets complicated. First thing
>> first, yes, the link you provide is still valid.
>> The offset in X is not random but computed in
>> BackProjectionImageFilter::GenerateInputRequestedRegion
>> <https://github.com/SimonRit/RTK/blob/master/code/rtkBackProjectionImageFilter.txx>.
>> The idea is that we request only the part of the projections we need to do
>> the backprojection. This optimizes the streaming (we only read from disk
>> what we need). If you use a huge volume (the test I'd suggest to validate
>> that I'm correct and there is nothing wrong with your code), then you'll
>> need the full projection and you will always get 0 in X as in Y. If you use
>> a small volume and do a computation projection per projection, you will get
>> a varying index depending on your input volume and the geometry for that
>> projection.
>> I think you understood the rest pretty well. Does that make sense or am I
>> missing something else?
>> Simon
>>
>> On Tue, Nov 10, 2015 at 1:39 PM, Notargiacomo Thibault <
>> gnthibault at gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> I am currently trying to use the "AddProjectionInRadians" method from
>>> the ThreeDCircularProjectionGeometry class in RTK to import my geometry.
>>>
>>> First things first, I would like to know if the information on this pdf
>>> are still valid: http://www.openrtk.org/Doxygen/geometry.pdf
>>>
>>> Because I used them to deduce the source offset and Projection offset
>>> from my own matrix decomposition.
>>>
>>> Notice that I don't want to use geometric informations coming from the
>>> projection images themselves, so their geometric origin is assumed to be
>>> (0,0,0) in my case.
>>>
>>> In order to check if my geometry import method is correct, I print out
>>> one of the intermediate form of the projection matrix used in the
>>> backprojection process, in order to check if it is the same as in my own
>>> implementation.
>>>
>>> To do so, I print out one of the intermediate matrix that is generated
>>> in rtkCudaBackProjectionImageFilter while launching a SART reconstruction
>>> for instance.
>>>
>>> I was surpised by the fact that, the matrix allowing the transformation
>>> from 2D geometric world to 2D image index world, namely matrixIdxProj in
>>> rtkCudaBackProjectionImageFilte.cxx
>>> <http://www.openrtk.org/Doxygen/rtkCudaBackProjectionImageFilter_8cxx_source.html>
>>> is not always the same along the reconstruction process ?
>>>
>>> Here is the line that generates the matrix I don't understand:
>>>
>>> for(unsigned int i=0; i<2; i++)
>>>  //SR: 0.5 for 2D texture
>>>   matrixIdxProj[i][2] =
>>> -1*(this->GetInput(1)->GetBufferedRegion().GetIndex()[i])+0.5;
>>>
>>> What I understand here, is that, we are generating a 2D translation
>>> matrix embedded in a 3*3 matrix that allows to take into account two things
>>> related to the 2D projection:
>>>
>>> -If the internal behaviour of the imageContainer, allows buffering of
>>> only a part of the image, beginning at index (i,j), this information will
>>> be embeded in the projection matrix
>>>
>>> -the ITK floating point addressing definition seems to differ from the
>>> one from cuda (and openCV):
>>> When I take a look at this page
>>> <http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#texture-fetching>
>>> I understand that the floating point indexing (0.5,0.5) in Cuda points to
>>> the center of the pixel (0,0) hence a linear contribution of 100%, while it
>>> seems that we must add a translation of (0.5,0.5) to the ITK geometric
>>> framework in order to get the same behaviour.
>>>
>>> In practice matrixIdxProj is based on a 3*3 identity matrix, where the
>>> inner 2D translation (ie 2 first term of the last column) in my case are:
>>> -in X, a random number between 10 and 150 plus 0.5
>>> -in Y: always 0.5
>>>
>>> I understand the 0.5 part, but why is there always a 0 offset in Y but a
>>> random offset in X remains a mystery to me.
>>>
>>> At first, I believed that each projection was splitted into multiple
>>> part, each having a different X and Y offset.
>>> But reconstructing using only one projection generates only one
>>> backprojection operation, with a non zero offset in X, 123 in my case, for
>>> an image of size 780 in X.
>>>
>>> Do you think there is something wrong whith the values of matrixIdxProjI
>>> am experiencing ?
>>>
>>> Thank you in advance.
>>>
>>> Kind regards
>>>
>>> Thibault Notargiacomo
>>>
>>> _______________________________________________
>>> 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/20151110/d8913dc3/attachment-0008.html>

From simon.rit at creatis.insa-lyon.fr  Tue Nov 10 11:21:29 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Tue, 10 Nov 2015 17:21:29 +0100
Subject: [Rtk-users] Understanding projection matrices management in
	rtkCudaBackProjectionImageFilter
In-Reply-To: <CAP+mR7ZKqnbUyRHyHkti=3sZd2dEw-OUV6oqsqcga55=tcQ9OQ@mail.gmail.com>
References: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>
 <CAF0oig3muuH+1=eLZ66DJ22QcnsSrUKzRFS4RzDRvDJXNxAVXg@mail.gmail.com>
 <CAP+mR7ZLJV8V5dMOW_jgM5G2-kCZhy8o0tB19685LGo-1bxLUg@mail.gmail.com>
 <CAF0oig3fALRnZNCJ53+TsSjBm7raRC_mqahWEU6x+D+zxwOnVQ@mail.gmail.com>
 <CAP+mR7ZKqnbUyRHyHkti=3sZd2dEw-OUV6oqsqcga55=tcQ9OQ@mail.gmail.com>
Message-ID: <CAF0oig12pRGBfgiCQMCwTG7zX_3vz87AEWhTQ4EYaVbH_m0t5Q@mail.gmail.com>

Your welcome (I cc the mailing list for info).
Simon

On Tue, Nov 10, 2015 at 5:03 PM, Notargiacomo Thibault <gnthibault at gmail.com
> wrote:

> I replaced the original Update by the "UpdateLargestPossibleRegion" to the
> divideFilter in SART (I bypassed displacedDetectorFilter for now) and it
> work as expected, I have now a "clean" matProjIdx.
>
> Thank you for your help !
>
> 2015-11-10 15:03 GMT+01:00 Simon Rit <simon.rit at creatis.insa-lyon.fr>:
>
>> A small correction: it's actually the amount of data pre-processed (read
>> from disk + all the processing before backprojection) but that should
>> change nothing to what is backprojected.
>> I remembered something that can help you: you may want to run
>> UpdateLargestPossibleRegion() to the projections (input 1 of the
>> BackProjectImageFilter) before backprojection to avoid this and make things
>> clearer instead of using a large volume as I was suggesting before.
>> Simon
>>
>> On Tue, Nov 10, 2015 at 2:34 PM, Notargiacomo Thibault <
>> gnthibault at gmail.com> wrote:
>>
>>> Ok, using geometric information to reduce the amount of data to be
>>> backprojected is pretty clever ;)
>>> This explains the "random" index I was asking about in my previous
>>> question, I now know what it is used for and continue my debugging process.
>>>
>>> Kind regards
>>>
>>> Thibault Notargiacomo
>>>
>>> 2015-11-10 14:21 GMT+01:00 Simon Rit <simon.rit at creatis.insa-lyon.fr>:
>>>
>>>> Hi Thibault,
>>>> You started digging in the code so that gets complicated. First thing
>>>> first, yes, the link you provide is still valid.
>>>> The offset in X is not random but computed in
>>>> BackProjectionImageFilter::GenerateInputRequestedRegion
>>>> <https://github.com/SimonRit/RTK/blob/master/code/rtkBackProjectionImageFilter.txx>.
>>>> The idea is that we request only the part of the projections we need to do
>>>> the backprojection. This optimizes the streaming (we only read from disk
>>>> what we need). If you use a huge volume (the test I'd suggest to validate
>>>> that I'm correct and there is nothing wrong with your code), then you'll
>>>> need the full projection and you will always get 0 in X as in Y. If you use
>>>> a small volume and do a computation projection per projection, you will get
>>>> a varying index depending on your input volume and the geometry for that
>>>> projection.
>>>> I think you understood the rest pretty well. Does that make sense or am
>>>> I missing something else?
>>>> Simon
>>>>
>>>> On Tue, Nov 10, 2015 at 1:39 PM, Notargiacomo Thibault <
>>>> gnthibault at gmail.com> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I am currently trying to use the "AddProjectionInRadians" method from
>>>>> the ThreeDCircularProjectionGeometry class in RTK to import my geometry.
>>>>>
>>>>> First things first, I would like to know if the information on this
>>>>> pdf are still valid: http://www.openrtk.org/Doxygen/geometry.pdf
>>>>>
>>>>> Because I used them to deduce the source offset and Projection offset
>>>>> from my own matrix decomposition.
>>>>>
>>>>> Notice that I don't want to use geometric informations coming from the
>>>>> projection images themselves, so their geometric origin is assumed to be
>>>>> (0,0,0) in my case.
>>>>>
>>>>> In order to check if my geometry import method is correct, I print out
>>>>> one of the intermediate form of the projection matrix used in the
>>>>> backprojection process, in order to check if it is the same as in my own
>>>>> implementation.
>>>>>
>>>>> To do so, I print out one of the intermediate matrix that is generated
>>>>> in rtkCudaBackProjectionImageFilter while launching a SART reconstruction
>>>>> for instance.
>>>>>
>>>>> I was surpised by the fact that, the matrix allowing the
>>>>> transformation from 2D geometric world to 2D image index world, namely
>>>>> matrixIdxProj in rtkCudaBackProjectionImageFilte.cxx
>>>>> <http://www.openrtk.org/Doxygen/rtkCudaBackProjectionImageFilter_8cxx_source.html>
>>>>> is not always the same along the reconstruction process ?
>>>>>
>>>>> Here is the line that generates the matrix I don't understand:
>>>>>
>>>>> for(unsigned int i=0; i<2; i++)
>>>>>  //SR: 0.5 for 2D texture
>>>>>   matrixIdxProj[i][2] =
>>>>> -1*(this->GetInput(1)->GetBufferedRegion().GetIndex()[i])+0.5;
>>>>>
>>>>> What I understand here, is that, we are generating a 2D translation
>>>>> matrix embedded in a 3*3 matrix that allows to take into account two things
>>>>> related to the 2D projection:
>>>>>
>>>>> -If the internal behaviour of the imageContainer, allows buffering of
>>>>> only a part of the image, beginning at index (i,j), this information will
>>>>> be embeded in the projection matrix
>>>>>
>>>>> -the ITK floating point addressing definition seems to differ from the
>>>>> one from cuda (and openCV):
>>>>> When I take a look at this page
>>>>> <http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#texture-fetching>
>>>>> I understand that the floating point indexing (0.5,0.5) in Cuda points to
>>>>> the center of the pixel (0,0) hence a linear contribution of 100%, while it
>>>>> seems that we must add a translation of (0.5,0.5) to the ITK geometric
>>>>> framework in order to get the same behaviour.
>>>>>
>>>>> In practice matrixIdxProj is based on a 3*3 identity matrix, where
>>>>> the inner 2D translation (ie 2 first term of the last column) in my case
>>>>> are:
>>>>> -in X, a random number between 10 and 150 plus 0.5
>>>>> -in Y: always 0.5
>>>>>
>>>>> I understand the 0.5 part, but why is there always a 0 offset in Y but
>>>>> a random offset in X remains a mystery to me.
>>>>>
>>>>> At first, I believed that each projection was splitted into multiple
>>>>> part, each having a different X and Y offset.
>>>>> But reconstructing using only one projection generates only one
>>>>> backprojection operation, with a non zero offset in X, 123 in my case, for
>>>>> an image of size 780 in X.
>>>>>
>>>>> Do you think there is something wrong whith the values of matrixIdxProjI
>>>>> am experiencing ?
>>>>>
>>>>> Thank you in advance.
>>>>>
>>>>> Kind regards
>>>>>
>>>>> Thibault Notargiacomo
>>>>>
>>>>> _______________________________________________
>>>>> 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/20151110/b7eba683/attachment-0008.html>

From theday79 at gmail.com  Wed Nov 11 13:50:45 2015
From: theday79 at gmail.com (Yang K Park)
Date: Wed, 11 Nov 2015 13:50:45 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after  a recent update
Message-ID: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>

Hi all,

 

I?ve updated rtk with the up-to-date revision and have encountered a couple of problems.

 

1.       Compile error: RTK couldn?t find itkMacro.h while it compiled rtkCudaUtilities.hcu. It was solved by a minor fetching:

#include <itkMacro.h>   --> #include "itkMacro.h" in rtkCudaUtilities.hcu

 

2.       Output of rtkfdk with CUDA was not the same as before. It was very blurry as seen in the attached image.

a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.

 

 

I?m using VS2013 with win7, itk4.8.1.

 

The command line I used was :

rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware cuda --pad 1 --hann 5 --hannY 5

 

Does anyone have any idea about this?

 

Thanks.

 

Yang

 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151111/b1c7df5f/attachment-0008.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 16577 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151111/b1c7df5f/attachment-0008.png>

From simon.rit at creatis.insa-lyon.fr  Wed Nov 11 16:15:49 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Wed, 11 Nov 2015 22:15:49 +0100
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
Message-ID: <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>

Hi,
I didn't manage to reproduce the two problems on linux with the same
ITK version.
For point 1, did you copy itkMacro.h by hand? Because I don't see how
replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not
in the same folder as rtkCudaUtilities.hcu
For point 2, no clue. Do you use FFTW? It looks like a ramp filter
issue. Can you try rtkramp --path projPath --regexp .*.his, with and
without --hardware cuda? Maybe you can provide your geometry file in
case it's a specific geometric issue.
Simon

On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
> Hi all,
>
>
>
> I?ve updated rtk with the up-to-date revision and have encountered a couple
> of problems.
>
>
>
> 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
> rtkCudaUtilities.hcu. It was solved by a minor fetching:
>
> #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>
>
>
> 2.       Output of rtkfdk with CUDA was not the same as before. It was very
> blurry as seen in the attached image.
>
> a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>
>
>
>
>
> I?m using VS2013 with win7, itk4.8.1.
>
>
>
> The command line I used was :
>
> rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his --output
> output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware cuda --pad 1
> --hann 5 --hannY 5
>
>
>
> Does anyone have any idea about this?
>
>
>
> Thanks.
>
>
>
> Yang
>
>
>
>
> _______________________________________________
> Rtk-users mailing list
> Rtk-users at public.kitware.com
> http://public.kitware.com/mailman/listinfo/rtk-users
>


From theday79 at gmail.com  Thu Nov 12 17:39:38 2015
From: theday79 at gmail.com (Yang K Park)
Date: Thu, 12 Nov 2015 17:39:38 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
Message-ID: <000001d11d9b$04142320$0c3c6960$@gmail.com>

Hi Simon,

 

Thanks for the advice. The current RTK was compiled with FFTW to use the phase extraction feature from Amsterdam shroud.

 

Regarding your suggestions,

 

1)      rtkramp w/ or w/o CUDA:

(command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda --output Ramp_wCUDA.mha? )

 

Then, I have encountered following error.

?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that input requested and buffered regions are equal.?

 



 

Without CUDA, it was successfully done.

 

2)      I?ve re-compiled ITK w/o FFTW and built RTK again. rtkfdk worked fine.

-          I?ve also repeated ?rtkramp+CUDA? with this rtk version and the error was same as above.

 

In conclusion, my FFTW seems to affect CUDA-based fdk reconstruction only.

But I do need FFTW for the phase extraction. What should I do?

 

Thanks.

 

Yang

 

 

-----Original Message-----
From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit
Sent: Wednesday, November 11, 2015 4:16 PM
To: Yang K Park <theday79 at gmail.com>
Cc: rtk-users at openrtk.org
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

I didn't manage to reproduce the two problems on linux with the same ITK version.

For point 1, did you copy itkMacro.h by hand? Because I don't see how replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW? It looks like a ramp filter issue. Can you try rtkramp --path projPath --regexp .*.his, with and without --hardware cuda? Maybe you can provide your geometry file in case it's a specific geometric issue.

Simon

 

On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park < <mailto:theday79 at gmail.com> theday79 at gmail.com> wrote:

> Hi all,

> 

> 

> 

> I?ve updated rtk with the up-to-date revision and have encountered a 

> couple of problems.

> 

> 

> 

> 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled

> rtkCudaUtilities.hcu. It was solved by a minor fetching:

> 

> #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu

> 

> 

> 

> 2.       Output of rtkfdk with CUDA was not the same as before. It was very

> blurry as seen in the attached image.

> 

> a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.

> 

> 

> 

> 

> 

> I?m using VS2013 with win7, itk4.8.1.

> 

> 

> 

> The command line I used was :

> 

> rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his 

> --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware 

> cuda --pad 1 --hann 5 --hannY 5

> 

> 

> 

> Does anyone have any idea about this?

> 

> 

> 

> Thanks.

> 

> 

> 

> Yang

> 

> 

> 

> 

> _______________________________________________

> Rtk-users mailing list

>  <mailto: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/20151112/4e0825dc/attachment-0008.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151112/4e0825dc/attachment-0008.png>

From simon.rit at creatis.insa-lyon.fr  Thu Nov 12 17:58:42 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Thu, 12 Nov 2015 23:58:42 +0100
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <000001d11d9b$04142320$0c3c6960$@gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
Message-ID: <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>

Hi,
Ok. Can you try rtkramp with only one projection? Then you shouldn't
encounter this regions issue (that should be solved one day but that's a
different story).
Can you also indicate which version of CUDA you're using?
FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft for
the FFT of the projections. So if they are not in the same format, you're
in trouble and that might be the issue here... The weird part is that I
didn't reproduce this problem on linux (with and without FFTW) but it might
be a CUDA version difference. I'll give it another try tomorrow when you
provide the CUDA version.
Thanks again for reporting the issue,
Simon

On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com> wrote:

> Hi Simon,
>
>
>
> Thanks for the advice. The current RTK was compiled with FFTW to use the
> phase extraction feature from Amsterdam shroud.
>
>
>
> Regarding your suggestions,
>
>
>
> 1)      rtkramp w/ or w/o CUDA:
>
> (command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda
> --output Ramp_wCUDA.mha? )
>
>
>
> Then, I have encountered following error.
>
> ?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that
> input requested and buffered regions are equal.?
>
>
>
>
>
> Without CUDA, it was successfully done.
>
>
>
> 2)      I?ve re-compiled *ITK w/o FFTW* and built RTK again. r*tkfdk
> worked fine.*
>
> -          I?ve also repeated ?rtkramp+CUDA? with this rtk version and
> the error was same as above.
>
>
>
> In conclusion, my *FFTW seems to affect CUDA-based fdk reconstruction
> only*.
>
> But I do need FFTW for the phase extraction. What should I do?
>
>
>
> Thanks.
>
>
>
> Yang
>
>
>
>
>
> -----Original Message-----
> From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon
> Rit
> Sent: Wednesday, November 11, 2015 4:16 PM
> To: Yang K Park <theday79 at gmail.com>
> Cc: rtk-users at openrtk.org
> Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
> update
>
>
>
> Hi,
>
> I didn't manage to reproduce the two problems on linux with the same ITK
> version.
>
> For point 1, did you copy itkMacro.h by hand? Because I don't see how
> replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the
> same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW?
> It looks like a ramp filter issue. Can you try rtkramp --path projPath
> --regexp .*.his, with and without --hardware cuda? Maybe you can provide
> your geometry file in case it's a specific geometric issue.
>
> Simon
>
>
>
> On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
>
> > Hi all,
>
> >
>
> >
>
> >
>
> > I?ve updated rtk with the up-to-date revision and have encountered a
>
> > couple of problems.
>
> >
>
> >
>
> >
>
> > 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
>
> > rtkCudaUtilities.hcu. It was solved by a minor fetching:
>
> >
>
> > #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>
> >
>
> >
>
> >
>
> > 2.       Output of rtkfdk with CUDA was not the same as before. It was
> very
>
> > blurry as seen in the attached image.
>
> >
>
> > a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > I?m using VS2013 with win7, itk4.8.1.
>
> >
>
> >
>
> >
>
> > The command line I used was :
>
> >
>
> > rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his
>
> > --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware
>
> > cuda --pad 1 --hann 5 --hannY 5
>
> >
>
> >
>
> >
>
> > Does anyone have any idea about this?
>
> >
>
> >
>
> >
>
> > Thanks.
>
> >
>
> >
>
> >
>
> > Yang
>
> >
>
> >
>
> >
>
> >
>
> > _______________________________________________
>
> > 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/20151112/e7c15ff8/attachment-0008.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151112/e7c15ff8/attachment-0008.png>

From theday79 at gmail.com  Mon Nov 16 09:54:01 2015
From: theday79 at gmail.com (Yang K Park)
Date: Mon, 16 Nov 2015 09:54:01 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
Message-ID: <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>

Hi Simon,

 

Sorry for the late response.

 

As you suggested, I?ve tried rtkramp+CUDA with only one projection and it was successfully done for both w/ FFTW and w/o FFTW.

(Two results were exactly same.)

 

Regarding  the CUDA version, I?m using v6.5.

 

Thanks a lot for the help!

 

Yang

 

 

From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit
Sent: Thursday, November 12, 2015 5:59 PM
To: Yang K Park <theday79 at gmail.com>
Cc: rtk-users at openrtk.org
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

Ok. Can you try rtkramp with only one projection? Then you shouldn't encounter this regions issue (that should be solved one day but that's a different story). 

Can you also indicate which version of CUDA you're using?

FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft for the FFT of the projections. So if they are not in the same format, you're in trouble and that might be the issue here... The weird part is that I didn't reproduce this problem on linux (with and without FFTW) but it might be a CUDA version difference. I'll give it another try tomorrow when you provide the CUDA version.

Thanks again for reporting the issue,
Simon

 

On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> > wrote:

Hi Simon,

 

Thanks for the advice. The current RTK was compiled with FFTW to use the phase extraction feature from Amsterdam shroud.

 

Regarding your suggestions,

 

1)      rtkramp w/ or w/o CUDA:

(command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda --output Ramp_wCUDA.mha? )

 

Then, I have encountered following error.

?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that input requested and buffered regions are equal.?

 



 

Without CUDA, it was successfully done.

 

2)      I?ve re-compiled ITK w/o FFTW and built RTK again. rtkfdk worked fine.

-          I?ve also repeated ?rtkramp+CUDA? with this rtk version and the error was same as above.

 

In conclusion, my FFTW seems to affect CUDA-based fdk reconstruction only.

But I do need FFTW for the phase extraction. What should I do?

 

Thanks.

 

Yang

 

 

-----Original Message-----
From: simon.rit at gmail.com <mailto:simon.rit at gmail.com>  [mailto:simon.rit at gmail.com <mailto:simon.rit at gmail.com> ] On Behalf Of Simon Rit
Sent: Wednesday, November 11, 2015 4:16 PM
To: Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> >
Cc: rtk-users at openrtk.org <mailto:rtk-users at openrtk.org> 
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

I didn't manage to reproduce the two problems on linux with the same ITK version.

For point 1, did you copy itkMacro.h by hand? Because I don't see how replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW? It looks like a ramp filter issue. Can you try rtkramp --path projPath --regexp .*.his, with and without --hardware cuda? Maybe you can provide your geometry file in case it's a specific geometric issue.

Simon

 

On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park < <mailto:theday79 at gmail.com> theday79 at gmail.com> wrote:

> Hi all,

> 

> 

> 

> I?ve updated rtk with the up-to-date revision and have encountered a 

> couple of problems.

> 

> 

> 

> 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled

> rtkCudaUtilities.hcu. It was solved by a minor fetching:

> 

> #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu

> 

> 

> 

> 2.       Output of rtkfdk with CUDA was not the same as before. It was very

> blurry as seen in the attached image.

> 

> a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.

> 

> 

> 

> 

> 

> I?m using VS2013 with win7, itk4.8.1.

> 

> 

> 

> The command line I used was :

> 

> rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his 

> --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware 

> cuda --pad 1 --hann 5 --hannY 5

> 

> 

> 

> Does anyone have any idea about this?

> 

> 

> 

> Thanks.

> 

> 

> 

> Yang

> 

> 

> 

> 

> _______________________________________________

> Rtk-users mailing list

>  <mailto: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/20151116/e77c2f96/attachment-0008.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151116/e77c2f96/attachment-0008.png>

From simon.rit at creatis.insa-lyon.fr  Mon Nov 16 10:07:46 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Mon, 16 Nov 2015 16:07:46 +0100
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
 <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
Message-ID: <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>

Hi,
Thanks. It's really weird... When you run the tests with FFTW (compiling
the "test" target), do they fail?
Can you provide your geometry file? It might be specific to this geometry.
Thanks again for looking into this issue, we'll find what's the problem.
Simon

On Mon, Nov 16, 2015 at 3:54 PM, Yang K Park <theday79 at gmail.com> wrote:

> Hi Simon,
>
>
>
> Sorry for the late response.
>
>
>
> As you suggested, I?ve tried rtkramp+CUDA with only one projection and it
> was successfully done for both w/ FFTW and w/o FFTW.
>
> (Two results were exactly same.)
>
>
>
> Regarding  the CUDA version, I?m using v6.5.
>
>
>
> Thanks a lot for the help!
>
>
>
> Yang
>
>
>
>
>
> *From:* simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of *Simon
> Rit
> *Sent:* Thursday, November 12, 2015 5:59 PM
>
> *To:* Yang K Park <theday79 at gmail.com>
> *Cc:* rtk-users at openrtk.org
> *Subject:* Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
> update
>
>
>
> Hi,
>
> Ok. Can you try rtkramp with only one projection? Then you shouldn't
> encounter this regions issue (that should be solved one day but that's a
> different story).
>
> Can you also indicate which version of CUDA you're using?
>
> FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft for
> the FFT of the projections. So if they are not in the same format, you're
> in trouble and that might be the issue here... The weird part is that I
> didn't reproduce this problem on linux (with and without FFTW) but it might
> be a CUDA version difference. I'll give it another try tomorrow when you
> provide the CUDA version.
>
> Thanks again for reporting the issue,
> Simon
>
>
>
> On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com> wrote:
>
> Hi Simon,
>
>
>
> Thanks for the advice. The current RTK was compiled with FFTW to use the
> phase extraction feature from Amsterdam shroud.
>
>
>
> Regarding your suggestions,
>
>
>
> 1)      rtkramp w/ or w/o CUDA:
>
> (command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda
> --output Ramp_wCUDA.mha? )
>
>
>
> Then, I have encountered following error.
>
> ?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that
> input requested and buffered regions are equal.?
>
>
>
>
>
> Without CUDA, it was successfully done.
>
>
>
> 2)      I?ve re-compiled *ITK w/o FFTW* and built RTK again. r*tkfdk
> worked fine.*
>
> -          I?ve also repeated ?rtkramp+CUDA? with this rtk version and
> the error was same as above.
>
>
>
> In conclusion, my *FFTW seems to affect CUDA-based fdk reconstruction
> only*.
>
> But I do need FFTW for the phase extraction. What should I do?
>
>
>
> Thanks.
>
>
>
> Yang
>
>
>
>
>
> -----Original Message-----
> From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon
> Rit
> Sent: Wednesday, November 11, 2015 4:16 PM
> To: Yang K Park <theday79 at gmail.com>
> Cc: rtk-users at openrtk.org
> Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
> update
>
>
>
> Hi,
>
> I didn't manage to reproduce the two problems on linux with the same ITK
> version.
>
> For point 1, did you copy itkMacro.h by hand? Because I don't see how
> replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the
> same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW?
> It looks like a ramp filter issue. Can you try rtkramp --path projPath
> --regexp .*.his, with and without --hardware cuda? Maybe you can provide
> your geometry file in case it's a specific geometric issue.
>
> Simon
>
>
>
> On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
>
> > Hi all,
>
> >
>
> >
>
> >
>
> > I?ve updated rtk with the up-to-date revision and have encountered a
>
> > couple of problems.
>
> >
>
> >
>
> >
>
> > 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
>
> > rtkCudaUtilities.hcu. It was solved by a minor fetching:
>
> >
>
> > #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>
> >
>
> >
>
> >
>
> > 2.       Output of rtkfdk with CUDA was not the same as before. It was
> very
>
> > blurry as seen in the attached image.
>
> >
>
> > a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > I?m using VS2013 with win7, itk4.8.1.
>
> >
>
> >
>
> >
>
> > The command line I used was :
>
> >
>
> > rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his
>
> > --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware
>
> > cuda --pad 1 --hann 5 --hannY 5
>
> >
>
> >
>
> >
>
> > Does anyone have any idea about this?
>
> >
>
> >
>
> >
>
> > Thanks.
>
> >
>
> >
>
> >
>
> > Yang
>
> >
>
> >
>
> >
>
> >
>
> > _______________________________________________
>
> > 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/20151116/38acfca5/attachment-0008.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151116/38acfca5/attachment-0008.png>

From theday79 at gmail.com  Mon Nov 16 10:47:43 2015
From: theday79 at gmail.com (Yang-Kyun Park)
Date: Mon, 16 Nov 2015 10:47:43 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
 <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
 <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>
Message-ID: <CAJM7=xjBjx=FzLazWJWqJbV5d45zGi2U71NKejm9HxKhJ0-xLQ@mail.gmail.com>

Hi Simon,

For better understanding, I'm attaching the problematic case including
projection files, geometry file(xml) and reconstructed images.(please find
the GDrive links. The file size is ~800 MB)
This is phantom data and there is no patient information in it.

Regarding the fftw library, I'm using [fftw-3.3.4-dll64].

By the way, I found another clue. When I've tried it with a head phantom
image (full-fan, ~ 190 projections), there was no problem. Is there any
possibility that DDF and parker short filter play some roles on this issue?

Feel free to let me know if further data is needed.

Thanks!

Yang

?
 FFTW_issue.zip
<https://drive.google.com/file/d/0BxuP3mON9V-qbVdQd0luc1lIb2M/view?usp=drive_web>
?

On Mon, Nov 16, 2015 at 10:07 AM, Simon Rit <simon.rit at creatis.insa-lyon.fr>
wrote:

> Hi,
> Thanks. It's really weird... When you run the tests with FFTW (compiling
> the "test" target), do they fail?
> Can you provide your geometry file? It might be specific to this geometry.
> Thanks again for looking into this issue, we'll find what's the problem.
> Simon
>
> On Mon, Nov 16, 2015 at 3:54 PM, Yang K Park <theday79 at gmail.com> wrote:
>
>> Hi Simon,
>>
>>
>>
>> Sorry for the late response.
>>
>>
>>
>> As you suggested, I?ve tried rtkramp+CUDA with only one projection and it
>> was successfully done for both w/ FFTW and w/o FFTW.
>>
>> (Two results were exactly same.)
>>
>>
>>
>> Regarding  the CUDA version, I?m using v6.5.
>>
>>
>>
>> Thanks a lot for the help!
>>
>>
>>
>> Yang
>>
>>
>>
>>
>>
>> *From:* simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of *Simon
>> Rit
>> *Sent:* Thursday, November 12, 2015 5:59 PM
>>
>> *To:* Yang K Park <theday79 at gmail.com>
>> *Cc:* rtk-users at openrtk.org
>> *Subject:* Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
>> update
>>
>>
>>
>> Hi,
>>
>> Ok. Can you try rtkramp with only one projection? Then you shouldn't
>> encounter this regions issue (that should be solved one day but that's a
>> different story).
>>
>> Can you also indicate which version of CUDA you're using?
>>
>> FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft
>> for the FFT of the projections. So if they are not in the same format,
>> you're in trouble and that might be the issue here... The weird part is
>> that I didn't reproduce this problem on linux (with and without FFTW) but
>> it might be a CUDA version difference. I'll give it another try tomorrow
>> when you provide the CUDA version.
>>
>> Thanks again for reporting the issue,
>> Simon
>>
>>
>>
>> On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com> wrote:
>>
>> Hi Simon,
>>
>>
>>
>> Thanks for the advice. The current RTK was compiled with FFTW to use the
>> phase extraction feature from Amsterdam shroud.
>>
>>
>>
>> Regarding your suggestions,
>>
>>
>>
>> 1)      rtkramp w/ or w/o CUDA:
>>
>> (command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda
>> --output Ramp_wCUDA.mha? )
>>
>>
>>
>> Then, I have encountered following error.
>>
>> ?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that
>> input requested and buffered regions are equal.?
>>
>>
>>
>>
>>
>> Without CUDA, it was successfully done.
>>
>>
>>
>> 2)      I?ve re-compiled *ITK w/o FFTW* and built RTK again. r*tkfdk
>> worked fine.*
>>
>> -          I?ve also repeated ?rtkramp+CUDA? with this rtk version and
>> the error was same as above.
>>
>>
>>
>> In conclusion, my *FFTW seems to affect CUDA-based fdk reconstruction
>> only*.
>>
>> But I do need FFTW for the phase extraction. What should I do?
>>
>>
>>
>> Thanks.
>>
>>
>>
>> Yang
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of
>> Simon Rit
>> Sent: Wednesday, November 11, 2015 4:16 PM
>> To: Yang K Park <theday79 at gmail.com>
>> Cc: rtk-users at openrtk.org
>> Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
>> update
>>
>>
>>
>> Hi,
>>
>> I didn't manage to reproduce the two problems on linux with the same ITK
>> version.
>>
>> For point 1, did you copy itkMacro.h by hand? Because I don't see how
>> replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the
>> same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW?
>> It looks like a ramp filter issue. Can you try rtkramp --path projPath
>> --regexp .*.his, with and without --hardware cuda? Maybe you can provide
>> your geometry file in case it's a specific geometric issue.
>>
>> Simon
>>
>>
>>
>> On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
>>
>> > Hi all,
>>
>> >
>>
>> >
>>
>> >
>>
>> > I?ve updated rtk with the up-to-date revision and have encountered a
>>
>> > couple of problems.
>>
>> >
>>
>> >
>>
>> >
>>
>> > 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
>>
>> > rtkCudaUtilities.hcu. It was solved by a minor fetching:
>>
>> >
>>
>> > #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>>
>> >
>>
>> >
>>
>> >
>>
>> > 2.       Output of rtkfdk with CUDA was not the same as before. It was
>> very
>>
>> > blurry as seen in the attached image.
>>
>> >
>>
>> > a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>
>> > I?m using VS2013 with win7, itk4.8.1.
>>
>> >
>>
>> >
>>
>> >
>>
>> > The command line I used was :
>>
>> >
>>
>> > rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his
>>
>> > --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware
>>
>> > cuda --pad 1 --hann 5 --hannY 5
>>
>> >
>>
>> >
>>
>> >
>>
>> > Does anyone have any idea about this?
>>
>> >
>>
>> >
>>
>> >
>>
>> > Thanks.
>>
>> >
>>
>> >
>>
>> >
>>
>> > Yang
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>
>> > _______________________________________________
>>
>> > 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/20151116/90d2c5a0/attachment-0008.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151116/90d2c5a0/attachment-0008.png>

From simon.rit at creatis.insa-lyon.fr  Fri Nov 20 11:28:22 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Fri, 20 Nov 2015 17:28:22 +0100
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAJM7=xjBjx=FzLazWJWqJbV5d45zGi2U71NKejm9HxKhJ0-xLQ@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
 <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
 <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>
 <CAJM7=xjBjx=FzLazWJWqJbV5d45zGi2U71NKejm9HxKhJ0-xLQ@mail.gmail.com>
Message-ID: <CAF0oig027_u_9gb8bnwT1w9jr3epZ0hkd9Mt73qK5heUq_kCkg@mail.gmail.com>

Hi Yang,
Thanks a lot for sharing the data. I have good news. I could reproduce the
bug and I have solutions. First, about your dataset: it's a huge dataset
and the hannY requires zero padding in both x and y. Because of this, cufft
has to take the 2D FFT of projection subsets that are 4095x2048x16. Quite
big!
When I ran it on my cuda 7.0, I immediately got:

itk::ExceptionObject (0x8b9cb30)
Location: "void CUDA_fft_convolution(const int3&, const int2&, float*,
cufftComplex*)"
File: /home/srit/src/rtk/rtk/code/rtkCudaFFTConvolutionImageFilter.cu
Line: 97
Description: itk::ERROR: CUFFT ERROR #2

i.e., a GPU alloc issue, even if I have the largest possible memory on a
nvidia desktop computer. Then, I ran it with cuda 6.5 and I got no error
message but a result similar to yours.
Conclusions:
- if you add the option --subsetsize 1 to your rtkfdk command line, that
should reconstruct correctly
- if you upgrade cuda, you should get an understandable error message,
- I don't think I'm going to look for a solution because the pb is probably
in cufft but if someone is willing to, be my guest!
Simon

On Mon, Nov 16, 2015 at 4:47 PM, Yang-Kyun Park <theday79 at gmail.com> wrote:

> Hi Simon,
>
> For better understanding, I'm attaching the problematic case including
> projection files, geometry file(xml) and reconstructed images.(please find
> the GDrive links. The file size is ~800 MB)
> This is phantom data and there is no patient information in it.
>
> Regarding the fftw library, I'm using [fftw-3.3.4-dll64].
>
> By the way, I found another clue. When I've tried it with a head phantom
> image (full-fan, ~ 190 projections), there was no problem. Is there any
> possibility that DDF and parker short filter play some roles on this issue?
>
> Feel free to let me know if further data is needed.
>
> Thanks!
>
> Yang
>
> ?
>  FFTW_issue.zip
> <https://drive.google.com/file/d/0BxuP3mON9V-qbVdQd0luc1lIb2M/view?usp=drive_web>
> ?
>
> On Mon, Nov 16, 2015 at 10:07 AM, Simon Rit <
> simon.rit at creatis.insa-lyon.fr> wrote:
>
>> Hi,
>> Thanks. It's really weird... When you run the tests with FFTW (compiling
>> the "test" target), do they fail?
>> Can you provide your geometry file? It might be specific to this geometry.
>> Thanks again for looking into this issue, we'll find what's the problem.
>> Simon
>>
>> On Mon, Nov 16, 2015 at 3:54 PM, Yang K Park <theday79 at gmail.com> wrote:
>>
>>> Hi Simon,
>>>
>>>
>>>
>>> Sorry for the late response.
>>>
>>>
>>>
>>> As you suggested, I?ve tried rtkramp+CUDA with only one projection and
>>> it was successfully done for both w/ FFTW and w/o FFTW.
>>>
>>> (Two results were exactly same.)
>>>
>>>
>>>
>>> Regarding  the CUDA version, I?m using v6.5.
>>>
>>>
>>>
>>> Thanks a lot for the help!
>>>
>>>
>>>
>>> Yang
>>>
>>>
>>>
>>>
>>>
>>> *From:* simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of *Simon
>>> Rit
>>> *Sent:* Thursday, November 12, 2015 5:59 PM
>>>
>>> *To:* Yang K Park <theday79 at gmail.com>
>>> *Cc:* rtk-users at openrtk.org
>>> *Subject:* Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
>>> update
>>>
>>>
>>>
>>> Hi,
>>>
>>> Ok. Can you try rtkramp with only one projection? Then you shouldn't
>>> encounter this regions issue (that should be solved one day but that's a
>>> different story).
>>>
>>> Can you also indicate which version of CUDA you're using?
>>>
>>> FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft
>>> for the FFT of the projections. So if they are not in the same format,
>>> you're in trouble and that might be the issue here... The weird part is
>>> that I didn't reproduce this problem on linux (with and without FFTW) but
>>> it might be a CUDA version difference. I'll give it another try tomorrow
>>> when you provide the CUDA version.
>>>
>>> Thanks again for reporting the issue,
>>> Simon
>>>
>>>
>>>
>>> On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com>
>>> wrote:
>>>
>>> Hi Simon,
>>>
>>>
>>>
>>> Thanks for the advice. The current RTK was compiled with FFTW to use the
>>> phase extraction feature from Amsterdam shroud.
>>>
>>>
>>>
>>> Regarding your suggestions,
>>>
>>>
>>>
>>> 1)      rtkramp w/ or w/o CUDA:
>>>
>>> (command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda
>>> --output Ramp_wCUDA.mha? )
>>>
>>>
>>>
>>> Then, I have encountered following error.
>>>
>>> ?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that
>>> input requested and buffered regions are equal.?
>>>
>>>
>>>
>>>
>>>
>>> Without CUDA, it was successfully done.
>>>
>>>
>>>
>>> 2)      I?ve re-compiled *ITK w/o FFTW* and built RTK again. r*tkfdk
>>> worked fine.*
>>>
>>> -          I?ve also repeated ?rtkramp+CUDA? with this rtk version and
>>> the error was same as above.
>>>
>>>
>>>
>>> In conclusion, my *FFTW seems to affect CUDA-based fdk reconstruction
>>> only*.
>>>
>>> But I do need FFTW for the phase extraction. What should I do?
>>>
>>>
>>>
>>> Thanks.
>>>
>>>
>>>
>>> Yang
>>>
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of
>>> Simon Rit
>>> Sent: Wednesday, November 11, 2015 4:16 PM
>>> To: Yang K Park <theday79 at gmail.com>
>>> Cc: rtk-users at openrtk.org
>>> Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
>>> update
>>>
>>>
>>>
>>> Hi,
>>>
>>> I didn't manage to reproduce the two problems on linux with the same ITK
>>> version.
>>>
>>> For point 1, did you copy itkMacro.h by hand? Because I don't see how
>>> replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the
>>> same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW?
>>> It looks like a ramp filter issue. Can you try rtkramp --path projPath
>>> --regexp .*.his, with and without --hardware cuda? Maybe you can provide
>>> your geometry file in case it's a specific geometric issue.
>>>
>>> Simon
>>>
>>>
>>>
>>> On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
>>>
>>> > Hi all,
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > I?ve updated rtk with the up-to-date revision and have encountered a
>>>
>>> > couple of problems.
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
>>>
>>> > rtkCudaUtilities.hcu. It was solved by a minor fetching:
>>>
>>> >
>>>
>>> > #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > 2.       Output of rtkfdk with CUDA was not the same as before. It was
>>> very
>>>
>>> > blurry as seen in the attached image.
>>>
>>> >
>>>
>>> > a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > I?m using VS2013 with win7, itk4.8.1.
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > The command line I used was :
>>>
>>> >
>>>
>>> > rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his
>>>
>>> > --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware
>>>
>>> > cuda --pad 1 --hann 5 --hannY 5
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > Does anyone have any idea about this?
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > Thanks.
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > Yang
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > _______________________________________________
>>>
>>> > 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/20151120/4e6c0e1e/attachment-0008.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151120/4e6c0e1e/attachment-0008.png>

From theday79 at gmail.com  Fri Nov 20 12:36:51 2015
From: theday79 at gmail.com (Yang K Park)
Date: Fri, 20 Nov 2015 12:36:51 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAF0oig027_u_9gb8bnwT1w9jr3epZ0hkd9Mt73qK5heUq_kCkg@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
 <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
 <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>
 <CAJM7=xjBjx=FzLazWJWqJbV5d45zGi2U71NKejm9HxKhJ0-xLQ@mail.gmail.com>
 <CAF0oig027_u_9gb8bnwT1w9jr3epZ0hkd9Mt73qK5heUq_kCkg@mail.gmail.com>
Message-ID: <000901d123ba$0ae3de50$20ab9af0$@gmail.com>

Hi Simon,

 

That sounds great! Thanks a lot for your hard work.

As you said, now I can reconstruct it successfully with --subsetsize option.

 

I think the only concern left is the elongated reconstruction time.

I?ve measured it for the same phantom image with different ?subsetsize? values as well as w/o FFTW compiling.

I just report it for your information.

 

1)      w/o FFTW  : 21.4 s

2)      w/ FFTW & --subsetsize 1: 89 s

3)      w/ FFTW & --subsetsize 2: 77 s

4)      w/ FFTW & --subsetsize 4: 65 s

5)      w/ FFTW & --subsetsize 6: 51 s

6)      w/ FFTW & --subsetsize 7: (Error-graphic card seemed to be freezed)

7)      w/ FFTW & --subsetsize 8: (Error-?itk::ERROR: CUFFT ERROR #2 in rtkCudaFFTConvolutionImageFilter.cu?)

 

Of course, the difference was coming from the Ramp filter.

Therefore, I?m going to use [--subsetsize 6] for my system and will update CUDA version soon!

 

Thanks.

 

Yang

 

 

From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit
Sent: Friday, November 20, 2015 11:28 AM
To: Yang-Kyun Park <theday79 at gmail.com>
Cc: rtk-users at openrtk.org
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi Yang,
Thanks a lot for sharing the data. I have good news. I could reproduce the bug and I have solutions. First, about your dataset: it's a huge dataset and the hannY requires zero padding in both x and y. Because of this, cufft has to take the 2D FFT of projection subsets that are 4095x2048x16. Quite big!

When I ran it on my cuda 7.0, I immediately got:

itk::ExceptionObject (0x8b9cb30)
Location: "void CUDA_fft_convolution(const int3&, const int2&, float*, cufftComplex*)" 
File: /home/srit/src/rtk/rtk/code/rtkCudaFFTConvolutionImageFilter.cu
Line: 97
Description: itk::ERROR: CUFFT ERROR #2

i.e., a GPU alloc issue, even if I have the largest possible memory on a nvidia desktop computer. Then, I ran it with cuda 6.5 and I got no error message but a result similar to yours.

Conclusions:

- if you add the option --subsetsize 1 to your rtkfdk command line, that should reconstruct correctly

- if you upgrade cuda, you should get an understandable error message,

- I don't think I'm going to look for a solution because the pb is probably in cufft but if someone is willing to, be my guest!

Simon

 

On Mon, Nov 16, 2015 at 4:47 PM, Yang-Kyun Park <theday79 at gmail.com <mailto:theday79 at gmail.com> > wrote:

Hi Simon,

 

For better understanding, I'm attaching the problematic case including projection files, geometry file(xml) and reconstructed images.(please find the GDrive links. The file size is ~800 MB)

This is phantom data and there is no patient information in it.

 

Regarding the fftw library, I'm using [fftw-3.3.4-dll64].

 

By the way, I found another clue. When I've tried it with a head phantom image (full-fan, ~ 190 projections), there was no problem. Is there any possibility that DDF and parker short filter play some roles on this issue?

 

Feel free to let me know if further data is needed.

 

Thanks!

 

Yang

 

?

 <https://drive.google.com/file/d/0BxuP3mON9V-qbVdQd0luc1lIb2M/view?usp=drive_web>  FFTW_issue.zip

?

 

On Mon, Nov 16, 2015 at 10:07 AM, Simon Rit <simon.rit at creatis.insa-lyon.fr <mailto:simon.rit at creatis.insa-lyon.fr> > wrote:

Hi,

Thanks. It's really weird... When you run the tests with FFTW (compiling the "test" target), do they fail?
Can you provide your geometry file? It might be specific to this geometry.

Thanks again for looking into this issue, we'll find what's the problem.

Simon

 

On Mon, Nov 16, 2015 at 3:54 PM, Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> > wrote:

Hi Simon,

 

Sorry for the late response.

 

As you suggested, I?ve tried rtkramp+CUDA with only one projection and it was successfully done for both w/ FFTW and w/o FFTW.

(Two results were exactly same.)

 

Regarding  the CUDA version, I?m using v6.5.

 

Thanks a lot for the help!

 

Yang

 

 

From: simon.rit at gmail.com <mailto:simon.rit at gmail.com>  [mailto:simon.rit at gmail.com <mailto:simon.rit at gmail.com> ] On Behalf Of Simon Rit
Sent: Thursday, November 12, 2015 5:59 PM


To: Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> >
Cc: rtk-users at openrtk.org <mailto:rtk-users at openrtk.org> 
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

Ok. Can you try rtkramp with only one projection? Then you shouldn't encounter this regions issue (that should be solved one day but that's a different story). 

Can you also indicate which version of CUDA you're using?

FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft for the FFT of the projections. So if they are not in the same format, you're in trouble and that might be the issue here... The weird part is that I didn't reproduce this problem on linux (with and without FFTW) but it might be a CUDA version difference. I'll give it another try tomorrow when you provide the CUDA version.

Thanks again for reporting the issue,
Simon

 

On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> > wrote:

Hi Simon,

 

Thanks for the advice. The current RTK was compiled with FFTW to use the phase extraction feature from Amsterdam shroud.

 

Regarding your suggestions,

 

1)      rtkramp w/ or w/o CUDA:

(command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda --output Ramp_wCUDA.mha? )

 

Then, I have encountered following error.

?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that input requested and buffered regions are equal.?

 



 

Without CUDA, it was successfully done.

 

2)      I?ve re-compiled ITK w/o FFTW and built RTK again. rtkfdk worked fine.

-          I?ve also repeated ?rtkramp+CUDA? with this rtk version and the error was same as above.

 

In conclusion, my FFTW seems to affect CUDA-based fdk reconstruction only.

But I do need FFTW for the phase extraction. What should I do?

 

Thanks.

 

Yang

 

 

-----Original Message-----
From: simon.rit at gmail.com <mailto:simon.rit at gmail.com>  [mailto:simon.rit at gmail.com <mailto:simon.rit at gmail.com> ] On Behalf Of Simon Rit
Sent: Wednesday, November 11, 2015 4:16 PM
To: Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> >
Cc: rtk-users at openrtk.org <mailto:rtk-users at openrtk.org> 
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

I didn't manage to reproduce the two problems on linux with the same ITK version.

For point 1, did you copy itkMacro.h by hand? Because I don't see how replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW? It looks like a ramp filter issue. Can you try rtkramp --path projPath --regexp .*.his, with and without --hardware cuda? Maybe you can provide your geometry file in case it's a specific geometric issue.

Simon

 

On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park < <mailto:theday79 at gmail.com> theday79 at gmail.com> wrote:

> Hi all,

> 

> 

> 

> I?ve updated rtk with the up-to-date revision and have encountered a 

> couple of problems.

> 

> 

> 

> 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled

> rtkCudaUtilities.hcu. It was solved by a minor fetching:

> 

> #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu

> 

> 

> 

> 2.       Output of rtkfdk with CUDA was not the same as before. It was very

> blurry as seen in the attached image.

> 

> a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.

> 

> 

> 

> 

> 

> I?m using VS2013 with win7, itk4.8.1.

> 

> 

> 

> The command line I used was :

> 

> rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his 

> --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware 

> cuda --pad 1 --hann 5 --hannY 5

> 

> 

> 

> Does anyone have any idea about this?

> 

> 

> 

> Thanks.

> 

> 

> 

> Yang

> 

> 

> 

> 

> _______________________________________________

> Rtk-users mailing list

>  <mailto: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/20151120/0d98ace1/attachment-0008.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151120/0d98ace1/attachment-0008.png>

From simon.rit at creatis.insa-lyon.fr  Wed Nov 25 02:36:44 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Wed, 25 Nov 2015 08:36:44 +0100
Subject: [Rtk-users] Compiling Problem
In-Reply-To: <040e01d125c7$83648e60$8a2dab20$@126.com>
References: <040e01d125c7$83648e60$8a2dab20$@126.com>
Message-ID: <5655650C.1040500@creatis.insa-lyon.fr>

Hi,
Please use the mailing list. I don't know where does the linking problem 
come from and it seems to work on our side:
http://my.cdash.org/index.php?project=RTK
Have you tried disabling CUDA?
Simon

On 23/11/2015 09:18, Freyman li wrote:
>
> Dear Simon,
>
> Recently I configured the RTK tool and suffer some problems. After set 
> up the itk tool and cuda, I compiled the rtk application but 
> encountered two errors attached to the email(jpg format)
>
> CUDA and ITK environment are tested successfully. My compile tool is 
> Visual studio 2012(64bit) and CUDA version is v6.5.
>
> Can you tell me how to deal with it and I am looking forward to hear 
> you again.
>
> Thank you!
>
> Best Regards
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151125/285f7f3c/attachment-0008.html>

From theday79 at gmail.com  Wed Nov 25 12:38:52 2015
From: theday79 at gmail.com (Yang K Park)
Date: Wed, 25 Nov 2015 12:38:52 -0500
Subject: [Rtk-users] Compiling Problem
In-Reply-To: <5655650C.1040500@creatis.insa-lyon.fr>
References: <040e01d125c7$83648e60$8a2dab20$@126.com>
 <5655650C.1040500@creatis.insa-lyon.fr>
Message-ID: <003d01d127a8$27a52b60$76ef8220$@gmail.com>

Hi Freyman,

 

I think your setting is much similar to mine, since I have compiled RTK with
VS2013 and CUDA v6.5 several times. Can you post those error messages again
so that I can see?

Yang

 

 

From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of
Simon Rit
Sent: Wednesday, November 25, 2015 2:37 AM
To: Freyman li <lihanwei_1500 at 126.com>
Cc: rtk-users at openrtk.org
Subject: Re: [Rtk-users] Compiling Problem

 

Hi,
Please use the mailing list. I don't know where does the linking problem
come from and it seems to work on our side:
http://my.cdash.org/index.php?project=RTK
Have you tried disabling CUDA?
Simon

On 23/11/2015 09:18, Freyman li wrote:

Dear Simon,

 

Recently I configured the RTK tool and suffer some problems. After set up
the itk tool and cuda, I compiled the rtk application but encountered two
errors attached to the email(jpg format)

CUDA and ITK environment are tested successfully. My compile tool is Visual
studio 2012(64bit) and CUDA version is v6.5.

Can you tell me how to deal with it and I am looking forward to hear you
again.

Thank you!

 

Best Regards

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151125/984feb50/attachment-0008.html>

From bioniloofar at gmail.com  Mon Nov 30 06:06:41 2015
From: bioniloofar at gmail.com (niloufar teyfouri)
Date: Mon, 30 Nov 2015 14:36:41 +0330
Subject: [Rtk-users] ElectaReconstruction
Message-ID: <CALChM12F4PuiLvgENg3Yyn7E+uZ7iPJ+GiY04z7VQ-90AS83EA@mail.gmail.com>

I ran the application of Electa Reconstruction implemented by you with
RTK. But after debugging I was encountered with the message of
"--output' ('-o') option required". Could you please help me for running
this example and the other ones?
I don't know any thing about the texts in the gray boxes mentioned at
each link related to examples of RTK.
For example in the link of
http://wiki.openrtk.org/index.php/RTK/Examples/ElektaReconstruction
how I should use gengetopt for the instructions below?


2. Run the application to convert Elekta's geometry into RTKs (DICOM_UID
is contained in the subfolder name of the his files):

  rtkelektasynergygeometry \
    --image_db IMAGE.DBF \
    --frame_db FRAME.DBF \
    --dicom_uid 1.3.46.423632.135428.1351013645.166 \
    -o elektaGeometry

I would be appreciate if one could answer my question.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151130/b11ad4e2/attachment-0008.html>

From cyril.mory at uclouvain.be  Mon Nov 30 09:30:48 2015
From: cyril.mory at uclouvain.be (Cyril Mory)
Date: Mon, 30 Nov 2015 15:30:48 +0100
Subject: [Rtk-users] ElectaReconstruction
In-Reply-To: <CALChM12F4PuiLvgENg3Yyn7E+uZ7iPJ+GiY04z7VQ-90AS83EA@mail.gmail.com>
References: <CALChM12F4PuiLvgENg3Yyn7E+uZ7iPJ+GiY04z7VQ-90AS83EA@mail.gmail.com>
Message-ID: <565C5D98.1000309@uclouvain.be>

Hi, and welcome to RTK,

Gengetopt is the piece of software that parses the command line 
arguments in all RTK applications. You do not have to "use" it. You just 
need to give correct arguments on the command line.

The message "--output' ('-o') option required" means what it says : you 
need to provide the name of the file in which you want to store the 
geometry information generated by the application 
rtkelektasynergygeometry. If you just copy-pasted the command you found 
on the wiki, then something went wrong during the copy-paste. Try to run 
the following :

rtkelektasynergygeometry --image_db IMAGE.DBF --frame_db FRAME.DBF 
--dicom_uid 1.3.46.423632.135428.1351013645.166 -o elektaGeometry

I just removed the '\' and the useless spaces. You can do the same for 
all other command line examples and it should work.

Let us know if you keep encountering trouble.
Cyril


Le 30/11/2015 12:06, niloufar teyfouri a ?crit :
>
> I ran the application of Electa Reconstruction implemented by you with
> RTK. But after debugging I was encountered with the message of
> "--output' ('-o') option required". Could you please help me for running
> this example and the other ones?
> I don't know any thing about the texts in the gray boxes mentioned at
> each link related to examples of RTK.
> For example in the link of
> http://wiki.openrtk.org/index.php/RTK/Examples/ElektaReconstruction
> how I should use gengetopt for the instructions below?
>
>
> 2. Run the application to convert Elekta's geometry into RTKs (DICOM_UID
> is contained in the subfolder name of the his files):
>
> rtkelektasynergygeometry \
> --image_db IMAGE.DBF \
> --frame_db FRAME.DBF \
> --dicom_uid 1.3.46.423632.135428.1351013645.166 \
>     -o elektaGeometry
>
> I would be appreciate if one could answer my question.
>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151130/66741755/attachment-0008.html>

From j.mason at ed.ac.uk  Mon Nov 30 11:29:27 2015
From: j.mason at ed.ac.uk (Jonathan Mason)
Date: Mon, 30 Nov 2015 16:29:27 +0000
Subject: [Rtk-users] Preprocessing
Message-ID: <565C7967.4000401@ed.ac.uk>

Good afternoon RTK users,

I have access to "raw data" from a Varian OBI scanner, and have
experimented with RTK for performing its reconstruction. However, it is
not really "raw" in the sense that the coefficients are proportional to
the photon flux recorded at a given sensor, but is instead proportional
to the Hounsfield attenuation along that path. With this data, it means
that one can reconstruct using FDK and other iterative techniques, which
assume a linear model, but the connection to the underlying physics is
abstract.

The problem I then have when trying to develop reconstruction
techniques, is that I do not know whether I am really correcting for
physical distortions or just correcting for Varian's preprocessing,
which has been finely tuned for its own FDK method.

My question is whether anybody has dug into the steps that manufacturers
such as Varian or Elekta perform to arrive at these projection images?
And if they think that if reverse engineered, could provide a richer set
of information to facilitate advanced strategies.

Best wishes,

Jonathan Mason

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.



From simon.rit at creatis.insa-lyon.fr  Mon Nov 30 12:44:03 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Mon, 30 Nov 2015 18:44:03 +0100
Subject: [Rtk-users] ElectaReconstruction
In-Reply-To: <565C5D98.1000309@uclouvain.be>
References: <CALChM12F4PuiLvgENg3Yyn7E+uZ7iPJ+GiY04z7VQ-90AS83EA@mail.gmail.com>
 <565C5D98.1000309@uclouvain.be>
Message-ID: <CAF0oig2Zg96AZaRn9w9=F+LnLnyteTn5zS1rLguQ8WXiYhnnYg@mail.gmail.com>

Hi,
I think Cyril is right, it's not possible to use backslashes to put a
command line on several line with Windows command line. Can you confirm
this? If you confirm, we will correct the wiki.
Thanks,
Simon

On Mon, Nov 30, 2015 at 3:30 PM, Cyril Mory <cyril.mory at uclouvain.be> wrote:

> Hi, and welcome to RTK,
>
> Gengetopt is the piece of software that parses the command line arguments
> in all RTK applications. You do not have to "use" it. You just need to give
> correct arguments on the command line.
>
> The message "--output' ('-o') option required" means what it says : you
> need to provide the name of the file in which you want to store the
> geometry information generated by the application rtkelektasynergygeometry.
> If you just copy-pasted the command you found on the wiki, then something
> went wrong during the copy-paste. Try to run the following :
>
> rtkelektasynergygeometry --image_db IMAGE.DBF --frame_db FRAME.DBF
> --dicom_uid 1.3.46.423632.135428.1351013645.166 -o elektaGeometry
>
> I just removed the '\' and the useless spaces. You can do the same for all
> other command line examples and it should work.
>
> Let us know if you keep encountering trouble.
> Cyril
>
>
>
> Le 30/11/2015 12:06, niloufar teyfouri a ?crit :
>
>
> I ran the application of Electa Reconstruction implemented by you with
> RTK. But after debugging I was encountered with the message of
> "--output' ('-o') option required". Could you please help me for running
> this example and the other ones?
> I don't know any thing about the texts in the gray boxes mentioned at
> each link related to examples of RTK.
> For example in the link of
> http://wiki.openrtk.org/index.php/RTK/Examples/ElektaReconstruction
> how I should use gengetopt for the instructions below?
>
>
> 2. Run the application to convert Elekta's geometry into RTKs (DICOM_UID
> is contained in the subfolder name of the his files):
>
>   rtkelektasynergygeometry \
>     --image_db IMAGE.DBF \
>     --frame_db FRAME.DBF \
>     --dicom_uid 1.3.46.423632.135428.1351013645.166 \
>     -o elektaGeometry
>
> I would be appreciate if one could answer my question.
>
>
> _______________________________________________
> Rtk-users mailing listRtk-users at public.kitware.comhttp://public.kitware.com/mailman/listinfo/rtk-users
>
>
>
>
> ------------------------------
> [image: Avast logo] <https://www.avast.com/antivirus>
>
> L'absence de virus dans ce courrier ?lectronique a ?t? v?rifi?e par le
> logiciel antivirus Avast.
> www.avast.com <https://www.avast.com/antivirus>
>
>
> _______________________________________________
> 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/20151130/6d6dd6aa/attachment-0008.html>

From wuchao04 at gmail.com  Mon Nov 30 13:50:06 2015
From: wuchao04 at gmail.com (Chao Wu)
Date: Mon, 30 Nov 2015 19:50:06 +0100
Subject: [Rtk-users] Preprocessing
In-Reply-To: <565C7967.4000401@ed.ac.uk>
References: <565C7967.4000401@ed.ac.uk>
Message-ID: <CAH+sHrUFov5f=8h4-ePhC2xLraM3BxA9r12yfXdM3rrKPeqCBg@mail.gmail.com>

Hi Jonathan,

I do not quite understand your problem.
I think most information can be retrieved by the relationship between flux
(I) and attenuation (u):
I = I0 * exp (- integral(u * dL) )
Of course there are other effects like beam hardening and scattering
involved but this model is the basic.

Regards,
Chao

2015-11-30 17:29 GMT+01:00 Jonathan Mason <j.mason at ed.ac.uk>:

> Good afternoon RTK users,
>
> I have access to "raw data" from a Varian OBI scanner, and have
> experimented with RTK for performing its reconstruction. However, it is
> not really "raw" in the sense that the coefficients are proportional to
> the photon flux recorded at a given sensor, but is instead proportional
> to the Hounsfield attenuation along that path. With this data, it means
> that one can reconstruct using FDK and other iterative techniques, which
> assume a linear model, but the connection to the underlying physics is
> abstract.
>
> The problem I then have when trying to develop reconstruction
> techniques, is that I do not know whether I am really correcting for
> physical distortions or just correcting for Varian's preprocessing,
> which has been finely tuned for its own FDK method.
>
> My question is whether anybody has dug into the steps that manufacturers
> such as Varian or Elekta perform to arrive at these projection images?
> And if they think that if reverse engineered, could provide a richer set
> of information to facilitate advanced strategies.
>
> Best wishes,
>
> Jonathan Mason
>
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
> _______________________________________________
> 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/20151130/ccb833fe/attachment-0008.html>

From mdupont at cppm.in2p3.fr  Sun Nov  1 12:41:49 2015
From: mdupont at cppm.in2p3.fr (Mathieu Dupont)
Date: Sun, 01 Nov 2015 18:41:49 +0100
Subject: [Rtk-users] question about rtkDraw*ImageFilter
In-Reply-To: <56334CF2.8070902@cppm.in2p3.fr>
References: <5630EE01.5070900@cppm.in2p3.fr>
 <CAF0oig279ZWGJMFnJdXaPiYLPponadz_J-PVKt2z3iHiTRQ_gg@mail.gmail.com>
 <56334CF2.8070902@cppm.in2p3.fr>
Message-ID: <1539144.WPSdtJ8lhZ@marabunta>

Hello Simon, 

I started to implement what I suggested : 

https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawImageFilter.h
and 
https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawCylinderImageFilter.h

rtk::DrawCylinderImageFilter derives from rtk::DrawImageFilter and specializes 
it (by defaulting the template parameter TSpatialObject with 
DrawCylinderSpatialObject). 

By default, DrawCylinderImageFilter uses Add2 for filling output image (to be 
backward compatible (all tests pass)). I created Discard (I did not find 
equivalent in itk) functor in order to do what I wanted in my first email.  

I just implemented DrawCylinderImageFilter, the others will follow. 

What do you think about it ?

Le vendredi 30 octobre 2015, 11:56:50 Mathieu Dupont a ?crit :
> Hi,
> 
> In case of your first solution, you can not chain several
> Draw*ImageFilters. For example, if you want to create small cylinders in
> a big cylinder.
> 
> Your second solution is better.
> 
> One another solution can be a thing like itk:SpatialObject but more
> simpler. An rtk::SpatialObject which one function (isInside(point)). We
> create a rtkDrawImageFilter class and implement ThreadedGenerateData
> like this :
> 
> DrawImageFilter<InImage, OutImage, rtkSpatialObject,
> rtkFillFunctor>::ThreadedGenerateData(const OutputImageRegionType&
> outputRegionForThread,                 ThreadIdType itkNotUsed(threadId)
> {
> ...
> 
>   while( !itOut.IsAtEnd() )
>      {
>      this->GetInput()->TransformIndexToPhysicalPoint(itOut.GetIndex(),
> point);
> 
>     if(m_rtkSpatialObject.isInside(point)
>       itOut.Set(m_rtkFillFunctor(density, itIn.Get());
> ...
> }
> 
> 
> DrawConeImageFilter class can be a child of this new DrawImageFilter
> (with new methods like setAngle, SetRadius which will adjust the
> rtkConeSpatialObject)
> 
> This solution suppress duplicated code in
> Draw*ImageFilter::ThreadedGenerateData and makes easier implementation
> of another type of filling.
> 
> On 28/10/2015 20:52, Simon Rit wrote:
> > Hi Mathieu,
> > Thanks for pointing this out. I agree that it might not be the best
> > solution, yet one could argue that you could simply create a constant
> > image with 0 to do what you'd like from the current implementation. My
> > main problem is that I just tried to do what you suggest and some tests
> > then fail... which shows the obvious, it's not a backward compatible
> > change. I see two solutions:
> > - keep it as is and you use ConstantImageFilter + we remove useless add
> > filters,
> > - a more complex but maybe more elegant solution: add a third template
> > parameter for the operation that would allow the user to do what he'd
> > like in a functor. That's what's done with filters that derive from
> > itk::UnaryImageFilter
> > <http://www.itk.org/Doxygen/html/classitk_1_1UnaryFunctorImageFilter.html>
> > .
> > The default would be itk::Add2 but we could find or implement another
> > one that simply discards the pixel value.
> > What do you think?
> > Simon
> > 
> > PS: looking in the code, I just found that rtk::DrawConeImageFilter is
> > not consistent with the others, it was always setting to 0 outside...
> > that's been fixed!
> > 
> > On Wed, Oct 28, 2015 at 4:47 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr
> > 
> > <mailto:mdupont at cppm.in2p3.fr>> wrote:
> >     Hello everyone,
> >     
> >     I have a question/suggestion about the set of rtkDraw*ImageFilter.
> >     This filter are written as additive filters: for example, in
> >     rtkDrawEllipsoidImageFilter.txx, we can find
> >     
> >     for(..)
> >     
> >       itOut.Set( ellipsoid.density + itIn.Get() )
> >     
> >     instead of
> >     
> >     for(..)
> >     itOut.Set( ellipsoid.density )
> >     
> >     
> >     I think it can be more flexible the second option, because we can
> >     always associate Draw*ImageFilter and itkAddImageFilter to get an
> >     additive filter.
> >     
> >     Moreover, the  rtkDrawGeometricPhantomImageFilter class already uses
> >     itkAddImageFilter in order to have additive filters (which is
> >     redundant in current situation).
> >     
> >     What do you think ?
> >     
> >     
> >     
> >     
> >     
> >     Regards
> >     
> >     
> >     
> >     _______________________________________________
> >     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


From gnthibault at gmail.com  Mon Nov  2 08:08:42 2015
From: gnthibault at gmail.com (Notargiacomo Thibault)
Date: Mon, 2 Nov 2015 14:08:42 +0100
Subject: [Rtk-users] Problem with rtkGgoFunctions when importing series of
	images
Message-ID: <CAP+mR7Zw7WmRmEgVUTamNhS6m4S6ORvWFjRu1EANViPRJ7jtuQ@mail.gmail.com>

I recently experienced the following problem, when importing multiple tif
files inside a directory using itk::ImageSeriesReader:

[...]
code/rtkGgoFunctions.h: In instantiation of ?void
rtk::SetProjectionsReaderFromGgo(typename TProjectionsReaderType::Pointer,
const TArgsInfo&)
[...]
code/rtkGgoFunctions.h:121:61: error: no type named
?OutputImageDirectionType? in ?class
itk::ImageSeriesReader<itk::Image<short unsigned int, 3u> >?
   typename TProjectionsReaderType::OutputImageDirectionType direction;
[...]

It seems that, a new functionality added in rtkGgoFunctions.h (19/05/2015),
allowing to directly modify input images properties through command line,
like geometry (direction vector), assumes that the input image type defines
OutputImageDirectionType, but in the case of itk::ImageSeriesReader, it
does not.

Is this considered as a regression, or should the
SetProjectionsReaderFromGgo function be used with specific input image type
?

Thank you in advance for your help.

Kind regards

Thibault Notargiacomo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151102/6cad3583/attachment-0009.html>

From simon.rit at creatis.insa-lyon.fr  Mon Nov  2 08:58:24 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Mon, 2 Nov 2015 14:58:24 +0100
Subject: [Rtk-users] Problem with rtkGgoFunctions when importing series
	of images
In-Reply-To: <CAP+mR7Zw7WmRmEgVUTamNhS6m4S6ORvWFjRu1EANViPRJ7jtuQ@mail.gmail.com>
References: <CAP+mR7Zw7WmRmEgVUTamNhS6m4S6ORvWFjRu1EANViPRJ7jtuQ@mail.gmail.com>
Message-ID: <CAF0oig2bAidO4JR7pa_PUxOQm-X7JrEz8=ybGX3bskYJM9YRAQ@mail.gmail.com>

Hi Thibault,
SetProjectionsReaderFromGgo is a macro designed for the
rtk::ProjectionsReader
<http://www.openrtk.org/Doxygen/classrtk_1_1ProjectionsReader.html>, I'm
not surprised that it does not work with the itk::ImageSeriesReader. It's
not about the image type but about the filter type... We use this macro to
set many parameters specific to the rtk::ProjectionsReader
<http://www.openrtk.org/Doxygen/classrtk_1_1ProjectionsReader.html>. Since
a while, I have made have a common rtkinputprojections_section.ggo
<https://github.com/SimonRit/RTK/blob/master/applications/rtkinputprojections_section.ggo>
file for all the applications that use the rtk::ProjectionsReader.
If you don't want to use the rtk::ProjectionsReader but
itk::ImageSeriesReader (e.g., because it does a lot of automatic processing
that you don't want), you'll have to write your own code to set it up.
I hope this clarifies things.
Simon

On Mon, Nov 2, 2015 at 2:08 PM, Notargiacomo Thibault <gnthibault at gmail.com>
wrote:

> I recently experienced the following problem, when importing multiple tif
> files inside a directory using itk::ImageSeriesReader:
>
> [...]
> code/rtkGgoFunctions.h: In instantiation of ?void
> rtk::SetProjectionsReaderFromGgo(typename TProjectionsReaderType::Pointer,
> const TArgsInfo&)
> [...]
> code/rtkGgoFunctions.h:121:61: error: no type named
> ?OutputImageDirectionType? in ?class
> itk::ImageSeriesReader<itk::Image<short unsigned int, 3u> >?
>    typename TProjectionsReaderType::OutputImageDirectionType direction;
> [...]
>
> It seems that, a new functionality added in rtkGgoFunctions.h
> (19/05/2015), allowing to directly modify input images properties through
> command line, like geometry (direction vector), assumes that the input
> image type defines OutputImageDirectionType, but in the case of
> itk::ImageSeriesReader, it does not.
>
> Is this considered as a regression, or should the
> SetProjectionsReaderFromGgo function be used with specific input image type
> ?
>
> Thank you in advance for your help.
>
> Kind regards
>
> Thibault Notargiacomo
>
> _______________________________________________
> 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/20151102/ee7e2c17/attachment-0009.html>

From simon.rit at creatis.insa-lyon.fr  Wed Nov  4 16:38:18 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Wed, 4 Nov 2015 22:38:18 +0100
Subject: [Rtk-users] question about rtkDraw*ImageFilter
In-Reply-To: <1539144.WPSdtJ8lhZ@marabunta>
References: <5630EE01.5070900@cppm.in2p3.fr>
 <CAF0oig279ZWGJMFnJdXaPiYLPponadz_J-PVKt2z3iHiTRQ_gg@mail.gmail.com>
 <56334CF2.8070902@cppm.in2p3.fr> <1539144.WPSdtJ8lhZ@marabunta>
Message-ID: <CAF0oig3jBsfoadM_k6SYvOMwikOCNFmH19J7m1YJZx-RU0y+5g@mail.gmail.com>

Hi Mathieu,
Sorry, I'm very busy these days. I had a first quick look. Why not, it
looks a bit complicated but good. I would have a few things I would change
style wise, e.g., move DrawCylinderSpatialObject to
DrawCylinderImageFilter, create a common DrawQuadricSpatialObject that
would all have the same IsInside function, make DrawSpatialObjectpurely
virtual by not defining
IsInside etc. but those are details I can correct myself. Do you want to
finish what you started and I work from there or should I finish everything?
Simon

On Sun, Nov 1, 2015 at 6:41 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr>
wrote:

> Hello Simon,
>
> I started to implement what I suggested :
>
>
> https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawImageFilter.h
> and
>
> https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawCylinderImageFilter.h
>
> rtk::DrawCylinderImageFilter derives from rtk::DrawImageFilter and
> specializes
> it (by defaulting the template parameter TSpatialObject with
> DrawCylinderSpatialObject).
>
> By default, DrawCylinderImageFilter uses Add2 for filling output image (to
> be
> backward compatible (all tests pass)). I created Discard (I did not find
> equivalent in itk) functor in order to do what I wanted in my first email.
>
> I just implemented DrawCylinderImageFilter, the others will follow.
>
> What do you think about it ?
>
> Le vendredi 30 octobre 2015, 11:56:50 Mathieu Dupont a ?crit :
> > Hi,
> >
> > In case of your first solution, you can not chain several
> > Draw*ImageFilters. For example, if you want to create small cylinders in
> > a big cylinder.
> >
> > Your second solution is better.
> >
> > One another solution can be a thing like itk:SpatialObject but more
> > simpler. An rtk::SpatialObject which one function (isInside(point)). We
> > create a rtkDrawImageFilter class and implement ThreadedGenerateData
> > like this :
> >
> > DrawImageFilter<InImage, OutImage, rtkSpatialObject,
> > rtkFillFunctor>::ThreadedGenerateData(const OutputImageRegionType&
> > outputRegionForThread,                 ThreadIdType itkNotUsed(threadId)
> > {
> > ...
> >
> >   while( !itOut.IsAtEnd() )
> >      {
> >      this->GetInput()->TransformIndexToPhysicalPoint(itOut.GetIndex(),
> > point);
> >
> >     if(m_rtkSpatialObject.isInside(point)
> >       itOut.Set(m_rtkFillFunctor(density, itIn.Get());
> > ...
> > }
> >
> >
> > DrawConeImageFilter class can be a child of this new DrawImageFilter
> > (with new methods like setAngle, SetRadius which will adjust the
> > rtkConeSpatialObject)
> >
> > This solution suppress duplicated code in
> > Draw*ImageFilter::ThreadedGenerateData and makes easier implementation
> > of another type of filling.
> >
> > On 28/10/2015 20:52, Simon Rit wrote:
> > > Hi Mathieu,
> > > Thanks for pointing this out. I agree that it might not be the best
> > > solution, yet one could argue that you could simply create a constant
> > > image with 0 to do what you'd like from the current implementation. My
> > > main problem is that I just tried to do what you suggest and some tests
> > > then fail... which shows the obvious, it's not a backward compatible
> > > change. I see two solutions:
> > > - keep it as is and you use ConstantImageFilter + we remove useless add
> > > filters,
> > > - a more complex but maybe more elegant solution: add a third template
> > > parameter for the operation that would allow the user to do what he'd
> > > like in a functor. That's what's done with filters that derive from
> > > itk::UnaryImageFilter
> > > <
> http://www.itk.org/Doxygen/html/classitk_1_1UnaryFunctorImageFilter.html>
> > > .
> > > The default would be itk::Add2 but we could find or implement another
> > > one that simply discards the pixel value.
> > > What do you think?
> > > Simon
> > >
> > > PS: looking in the code, I just found that rtk::DrawConeImageFilter is
> > > not consistent with the others, it was always setting to 0 outside...
> > > that's been fixed!
> > >
> > > On Wed, Oct 28, 2015 at 4:47 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr
> > >
> > > <mailto:mdupont at cppm.in2p3.fr>> wrote:
> > >     Hello everyone,
> > >
> > >     I have a question/suggestion about the set of rtkDraw*ImageFilter.
> > >     This filter are written as additive filters: for example, in
> > >     rtkDrawEllipsoidImageFilter.txx, we can find
> > >
> > >     for(..)
> > >
> > >       itOut.Set( ellipsoid.density + itIn.Get() )
> > >
> > >     instead of
> > >
> > >     for(..)
> > >     itOut.Set( ellipsoid.density )
> > >
> > >
> > >     I think it can be more flexible the second option, because we can
> > >     always associate Draw*ImageFilter and itkAddImageFilter to get an
> > >     additive filter.
> > >
> > >     Moreover, the  rtkDrawGeometricPhantomImageFilter class already
> uses
> > >     itkAddImageFilter in order to have additive filters (which is
> > >     redundant in current situation).
> > >
> > >     What do you think ?
> > >
> > >
> > >
> > >
> > >
> > >     Regards
> > >
> > >
> > >
> > >     _______________________________________________
> > >     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/20151104/46314d97/attachment-0009.html>

From mdupont at cppm.in2p3.fr  Mon Nov  9 14:35:47 2015
From: mdupont at cppm.in2p3.fr (Mathieu Dupont)
Date: Mon, 09 Nov 2015 20:35:47 +0100
Subject: [Rtk-users] question about rtkDraw*ImageFilter
In-Reply-To: <CAF0oig3jBsfoadM_k6SYvOMwikOCNFmH19J7m1YJZx-RU0y+5g@mail.gmail.com>
References: <5630EE01.5070900@cppm.in2p3.fr> <1539144.WPSdtJ8lhZ@marabunta>
 <CAF0oig3jBsfoadM_k6SYvOMwikOCNFmH19J7m1YJZx-RU0y+5g@mail.gmail.com>
Message-ID: <5634494.U9CmFl2V79@marabunta>

hi, 

i will do this during this week and try to implement your remarks. 


Le mercredi 4 novembre 2015, 22:38:18 Simon Rit a ?crit :
> Hi Mathieu,
> Sorry, I'm very busy these days. I had a first quick look. Why not, it
> looks a bit complicated but good. I would have a few things I would change
> style wise, e.g., move DrawCylinderSpatialObject to
> DrawCylinderImageFilter, create a common DrawQuadricSpatialObject that
> would all have the same IsInside function, make DrawSpatialObjectpurely
> virtual by not defining
> IsInside etc. but those are details I can correct myself. Do you want to
> finish what you started and I work from there or should I finish everything?
> Simon
> 
> On Sun, Nov 1, 2015 at 6:41 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr>
> 
> wrote:
> > Hello Simon,
> > 
> > I started to implement what I suggested :
> > 
> > 
> > https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawImag
> > eFilter.h and
> > 
> > https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawCyli
> > nderImageFilter.h
> > 
> > rtk::DrawCylinderImageFilter derives from rtk::DrawImageFilter and
> > specializes
> > it (by defaulting the template parameter TSpatialObject with
> > DrawCylinderSpatialObject).
> > 
> > By default, DrawCylinderImageFilter uses Add2 for filling output image (to
> > be
> > backward compatible (all tests pass)). I created Discard (I did not find
> > equivalent in itk) functor in order to do what I wanted in my first email.
> > 
> > I just implemented DrawCylinderImageFilter, the others will follow.
> > 
> > What do you think about it ?
> > 
> > Le vendredi 30 octobre 2015, 11:56:50 Mathieu Dupont a ?crit :
> > > Hi,
> > > 
> > > In case of your first solution, you can not chain several
> > > Draw*ImageFilters. For example, if you want to create small cylinders in
> > > a big cylinder.
> > > 
> > > Your second solution is better.
> > > 
> > > One another solution can be a thing like itk:SpatialObject but more
> > > simpler. An rtk::SpatialObject which one function (isInside(point)). We
> > > create a rtkDrawImageFilter class and implement ThreadedGenerateData
> > > like this :
> > > 
> > > DrawImageFilter<InImage, OutImage, rtkSpatialObject,
> > > rtkFillFunctor>::ThreadedGenerateData(const OutputImageRegionType&
> > > outputRegionForThread,                 ThreadIdType itkNotUsed(threadId)
> > > {
> > > ...
> > > 
> > >   while( !itOut.IsAtEnd() )
> > >   
> > >      {
> > >      this->GetInput()->TransformIndexToPhysicalPoint(itOut.GetIndex(),
> > > 
> > > point);
> > > 
> > >     if(m_rtkSpatialObject.isInside(point)
> > >     
> > >       itOut.Set(m_rtkFillFunctor(density, itIn.Get());
> > > 
> > > ...
> > > }
> > > 
> > > 
> > > DrawConeImageFilter class can be a child of this new DrawImageFilter
> > > (with new methods like setAngle, SetRadius which will adjust the
> > > rtkConeSpatialObject)
> > > 
> > > This solution suppress duplicated code in
> > > Draw*ImageFilter::ThreadedGenerateData and makes easier implementation
> > > of another type of filling.
> > > 
> > > On 28/10/2015 20:52, Simon Rit wrote:
> > > > Hi Mathieu,
> > > > Thanks for pointing this out. I agree that it might not be the best
> > > > solution, yet one could argue that you could simply create a constant
> > > > image with 0 to do what you'd like from the current implementation. My
> > > > main problem is that I just tried to do what you suggest and some
> > > > tests
> > > > then fail... which shows the obvious, it's not a backward compatible
> > > > change. I see two solutions:
> > > > - keep it as is and you use ConstantImageFilter + we remove useless
> > > > add
> > > > filters,
> > > > - a more complex but maybe more elegant solution: add a third template
> > > > parameter for the operation that would allow the user to do what he'd
> > > > like in a functor. That's what's done with filters that derive from
> > > > itk::UnaryImageFilter
> > > > <
> > 
> > http://www.itk.org/Doxygen/html/classitk_1_1UnaryFunctorImageFilter.html>
> > 
> > > > .
> > > > The default would be itk::Add2 but we could find or implement another
> > > > one that simply discards the pixel value.
> > > > What do you think?
> > > > Simon
> > > > 
> > > > PS: looking in the code, I just found that rtk::DrawConeImageFilter is
> > > > not consistent with the others, it was always setting to 0 outside...
> > > > that's been fixed!
> > > > 
> > > > On Wed, Oct 28, 2015 at 4:47 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr
> > > > 
> > > > <mailto:mdupont at cppm.in2p3.fr>> wrote:
> > > >     Hello everyone,
> > > >     
> > > >     I have a question/suggestion about the set of rtkDraw*ImageFilter.
> > > >     This filter are written as additive filters: for example, in
> > > >     rtkDrawEllipsoidImageFilter.txx, we can find
> > > >     
> > > >     for(..)
> > > >     
> > > >       itOut.Set( ellipsoid.density + itIn.Get() )
> > > >     
> > > >     instead of
> > > >     
> > > >     for(..)
> > > >     itOut.Set( ellipsoid.density )
> > > >     
> > > >     
> > > >     I think it can be more flexible the second option, because we can
> > > >     always associate Draw*ImageFilter and itkAddImageFilter to get an
> > > >     additive filter.
> > > >     
> > > >     Moreover, the  rtkDrawGeometricPhantomImageFilter class already
> > 
> > uses
> > 
> > > >     itkAddImageFilter in order to have additive filters (which is
> > > >     redundant in current situation).
> > > >     
> > > >     What do you think ?
> > > >     
> > > >     
> > > >     
> > > >     
> > > >     
> > > >     Regards
> > > >     
> > > >     
> > > >     
> > > >     _______________________________________________
> > > >     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


From gnthibault at gmail.com  Tue Nov 10 07:39:46 2015
From: gnthibault at gmail.com (Notargiacomo Thibault)
Date: Tue, 10 Nov 2015 13:39:46 +0100
Subject: [Rtk-users] Understanding projection matrices management in
	rtkCudaBackProjectionImageFilter
Message-ID: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>

Hi all,

I am currently trying to use the "AddProjectionInRadians" method from the
ThreeDCircularProjectionGeometry class in RTK to import my geometry.

First things first, I would like to know if the information on this pdf are
still valid: http://www.openrtk.org/Doxygen/geometry.pdf

Because I used them to deduce the source offset and Projection offset from
my own matrix decomposition.

Notice that I don't want to use geometric informations coming from the
projection images themselves, so their geometric origin is assumed to be
(0,0,0) in my case.

In order to check if my geometry import method is correct, I print out one
of the intermediate form of the projection matrix used in the
backprojection process, in order to check if it is the same as in my own
implementation.

To do so, I print out one of the intermediate matrix that is generated in
rtkCudaBackProjectionImageFilter while launching a SART reconstruction for
instance.

I was surpised by the fact that, the matrix allowing the transformation
from 2D geometric world to 2D image index world, namely matrixIdxProj in
rtkCudaBackProjectionImageFilte.cxx
<http://www.openrtk.org/Doxygen/rtkCudaBackProjectionImageFilter_8cxx_source.html>
is not always the same along the reconstruction process ?

Here is the line that generates the matrix I don't understand:

for(unsigned int i=0; i<2; i++)
 //SR: 0.5 for 2D texture
  matrixIdxProj[i][2] =
-1*(this->GetInput(1)->GetBufferedRegion().GetIndex()[i])+0.5;

What I understand here, is that, we are generating a 2D translation matrix
embedded in a 3*3 matrix that allows to take into account two things
related to the 2D projection:

-If the internal behaviour of the imageContainer, allows buffering of only
a part of the image, beginning at index (i,j), this information will be
embeded in the projection matrix

-the ITK floating point addressing definition seems to differ from the one
from cuda (and openCV):
When I take a look at this page
<http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#texture-fetching>
I understand that the floating point indexing (0.5,0.5) in Cuda points to
the center of the pixel (0,0) hence a linear contribution of 100%, while it
seems that we must add a translation of (0.5,0.5) to the ITK geometric
framework in order to get the same behaviour.

In practice matrixIdxProj is based on a 3*3 identity matrix, where the
inner 2D translation (ie 2 first term of the last column) in my case are:
-in X, a random number between 10 and 150 plus 0.5
-in Y: always 0.5

I understand the 0.5 part, but why is there always a 0 offset in Y but a
random offset in X remains a mystery to me.

At first, I believed that each projection was splitted into multiple part,
each having a different X and Y offset.
But reconstructing using only one projection generates only one
backprojection operation, with a non zero offset in X, 123 in my case, for
an image of size 780 in X.

Do you think there is something wrong whith the values of matrixIdxProjI am
experiencing ?

Thank you in advance.

Kind regards

Thibault Notargiacomo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151110/fbd3fb46/attachment-0009.html>

From simon.rit at creatis.insa-lyon.fr  Tue Nov 10 08:21:29 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Tue, 10 Nov 2015 14:21:29 +0100
Subject: [Rtk-users] Understanding projection matrices management in
	rtkCudaBackProjectionImageFilter
In-Reply-To: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>
References: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>
Message-ID: <CAF0oig3muuH+1=eLZ66DJ22QcnsSrUKzRFS4RzDRvDJXNxAVXg@mail.gmail.com>

Hi Thibault,
You started digging in the code so that gets complicated. First thing
first, yes, the link you provide is still valid.
The offset in X is not random but computed in
BackProjectionImageFilter::GenerateInputRequestedRegion
<https://github.com/SimonRit/RTK/blob/master/code/rtkBackProjectionImageFilter.txx>.
The idea is that we request only the part of the projections we need to do
the backprojection. This optimizes the streaming (we only read from disk
what we need). If you use a huge volume (the test I'd suggest to validate
that I'm correct and there is nothing wrong with your code), then you'll
need the full projection and you will always get 0 in X as in Y. If you use
a small volume and do a computation projection per projection, you will get
a varying index depending on your input volume and the geometry for that
projection.
I think you understood the rest pretty well. Does that make sense or am I
missing something else?
Simon

On Tue, Nov 10, 2015 at 1:39 PM, Notargiacomo Thibault <gnthibault at gmail.com
> wrote:

> Hi all,
>
> I am currently trying to use the "AddProjectionInRadians" method from the
> ThreeDCircularProjectionGeometry class in RTK to import my geometry.
>
> First things first, I would like to know if the information on this pdf
> are still valid: http://www.openrtk.org/Doxygen/geometry.pdf
>
> Because I used them to deduce the source offset and Projection offset from
> my own matrix decomposition.
>
> Notice that I don't want to use geometric informations coming from the
> projection images themselves, so their geometric origin is assumed to be
> (0,0,0) in my case.
>
> In order to check if my geometry import method is correct, I print out one
> of the intermediate form of the projection matrix used in the
> backprojection process, in order to check if it is the same as in my own
> implementation.
>
> To do so, I print out one of the intermediate matrix that is generated in
> rtkCudaBackProjectionImageFilter while launching a SART reconstruction for
> instance.
>
> I was surpised by the fact that, the matrix allowing the transformation
> from 2D geometric world to 2D image index world, namely matrixIdxProj in
> rtkCudaBackProjectionImageFilte.cxx
> <http://www.openrtk.org/Doxygen/rtkCudaBackProjectionImageFilter_8cxx_source.html>
> is not always the same along the reconstruction process ?
>
> Here is the line that generates the matrix I don't understand:
>
> for(unsigned int i=0; i<2; i++)
>  //SR: 0.5 for 2D texture
>   matrixIdxProj[i][2] =
> -1*(this->GetInput(1)->GetBufferedRegion().GetIndex()[i])+0.5;
>
> What I understand here, is that, we are generating a 2D translation matrix
> embedded in a 3*3 matrix that allows to take into account two things
> related to the 2D projection:
>
> -If the internal behaviour of the imageContainer, allows buffering of only
> a part of the image, beginning at index (i,j), this information will be
> embeded in the projection matrix
>
> -the ITK floating point addressing definition seems to differ from the one
> from cuda (and openCV):
> When I take a look at this page
> <http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#texture-fetching>
> I understand that the floating point indexing (0.5,0.5) in Cuda points to
> the center of the pixel (0,0) hence a linear contribution of 100%, while it
> seems that we must add a translation of (0.5,0.5) to the ITK geometric
> framework in order to get the same behaviour.
>
> In practice matrixIdxProj is based on a 3*3 identity matrix, where the
> inner 2D translation (ie 2 first term of the last column) in my case are:
> -in X, a random number between 10 and 150 plus 0.5
> -in Y: always 0.5
>
> I understand the 0.5 part, but why is there always a 0 offset in Y but a
> random offset in X remains a mystery to me.
>
> At first, I believed that each projection was splitted into multiple part,
> each having a different X and Y offset.
> But reconstructing using only one projection generates only one
> backprojection operation, with a non zero offset in X, 123 in my case, for
> an image of size 780 in X.
>
> Do you think there is something wrong whith the values of matrixIdxProjI
> am experiencing ?
>
> Thank you in advance.
>
> Kind regards
>
> Thibault Notargiacomo
>
> _______________________________________________
> 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/20151110/8b9b86e6/attachment-0009.html>

From simon.rit at creatis.insa-lyon.fr  Tue Nov 10 09:03:52 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Tue, 10 Nov 2015 15:03:52 +0100
Subject: [Rtk-users] Understanding projection matrices management in
	rtkCudaBackProjectionImageFilter
In-Reply-To: <CAP+mR7ZLJV8V5dMOW_jgM5G2-kCZhy8o0tB19685LGo-1bxLUg@mail.gmail.com>
References: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>
 <CAF0oig3muuH+1=eLZ66DJ22QcnsSrUKzRFS4RzDRvDJXNxAVXg@mail.gmail.com>
 <CAP+mR7ZLJV8V5dMOW_jgM5G2-kCZhy8o0tB19685LGo-1bxLUg@mail.gmail.com>
Message-ID: <CAF0oig3fALRnZNCJ53+TsSjBm7raRC_mqahWEU6x+D+zxwOnVQ@mail.gmail.com>

A small correction: it's actually the amount of data pre-processed (read
from disk + all the processing before backprojection) but that should
change nothing to what is backprojected.
I remembered something that can help you: you may want to run
UpdateLargestPossibleRegion() to the projections (input 1 of the
BackProjectImageFilter) before backprojection to avoid this and make things
clearer instead of using a large volume as I was suggesting before.
Simon

On Tue, Nov 10, 2015 at 2:34 PM, Notargiacomo Thibault <gnthibault at gmail.com
> wrote:

> Ok, using geometric information to reduce the amount of data to be
> backprojected is pretty clever ;)
> This explains the "random" index I was asking about in my previous
> question, I now know what it is used for and continue my debugging process.
>
> Kind regards
>
> Thibault Notargiacomo
>
> 2015-11-10 14:21 GMT+01:00 Simon Rit <simon.rit at creatis.insa-lyon.fr>:
>
>> Hi Thibault,
>> You started digging in the code so that gets complicated. First thing
>> first, yes, the link you provide is still valid.
>> The offset in X is not random but computed in
>> BackProjectionImageFilter::GenerateInputRequestedRegion
>> <https://github.com/SimonRit/RTK/blob/master/code/rtkBackProjectionImageFilter.txx>.
>> The idea is that we request only the part of the projections we need to do
>> the backprojection. This optimizes the streaming (we only read from disk
>> what we need). If you use a huge volume (the test I'd suggest to validate
>> that I'm correct and there is nothing wrong with your code), then you'll
>> need the full projection and you will always get 0 in X as in Y. If you use
>> a small volume and do a computation projection per projection, you will get
>> a varying index depending on your input volume and the geometry for that
>> projection.
>> I think you understood the rest pretty well. Does that make sense or am I
>> missing something else?
>> Simon
>>
>> On Tue, Nov 10, 2015 at 1:39 PM, Notargiacomo Thibault <
>> gnthibault at gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> I am currently trying to use the "AddProjectionInRadians" method from
>>> the ThreeDCircularProjectionGeometry class in RTK to import my geometry.
>>>
>>> First things first, I would like to know if the information on this pdf
>>> are still valid: http://www.openrtk.org/Doxygen/geometry.pdf
>>>
>>> Because I used them to deduce the source offset and Projection offset
>>> from my own matrix decomposition.
>>>
>>> Notice that I don't want to use geometric informations coming from the
>>> projection images themselves, so their geometric origin is assumed to be
>>> (0,0,0) in my case.
>>>
>>> In order to check if my geometry import method is correct, I print out
>>> one of the intermediate form of the projection matrix used in the
>>> backprojection process, in order to check if it is the same as in my own
>>> implementation.
>>>
>>> To do so, I print out one of the intermediate matrix that is generated
>>> in rtkCudaBackProjectionImageFilter while launching a SART reconstruction
>>> for instance.
>>>
>>> I was surpised by the fact that, the matrix allowing the transformation
>>> from 2D geometric world to 2D image index world, namely matrixIdxProj in
>>> rtkCudaBackProjectionImageFilte.cxx
>>> <http://www.openrtk.org/Doxygen/rtkCudaBackProjectionImageFilter_8cxx_source.html>
>>> is not always the same along the reconstruction process ?
>>>
>>> Here is the line that generates the matrix I don't understand:
>>>
>>> for(unsigned int i=0; i<2; i++)
>>>  //SR: 0.5 for 2D texture
>>>   matrixIdxProj[i][2] =
>>> -1*(this->GetInput(1)->GetBufferedRegion().GetIndex()[i])+0.5;
>>>
>>> What I understand here, is that, we are generating a 2D translation
>>> matrix embedded in a 3*3 matrix that allows to take into account two things
>>> related to the 2D projection:
>>>
>>> -If the internal behaviour of the imageContainer, allows buffering of
>>> only a part of the image, beginning at index (i,j), this information will
>>> be embeded in the projection matrix
>>>
>>> -the ITK floating point addressing definition seems to differ from the
>>> one from cuda (and openCV):
>>> When I take a look at this page
>>> <http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#texture-fetching>
>>> I understand that the floating point indexing (0.5,0.5) in Cuda points to
>>> the center of the pixel (0,0) hence a linear contribution of 100%, while it
>>> seems that we must add a translation of (0.5,0.5) to the ITK geometric
>>> framework in order to get the same behaviour.
>>>
>>> In practice matrixIdxProj is based on a 3*3 identity matrix, where the
>>> inner 2D translation (ie 2 first term of the last column) in my case are:
>>> -in X, a random number between 10 and 150 plus 0.5
>>> -in Y: always 0.5
>>>
>>> I understand the 0.5 part, but why is there always a 0 offset in Y but a
>>> random offset in X remains a mystery to me.
>>>
>>> At first, I believed that each projection was splitted into multiple
>>> part, each having a different X and Y offset.
>>> But reconstructing using only one projection generates only one
>>> backprojection operation, with a non zero offset in X, 123 in my case, for
>>> an image of size 780 in X.
>>>
>>> Do you think there is something wrong whith the values of matrixIdxProjI
>>> am experiencing ?
>>>
>>> Thank you in advance.
>>>
>>> Kind regards
>>>
>>> Thibault Notargiacomo
>>>
>>> _______________________________________________
>>> 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/20151110/d8913dc3/attachment-0009.html>

From simon.rit at creatis.insa-lyon.fr  Tue Nov 10 11:21:29 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Tue, 10 Nov 2015 17:21:29 +0100
Subject: [Rtk-users] Understanding projection matrices management in
	rtkCudaBackProjectionImageFilter
In-Reply-To: <CAP+mR7ZKqnbUyRHyHkti=3sZd2dEw-OUV6oqsqcga55=tcQ9OQ@mail.gmail.com>
References: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>
 <CAF0oig3muuH+1=eLZ66DJ22QcnsSrUKzRFS4RzDRvDJXNxAVXg@mail.gmail.com>
 <CAP+mR7ZLJV8V5dMOW_jgM5G2-kCZhy8o0tB19685LGo-1bxLUg@mail.gmail.com>
 <CAF0oig3fALRnZNCJ53+TsSjBm7raRC_mqahWEU6x+D+zxwOnVQ@mail.gmail.com>
 <CAP+mR7ZKqnbUyRHyHkti=3sZd2dEw-OUV6oqsqcga55=tcQ9OQ@mail.gmail.com>
Message-ID: <CAF0oig12pRGBfgiCQMCwTG7zX_3vz87AEWhTQ4EYaVbH_m0t5Q@mail.gmail.com>

Your welcome (I cc the mailing list for info).
Simon

On Tue, Nov 10, 2015 at 5:03 PM, Notargiacomo Thibault <gnthibault at gmail.com
> wrote:

> I replaced the original Update by the "UpdateLargestPossibleRegion" to the
> divideFilter in SART (I bypassed displacedDetectorFilter for now) and it
> work as expected, I have now a "clean" matProjIdx.
>
> Thank you for your help !
>
> 2015-11-10 15:03 GMT+01:00 Simon Rit <simon.rit at creatis.insa-lyon.fr>:
>
>> A small correction: it's actually the amount of data pre-processed (read
>> from disk + all the processing before backprojection) but that should
>> change nothing to what is backprojected.
>> I remembered something that can help you: you may want to run
>> UpdateLargestPossibleRegion() to the projections (input 1 of the
>> BackProjectImageFilter) before backprojection to avoid this and make things
>> clearer instead of using a large volume as I was suggesting before.
>> Simon
>>
>> On Tue, Nov 10, 2015 at 2:34 PM, Notargiacomo Thibault <
>> gnthibault at gmail.com> wrote:
>>
>>> Ok, using geometric information to reduce the amount of data to be
>>> backprojected is pretty clever ;)
>>> This explains the "random" index I was asking about in my previous
>>> question, I now know what it is used for and continue my debugging process.
>>>
>>> Kind regards
>>>
>>> Thibault Notargiacomo
>>>
>>> 2015-11-10 14:21 GMT+01:00 Simon Rit <simon.rit at creatis.insa-lyon.fr>:
>>>
>>>> Hi Thibault,
>>>> You started digging in the code so that gets complicated. First thing
>>>> first, yes, the link you provide is still valid.
>>>> The offset in X is not random but computed in
>>>> BackProjectionImageFilter::GenerateInputRequestedRegion
>>>> <https://github.com/SimonRit/RTK/blob/master/code/rtkBackProjectionImageFilter.txx>.
>>>> The idea is that we request only the part of the projections we need to do
>>>> the backprojection. This optimizes the streaming (we only read from disk
>>>> what we need). If you use a huge volume (the test I'd suggest to validate
>>>> that I'm correct and there is nothing wrong with your code), then you'll
>>>> need the full projection and you will always get 0 in X as in Y. If you use
>>>> a small volume and do a computation projection per projection, you will get
>>>> a varying index depending on your input volume and the geometry for that
>>>> projection.
>>>> I think you understood the rest pretty well. Does that make sense or am
>>>> I missing something else?
>>>> Simon
>>>>
>>>> On Tue, Nov 10, 2015 at 1:39 PM, Notargiacomo Thibault <
>>>> gnthibault at gmail.com> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I am currently trying to use the "AddProjectionInRadians" method from
>>>>> the ThreeDCircularProjectionGeometry class in RTK to import my geometry.
>>>>>
>>>>> First things first, I would like to know if the information on this
>>>>> pdf are still valid: http://www.openrtk.org/Doxygen/geometry.pdf
>>>>>
>>>>> Because I used them to deduce the source offset and Projection offset
>>>>> from my own matrix decomposition.
>>>>>
>>>>> Notice that I don't want to use geometric informations coming from the
>>>>> projection images themselves, so their geometric origin is assumed to be
>>>>> (0,0,0) in my case.
>>>>>
>>>>> In order to check if my geometry import method is correct, I print out
>>>>> one of the intermediate form of the projection matrix used in the
>>>>> backprojection process, in order to check if it is the same as in my own
>>>>> implementation.
>>>>>
>>>>> To do so, I print out one of the intermediate matrix that is generated
>>>>> in rtkCudaBackProjectionImageFilter while launching a SART reconstruction
>>>>> for instance.
>>>>>
>>>>> I was surpised by the fact that, the matrix allowing the
>>>>> transformation from 2D geometric world to 2D image index world, namely
>>>>> matrixIdxProj in rtkCudaBackProjectionImageFilte.cxx
>>>>> <http://www.openrtk.org/Doxygen/rtkCudaBackProjectionImageFilter_8cxx_source.html>
>>>>> is not always the same along the reconstruction process ?
>>>>>
>>>>> Here is the line that generates the matrix I don't understand:
>>>>>
>>>>> for(unsigned int i=0; i<2; i++)
>>>>>  //SR: 0.5 for 2D texture
>>>>>   matrixIdxProj[i][2] =
>>>>> -1*(this->GetInput(1)->GetBufferedRegion().GetIndex()[i])+0.5;
>>>>>
>>>>> What I understand here, is that, we are generating a 2D translation
>>>>> matrix embedded in a 3*3 matrix that allows to take into account two things
>>>>> related to the 2D projection:
>>>>>
>>>>> -If the internal behaviour of the imageContainer, allows buffering of
>>>>> only a part of the image, beginning at index (i,j), this information will
>>>>> be embeded in the projection matrix
>>>>>
>>>>> -the ITK floating point addressing definition seems to differ from the
>>>>> one from cuda (and openCV):
>>>>> When I take a look at this page
>>>>> <http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#texture-fetching>
>>>>> I understand that the floating point indexing (0.5,0.5) in Cuda points to
>>>>> the center of the pixel (0,0) hence a linear contribution of 100%, while it
>>>>> seems that we must add a translation of (0.5,0.5) to the ITK geometric
>>>>> framework in order to get the same behaviour.
>>>>>
>>>>> In practice matrixIdxProj is based on a 3*3 identity matrix, where
>>>>> the inner 2D translation (ie 2 first term of the last column) in my case
>>>>> are:
>>>>> -in X, a random number between 10 and 150 plus 0.5
>>>>> -in Y: always 0.5
>>>>>
>>>>> I understand the 0.5 part, but why is there always a 0 offset in Y but
>>>>> a random offset in X remains a mystery to me.
>>>>>
>>>>> At first, I believed that each projection was splitted into multiple
>>>>> part, each having a different X and Y offset.
>>>>> But reconstructing using only one projection generates only one
>>>>> backprojection operation, with a non zero offset in X, 123 in my case, for
>>>>> an image of size 780 in X.
>>>>>
>>>>> Do you think there is something wrong whith the values of matrixIdxProjI
>>>>> am experiencing ?
>>>>>
>>>>> Thank you in advance.
>>>>>
>>>>> Kind regards
>>>>>
>>>>> Thibault Notargiacomo
>>>>>
>>>>> _______________________________________________
>>>>> 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/20151110/b7eba683/attachment-0009.html>

From theday79 at gmail.com  Wed Nov 11 13:50:45 2015
From: theday79 at gmail.com (Yang K Park)
Date: Wed, 11 Nov 2015 13:50:45 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after  a recent update
Message-ID: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>

Hi all,

 

I?ve updated rtk with the up-to-date revision and have encountered a couple of problems.

 

1.       Compile error: RTK couldn?t find itkMacro.h while it compiled rtkCudaUtilities.hcu. It was solved by a minor fetching:

#include <itkMacro.h>   --> #include "itkMacro.h" in rtkCudaUtilities.hcu

 

2.       Output of rtkfdk with CUDA was not the same as before. It was very blurry as seen in the attached image.

a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.

 

 

I?m using VS2013 with win7, itk4.8.1.

 

The command line I used was :

rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware cuda --pad 1 --hann 5 --hannY 5

 

Does anyone have any idea about this?

 

Thanks.

 

Yang

 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151111/b1c7df5f/attachment-0009.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 16577 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151111/b1c7df5f/attachment-0009.png>

From simon.rit at creatis.insa-lyon.fr  Wed Nov 11 16:15:49 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Wed, 11 Nov 2015 22:15:49 +0100
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
Message-ID: <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>

Hi,
I didn't manage to reproduce the two problems on linux with the same
ITK version.
For point 1, did you copy itkMacro.h by hand? Because I don't see how
replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not
in the same folder as rtkCudaUtilities.hcu
For point 2, no clue. Do you use FFTW? It looks like a ramp filter
issue. Can you try rtkramp --path projPath --regexp .*.his, with and
without --hardware cuda? Maybe you can provide your geometry file in
case it's a specific geometric issue.
Simon

On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
> Hi all,
>
>
>
> I?ve updated rtk with the up-to-date revision and have encountered a couple
> of problems.
>
>
>
> 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
> rtkCudaUtilities.hcu. It was solved by a minor fetching:
>
> #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>
>
>
> 2.       Output of rtkfdk with CUDA was not the same as before. It was very
> blurry as seen in the attached image.
>
> a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>
>
>
>
>
> I?m using VS2013 with win7, itk4.8.1.
>
>
>
> The command line I used was :
>
> rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his --output
> output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware cuda --pad 1
> --hann 5 --hannY 5
>
>
>
> Does anyone have any idea about this?
>
>
>
> Thanks.
>
>
>
> Yang
>
>
>
>
> _______________________________________________
> Rtk-users mailing list
> Rtk-users at public.kitware.com
> http://public.kitware.com/mailman/listinfo/rtk-users
>


From theday79 at gmail.com  Thu Nov 12 17:39:38 2015
From: theday79 at gmail.com (Yang K Park)
Date: Thu, 12 Nov 2015 17:39:38 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
Message-ID: <000001d11d9b$04142320$0c3c6960$@gmail.com>

Hi Simon,

 

Thanks for the advice. The current RTK was compiled with FFTW to use the phase extraction feature from Amsterdam shroud.

 

Regarding your suggestions,

 

1)      rtkramp w/ or w/o CUDA:

(command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda --output Ramp_wCUDA.mha? )

 

Then, I have encountered following error.

?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that input requested and buffered regions are equal.?

 



 

Without CUDA, it was successfully done.

 

2)      I?ve re-compiled ITK w/o FFTW and built RTK again. rtkfdk worked fine.

-          I?ve also repeated ?rtkramp+CUDA? with this rtk version and the error was same as above.

 

In conclusion, my FFTW seems to affect CUDA-based fdk reconstruction only.

But I do need FFTW for the phase extraction. What should I do?

 

Thanks.

 

Yang

 

 

-----Original Message-----
From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit
Sent: Wednesday, November 11, 2015 4:16 PM
To: Yang K Park <theday79 at gmail.com>
Cc: rtk-users at openrtk.org
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

I didn't manage to reproduce the two problems on linux with the same ITK version.

For point 1, did you copy itkMacro.h by hand? Because I don't see how replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW? It looks like a ramp filter issue. Can you try rtkramp --path projPath --regexp .*.his, with and without --hardware cuda? Maybe you can provide your geometry file in case it's a specific geometric issue.

Simon

 

On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park < <mailto:theday79 at gmail.com> theday79 at gmail.com> wrote:

> Hi all,

> 

> 

> 

> I?ve updated rtk with the up-to-date revision and have encountered a 

> couple of problems.

> 

> 

> 

> 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled

> rtkCudaUtilities.hcu. It was solved by a minor fetching:

> 

> #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu

> 

> 

> 

> 2.       Output of rtkfdk with CUDA was not the same as before. It was very

> blurry as seen in the attached image.

> 

> a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.

> 

> 

> 

> 

> 

> I?m using VS2013 with win7, itk4.8.1.

> 

> 

> 

> The command line I used was :

> 

> rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his 

> --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware 

> cuda --pad 1 --hann 5 --hannY 5

> 

> 

> 

> Does anyone have any idea about this?

> 

> 

> 

> Thanks.

> 

> 

> 

> Yang

> 

> 

> 

> 

> _______________________________________________

> Rtk-users mailing list

>  <mailto: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/20151112/4e0825dc/attachment-0009.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151112/4e0825dc/attachment-0009.png>

From simon.rit at creatis.insa-lyon.fr  Thu Nov 12 17:58:42 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Thu, 12 Nov 2015 23:58:42 +0100
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <000001d11d9b$04142320$0c3c6960$@gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
Message-ID: <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>

Hi,
Ok. Can you try rtkramp with only one projection? Then you shouldn't
encounter this regions issue (that should be solved one day but that's a
different story).
Can you also indicate which version of CUDA you're using?
FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft for
the FFT of the projections. So if they are not in the same format, you're
in trouble and that might be the issue here... The weird part is that I
didn't reproduce this problem on linux (with and without FFTW) but it might
be a CUDA version difference. I'll give it another try tomorrow when you
provide the CUDA version.
Thanks again for reporting the issue,
Simon

On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com> wrote:

> Hi Simon,
>
>
>
> Thanks for the advice. The current RTK was compiled with FFTW to use the
> phase extraction feature from Amsterdam shroud.
>
>
>
> Regarding your suggestions,
>
>
>
> 1)      rtkramp w/ or w/o CUDA:
>
> (command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda
> --output Ramp_wCUDA.mha? )
>
>
>
> Then, I have encountered following error.
>
> ?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that
> input requested and buffered regions are equal.?
>
>
>
>
>
> Without CUDA, it was successfully done.
>
>
>
> 2)      I?ve re-compiled *ITK w/o FFTW* and built RTK again. r*tkfdk
> worked fine.*
>
> -          I?ve also repeated ?rtkramp+CUDA? with this rtk version and
> the error was same as above.
>
>
>
> In conclusion, my *FFTW seems to affect CUDA-based fdk reconstruction
> only*.
>
> But I do need FFTW for the phase extraction. What should I do?
>
>
>
> Thanks.
>
>
>
> Yang
>
>
>
>
>
> -----Original Message-----
> From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon
> Rit
> Sent: Wednesday, November 11, 2015 4:16 PM
> To: Yang K Park <theday79 at gmail.com>
> Cc: rtk-users at openrtk.org
> Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
> update
>
>
>
> Hi,
>
> I didn't manage to reproduce the two problems on linux with the same ITK
> version.
>
> For point 1, did you copy itkMacro.h by hand? Because I don't see how
> replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the
> same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW?
> It looks like a ramp filter issue. Can you try rtkramp --path projPath
> --regexp .*.his, with and without --hardware cuda? Maybe you can provide
> your geometry file in case it's a specific geometric issue.
>
> Simon
>
>
>
> On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
>
> > Hi all,
>
> >
>
> >
>
> >
>
> > I?ve updated rtk with the up-to-date revision and have encountered a
>
> > couple of problems.
>
> >
>
> >
>
> >
>
> > 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
>
> > rtkCudaUtilities.hcu. It was solved by a minor fetching:
>
> >
>
> > #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>
> >
>
> >
>
> >
>
> > 2.       Output of rtkfdk with CUDA was not the same as before. It was
> very
>
> > blurry as seen in the attached image.
>
> >
>
> > a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > I?m using VS2013 with win7, itk4.8.1.
>
> >
>
> >
>
> >
>
> > The command line I used was :
>
> >
>
> > rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his
>
> > --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware
>
> > cuda --pad 1 --hann 5 --hannY 5
>
> >
>
> >
>
> >
>
> > Does anyone have any idea about this?
>
> >
>
> >
>
> >
>
> > Thanks.
>
> >
>
> >
>
> >
>
> > Yang
>
> >
>
> >
>
> >
>
> >
>
> > _______________________________________________
>
> > 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/20151112/e7c15ff8/attachment-0009.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151112/e7c15ff8/attachment-0009.png>

From theday79 at gmail.com  Mon Nov 16 09:54:01 2015
From: theday79 at gmail.com (Yang K Park)
Date: Mon, 16 Nov 2015 09:54:01 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
Message-ID: <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>

Hi Simon,

 

Sorry for the late response.

 

As you suggested, I?ve tried rtkramp+CUDA with only one projection and it was successfully done for both w/ FFTW and w/o FFTW.

(Two results were exactly same.)

 

Regarding  the CUDA version, I?m using v6.5.

 

Thanks a lot for the help!

 

Yang

 

 

From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit
Sent: Thursday, November 12, 2015 5:59 PM
To: Yang K Park <theday79 at gmail.com>
Cc: rtk-users at openrtk.org
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

Ok. Can you try rtkramp with only one projection? Then you shouldn't encounter this regions issue (that should be solved one day but that's a different story). 

Can you also indicate which version of CUDA you're using?

FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft for the FFT of the projections. So if they are not in the same format, you're in trouble and that might be the issue here... The weird part is that I didn't reproduce this problem on linux (with and without FFTW) but it might be a CUDA version difference. I'll give it another try tomorrow when you provide the CUDA version.

Thanks again for reporting the issue,
Simon

 

On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> > wrote:

Hi Simon,

 

Thanks for the advice. The current RTK was compiled with FFTW to use the phase extraction feature from Amsterdam shroud.

 

Regarding your suggestions,

 

1)      rtkramp w/ or w/o CUDA:

(command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda --output Ramp_wCUDA.mha? )

 

Then, I have encountered following error.

?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that input requested and buffered regions are equal.?

 



 

Without CUDA, it was successfully done.

 

2)      I?ve re-compiled ITK w/o FFTW and built RTK again. rtkfdk worked fine.

-          I?ve also repeated ?rtkramp+CUDA? with this rtk version and the error was same as above.

 

In conclusion, my FFTW seems to affect CUDA-based fdk reconstruction only.

But I do need FFTW for the phase extraction. What should I do?

 

Thanks.

 

Yang

 

 

-----Original Message-----
From: simon.rit at gmail.com <mailto:simon.rit at gmail.com>  [mailto:simon.rit at gmail.com <mailto:simon.rit at gmail.com> ] On Behalf Of Simon Rit
Sent: Wednesday, November 11, 2015 4:16 PM
To: Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> >
Cc: rtk-users at openrtk.org <mailto:rtk-users at openrtk.org> 
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

I didn't manage to reproduce the two problems on linux with the same ITK version.

For point 1, did you copy itkMacro.h by hand? Because I don't see how replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW? It looks like a ramp filter issue. Can you try rtkramp --path projPath --regexp .*.his, with and without --hardware cuda? Maybe you can provide your geometry file in case it's a specific geometric issue.

Simon

 

On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park < <mailto:theday79 at gmail.com> theday79 at gmail.com> wrote:

> Hi all,

> 

> 

> 

> I?ve updated rtk with the up-to-date revision and have encountered a 

> couple of problems.

> 

> 

> 

> 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled

> rtkCudaUtilities.hcu. It was solved by a minor fetching:

> 

> #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu

> 

> 

> 

> 2.       Output of rtkfdk with CUDA was not the same as before. It was very

> blurry as seen in the attached image.

> 

> a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.

> 

> 

> 

> 

> 

> I?m using VS2013 with win7, itk4.8.1.

> 

> 

> 

> The command line I used was :

> 

> rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his 

> --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware 

> cuda --pad 1 --hann 5 --hannY 5

> 

> 

> 

> Does anyone have any idea about this?

> 

> 

> 

> Thanks.

> 

> 

> 

> Yang

> 

> 

> 

> 

> _______________________________________________

> Rtk-users mailing list

>  <mailto: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/20151116/e77c2f96/attachment-0009.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151116/e77c2f96/attachment-0009.png>

From simon.rit at creatis.insa-lyon.fr  Mon Nov 16 10:07:46 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Mon, 16 Nov 2015 16:07:46 +0100
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
 <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
Message-ID: <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>

Hi,
Thanks. It's really weird... When you run the tests with FFTW (compiling
the "test" target), do they fail?
Can you provide your geometry file? It might be specific to this geometry.
Thanks again for looking into this issue, we'll find what's the problem.
Simon

On Mon, Nov 16, 2015 at 3:54 PM, Yang K Park <theday79 at gmail.com> wrote:

> Hi Simon,
>
>
>
> Sorry for the late response.
>
>
>
> As you suggested, I?ve tried rtkramp+CUDA with only one projection and it
> was successfully done for both w/ FFTW and w/o FFTW.
>
> (Two results were exactly same.)
>
>
>
> Regarding  the CUDA version, I?m using v6.5.
>
>
>
> Thanks a lot for the help!
>
>
>
> Yang
>
>
>
>
>
> *From:* simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of *Simon
> Rit
> *Sent:* Thursday, November 12, 2015 5:59 PM
>
> *To:* Yang K Park <theday79 at gmail.com>
> *Cc:* rtk-users at openrtk.org
> *Subject:* Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
> update
>
>
>
> Hi,
>
> Ok. Can you try rtkramp with only one projection? Then you shouldn't
> encounter this regions issue (that should be solved one day but that's a
> different story).
>
> Can you also indicate which version of CUDA you're using?
>
> FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft for
> the FFT of the projections. So if they are not in the same format, you're
> in trouble and that might be the issue here... The weird part is that I
> didn't reproduce this problem on linux (with and without FFTW) but it might
> be a CUDA version difference. I'll give it another try tomorrow when you
> provide the CUDA version.
>
> Thanks again for reporting the issue,
> Simon
>
>
>
> On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com> wrote:
>
> Hi Simon,
>
>
>
> Thanks for the advice. The current RTK was compiled with FFTW to use the
> phase extraction feature from Amsterdam shroud.
>
>
>
> Regarding your suggestions,
>
>
>
> 1)      rtkramp w/ or w/o CUDA:
>
> (command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda
> --output Ramp_wCUDA.mha? )
>
>
>
> Then, I have encountered following error.
>
> ?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that
> input requested and buffered regions are equal.?
>
>
>
>
>
> Without CUDA, it was successfully done.
>
>
>
> 2)      I?ve re-compiled *ITK w/o FFTW* and built RTK again. r*tkfdk
> worked fine.*
>
> -          I?ve also repeated ?rtkramp+CUDA? with this rtk version and
> the error was same as above.
>
>
>
> In conclusion, my *FFTW seems to affect CUDA-based fdk reconstruction
> only*.
>
> But I do need FFTW for the phase extraction. What should I do?
>
>
>
> Thanks.
>
>
>
> Yang
>
>
>
>
>
> -----Original Message-----
> From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon
> Rit
> Sent: Wednesday, November 11, 2015 4:16 PM
> To: Yang K Park <theday79 at gmail.com>
> Cc: rtk-users at openrtk.org
> Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
> update
>
>
>
> Hi,
>
> I didn't manage to reproduce the two problems on linux with the same ITK
> version.
>
> For point 1, did you copy itkMacro.h by hand? Because I don't see how
> replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the
> same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW?
> It looks like a ramp filter issue. Can you try rtkramp --path projPath
> --regexp .*.his, with and without --hardware cuda? Maybe you can provide
> your geometry file in case it's a specific geometric issue.
>
> Simon
>
>
>
> On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
>
> > Hi all,
>
> >
>
> >
>
> >
>
> > I?ve updated rtk with the up-to-date revision and have encountered a
>
> > couple of problems.
>
> >
>
> >
>
> >
>
> > 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
>
> > rtkCudaUtilities.hcu. It was solved by a minor fetching:
>
> >
>
> > #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>
> >
>
> >
>
> >
>
> > 2.       Output of rtkfdk with CUDA was not the same as before. It was
> very
>
> > blurry as seen in the attached image.
>
> >
>
> > a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > I?m using VS2013 with win7, itk4.8.1.
>
> >
>
> >
>
> >
>
> > The command line I used was :
>
> >
>
> > rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his
>
> > --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware
>
> > cuda --pad 1 --hann 5 --hannY 5
>
> >
>
> >
>
> >
>
> > Does anyone have any idea about this?
>
> >
>
> >
>
> >
>
> > Thanks.
>
> >
>
> >
>
> >
>
> > Yang
>
> >
>
> >
>
> >
>
> >
>
> > _______________________________________________
>
> > 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/20151116/38acfca5/attachment-0009.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151116/38acfca5/attachment-0009.png>

From theday79 at gmail.com  Mon Nov 16 10:47:43 2015
From: theday79 at gmail.com (Yang-Kyun Park)
Date: Mon, 16 Nov 2015 10:47:43 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
 <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
 <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>
Message-ID: <CAJM7=xjBjx=FzLazWJWqJbV5d45zGi2U71NKejm9HxKhJ0-xLQ@mail.gmail.com>

Hi Simon,

For better understanding, I'm attaching the problematic case including
projection files, geometry file(xml) and reconstructed images.(please find
the GDrive links. The file size is ~800 MB)
This is phantom data and there is no patient information in it.

Regarding the fftw library, I'm using [fftw-3.3.4-dll64].

By the way, I found another clue. When I've tried it with a head phantom
image (full-fan, ~ 190 projections), there was no problem. Is there any
possibility that DDF and parker short filter play some roles on this issue?

Feel free to let me know if further data is needed.

Thanks!

Yang

?
 FFTW_issue.zip
<https://drive.google.com/file/d/0BxuP3mON9V-qbVdQd0luc1lIb2M/view?usp=drive_web>
?

On Mon, Nov 16, 2015 at 10:07 AM, Simon Rit <simon.rit at creatis.insa-lyon.fr>
wrote:

> Hi,
> Thanks. It's really weird... When you run the tests with FFTW (compiling
> the "test" target), do they fail?
> Can you provide your geometry file? It might be specific to this geometry.
> Thanks again for looking into this issue, we'll find what's the problem.
> Simon
>
> On Mon, Nov 16, 2015 at 3:54 PM, Yang K Park <theday79 at gmail.com> wrote:
>
>> Hi Simon,
>>
>>
>>
>> Sorry for the late response.
>>
>>
>>
>> As you suggested, I?ve tried rtkramp+CUDA with only one projection and it
>> was successfully done for both w/ FFTW and w/o FFTW.
>>
>> (Two results were exactly same.)
>>
>>
>>
>> Regarding  the CUDA version, I?m using v6.5.
>>
>>
>>
>> Thanks a lot for the help!
>>
>>
>>
>> Yang
>>
>>
>>
>>
>>
>> *From:* simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of *Simon
>> Rit
>> *Sent:* Thursday, November 12, 2015 5:59 PM
>>
>> *To:* Yang K Park <theday79 at gmail.com>
>> *Cc:* rtk-users at openrtk.org
>> *Subject:* Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
>> update
>>
>>
>>
>> Hi,
>>
>> Ok. Can you try rtkramp with only one projection? Then you shouldn't
>> encounter this regions issue (that should be solved one day but that's a
>> different story).
>>
>> Can you also indicate which version of CUDA you're using?
>>
>> FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft
>> for the FFT of the projections. So if they are not in the same format,
>> you're in trouble and that might be the issue here... The weird part is
>> that I didn't reproduce this problem on linux (with and without FFTW) but
>> it might be a CUDA version difference. I'll give it another try tomorrow
>> when you provide the CUDA version.
>>
>> Thanks again for reporting the issue,
>> Simon
>>
>>
>>
>> On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com> wrote:
>>
>> Hi Simon,
>>
>>
>>
>> Thanks for the advice. The current RTK was compiled with FFTW to use the
>> phase extraction feature from Amsterdam shroud.
>>
>>
>>
>> Regarding your suggestions,
>>
>>
>>
>> 1)      rtkramp w/ or w/o CUDA:
>>
>> (command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda
>> --output Ramp_wCUDA.mha? )
>>
>>
>>
>> Then, I have encountered following error.
>>
>> ?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that
>> input requested and buffered regions are equal.?
>>
>>
>>
>>
>>
>> Without CUDA, it was successfully done.
>>
>>
>>
>> 2)      I?ve re-compiled *ITK w/o FFTW* and built RTK again. r*tkfdk
>> worked fine.*
>>
>> -          I?ve also repeated ?rtkramp+CUDA? with this rtk version and
>> the error was same as above.
>>
>>
>>
>> In conclusion, my *FFTW seems to affect CUDA-based fdk reconstruction
>> only*.
>>
>> But I do need FFTW for the phase extraction. What should I do?
>>
>>
>>
>> Thanks.
>>
>>
>>
>> Yang
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of
>> Simon Rit
>> Sent: Wednesday, November 11, 2015 4:16 PM
>> To: Yang K Park <theday79 at gmail.com>
>> Cc: rtk-users at openrtk.org
>> Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
>> update
>>
>>
>>
>> Hi,
>>
>> I didn't manage to reproduce the two problems on linux with the same ITK
>> version.
>>
>> For point 1, did you copy itkMacro.h by hand? Because I don't see how
>> replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the
>> same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW?
>> It looks like a ramp filter issue. Can you try rtkramp --path projPath
>> --regexp .*.his, with and without --hardware cuda? Maybe you can provide
>> your geometry file in case it's a specific geometric issue.
>>
>> Simon
>>
>>
>>
>> On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
>>
>> > Hi all,
>>
>> >
>>
>> >
>>
>> >
>>
>> > I?ve updated rtk with the up-to-date revision and have encountered a
>>
>> > couple of problems.
>>
>> >
>>
>> >
>>
>> >
>>
>> > 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
>>
>> > rtkCudaUtilities.hcu. It was solved by a minor fetching:
>>
>> >
>>
>> > #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>>
>> >
>>
>> >
>>
>> >
>>
>> > 2.       Output of rtkfdk with CUDA was not the same as before. It was
>> very
>>
>> > blurry as seen in the attached image.
>>
>> >
>>
>> > a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>
>> > I?m using VS2013 with win7, itk4.8.1.
>>
>> >
>>
>> >
>>
>> >
>>
>> > The command line I used was :
>>
>> >
>>
>> > rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his
>>
>> > --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware
>>
>> > cuda --pad 1 --hann 5 --hannY 5
>>
>> >
>>
>> >
>>
>> >
>>
>> > Does anyone have any idea about this?
>>
>> >
>>
>> >
>>
>> >
>>
>> > Thanks.
>>
>> >
>>
>> >
>>
>> >
>>
>> > Yang
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>
>> > _______________________________________________
>>
>> > 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/20151116/90d2c5a0/attachment-0009.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151116/90d2c5a0/attachment-0009.png>

From simon.rit at creatis.insa-lyon.fr  Fri Nov 20 11:28:22 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Fri, 20 Nov 2015 17:28:22 +0100
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAJM7=xjBjx=FzLazWJWqJbV5d45zGi2U71NKejm9HxKhJ0-xLQ@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
 <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
 <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>
 <CAJM7=xjBjx=FzLazWJWqJbV5d45zGi2U71NKejm9HxKhJ0-xLQ@mail.gmail.com>
Message-ID: <CAF0oig027_u_9gb8bnwT1w9jr3epZ0hkd9Mt73qK5heUq_kCkg@mail.gmail.com>

Hi Yang,
Thanks a lot for sharing the data. I have good news. I could reproduce the
bug and I have solutions. First, about your dataset: it's a huge dataset
and the hannY requires zero padding in both x and y. Because of this, cufft
has to take the 2D FFT of projection subsets that are 4095x2048x16. Quite
big!
When I ran it on my cuda 7.0, I immediately got:

itk::ExceptionObject (0x8b9cb30)
Location: "void CUDA_fft_convolution(const int3&, const int2&, float*,
cufftComplex*)"
File: /home/srit/src/rtk/rtk/code/rtkCudaFFTConvolutionImageFilter.cu
Line: 97
Description: itk::ERROR: CUFFT ERROR #2

i.e., a GPU alloc issue, even if I have the largest possible memory on a
nvidia desktop computer. Then, I ran it with cuda 6.5 and I got no error
message but a result similar to yours.
Conclusions:
- if you add the option --subsetsize 1 to your rtkfdk command line, that
should reconstruct correctly
- if you upgrade cuda, you should get an understandable error message,
- I don't think I'm going to look for a solution because the pb is probably
in cufft but if someone is willing to, be my guest!
Simon

On Mon, Nov 16, 2015 at 4:47 PM, Yang-Kyun Park <theday79 at gmail.com> wrote:

> Hi Simon,
>
> For better understanding, I'm attaching the problematic case including
> projection files, geometry file(xml) and reconstructed images.(please find
> the GDrive links. The file size is ~800 MB)
> This is phantom data and there is no patient information in it.
>
> Regarding the fftw library, I'm using [fftw-3.3.4-dll64].
>
> By the way, I found another clue. When I've tried it with a head phantom
> image (full-fan, ~ 190 projections), there was no problem. Is there any
> possibility that DDF and parker short filter play some roles on this issue?
>
> Feel free to let me know if further data is needed.
>
> Thanks!
>
> Yang
>
> ?
>  FFTW_issue.zip
> <https://drive.google.com/file/d/0BxuP3mON9V-qbVdQd0luc1lIb2M/view?usp=drive_web>
> ?
>
> On Mon, Nov 16, 2015 at 10:07 AM, Simon Rit <
> simon.rit at creatis.insa-lyon.fr> wrote:
>
>> Hi,
>> Thanks. It's really weird... When you run the tests with FFTW (compiling
>> the "test" target), do they fail?
>> Can you provide your geometry file? It might be specific to this geometry.
>> Thanks again for looking into this issue, we'll find what's the problem.
>> Simon
>>
>> On Mon, Nov 16, 2015 at 3:54 PM, Yang K Park <theday79 at gmail.com> wrote:
>>
>>> Hi Simon,
>>>
>>>
>>>
>>> Sorry for the late response.
>>>
>>>
>>>
>>> As you suggested, I?ve tried rtkramp+CUDA with only one projection and
>>> it was successfully done for both w/ FFTW and w/o FFTW.
>>>
>>> (Two results were exactly same.)
>>>
>>>
>>>
>>> Regarding  the CUDA version, I?m using v6.5.
>>>
>>>
>>>
>>> Thanks a lot for the help!
>>>
>>>
>>>
>>> Yang
>>>
>>>
>>>
>>>
>>>
>>> *From:* simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of *Simon
>>> Rit
>>> *Sent:* Thursday, November 12, 2015 5:59 PM
>>>
>>> *To:* Yang K Park <theday79 at gmail.com>
>>> *Cc:* rtk-users at openrtk.org
>>> *Subject:* Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
>>> update
>>>
>>>
>>>
>>> Hi,
>>>
>>> Ok. Can you try rtkramp with only one projection? Then you shouldn't
>>> encounter this regions issue (that should be solved one day but that's a
>>> different story).
>>>
>>> Can you also indicate which version of CUDA you're using?
>>>
>>> FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft
>>> for the FFT of the projections. So if they are not in the same format,
>>> you're in trouble and that might be the issue here... The weird part is
>>> that I didn't reproduce this problem on linux (with and without FFTW) but
>>> it might be a CUDA version difference. I'll give it another try tomorrow
>>> when you provide the CUDA version.
>>>
>>> Thanks again for reporting the issue,
>>> Simon
>>>
>>>
>>>
>>> On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com>
>>> wrote:
>>>
>>> Hi Simon,
>>>
>>>
>>>
>>> Thanks for the advice. The current RTK was compiled with FFTW to use the
>>> phase extraction feature from Amsterdam shroud.
>>>
>>>
>>>
>>> Regarding your suggestions,
>>>
>>>
>>>
>>> 1)      rtkramp w/ or w/o CUDA:
>>>
>>> (command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda
>>> --output Ramp_wCUDA.mha? )
>>>
>>>
>>>
>>> Then, I have encountered following error.
>>>
>>> ?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that
>>> input requested and buffered regions are equal.?
>>>
>>>
>>>
>>>
>>>
>>> Without CUDA, it was successfully done.
>>>
>>>
>>>
>>> 2)      I?ve re-compiled *ITK w/o FFTW* and built RTK again. r*tkfdk
>>> worked fine.*
>>>
>>> -          I?ve also repeated ?rtkramp+CUDA? with this rtk version and
>>> the error was same as above.
>>>
>>>
>>>
>>> In conclusion, my *FFTW seems to affect CUDA-based fdk reconstruction
>>> only*.
>>>
>>> But I do need FFTW for the phase extraction. What should I do?
>>>
>>>
>>>
>>> Thanks.
>>>
>>>
>>>
>>> Yang
>>>
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of
>>> Simon Rit
>>> Sent: Wednesday, November 11, 2015 4:16 PM
>>> To: Yang K Park <theday79 at gmail.com>
>>> Cc: rtk-users at openrtk.org
>>> Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
>>> update
>>>
>>>
>>>
>>> Hi,
>>>
>>> I didn't manage to reproduce the two problems on linux with the same ITK
>>> version.
>>>
>>> For point 1, did you copy itkMacro.h by hand? Because I don't see how
>>> replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the
>>> same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW?
>>> It looks like a ramp filter issue. Can you try rtkramp --path projPath
>>> --regexp .*.his, with and without --hardware cuda? Maybe you can provide
>>> your geometry file in case it's a specific geometric issue.
>>>
>>> Simon
>>>
>>>
>>>
>>> On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
>>>
>>> > Hi all,
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > I?ve updated rtk with the up-to-date revision and have encountered a
>>>
>>> > couple of problems.
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
>>>
>>> > rtkCudaUtilities.hcu. It was solved by a minor fetching:
>>>
>>> >
>>>
>>> > #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > 2.       Output of rtkfdk with CUDA was not the same as before. It was
>>> very
>>>
>>> > blurry as seen in the attached image.
>>>
>>> >
>>>
>>> > a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > I?m using VS2013 with win7, itk4.8.1.
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > The command line I used was :
>>>
>>> >
>>>
>>> > rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his
>>>
>>> > --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware
>>>
>>> > cuda --pad 1 --hann 5 --hannY 5
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > Does anyone have any idea about this?
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > Thanks.
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > Yang
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > _______________________________________________
>>>
>>> > 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/20151120/4e6c0e1e/attachment-0009.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151120/4e6c0e1e/attachment-0009.png>

From theday79 at gmail.com  Fri Nov 20 12:36:51 2015
From: theday79 at gmail.com (Yang K Park)
Date: Fri, 20 Nov 2015 12:36:51 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAF0oig027_u_9gb8bnwT1w9jr3epZ0hkd9Mt73qK5heUq_kCkg@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
 <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
 <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>
 <CAJM7=xjBjx=FzLazWJWqJbV5d45zGi2U71NKejm9HxKhJ0-xLQ@mail.gmail.com>
 <CAF0oig027_u_9gb8bnwT1w9jr3epZ0hkd9Mt73qK5heUq_kCkg@mail.gmail.com>
Message-ID: <000901d123ba$0ae3de50$20ab9af0$@gmail.com>

Hi Simon,

 

That sounds great! Thanks a lot for your hard work.

As you said, now I can reconstruct it successfully with --subsetsize option.

 

I think the only concern left is the elongated reconstruction time.

I?ve measured it for the same phantom image with different ?subsetsize? values as well as w/o FFTW compiling.

I just report it for your information.

 

1)      w/o FFTW  : 21.4 s

2)      w/ FFTW & --subsetsize 1: 89 s

3)      w/ FFTW & --subsetsize 2: 77 s

4)      w/ FFTW & --subsetsize 4: 65 s

5)      w/ FFTW & --subsetsize 6: 51 s

6)      w/ FFTW & --subsetsize 7: (Error-graphic card seemed to be freezed)

7)      w/ FFTW & --subsetsize 8: (Error-?itk::ERROR: CUFFT ERROR #2 in rtkCudaFFTConvolutionImageFilter.cu?)

 

Of course, the difference was coming from the Ramp filter.

Therefore, I?m going to use [--subsetsize 6] for my system and will update CUDA version soon!

 

Thanks.

 

Yang

 

 

From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit
Sent: Friday, November 20, 2015 11:28 AM
To: Yang-Kyun Park <theday79 at gmail.com>
Cc: rtk-users at openrtk.org
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi Yang,
Thanks a lot for sharing the data. I have good news. I could reproduce the bug and I have solutions. First, about your dataset: it's a huge dataset and the hannY requires zero padding in both x and y. Because of this, cufft has to take the 2D FFT of projection subsets that are 4095x2048x16. Quite big!

When I ran it on my cuda 7.0, I immediately got:

itk::ExceptionObject (0x8b9cb30)
Location: "void CUDA_fft_convolution(const int3&, const int2&, float*, cufftComplex*)" 
File: /home/srit/src/rtk/rtk/code/rtkCudaFFTConvolutionImageFilter.cu
Line: 97
Description: itk::ERROR: CUFFT ERROR #2

i.e., a GPU alloc issue, even if I have the largest possible memory on a nvidia desktop computer. Then, I ran it with cuda 6.5 and I got no error message but a result similar to yours.

Conclusions:

- if you add the option --subsetsize 1 to your rtkfdk command line, that should reconstruct correctly

- if you upgrade cuda, you should get an understandable error message,

- I don't think I'm going to look for a solution because the pb is probably in cufft but if someone is willing to, be my guest!

Simon

 

On Mon, Nov 16, 2015 at 4:47 PM, Yang-Kyun Park <theday79 at gmail.com <mailto:theday79 at gmail.com> > wrote:

Hi Simon,

 

For better understanding, I'm attaching the problematic case including projection files, geometry file(xml) and reconstructed images.(please find the GDrive links. The file size is ~800 MB)

This is phantom data and there is no patient information in it.

 

Regarding the fftw library, I'm using [fftw-3.3.4-dll64].

 

By the way, I found another clue. When I've tried it with a head phantom image (full-fan, ~ 190 projections), there was no problem. Is there any possibility that DDF and parker short filter play some roles on this issue?

 

Feel free to let me know if further data is needed.

 

Thanks!

 

Yang

 

?

 <https://drive.google.com/file/d/0BxuP3mON9V-qbVdQd0luc1lIb2M/view?usp=drive_web>  FFTW_issue.zip

?

 

On Mon, Nov 16, 2015 at 10:07 AM, Simon Rit <simon.rit at creatis.insa-lyon.fr <mailto:simon.rit at creatis.insa-lyon.fr> > wrote:

Hi,

Thanks. It's really weird... When you run the tests with FFTW (compiling the "test" target), do they fail?
Can you provide your geometry file? It might be specific to this geometry.

Thanks again for looking into this issue, we'll find what's the problem.

Simon

 

On Mon, Nov 16, 2015 at 3:54 PM, Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> > wrote:

Hi Simon,

 

Sorry for the late response.

 

As you suggested, I?ve tried rtkramp+CUDA with only one projection and it was successfully done for both w/ FFTW and w/o FFTW.

(Two results were exactly same.)

 

Regarding  the CUDA version, I?m using v6.5.

 

Thanks a lot for the help!

 

Yang

 

 

From: simon.rit at gmail.com <mailto:simon.rit at gmail.com>  [mailto:simon.rit at gmail.com <mailto:simon.rit at gmail.com> ] On Behalf Of Simon Rit
Sent: Thursday, November 12, 2015 5:59 PM


To: Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> >
Cc: rtk-users at openrtk.org <mailto:rtk-users at openrtk.org> 
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

Ok. Can you try rtkramp with only one projection? Then you shouldn't encounter this regions issue (that should be solved one day but that's a different story). 

Can you also indicate which version of CUDA you're using?

FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft for the FFT of the projections. So if they are not in the same format, you're in trouble and that might be the issue here... The weird part is that I didn't reproduce this problem on linux (with and without FFTW) but it might be a CUDA version difference. I'll give it another try tomorrow when you provide the CUDA version.

Thanks again for reporting the issue,
Simon

 

On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> > wrote:

Hi Simon,

 

Thanks for the advice. The current RTK was compiled with FFTW to use the phase extraction feature from Amsterdam shroud.

 

Regarding your suggestions,

 

1)      rtkramp w/ or w/o CUDA:

(command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda --output Ramp_wCUDA.mha? )

 

Then, I have encountered following error.

?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that input requested and buffered regions are equal.?

 



 

Without CUDA, it was successfully done.

 

2)      I?ve re-compiled ITK w/o FFTW and built RTK again. rtkfdk worked fine.

-          I?ve also repeated ?rtkramp+CUDA? with this rtk version and the error was same as above.

 

In conclusion, my FFTW seems to affect CUDA-based fdk reconstruction only.

But I do need FFTW for the phase extraction. What should I do?

 

Thanks.

 

Yang

 

 

-----Original Message-----
From: simon.rit at gmail.com <mailto:simon.rit at gmail.com>  [mailto:simon.rit at gmail.com <mailto:simon.rit at gmail.com> ] On Behalf Of Simon Rit
Sent: Wednesday, November 11, 2015 4:16 PM
To: Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> >
Cc: rtk-users at openrtk.org <mailto:rtk-users at openrtk.org> 
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

I didn't manage to reproduce the two problems on linux with the same ITK version.

For point 1, did you copy itkMacro.h by hand? Because I don't see how replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW? It looks like a ramp filter issue. Can you try rtkramp --path projPath --regexp .*.his, with and without --hardware cuda? Maybe you can provide your geometry file in case it's a specific geometric issue.

Simon

 

On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park < <mailto:theday79 at gmail.com> theday79 at gmail.com> wrote:

> Hi all,

> 

> 

> 

> I?ve updated rtk with the up-to-date revision and have encountered a 

> couple of problems.

> 

> 

> 

> 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled

> rtkCudaUtilities.hcu. It was solved by a minor fetching:

> 

> #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu

> 

> 

> 

> 2.       Output of rtkfdk with CUDA was not the same as before. It was very

> blurry as seen in the attached image.

> 

> a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.

> 

> 

> 

> 

> 

> I?m using VS2013 with win7, itk4.8.1.

> 

> 

> 

> The command line I used was :

> 

> rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his 

> --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware 

> cuda --pad 1 --hann 5 --hannY 5

> 

> 

> 

> Does anyone have any idea about this?

> 

> 

> 

> Thanks.

> 

> 

> 

> Yang

> 

> 

> 

> 

> _______________________________________________

> Rtk-users mailing list

>  <mailto: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/20151120/0d98ace1/attachment-0009.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151120/0d98ace1/attachment-0009.png>

From simon.rit at creatis.insa-lyon.fr  Wed Nov 25 02:36:44 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Wed, 25 Nov 2015 08:36:44 +0100
Subject: [Rtk-users] Compiling Problem
In-Reply-To: <040e01d125c7$83648e60$8a2dab20$@126.com>
References: <040e01d125c7$83648e60$8a2dab20$@126.com>
Message-ID: <5655650C.1040500@creatis.insa-lyon.fr>

Hi,
Please use the mailing list. I don't know where does the linking problem 
come from and it seems to work on our side:
http://my.cdash.org/index.php?project=RTK
Have you tried disabling CUDA?
Simon

On 23/11/2015 09:18, Freyman li wrote:
>
> Dear Simon,
>
> Recently I configured the RTK tool and suffer some problems. After set 
> up the itk tool and cuda, I compiled the rtk application but 
> encountered two errors attached to the email(jpg format)
>
> CUDA and ITK environment are tested successfully. My compile tool is 
> Visual studio 2012(64bit) and CUDA version is v6.5.
>
> Can you tell me how to deal with it and I am looking forward to hear 
> you again.
>
> Thank you!
>
> Best Regards
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151125/285f7f3c/attachment-0009.html>

From theday79 at gmail.com  Wed Nov 25 12:38:52 2015
From: theday79 at gmail.com (Yang K Park)
Date: Wed, 25 Nov 2015 12:38:52 -0500
Subject: [Rtk-users] Compiling Problem
In-Reply-To: <5655650C.1040500@creatis.insa-lyon.fr>
References: <040e01d125c7$83648e60$8a2dab20$@126.com>
 <5655650C.1040500@creatis.insa-lyon.fr>
Message-ID: <003d01d127a8$27a52b60$76ef8220$@gmail.com>

Hi Freyman,

 

I think your setting is much similar to mine, since I have compiled RTK with
VS2013 and CUDA v6.5 several times. Can you post those error messages again
so that I can see?

Yang

 

 

From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of
Simon Rit
Sent: Wednesday, November 25, 2015 2:37 AM
To: Freyman li <lihanwei_1500 at 126.com>
Cc: rtk-users at openrtk.org
Subject: Re: [Rtk-users] Compiling Problem

 

Hi,
Please use the mailing list. I don't know where does the linking problem
come from and it seems to work on our side:
http://my.cdash.org/index.php?project=RTK
Have you tried disabling CUDA?
Simon

On 23/11/2015 09:18, Freyman li wrote:

Dear Simon,

 

Recently I configured the RTK tool and suffer some problems. After set up
the itk tool and cuda, I compiled the rtk application but encountered two
errors attached to the email(jpg format)

CUDA and ITK environment are tested successfully. My compile tool is Visual
studio 2012(64bit) and CUDA version is v6.5.

Can you tell me how to deal with it and I am looking forward to hear you
again.

Thank you!

 

Best Regards

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151125/984feb50/attachment-0009.html>

From bioniloofar at gmail.com  Mon Nov 30 06:06:41 2015
From: bioniloofar at gmail.com (niloufar teyfouri)
Date: Mon, 30 Nov 2015 14:36:41 +0330
Subject: [Rtk-users] ElectaReconstruction
Message-ID: <CALChM12F4PuiLvgENg3Yyn7E+uZ7iPJ+GiY04z7VQ-90AS83EA@mail.gmail.com>

I ran the application of Electa Reconstruction implemented by you with
RTK. But after debugging I was encountered with the message of
"--output' ('-o') option required". Could you please help me for running
this example and the other ones?
I don't know any thing about the texts in the gray boxes mentioned at
each link related to examples of RTK.
For example in the link of
http://wiki.openrtk.org/index.php/RTK/Examples/ElektaReconstruction
how I should use gengetopt for the instructions below?


2. Run the application to convert Elekta's geometry into RTKs (DICOM_UID
is contained in the subfolder name of the his files):

  rtkelektasynergygeometry \
    --image_db IMAGE.DBF \
    --frame_db FRAME.DBF \
    --dicom_uid 1.3.46.423632.135428.1351013645.166 \
    -o elektaGeometry

I would be appreciate if one could answer my question.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151130/b11ad4e2/attachment-0009.html>

From cyril.mory at uclouvain.be  Mon Nov 30 09:30:48 2015
From: cyril.mory at uclouvain.be (Cyril Mory)
Date: Mon, 30 Nov 2015 15:30:48 +0100
Subject: [Rtk-users] ElectaReconstruction
In-Reply-To: <CALChM12F4PuiLvgENg3Yyn7E+uZ7iPJ+GiY04z7VQ-90AS83EA@mail.gmail.com>
References: <CALChM12F4PuiLvgENg3Yyn7E+uZ7iPJ+GiY04z7VQ-90AS83EA@mail.gmail.com>
Message-ID: <565C5D98.1000309@uclouvain.be>

Hi, and welcome to RTK,

Gengetopt is the piece of software that parses the command line 
arguments in all RTK applications. You do not have to "use" it. You just 
need to give correct arguments on the command line.

The message "--output' ('-o') option required" means what it says : you 
need to provide the name of the file in which you want to store the 
geometry information generated by the application 
rtkelektasynergygeometry. If you just copy-pasted the command you found 
on the wiki, then something went wrong during the copy-paste. Try to run 
the following :

rtkelektasynergygeometry --image_db IMAGE.DBF --frame_db FRAME.DBF 
--dicom_uid 1.3.46.423632.135428.1351013645.166 -o elektaGeometry

I just removed the '\' and the useless spaces. You can do the same for 
all other command line examples and it should work.

Let us know if you keep encountering trouble.
Cyril


Le 30/11/2015 12:06, niloufar teyfouri a ?crit :
>
> I ran the application of Electa Reconstruction implemented by you with
> RTK. But after debugging I was encountered with the message of
> "--output' ('-o') option required". Could you please help me for running
> this example and the other ones?
> I don't know any thing about the texts in the gray boxes mentioned at
> each link related to examples of RTK.
> For example in the link of
> http://wiki.openrtk.org/index.php/RTK/Examples/ElektaReconstruction
> how I should use gengetopt for the instructions below?
>
>
> 2. Run the application to convert Elekta's geometry into RTKs (DICOM_UID
> is contained in the subfolder name of the his files):
>
> rtkelektasynergygeometry \
> --image_db IMAGE.DBF \
> --frame_db FRAME.DBF \
> --dicom_uid 1.3.46.423632.135428.1351013645.166 \
>     -o elektaGeometry
>
> I would be appreciate if one could answer my question.
>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151130/66741755/attachment-0009.html>

From j.mason at ed.ac.uk  Mon Nov 30 11:29:27 2015
From: j.mason at ed.ac.uk (Jonathan Mason)
Date: Mon, 30 Nov 2015 16:29:27 +0000
Subject: [Rtk-users] Preprocessing
Message-ID: <565C7967.4000401@ed.ac.uk>

Good afternoon RTK users,

I have access to "raw data" from a Varian OBI scanner, and have
experimented with RTK for performing its reconstruction. However, it is
not really "raw" in the sense that the coefficients are proportional to
the photon flux recorded at a given sensor, but is instead proportional
to the Hounsfield attenuation along that path. With this data, it means
that one can reconstruct using FDK and other iterative techniques, which
assume a linear model, but the connection to the underlying physics is
abstract.

The problem I then have when trying to develop reconstruction
techniques, is that I do not know whether I am really correcting for
physical distortions or just correcting for Varian's preprocessing,
which has been finely tuned for its own FDK method.

My question is whether anybody has dug into the steps that manufacturers
such as Varian or Elekta perform to arrive at these projection images?
And if they think that if reverse engineered, could provide a richer set
of information to facilitate advanced strategies.

Best wishes,

Jonathan Mason

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.



From simon.rit at creatis.insa-lyon.fr  Mon Nov 30 12:44:03 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Mon, 30 Nov 2015 18:44:03 +0100
Subject: [Rtk-users] ElectaReconstruction
In-Reply-To: <565C5D98.1000309@uclouvain.be>
References: <CALChM12F4PuiLvgENg3Yyn7E+uZ7iPJ+GiY04z7VQ-90AS83EA@mail.gmail.com>
 <565C5D98.1000309@uclouvain.be>
Message-ID: <CAF0oig2Zg96AZaRn9w9=F+LnLnyteTn5zS1rLguQ8WXiYhnnYg@mail.gmail.com>

Hi,
I think Cyril is right, it's not possible to use backslashes to put a
command line on several line with Windows command line. Can you confirm
this? If you confirm, we will correct the wiki.
Thanks,
Simon

On Mon, Nov 30, 2015 at 3:30 PM, Cyril Mory <cyril.mory at uclouvain.be> wrote:

> Hi, and welcome to RTK,
>
> Gengetopt is the piece of software that parses the command line arguments
> in all RTK applications. You do not have to "use" it. You just need to give
> correct arguments on the command line.
>
> The message "--output' ('-o') option required" means what it says : you
> need to provide the name of the file in which you want to store the
> geometry information generated by the application rtkelektasynergygeometry.
> If you just copy-pasted the command you found on the wiki, then something
> went wrong during the copy-paste. Try to run the following :
>
> rtkelektasynergygeometry --image_db IMAGE.DBF --frame_db FRAME.DBF
> --dicom_uid 1.3.46.423632.135428.1351013645.166 -o elektaGeometry
>
> I just removed the '\' and the useless spaces. You can do the same for all
> other command line examples and it should work.
>
> Let us know if you keep encountering trouble.
> Cyril
>
>
>
> Le 30/11/2015 12:06, niloufar teyfouri a ?crit :
>
>
> I ran the application of Electa Reconstruction implemented by you with
> RTK. But after debugging I was encountered with the message of
> "--output' ('-o') option required". Could you please help me for running
> this example and the other ones?
> I don't know any thing about the texts in the gray boxes mentioned at
> each link related to examples of RTK.
> For example in the link of
> http://wiki.openrtk.org/index.php/RTK/Examples/ElektaReconstruction
> how I should use gengetopt for the instructions below?
>
>
> 2. Run the application to convert Elekta's geometry into RTKs (DICOM_UID
> is contained in the subfolder name of the his files):
>
>   rtkelektasynergygeometry \
>     --image_db IMAGE.DBF \
>     --frame_db FRAME.DBF \
>     --dicom_uid 1.3.46.423632.135428.1351013645.166 \
>     -o elektaGeometry
>
> I would be appreciate if one could answer my question.
>
>
> _______________________________________________
> Rtk-users mailing listRtk-users at public.kitware.comhttp://public.kitware.com/mailman/listinfo/rtk-users
>
>
>
>
> ------------------------------
> [image: Avast logo] <https://www.avast.com/antivirus>
>
> L'absence de virus dans ce courrier ?lectronique a ?t? v?rifi?e par le
> logiciel antivirus Avast.
> www.avast.com <https://www.avast.com/antivirus>
>
>
> _______________________________________________
> 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/20151130/6d6dd6aa/attachment-0009.html>

From wuchao04 at gmail.com  Mon Nov 30 13:50:06 2015
From: wuchao04 at gmail.com (Chao Wu)
Date: Mon, 30 Nov 2015 19:50:06 +0100
Subject: [Rtk-users] Preprocessing
In-Reply-To: <565C7967.4000401@ed.ac.uk>
References: <565C7967.4000401@ed.ac.uk>
Message-ID: <CAH+sHrUFov5f=8h4-ePhC2xLraM3BxA9r12yfXdM3rrKPeqCBg@mail.gmail.com>

Hi Jonathan,

I do not quite understand your problem.
I think most information can be retrieved by the relationship between flux
(I) and attenuation (u):
I = I0 * exp (- integral(u * dL) )
Of course there are other effects like beam hardening and scattering
involved but this model is the basic.

Regards,
Chao

2015-11-30 17:29 GMT+01:00 Jonathan Mason <j.mason at ed.ac.uk>:

> Good afternoon RTK users,
>
> I have access to "raw data" from a Varian OBI scanner, and have
> experimented with RTK for performing its reconstruction. However, it is
> not really "raw" in the sense that the coefficients are proportional to
> the photon flux recorded at a given sensor, but is instead proportional
> to the Hounsfield attenuation along that path. With this data, it means
> that one can reconstruct using FDK and other iterative techniques, which
> assume a linear model, but the connection to the underlying physics is
> abstract.
>
> The problem I then have when trying to develop reconstruction
> techniques, is that I do not know whether I am really correcting for
> physical distortions or just correcting for Varian's preprocessing,
> which has been finely tuned for its own FDK method.
>
> My question is whether anybody has dug into the steps that manufacturers
> such as Varian or Elekta perform to arrive at these projection images?
> And if they think that if reverse engineered, could provide a richer set
> of information to facilitate advanced strategies.
>
> Best wishes,
>
> Jonathan Mason
>
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
> _______________________________________________
> 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/20151130/ccb833fe/attachment-0009.html>

From mdupont at cppm.in2p3.fr  Sun Nov  1 12:41:49 2015
From: mdupont at cppm.in2p3.fr (Mathieu Dupont)
Date: Sun, 01 Nov 2015 18:41:49 +0100
Subject: [Rtk-users] question about rtkDraw*ImageFilter
In-Reply-To: <56334CF2.8070902@cppm.in2p3.fr>
References: <5630EE01.5070900@cppm.in2p3.fr>
 <CAF0oig279ZWGJMFnJdXaPiYLPponadz_J-PVKt2z3iHiTRQ_gg@mail.gmail.com>
 <56334CF2.8070902@cppm.in2p3.fr>
Message-ID: <1539144.WPSdtJ8lhZ@marabunta>

Hello Simon, 

I started to implement what I suggested : 

https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawImageFilter.h
and 
https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawCylinderImageFilter.h

rtk::DrawCylinderImageFilter derives from rtk::DrawImageFilter and specializes 
it (by defaulting the template parameter TSpatialObject with 
DrawCylinderSpatialObject). 

By default, DrawCylinderImageFilter uses Add2 for filling output image (to be 
backward compatible (all tests pass)). I created Discard (I did not find 
equivalent in itk) functor in order to do what I wanted in my first email.  

I just implemented DrawCylinderImageFilter, the others will follow. 

What do you think about it ?

Le vendredi 30 octobre 2015, 11:56:50 Mathieu Dupont a ?crit :
> Hi,
> 
> In case of your first solution, you can not chain several
> Draw*ImageFilters. For example, if you want to create small cylinders in
> a big cylinder.
> 
> Your second solution is better.
> 
> One another solution can be a thing like itk:SpatialObject but more
> simpler. An rtk::SpatialObject which one function (isInside(point)). We
> create a rtkDrawImageFilter class and implement ThreadedGenerateData
> like this :
> 
> DrawImageFilter<InImage, OutImage, rtkSpatialObject,
> rtkFillFunctor>::ThreadedGenerateData(const OutputImageRegionType&
> outputRegionForThread,                 ThreadIdType itkNotUsed(threadId)
> {
> ...
> 
>   while( !itOut.IsAtEnd() )
>      {
>      this->GetInput()->TransformIndexToPhysicalPoint(itOut.GetIndex(),
> point);
> 
>     if(m_rtkSpatialObject.isInside(point)
>       itOut.Set(m_rtkFillFunctor(density, itIn.Get());
> ...
> }
> 
> 
> DrawConeImageFilter class can be a child of this new DrawImageFilter
> (with new methods like setAngle, SetRadius which will adjust the
> rtkConeSpatialObject)
> 
> This solution suppress duplicated code in
> Draw*ImageFilter::ThreadedGenerateData and makes easier implementation
> of another type of filling.
> 
> On 28/10/2015 20:52, Simon Rit wrote:
> > Hi Mathieu,
> > Thanks for pointing this out. I agree that it might not be the best
> > solution, yet one could argue that you could simply create a constant
> > image with 0 to do what you'd like from the current implementation. My
> > main problem is that I just tried to do what you suggest and some tests
> > then fail... which shows the obvious, it's not a backward compatible
> > change. I see two solutions:
> > - keep it as is and you use ConstantImageFilter + we remove useless add
> > filters,
> > - a more complex but maybe more elegant solution: add a third template
> > parameter for the operation that would allow the user to do what he'd
> > like in a functor. That's what's done with filters that derive from
> > itk::UnaryImageFilter
> > <http://www.itk.org/Doxygen/html/classitk_1_1UnaryFunctorImageFilter.html>
> > .
> > The default would be itk::Add2 but we could find or implement another
> > one that simply discards the pixel value.
> > What do you think?
> > Simon
> > 
> > PS: looking in the code, I just found that rtk::DrawConeImageFilter is
> > not consistent with the others, it was always setting to 0 outside...
> > that's been fixed!
> > 
> > On Wed, Oct 28, 2015 at 4:47 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr
> > 
> > <mailto:mdupont at cppm.in2p3.fr>> wrote:
> >     Hello everyone,
> >     
> >     I have a question/suggestion about the set of rtkDraw*ImageFilter.
> >     This filter are written as additive filters: for example, in
> >     rtkDrawEllipsoidImageFilter.txx, we can find
> >     
> >     for(..)
> >     
> >       itOut.Set( ellipsoid.density + itIn.Get() )
> >     
> >     instead of
> >     
> >     for(..)
> >     itOut.Set( ellipsoid.density )
> >     
> >     
> >     I think it can be more flexible the second option, because we can
> >     always associate Draw*ImageFilter and itkAddImageFilter to get an
> >     additive filter.
> >     
> >     Moreover, the  rtkDrawGeometricPhantomImageFilter class already uses
> >     itkAddImageFilter in order to have additive filters (which is
> >     redundant in current situation).
> >     
> >     What do you think ?
> >     
> >     
> >     
> >     
> >     
> >     Regards
> >     
> >     
> >     
> >     _______________________________________________
> >     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


From gnthibault at gmail.com  Mon Nov  2 08:08:42 2015
From: gnthibault at gmail.com (Notargiacomo Thibault)
Date: Mon, 2 Nov 2015 14:08:42 +0100
Subject: [Rtk-users] Problem with rtkGgoFunctions when importing series of
	images
Message-ID: <CAP+mR7Zw7WmRmEgVUTamNhS6m4S6ORvWFjRu1EANViPRJ7jtuQ@mail.gmail.com>

I recently experienced the following problem, when importing multiple tif
files inside a directory using itk::ImageSeriesReader:

[...]
code/rtkGgoFunctions.h: In instantiation of ?void
rtk::SetProjectionsReaderFromGgo(typename TProjectionsReaderType::Pointer,
const TArgsInfo&)
[...]
code/rtkGgoFunctions.h:121:61: error: no type named
?OutputImageDirectionType? in ?class
itk::ImageSeriesReader<itk::Image<short unsigned int, 3u> >?
   typename TProjectionsReaderType::OutputImageDirectionType direction;
[...]

It seems that, a new functionality added in rtkGgoFunctions.h (19/05/2015),
allowing to directly modify input images properties through command line,
like geometry (direction vector), assumes that the input image type defines
OutputImageDirectionType, but in the case of itk::ImageSeriesReader, it
does not.

Is this considered as a regression, or should the
SetProjectionsReaderFromGgo function be used with specific input image type
?

Thank you in advance for your help.

Kind regards

Thibault Notargiacomo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151102/6cad3583/attachment-0010.html>

From simon.rit at creatis.insa-lyon.fr  Mon Nov  2 08:58:24 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Mon, 2 Nov 2015 14:58:24 +0100
Subject: [Rtk-users] Problem with rtkGgoFunctions when importing series
	of images
In-Reply-To: <CAP+mR7Zw7WmRmEgVUTamNhS6m4S6ORvWFjRu1EANViPRJ7jtuQ@mail.gmail.com>
References: <CAP+mR7Zw7WmRmEgVUTamNhS6m4S6ORvWFjRu1EANViPRJ7jtuQ@mail.gmail.com>
Message-ID: <CAF0oig2bAidO4JR7pa_PUxOQm-X7JrEz8=ybGX3bskYJM9YRAQ@mail.gmail.com>

Hi Thibault,
SetProjectionsReaderFromGgo is a macro designed for the
rtk::ProjectionsReader
<http://www.openrtk.org/Doxygen/classrtk_1_1ProjectionsReader.html>, I'm
not surprised that it does not work with the itk::ImageSeriesReader. It's
not about the image type but about the filter type... We use this macro to
set many parameters specific to the rtk::ProjectionsReader
<http://www.openrtk.org/Doxygen/classrtk_1_1ProjectionsReader.html>. Since
a while, I have made have a common rtkinputprojections_section.ggo
<https://github.com/SimonRit/RTK/blob/master/applications/rtkinputprojections_section.ggo>
file for all the applications that use the rtk::ProjectionsReader.
If you don't want to use the rtk::ProjectionsReader but
itk::ImageSeriesReader (e.g., because it does a lot of automatic processing
that you don't want), you'll have to write your own code to set it up.
I hope this clarifies things.
Simon

On Mon, Nov 2, 2015 at 2:08 PM, Notargiacomo Thibault <gnthibault at gmail.com>
wrote:

> I recently experienced the following problem, when importing multiple tif
> files inside a directory using itk::ImageSeriesReader:
>
> [...]
> code/rtkGgoFunctions.h: In instantiation of ?void
> rtk::SetProjectionsReaderFromGgo(typename TProjectionsReaderType::Pointer,
> const TArgsInfo&)
> [...]
> code/rtkGgoFunctions.h:121:61: error: no type named
> ?OutputImageDirectionType? in ?class
> itk::ImageSeriesReader<itk::Image<short unsigned int, 3u> >?
>    typename TProjectionsReaderType::OutputImageDirectionType direction;
> [...]
>
> It seems that, a new functionality added in rtkGgoFunctions.h
> (19/05/2015), allowing to directly modify input images properties through
> command line, like geometry (direction vector), assumes that the input
> image type defines OutputImageDirectionType, but in the case of
> itk::ImageSeriesReader, it does not.
>
> Is this considered as a regression, or should the
> SetProjectionsReaderFromGgo function be used with specific input image type
> ?
>
> Thank you in advance for your help.
>
> Kind regards
>
> Thibault Notargiacomo
>
> _______________________________________________
> 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/20151102/ee7e2c17/attachment-0010.html>

From simon.rit at creatis.insa-lyon.fr  Wed Nov  4 16:38:18 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Wed, 4 Nov 2015 22:38:18 +0100
Subject: [Rtk-users] question about rtkDraw*ImageFilter
In-Reply-To: <1539144.WPSdtJ8lhZ@marabunta>
References: <5630EE01.5070900@cppm.in2p3.fr>
 <CAF0oig279ZWGJMFnJdXaPiYLPponadz_J-PVKt2z3iHiTRQ_gg@mail.gmail.com>
 <56334CF2.8070902@cppm.in2p3.fr> <1539144.WPSdtJ8lhZ@marabunta>
Message-ID: <CAF0oig3jBsfoadM_k6SYvOMwikOCNFmH19J7m1YJZx-RU0y+5g@mail.gmail.com>

Hi Mathieu,
Sorry, I'm very busy these days. I had a first quick look. Why not, it
looks a bit complicated but good. I would have a few things I would change
style wise, e.g., move DrawCylinderSpatialObject to
DrawCylinderImageFilter, create a common DrawQuadricSpatialObject that
would all have the same IsInside function, make DrawSpatialObjectpurely
virtual by not defining
IsInside etc. but those are details I can correct myself. Do you want to
finish what you started and I work from there or should I finish everything?
Simon

On Sun, Nov 1, 2015 at 6:41 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr>
wrote:

> Hello Simon,
>
> I started to implement what I suggested :
>
>
> https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawImageFilter.h
> and
>
> https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawCylinderImageFilter.h
>
> rtk::DrawCylinderImageFilter derives from rtk::DrawImageFilter and
> specializes
> it (by defaulting the template parameter TSpatialObject with
> DrawCylinderSpatialObject).
>
> By default, DrawCylinderImageFilter uses Add2 for filling output image (to
> be
> backward compatible (all tests pass)). I created Discard (I did not find
> equivalent in itk) functor in order to do what I wanted in my first email.
>
> I just implemented DrawCylinderImageFilter, the others will follow.
>
> What do you think about it ?
>
> Le vendredi 30 octobre 2015, 11:56:50 Mathieu Dupont a ?crit :
> > Hi,
> >
> > In case of your first solution, you can not chain several
> > Draw*ImageFilters. For example, if you want to create small cylinders in
> > a big cylinder.
> >
> > Your second solution is better.
> >
> > One another solution can be a thing like itk:SpatialObject but more
> > simpler. An rtk::SpatialObject which one function (isInside(point)). We
> > create a rtkDrawImageFilter class and implement ThreadedGenerateData
> > like this :
> >
> > DrawImageFilter<InImage, OutImage, rtkSpatialObject,
> > rtkFillFunctor>::ThreadedGenerateData(const OutputImageRegionType&
> > outputRegionForThread,                 ThreadIdType itkNotUsed(threadId)
> > {
> > ...
> >
> >   while( !itOut.IsAtEnd() )
> >      {
> >      this->GetInput()->TransformIndexToPhysicalPoint(itOut.GetIndex(),
> > point);
> >
> >     if(m_rtkSpatialObject.isInside(point)
> >       itOut.Set(m_rtkFillFunctor(density, itIn.Get());
> > ...
> > }
> >
> >
> > DrawConeImageFilter class can be a child of this new DrawImageFilter
> > (with new methods like setAngle, SetRadius which will adjust the
> > rtkConeSpatialObject)
> >
> > This solution suppress duplicated code in
> > Draw*ImageFilter::ThreadedGenerateData and makes easier implementation
> > of another type of filling.
> >
> > On 28/10/2015 20:52, Simon Rit wrote:
> > > Hi Mathieu,
> > > Thanks for pointing this out. I agree that it might not be the best
> > > solution, yet one could argue that you could simply create a constant
> > > image with 0 to do what you'd like from the current implementation. My
> > > main problem is that I just tried to do what you suggest and some tests
> > > then fail... which shows the obvious, it's not a backward compatible
> > > change. I see two solutions:
> > > - keep it as is and you use ConstantImageFilter + we remove useless add
> > > filters,
> > > - a more complex but maybe more elegant solution: add a third template
> > > parameter for the operation that would allow the user to do what he'd
> > > like in a functor. That's what's done with filters that derive from
> > > itk::UnaryImageFilter
> > > <
> http://www.itk.org/Doxygen/html/classitk_1_1UnaryFunctorImageFilter.html>
> > > .
> > > The default would be itk::Add2 but we could find or implement another
> > > one that simply discards the pixel value.
> > > What do you think?
> > > Simon
> > >
> > > PS: looking in the code, I just found that rtk::DrawConeImageFilter is
> > > not consistent with the others, it was always setting to 0 outside...
> > > that's been fixed!
> > >
> > > On Wed, Oct 28, 2015 at 4:47 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr
> > >
> > > <mailto:mdupont at cppm.in2p3.fr>> wrote:
> > >     Hello everyone,
> > >
> > >     I have a question/suggestion about the set of rtkDraw*ImageFilter.
> > >     This filter are written as additive filters: for example, in
> > >     rtkDrawEllipsoidImageFilter.txx, we can find
> > >
> > >     for(..)
> > >
> > >       itOut.Set( ellipsoid.density + itIn.Get() )
> > >
> > >     instead of
> > >
> > >     for(..)
> > >     itOut.Set( ellipsoid.density )
> > >
> > >
> > >     I think it can be more flexible the second option, because we can
> > >     always associate Draw*ImageFilter and itkAddImageFilter to get an
> > >     additive filter.
> > >
> > >     Moreover, the  rtkDrawGeometricPhantomImageFilter class already
> uses
> > >     itkAddImageFilter in order to have additive filters (which is
> > >     redundant in current situation).
> > >
> > >     What do you think ?
> > >
> > >
> > >
> > >
> > >
> > >     Regards
> > >
> > >
> > >
> > >     _______________________________________________
> > >     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/20151104/46314d97/attachment-0010.html>

From mdupont at cppm.in2p3.fr  Mon Nov  9 14:35:47 2015
From: mdupont at cppm.in2p3.fr (Mathieu Dupont)
Date: Mon, 09 Nov 2015 20:35:47 +0100
Subject: [Rtk-users] question about rtkDraw*ImageFilter
In-Reply-To: <CAF0oig3jBsfoadM_k6SYvOMwikOCNFmH19J7m1YJZx-RU0y+5g@mail.gmail.com>
References: <5630EE01.5070900@cppm.in2p3.fr> <1539144.WPSdtJ8lhZ@marabunta>
 <CAF0oig3jBsfoadM_k6SYvOMwikOCNFmH19J7m1YJZx-RU0y+5g@mail.gmail.com>
Message-ID: <5634494.U9CmFl2V79@marabunta>

hi, 

i will do this during this week and try to implement your remarks. 


Le mercredi 4 novembre 2015, 22:38:18 Simon Rit a ?crit :
> Hi Mathieu,
> Sorry, I'm very busy these days. I had a first quick look. Why not, it
> looks a bit complicated but good. I would have a few things I would change
> style wise, e.g., move DrawCylinderSpatialObject to
> DrawCylinderImageFilter, create a common DrawQuadricSpatialObject that
> would all have the same IsInside function, make DrawSpatialObjectpurely
> virtual by not defining
> IsInside etc. but those are details I can correct myself. Do you want to
> finish what you started and I work from there or should I finish everything?
> Simon
> 
> On Sun, Nov 1, 2015 at 6:41 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr>
> 
> wrote:
> > Hello Simon,
> > 
> > I started to implement what I suggested :
> > 
> > 
> > https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawImag
> > eFilter.h and
> > 
> > https://github.com/wrzof/RTK/blob/rewrite_DrawImageFilter/code/rtkDrawCyli
> > nderImageFilter.h
> > 
> > rtk::DrawCylinderImageFilter derives from rtk::DrawImageFilter and
> > specializes
> > it (by defaulting the template parameter TSpatialObject with
> > DrawCylinderSpatialObject).
> > 
> > By default, DrawCylinderImageFilter uses Add2 for filling output image (to
> > be
> > backward compatible (all tests pass)). I created Discard (I did not find
> > equivalent in itk) functor in order to do what I wanted in my first email.
> > 
> > I just implemented DrawCylinderImageFilter, the others will follow.
> > 
> > What do you think about it ?
> > 
> > Le vendredi 30 octobre 2015, 11:56:50 Mathieu Dupont a ?crit :
> > > Hi,
> > > 
> > > In case of your first solution, you can not chain several
> > > Draw*ImageFilters. For example, if you want to create small cylinders in
> > > a big cylinder.
> > > 
> > > Your second solution is better.
> > > 
> > > One another solution can be a thing like itk:SpatialObject but more
> > > simpler. An rtk::SpatialObject which one function (isInside(point)). We
> > > create a rtkDrawImageFilter class and implement ThreadedGenerateData
> > > like this :
> > > 
> > > DrawImageFilter<InImage, OutImage, rtkSpatialObject,
> > > rtkFillFunctor>::ThreadedGenerateData(const OutputImageRegionType&
> > > outputRegionForThread,                 ThreadIdType itkNotUsed(threadId)
> > > {
> > > ...
> > > 
> > >   while( !itOut.IsAtEnd() )
> > >   
> > >      {
> > >      this->GetInput()->TransformIndexToPhysicalPoint(itOut.GetIndex(),
> > > 
> > > point);
> > > 
> > >     if(m_rtkSpatialObject.isInside(point)
> > >     
> > >       itOut.Set(m_rtkFillFunctor(density, itIn.Get());
> > > 
> > > ...
> > > }
> > > 
> > > 
> > > DrawConeImageFilter class can be a child of this new DrawImageFilter
> > > (with new methods like setAngle, SetRadius which will adjust the
> > > rtkConeSpatialObject)
> > > 
> > > This solution suppress duplicated code in
> > > Draw*ImageFilter::ThreadedGenerateData and makes easier implementation
> > > of another type of filling.
> > > 
> > > On 28/10/2015 20:52, Simon Rit wrote:
> > > > Hi Mathieu,
> > > > Thanks for pointing this out. I agree that it might not be the best
> > > > solution, yet one could argue that you could simply create a constant
> > > > image with 0 to do what you'd like from the current implementation. My
> > > > main problem is that I just tried to do what you suggest and some
> > > > tests
> > > > then fail... which shows the obvious, it's not a backward compatible
> > > > change. I see two solutions:
> > > > - keep it as is and you use ConstantImageFilter + we remove useless
> > > > add
> > > > filters,
> > > > - a more complex but maybe more elegant solution: add a third template
> > > > parameter for the operation that would allow the user to do what he'd
> > > > like in a functor. That's what's done with filters that derive from
> > > > itk::UnaryImageFilter
> > > > <
> > 
> > http://www.itk.org/Doxygen/html/classitk_1_1UnaryFunctorImageFilter.html>
> > 
> > > > .
> > > > The default would be itk::Add2 but we could find or implement another
> > > > one that simply discards the pixel value.
> > > > What do you think?
> > > > Simon
> > > > 
> > > > PS: looking in the code, I just found that rtk::DrawConeImageFilter is
> > > > not consistent with the others, it was always setting to 0 outside...
> > > > that's been fixed!
> > > > 
> > > > On Wed, Oct 28, 2015 at 4:47 PM, Mathieu Dupont <mdupont at cppm.in2p3.fr
> > > > 
> > > > <mailto:mdupont at cppm.in2p3.fr>> wrote:
> > > >     Hello everyone,
> > > >     
> > > >     I have a question/suggestion about the set of rtkDraw*ImageFilter.
> > > >     This filter are written as additive filters: for example, in
> > > >     rtkDrawEllipsoidImageFilter.txx, we can find
> > > >     
> > > >     for(..)
> > > >     
> > > >       itOut.Set( ellipsoid.density + itIn.Get() )
> > > >     
> > > >     instead of
> > > >     
> > > >     for(..)
> > > >     itOut.Set( ellipsoid.density )
> > > >     
> > > >     
> > > >     I think it can be more flexible the second option, because we can
> > > >     always associate Draw*ImageFilter and itkAddImageFilter to get an
> > > >     additive filter.
> > > >     
> > > >     Moreover, the  rtkDrawGeometricPhantomImageFilter class already
> > 
> > uses
> > 
> > > >     itkAddImageFilter in order to have additive filters (which is
> > > >     redundant in current situation).
> > > >     
> > > >     What do you think ?
> > > >     
> > > >     
> > > >     
> > > >     
> > > >     
> > > >     Regards
> > > >     
> > > >     
> > > >     
> > > >     _______________________________________________
> > > >     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


From gnthibault at gmail.com  Tue Nov 10 07:39:46 2015
From: gnthibault at gmail.com (Notargiacomo Thibault)
Date: Tue, 10 Nov 2015 13:39:46 +0100
Subject: [Rtk-users] Understanding projection matrices management in
	rtkCudaBackProjectionImageFilter
Message-ID: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>

Hi all,

I am currently trying to use the "AddProjectionInRadians" method from the
ThreeDCircularProjectionGeometry class in RTK to import my geometry.

First things first, I would like to know if the information on this pdf are
still valid: http://www.openrtk.org/Doxygen/geometry.pdf

Because I used them to deduce the source offset and Projection offset from
my own matrix decomposition.

Notice that I don't want to use geometric informations coming from the
projection images themselves, so their geometric origin is assumed to be
(0,0,0) in my case.

In order to check if my geometry import method is correct, I print out one
of the intermediate form of the projection matrix used in the
backprojection process, in order to check if it is the same as in my own
implementation.

To do so, I print out one of the intermediate matrix that is generated in
rtkCudaBackProjectionImageFilter while launching a SART reconstruction for
instance.

I was surpised by the fact that, the matrix allowing the transformation
from 2D geometric world to 2D image index world, namely matrixIdxProj in
rtkCudaBackProjectionImageFilte.cxx
<http://www.openrtk.org/Doxygen/rtkCudaBackProjectionImageFilter_8cxx_source.html>
is not always the same along the reconstruction process ?

Here is the line that generates the matrix I don't understand:

for(unsigned int i=0; i<2; i++)
 //SR: 0.5 for 2D texture
  matrixIdxProj[i][2] =
-1*(this->GetInput(1)->GetBufferedRegion().GetIndex()[i])+0.5;

What I understand here, is that, we are generating a 2D translation matrix
embedded in a 3*3 matrix that allows to take into account two things
related to the 2D projection:

-If the internal behaviour of the imageContainer, allows buffering of only
a part of the image, beginning at index (i,j), this information will be
embeded in the projection matrix

-the ITK floating point addressing definition seems to differ from the one
from cuda (and openCV):
When I take a look at this page
<http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#texture-fetching>
I understand that the floating point indexing (0.5,0.5) in Cuda points to
the center of the pixel (0,0) hence a linear contribution of 100%, while it
seems that we must add a translation of (0.5,0.5) to the ITK geometric
framework in order to get the same behaviour.

In practice matrixIdxProj is based on a 3*3 identity matrix, where the
inner 2D translation (ie 2 first term of the last column) in my case are:
-in X, a random number between 10 and 150 plus 0.5
-in Y: always 0.5

I understand the 0.5 part, but why is there always a 0 offset in Y but a
random offset in X remains a mystery to me.

At first, I believed that each projection was splitted into multiple part,
each having a different X and Y offset.
But reconstructing using only one projection generates only one
backprojection operation, with a non zero offset in X, 123 in my case, for
an image of size 780 in X.

Do you think there is something wrong whith the values of matrixIdxProjI am
experiencing ?

Thank you in advance.

Kind regards

Thibault Notargiacomo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151110/fbd3fb46/attachment-0010.html>

From simon.rit at creatis.insa-lyon.fr  Tue Nov 10 08:21:29 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Tue, 10 Nov 2015 14:21:29 +0100
Subject: [Rtk-users] Understanding projection matrices management in
	rtkCudaBackProjectionImageFilter
In-Reply-To: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>
References: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>
Message-ID: <CAF0oig3muuH+1=eLZ66DJ22QcnsSrUKzRFS4RzDRvDJXNxAVXg@mail.gmail.com>

Hi Thibault,
You started digging in the code so that gets complicated. First thing
first, yes, the link you provide is still valid.
The offset in X is not random but computed in
BackProjectionImageFilter::GenerateInputRequestedRegion
<https://github.com/SimonRit/RTK/blob/master/code/rtkBackProjectionImageFilter.txx>.
The idea is that we request only the part of the projections we need to do
the backprojection. This optimizes the streaming (we only read from disk
what we need). If you use a huge volume (the test I'd suggest to validate
that I'm correct and there is nothing wrong with your code), then you'll
need the full projection and you will always get 0 in X as in Y. If you use
a small volume and do a computation projection per projection, you will get
a varying index depending on your input volume and the geometry for that
projection.
I think you understood the rest pretty well. Does that make sense or am I
missing something else?
Simon

On Tue, Nov 10, 2015 at 1:39 PM, Notargiacomo Thibault <gnthibault at gmail.com
> wrote:

> Hi all,
>
> I am currently trying to use the "AddProjectionInRadians" method from the
> ThreeDCircularProjectionGeometry class in RTK to import my geometry.
>
> First things first, I would like to know if the information on this pdf
> are still valid: http://www.openrtk.org/Doxygen/geometry.pdf
>
> Because I used them to deduce the source offset and Projection offset from
> my own matrix decomposition.
>
> Notice that I don't want to use geometric informations coming from the
> projection images themselves, so their geometric origin is assumed to be
> (0,0,0) in my case.
>
> In order to check if my geometry import method is correct, I print out one
> of the intermediate form of the projection matrix used in the
> backprojection process, in order to check if it is the same as in my own
> implementation.
>
> To do so, I print out one of the intermediate matrix that is generated in
> rtkCudaBackProjectionImageFilter while launching a SART reconstruction for
> instance.
>
> I was surpised by the fact that, the matrix allowing the transformation
> from 2D geometric world to 2D image index world, namely matrixIdxProj in
> rtkCudaBackProjectionImageFilte.cxx
> <http://www.openrtk.org/Doxygen/rtkCudaBackProjectionImageFilter_8cxx_source.html>
> is not always the same along the reconstruction process ?
>
> Here is the line that generates the matrix I don't understand:
>
> for(unsigned int i=0; i<2; i++)
>  //SR: 0.5 for 2D texture
>   matrixIdxProj[i][2] =
> -1*(this->GetInput(1)->GetBufferedRegion().GetIndex()[i])+0.5;
>
> What I understand here, is that, we are generating a 2D translation matrix
> embedded in a 3*3 matrix that allows to take into account two things
> related to the 2D projection:
>
> -If the internal behaviour of the imageContainer, allows buffering of only
> a part of the image, beginning at index (i,j), this information will be
> embeded in the projection matrix
>
> -the ITK floating point addressing definition seems to differ from the one
> from cuda (and openCV):
> When I take a look at this page
> <http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#texture-fetching>
> I understand that the floating point indexing (0.5,0.5) in Cuda points to
> the center of the pixel (0,0) hence a linear contribution of 100%, while it
> seems that we must add a translation of (0.5,0.5) to the ITK geometric
> framework in order to get the same behaviour.
>
> In practice matrixIdxProj is based on a 3*3 identity matrix, where the
> inner 2D translation (ie 2 first term of the last column) in my case are:
> -in X, a random number between 10 and 150 plus 0.5
> -in Y: always 0.5
>
> I understand the 0.5 part, but why is there always a 0 offset in Y but a
> random offset in X remains a mystery to me.
>
> At first, I believed that each projection was splitted into multiple part,
> each having a different X and Y offset.
> But reconstructing using only one projection generates only one
> backprojection operation, with a non zero offset in X, 123 in my case, for
> an image of size 780 in X.
>
> Do you think there is something wrong whith the values of matrixIdxProjI
> am experiencing ?
>
> Thank you in advance.
>
> Kind regards
>
> Thibault Notargiacomo
>
> _______________________________________________
> 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/20151110/8b9b86e6/attachment-0010.html>

From simon.rit at creatis.insa-lyon.fr  Tue Nov 10 09:03:52 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Tue, 10 Nov 2015 15:03:52 +0100
Subject: [Rtk-users] Understanding projection matrices management in
	rtkCudaBackProjectionImageFilter
In-Reply-To: <CAP+mR7ZLJV8V5dMOW_jgM5G2-kCZhy8o0tB19685LGo-1bxLUg@mail.gmail.com>
References: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>
 <CAF0oig3muuH+1=eLZ66DJ22QcnsSrUKzRFS4RzDRvDJXNxAVXg@mail.gmail.com>
 <CAP+mR7ZLJV8V5dMOW_jgM5G2-kCZhy8o0tB19685LGo-1bxLUg@mail.gmail.com>
Message-ID: <CAF0oig3fALRnZNCJ53+TsSjBm7raRC_mqahWEU6x+D+zxwOnVQ@mail.gmail.com>

A small correction: it's actually the amount of data pre-processed (read
from disk + all the processing before backprojection) but that should
change nothing to what is backprojected.
I remembered something that can help you: you may want to run
UpdateLargestPossibleRegion() to the projections (input 1 of the
BackProjectImageFilter) before backprojection to avoid this and make things
clearer instead of using a large volume as I was suggesting before.
Simon

On Tue, Nov 10, 2015 at 2:34 PM, Notargiacomo Thibault <gnthibault at gmail.com
> wrote:

> Ok, using geometric information to reduce the amount of data to be
> backprojected is pretty clever ;)
> This explains the "random" index I was asking about in my previous
> question, I now know what it is used for and continue my debugging process.
>
> Kind regards
>
> Thibault Notargiacomo
>
> 2015-11-10 14:21 GMT+01:00 Simon Rit <simon.rit at creatis.insa-lyon.fr>:
>
>> Hi Thibault,
>> You started digging in the code so that gets complicated. First thing
>> first, yes, the link you provide is still valid.
>> The offset in X is not random but computed in
>> BackProjectionImageFilter::GenerateInputRequestedRegion
>> <https://github.com/SimonRit/RTK/blob/master/code/rtkBackProjectionImageFilter.txx>.
>> The idea is that we request only the part of the projections we need to do
>> the backprojection. This optimizes the streaming (we only read from disk
>> what we need). If you use a huge volume (the test I'd suggest to validate
>> that I'm correct and there is nothing wrong with your code), then you'll
>> need the full projection and you will always get 0 in X as in Y. If you use
>> a small volume and do a computation projection per projection, you will get
>> a varying index depending on your input volume and the geometry for that
>> projection.
>> I think you understood the rest pretty well. Does that make sense or am I
>> missing something else?
>> Simon
>>
>> On Tue, Nov 10, 2015 at 1:39 PM, Notargiacomo Thibault <
>> gnthibault at gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> I am currently trying to use the "AddProjectionInRadians" method from
>>> the ThreeDCircularProjectionGeometry class in RTK to import my geometry.
>>>
>>> First things first, I would like to know if the information on this pdf
>>> are still valid: http://www.openrtk.org/Doxygen/geometry.pdf
>>>
>>> Because I used them to deduce the source offset and Projection offset
>>> from my own matrix decomposition.
>>>
>>> Notice that I don't want to use geometric informations coming from the
>>> projection images themselves, so their geometric origin is assumed to be
>>> (0,0,0) in my case.
>>>
>>> In order to check if my geometry import method is correct, I print out
>>> one of the intermediate form of the projection matrix used in the
>>> backprojection process, in order to check if it is the same as in my own
>>> implementation.
>>>
>>> To do so, I print out one of the intermediate matrix that is generated
>>> in rtkCudaBackProjectionImageFilter while launching a SART reconstruction
>>> for instance.
>>>
>>> I was surpised by the fact that, the matrix allowing the transformation
>>> from 2D geometric world to 2D image index world, namely matrixIdxProj in
>>> rtkCudaBackProjectionImageFilte.cxx
>>> <http://www.openrtk.org/Doxygen/rtkCudaBackProjectionImageFilter_8cxx_source.html>
>>> is not always the same along the reconstruction process ?
>>>
>>> Here is the line that generates the matrix I don't understand:
>>>
>>> for(unsigned int i=0; i<2; i++)
>>>  //SR: 0.5 for 2D texture
>>>   matrixIdxProj[i][2] =
>>> -1*(this->GetInput(1)->GetBufferedRegion().GetIndex()[i])+0.5;
>>>
>>> What I understand here, is that, we are generating a 2D translation
>>> matrix embedded in a 3*3 matrix that allows to take into account two things
>>> related to the 2D projection:
>>>
>>> -If the internal behaviour of the imageContainer, allows buffering of
>>> only a part of the image, beginning at index (i,j), this information will
>>> be embeded in the projection matrix
>>>
>>> -the ITK floating point addressing definition seems to differ from the
>>> one from cuda (and openCV):
>>> When I take a look at this page
>>> <http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#texture-fetching>
>>> I understand that the floating point indexing (0.5,0.5) in Cuda points to
>>> the center of the pixel (0,0) hence a linear contribution of 100%, while it
>>> seems that we must add a translation of (0.5,0.5) to the ITK geometric
>>> framework in order to get the same behaviour.
>>>
>>> In practice matrixIdxProj is based on a 3*3 identity matrix, where the
>>> inner 2D translation (ie 2 first term of the last column) in my case are:
>>> -in X, a random number between 10 and 150 plus 0.5
>>> -in Y: always 0.5
>>>
>>> I understand the 0.5 part, but why is there always a 0 offset in Y but a
>>> random offset in X remains a mystery to me.
>>>
>>> At first, I believed that each projection was splitted into multiple
>>> part, each having a different X and Y offset.
>>> But reconstructing using only one projection generates only one
>>> backprojection operation, with a non zero offset in X, 123 in my case, for
>>> an image of size 780 in X.
>>>
>>> Do you think there is something wrong whith the values of matrixIdxProjI
>>> am experiencing ?
>>>
>>> Thank you in advance.
>>>
>>> Kind regards
>>>
>>> Thibault Notargiacomo
>>>
>>> _______________________________________________
>>> 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/20151110/d8913dc3/attachment-0010.html>

From simon.rit at creatis.insa-lyon.fr  Tue Nov 10 11:21:29 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Tue, 10 Nov 2015 17:21:29 +0100
Subject: [Rtk-users] Understanding projection matrices management in
	rtkCudaBackProjectionImageFilter
In-Reply-To: <CAP+mR7ZKqnbUyRHyHkti=3sZd2dEw-OUV6oqsqcga55=tcQ9OQ@mail.gmail.com>
References: <CAP+mR7YH1qBHrS9QTOXv1H8A=x=FxWk+xFF2SQZc4A0BpWHXbQ@mail.gmail.com>
 <CAF0oig3muuH+1=eLZ66DJ22QcnsSrUKzRFS4RzDRvDJXNxAVXg@mail.gmail.com>
 <CAP+mR7ZLJV8V5dMOW_jgM5G2-kCZhy8o0tB19685LGo-1bxLUg@mail.gmail.com>
 <CAF0oig3fALRnZNCJ53+TsSjBm7raRC_mqahWEU6x+D+zxwOnVQ@mail.gmail.com>
 <CAP+mR7ZKqnbUyRHyHkti=3sZd2dEw-OUV6oqsqcga55=tcQ9OQ@mail.gmail.com>
Message-ID: <CAF0oig12pRGBfgiCQMCwTG7zX_3vz87AEWhTQ4EYaVbH_m0t5Q@mail.gmail.com>

Your welcome (I cc the mailing list for info).
Simon

On Tue, Nov 10, 2015 at 5:03 PM, Notargiacomo Thibault <gnthibault at gmail.com
> wrote:

> I replaced the original Update by the "UpdateLargestPossibleRegion" to the
> divideFilter in SART (I bypassed displacedDetectorFilter for now) and it
> work as expected, I have now a "clean" matProjIdx.
>
> Thank you for your help !
>
> 2015-11-10 15:03 GMT+01:00 Simon Rit <simon.rit at creatis.insa-lyon.fr>:
>
>> A small correction: it's actually the amount of data pre-processed (read
>> from disk + all the processing before backprojection) but that should
>> change nothing to what is backprojected.
>> I remembered something that can help you: you may want to run
>> UpdateLargestPossibleRegion() to the projections (input 1 of the
>> BackProjectImageFilter) before backprojection to avoid this and make things
>> clearer instead of using a large volume as I was suggesting before.
>> Simon
>>
>> On Tue, Nov 10, 2015 at 2:34 PM, Notargiacomo Thibault <
>> gnthibault at gmail.com> wrote:
>>
>>> Ok, using geometric information to reduce the amount of data to be
>>> backprojected is pretty clever ;)
>>> This explains the "random" index I was asking about in my previous
>>> question, I now know what it is used for and continue my debugging process.
>>>
>>> Kind regards
>>>
>>> Thibault Notargiacomo
>>>
>>> 2015-11-10 14:21 GMT+01:00 Simon Rit <simon.rit at creatis.insa-lyon.fr>:
>>>
>>>> Hi Thibault,
>>>> You started digging in the code so that gets complicated. First thing
>>>> first, yes, the link you provide is still valid.
>>>> The offset in X is not random but computed in
>>>> BackProjectionImageFilter::GenerateInputRequestedRegion
>>>> <https://github.com/SimonRit/RTK/blob/master/code/rtkBackProjectionImageFilter.txx>.
>>>> The idea is that we request only the part of the projections we need to do
>>>> the backprojection. This optimizes the streaming (we only read from disk
>>>> what we need). If you use a huge volume (the test I'd suggest to validate
>>>> that I'm correct and there is nothing wrong with your code), then you'll
>>>> need the full projection and you will always get 0 in X as in Y. If you use
>>>> a small volume and do a computation projection per projection, you will get
>>>> a varying index depending on your input volume and the geometry for that
>>>> projection.
>>>> I think you understood the rest pretty well. Does that make sense or am
>>>> I missing something else?
>>>> Simon
>>>>
>>>> On Tue, Nov 10, 2015 at 1:39 PM, Notargiacomo Thibault <
>>>> gnthibault at gmail.com> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I am currently trying to use the "AddProjectionInRadians" method from
>>>>> the ThreeDCircularProjectionGeometry class in RTK to import my geometry.
>>>>>
>>>>> First things first, I would like to know if the information on this
>>>>> pdf are still valid: http://www.openrtk.org/Doxygen/geometry.pdf
>>>>>
>>>>> Because I used them to deduce the source offset and Projection offset
>>>>> from my own matrix decomposition.
>>>>>
>>>>> Notice that I don't want to use geometric informations coming from the
>>>>> projection images themselves, so their geometric origin is assumed to be
>>>>> (0,0,0) in my case.
>>>>>
>>>>> In order to check if my geometry import method is correct, I print out
>>>>> one of the intermediate form of the projection matrix used in the
>>>>> backprojection process, in order to check if it is the same as in my own
>>>>> implementation.
>>>>>
>>>>> To do so, I print out one of the intermediate matrix that is generated
>>>>> in rtkCudaBackProjectionImageFilter while launching a SART reconstruction
>>>>> for instance.
>>>>>
>>>>> I was surpised by the fact that, the matrix allowing the
>>>>> transformation from 2D geometric world to 2D image index world, namely
>>>>> matrixIdxProj in rtkCudaBackProjectionImageFilte.cxx
>>>>> <http://www.openrtk.org/Doxygen/rtkCudaBackProjectionImageFilter_8cxx_source.html>
>>>>> is not always the same along the reconstruction process ?
>>>>>
>>>>> Here is the line that generates the matrix I don't understand:
>>>>>
>>>>> for(unsigned int i=0; i<2; i++)
>>>>>  //SR: 0.5 for 2D texture
>>>>>   matrixIdxProj[i][2] =
>>>>> -1*(this->GetInput(1)->GetBufferedRegion().GetIndex()[i])+0.5;
>>>>>
>>>>> What I understand here, is that, we are generating a 2D translation
>>>>> matrix embedded in a 3*3 matrix that allows to take into account two things
>>>>> related to the 2D projection:
>>>>>
>>>>> -If the internal behaviour of the imageContainer, allows buffering of
>>>>> only a part of the image, beginning at index (i,j), this information will
>>>>> be embeded in the projection matrix
>>>>>
>>>>> -the ITK floating point addressing definition seems to differ from the
>>>>> one from cuda (and openCV):
>>>>> When I take a look at this page
>>>>> <http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#texture-fetching>
>>>>> I understand that the floating point indexing (0.5,0.5) in Cuda points to
>>>>> the center of the pixel (0,0) hence a linear contribution of 100%, while it
>>>>> seems that we must add a translation of (0.5,0.5) to the ITK geometric
>>>>> framework in order to get the same behaviour.
>>>>>
>>>>> In practice matrixIdxProj is based on a 3*3 identity matrix, where
>>>>> the inner 2D translation (ie 2 first term of the last column) in my case
>>>>> are:
>>>>> -in X, a random number between 10 and 150 plus 0.5
>>>>> -in Y: always 0.5
>>>>>
>>>>> I understand the 0.5 part, but why is there always a 0 offset in Y but
>>>>> a random offset in X remains a mystery to me.
>>>>>
>>>>> At first, I believed that each projection was splitted into multiple
>>>>> part, each having a different X and Y offset.
>>>>> But reconstructing using only one projection generates only one
>>>>> backprojection operation, with a non zero offset in X, 123 in my case, for
>>>>> an image of size 780 in X.
>>>>>
>>>>> Do you think there is something wrong whith the values of matrixIdxProjI
>>>>> am experiencing ?
>>>>>
>>>>> Thank you in advance.
>>>>>
>>>>> Kind regards
>>>>>
>>>>> Thibault Notargiacomo
>>>>>
>>>>> _______________________________________________
>>>>> 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/20151110/b7eba683/attachment-0010.html>

From theday79 at gmail.com  Wed Nov 11 13:50:45 2015
From: theday79 at gmail.com (Yang K Park)
Date: Wed, 11 Nov 2015 13:50:45 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after  a recent update
Message-ID: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>

Hi all,

 

I?ve updated rtk with the up-to-date revision and have encountered a couple of problems.

 

1.       Compile error: RTK couldn?t find itkMacro.h while it compiled rtkCudaUtilities.hcu. It was solved by a minor fetching:

#include <itkMacro.h>   --> #include "itkMacro.h" in rtkCudaUtilities.hcu

 

2.       Output of rtkfdk with CUDA was not the same as before. It was very blurry as seen in the attached image.

a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.

 

 

I?m using VS2013 with win7, itk4.8.1.

 

The command line I used was :

rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware cuda --pad 1 --hann 5 --hannY 5

 

Does anyone have any idea about this?

 

Thanks.

 

Yang

 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151111/b1c7df5f/attachment-0010.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 16577 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151111/b1c7df5f/attachment-0010.png>

From simon.rit at creatis.insa-lyon.fr  Wed Nov 11 16:15:49 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Wed, 11 Nov 2015 22:15:49 +0100
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
Message-ID: <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>

Hi,
I didn't manage to reproduce the two problems on linux with the same
ITK version.
For point 1, did you copy itkMacro.h by hand? Because I don't see how
replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not
in the same folder as rtkCudaUtilities.hcu
For point 2, no clue. Do you use FFTW? It looks like a ramp filter
issue. Can you try rtkramp --path projPath --regexp .*.his, with and
without --hardware cuda? Maybe you can provide your geometry file in
case it's a specific geometric issue.
Simon

On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
> Hi all,
>
>
>
> I?ve updated rtk with the up-to-date revision and have encountered a couple
> of problems.
>
>
>
> 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
> rtkCudaUtilities.hcu. It was solved by a minor fetching:
>
> #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>
>
>
> 2.       Output of rtkfdk with CUDA was not the same as before. It was very
> blurry as seen in the attached image.
>
> a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>
>
>
>
>
> I?m using VS2013 with win7, itk4.8.1.
>
>
>
> The command line I used was :
>
> rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his --output
> output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware cuda --pad 1
> --hann 5 --hannY 5
>
>
>
> Does anyone have any idea about this?
>
>
>
> Thanks.
>
>
>
> Yang
>
>
>
>
> _______________________________________________
> Rtk-users mailing list
> Rtk-users at public.kitware.com
> http://public.kitware.com/mailman/listinfo/rtk-users
>


From theday79 at gmail.com  Thu Nov 12 17:39:38 2015
From: theday79 at gmail.com (Yang K Park)
Date: Thu, 12 Nov 2015 17:39:38 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
Message-ID: <000001d11d9b$04142320$0c3c6960$@gmail.com>

Hi Simon,

 

Thanks for the advice. The current RTK was compiled with FFTW to use the phase extraction feature from Amsterdam shroud.

 

Regarding your suggestions,

 

1)      rtkramp w/ or w/o CUDA:

(command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda --output Ramp_wCUDA.mha? )

 

Then, I have encountered following error.

?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that input requested and buffered regions are equal.?

 



 

Without CUDA, it was successfully done.

 

2)      I?ve re-compiled ITK w/o FFTW and built RTK again. rtkfdk worked fine.

-          I?ve also repeated ?rtkramp+CUDA? with this rtk version and the error was same as above.

 

In conclusion, my FFTW seems to affect CUDA-based fdk reconstruction only.

But I do need FFTW for the phase extraction. What should I do?

 

Thanks.

 

Yang

 

 

-----Original Message-----
From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit
Sent: Wednesday, November 11, 2015 4:16 PM
To: Yang K Park <theday79 at gmail.com>
Cc: rtk-users at openrtk.org
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

I didn't manage to reproduce the two problems on linux with the same ITK version.

For point 1, did you copy itkMacro.h by hand? Because I don't see how replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW? It looks like a ramp filter issue. Can you try rtkramp --path projPath --regexp .*.his, with and without --hardware cuda? Maybe you can provide your geometry file in case it's a specific geometric issue.

Simon

 

On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park < <mailto:theday79 at gmail.com> theday79 at gmail.com> wrote:

> Hi all,

> 

> 

> 

> I?ve updated rtk with the up-to-date revision and have encountered a 

> couple of problems.

> 

> 

> 

> 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled

> rtkCudaUtilities.hcu. It was solved by a minor fetching:

> 

> #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu

> 

> 

> 

> 2.       Output of rtkfdk with CUDA was not the same as before. It was very

> blurry as seen in the attached image.

> 

> a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.

> 

> 

> 

> 

> 

> I?m using VS2013 with win7, itk4.8.1.

> 

> 

> 

> The command line I used was :

> 

> rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his 

> --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware 

> cuda --pad 1 --hann 5 --hannY 5

> 

> 

> 

> Does anyone have any idea about this?

> 

> 

> 

> Thanks.

> 

> 

> 

> Yang

> 

> 

> 

> 

> _______________________________________________

> Rtk-users mailing list

>  <mailto: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/20151112/4e0825dc/attachment-0010.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151112/4e0825dc/attachment-0010.png>

From simon.rit at creatis.insa-lyon.fr  Thu Nov 12 17:58:42 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Thu, 12 Nov 2015 23:58:42 +0100
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <000001d11d9b$04142320$0c3c6960$@gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
Message-ID: <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>

Hi,
Ok. Can you try rtkramp with only one projection? Then you shouldn't
encounter this regions issue (that should be solved one day but that's a
different story).
Can you also indicate which version of CUDA you're using?
FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft for
the FFT of the projections. So if they are not in the same format, you're
in trouble and that might be the issue here... The weird part is that I
didn't reproduce this problem on linux (with and without FFTW) but it might
be a CUDA version difference. I'll give it another try tomorrow when you
provide the CUDA version.
Thanks again for reporting the issue,
Simon

On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com> wrote:

> Hi Simon,
>
>
>
> Thanks for the advice. The current RTK was compiled with FFTW to use the
> phase extraction feature from Amsterdam shroud.
>
>
>
> Regarding your suggestions,
>
>
>
> 1)      rtkramp w/ or w/o CUDA:
>
> (command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda
> --output Ramp_wCUDA.mha? )
>
>
>
> Then, I have encountered following error.
>
> ?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that
> input requested and buffered regions are equal.?
>
>
>
>
>
> Without CUDA, it was successfully done.
>
>
>
> 2)      I?ve re-compiled *ITK w/o FFTW* and built RTK again. r*tkfdk
> worked fine.*
>
> -          I?ve also repeated ?rtkramp+CUDA? with this rtk version and
> the error was same as above.
>
>
>
> In conclusion, my *FFTW seems to affect CUDA-based fdk reconstruction
> only*.
>
> But I do need FFTW for the phase extraction. What should I do?
>
>
>
> Thanks.
>
>
>
> Yang
>
>
>
>
>
> -----Original Message-----
> From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon
> Rit
> Sent: Wednesday, November 11, 2015 4:16 PM
> To: Yang K Park <theday79 at gmail.com>
> Cc: rtk-users at openrtk.org
> Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
> update
>
>
>
> Hi,
>
> I didn't manage to reproduce the two problems on linux with the same ITK
> version.
>
> For point 1, did you copy itkMacro.h by hand? Because I don't see how
> replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the
> same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW?
> It looks like a ramp filter issue. Can you try rtkramp --path projPath
> --regexp .*.his, with and without --hardware cuda? Maybe you can provide
> your geometry file in case it's a specific geometric issue.
>
> Simon
>
>
>
> On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
>
> > Hi all,
>
> >
>
> >
>
> >
>
> > I?ve updated rtk with the up-to-date revision and have encountered a
>
> > couple of problems.
>
> >
>
> >
>
> >
>
> > 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
>
> > rtkCudaUtilities.hcu. It was solved by a minor fetching:
>
> >
>
> > #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>
> >
>
> >
>
> >
>
> > 2.       Output of rtkfdk with CUDA was not the same as before. It was
> very
>
> > blurry as seen in the attached image.
>
> >
>
> > a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > I?m using VS2013 with win7, itk4.8.1.
>
> >
>
> >
>
> >
>
> > The command line I used was :
>
> >
>
> > rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his
>
> > --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware
>
> > cuda --pad 1 --hann 5 --hannY 5
>
> >
>
> >
>
> >
>
> > Does anyone have any idea about this?
>
> >
>
> >
>
> >
>
> > Thanks.
>
> >
>
> >
>
> >
>
> > Yang
>
> >
>
> >
>
> >
>
> >
>
> > _______________________________________________
>
> > 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/20151112/e7c15ff8/attachment-0010.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151112/e7c15ff8/attachment-0010.png>

From theday79 at gmail.com  Mon Nov 16 09:54:01 2015
From: theday79 at gmail.com (Yang K Park)
Date: Mon, 16 Nov 2015 09:54:01 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
Message-ID: <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>

Hi Simon,

 

Sorry for the late response.

 

As you suggested, I?ve tried rtkramp+CUDA with only one projection and it was successfully done for both w/ FFTW and w/o FFTW.

(Two results were exactly same.)

 

Regarding  the CUDA version, I?m using v6.5.

 

Thanks a lot for the help!

 

Yang

 

 

From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit
Sent: Thursday, November 12, 2015 5:59 PM
To: Yang K Park <theday79 at gmail.com>
Cc: rtk-users at openrtk.org
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

Ok. Can you try rtkramp with only one projection? Then you shouldn't encounter this regions issue (that should be solved one day but that's a different story). 

Can you also indicate which version of CUDA you're using?

FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft for the FFT of the projections. So if they are not in the same format, you're in trouble and that might be the issue here... The weird part is that I didn't reproduce this problem on linux (with and without FFTW) but it might be a CUDA version difference. I'll give it another try tomorrow when you provide the CUDA version.

Thanks again for reporting the issue,
Simon

 

On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> > wrote:

Hi Simon,

 

Thanks for the advice. The current RTK was compiled with FFTW to use the phase extraction feature from Amsterdam shroud.

 

Regarding your suggestions,

 

1)      rtkramp w/ or w/o CUDA:

(command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda --output Ramp_wCUDA.mha? )

 

Then, I have encountered following error.

?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that input requested and buffered regions are equal.?

 



 

Without CUDA, it was successfully done.

 

2)      I?ve re-compiled ITK w/o FFTW and built RTK again. rtkfdk worked fine.

-          I?ve also repeated ?rtkramp+CUDA? with this rtk version and the error was same as above.

 

In conclusion, my FFTW seems to affect CUDA-based fdk reconstruction only.

But I do need FFTW for the phase extraction. What should I do?

 

Thanks.

 

Yang

 

 

-----Original Message-----
From: simon.rit at gmail.com <mailto:simon.rit at gmail.com>  [mailto:simon.rit at gmail.com <mailto:simon.rit at gmail.com> ] On Behalf Of Simon Rit
Sent: Wednesday, November 11, 2015 4:16 PM
To: Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> >
Cc: rtk-users at openrtk.org <mailto:rtk-users at openrtk.org> 
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

I didn't manage to reproduce the two problems on linux with the same ITK version.

For point 1, did you copy itkMacro.h by hand? Because I don't see how replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW? It looks like a ramp filter issue. Can you try rtkramp --path projPath --regexp .*.his, with and without --hardware cuda? Maybe you can provide your geometry file in case it's a specific geometric issue.

Simon

 

On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park < <mailto:theday79 at gmail.com> theday79 at gmail.com> wrote:

> Hi all,

> 

> 

> 

> I?ve updated rtk with the up-to-date revision and have encountered a 

> couple of problems.

> 

> 

> 

> 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled

> rtkCudaUtilities.hcu. It was solved by a minor fetching:

> 

> #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu

> 

> 

> 

> 2.       Output of rtkfdk with CUDA was not the same as before. It was very

> blurry as seen in the attached image.

> 

> a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.

> 

> 

> 

> 

> 

> I?m using VS2013 with win7, itk4.8.1.

> 

> 

> 

> The command line I used was :

> 

> rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his 

> --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware 

> cuda --pad 1 --hann 5 --hannY 5

> 

> 

> 

> Does anyone have any idea about this?

> 

> 

> 

> Thanks.

> 

> 

> 

> Yang

> 

> 

> 

> 

> _______________________________________________

> Rtk-users mailing list

>  <mailto: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/20151116/e77c2f96/attachment-0010.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151116/e77c2f96/attachment-0010.png>

From simon.rit at creatis.insa-lyon.fr  Mon Nov 16 10:07:46 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Mon, 16 Nov 2015 16:07:46 +0100
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
 <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
Message-ID: <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>

Hi,
Thanks. It's really weird... When you run the tests with FFTW (compiling
the "test" target), do they fail?
Can you provide your geometry file? It might be specific to this geometry.
Thanks again for looking into this issue, we'll find what's the problem.
Simon

On Mon, Nov 16, 2015 at 3:54 PM, Yang K Park <theday79 at gmail.com> wrote:

> Hi Simon,
>
>
>
> Sorry for the late response.
>
>
>
> As you suggested, I?ve tried rtkramp+CUDA with only one projection and it
> was successfully done for both w/ FFTW and w/o FFTW.
>
> (Two results were exactly same.)
>
>
>
> Regarding  the CUDA version, I?m using v6.5.
>
>
>
> Thanks a lot for the help!
>
>
>
> Yang
>
>
>
>
>
> *From:* simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of *Simon
> Rit
> *Sent:* Thursday, November 12, 2015 5:59 PM
>
> *To:* Yang K Park <theday79 at gmail.com>
> *Cc:* rtk-users at openrtk.org
> *Subject:* Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
> update
>
>
>
> Hi,
>
> Ok. Can you try rtkramp with only one projection? Then you shouldn't
> encounter this regions issue (that should be solved one day but that's a
> different story).
>
> Can you also indicate which version of CUDA you're using?
>
> FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft for
> the FFT of the projections. So if they are not in the same format, you're
> in trouble and that might be the issue here... The weird part is that I
> didn't reproduce this problem on linux (with and without FFTW) but it might
> be a CUDA version difference. I'll give it another try tomorrow when you
> provide the CUDA version.
>
> Thanks again for reporting the issue,
> Simon
>
>
>
> On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com> wrote:
>
> Hi Simon,
>
>
>
> Thanks for the advice. The current RTK was compiled with FFTW to use the
> phase extraction feature from Amsterdam shroud.
>
>
>
> Regarding your suggestions,
>
>
>
> 1)      rtkramp w/ or w/o CUDA:
>
> (command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda
> --output Ramp_wCUDA.mha? )
>
>
>
> Then, I have encountered following error.
>
> ?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that
> input requested and buffered regions are equal.?
>
>
>
>
>
> Without CUDA, it was successfully done.
>
>
>
> 2)      I?ve re-compiled *ITK w/o FFTW* and built RTK again. r*tkfdk
> worked fine.*
>
> -          I?ve also repeated ?rtkramp+CUDA? with this rtk version and
> the error was same as above.
>
>
>
> In conclusion, my *FFTW seems to affect CUDA-based fdk reconstruction
> only*.
>
> But I do need FFTW for the phase extraction. What should I do?
>
>
>
> Thanks.
>
>
>
> Yang
>
>
>
>
>
> -----Original Message-----
> From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon
> Rit
> Sent: Wednesday, November 11, 2015 4:16 PM
> To: Yang K Park <theday79 at gmail.com>
> Cc: rtk-users at openrtk.org
> Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
> update
>
>
>
> Hi,
>
> I didn't manage to reproduce the two problems on linux with the same ITK
> version.
>
> For point 1, did you copy itkMacro.h by hand? Because I don't see how
> replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the
> same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW?
> It looks like a ramp filter issue. Can you try rtkramp --path projPath
> --regexp .*.his, with and without --hardware cuda? Maybe you can provide
> your geometry file in case it's a specific geometric issue.
>
> Simon
>
>
>
> On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
>
> > Hi all,
>
> >
>
> >
>
> >
>
> > I?ve updated rtk with the up-to-date revision and have encountered a
>
> > couple of problems.
>
> >
>
> >
>
> >
>
> > 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
>
> > rtkCudaUtilities.hcu. It was solved by a minor fetching:
>
> >
>
> > #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>
> >
>
> >
>
> >
>
> > 2.       Output of rtkfdk with CUDA was not the same as before. It was
> very
>
> > blurry as seen in the attached image.
>
> >
>
> > a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > I?m using VS2013 with win7, itk4.8.1.
>
> >
>
> >
>
> >
>
> > The command line I used was :
>
> >
>
> > rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his
>
> > --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware
>
> > cuda --pad 1 --hann 5 --hannY 5
>
> >
>
> >
>
> >
>
> > Does anyone have any idea about this?
>
> >
>
> >
>
> >
>
> > Thanks.
>
> >
>
> >
>
> >
>
> > Yang
>
> >
>
> >
>
> >
>
> >
>
> > _______________________________________________
>
> > 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/20151116/38acfca5/attachment-0010.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151116/38acfca5/attachment-0010.png>

From theday79 at gmail.com  Mon Nov 16 10:47:43 2015
From: theday79 at gmail.com (Yang-Kyun Park)
Date: Mon, 16 Nov 2015 10:47:43 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
 <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
 <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>
Message-ID: <CAJM7=xjBjx=FzLazWJWqJbV5d45zGi2U71NKejm9HxKhJ0-xLQ@mail.gmail.com>

Hi Simon,

For better understanding, I'm attaching the problematic case including
projection files, geometry file(xml) and reconstructed images.(please find
the GDrive links. The file size is ~800 MB)
This is phantom data and there is no patient information in it.

Regarding the fftw library, I'm using [fftw-3.3.4-dll64].

By the way, I found another clue. When I've tried it with a head phantom
image (full-fan, ~ 190 projections), there was no problem. Is there any
possibility that DDF and parker short filter play some roles on this issue?

Feel free to let me know if further data is needed.

Thanks!

Yang

?
 FFTW_issue.zip
<https://drive.google.com/file/d/0BxuP3mON9V-qbVdQd0luc1lIb2M/view?usp=drive_web>
?

On Mon, Nov 16, 2015 at 10:07 AM, Simon Rit <simon.rit at creatis.insa-lyon.fr>
wrote:

> Hi,
> Thanks. It's really weird... When you run the tests with FFTW (compiling
> the "test" target), do they fail?
> Can you provide your geometry file? It might be specific to this geometry.
> Thanks again for looking into this issue, we'll find what's the problem.
> Simon
>
> On Mon, Nov 16, 2015 at 3:54 PM, Yang K Park <theday79 at gmail.com> wrote:
>
>> Hi Simon,
>>
>>
>>
>> Sorry for the late response.
>>
>>
>>
>> As you suggested, I?ve tried rtkramp+CUDA with only one projection and it
>> was successfully done for both w/ FFTW and w/o FFTW.
>>
>> (Two results were exactly same.)
>>
>>
>>
>> Regarding  the CUDA version, I?m using v6.5.
>>
>>
>>
>> Thanks a lot for the help!
>>
>>
>>
>> Yang
>>
>>
>>
>>
>>
>> *From:* simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of *Simon
>> Rit
>> *Sent:* Thursday, November 12, 2015 5:59 PM
>>
>> *To:* Yang K Park <theday79 at gmail.com>
>> *Cc:* rtk-users at openrtk.org
>> *Subject:* Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
>> update
>>
>>
>>
>> Hi,
>>
>> Ok. Can you try rtkramp with only one projection? Then you shouldn't
>> encounter this regions issue (that should be solved one day but that's a
>> different story).
>>
>> Can you also indicate which version of CUDA you're using?
>>
>> FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft
>> for the FFT of the projections. So if they are not in the same format,
>> you're in trouble and that might be the issue here... The weird part is
>> that I didn't reproduce this problem on linux (with and without FFTW) but
>> it might be a CUDA version difference. I'll give it another try tomorrow
>> when you provide the CUDA version.
>>
>> Thanks again for reporting the issue,
>> Simon
>>
>>
>>
>> On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com> wrote:
>>
>> Hi Simon,
>>
>>
>>
>> Thanks for the advice. The current RTK was compiled with FFTW to use the
>> phase extraction feature from Amsterdam shroud.
>>
>>
>>
>> Regarding your suggestions,
>>
>>
>>
>> 1)      rtkramp w/ or w/o CUDA:
>>
>> (command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda
>> --output Ramp_wCUDA.mha? )
>>
>>
>>
>> Then, I have encountered following error.
>>
>> ?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that
>> input requested and buffered regions are equal.?
>>
>>
>>
>>
>>
>> Without CUDA, it was successfully done.
>>
>>
>>
>> 2)      I?ve re-compiled *ITK w/o FFTW* and built RTK again. r*tkfdk
>> worked fine.*
>>
>> -          I?ve also repeated ?rtkramp+CUDA? with this rtk version and
>> the error was same as above.
>>
>>
>>
>> In conclusion, my *FFTW seems to affect CUDA-based fdk reconstruction
>> only*.
>>
>> But I do need FFTW for the phase extraction. What should I do?
>>
>>
>>
>> Thanks.
>>
>>
>>
>> Yang
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of
>> Simon Rit
>> Sent: Wednesday, November 11, 2015 4:16 PM
>> To: Yang K Park <theday79 at gmail.com>
>> Cc: rtk-users at openrtk.org
>> Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
>> update
>>
>>
>>
>> Hi,
>>
>> I didn't manage to reproduce the two problems on linux with the same ITK
>> version.
>>
>> For point 1, did you copy itkMacro.h by hand? Because I don't see how
>> replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the
>> same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW?
>> It looks like a ramp filter issue. Can you try rtkramp --path projPath
>> --regexp .*.his, with and without --hardware cuda? Maybe you can provide
>> your geometry file in case it's a specific geometric issue.
>>
>> Simon
>>
>>
>>
>> On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
>>
>> > Hi all,
>>
>> >
>>
>> >
>>
>> >
>>
>> > I?ve updated rtk with the up-to-date revision and have encountered a
>>
>> > couple of problems.
>>
>> >
>>
>> >
>>
>> >
>>
>> > 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
>>
>> > rtkCudaUtilities.hcu. It was solved by a minor fetching:
>>
>> >
>>
>> > #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>>
>> >
>>
>> >
>>
>> >
>>
>> > 2.       Output of rtkfdk with CUDA was not the same as before. It was
>> very
>>
>> > blurry as seen in the attached image.
>>
>> >
>>
>> > a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>
>> > I?m using VS2013 with win7, itk4.8.1.
>>
>> >
>>
>> >
>>
>> >
>>
>> > The command line I used was :
>>
>> >
>>
>> > rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his
>>
>> > --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware
>>
>> > cuda --pad 1 --hann 5 --hannY 5
>>
>> >
>>
>> >
>>
>> >
>>
>> > Does anyone have any idea about this?
>>
>> >
>>
>> >
>>
>> >
>>
>> > Thanks.
>>
>> >
>>
>> >
>>
>> >
>>
>> > Yang
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>
>> > _______________________________________________
>>
>> > 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/20151116/90d2c5a0/attachment-0010.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151116/90d2c5a0/attachment-0010.png>

From simon.rit at creatis.insa-lyon.fr  Fri Nov 20 11:28:22 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Fri, 20 Nov 2015 17:28:22 +0100
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAJM7=xjBjx=FzLazWJWqJbV5d45zGi2U71NKejm9HxKhJ0-xLQ@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
 <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
 <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>
 <CAJM7=xjBjx=FzLazWJWqJbV5d45zGi2U71NKejm9HxKhJ0-xLQ@mail.gmail.com>
Message-ID: <CAF0oig027_u_9gb8bnwT1w9jr3epZ0hkd9Mt73qK5heUq_kCkg@mail.gmail.com>

Hi Yang,
Thanks a lot for sharing the data. I have good news. I could reproduce the
bug and I have solutions. First, about your dataset: it's a huge dataset
and the hannY requires zero padding in both x and y. Because of this, cufft
has to take the 2D FFT of projection subsets that are 4095x2048x16. Quite
big!
When I ran it on my cuda 7.0, I immediately got:

itk::ExceptionObject (0x8b9cb30)
Location: "void CUDA_fft_convolution(const int3&, const int2&, float*,
cufftComplex*)"
File: /home/srit/src/rtk/rtk/code/rtkCudaFFTConvolutionImageFilter.cu
Line: 97
Description: itk::ERROR: CUFFT ERROR #2

i.e., a GPU alloc issue, even if I have the largest possible memory on a
nvidia desktop computer. Then, I ran it with cuda 6.5 and I got no error
message but a result similar to yours.
Conclusions:
- if you add the option --subsetsize 1 to your rtkfdk command line, that
should reconstruct correctly
- if you upgrade cuda, you should get an understandable error message,
- I don't think I'm going to look for a solution because the pb is probably
in cufft but if someone is willing to, be my guest!
Simon

On Mon, Nov 16, 2015 at 4:47 PM, Yang-Kyun Park <theday79 at gmail.com> wrote:

> Hi Simon,
>
> For better understanding, I'm attaching the problematic case including
> projection files, geometry file(xml) and reconstructed images.(please find
> the GDrive links. The file size is ~800 MB)
> This is phantom data and there is no patient information in it.
>
> Regarding the fftw library, I'm using [fftw-3.3.4-dll64].
>
> By the way, I found another clue. When I've tried it with a head phantom
> image (full-fan, ~ 190 projections), there was no problem. Is there any
> possibility that DDF and parker short filter play some roles on this issue?
>
> Feel free to let me know if further data is needed.
>
> Thanks!
>
> Yang
>
> ?
>  FFTW_issue.zip
> <https://drive.google.com/file/d/0BxuP3mON9V-qbVdQd0luc1lIb2M/view?usp=drive_web>
> ?
>
> On Mon, Nov 16, 2015 at 10:07 AM, Simon Rit <
> simon.rit at creatis.insa-lyon.fr> wrote:
>
>> Hi,
>> Thanks. It's really weird... When you run the tests with FFTW (compiling
>> the "test" target), do they fail?
>> Can you provide your geometry file? It might be specific to this geometry.
>> Thanks again for looking into this issue, we'll find what's the problem.
>> Simon
>>
>> On Mon, Nov 16, 2015 at 3:54 PM, Yang K Park <theday79 at gmail.com> wrote:
>>
>>> Hi Simon,
>>>
>>>
>>>
>>> Sorry for the late response.
>>>
>>>
>>>
>>> As you suggested, I?ve tried rtkramp+CUDA with only one projection and
>>> it was successfully done for both w/ FFTW and w/o FFTW.
>>>
>>> (Two results were exactly same.)
>>>
>>>
>>>
>>> Regarding  the CUDA version, I?m using v6.5.
>>>
>>>
>>>
>>> Thanks a lot for the help!
>>>
>>>
>>>
>>> Yang
>>>
>>>
>>>
>>>
>>>
>>> *From:* simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of *Simon
>>> Rit
>>> *Sent:* Thursday, November 12, 2015 5:59 PM
>>>
>>> *To:* Yang K Park <theday79 at gmail.com>
>>> *Cc:* rtk-users at openrtk.org
>>> *Subject:* Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
>>> update
>>>
>>>
>>>
>>> Hi,
>>>
>>> Ok. Can you try rtkramp with only one projection? Then you shouldn't
>>> encounter this regions issue (that should be solved one day but that's a
>>> different story).
>>>
>>> Can you also indicate which version of CUDA you're using?
>>>
>>> FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft
>>> for the FFT of the projections. So if they are not in the same format,
>>> you're in trouble and that might be the issue here... The weird part is
>>> that I didn't reproduce this problem on linux (with and without FFTW) but
>>> it might be a CUDA version difference. I'll give it another try tomorrow
>>> when you provide the CUDA version.
>>>
>>> Thanks again for reporting the issue,
>>> Simon
>>>
>>>
>>>
>>> On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com>
>>> wrote:
>>>
>>> Hi Simon,
>>>
>>>
>>>
>>> Thanks for the advice. The current RTK was compiled with FFTW to use the
>>> phase extraction feature from Amsterdam shroud.
>>>
>>>
>>>
>>> Regarding your suggestions,
>>>
>>>
>>>
>>> 1)      rtkramp w/ or w/o CUDA:
>>>
>>> (command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda
>>> --output Ramp_wCUDA.mha? )
>>>
>>>
>>>
>>> Then, I have encountered following error.
>>>
>>> ?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that
>>> input requested and buffered regions are equal.?
>>>
>>>
>>>
>>>
>>>
>>> Without CUDA, it was successfully done.
>>>
>>>
>>>
>>> 2)      I?ve re-compiled *ITK w/o FFTW* and built RTK again. r*tkfdk
>>> worked fine.*
>>>
>>> -          I?ve also repeated ?rtkramp+CUDA? with this rtk version and
>>> the error was same as above.
>>>
>>>
>>>
>>> In conclusion, my *FFTW seems to affect CUDA-based fdk reconstruction
>>> only*.
>>>
>>> But I do need FFTW for the phase extraction. What should I do?
>>>
>>>
>>>
>>> Thanks.
>>>
>>>
>>>
>>> Yang
>>>
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of
>>> Simon Rit
>>> Sent: Wednesday, November 11, 2015 4:16 PM
>>> To: Yang K Park <theday79 at gmail.com>
>>> Cc: rtk-users at openrtk.org
>>> Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent
>>> update
>>>
>>>
>>>
>>> Hi,
>>>
>>> I didn't manage to reproduce the two problems on linux with the same ITK
>>> version.
>>>
>>> For point 1, did you copy itkMacro.h by hand? Because I don't see how
>>> replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the
>>> same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW?
>>> It looks like a ramp filter issue. Can you try rtkramp --path projPath
>>> --regexp .*.his, with and without --hardware cuda? Maybe you can provide
>>> your geometry file in case it's a specific geometric issue.
>>>
>>> Simon
>>>
>>>
>>>
>>> On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park <theday79 at gmail.com> wrote:
>>>
>>> > Hi all,
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > I?ve updated rtk with the up-to-date revision and have encountered a
>>>
>>> > couple of problems.
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled
>>>
>>> > rtkCudaUtilities.hcu. It was solved by a minor fetching:
>>>
>>> >
>>>
>>> > #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > 2.       Output of rtkfdk with CUDA was not the same as before. It was
>>> very
>>>
>>> > blurry as seen in the attached image.
>>>
>>> >
>>>
>>> > a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > I?m using VS2013 with win7, itk4.8.1.
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > The command line I used was :
>>>
>>> >
>>>
>>> > rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his
>>>
>>> > --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware
>>>
>>> > cuda --pad 1 --hann 5 --hannY 5
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > Does anyone have any idea about this?
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > Thanks.
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > Yang
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> >
>>>
>>> > _______________________________________________
>>>
>>> > 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/20151120/4e6c0e1e/attachment-0010.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151120/4e6c0e1e/attachment-0010.png>

From theday79 at gmail.com  Fri Nov 20 12:36:51 2015
From: theday79 at gmail.com (Yang K Park)
Date: Fri, 20 Nov 2015 12:36:51 -0500
Subject: [Rtk-users] rtkfdk doesn't work correctly after a recent update
In-Reply-To: <CAF0oig027_u_9gb8bnwT1w9jr3epZ0hkd9Mt73qK5heUq_kCkg@mail.gmail.com>
References: <001601d11cb1$e0691ff0$a13b5fd0$@gmail.com>
 <CAF0oig3datym3D7ydaZJYh+VwHBO3ytr9txycJxDn6KqjMaXAA@mail.gmail.com>
 <000001d11d9b$04142320$0c3c6960$@gmail.com>
 <CAF0oig3WuwgS0DHLfhv7=sC0R-7V+usxT9kKCf0JOfTNB0uF+g@mail.gmail.com>
 <000b01d1207e$a1b2c1f0$e51845d0$@gmail.com>
 <CAF0oig1CFgUwpe9VOOU_=z0wpn1G-hw-T-S34RjY-cin7rh6iw@mail.gmail.com>
 <CAJM7=xjBjx=FzLazWJWqJbV5d45zGi2U71NKejm9HxKhJ0-xLQ@mail.gmail.com>
 <CAF0oig027_u_9gb8bnwT1w9jr3epZ0hkd9Mt73qK5heUq_kCkg@mail.gmail.com>
Message-ID: <000901d123ba$0ae3de50$20ab9af0$@gmail.com>

Hi Simon,

 

That sounds great! Thanks a lot for your hard work.

As you said, now I can reconstruct it successfully with --subsetsize option.

 

I think the only concern left is the elongated reconstruction time.

I?ve measured it for the same phantom image with different ?subsetsize? values as well as w/o FFTW compiling.

I just report it for your information.

 

1)      w/o FFTW  : 21.4 s

2)      w/ FFTW & --subsetsize 1: 89 s

3)      w/ FFTW & --subsetsize 2: 77 s

4)      w/ FFTW & --subsetsize 4: 65 s

5)      w/ FFTW & --subsetsize 6: 51 s

6)      w/ FFTW & --subsetsize 7: (Error-graphic card seemed to be freezed)

7)      w/ FFTW & --subsetsize 8: (Error-?itk::ERROR: CUFFT ERROR #2 in rtkCudaFFTConvolutionImageFilter.cu?)

 

Of course, the difference was coming from the Ramp filter.

Therefore, I?m going to use [--subsetsize 6] for my system and will update CUDA version soon!

 

Thanks.

 

Yang

 

 

From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit
Sent: Friday, November 20, 2015 11:28 AM
To: Yang-Kyun Park <theday79 at gmail.com>
Cc: rtk-users at openrtk.org
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi Yang,
Thanks a lot for sharing the data. I have good news. I could reproduce the bug and I have solutions. First, about your dataset: it's a huge dataset and the hannY requires zero padding in both x and y. Because of this, cufft has to take the 2D FFT of projection subsets that are 4095x2048x16. Quite big!

When I ran it on my cuda 7.0, I immediately got:

itk::ExceptionObject (0x8b9cb30)
Location: "void CUDA_fft_convolution(const int3&, const int2&, float*, cufftComplex*)" 
File: /home/srit/src/rtk/rtk/code/rtkCudaFFTConvolutionImageFilter.cu
Line: 97
Description: itk::ERROR: CUFFT ERROR #2

i.e., a GPU alloc issue, even if I have the largest possible memory on a nvidia desktop computer. Then, I ran it with cuda 6.5 and I got no error message but a result similar to yours.

Conclusions:

- if you add the option --subsetsize 1 to your rtkfdk command line, that should reconstruct correctly

- if you upgrade cuda, you should get an understandable error message,

- I don't think I'm going to look for a solution because the pb is probably in cufft but if someone is willing to, be my guest!

Simon

 

On Mon, Nov 16, 2015 at 4:47 PM, Yang-Kyun Park <theday79 at gmail.com <mailto:theday79 at gmail.com> > wrote:

Hi Simon,

 

For better understanding, I'm attaching the problematic case including projection files, geometry file(xml) and reconstructed images.(please find the GDrive links. The file size is ~800 MB)

This is phantom data and there is no patient information in it.

 

Regarding the fftw library, I'm using [fftw-3.3.4-dll64].

 

By the way, I found another clue. When I've tried it with a head phantom image (full-fan, ~ 190 projections), there was no problem. Is there any possibility that DDF and parker short filter play some roles on this issue?

 

Feel free to let me know if further data is needed.

 

Thanks!

 

Yang

 

?

 <https://drive.google.com/file/d/0BxuP3mON9V-qbVdQd0luc1lIb2M/view?usp=drive_web>  FFTW_issue.zip

?

 

On Mon, Nov 16, 2015 at 10:07 AM, Simon Rit <simon.rit at creatis.insa-lyon.fr <mailto:simon.rit at creatis.insa-lyon.fr> > wrote:

Hi,

Thanks. It's really weird... When you run the tests with FFTW (compiling the "test" target), do they fail?
Can you provide your geometry file? It might be specific to this geometry.

Thanks again for looking into this issue, we'll find what's the problem.

Simon

 

On Mon, Nov 16, 2015 at 3:54 PM, Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> > wrote:

Hi Simon,

 

Sorry for the late response.

 

As you suggested, I?ve tried rtkramp+CUDA with only one projection and it was successfully done for both w/ FFTW and w/o FFTW.

(Two results were exactly same.)

 

Regarding  the CUDA version, I?m using v6.5.

 

Thanks a lot for the help!

 

Yang

 

 

From: simon.rit at gmail.com <mailto:simon.rit at gmail.com>  [mailto:simon.rit at gmail.com <mailto:simon.rit at gmail.com> ] On Behalf Of Simon Rit
Sent: Thursday, November 12, 2015 5:59 PM


To: Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> >
Cc: rtk-users at openrtk.org <mailto:rtk-users at openrtk.org> 
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

Ok. Can you try rtkramp with only one projection? Then you shouldn't encounter this regions issue (that should be solved one day but that's a different story). 

Can you also indicate which version of CUDA you're using?

FYI, we use ITK for the FFT of the kernel of the ramp filter and cufft for the FFT of the projections. So if they are not in the same format, you're in trouble and that might be the issue here... The weird part is that I didn't reproduce this problem on linux (with and without FFTW) but it might be a CUDA version difference. I'll give it another try tomorrow when you provide the CUDA version.

Thanks again for reporting the issue,
Simon

 

On Thu, Nov 12, 2015 at 11:39 PM, Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> > wrote:

Hi Simon,

 

Thanks for the advice. The current RTK was compiled with FFTW to use the phase extraction feature from Amsterdam shroud.

 

Regarding your suggestions,

 

1)      rtkramp w/ or w/o CUDA:

(command line: ? rtkramp --path projPath --regexp .*.his --hardware cuda --output Ramp_wCUDA.mha? )

 

Then, I have encountered following error.

?CudaFFTRampImageFilter<..> CudaFFTConvolutionImageFilter assumes that input requested and buffered regions are equal.?

 



 

Without CUDA, it was successfully done.

 

2)      I?ve re-compiled ITK w/o FFTW and built RTK again. rtkfdk worked fine.

-          I?ve also repeated ?rtkramp+CUDA? with this rtk version and the error was same as above.

 

In conclusion, my FFTW seems to affect CUDA-based fdk reconstruction only.

But I do need FFTW for the phase extraction. What should I do?

 

Thanks.

 

Yang

 

 

-----Original Message-----
From: simon.rit at gmail.com <mailto:simon.rit at gmail.com>  [mailto:simon.rit at gmail.com <mailto:simon.rit at gmail.com> ] On Behalf Of Simon Rit
Sent: Wednesday, November 11, 2015 4:16 PM
To: Yang K Park <theday79 at gmail.com <mailto:theday79 at gmail.com> >
Cc: rtk-users at openrtk.org <mailto:rtk-users at openrtk.org> 
Subject: Re: [Rtk-users] rtkfdk doesn't work correctly after a recent update

 

Hi,

I didn't manage to reproduce the two problems on linux with the same ITK version.

For point 1, did you copy itkMacro.h by hand? Because I don't see how replacing <itkMacro.h> by "itkMacro.h" can help if itkMacro.h is not in the same folder as rtkCudaUtilities.hcu For point 2, no clue. Do you use FFTW? It looks like a ramp filter issue. Can you try rtkramp --path projPath --regexp .*.his, with and without --hardware cuda? Maybe you can provide your geometry file in case it's a specific geometric issue.

Simon

 

On Wed, Nov 11, 2015 at 7:50 PM, Yang K Park < <mailto:theday79 at gmail.com> theday79 at gmail.com> wrote:

> Hi all,

> 

> 

> 

> I?ve updated rtk with the up-to-date revision and have encountered a 

> couple of problems.

> 

> 

> 

> 1.       Compile error: RTK couldn?t find itkMacro.h while it compiled

> rtkCudaUtilities.hcu. It was solved by a minor fetching:

> 

> #include <itkMacro.h>   ? #include "itkMacro.h" in rtkCudaUtilities.hcu

> 

> 

> 

> 2.       Output of rtkfdk with CUDA was not the same as before. It was very

> blurry as seen in the attached image.

> 

> a.       With ?FDK with CPU? or ?SART with CUDA?, there was no problem.

> 

> 

> 

> 

> 

> I?m using VS2013 with win7, itk4.8.1.

> 

> 

> 

> The command line I used was :

> 

> rtkfdk --geometry 1111.xml --path projPath --verbos --regexp .*.his 

> --output output.mha --spacing 1,1,1 --dimension 400,200,400 --hardware 

> cuda --pad 1 --hann 5 --hannY 5

> 

> 

> 

> Does anyone have any idea about this?

> 

> 

> 

> Thanks.

> 

> 

> 

> Yang

> 

> 

> 

> 

> _______________________________________________

> Rtk-users mailing list

>  <mailto: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/20151120/0d98ace1/attachment-0010.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5752 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151120/0d98ace1/attachment-0010.png>

From simon.rit at creatis.insa-lyon.fr  Wed Nov 25 02:36:44 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Wed, 25 Nov 2015 08:36:44 +0100
Subject: [Rtk-users] Compiling Problem
In-Reply-To: <040e01d125c7$83648e60$8a2dab20$@126.com>
References: <040e01d125c7$83648e60$8a2dab20$@126.com>
Message-ID: <5655650C.1040500@creatis.insa-lyon.fr>

Hi,
Please use the mailing list. I don't know where does the linking problem 
come from and it seems to work on our side:
http://my.cdash.org/index.php?project=RTK
Have you tried disabling CUDA?
Simon

On 23/11/2015 09:18, Freyman li wrote:
>
> Dear Simon,
>
> Recently I configured the RTK tool and suffer some problems. After set 
> up the itk tool and cuda, I compiled the rtk application but 
> encountered two errors attached to the email(jpg format)
>
> CUDA and ITK environment are tested successfully. My compile tool is 
> Visual studio 2012(64bit) and CUDA version is v6.5.
>
> Can you tell me how to deal with it and I am looking forward to hear 
> you again.
>
> Thank you!
>
> Best Regards
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151125/285f7f3c/attachment-0010.html>

From theday79 at gmail.com  Wed Nov 25 12:38:52 2015
From: theday79 at gmail.com (Yang K Park)
Date: Wed, 25 Nov 2015 12:38:52 -0500
Subject: [Rtk-users] Compiling Problem
In-Reply-To: <5655650C.1040500@creatis.insa-lyon.fr>
References: <040e01d125c7$83648e60$8a2dab20$@126.com>
 <5655650C.1040500@creatis.insa-lyon.fr>
Message-ID: <003d01d127a8$27a52b60$76ef8220$@gmail.com>

Hi Freyman,

 

I think your setting is much similar to mine, since I have compiled RTK with
VS2013 and CUDA v6.5 several times. Can you post those error messages again
so that I can see?

Yang

 

 

From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of
Simon Rit
Sent: Wednesday, November 25, 2015 2:37 AM
To: Freyman li <lihanwei_1500 at 126.com>
Cc: rtk-users at openrtk.org
Subject: Re: [Rtk-users] Compiling Problem

 

Hi,
Please use the mailing list. I don't know where does the linking problem
come from and it seems to work on our side:
http://my.cdash.org/index.php?project=RTK
Have you tried disabling CUDA?
Simon

On 23/11/2015 09:18, Freyman li wrote:

Dear Simon,

 

Recently I configured the RTK tool and suffer some problems. After set up
the itk tool and cuda, I compiled the rtk application but encountered two
errors attached to the email(jpg format)

CUDA and ITK environment are tested successfully. My compile tool is Visual
studio 2012(64bit) and CUDA version is v6.5.

Can you tell me how to deal with it and I am looking forward to hear you
again.

Thank you!

 

Best Regards

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151125/984feb50/attachment-0010.html>

From bioniloofar at gmail.com  Mon Nov 30 06:06:41 2015
From: bioniloofar at gmail.com (niloufar teyfouri)
Date: Mon, 30 Nov 2015 14:36:41 +0330
Subject: [Rtk-users] ElectaReconstruction
Message-ID: <CALChM12F4PuiLvgENg3Yyn7E+uZ7iPJ+GiY04z7VQ-90AS83EA@mail.gmail.com>

I ran the application of Electa Reconstruction implemented by you with
RTK. But after debugging I was encountered with the message of
"--output' ('-o') option required". Could you please help me for running
this example and the other ones?
I don't know any thing about the texts in the gray boxes mentioned at
each link related to examples of RTK.
For example in the link of
http://wiki.openrtk.org/index.php/RTK/Examples/ElektaReconstruction
how I should use gengetopt for the instructions below?


2. Run the application to convert Elekta's geometry into RTKs (DICOM_UID
is contained in the subfolder name of the his files):

  rtkelektasynergygeometry \
    --image_db IMAGE.DBF \
    --frame_db FRAME.DBF \
    --dicom_uid 1.3.46.423632.135428.1351013645.166 \
    -o elektaGeometry

I would be appreciate if one could answer my question.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151130/b11ad4e2/attachment-0010.html>

From cyril.mory at uclouvain.be  Mon Nov 30 09:30:48 2015
From: cyril.mory at uclouvain.be (Cyril Mory)
Date: Mon, 30 Nov 2015 15:30:48 +0100
Subject: [Rtk-users] ElectaReconstruction
In-Reply-To: <CALChM12F4PuiLvgENg3Yyn7E+uZ7iPJ+GiY04z7VQ-90AS83EA@mail.gmail.com>
References: <CALChM12F4PuiLvgENg3Yyn7E+uZ7iPJ+GiY04z7VQ-90AS83EA@mail.gmail.com>
Message-ID: <565C5D98.1000309@uclouvain.be>

Hi, and welcome to RTK,

Gengetopt is the piece of software that parses the command line 
arguments in all RTK applications. You do not have to "use" it. You just 
need to give correct arguments on the command line.

The message "--output' ('-o') option required" means what it says : you 
need to provide the name of the file in which you want to store the 
geometry information generated by the application 
rtkelektasynergygeometry. If you just copy-pasted the command you found 
on the wiki, then something went wrong during the copy-paste. Try to run 
the following :

rtkelektasynergygeometry --image_db IMAGE.DBF --frame_db FRAME.DBF 
--dicom_uid 1.3.46.423632.135428.1351013645.166 -o elektaGeometry

I just removed the '\' and the useless spaces. You can do the same for 
all other command line examples and it should work.

Let us know if you keep encountering trouble.
Cyril


Le 30/11/2015 12:06, niloufar teyfouri a ?crit :
>
> I ran the application of Electa Reconstruction implemented by you with
> RTK. But after debugging I was encountered with the message of
> "--output' ('-o') option required". Could you please help me for running
> this example and the other ones?
> I don't know any thing about the texts in the gray boxes mentioned at
> each link related to examples of RTK.
> For example in the link of
> http://wiki.openrtk.org/index.php/RTK/Examples/ElektaReconstruction
> how I should use gengetopt for the instructions below?
>
>
> 2. Run the application to convert Elekta's geometry into RTKs (DICOM_UID
> is contained in the subfolder name of the his files):
>
> rtkelektasynergygeometry \
> --image_db IMAGE.DBF \
> --frame_db FRAME.DBF \
> --dicom_uid 1.3.46.423632.135428.1351013645.166 \
>     -o elektaGeometry
>
> I would be appreciate if one could answer my question.
>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20151130/66741755/attachment-0010.html>

From j.mason at ed.ac.uk  Mon Nov 30 11:29:27 2015
From: j.mason at ed.ac.uk (Jonathan Mason)
Date: Mon, 30 Nov 2015 16:29:27 +0000
Subject: [Rtk-users] Preprocessing
Message-ID: <565C7967.4000401@ed.ac.uk>

Good afternoon RTK users,

I have access to "raw data" from a Varian OBI scanner, and have
experimented with RTK for performing its reconstruction. However, it is
not really "raw" in the sense that the coefficients are proportional to
the photon flux recorded at a given sensor, but is instead proportional
to the Hounsfield attenuation along that path. With this data, it means
that one can reconstruct using FDK and other iterative techniques, which
assume a linear model, but the connection to the underlying physics is
abstract.

The problem I then have when trying to develop reconstruction
techniques, is that I do not know whether I am really correcting for
physical distortions or just correcting for Varian's preprocessing,
which has been finely tuned for its own FDK method.

My question is whether anybody has dug into the steps that manufacturers
such as Varian or Elekta perform to arrive at these projection images?
And if they think that if reverse engineered, could provide a richer set
of information to facilitate advanced strategies.

Best wishes,

Jonathan Mason

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.



From simon.rit at creatis.insa-lyon.fr  Mon Nov 30 12:44:03 2015
From: simon.rit at creatis.insa-lyon.fr (Simon Rit)
Date: Mon, 30 Nov 2015 18:44:03 +0100
Subject: [Rtk-users] ElectaReconstruction
In-Reply-To: <565C5D98.1000309@uclouvain.be>
References: <CALChM12F4PuiLvgENg3Yyn7E+uZ7iPJ+GiY04z7VQ-90AS83EA@mail.gmail.com>
 <565C5D98.1000309@uclouvain.be>
Message-ID: <CAF0oig2Zg96AZaRn9w9=F+LnLnyteTn5zS1rLguQ8WXiYhnnYg@mail.gmail.com>

Hi,
I think Cyril is right, it's not possible to use backslashes to put a
command line on several line with Windows command line. Can you confirm
this? If you confirm, we will correct the wiki.
Thanks,
Simon

On Mon, Nov 30, 2015 at 3:30 PM, Cyril Mory <cyril.mory at uclouvain.be> wrote:

> Hi, and welcome to RTK,
>
> Gengetopt is the piece of software that parses the command line arguments
> in all RTK applications. You do not have to "use" it. You just need to give
> correct arguments on the command line.
>
> The message "--output' ('-o') option required" means what it says : you
> need to provide the name of the file in which you want to store the
> geometry information generated by the application rtkelektasynergygeometry.
> If you just copy-pasted the command you found on the wiki, then something
> went wrong during the copy-paste. Try to run the following :
>
> rtkelektasynergygeometry --image_db IMAGE.DBF --frame_db FRAME.DBF
> --dicom_uid 1.3.46.423632.135428.1351013645.166 -o elektaGeometry
>
> I just removed the '\' and the useless spaces. You can do the same for all
> other command line examples and it should work.
>
> Let us know if you keep encountering trouble.
> Cyril
>
>
>
> Le 30/11/2015 12:06, niloufar teyfouri a ?crit :
>
>
> I ran the application of Electa Reconstruction implemented by you with
> RTK. But after debugging I was encountered with the message of
> "--output' ('-o') option required". Could you please help me for running
> this example and the other ones?
> I don't know any thing about the texts in the gray boxes mentioned at
> each link related to examples of RTK.
> For example in the link of
> http://wiki.openrtk.org/index.php/RTK/Examples/ElektaReconstruction
> how I should use gengetopt for the instructions below?
>
>
> 2. Run the application to convert Elekta's geometry into RTKs (DICOM_UID
> is contained in the subfolder name of the his files):
>
>   rtkelektasynergygeometry \
>     --image_db IMAGE.DBF \
>     --frame_db FRAME.DBF \
>     --dicom_uid 1.3.46.423632.135428.1351013645.166 \
>     -o elektaGeometry
>
> I would be appreciate if one could answer my question.
>
>
> _______________________________________________
> Rtk-users mailing listRtk-users at public.kitware.comhttp://public.kitware.com/mailman/listinfo/rtk-users
>
>
>
>
> ------------------------------
> [image: Avast logo] <https://www.avast.com/antivirus>
>
> L'absence de virus dans ce courrier ?lectronique a ?t? v?rifi?e par le
> logiciel antivirus Avast.
> www.avast.com <https://www.avast.com/antivirus>
>
>
> _______________________________________________
> 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/20151130/6d6dd6aa/attachment-0010.html>

From wuchao04 at gmail.com  Mon Nov 30 13:50:06 2015
From: wuchao04 at gmail.com (Chao Wu)
Date: Mon, 30 Nov 2015 19:50:06 +0100
Subject: [Rtk-users] Preprocessing
In-Reply-To: <565C7967.4000401@ed.ac.uk>
References: <565C7967.4000401@ed.ac.uk>
Message-ID: <CAH+sHrUFov5f=8h4-ePhC2xLraM3BxA9r12yfXdM3rrKPeqCBg@mail.gmail.com>

Hi Jonathan,

I do not quite understand your problem.
I think most information can be retrieved by the relationship between flux
(I) and attenuation (u):
I = I0 * exp (- integral(u * dL) )
Of course there are other effects like beam hardening and scattering
involved but this model is the basic.

Regards,
Chao

2015-11-30 17:29 GMT+01:00 Jonathan Mason <j.mason at ed.ac.uk>:

> Good afternoon RTK users,
>
> I have access to "raw data" from a Varian OBI scanner, and have
> experimented with RTK for performing its reconstruction. However, it is
> not really "raw" in the sense that the coefficients are proportional to
> the photon flux recorded at a given sensor, but is instead proportional
> to the Hounsfield attenuation along that path. With this data, it means
> that one can reconstruct using FDK and other iterative techniques, which
> assume a linear model, but the connection to the underlying physics is
> abstract.
>
> The problem I then have when trying to develop reconstruction
> techniques, is that I do not know whether I am really correcting for
> physical distortions or just correcting for Varian's preprocessing,
> which has been finely tuned for its own FDK method.
>
> My question is whether anybody has dug into the steps that manufacturers
> such as Varian or Elekta perform to arrive at these projection images?
> And if they think that if reverse engineered, could provide a richer set
> of information to facilitate advanced strategies.
>
> Best wishes,
>
> Jonathan Mason
>
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
> _______________________________________________
> 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/20151130/ccb833fe/attachment-0010.html>