Glenn,
I do agree that your interpretation feels more natural to me, but I
definitely don't see it as the only possible interpretation. If you hand
me four bytes of RGBA color packed into a 32 bit value, I expect the
first byte to be the red channel. The question then arises, how does one
number the bytes? This is indisputably a question of endianness.
As an example, the Microsoft Windows header file WinGDI.h defines a
macro to generate an integer value from RGB component byte values. This
macro is defined like this:
#define RGB(r,g,b)
((COLORREF)(((BYTE)(r)|((WORD)((BYTE)(g))<<8))|(((DWORD)(BYTE)(b))<<16)))
The red component is in the least significant byte, just like the
behavior of asRGBA. I certainly wouldn't suggest doing things this way
just because Microsoft does, but I would claim that Windows' GDI API is
prominent enough to dash any claim that the opposite way of packing
colors into an integer is the only expected one.
I do prefer the packing that you promote, I just don't think that's
enough reason to break compatibility since there are other reasonable
interpretations.
Mark
On 9/16/2010 1:34 PM, Glenn Waldron wrote:
Mark,
I have to disagree with your initial statement. RGBA is a well-worn
specification for byte-encoded color. It implies a specific byte
order. Endianness is not relevant since it is not meant to be
interpreted as an integer. If you hand me 32 bits of data and tell me
it's RGBA-encoded, I expect to be able to do (data & 0xFF) and get the
alpha component no matter what platform I'm on.
Glenn Waldron : Pelican Mapping : +1.703.652.4791
On Thu, Sep 16, 2010 at 3:55 PM, Mark Sciabica <[email protected]
<mailto:[email protected]>> wrote:
Hi Glenn,
I think what these functions *should* return can not be determined by
the names of the functions. They return 32 bit integers and
whether the
low byte or the high byte corresponds to the first color channel named
is not immediately obvious. Like you, my first guess would be that the
high byte has the first named color channel so that asRGBA() would
return 0xff for opaque black. As you have discovered, this is not what
happens.
However, on little-endian architectures (like the dominant x86)
writing
this 32 bit value to memory results in the bytes being ordered as
in the
function name. This is very useful, although not entirely portable.
I would not recommend changing these functions' behaviors since
that can
easily break any existing code that uses them. New functions with more
descriptive names could certainly be helpful. Documenting these
functions is also a good idea so other users don't waste too much time
wondering why their code does not behave as expected.
Mark
On 9/16/2010 11:53 AM, Glenn Waldron wrote:
Hi folks,
Tthe methods Vec4f::asABGR() and asRGBA() appear to be
reversed. (That
is, asABGR() returns RGBA and vice-versa.) Can someone lay another
pair of eyes on them and confirm this?
Glenn Waldron : Pelican Mapping : +1.703.652.4791
This message and any attachments are solely for the intended
recipient and may contain confidential or privileged information.
If you are not the intended recipient, any disclosure, copying,
use, or distribution of the information included in this message
and any attachments is prohibited. If you have received this
communication in error, please notify us by reply e-mail and
immediately and permanently delete this message and any
attachments. Thank you.
_______________________________________________
osg-users mailing list
[email protected]
<mailto:[email protected]>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
