[Insight-developers] ITKv4 Modularization Plan

Thu Feb 10 00:02:37 EST 2011

Hi Gaëtan,

 I have submitted two gerrit reviews regarding to your suggestions:
http://review.source.kitware.com/#change,874
http://review.source.kitware.com/#change,875
  I will keep working on more and add you as reviewer  for those changes.

Regarding to io modules, after discussion with Luis, we think it is better
to keep all io modules separated no matter whether they have third party
libraries. An important reason of modularization is code quality control.
Some of the io modules are not tested well (low code coverage).  It is
helpful to be able to focus on one image format for improving code coverage
later.

We are also working on the  directory tree structure idea that Bill Lorensen
suggested, it is possible  that all io modules will end up in a subdirectory
named as IO.

2011/2/9 Gaëtan Lehmann <gaetan.lehmann at jouy.inra.fr>

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

-- 
---------------------------------------------
*Xiaoxiao Liu*, Ph.D.
R & D Engineer
Kitware Inc <http://www.kitware.com/>.
Clifton Park, NY
Phone: (518) 881-4924  or  (518) 371-3971 x124
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20110210/de68c782/attachment.htm>