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