Enumeration of pixel formats?

(This is actually a bit off-topic in the context I’m currently most interested
in it, but…)

Is it feasible to encode/enumerate pixel formats in a way that fits into say
around 8 bits, rather than using the usual structure with size and shift for
each field? What I need is a bunch of 32 bit integer constants that fit into a
relatively large set of types, covering the majority of integer, float and
fixed point data formats used on various platforms, including endianness.

Ok, why do I want to do this?

Well, it’s for the data type management of MAIA, the Multimedia Application
Integration Architecture. (Note: The web site is really in need of an update;
the name has changed, as well as major parts of the files released so far.)

Basically, what I need is a simple, single step way of identifying and matching
data types of very simple objects, such as integers, floats, fixed point
numbers and RGB pixels. (More complex stuff is handled with arrays and
extended protocols in order to keep complexity and overhead away from the
general case. This is to be used primarily in low latency hard RT systems.)

So far, it has been quite easy to encode ints, floats and similar formats of
various sizes up to the (current) maximum of 128 bits, but the well known pixel
format mess worries me a bit… Is it safe to assume that all hardware can be
covered with something like

fields: 4 bits;
sizes:	4 bits;

that is, max 16 field arrangements (RGB, BGR, RGBA, ABGR, ARGB, BGRA etc) and
max 16 field size combos (555, 565, 5551, 1555, 4444, 8888 etc)? (Perhaps more
than 4 bits per field - no absolute limit here; just less than 16 bits or so
total.) (Note that endian is encoded in other bits.)

Could something like this cover all graphics hardware, or should I go for a
more powerful solution right away? (Could go to 64 bits per ID, allowing small
structs rather than tiny bit fields… By the time this API will be of any
importance, we’ll probably be using true 64 bit CPUs for any serious processing
anyway.)

Note: It’s not required that all necessarry information is encoded in the
type ID; it just has to be possible to define one unique ID for every single
fundamental data type that we’ll ever see in a multimedia system. (Preferably.)
The details will be hardcoded into conversion libraries and plugins anyway, as
well as being available in IDL format or similar for those who prefer to use
that. The IDs are just references to format specifications, although I’d
still like them to be encoded in some logically sensible way, as far as
possible.

Another note: I’m not talking about any compressed formats here; not even
special uses of integers and stuff, as that belongs on a higher level as well.
Just raw data types that are usually treated as single “words”, rather than
structs or bit fields. RGB, HSV, CMYK etc is as complex as it gets on this
level. (As if that’s not complex enough… :wink:

I’d be grateful for som input - it’s not critical, or extremely urgent, but I’d
like to get it right ASAP, so I don’t have to mess with it later on, after the
MAIA 1.0 API finalizition. (It’s possible to do that rather nicely, but… it’s
not going to be fun if I don’t have enough bits for nice encoding.)

//David

…- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' ..- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -’