Re: [boost] Interest in color library.

From: Adam Badura (abadura_at_[hidden])
Date: 2005-09-26 12:48:04

> 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 will be harder to provide image manipulation plugins (as dynamic
> libraries)

    Here I thik I don't understnad what you mean. STL is also templet based
and is widely used...

> It was already noted that YUV typically has different sizes for
components,
> so it is not exactly usable with the above function.

    Why?

> In fact, I think your proposal lacks concrete goals and real-world
examples.
> Are you trying to get somethink like QColor
> (http://doc.trolltech.com/4.0/qcolor.html) with BSL license? Or color
> library that can handle any color model on earth?

    I took a look on QColor and this is not what I want to do. To be honest
at first I wanted something like this, but than chagedn my mind. I think a
better solution can be achived when library serves one class for each color
model (say it would be color_rgb, color_yuv, color_hsv, ...). Those classes
would serve basic functionality on manipulating on color components in to
manners: representation dependent and representation independent. Plus
naturally features like constants for some set of colors, reading colors
from string, or writing as a string, converting beetwean models (where
possible), darkening, lightening of a color and so like... Also I would like
to make controled functions and uncontroled (contorled would correct
uncorect data for example if R in RGB is unsigned 8 bit and user gives 257
it would round it to correct 255 or throw an error - but this should be easy
to turn on or of, so I'm still not sure how best to achive it).
    Another (larger) set of classes would take care of color representation.
Take RGB as an example. You can store it as just 3x8-bit, or 32 bit (with
different byte order possibilites!), or 3xfloat, or 3xdouble, or... or...
And this is only RGB! what with other formats. What with other libraries
(like DirectX or OpenGL - they too have their formats). All this are stil
RGB colors with theri properties but are stored differently in memory. So I
thought that it would be best to make a small class responisble for this
memory storage and serving of data (few simple functions like set and get
for each component). This would be easy to implement and library would have
its implementations for most common formats. And with such a class would be
parametrized color model class (you would have something like
color_rgb<rgb_8888> or color_rgb<rgb_float>).
    This would ease writing representation independend but due to template
use sill speed effective functions manipuleting on colors (for example
interpolating color one a triangle or something like this...). It would also
ease the task of color conversions. You would not have to have a conversion
for each representation, but only for each model.
    So I thought...

> If the latter, how about taking look at existing open-source drawing
> applications written in C++
>
> 1. Inkscape (http://inkscape.org) (Vector drawing tool)
> 2. Krita (http://www.koffice.org/krita/) (Pixel drawining tool)
>
> The latter is especially interesting because it supports CMYK, and 16-bit
> color depth.
>
> Maybe, you can study their code and describe how your library can benefit
> those projects? And then contact them to find their opinion? Or ask them
> what they'd like to have?

    Thanks. I will do this... I still have no good enough solution to some
problems so this would certenly help...

    Adam Badura