[Insight-developers] Modularization Use Cases
Bill Lorensen
bill.lorensen at gmail.com
Tue Jan 25 12:17:42 EST 2011
One could argue, that such a basic capability as threading should be
handled another way. For example, VTK also has threading which is very
similar to ITK's (since ITK's was initially a ripoff of VTK's).
Maybe threading should have been part of kwsys.
That said, I don't think the current itk modularization would handle
your use case the multithreader stuff is all lumped in with
itk-common.
On Tue, Jan 25, 2011 at 9:07 AM, Ziv Yaniv <zivy at isis.georgetown.edu> wrote:
> 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_TACT
>>>> 5AGX59&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