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

[Jean-Christophe Fillion-Robin]

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

On Mon, Jul 18, 2011 at 9:58 PM, Stephen Aylward <
stephen.aylward at kitware.com> wrote:

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



-- 
+1 919 869 8849
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20110718/c1353935/attachment.htm>