[Insight-developers] Modularization Use Cases
Luis Ibanez
luis.ibanez at kitware.com
Tue Jan 25 01:04:05 EST 2011
Errata: That 1% for SNAP, is actually a 11%.
My Bad.
Luis
-----------------------------------------------------------------------
On Tue, Jan 25, 2011 at 1:01 AM, Luis Ibanez <luis.ibanez at kitware.com> wrote:
> Hi Bill,
>
>
> Thanks offering these use case scenarios,
> let me comment on them below.
>
>
> ------------------------------------------------------------------------
> On Sun, Jan 23, 2011 at 2:14 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>> Folks,
>>
>> I am still confused about modularization and its benefits.
>>
>> I would like to see some use cases and see how this effort will
>> benefit them given that it will have a major impact on the
>> organization of ITK in the future.
>>
>> I'll offer one use case.
>>
>> Use Case #1: An application to process 2D images
>> This application will only read tiff and png images. All operations
>> will be 2D. Filters required are smoothing and denoising as well as
>> some simple arithmetic operations. Maybe NormalizeImageFilter,
>> HiostogramEqualization, etc. No level sets, no registration, no
>> medical, image formats. Will probably need resampling.
>>
>> Benefit: How will modularization benefit this use case? I can see
>> benefits of limited IO libraries. But outside of that, what benefits?
>>
> -------------------------------------------------------------------------------------------
>
> In this case, the application can benefit from a simplified software
> distribution and simplified software configuration.
>
> The developers of this application can create a customized file
> listing the modules needed from ITK to support this application.
> They could then pre-package a custom ITK (with only the needed
> modules) to be distributed along with the application's source code.
>
> This one may not be the most compelling case for modularization,...
>
> Unless that application needs to go through an FDA approval process,
> in which case, it is advantageous to be able to focus on testing and
> validating the pieces of ITK that are actually used in that application
> or medical device. As you know better than most of us, it is quite
> common for medical devices to have a small and focused set of
> functionalities, and it is quite costly to validate an entire software
> package, particularly when you know that only a minimal portion of
> that package is being used in your application.
>
>
> ------------------------------------------------------------------------------------------------
>> Also, what benefits for applications like Slicer and SNAP? For
>> example, we heard recently that SNAP only uses one of the level set
>> algorithms. Will SNAP benefit? I don't believe that modularization
>> will be at that level.
>>
> ----------------------------------------------------------------------------------------------
>
> Even an application as ITK-centered as SNAP
> will benefit from a modularized ITK.
>
>
> SNAP doesn't use:
>
> Meshes, Registration, Label Maps, Paths, Bloxs, Resampling, Optimizers,
> Polynomials, FFT, Statistics, Spatial Objects, Region Growing, Watersheds,
> Voting filters, Markov Random Fields, Gibbs filters, Canny Edge detection,
> FEM, Demons, Tensor Images, Vector Images, Bias Field Correction,
> XML parsing, Neural Networks, PDE deformable registration, Voronoi
> segmentation... among others.
>
>
> From the 1,496 header files currently available in ITK/Code
>
> SNAP only include (directly) 140 of those headers.
>
> (the list is attached to this email for convenience)
> ( interestingly, 16 of those 140 are ImageIO classes )
>
>
> so,
>
> SNAP uses about 1% of ITK
>
>
> Granted,
> those 140 headers probably pull in another 200..(maybe ?).
> but still, that will make about 3~4% of ITK.
>
> ----
>
> In the case of Slicer3.6:
>
> There are 467 ITK unique headers included in its source code.
>
> So, Slicer uses about 30% of ITK.
>
>
> This list of headers is also attached to this email for convenience.
>
>
> ---------------------------------------------------------------------------------------
>
>
> The rationale for modularization derives from this graph:
>
> http://public.kitware.com/pub/itk/InsightStatCVS/loc.html
>
> Essentially:
>
> ITK has Linear Growth
>
> The toolkit has consistently increased in number of lines
> during the past ten years. We have every reason to think
> that it will continue growing at a similar rate for the next
> ten years, as more specialized algorithms and classes are
> added to it.
>
> In particular, as we reach out to the application domains
> of microscopy, remote sensing and computer vision.
>
>
> Here is already the bump in growth for 2011:
>
> http://public.kitware.com/pub/itk/gitstat/ITK/lines.html
>
> As more code is added to the toolkit, it becomes harder
> to distribute, tests, and maintain. Modularization is one,
> among many other (as you point out), approaches for
> letting ITK continue growing without getting out of hand.
>
>
> The immediate goals for modularization are:
>
> 1) Find / label / remove the trash in ITK.
>
>
> 2) Organize the ~2,330 files into conceptual cohesive groups.
>
>
> 3) Test and label each group according to measures of
> quality control : Code coverage, correctness, style,
> dynamic testing, documentation...
>
>
> 4) Raise the quality bar for critical components.
>
> For example, the itkObject must have 100% code coverage,
> while we could live with the Blox classes having 30%.
>
>
> 5) Maintain that level of quality as more code is added to the toolkit.
>
>
> 6) Facilitate the use of Add-ons with ITK without having to
> include them in the toolkit.
>
> So a specialized module that INRIA may create, could be
> distributed as a module that specific application developers
> can add to their ITK installation as an extra module.
>
> The same way that you can install extra packages in a Linux
> distribution, or R-packages in an R installation, or extra packages
> in a Latex installation, or extra toolboxes in Matlab, or extra plugins
> in Firefox.
>
>
> Points (1-5) relate quite closely to Six Sigma methodologies
>
> http://en.wikipedia.org/wiki/Six_Sigma#DMAIC
>
> that you know better than any of us.
>
> They map to :
>
> Define,
> Measure
> Analyze
> Improve
> Control
>
> ---------------------------------------------------------------------
>
> Modularization is a common design answer to the
> problem of managing complexity and growth.
>
>
> From the Linux Kernel:
> http://www.ibm.com/developerworks/linux/library/l-lkm/index.html?ca=dgr-lnxw07LinuxLKM&S_TACT=105AGX59&S_CMP=GR
>
> to KDE:
> https://wiki.archlinux.org/index.php/KDE_Packages#Terminology
>
> to Boost:
> http://ryppl.github.com/index.html
>
> to Qt:
> http://labs.qt.nokia.com/2010/10/26/qt-is-going-modular/
> http://labs.qt.nokia.com/2011/01/21/status-of-qt-modularization/
>
>
> ----
>
> More details on the goals of modularization were presented here:
>
> http://www.itk.org/Wiki/ITK_Release_4/Modularization/Tcon-2010-12-03
>
>
> In particular in:
> http://www.itk.org/Wiki/images/1/16/ITKv4-Modularization-2010-12-03.odp
> http://www.itk.org/Wiki/images/7/75/ITKv4-Modularization-2010-12-03.pdf
>
>
>
> Luis
>
More information about the Insight-developers
mailing list