[Rtk-users] question about rtkDraw*ImageFilter

Simon Rit simon.rit at creatis.insa-lyon.fr
Wed Nov 4 16:38:18 EST 2015


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>


More information about the Rtk-users mailing list