[ITK] [ITK-users] VectorImage vs image of vectors

Bradley Lowekamp blowekamp at mail.nih.gov
Mon Nov 10 12:02:42 EST 2014 

The underlying interaction with the buffer and the accessor is rather complicated. But the results of a access to the image is a reference not a copy.

I believe The problem with this filer and the VectorImage is the number temporaries created in these blocks:

https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Filtering/ImageFilterBase/include/itkRecursiveSeparableImageFilter.hxx#L105-L123

each of the terms creates a temporary variable length vector which causes an memory allocation.

I'll think about the best way to do this. I bet with out much trouble we can get 10-30x performance restoration... here.

Brad


On Nov 10, 2014, at 11:28 AM, Olivier Commowick <Olivier.Commowick at inria.fr> wrote:

> Hi,
> 
> I finally took some time to test this further using ITK smoothing filters. Here is an example file that illustrates my problem. Running it in some profiler, it appears that the time is truly lost in allocations and freeing elements (variable length vectors, method AllocateElements and free) when browsing elements in a vector image (while this doesn’t happen for images of itk vectors). Looking into it, there is a part of itk vectorimage I didn’t know about which is the accessor classes and functors. 
> 
> Would someone have an explanation of the system itself and if it might spend its time creating variable length vectors, or if the problem would come from somewhere else ? Nothing urgent though, I took the second technique in the previous email  for my urgent things.
> 
> Thanks in advance
> Olivier
> 
> 
>> On Nov 3, 2014, at 17:18 , Williams, Norman K <norman-k-williams at uiowa.edu> wrote:
>> 
>> 2 observations:
>> 
>> 1. I think the redundant SetSize you mentioned is almost certainly
>> unnecessary.  I¹ve seen similar unnecessary vector/array sizing other
>> places in ITK; I think it arose out of an abundance of caution, and just
>> never showed up on anyone¹s optimization radar yet.
>> 
>> 2. There¹s a technique you can use to get around the
>> itk::Image<itk::Vector<TScalar,TVecLength>, TDim> problem, if there is a
>> small, finite number of possible vector lengths.  Put the code using the
>> vector image inside a function templated over TVecLength.  Then at
>> runtime, determine the vector length and invoke the template function with
>> that vector length.
>> 
>> E.G.
>> 
>> template<typename TScalar,unsigned NVecLength, unsigned NDim>
>> void DoSomething()
>> {
>>  typedef itk::Image< itk::Vector<TScalar, NVecLength>, NDim > ImageType;
>>        ...
>> }
>> 
>> int main(int,char *[])
>> {
>>  ...
>>  switch(vecLength)
>>  {
>>  case 3:
>>     DoSomething<double,3,3>();
>>     break;
>>  case 11:
>>     DoSomething<double,11,3>();
>>  Š
>>  }
>> }
>> 
>> This is of course in most cases bad C++ programming practice, but it does
>> allow you to accommodate different data types in a program.
>> 
>> On 11/3/14, 8:39 AM, "Olivier Commowick" <Olivier.Commowick at inria.fr>
>> wrote:
>> 
>>> Hello all,
>>> 
>>> I encountered some weird behavior in ITK. For some reason, I have in my
>>> code some vector images that I need to smooth using a Gaussian filter. It
>>> appears that whether the image is stored as a VectorImage or an Image of
>>> itk Vectors is actually extremely important in terms of performance for
>>> this task. Namely, if using VectorImages, the processing time can be much
>>> worse (30s vs 1s with an image of vectors). My problem is that I cannot
>>> really use the templated itk::Image <itk::Vectors <Type, Size> , Ndim >
>>> since I do not know Size at compilation time.
>>> 
>>> Looking deeper into the code, I have two questions for whoever would know
>>> about these images:
>>> - the first one is on the Variable length vector: it seems to me that the
>>> operator= method always starts by destroying current data, even if the
>>> vector size is the same. It doesn¹t seem really efficient so I was
>>> wondering if there was any reason for that
>>> - the second one is on the VectorImage itself: is there something in it
>>> that would justify the computation times to be much worse ?
>>> 
>>> If someone has any info on which image type I should be using or why
>>> VectorImage would be slower, I would be grateful.
>>> 
>>> Thanks in advance
>>> 
>>> ---
>>> 
>>> Olivier Commowick, Ph.D.
>>> Research Scientist
>>> INRIA Rennes - Bretagne Atlantique, VISAGES Team
>>> Campus de Beaulieu
>>> 35042 Rennes
>>> FRANCE
>>> 
>>> Phone: +33 2 99 84 25 92
>>> Email: Olivier.Commowick at inria.fr
>>> Web: http://olivier.commowick.org/
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _____________________________________
>>> 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://www.kitware.com/products/protraining.php
>>> 
>>> 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://public.kitware.com/mailman/listinfo/insight-users
>> 
>> 
>> 
>> ________________________________
>> Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged.  If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited.  Please reply to the sender that you have received the message in error, then delete it.  Thank you.
>> ________________________________
> 
> 
> ---
> 
> Olivier Commowick, Ph.D.
> Research Scientist
> INRIA Rennes - Bretagne Atlantique, VISAGES Team
> Campus de Beaulieu
> 35042 Rennes
> FRANCE
> 
> Phone: +33 2 99 84 25 92
> Email: Olivier.Commowick at inria.fr
> Web: http://olivier.commowick.org/
> 
> 
> 
> 
> 
> <smoothingTest.cxx>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/community/attachments/20141110/8aac907e/attachment-0001.html>
-------------- next part --------------
_____________________________________
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://www.kitware.com/products/protraining.php

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://public.kitware.com/mailman/listinfo/insight-users

More information about the Community mailing list