Re: [boost] GIL Image Processing Library - specific comments

From: ïÌÅÇ áÂÒÏÓÉÍÏ× (olegabr_at_[hidden])
Date: 2006-10-18 13:15:10

Lubomir Bourdev writes:
> Hi Ulli,
> 
> Thanks for spending time to review GIL. 
> 
> [...]
>> A traditional STL style solution would probably be easier:
>>
>>    transform(source.begin(), source.end(), destination.begin(),
>>              SomeFunctor());
>>
>> (since implementing a view is more involved than implementing 
>> a functor, at least in terms of reading documentation).
> 
> They are not quite equivalent. Views can transform both the domain and
> the range of images. For example, a view may change the way its
> horizontal and/or vertical iterators advance, and similarly may perform
> a transformation upon dereferencing (which your SomeFunctor does). We
> find it appealing to represent this as a single object (view) rather
> than splitting it into multiple parts, such as ranges and accessors.
> Yes, I know these are conceptually different transformations, and they
> are implemented in different classes; they are just combined in the
> View. It is appealing because conceptually it just represents an
> abstract image. And you can pipe views nicely together.
> Another difference is in performance:  copy_pixels(src,dst) is usually
> faster than the STL equivalent std::copy(src.begin(), src.end(),
> dst.begin())
> This is because the one-dimensional iterators are slower, as they have
> to deal with potential padding at the end of rows, and also because we
> provide performance specializations.
> 

Seems like no one have mentioned segmented iterators so far. They can make your 1D iterators as fast as 2D counterparts.

Oleg Abrosimov.