ITKv4 Migration plan

From Slicer Wiki
Jump to: navigation, search
Home < ITKv4 Migration plan

Back to Slicer

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.

Issue To Address

Timeline

Issues for migration to ITKv4
_Due_Date_ Progress Status Team Members Description
2012-12-31 Started Hans J., Steve P., JC, Bill L., Matt M., Kent W. http://www.na-mic.org/Bug/search.php?project_id=3&sticky_issues=on&sortby=last_updated&dir=DESC&hide_status_id=80&tag_string=ITKv4
2012-12-05 Steve P., Bill L., Matt M., Kent W. Test Slicer/ITKv4 on all platforms, especially 64bit VS2008. ( see comments in table below for checkout information: 2012-12-01 )
2012-12-05 Matt M., Bill L. Look into reducing the number of ITKv4 Modules enabled when building
N/A to ITKv4 Matt M., Steve P., Bill L., Matt M. Slicer modules to reduce load time on Windows

Timeline

Timeline for ITKv4
_Due_Date_ Progress 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.
I also installed homebrew, and from that installed QT 4.8.3. ( I manually set the required Qt version to 4.8.3)

  • FROM THE SAME SOURCE TREE* I also am building Slicer built with ITKv3, and that also seems to be building a reasonable package.
git clone git@github.com:BRAINSia/Slicer43.git
cd  Slicer43
git checkout origin/next-slicer43 –b 20130107-next-slicer43
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:  <br\>

Please join my meeting, Dec 5, 2012 at 9:00 AM CST. <br\> https://www1.gotomeeting.com/join/739397184 <br\> Meeting ID: 739-397-184<br\>


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: ( See table above )

If there are other issues to address, please report them in the Slicer bug tracker and reply to this thread.

Work will occur on the following repository on Github.   https://github.com/BRAINSia/Slicer43

2012-12-
2012-12-
2012-12-
2012-12-
2012-12-

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

  • 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.