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

Mon Jul 18 19:47:58 EDT 2011

Hello Stephen,

I'd thought I'd share my thoughts, because I can.

I think adding contributions 2 and 3 to make a 3.20.1 patch/minor release makes a lot of sense to me. Seems like good bug fixes to keep things working, for those who may need to say with 3.20.

However, with the 1st contribution I have some concerns. I have looked through Slicers repo, and I don't see the new methods used any other places besides the MRML IO. I couldn't find them in MetaImageIO as earlier suggested. So without a test to cover the new code in ITK, nor a performance timing of how it improves current IOs, I am not sure there is evidence that this would be a good contribution for the broader ITK community. As this is "just a performance" issue,  perhaps its optional. SuperBuild could add this patch, but the unfortunate system builds will not have this advantage? Additionally, I have large concerns with the compatibility with the follow patch: 71d8a7cee20cfcb11337aa9feb37c66f76d7ec73 and very much fear the maintainability of too many permutations of ImageIO options.

Brad

________________________________________
From: Stephen Aylward [stephen.aylward at kitware.com]
Sent: Monday, July 18, 2011 7:22 PM
To: Bill Lorensen
Cc: Slicer Devel List; Insight Developers; Julien Finet
Subject: Re: [Insight-developers] [slicer-devel] Strawman: ITK 3 tag to use     with slicer

Hi Bill,

I guess the common theme I'm picking up in your emails is that in
moving from release ITKv3.20 to ITKv3.21 you're against making the
changes necessary to support the packaging of Slicer for Debian
because creating a Debian package is an unusual case for Slicer, and
therefore an unusual case for ITK, and therefore not something that
should be considered in an ITK release.

I can see your point.  Supporting Slicer really isn't the ITK
developers' job.  Slicer developers can offer fixes, but those fixes
do not have to be accepted by the ITK developers.   It is kind of
incestuous that the ITK and Slicer development teams mix as much as
they do, and I can see how some could argue that ITK development,
Slicer development, etc should be kept apart so as not to bias one
another too much - I personally don't think that is best, but I do see
how some could think that and there are valid arguments along those
lines.

In the end, what needs to be done is what is best for the medical
image analysis community as a whole.  I'll defer it to y'all on this.

Stephen

PS> Sorry if I have misinterpreted your emails.  It really could be a
misunderstanding on my part - or perhaps there is a misunderstanding
on what is needed for packaging or what the Slicer community is
proposing for ITKv3.21?

As JC said, the changes Slicer needs for it to switch to ITKv3.21 are
the 13 listed at:
https://github.com/Slicer/ITK/commits/slicer-4.0
The features are
1) Don't require IO methods to copy data from the reader's internal
data storage to the reader's output image, instead just copy the
buffer pointer, when the pixel types in both are the same.
2) Fix VXL to support 64bit compilation
3) Update ITK to support the latest releases of gcc (gcc4.6)

On Mon, Jul 18, 2011 at 5:59 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> I'm sorry, what is the way?
>
> On Mon, Jul 18, 2011 at 5:56 PM, Stephen Aylward
> <stephen.aylward at kitware.com> wrote:
>> This is the way every debian user would use slicer...if they use the slicer
>> package.   These packages are installed via a simple package-add/apt-get
>> command.  It is really quite easy.  Particularly for apps, like slicer.
>>
>> I don't think debian packaging should be viewed as an unsupported or an
>> odd/advanced case.
>>
>> All of our open source packages should shoot for being debian packages and
>> easy to install/use in the ways that have the greatest impact.
>>
>> S
>>
>> On Jul 18, 2011 5:42 PM, "Bill Lorensen" <bill.lorensen at gmail.com> wrote:
>>> That is my point. Are we trying to address a sophisticated use case or
>>> one that a normal user might encounter.
>>>
>>> Is there an existing dashboard that is using a system itk, vtk, ctk,
>>> etc...
>>>
>>> On Mon, Jul 18, 2011 at 5:36 PM, Julien Finet <julien.finet at kitware.com>
>>> wrote:
>>>> There is no SLICER_USE_SYSTEM_ITK...
>>>> However, if you don't provide any ITK_DIR, it will try to find
>>>> (find_package) an ITK directory. So if it's installed on your machine
>>>> (and
>>>> the only ITK on the machine), it should use it automatically.
>>>> Julien.
>>>>
>>>> On Mon, Jul 18, 2011 at 5:30 PM, Bill Lorensen <bill.lorensen at gmail.com>
>>>> wrote:
>>>>>
>>>>> So can I do this now?
>>>>>
>>>>> I'd like to test it.
>>>>>
>>>>> Bill
>>>>>
>>>>> On Mon, Jul 18, 2011 at 5:19 PM, Stephen Aylward
>>>>> <stephen.aylward at kitware.com> wrote:
>>>>> > Hi Bill,
>>>>> >
>>>>> > Great way of phrasing it....this is exactly the use case we're
>>>>> > shooting for.   It is the use-case needed for the Debian packaging.
>>>>> > Each Debian package should not provide its own version of ITK, VTK,
>>>>> > etc - they should be shared.
>>>>> >
>>>>> > Stephen
>>>>> >
>>>>> > On Mon, Jul 18, 2011 at 5:13 PM, Bill Lorensen
>>>>> > <bill.lorensen at gmail.com>
>>>>> > wrote:
>>>>> >> For example, is there a SLICER_USE_SYSTEM_ITK, SLICER_USE_SYSTEM_VTK,
>>>>> >> SLICER_USE_SYSTEM_CTK, etc...
>>>>> >>
>>>>> >> I don't want be a PITA, I just want to make sure that we don't spend
>>>>> >> time on a non-supported use-case.
>>>>> >>
>>>>> >> On Mon, Jul 18, 2011 at 5:08 PM, Bill Lorensen
>>>>> >> <bill.lorensen at gmail.com> wrote:
>>>>> >>> But who is doing this now? Is this a common use case?
>>>>> >>>
>>>>> >>> On Mon, Jul 18, 2011 at 4:33 PM, Steve Pieper <pieper at ibility.net>
>>>>> >>> wrote:
>>>>> >>>> You should be able to do it just by setting the ITK_DIR with cmake
>>>>> >>>> in
>>>>> >>>> the
>>>>> >>>> build directory and then remaking.
>>>>> >>>>
>>>>> >>>> On Mon, Jul 18, 2011 at 4:19 PM, Bill Lorensen
>>>>> >>>> <bill.lorensen at gmail.com>
>>>>> >>>> wrote:
>>>>> >>>>>
>>>>> >>>>> I agree about the version explosion. I wish we did not have this
>>>>> >>>>> diversion.
>>>>> >>>>>
>>>>> >>>>> So, do we currently support a slicer with an installed system ITK
>>>>> >>>>> version? How do I configure a build to use it? I'd like to try it.
>>>>> >>>>>
>>>>> >>>>> Bill
>>>>> >>>>>
>>>>> >>>>> On Mon, Jul 18, 2011 at 4:05 PM, Steve Pieper <pieper at ibility.net>
>>>>> >>>>> wrote:
>>>>> >>>>> > Hi Bill -
>>>>> >>>>> >
>>>>> >>>>> > Most developers build their own and most users will get the
>>>>> >>>>> > binary
>>>>> >>>>> > package
>>>>> >>>>> > of slicer that comes with ITK (and other things) pre-compiled.
>>>>> >>>>> > The
>>>>> >>>>> > special
>>>>> >>>>> > case is debian/ubuntu, where we'd like to be able to provide a
>>>>> >>>>> > slicer
>>>>> >>>>> > package that relies only on the standard system installed
>>>>> >>>>> > versions
>>>>> >>>>> > of
>>>>> >>>>> > all
>>>>> >>>>> > libraries.  Presumably the same approach would work for other
>>>>> >>>>> > linux
>>>>> >>>>> > distributions too, although nobody is working on those, I think.
>>>>> >>>>> >
>>>>> >>>>> > Aside from the convenience for linux distributions, I think it
>>>>> >>>>> > would be
>>>>> >>>>> > good
>>>>> >>>>> > practice not to have too many versions of ITK floating around.
>>>>> >>>>> >
>>>>> >>>>> > -Steve
>>>>> >>>>> >
>>>>> >>>>> > On Mon, Jul 18, 2011 at 3:43 PM, Bill Lorensen
>>>>> >>>>> > <bill.lorensen at gmail.com>
>>>>> >>>>> > wrote:
>>>>> >>>>> >>
>>>>> >>>>> >> Do not most slicer developers build their own version of ITK?
>>>>> >>>>> >> Or
>>>>> >>>>> >> do
>>>>> >>>>> >> they use a system ITK?
>>>>> >>>>> >>
>>>>> >>>>> >> On Mon, Jul 18, 2011 at 3:37 PM, Stephen Aylward
>>>>> >>>>> >> <stephen.aylward at kitware.com> wrote:
>>>>> >>>>> >> > Hi,
>>>>> >>>>> >> >
>>>>> >>>>> >> > Using superbuild to apply patches doesn't help create a
>>>>> >>>>> >> > version
>>>>> >>>>> >> > of
>>>>> >>>>> >> > ITK
>>>>> >>>>> >> > that can be used with the Debian package of Slicer.
>>>>> >>>>> >> >
>>>>> >>>>> >> > Perhaps the version of ITK being used with Slicer should
>>>>> >>>>> >> > become
>>>>> >>>>> >> > ITK
>>>>> >>>>> >> > v3.21 instead of cherrypicking from it.   I believe what your
>>>>> >>>>> >> > are
>>>>> >>>>> >> > proposing would only provide one feature difference between
>>>>> >>>>> >> > ITK3.20
>>>>> >>>>> >> > and 3.21, i.e., the ability to compile on gcc4.6 - doesn't
>>>>> >>>>> >> > seem
>>>>> >>>>> >> > like
>>>>> >>>>> >> > a
>>>>> >>>>> >> > good reason for a whole new release.   By not including the
>>>>> >>>>> >> > other
>>>>> >>>>> >> > patches that the Slicer folks are providing we loose the
>>>>> >>>>> >> > chance
>>>>> >>>>> >> > to
>>>>> >>>>> >> > build itk with 64bits and fix other bugs.
>>>>> >>>>> >> >
>>>>> >>>>> >> > s
>>>>> >>>>> >> >
>>>>> >>>>> >> > On Mon, Jul 18, 2011 at 3:19 PM, Bill Lorensen
>>>>> >>>>> >> > <bill.lorensen at gmail.com>
>>>>> >>>>> >> > wrote:
>>>>> >>>>> >> >> Folks,
>>>>> >>>>> >> >>
>>>>> >>>>> >> >> We have been discussing multiple issues in this thread. I
>>>>> >>>>> >> >> propose
>>>>> >>>>> >> >> the
>>>>> >>>>> >> >> following strawman (my knowledge of all of the different
>>>>> >>>>> >> >> config
>>>>> >>>>> >> >> possibilities is limited):
>>>>> >>>>> >> >>
>>>>> >>>>> >> >> 1) ITK 3.20, should build with gcc4.6. Apparently Debian is
>>>>> >>>>> >> >> using
>>>>> >>>>> >> >> gcc4.6.
>>>>> >>>>> >> >>    We should apply the minimum patches to ITK 3.20 to
>>>>> >>>>> >> >> compile
>>>>> >>>>> >> >> with
>>>>> >>>>> >> >> 4.6. These seem to be a small number of changes.
>>>>> >>>>> >> >>
>>>>> >>>>> >> >> 2) The specialised patches to ITK 3.20 (e.g. 64 bit support)
>>>>> >>>>> >> >> required
>>>>> >>>>> >> >> for Slicer3/4 can be delivered via the Slicer3/4 superbuild
>>>>> >>>>> >> >> mechanism.
>>>>> >>>>> >> >>
>>>>> >>>>> >> >> 3) Slicer4 patches to ITKv4 should follow the procedures to
>>>>> >>>>> >> >> add
>>>>> >>>>> >> >> changes to ITK:
>>>>> >>>>> >> >>
>>>>> >>>>> >> >>
>>>>> >>>>> >> >> http://itk.org/Wiki/ITK_Release_4/New_Code_Contribution_Process .
>>>>> >>>>> >> >> The
>>>>> >>>>> >> >> goal will be to have Slicer4 build/test with ITKv4.
>>>>> >>>>> >> >>
>>>>> >>>>> >> >> Slicer is an important ITK customer and the Slicer/ITK
>>>>> >>>>> >> >> community has
>>>>> >>>>> >> >> large overlap and funding.
>>>>> >>>>> >> >>
>>>>> >>>>> >> >> Let's refine these topics and come to consensus.
>>>>> >>>>> >> >>
>>>>> >>>>> >> >> Bill
>>>>> >>>>> >> >> _______________________________________________
>>>>> >>>>> >> >> slicer-devel mailing list
>>>>> >>>>> >> >> slicer-devel at bwh.harvard.edu
>>>>> >>>>> >> >>
>>>>> >>>>> >> >> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
>>>>> >>>>> >> >> To unsubscribe: send email to
>>>>> >>>>> >> >> slicer-devel-request at massmail.spl.harvard.edu with
>>>>> >>>>> >> >> unsubscribe
>>>>> >>>>> >> >> as
>>>>> >>>>> >> >> the
>>>>> >>>>> >> >> subject
>>>>> >>>>> >> >>
>>>>> >>>>> >> >
>>>>> >>>>> >> >
>>>>> >>>>> >> >
>>>>> >>>>> >> > --
>>>>> >>>>> >> >
>>>>> >>>>> >> > ==============================
>>>>> >>>>> >> > 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
>>>>> >>>>> >> >
>>>>> >>>>> >
>>>>> >>>>> >
>>>>> >>>>
>>>>> >>>>
>>>>> >>>
>>>>> >>
>>>>> >
>>>>> >
>>>>> >
>>>>> > --
>>>>> >
>>>>> > ==============================
>>>>> > 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
>>>>> >
>>>>> _______________________________________________
>>>>> slicer-devel mailing list
>>>>> slicer-devel at bwh.harvard.edu
>>>>> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel
>>>>> To unsubscribe: send email to
>>>>> slicer-devel-request at massmail.spl.harvard.edu with unsubscribe as the
>>>>> subject
>>>>
>>>>
>>
>

--

==============================
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
_______________________________________________
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