Re: [boost] [gil] Ideas to make my extension more generic?

From: John Femiani (JOHN.FEMIANI_at_[hidden])
Date: 2007-04-29 03:41:37

Lubomir, 
Regarding your comment:

> I haven't thought much about this, but this is 
> k-order statistic (in an array of numbers, find 
> the K-th smallest one). There is an algorithm to do
> this in O(N). This would be rather useful, perhaps
> someone should put it in Boost?

It is part of the stl already: std::nth_element in the <algorithm>
header.

Also,

> My suggestion is to ignore the fact that there are multiple channels
in a
> pixel and just white the algorithm to operate on a grayscale image. It
is
> then trivial to extend it by using nth_channel_view.

But nth_channel_view does not work for heterogeneous pixels, runtime
specification of the channel requires that all channels be of the same
type. As you said in an earlier post 'n' means runtime, 'k' means
compile time. 

This is exactly the type of issue I have been having when I try to write
code that is generic enough to apply to heterogeneous pixels.
Unfortunately I have started writing code that simply precludes
heterogeneous pixels (using nth_channel_view or operator[] to loop
through channels) because I was spending too much time trying to write
functors for every operation I needed to do on an image.  

I posted a message on the sourceforge discussion and I will summarize it
here:

I saw the recent posting on fixed point (or scaled value) types in the
works by Phil Endecott, and apparently another version by Maurizio
Vitale, and I was wondering whether GIL folks thought this could be
useful for describing individual samples in gil.  Instead of using
bits8, one could define a pixel in terms of scaled<uint8_t, 255>, or
scaled<uint16_t, 255>, etc. Operations on the pixels can deduce the
return type for each channel using the methods applied by the fixed
point authors.  This way each channel, regardless of its type, should
produce expected results for an expression without all the tweaking
required when dealing with integer types directly. Any operation on a
pixel could be applied to each of its channels, like in valarray, and
code that uses operations on pixels is automatically generic wrt
heterogeneous layouts as long as all channels have similar semantic
meanings.
    

John