pre-printThe emergence of open-source libraries and development tools in the last decade has changed the process of academic software development in many ways. In medical image processing and visualization this change is especially evident, also because open source projects are actively furthered by grant funding institutions. This manuscript presents the use of such development tools and libraries at the UNC Neuro-Image Analysis Laboratory for open source applications and tools. We have also experienced in our research that the development of open source in academics raises the issue of access to unpublished methodology. The strategy at our laboratory is to combine all in-house libraries and applications into a single repository that consists of two parts: a fully open source part that is distributed under a Berkley-style license and a private, closed source part with unpublished tools and methods. Access to the open source part is unrestricted, whereas the private parts can only be downloaded via cvs user login. This setup solved our issues regarding unpublished methodology, as migration from the private to the open source part is very simple. Overall our experience with this development environment within the academic setting is very positive

Gerig, Guido

Styner, Martin

English

The University of Utah: J. Willard Marriott Digital Library

CLOSED AND OPEN SOURCE NEUROIMAGE ANALYSIS TOOLS AND LIBRARIES AT UNCMartin Styner, Matthieu Jomier, Guido GerigDepartments of Computer Science and Psychiatry, University of North Carolina at Chapel Hill, NCABSTRACTThe emergence of open-source libraries and development toolsin the last decade has changed the process of academic soft-ware development in many ways. In medical image process-ing and visualization this change is especially evident, alsobecause open source projects are actively furthered by grantfunding institutions. This manuscript presents the use of suchdevelopment tools and libraries at the UNCNeuro-Image Anal-ysis Laboratory for open source applications and tools. Wehave also experienced in our research that the developmentof open source in academics raises the issue of access to un-published methodology. The strategy at our laboratory is tocombine all in-house libraries and applications into a singlerepository that consists of two parts: a fully open source partthat is distributed under a Berkley-style license and a private,closed source part with unpublished tools and methods. Ac-cess to the open source part is unrestricted, whereas the pri-vate parts can only be downloaded via cvs user login. Thissetup solved our issues regarding unpublished methodology,as migration from the private to the open source part is verysimple. Overall our experience with this development envi-ronment within the academic setting is very positive.1. INTRODUCTIONSoftware development in medical image analysis and visual-ization is structurally quite different than it was less than 10years ago due to the maturation of major open-source commu-nity libraries and tools. The ﬁeld was always quite open forcollaboration between different laboratories, but exchange ofactual source code and implementation of methods were notcommon place, as most groups had their own software solu-tions which quite often were single-platform or based on pro-prietary software. Several changes in the community lead tothe ongoing change towards openly exchanging source code.One major contribution were the maturation and stability ofopen source libraries like the visualization toolkit[1] and theInsight Segmentation and Registration Toolkit[2], as well asopen source development tools such as CVS, CMake, Doxy-gen and others. As the research groups become more openThis research is supported by the NIH Roadmap for Medical Research,Grant U54-EB005149, as well as NIH NIBIB grant P01 EB002779, NIHgrant RO1MH61696, and the UNCNeurodevelopmental Disorders ResearchCenter HD 03110regarding publication of their source code, the issue of accessto unpublished methodology arose. This manuscript presentsthe current development environment at the UNCNeuro-ImageAnalysis Lab with its open and closed source tool and libraryrepository UNC NeuroLib.In the next section, we discuss the motivation and aimsfor our development process. Then, the basic set of tools,libraries and services that make up our development envi-ronment are presented, followed by the use of internet basedcommunication for dissemination, training and support. Next,our view of open and closed source in academics, as well asof licensing and patenting issues are presented.2. MOTIVATION AND AIMSThe structuring of our development environment was mainlymotivated by the difﬁculties in managing and synchronizingmultiple overlapping developments in our research projects.Inspired by the success of the development process in theopen-source libraries the Visualization Tool Kit (VTK)1 [1]and the Insight Segmentation and Registration Tool Kit (ITK)2 [2], we aimed to mirror some of these processes in our lab-oratory. Both libraries are vital to the tool development inmedical image analysis and visualization in many academicresearch groups due to their open source license, stability,and the availability of a large set of methods. Unlike theselibraries, we focus on stand-alone tools that can be readilyused in clinical neuro-image analysis research, e.g., morpho-metric studies of the human brain in neuro-degenerative orneuro-developmental diseases. The criterions listed belowwere used in the design of the UNC NeuroLib:• Libraries: Methods are grouped into libraries for usein different research projects. All methods are contin-uously tested regarding compilation and functional as-pects in order to facilitate maintenance.• Automation: While many tools will always need di-rect user interaction, we aim to increase the level ofautomation such that the tools can be run in an interac-tive ’training’ mode and an automatic mode with a setof prior ’trained’ parameters. Quality assessment of the1Visualization Toolkit (VTK), http://www.vtk.org2Insight Segmentation and Registration Toolkit”, http://www.itk.org7020-7803-9577-8/06/$20.00 ©2006 IEEE ISBI 2006processing are computed both qualitatively (visualiza-tions)and quantitatively to allow efﬁcient inspection ofthe computed results.• Modularity: We aim to develop small to mid-size appli-cations each solving a clearly outlined problem. Theseapplications can be serially applied and employed inpipeline software (e.g., the UNC NeuroLib tool ”Imag-ine”, or the UCLALONI pipeline software [3]) or largerscale projects (e.g., Slicer 3).• Dissemination: In general, we want to develop process-ing and analysis tools that can be disseminated to clin-ical collaborators, collaborating research labs, as wellas to the general research community.• Stability: All tools are validated with clinical data andare continuously tested. The stability of both the func-tionality as well as the code base is highlighted whentraining developers.• Versioning: While the development of a tool is pro-gressing, it may already be employed in neuroimagingstudies. In these studies we aim at using a single toolversion throughout the whole study. This calls for aversioning process, in which different version of a toolcan be released and minor bug ﬁxes can be applied todifferent versions.• Cross-platform development: The academic computingenvironment is constantly changing and cross-platformdevelopment allows for easy migration from one plat-form to another. It also facilitates dissemination.• Support: Through supporting computing and informa-tion infrastructure and services, all the above mentionedcriterions are aided and monitored.3. STRUCTURE OF THE DEVELOPMENTENVIRONMENTThe UNC NeuroLib development environment (see Fig. 1)depends on a large set of libraries of tools that are all sta-ble, cross-platform and open-source projects. Thanks to thecross-platform nature of these toolkits, the UNC NeuroLib it-self has been compiled for several Linux ﬂavors, Solaris, Win-dows andMacOSX. The source code of the UNCNeuroLib isavailable via CVS 4 access. The CVS repository of NeuroLibconsists of two main parts: a fully open source part that is dis-tributed under a Berkley-style license and an internal, privatepart with unpublished tools and research libraries. This setupsolves issues of open dissemination and protecting unpub-lished methodology (see Sec. 5). Central repository accessalso allows the use of the extreme programming paradigm.33D Slicer, http://www.slicer.org4Concurrent Versions System (CVS), http://www.nongnu.org/cvsUNC NeurolibLibrary & ApplicationsITKVTKfftwOpen SourceLibrariesCMakeDoxygenOpen SourceTools:CVS/SVNInformation:• Meetings• Training• Tutorials• Mailing lists• Bug Tracking• AdministratorDashboardFig. 1. Scheme of the development environment for the UNCNeuroLib. Open-source and cross-platform libraries and toolsbuild the foundation of the NeuroLib, which is maintained ina single CVS repository. A set of supporting information arealso needed for proper training, ongoing development, main-tenance and dissemination.Due to the modularity of the tools, only few projects involvea larger number of developers, e.g., the FiberViewer [4]. Forthose projects, frequent cycles of design, implementation andtesting phases with continuous integration of new parts are thegoal. Thus, all developers work on their copy of the sourcecode, which is synchronized with the repository as often aspossible. The guiding principle is ”Release early, Releaseoften” (Bill Lorensen, GE Research). This necessitates thatall developers agree to keep the software as a whole defectfree, as well as that a continuous monitoring of the repositoryis established. Several open-source tools facility our moni-toring task: CVS 4 for access, CMake 5 for cross-platformcompilation setup and Dart 6 for web-access compilation andtesting quality dashboard. Additional open source tools solvecross-platform editing (SourceNavigator 7), code documenta-tion (Doxygen 8), bug tracking and project management.At the center of the methodological aspects of our devel-opment environment are a set of libraries handling input/output(x-medcon 9, ITK 2), image processing (ITK 2 ), signal pro-cessing (fftw 10), and visualization (VTK 1, SOViewer 11).Our group actively adapts and extends the source code ofmany of these libraries. Some of these extensions are partof the UNC NeuroLib and others made their way back to the5Cross-platform Make, http://www.cmake.org6Dart: Tests, Reports and Dashboard”,http://public.kitware.com/Dart7Source Navigator, http://sourcenav.sourceforge.net8Doxygen Documentation System, http://www.doxygen.org9(X)Medcon utility”, http://xmedcon.sourceforge.net10FFTW: Fast, Free C FFT Library, http://www.fftw.org11SOViewer library”, http://caddlab.rad.unc.edu/software/SOViewer703originating libraries. The use of this set of libraries consider-ably shortened the implementation time of new applications,even though it also demands a longer initial training phase.The internal libraries are all that is needed for many of thecommand-line interface based tools in the UNC NeuroLib.However, few clinical collaborators can work with such toolswithout considerable training as they are unfamiliar with shellcommands, command-line interaction and scripting. Mostusers of our tools are not engineers and thus a graphical userinterface (GUI) is a necessity for most of our projects. This isachieved through GUI based pipeline tools (Imagine, LONIpipeline [3]) for command-line tools, as well as a host ofgeneric and application speciﬁc stand-alone tools. SeveralGUI libraries are used in our tools: Qt 12, FLTK 13 and KWWid-gets 14. All these libraries offer similar functionality, but eachone has its individual advantages and disadvantages regardinglicensing (see Sec. 6), ease-of-use, and functionality.4. INTERNET BASED COMMUNICATIONFig. 2. Schematic visualization of maintenance sup-port via server-based source revisioning (CVS/SVN), cross-compilation, module testing (both via Dart) and automaticdocumentation generation (Doxygen).In order to facilitate training, ongoing development anddissemination with information services, our lab hosts a UNCNeuroLib devoted webpage (see Fig. 3). This page includes adownload section for many tools with installers, as well as abug database, project manager, online tutorials, mailings listsand discussion forums. The nightly cross-platform compi-lation/testing dashboards and the local Wiki documentationsystem complete the supported facilities. The webpage is lo-cated at http://www.ia.unc.edu/dev .12Qt Application Framework: http://www.trolltech.com/products/qt/13Fast Light Toolkit, http://www.ﬂtk.org14KWWidgets, http://www.vtk.org/Wiki/KWWidgetsThe web-based setup allows incoming students and de-velopers to do a larger part of their training by themselves,but face-to-face training, and regular meetings for problemsolving and design reviews are also necessary. They are alsoenrolled in the mailing list and are introduced to the devel-opment support system. This support system entails the Neu-roLib CVS repository and the nightly compilation of the repos-itory on Linux, Windows XP and Solaris 9 machines (seeFig. 2). Most libraries and tools have additional testing pro-grams, which are run automatically after the compilation inorder to test the correctness of the compiled code. Resultsfrom both compilation and testing are visualized in the auto-matically generated dashboard. The online documentation isgenerated nightly using the Doxygen documentation system,which generates the documentation directly from the sourcecode and comments within the code.Fig. 3. Entry page of the Neurolib webpage. Several servicesare directly available from this webpage, most importantly thetutorials and the nightly dashboard.5. CLOSED VS. OPEN SOURCE IN ACADEMICSA few years ago, the National Institutes of Health (NIH) an-nounced clear goals for software dissemination for many oftheir funding programs. These goals entail that software de-veloped with NIH money should be freely available and per-mit the commercialization of enhanced or customized ver-sions. In some projects, such as the NIH National Centers ForBiomedical Computing, it is a necessity that researchers out-side the center and its collaborating projects be able to modifythe source code and to share modiﬁcations. This position infavor of open source research by the NIH differs somewhatfrom policies in academics that further patenting and com-mercialization of software and methodology. The position of704our laboratory is a clear commitment to open-source softwarewithout the need for software patents.Academic researchers that are committed to open sourceoften struggle with the need for the internal development ofnovel, unpublished methods, as well as the dissemination ofestablished tools and libraries, which still need regular main-tenance and bug ﬁxing. Both unpublished and established re-search tools usually rely on the same libraries and the samedevelopment and testing framework. A common solution inthe ﬁeld is to release the source code for disseminated toolsseparately, often in a separate version, and keep the devel-opment repository fully private. This solution involves con-siderable overhead as extracting the source code of a speciﬁctool including any dependent code located elsewhere in therepository is not trivial. This involves collecting the sourcecode, deﬁning a separate compilation environment and addi-tional testing phase. This leads to a rather low frequency ofreleasing new versions.Our proposal is a single source code repository and con-tinuous release. In order to protect the source code that con-tains unpublished tools and libraries from dissemination, therepository is divided into 2 parts. The ﬁrst part is open sourceand access to this part is unrestricted via CVS anonymous lo-gin. The other part is subject to restricted access via CVSuser login. Thus, the download and update of the repositoryfor both types of user access is the same only the CVS loginis different. The open source part is fully independent of theprivate part, whereas the private part also depends on librarieslocated in the open source part. Once a novel method hasbeen published in peer-reviewed literature, the correspondingsource code is migrated from the private to the open sourcepart. If a tool is to be released in a separate open source ver-sion, but the actual local development continues on the privateparts, the necessary parts are copied rather than moved.6. LICENSING AND PATENT ISSUESIn this section, we brieﬂy discuss our experience with issuesof licensing and patenting of internal and external libraries.Even though we mostly use external, open-source libraries,the licensing is quite different for some of these. Almost allcommon open source licenses are attractive to academic in-stitutions from the viewpoint of free software development.This is not the case for commercial institutions, as a set oflicenses such as the GNU General Public License (GPL) de-mand derivative work, e.g., via code inclusion or library link-ing, also to be free and open source. In case of collaborativeresearch with commercial institutions, whether the researchis funded by the NIH or industrial sources, the use of such li-censes can be a problem even in academic institutions. Of thelibraries used in our NeuroLib, this is the case for Qt, FFTWand Xmedcon. For many projects, we have thus moved to usealternatives (FLTK or KWWidgets instead of Qt, ITK insteadof Xmedcon) with simpler, less ”open-source-contagious” li-censes, such as Berkley-style licenses.For similar reasons of incompatibility with NIH fundedindustrial collaborations, we have encountered problems inusing open-source software that contains patented methods.Our laboratory has not yet patented any of its methods and isnot interested to do so in the future. Aside from the generalargument that software is essentially mathematics, which inturn cannot be patented [5], industrial leaders in the open-source community have also argued that releasing patentedmethods in open-source libraries is akin to advertising, as theopen source community popularizes the methods.7. CONCLUSIONIn this paper, we presented our UNC NeuroLib and our soft-ware development environment, which is based on open sourcelibraries and tools. The UNC NeuroLib features a series ofcommand-line and graphical user interface (GUI) tools estab-lished and validated in many neuro-imaging studies, as wellas C++ libraries that are supporting these tools. We also dis-cussed brieﬂy our position and solutions to deal with issuesof unpublished research and licensing.There are differences between our development and in-dustrial strength tools. As academic software developmentneeds some degree of ﬂexibility, API changes are not uncom-mon. This makes it more difﬁcult for external developers torely on the libraries offered in the NeuroLib repository. Butour goal mainly is to offer a extensive development processto our developers leading to stable, validated tools, which aredisseminated to clinical collaborators. In our experience, thissetup ﬁts this purpose excellently, as the development timeis shortened, libraries and tools are well maintained, and re-search team interaction is enhanced. We are highly motivatedand committed to stay with it.8. REFERENCES[1] W. Schroeder, K. Martin, and W. Lorensen, The Visual-ization Toolkit, Third Edition, Kitware Inc., 2004.[2] L. Ibanez, W. Schroeder, L. Ng, and J. Cates, The ITKSoftware Guide, Kitware Inc., 2003.[3] David E Rex, Jeffrey Q Ma, and Arthur W Toga, “TheLONI Pipeline Processing Environment,” NeuroImage,vol. 19, pp. 1033–1048, 2004.[4] C. Goodlett, I. Corouge, M. Jomier, and G. Gerig,“A Quantitative DTI Fiber Tract Analysis Suite,” TheInsight Journal, vol. ISC/NA-MIC/MICCAI Workshopon Open-Source Software, 2005, Online publication:http://hdl.handle.net/1926/39.[5] B Klemens, “Software Patents Don’t Compute,” IEEESpectrum, July 2005.705

Closed and open source neuroimage analysis tools and libraries at UNC

https://collections.lib.utah.edu/dl_files/dc/85/dc85ce2ab8b05f2ad8564af56f35a3ace296942b.pdf

Closed and open source neuroimage analysis tools and libraries at UNC

Abstract

Similar works

Full text

Available Versions

The University of Utah: J. Willard Marriott Digital Library