[Insight-developers] Wrapping Explosion

[Luis Ibanez]

Hi Vincent,

The classes in this list are quite useful and
are probably among the first segmentation
methods people may want to use.

We plan to translate to Python all the current
examples in the SoftwareGuide. The classes in
your list are certainly among this set.


   Luis


-----------------------------------

Vincent A. Magnotta wrote:
> We have been working both to expand some of the data types included in
> the wrapping as well as include some of the filters not originally
> wrapped in ITK. Here are a list of just a few filters not currently
> wrapped in ITK:
> 
> itkCurvatureFlowImageFilter
> itkMinMaxCurvatureFlowImageFilter
> itkNeighborhoodConnectedImageFilter
> itkIsolatedConnectedImageFilter
> itkGradientMagnitudeImageFilter
> itkFastMarchingImageFilter
> 
> We identified these based on some work we have been doing to integrate
> ITK Region growing and Level set segmentation into our software.
> 
> I would propose that we break wrapping into segments based on number of
> image dimensions. That way people could turn on wrapping for their
> particular problem and compilation times should not change very much for
> turning on just a single dimension. 
> 
> Vince
> 
> 
> On Thu, 2003-11-20 at 07:31, William A. Hoffman wrote:
> 
>>Hi,
>>
>>Are all the wrappings required to build ITK or an application in ITK?
>>If you think they are not general enough, I would recommend wrapping
>>them in your application only.   You should be able to wrap ITK classes
>>outside of the ITK tree.   With all the combinations, I could see
>>us with IOWA_EXPANDED_WRAPPING GE_EXPANDED_WRAPPING ... you get the idea.
>>
>>
>>-Bill
>>
>>
>>At 10:24 PM 11/19/2003, Hans J. Johnson wrote:
>>
>>>Hello All,
>>>
>>>A week or so ago, Luis stated that we would be adding classes to the
>>>wrapping as they are needed.  Well, the Iowa group is in the process of
>>>needing an awful lot of ITK to be wrapped for TCL.
>>>
>>>I'm currently working through the details of adding a couple of hundred
>>>more filter combinations to the wrapping for our current project.  I'm
>>>afraid that if I do this, it will greatly increase the compile time of
>>>the wrapping code, and many people may not want all the filters that we
>>>intend to add.
>>>
>>>I have no problem with the increased compile times, but I wanted to make
>>>sure that it will not undermine some of the nightly regression tests.
>>>
>>>If compile times are an issue, I would propose that we (i.e. the iowa
>>>gorup) implement a CMAKE conditional -- EXPANDED_WRAPPING -- that when
>>>turned off compiles a core set of the wrapping functionallity, and when
>>>turned on compiles the greatly extened set functionality.
>>>
>>>We've started the work, and want to make sure it benefits others without
>>>causing too much headache by default.
>>>
>>>Regards,
>>>Hans
>>>
>>>
>>>_______________________________________________
>>>Insight-developers mailing list
>>>Insight-developers at itk . org
>>>http://www . itk . org/mailman/listinfo/insight-developers
>>
>>_______________________________________________
>>Insight-developers mailing list
>>Insight-developers at itk . org
>>http://www . itk . org/mailman/listinfo/insight-developers
>