[Insight-developers] ITKv4 Modularization Plan

Gaëtan Lehmann gaetan.lehmann at jouy.inra.fr
Wed Feb 9 03:54:26 EST 2011 

Hi Xiaoxiao,

Can you tell me what you think of reducing the size of itk-common and  
itk-intensity-math?
As they are, they will probably be problematic for the wrapping.

More comments inlined.


Le 8 févr. 11 à 22:26, Xiaoxiao Liu a écrit :

> Hi Gaëtan,
>
> Thanks so much for the detailed investigation.
> We will take a deeper look but here is a brief answer from my point  
> of view.
>
> * no itk-fftw? As for the io modules, I guess this would simplify  
> the management of the dependency on FFTW. I'm not sure how we can  
> ensure that FFTW will be used if it is available however - is it  
> possible to ensure that behavior with the itk factories?  >>>> Not  
> sure I understand your question about  the io modules.. There are  
> some license issues with itk-fftw, and Luis will have a  better  
> answer on this one.

This is probably a bad understanding on my side. I thought that the IO  
modules have been splitted to allow to not build the ones with some  
dependencies on third party libraries.

>
> * MedianImageFilter .h and .txx files are not in the same module
> >>>> This is a mistake.... I am working on a patch that will fix this.

good

>
> * VectorImageToImagePixelAccessor in itk-intensity-math?
> >>>> There is no VectorImageToImagePixelAccessor ( maybe you meant  
> something else?).  There is VectorToRGBPixelAccessor in itk-common.

I meant VectorImageToImageAdaptor - sorry for that mistake.

>
> * ChangeLabelImageFilter and RelabelImageFilter are not restricted  
> to connected components
>    >>>>  True.  We could add another module, itk-image-label ?
>

yes, for example.

> * ReflectiveImageRegion[Const]Iterator in itk-distance-map?
> >>>>  Good catch. ReflectiveImageRegion seems to be quite stand  
> alone.  Should be bundled together with other RegionIterators.
>
> * AbsoluteValueDifferenceImageFilter in image-compare? I would  
> rather put it in itk-intensity-math
> >>>> Arguable. Probably all image-compare should be merged into itk- 
> intensity-math.
>

itk-intensity-math is already quite big. I wouldn't make it bigger!

> * I don't get immediately the meaning of itk-image-grid.  
> Unfortunately, I'm not sure to have something better to propose. In  
> WrapITK, the closest library is named Resize
> >>>>I agree that  itk-image-grid is not intuitive. It is much more  
> than resizing images, it has everything to do with manipulating the  
> image coordinates, including interpolation, resampling, padding,  
> permute axes etc. we can work on the renaming.
> * itk-image-statistics contains mostly the filters for the  
> projection. Those projections use some statistics to compute the  
> projected value, that's right, but many filters are also using some  
> statistics internally, like the Otsu threshold for example. In  
> WrapITK, the projection filters are in the Resize library.
> >>>> Make sense. Will think about this.
>
> * the compose filters in itk-intensity-math?
> >>>>  itk-intensity-math contains filters that uses vector images  
> (e.g.  itkVectorImageGradientMagnitudeImageFilter), so it was  
> convenient to put vector image related compose filters here too. But  
> I think we could take them out . Suggestions are welcomed.

itk-compose?

> * Gradient, Gaussian, Laplacian filters in itk-intensity-math?  
> Clearly, I won't look there to find them!
> >>>> Technically, those filters are all about calculations on  
> intensity values.  Suggestions are welcomed.
>

well, then almost all the subclasses of ImageToImageFilter can be put  
there.
I'd say those filters are about computing gradient and gradient  
magnitude. So maybe an itk-gradient?
Finding a name must be hard: in WrapITK, we put it in the meaning less  
"Filtering" library.

>
> * ImageToVectorImageFilter, RGBToLuminanceImageFilter and the Join  
> filters are grouped with the Compose filter in WrapITK
>
> * itk-intensity-math is quite big. It may be splitted in unary and  
> binary and more filters.
>
> * there is a lot of itk-io-*. It may be better to create a module  
> only if there is a dependency on another project, like gdcm or tiff?
> >>>> I don't think the number of the io modules matters, as long as  
> it is clear to users.  If we take out "io" from "itk-io-analyze" for  
> instance, it might be confusing for people who didn't know analyze  
> is an image format.

I was thinking to have a big itk-io module with almost everything, and  
a few itk-io-* if this specific io class require a third party  
library, like gdcm or libtiff.

>
> * itk-common is probably a bit too big for wrapping. If possible, it  
> would be nice to split it a bit.
> Here are the classes which are not in the Base library in WrapITK,  
> but are in itk-common — note the a library in wrapitk is a module in  
> the modularization work.
> >>>> Make sense. Will think about further split on itk-common.
> BSplineInterpolationWeightFunction
> CellInterface
> DataObjectDecorator
> DefaultDynamicMeshTraits
> DefaultStaticMeshTraits
> ExtractImageFilter
> ImageConstIterator
> ImageConstIteratorWithIndex
> ImageDuplicator
> ImageIterator
> ImageIteratorWithIndex
> ImageLinearConstIteratorWithIndex
> ImageLinearIteratorWithIndex
> ImageRandomConstIteratorWithIndex
> ImageRandomIteratorWithIndex
> ImageRandomNonRepeatingConstIteratorWithIndex
> ImageRandomNonRepeatingIteratorWithIndex
> ImageRegionConstIterator
> ImageRegionConstIteratorWithIndex
> ImageRegionIterator
> ImageRegionIteratorWithIndex
> ImageRegionSplitter
> ImportImageFilter
> LineCell
> MinimumMaximumImageCalculator
> PointSet
> SimpleDataObjectDecorator
> SparseFieldLayer
> SparseImage
> SpatialFunction
> StreamingImageFilter
> TreeNode
> TriangleCell
> TriangleHelper
> VertexCell
>
>
> In WrapITK I think we haven't kept anything related to mesh —  
> CellInterface, LineCell, TriangleCell, VertexCell,  
> DefaultDynamicMeshTraits, DefaultStaticMeshTraits, TriangleHelper  
> and PointSet are in the Mesh library.
> All the iterators are in a separate library in WrapITK.
> The Sparse* classes are in the LevelSet library.
> Some are not in Base in WrapITK because they are not widely used,  
> but I think they should be in itk-common, like  
> SimpleDataObjectDecorator, so that's ok :-)
>
> Gaëtan
>
>
>
> Le 7 févr. 11 à 21:51, Xiaoxiao Liu a écrit :
>
> Dear All,
>
>
>
> During the ITKv4 Boston meeting, we presented the modularization  
> progress and planned to push the modularized ITK into the main ITK  
> git repository on Feb, 28th.   To make this transition easier for  
> all of us, please let us know if you have any suggested improvements  
> as soon as possible. We would like to get more feedback especially  
> on the granularity of the segmentation of the modules and the naming  
> of the modules, since it will be harder to move things around once  
> everyone starts to contribute to the modularized ITK.
>
>
> So far we have created 90 modules out of the monolithic ITK (not  
> including Examples and Reviews). Among the 90 modules, there are 14  
> utility modules (such as  itk-tiff and itk-xml) ,  and  21 I/O  
> modules (such as itk-io-tiff).  The   Manifest (located ITK/ 
> Modularization/Manifest.txt)  lists 2352 source code files and  
> their  locations in the modularized ITK.  Here is a spreadsheet  
> version of the Manifest for your convinence to explore:  
> Manifest.xlsx.  You can also get a copy of a modularized ITK  
> (produced at Feb. 2nd) from  http://itk.org/gitweb?p=tmp/modularITK.git 
>  to investigate.
>
>
> The current modularization process involves manually editing the  
> Manifest file, adding tests for each module and running dashboards  
> for modularized ITK every day.  This process is done for the  
> majority of ITK now and will be done for the entire toolkit by Feb  
> 28th. Moreover, this process will continue to be carried out for any  
> new contributions into ITKv4. Therefore, it will be extremely  
> helpful for developers to get familiar with the new lay-out of the  
> toolkit and get ready for the changes.
>
>
> We are working on detailed documentations to help both developers  
> and users to adapt to the modularized version of ITK. More details  
> about the modularization can be found at this wiki page: http://www.itk.org/Wiki/ITK_Release_4/Modularization 
> .
>
>
> Thank you for your attention!
>
>
>
>
> - Best,
>
>  Modularization Team  (Luis, Bill, Brad, Xiaoxiao)
>
>
>
>
>
>
> ---------------------------------------------
> Xiaoxiao Liu, Ph.D.
> R & D Engineer
> Kitware Inc.
> Clifton Park, NY
> Phone: (518) 881-4924  or  (518) 371-3971 x124
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.html
>
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-developers
>
> -- 
> Gaëtan Lehmann
> Biologie du Développement et de la Reproduction
> INRA de Jouy-en-Josas (France)
> tel: +33 1 34 65 29 66    fax: 01 34 65 29 09
> http://voxel.jouy.inra.fr  http://www.itk.org
> http://www.mandriva.org  http://www.bepo.fr
>
>
>
>
> -- 
> ---------------------------------------------
> Xiaoxiao Liu, Ph.D.
> R & D Engineer
> Kitware Inc.
> Clifton Park, NY
> Phone: (518) 881-4924  or  (518) 371-3971 x124
>
>

-- 
Gaëtan Lehmann
Biologie du Développement et de la Reproduction
INRA de Jouy-en-Josas (France)
tel: +33 1 34 65 29 66    fax: 01 34 65 29 09
http://voxel.jouy.inra.fr  http://www.itk.org
http://www.mandriva.org  http://www.bepo.fr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 203 bytes
Desc: Ceci est une signature ?lectronique PGP
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20110209/ff7ce8d3/attachment.pgp>

More information about the Insight-developers mailing list