Re: [boost] Interest in color library.

From: Fabio Fracassi (f.fracassi_at_[hidden])
Date: 2005-09-27 06:01:35

Vladimir Prus wrote:

> Adam Badura wrote:
> 
>>> I get suspicious about the idea of using templated functions to work on
>>> image data, because
>>> - you can get slow compile times for non-trivial
>> 
>>     Yes. This can be hard. But I preffer that then have to write each
>>     class
>> by myself (those would also take time to compile) and to maintaint them
>> by myself.
> 
> It is not clear that you'll need really many classes. Specifically, do you
> know of any use case where you need to manipulate HSV color format
> directly? Say, scale an image in that format? I don't, but I'm not
> graphics expert.
> 
In Image processing you might use it. Depending on what you are doing with
the image different color models might be more appropriate than others. For
example Luminance is generally better suited for feature detection than
RGB. Depending on the algorithm it might be more efficient to convert the
Image once to the best suited color model and perform all manipulations on
the converted images.

IMO a generic Image processing library (to which the color library which is
discussed here is a first step) would be a great asset, especially for
research.

>>> It was already noted that YUV typically has different sizes for
>> components,
>>> so it is not exactly usable with the above function.
>> 
>>     Why?
> 
> Because you seem to associate a color object with each point. For YUV, the
> number of points for U and V and smaller than for Y. So, if I have
> 
>    color_yuv c = ...;
>    c.u();
> 
> what happens if the given point of image has no 'u' component?

Could you expand on what you mean here? I don't know much about different
image (or video) formates, so I might be wrong here, but I always assumed
that "different sizes for components" meant that in for example YUV844 an
16 bit pixel there are 8 bit Y and 4 bit for each U and V.
But from what you write it sounds more like: Only every second pixel carries
U and V data.
If this is the case the class that holds the color representation will
probably be more complex, and depend on a class that represents Image or
Video. Manipulation of Images that are represented in this way might be
slow, but it might still be faster than convert -> manipulate -> convert
back, if the image (or video) is big and only a few pixels are manipulated.
Whats more this is the only way to manipulate such an entity in-place.

Fabio