[Insight-developers] Modularization Use Cases
Ziv Yaniv
zivy at isis.georgetown.edu
Tue Jan 25 09:07:47 EST 2011
Bill,
As there was no clear case for modularization, I have one reasonable
example: Platform independent multi-threading.
OpenIGTLink took the relevant classes from ITK and repackaged them. It
would have been nicer to point to the ITK module and grab that as part
of the OpenIGTLink configuration. With the module approach the code is
maintained in ITK instead of both libraries maintaining separate/similar
copies.
Ziv
On 5:59 PM, Bill Lorensen wrote:
> 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=r-lnxw07LinuxLKM&S_TACT5AGX59&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
>>
--
Ziv Yaniv, PhD., Research Assistant Professor
Imaging Science and Information Systems (ISIS) Center
Department of Radiology
Georgetown University Medical Center
2115 Wisconsin Avenue, Suite 603
Washington, DC, 20007,
Phone: +1-202-6877286
Fax: +1-202-784-3479
email: zivy at isis.georgetown.edu
web: http://isiswiki.georgetown.edu/zivy/
More information about the Insight-developers
mailing list