[OSC_dev] 32 bit RGBA color format

[Chris Byrne]

Hi,

Is there a clearer explanation for the format of the 32 bit RGBA color
type (OSC Type Tag 'r')?

We would like to make use of this type, but very few implementations
actually support it, and those that do seem to be encoding it
differently. The Open Sound Control 1.0 Specification only defines the
argument as a 32 bit RGBA color, and does not specify in which order
the components are actually sent.

e.g. RGBA, ABGR, BGRA?

[Alexandre Quessy]

Hello!

Post by Chris Byrne
Is there a clearer explanation for the format of the 32 bit RGBA color
type (OSC Type Tag 'r')?

I don't know the answer to this question, but I would say this:

RGBA, with 1 byte per color, little endian. That results in a 32-bit color.
Of course, it would be nice to also be able to send 64-bit color, but
the user can define his/her own argument format for that.
See http://en.wikipedia.org/wiki/RGB_color_model#The_32-bit_RGB_representation

[Kurt Sterckx]

Chris,



I suggest that you use the same format as the Ventuz OSC.Net library (the only one I known that supports RGBA):



http://opensoundcontrol.org/implementation/ventuz-realtime-3d-rendering-net



I think it is the same format as suggested by Alexandre Quessy.



Regards,



Kurt

Date: Mon, 12 Jul 2010 17:41:26 -0700
Subject: [OSC_dev] 32 bit RGBA color format
Hi,
Is there a clearer explanation for the format of the 32 bit RGBA color
type (OSC Type Tag 'r')?
We would like to make use of this type, but very few implementations
actually support it, and those that do seem to be encoding it
differently. The Open Sound Control 1.0 Specification only defines the
argument as a 32 bit RGBA color, and does not specify in which order
the components are actually sent.
e.g. RGBA, ABGR, BGRA?

[Chris Byrne]

Thanks for the quick replies.


Looking at the Ventuz OSC.Net library; it sends the color data as: ARGB
So full opaque red is FF FF 00 00 and blue would be FF 00 00 FF.


However, there's an Erlang implementation which also supports the
color tag but it looks to use RGBA
http://opensoundcontrol.org/implementation/erlang-osc-application
http://github.com/mujaheed/erlang-osc/blob/master/src/osc_lib.erl

decode_args(<<R, G, B, A, Rest/binary>>, [$r|T], Acc) ->
decode_args(Rest, T, [{R,G,B,A}|Acc]);

Which is what I would have assumed based on the spec, and why I'm
asking for clarification.


There's several other implementations that also say they support the color tag:
http://opensoundcontrol.org/implementation/aestesis-elektronika
http://opensoundcontrol.org/implementation/tjshow-show-controller-software

but working out how to configure them to spit out OSC packets is
extremely difficult.

-

We don't have a problem using the OSC.Net ARGB convention. If others
are fine with this, in the interests of interoperability, can we
please update the OSC spec to make this order clearer?

r | 32 bit RGBA color with eight bits per component. Bytes ordered:
alpha, red, green, blue


Thanks again,
Chris

Post by Kurt Sterckx
Chris,
I suggest that you use the same format as the Ventuz OSC.Net library (the
http://opensoundcontrol.org/implementation/ventuz-realtime-3d-rendering-net
I think it is the same format as suggested by Alexandre Quessy.
Regards,
Kurt

[Alexandre Quessy]

Hello!
I implemented the Color type in txosc. See
http://bitbucket.org/arjan/txosc/changeset/3905e58dc375

Post by Chris Byrne
Looking at the Ventuz OSC.Net library; it sends the color data as: ARGB
So full opaque red is FF FF 00 00 and blue would be FF 00 00 FF.
However, there's an Erlang implementation which also supports the
color tag but it looks to use RGBA

I think that the RGBA form is more common and should be chosen in
favour of ARGB.

Post by Chris Byrne
We don't have a problem using the OSC.Net ARGB convention. If others
are fine with this, in the interests of interoperability, can we
please update the OSC spec to make this order clearer?
alpha, red, green, blue

With all respect, I am not quite fine with this and would like it to
be clarified as RGBA:

r | 32 bit RGBA color with eight bits per component. Bytes ordered:
red, green, blue, alpha

That's the order of the color channels in OpenGL, after all. Also,
some libraries might give a default value of 0xFF to the alpha
channel. One would then only need to specify the RGB channels, and the
alpha would be 100% by default. (I might do that in my Python
implementation)

Regards,

[Chris Byrne]

Post by Alexandre Quessy
I think that the RGBA form is more common and should be chosen in
favour of ARGB.

Actually the most common format is BGRA. This is what Windows uses and
most vendors have adopted this standard.

Post by Alexandre Quessy
That's the order of the color channels in OpenGL, after all.

OpenGL supports a variety of internal and external pixel formats (man
glTexImage2D). Internally most vendors (such as nVidia) store pixel
data as BGRA to optimize for the Windows BGRA byte ordering.

"For 8-bit textures, NVIDIA graphics cards are built to match the
Microsoft GDI pixel layout, so make sure the pixel format in system
memory is BGRA"
http://download.nvidia.com/developer/Papers/2005/Fast_Texture_Transfers/Fast_Texture_Transfers.pdf

---

Anyway, byte order is not nearly as important as consistency. Without
which there can't be interoperability.

Post by Alexandre Quessy
With all respect, I am not quite fine with this and would like it to

I agree.

[Matt Wright]

Sorry to be late on this discussion. The intent was always for RGBA color to be in the order RGBA, hence the name. It never occurred to me that this could be considered ambiguous --- sorry not to have been more explicit in the first place.

-Matt

Post by Alexandre Quessy
Hello!
I implemented the Color type in txosc. See
http://bitbucket.org/arjan/txosc/changeset/3905e58dc375

Post by Chris Byrne
Looking at the Ventuz OSC.Net library; it sends the color data as: ARGB
So full opaque red is FF FF 00 00 and blue would be FF 00 00 FF.
However, there's an Erlang implementation which also supports the
color tag but it looks to use RGBA

I think that the RGBA form is more common and should be chosen in
favour of ARGB.

Post by Chris Byrne
We don't have a problem using the OSC.Net ARGB convention. If others
are fine with this, in the interests of interoperability, can we
please update the OSC spec to make this order clearer?
alpha, red, green, blue

With all respect, I am not quite fine with this and would like it to
red, green, blue, alpha
That's the order of the color channels in OpenGL, after all. Also,
some libraries might give a default value of 0xFF to the alpha
channel. One would then only need to specify the RGB channels, and the
alpha would be 100% by default. (I might do that in my Python
implementation)
Regards,
--
Alexandre Quessy
http://alexandre.quessy.net/
_______________________________________________
OSC_dev mailing list
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Adrian Freed]

Post by Matt Wright
Sorry to be late on this discussion. The intent was always for RGBA color to be in the order RGBA, hence the name. It never occurred to me that this could be considered ambiguous --- sorry not to have been more explicit in the first place.

I concur. We should have said exactly where the bits are because of the lovely confusions of endianness etc. I favor the RGBA designation and conceptual ordering because it reflects the history and is a nod to the work (and original order) of the pioneers that developed the alpha channel: Ed Catmull and Alvy Ray Smith. Of course there are lots of hardware and software implementations that favor other orderings (and bit depths) but that is a larger problem.

[Chris Byrne]

Post by Adrian Freed

Sorry to be late on this discussion.  The intent was always for RGBA color
to be in the order RGBA, hence the name.  It never occurred to me that this
could be considered ambiguous --- sorry not to have been more explicit in
the first place.

I concur. We should have said exactly where the bits are because of the
lovely confusions of endianness etc. I favor the RGBA designation and
conceptual ordering because it reflects the history and is a nod to the work
(and original order) of the pioneers that developed the alpha channel: Ed
Catmull and Alvy Ray Smith. Of course there are lots of hardware and
software implementations that favor other orderings (and bit depths) but
that is a larger problem.

Thanks for the clarification.

Greatly appreciated,
CB