Re: [boost] GIL Image Processing Library - responses and more comments

From: Hailin Jin (hljin_at_[hidden])
Date: 2006-10-18 16:45:30

Hi Ulli -- we just tried your test file with GCC 4.0.2, GCC 4.1.1 and 
Visual Studio 2005 (VC8). I used Cygwin for both GCC tests. My machine 
is Xeon 3.2 dual CPU. Both proxy and accessor implementation run at the 
SAME speed (release builds: -O2 for GCC and /O2 for Visual Studio). So 
could it be that GCC 3 is not doing a good in optimizing the code?

Hailin

Ullrich Koethe wrote:
> Lubomir Bourdev wrote:
>>
>>> On the other hand, a PixelDereferenceAdapter is semantically also a 
>>> view, so the use of the view idea could be extended. 
>>
>>
>> PixelDereferenceAdapter is not a view. It is a function object to be
>> invoked upon pixel access, similar to your Pixel Accessor. You can
>> easily attach it to any iterator, locator or a view.
>>
>
> Consider the following view-like syntax:
>
>     pixel_view_A(dest_iter) = pixel_view_B(src_iter);
>
> Now, when you absorb the pixel_view objects into the iterators by 
> means of proxies, you get the GIL style of adaptation:
>
>     *pixel_view_iter_A = *pixel_view_iter_B;
>
> If you replace the assignment with a normal member function, you get 
> VIGRA data accessors (which, by the way, were invented by Dietmar 
> Kuehl, IIRC):
>
>      pixel_view_A.set(pixel_view_B(src_iter), dest_iter);
>
> All these should be semantically equivalent -- the only difference is 
> syntax and possibly performance. Hence I'm saying that pixel access 
> modifiers are essentially views, and treating them in that way may 
> simplify the documentation.
>
> The following advantages and disdvantages of either approach have 
> already been pointed out:
>
> Proxies: + nice syntax in algorithms
>          + compatible to STL
>          + can be chained
>          - harder to implement, harder to understand implementation
>          - may not work under some exotic circumstances
> DataAccessors:  + easy to implement, easy to understand
>                 + can be chained
>                 + do always work (even on non-conforming compilers)
>                 - slightly less readable syntax in algorithms
>
> To add some hard data to the comparison, I performed a benchmark were 
> I timed two proxy implementations vs the accessor approach for the 
> task of converting a planar RGB image into an interleaved one and vice 
> versa. It turned out that on my platform (Pentium M 1.7 GHz, cygwin 
> gcc 3.4.4), both proxy implementations were 30 to 60 percent _slower_ 
> than the equivalent data accessor version. The code is attached (it's 
> a stand-alone program).
>
>>
>> I understand your motivation for using pixel adaptors, but in my opinion
>> the benefits of using PixelDereferenceAdapter outweigh its
>> disadvantages.
>
> I'm not convinced.
>
>>
>> GIL incorporates a mechanism for active reduction of code bloat due to
>> variant instantiations. I will present this approach at the LCSD
>> workshop in the upcoming OOPSLA conference, which is in less than a
>> week: http://lcsd.cs.tamu.edu/2006/
>>
>
> I'd like to read this paper.
>
>>
>>> 3. I don't like that the input/output image format (jpeg, png etc.) 
>>> must be hardcoded in the program (by using jpeg_read_image() etc.).
>>
>>
>> We initially had a combined I/O methods like:
>>
>> template <typename Image>
>> void read_image(const char* file, Image& img) {
>>     switch (image_type_from_file_name(file)) {
>>         case kJPEG: jpeg_read_image(file,img); break;                
>> case kTIFF: tiff_read_image(file,img); break;
>>     ...
>>     }
>> }
>>
>> We decided to remove them for three reasons [snip] there are
>> plans to put in ASL a more advanced GIL I/O that allows for dynamic
>> registration of file format modules.
>
> VIGRA's import/export library almost supports this (the only missing 
> piece is the possibility to register new converters at runtime - at 
> the moment, they must be known at compile time, but otherwise there is 
> no need for a design modification).
>
>>> 6. GIL may have alignment problems. For example, the variant 
>>> template allocates internal memory as "char[MAX_SIZE]" but then 
>>> reinterpret_casts it to an image type. 
>>
>>
>> MAX_SIZE is determined by taking the maximum of the size_of of each
>> element in the MPL vector of image types with which the variant is
>> instantiated. So for every variant it is different, and the appropriate
>> size is evaluated at compile time.
>>
>
> I didn't say that the number of bytes was too small. I said that an 
> image object might be required to start at a multiple-of-8 address 
> (say), whereas a char array may start at an arbitrary address. So the 
> reinterpret_cast may return a forbidden address.
>
>>
>>> Casts from "signed short *" to "pixel<int16s, rgb_t> *" and similar 
>>> (see the tutorial) are also problematic
>>
>>
>> This cast is necessary to go from the outside world (pointer to the
>> beginning of the image) into GIL.
>> It is not obvious to me how to avoid it. How does VIGRA deal with the
>> case where the user constructs an 8-bit RGB image by providing VIGRA
>> with a raw pointer to the first pixel?
>>
>
> The DataAccessor takes care of this -- the iterator uses the original 
> pointer (see the PlanarAccessor in the attached program).
>
>>
>> We have been discussing the accessors/DereferenceAdaptors and promotion
>> traits issues in separate threads. Aside from these differences with
>> VIGRA, do you see any issues with the GIL interfaces that would prevent
>> porting the Vigra algorithms to GIL, or that would affect their
>> performance?
>> If yes, what interfaces are missing and what algorithms need them?
>>
>
> Three things come to mind:
> - many more type conversions; e.g. int8 => uint16; RGB <=> LAB etc.
> - adaptors for the subsampled image view
> - support for multi-dimensional images (e.g. volume data, image 
> sequences)
>
> Another important point are RGBA operations. In most cases, the alpha 
> channel is to be treated differently from the other channels, so you 
> can't just use component-wise operators as for the other color models. 
> VIGRA doesn't have an explicit RGBA type (TinyVector<T, 4> can be used 
> instead), because so far no-one came up with a convincing proposal for 
> these operations. But without them, RGBA is pretty useless.
>
> I don't think any of this is a show stopper, but it means considerable 
> work.
>
> And, of course, the documentation has to be improved a lot... (I 
> didn't look at the test suite.)
>
> Regards
> Ulli
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost