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