[Insight-developers] ITK 3 tag to use with slicer? Fwd: Slicer release schedule

Mon Jul 18 10:42:50 EDT 2011

I have been submitting an Experimental build of Slicer4/ITKv4 since
January. It appears under the name BillsBasement. It had been very
useful at detecting ITKv4 chnages that affect Slicer4.

It will be great to have an official nightly.

Bill

On Mon, Jul 18, 2011 at 9:30 AM, Jean-Christophe Fillion-Robin
<jchris.fillionr at kitware.com> wrote:
> That leads to the following question:
>   1) Who will be in charge of generalizing the "image-reader-speedup"
> project ?
>   2) When should we expect this project to be done ?
>
> Note: Thanks to the work of Hans, Slicer4 could compile without to much
> effort against ITKv4. If that help, we could have regular SlicerITKv4
> dashboard soon. In other words, Slicer would have an option named
> Slicer_USE_ITKv4.
>
> Thanks
> Jc
>
> On Mon, Jul 18, 2011 at 9:25 AM, Steve Pieper <pieper at ibility.net> wrote:
>>
>> Hi -
>>
>> For my part I hope these changes, particularly the speed ups for using the
>> reader's buffer in an ImageReader, can go in both itk3.x and itk4.x --
>> otherwise I guess we'll need to provide a non-standard fork of ITK for
>> slicer's use and that's not good for anyone.  AFAIK these changes are needed
>> for both slicer3 and slicer4, so restricting this to slicer3 only would not
>> be much good.
>>
>> If there use cases in ITK that won't work with this, as Brad suggests,
>> then it would be great to work through those and come up with a general
>> solution.  I tend to agree with Stephen's assessment that the memory read
>> buffer change is backwards compatible with the ITK API, but I could
>> definitely be missing something.
>>
>> Best,
>> Steve
>>
>>
>>
>> On Sun, Jul 17, 2011 at 6:31 PM, Stephen Aylward
>> <stephen.aylward at kitware.com> wrote:
>>>
>>> Also works with metaio.
>>>
>>> Happy for this not to go into itk4.  We just need it in 3.21.
>>>
>>> S
>>>
>>> On Jul 17, 2011 11:33 AM, "Bradley Lowekamp" <blowekamp at mail.nih.gov>
>>> wrote:
>>> >
>>> > On Jul 17, 2011, at 8:25 AM, Stephen Aylward wrote:
>>> >
>>> >> Hi JC,
>>> >>
>>> >> To accomplish the goal of having this ITKv3 release be the release
>>> >> used for Slicer requires your 64-bit modifications to be included
>>> >> (that you discuss below), right?
>>> >>
>>> >> Also, good catch on the IO framework changes. They are backward
>>> >> compatible (i.e., they offer significant IO speedup without breaking
>>> >> the API), and the speedup is also very important to Slicer - these
>>> >> changes should also be included in the release.
>>> >
>>> > Stephen,
>>> >
>>> > If I understand this change correctly, this patch allows the usage of a
>>> > buffer allocated by the ImageIO to be passed all the way to the Image class
>>> > if all the types match up. The is accomplished by adding the following
>>> > methods: ImageIO::CanUseOwnBuffer, ImageIO::ReadUsingOwnBuffer() and
>>> > ImageIO::GetOwnBuffer.
>>> >
>>> > I assume that this change is for the MemoryImageFileReader that is used
>>> > with Slicer. ( can see how this could be quite advantageous ( and also the
>>> > potential for scary alias when combined with InPlace filters ). But as not
>>> > one single ITK ImageIO has support for these methods. I'd like to question
>>> > if they should be brought into the ITK main repo, as they don't appear to
>>> > currently provide any benefit to ITK and only complicate as already
>>> > complicated interface to the ImageIO. If these changes are desired in ITK,
>>> > then I would strongly encourage better documentation for the new methods in
>>> > ImageIO, to enable new developers with add this feature to ImageIO classes.
>>> >
>>> > Brad
>>> >
>>> >>
>>> >> Thanks!
>>> >> Stephen
>>> >>
>>> >>
>>> >>
>>> >> On Sat, Jul 16, 2011 at 8:16 PM, Jean-Christophe Fillion-Robin
>>> >> <jchris.fillionr at kitware.com> wrote:
>>> >>> Bill,
>>> >>>
>>> >>> If this hasn't been fixed already, would be great to integrate the
>>> >>> following
>>> >>> patches also:
>>> >>>
>>> >>> 1) To compile ITK 3.20 on 64bits windows
>>> >>>
>>> >>> Merge branch 'fix-vnl-64bits-compile' into slicer-4.0
>>> >>>
>>> >>> * fix-vnl-64bits-compile:
>>> >>> Review DETERMINE_TYPE vxl macro
>>> >>> Add VXL_SIZEOF_SIZE_T test
>>> >>> Add VXL_HAS_WIN_WCHAR_T test
>>> >>>
>>> >>> Update VXL_HAS_TYPE_OF_SIZE test
>>> >>>
>>> >>>
>>> >>>
>>> >>> See
>>> >>>
>>> >>> https://github.com/Slicer/ITK/commit/71e4277a785ae0f14c5c1cd2a8df1a70d99f1052
>>> >>>
>>> >>>
>>> >>> Stephen,
>>> >>>
>>> >>> 2) What should we do regarding the following commits:
>>> >>>
>>> >>> Merge branch 'reader-speedup-reuse-buffer' into HEAD
>>> >>>
>>> >>> See
>>> >>>
>>> >>> https://github.com/Slicer/ITK/commit/5ec3d26e2d5533cb06f7fd0801593e16b77a2c96
>>> >>>
>>> >>> and
>>> >>>
>>> >>> Merge branch 'MetaIOUpdate' into slicer-4.0
>>> >>>
>>> >>> See
>>> >>>
>>> >>> https://github.com/Slicer/ITK/commit/9a6954f7a278fc010551980c8413cecb5c48ea62
>>> >>>
>>> >>>
>>> >>>
>>> >>> Regarding the MetaUIUpdate, would it be possible to add a flag /
>>> >>> property so
>>> >>> that:
>>> >>> - people using ITK 3.20 could then benefit from your improvement
>>> >>> - backward compatibility is maintained
>>> >>>
>>> >>> Thanks
>>> >>> Jc
>>> >>>
>>> >>> On Sat, Jul 16, 2011 at 6:03 PM, Stephen Aylward
>>> >>> <stephen.aylward at kitware.com> wrote:
>>> >>>>
>>> >>>> Hi Luis,
>>> >>>>
>>> >>>> Thanks for the reminder!
>>> >>>>
>>> >>>> Transparency, openness, and community involvement are key to ITK.
>>> >>>>
>>> >>>> What are the typical steps when considering backporting changes to
>>> >>>> an old
>>> >>>> version of itk?
>>> >>>>
>>> >>>> S
>>> >>>>
>>> >>>> On Jul 16, 2011 11:34 AM, "Luis Ibanez" <luis.ibanez at kitware.com>
>>> >>>> wrote:
>>> >>>>> On Sat, Jul 16, 2011 at 10:33 AM, Stephen Aylward
>>> >>>>> <stephen.aylward at kitware.com> wrote:
>>> >>>>>> I guess we could propose that itk-slicer become the next itk3
>>> >>>>>> release,
>>> >>>>>> but
>>> >>>>>> it would probably have to be funded by na-mic.
>>> >>>>>>
>>> >>>>>> Perhaps Hans as Pres and Bill as CTO of the ISC should decide?
>>> >>>>>>
>>> >>>>>
>>> >>>>> ---------------------------------------------------------------------
>>> >>>>>
>>> >>>>> I'm disappointed to have to remind this group that
>>> >>>>> this is *NOT* how Open Source communities operate.
>>> >>>>>
>>> >>>>> Decisions that involve the entire community are *NOT*
>>> >>>>> to be made by a couple of members of hierarchical
>>> >>>>> organization, not even the ISC.
>>> >>>>>
>>> >>>>>
>>> >>>>> ITK is not a Corporation.
>>> >>>>>
>>> >>>>> It is an Open Source project.
>>> >>>>>
>>> >>>>>
>>> >>>>> Changes are to be proposed to the community and
>>> >>>>> to be voted upon using the grassroots governance
>>> >>>>> structure that is already in place.
>>> >>>>>
>>> >>>>> Backroom negotiations are poisonous for an
>>> >>>>> Open Source projects. They send the signal to
>>> >>>>> developers that no matter how much sweet and
>>> >>>>> blood they put into the project, at the end we have
>>> >>>>> not respect for their opinion when it comes to making
>>> >>>>> important decisions that affect the entire project.
>>> >>>>>
>>> >>>>> It is *NOT* the role of the ISC to decide on the content
>>> >>>>> of an ITK release. That is up to the developers team
>>> >>>>> to decide.
>>> >>>>>
>>> >>>>>
>>> >>>>> Please:
>>> >>>>>
>>> >>>>>
>>> >>>>> A) Make this discussion public in the ITK developers list.
>>> >>>>> B) Put a proposal in an ITK Wiki page.
>>> >>>>> C) Explain the technical rationale for the proposal
>>> >>>>> D) Gather feedback from the community
>>> >>>>> E) Reach consensus
>>> >>>>> F) Execute
>>> >>>>>
>>> >>>>>
>>> >>>>> The day when ITK software decisions will be made by
>>> >>>>> a bureaucratic minority, that will be a great day to Fork.
>>> >>>>>
>>> >>>>>
>>> >>>>> Luis
>>> >>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>> +1 919 869 8849
>>> >>>
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >>
>>> >> ==============================
>>> >> 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
>
>
> _______________________________________________
> 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
>
>