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

Stephen Aylward stephen.aylward at kitware.com
Mon Jul 18 21:58:42 EDT 2011 

Maybe the way to start is for some IJ articles to be written?

s

On Mon, Jul 18, 2011 at 9:39 PM, Stephen Aylward
<stephen.aylward at kitware.com> wrote:
> Hi Bill,
>
>>  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.
>
> Ah - so this was the mis communication...and it was my fault.   I
> phrased things very poorly.  Of course I wouldn't expect the
> Slicer-ITK repo to be the ITK repo.   Nor would I expect changes to be
> made untested, etc etc.    Those kinds of things are trivial if we
> agree to move forward with porting the changes (and creating tests,
> etc) to create a release version of ITK that supports Slicer
> packaging.
>
>> 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.
>
> This is really good input on how to design Slicer and its tests.
> Slicer is unusual in that we make deviating from a standard build to
> be an obscure process on purpose.   We want people to do what is
> standard - and yet we also want to get Slicer distributed broadly
> (e.g., as a Debian package).   We'll need to walk the line carefully.
>
>> We should be able to work this out. As I said before there is so much
>> shared interest, community and company involvement.
>
> Agreed.   Seems like this would be good for everyone.
>
>>
>> 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
>>>
>>
>
>
>
> --
>
> ==============================
> 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

More information about the Insight-developers mailing list