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

Sun Jul 17 11:33:24 EDT 2011

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