[Rtk-users] question about rtkDraw*ImageFilter

[Mathieu Dupont]

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
>
>