[Rtk-users] question about rtkDraw*ImageFilter

[Mathieu Dupont]

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