[Insight-developers] Modularization Use Cases

Tue Jan 25 11:25:21 EST 2011

Stephen,

I especially agree with your statement that "modularization is about packaging."

Given that as a main driver, there is no need to drastically
restructure ITK. We just need a better ways to package it and test
subsets.

I like the presentation I saw at NA-MIC (I think it was yours Stephen)
that described how the testing results for modules in Slicer4 could be
presented.

Bill

On Tue, Jan 25, 2011 at 10:09 AM, Stephen Aylward
<stephen.aylward at kitware.com> wrote:
> Bill raises some good points.   Luis too.
>
> I'm not certain breaking up ITK for people to grab subsets of ITK is
> the right way of looking at this.   I think the impact on SNAP and a
> 2D filtering application should be minimal (or totally absent).  Those
> are two very common use cases and the impact on the user must be small
> or we're impacting the wrong people.
>
> I don't think we can get all of the way to the original dream we had
> for modularization, but we do seem to be working towards that goal.
> Recall that modularization of ITK was about lowering the cost of
> method redistribution when a method is "fresh."    By fresh I mean,
> not quite up to ITK standards but wanting to be shared.  Right now
> that is a high cost for the method developer (cost to get code up to
> ITK standards, push it to IJ, maintain it on the IJ, ...).   Also,
> right now that cost is high for the ITK maintainers - if we accept a
> code into ITK, we're saying that we're going to help move it into ITK,
> verify its compliance with our standards, and maintain it for the next
> ten years.   Furthermore, the cost is also high for the users, they
> must find methods on the IJ, download them, figure out what cmake
> magic variables need to be configured, and pray that it compiles on
> their machine...and if they want to use code from more than one IJ
> article, they better be a damn good ITK and CMake expert - not ideal
> requirements for an ITK user.
>
> Modularization is about packaging.   Making it easy for developers,
> maintainers, and users by providing code (binary and source) chunks as
> independent entities that can be picked and chosen, like the Android
> market is used to customize my phone.
>
> Use cases we originally identified remain valid:
> 1) Allowing alternate licensing and massive external libraries - e.g.,
> with a magical "single click," fftw is downloaded and ITK is
> configured to use it.   Or all of openCV, or DCMTK, or ...
>
> 2) Reducing ITK maintenance cost - moving less-frequently-used methods
> out of ITK and into modules that aren't officially supported by ITK
> (gold, silver, bronze levels of compliance based on their
> dashboards?),  They can be tested via dashboards (kwstyle, etc etc)
> but they don't report to the main ITK dashboard.
>
> 3) Allowing anyone to advertise that their code is available and that
> it can be grabbed and integrated with ITK via that magic click.
>
> The modularization of ITK source is an important step towards that goal.
>
> s
>
> 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
>>
>> _______________________________________________
>> 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
>>
>>
>
>
>
> --
>
> ==============================
> Stephen R. Aylward, Ph.D.
> Director of Medical Imaging Research
> Kitware, Inc. - North Carolina Office
> http://www.kitware.com
> stephen.aylward (Skype)
> (919) 969-6990 x300
>