ITKv4 Migration plan
From Slicer Wiki
Home < ITKv4 Migration plan
Contents
Overview
This page is designed to identify and track the work that needs to be done during the month of 2012-12-01 to 2012-12-31 in order to transition Slicer to a solid and uniform ITKv4 platform. Originally this document, created following the NAMIC Engineering TCon of July 28th [1], discuss the element that should be considered before transitioning Slicer to ITKv4.
Historical and other old pages with possibly outdated information. If the information on these other pages is relevant, they need to be pushed here.
- http://www.slicer.org/slicerWiki/index.php/ITKv4_Migration_plan
- http://www.slicer.org/slicerWiki/index.php/Developer_Meetings/20121106#ITKv4
- http://wiki.na-mic.org/Wiki/index.php/Engineering:TCON_2011#2011-07-28
| Date | Status | Description |
|---|---|---|
| 2012-12-01 | Done | Hans provides a first pass reference set of patches that build on Mac and demonstrates that nearly all functionality is maintained identically between ITKv3 and ITKv4 |
| I've successfully created a mac dmg package. "CPack: - package: /Users/johnsonhj/src/Slicer-git-itkv4/Slicer-build/Slicer-4.2.0-macosx-amd64.dmg generated." The package is not yet completely successful though :(. It seems to run just fine on the machine I used to build the package, but when running on my wifes laptop, it can not find a Qt library in /usr/local/lib/ This is probably something best left for discussion next Wednesday. I am building on 10.8 with a private build of clang 3.1 tagged as stable from svn.
git clone git@github.com:BRAINSia/Slicer43.git cd Slicer43 git checkout origin/AddDWIConvert –b AddDWIConvert cd ../ && mkdir sl-itkv3 && sl-itkv3 && CC=/opt/clang31/bin/clang CXX=/opt/clang31/bin/clang++ ccmake –DITK_VERSION_MAJOR:STRING=3 ../Slicer43 cd ../ && mkdir sl-itkv4 && sl-itkv4 && CC=/opt/clang31/bin/clang CXX=/opt/clang31/bin/clang++ ccmake –DITK_VERSION_MAJOR:STRING=4 ../Slicer43 | ||
| 2012-12-05 | Matt McCormick coordinates a Google Hang out | |
| In preparation for the upcoming Slicer 4.3 and the NA-MIC Winter Project Week, we are planning a hackathon to help with migration to ITKv4 as the default version of ITK in Slicer. For some time, community members such as Hans Johnson, Bill Lorensen, and Jean-Christophe Fillion-Robin have made sure ITKv4 works well with Slicer, and we hope to gather and focus on remaining issues that should be addressed.
The hackathon will take place on: Wednesday, December 5th from 10AM Eastern Time until we run out of energy :-). The hackathon will take place on a Google+ Hangout. I will follow up with the link to the hangout on this email thread when we starts.
Issues to address at Google Hangout: Issues in the Slicer bug tracker with the ITKv4 tag: <br\>
|
Historical (and probably outdated) information
Consensus as of 2011
- Slicer RSNA 2011 will be built against ITKv3
- External module requiring ITKv4 will be linked statically against ITKv4
- Associated command line module will be built as executable only. Indeed having both ITKv3 and ITKv4 in the same process will most likely result in some weird symbol clash.
Questions
- Should each extension depending on ITKv4 download and build its own copy of ITKv4 or should Slicer build and expose both ITKv3 and ITKv4 ?
Custom MetaIO in SlicerITK
- To minimize memory usage and increase efficiency of Command line module execution, itkImageFileReader.txx in SlicerITK has been patched. See https://github.com/Slicer/ITK/commit/8c73dc57e4ae67328ff8e44934b72fd4cc5d4dd3 and https://github.com/Slicer/ITK/commit/12349021b152ac6546c2caf09bbbee4266baddad
- Bill mentioned it should be possible to avoid patching SlicerITK by creating a custom Factory / plugins.
- From Bradley Lowekamp - ITK mailing list - Sun, Jul 17, 2011 at 11:33 AM subject Re: [Insight-developers] ITK 3 tag to use with slicer? Fwd: Slicer release schedule
Stephen, If I understand this change correctly, this patch allows the usage of a buffer allocated by the ImageIO to be passed all the way to the Image class if all the types match up. The is accomplished by adding the following methods: ImageIO::CanUseOwnBuffer, ImageIO::ReadUsingOwnBuffer() and ImageIO::GetOwnBuffer. I assume that this change is for the MemoryImageFileReader that is used with Slicer. ( can see how this could be quite advantageous ( and also the potential for scary alias when combined with InPlace filters ). But as not one single ITK ImageIO has support for these methods. I'd like to question if they should be brought into the ITK main repo, as they don't appear to currently provide any benefit to ITK and only complicate as already complicated interface to the ImageIO. If these changes are desired in ITK, then I would strongly encourage better documentation for the new methods in ImageIO, to enable new developers with add this feature to ImageIO classes. Brad
- From Bill - Thu, Jul 28, 2011 at 5:19 PM Re: [slicer-devel] Engineering:TCON 2011 - NAMIC
I checked the patches. Two classes are patched: ImageIOBase and ImageFileReader. Now I do not think my factory idea is worthwhile. We should to bring the changes into ITK, and convert ITK's Meta and Nifti ImageIO's to use it. Bill
- In the na-mic tcon it was discussed that nrrd and nifti readers also perform the memcpy since the native libraries perform the Information and Read steps in a single API call. Therefor if the feature existed at the ITK level, then several readers could take advantage of it.
