From: Fabio Fracassi (f.fracassi_at_[hidden])
Date: 2005-09-17 11:33:29
Adam Badura wrote:
>> like RGBA 8:8:8:8 or YUV 4:2:2, etc...
> What "etc.."? I need to know such things... :) Or do you have any
> sugestions for a "general foramt specification"?
I was just giving a few examples of common color encodings, using a rather
common scheme, the names of the Channels, and the number of bytes to encode
http://www.fourcc.org/rgb.php and http://www.fourcc.org/yuv.php give an
overview of several common pixel formats.
> Why do you use colors in format in which components are integers in
> range 0...255 and not floats in range 0.0...1.0? I want to know to better
> understand the task? (I know that WIndows uses such a format and that as I
> suppose ale the data that is received be devices is finally in this format
> but do you have any other reasons).
No, no other reasons. Most algorithms which work on images need to be as
efficient as possible, so I only convert colors to float if I need to (i.e.
repeated subsampling, etc.)
Of course I also like to have the matching float colors. OpenGL can use
them, at least as a drawing color, I haven't checked if it can use them as
texture, too. Unless you need extra high color fidelity (e.g. HDR-Images,
Photo post-production) the additional space which is required to store
floats is overkill.
My main concern is that the color library supports common pixel storage
formats so that I can handle raw image buffers without copying them first
in a typesafe way, or even more importantly to pass a data structures of
consecutive color library pixels as a a raw buffer, like for example (it
should demonstrate how such a library might be used, its not meant as a
load_from_file("test.png", img, width, height);
color_library_pixel p = img[10 * width + 5] // returns pixel at (5, 10)
This makes it possible to write high level image classes, with minimal
storage and an efficient interface to lower level code.
> Adam Badura
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk