[Insight-developers] [slicer-devel] Strawman: ITK 3 tag to use with slicer

Wed Jul 20 09:52:29 EDT 2011

Stephen,

An alternative to getting the ImageFileReader changes into ITK would be to use ITK"s object factory system. You could derive a class from ImageFileReader, detect when the MRML ImageIO is needed, and do an optimized import of the buffer pointer when appropriate. Really only the GenerateData methods would need to be overloaded. Then this class could be registered into the ObjectFactory system, and it would be created as needed. Doing this will prevent you from having to generalize your optimization to the reset of the ImageIO filters. 

Just another option.

Brad

________________________________________
From: Stephen Aylward [stephen.aylward at kitware.com]
Sent: Wednesday, July 20, 2011 9:18 AM
To: Lowekamp, Bradley (NIH/NLM/LHC) [C]
Cc: Jean-Christophe Fillion-Robin; Matt McCormick; Slicer Devel List; Insight Developers; Julien Finet
Subject: Re: [Insight-developers] [slicer-devel] Strawman: ITK 3 tag to use with slicer

Hi Brad,

This is really great help!  Thank you!

I think we should pass on the ImageIO changes until I submit them as
an IJ article, get reviews on it, etc.

A 3.20.1 tag seems like very good idea and it seems like it should be
sufficient.

Thank you!
Stephen

On Tue, Jul 19, 2011 at 11:16 PM, Bradley Lowekamp
<blowekamp at mail.nih.gov> wrote:
> Hello,
>  I just looked at Slicer branch
> ( https://github.com/Slicer/ITK/commits/slicer-4.0 ).
> 1) The topic "fix-gcc46-compile" is already in the ITK's release branch.
> 2) I just pushed JC's "fix-vnl-64bits-compile" to gerrit:
> http://review.source.kitware.com/#change,2142
> 3) The remaining commits  are in the topic "reader-speedup-reuse-buffer" (
> the best I can tell ). I believe this is just a performance improvement. And
> with out this Slicer should still compile against the gerrit' proposed
> release. It appears that additional work needs to be done on this topic to
> get it changes coverd by testing and supported by any itk imageIO.
> If the gerrit topic is merged into itk release, and a 3.20.1 tag was made.
> Would that be sufficient?
> Brad
> On Jul 19, 2011, at 10:35 PM, Jean-Christophe Fillion-Robin wrote:
>
> I would like to include Dominique Belhachemi in the discussion, he has been
> a debian packaged for now several year and I am sure he would provide
> insightful comments regarding the most appropriate of handling the packaging
> of a Superbuild based application like Slicer.
>
> Dominique>
>    What do you think ?
>    Could you comment on use case 3 ?
>    How would you proceed to efficiently, simply and robustly package an
> application like Slicer ?
>    What are the implication regarding the dependent project (ITK, CTK, ... )
> ?
>
> Thanks
> Jc
>
> On Tue, Jul 19, 2011 at 2:13 PM, Matt McCormick <matt.mccormick at kitware.com>
> wrote:
>>
>> Resending, so it hits the lists....
>>
>> On Tue, Jul 19, 2011 at 1:43 PM, Matt McCormick
>> <matt.mccormick at kitware.com> wrote:
>>>
>>> Hi JC,
>>>
>>> With default workflow to be Slicer superbuild, I don't think we ever
>>> reach Use case 3.  It encourages forking and generally promotes
>>> disorganization instead of cooperation.  In addition, if someone wants to
>>> work on other projects that use VTK/CTK/ITK, they needlessly use up CPU and
>>> hard drive resources with that approach.  As you mention, the
>>> Slicer_SUPERBUILD:OFF needs to be used and tested.  It should not only be
>>> the Debian packagers who test this.  The scenario would then be:
>>>
>>> Use case 1: You develop a Slicer module
>>>   Mac and Linux
>>>     -> Install CTK/VTK/ITK dependencies with a package manager (just like
>>> one normally does with every other open source dependency, qt, ...), or
>>> 'make install'
>>>   Windows
>>>     -> Slicer superbuild
>>>
>>> Use case 2: You work on Slicer core feature / Add feature to VTK / CTK /
>>> ITK ..
>>>     ->  Work with the upstream project to get the patch merged, then use
>>> it in Slicer
>>>
>>> Use case 3: Packager (Debian, Ubuntu ... )
>>>     ->  They have to do nothing unusual, there is not forked code, so we
>>> get debian packages :-)
>>>
>>> Use case 4: You use Slicer
>>>      -> apt-get install slicer
>>>
>>> My humble opinion,
>>>
>>> Matt
>>>
>>> On Mon, Jul 18, 2011 at 10:22 PM, Jean-Christophe Fillion-Robin
>>> <jchris.fillionr at kitware.com> wrote:
>>>>
>>>> To clarify,
>>>>
>>>> Use case 1: You develop a Slicer module
>>>>    -> Slicer superbuild
>>>>
>>>> Use case 2: You work on Slicer core feature / Add feature to VTK / CTK /
>>>> ITK ..
>>>>    -> Slicer superbuild  + sharing branch between Slicer superbuild
>>>> checkout of [VTK, ITK, ..] and your local checkouts of [VTK, ITK, CTK, ...]
>>>>    -> Slicer superbuild + pass your custom build using ITK_DIR, VTK_DIR
>>>> ...
>>>>    -> combination of both
>>>>
>>>> Use case 3: Packager (Debian, Ubuntu ... )
>>>>   -> Simply build Slicer with Slicer_SUPERBUILD:OFF
>>>>   -> It will then use the system VTK, ITK, ...
>>>>
>>>> I think all use cases are addressed.
>>>>
>>>> Note: The case Slicer_SUPERBUILD:OFF will have to be tested. I guess
>>>> this could / will be done with the help of debian auto-packaging dashboard.
>>>> ( As an example and thanks to the work of Dominique, you can see the one of
>>>> CTK - see [1] and [2])
>>>>
>>>> Questions:
>>>>
>>>>  Can somebody agree on validating / testing / leading / benchmarking the
>>>> Improvement of the image reader ?
>>>>
>>>>  Am I missing something ?
>>>>
>>>> Jc
>>>>
>>>> [1] http://packages.qa.debian.org/c/ctk.html
>>>> [2]
>>>> https://buildd.debian.org/status/package.php?p=ctk&suite=experimental
>
>
>
> --
> +1 919 869 8849
>
> _______________________________________________
> 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