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

Mon Jul 18 19:56:13 EDT 2011

Stephen,

First of all, these are my thoughts, not those of the ITK community.

There are at least two issues:

1) ITK support for the gcc 4.6 compiler. This seems like a no brainer
although I have not tried gcc 4.6 yet to see the issues.

2) The Slicer patches to itk3.20 are another issue. These should
proceed through the normal ITK channels. I do not recall any gerrit
patches for slicer fixes. I do know of one mantis bug however. They
are certainly welcome, but should go through the normal review
process.

 It would be difficult although not impossible to accept the slicer
repo as ITK 3.22 (3.21 is a development branch, not a release brnch).
My concern is the lack of testing and dashboards for 3.22.

As for debian packaging in the short term, I do not see a tested use
case that supports an installed ITK system. I do not see the usual
support for an ITK system build in the Slicer build.

We should be able to work this out. As I said before there is so much
shared interest, community and company involvement.

Bill

On Mon, Jul 18, 2011 at 7:22 PM, Stephen Aylward
<stephen.aylward at kitware.com> wrote:
> 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
>