Oops sorry small correction: Intel is little endian. I always confuse these
names. I prefer using Least Significant Byte First and Most Significant Byte
First to describe the CPU archtecture.
Wojtek
----- Original Message -----
From: "Wojciech Lewandowski" <lewandow...@ai.com.pl>
To: "OpenSceneGraph Users" <osg-users@lists.openscenegraph.org>
Sent: Wednesday, December 30, 2009 1:57 PM
Subject: Re: [osg-users] DDS uncompressed RGB(A) / BGR(A)
Hi,
I had some experience with D3D in the past maybe could help clear a
picture a little.
Basic 32 bit color format using in Directx is named in Direct 3D:
D3DFMT_A8R8G8B8. Components are enumerated from most significant byte to
least significant byte. Such pixel value is usually set by using single
DWORD. for example DWORD color = 0xAA112233 coresponds to following bytes
alpha = 0xAA red = 0x11 green = 0x22 blue = 0x33. As I said earlier, this
is an order byte significance, not an order of bytes in memory. When you
write this dword to memory they will land in following order on Intel (big
endian CPUs) [Blue][Red][Green][Alpha]. So in OpenGL notation it would be
GL_BGRA. Hope this explains a bit. Hence basic Directx ARGB format should
be read as OpenGL BGRA. To switch to more intuitive OpenGL RGBA you
apparently have to swap R and B bytes.
However, DDS format is capable of storing all variants of 32 bit color
layouts. RGBA, BGRA, ABGR, & ARGB. As far as I remember only color
component bitmasks should be changed accordingly to select proper variant.
If your tools do not read them correctly this is most probably an issue
with those tools. I am sure OSG DDS ReaderWiriter is not saint here as
well.
Cheers,
Wojtek
----- Original Message -----
From: "Sukender" <suky0...@free.fr>
To: "OpenSceneGraph Users" <osg-users@lists.openscenegraph.org>
Sent: Wednesday, December 30, 2009 1:22 PM
Subject: Re: [osg-users] DDS uncompressed RGB(A) / BGR(A)
Hi all,
Is there an endianess problem with DDS format? I'm using a Core2Duo here
and I don't know under which kind of machine the DDS has been tested...
A little explanation: After a bit of investigation (=cleaning stupid
copy-paste), I found that the only "true" bug I had was "Changing R, G or
B writer's masks doesn't seem to affect reading in 3rd-party readers".
Has anybody encountered this before?
Writing DDS: It seems the DDS must be BGR in order to make 3rd-party
readers work correctly (by inverting R and B channels).
Reading DDS: It seems DDS generated (from a JPG) by 3rd party tools are
marked RGB but are BGR...
Please help and share your experience!
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
----- "Sukender" <suky0...@free.fr> a écrit :
Hi Robert and all,
I'm lost:
- Changing R, G or B writer's masks doesn't seem to affect reading
(either the plugin or 3rd-party readers, except when masks are
completely nonsense)
- Copying the image (DEEP_COPY) and writing the copy instead of the
oringinal result in a vertical flip of the image in the file!
- Manually inverting R & B channels in a copy of the image doesn't do
anything...
I must have a very stupid mistake somewhere but I can't fugure out
where...
Any idea?
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
----- "Robert Osfield" <robert.osfi...@gmail.com> a écrit :
> Hi Sukender,
>
> I'm not overly familiar with the dds plugin, but what you describe
> sounds like a bug in writer in our dds plugin.
>
> Robert.
>
> On Fri, Dec 18, 2009 at 5:15 PM, Sukender <suky0...@free.fr> wrote:
> > Hi all,
> >
> > It was discussed a long time ago but I dit not find an answer.
> Saving to DDS an uncompressed RGB image and then loading from the
file
> works: the loaded image is the same as the original. However, the
file
> is BGR (R and B inverted). I tried three 3rd-party tools (image
> viewer/converters) and all display the same.
> > Do you think this is a bug in DDS readerwriter? Anyone has a clue
> about it?
> > Thanks a lot.
> >
> > Sukender
> > PVLE - Lightweight cross-platform game engine -
> http://pvle.sourceforge.net/
> > _______________________________________________
> > osg-users mailing list
> > osg-users@lists.openscenegraph.org
> >
>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> >
> _______________________________________________
> osg-users mailing list
> osg-users@lists.openscenegraph.org
>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
