Dear All,<br>

<br>

Does anybody use the DDS plugin to read and write DDS files? I am a bit
confused with regards to RGB vs. BGR; even looking at the DDS plugin
code, I'm still not sure:<br>

<br>

1) Does the DDS file format _demand_ that the byte order is BGRA? As
far as I can tell, it doesn't, because you specify the byte masks for
R,G,B,A separately.<br>

<br>

2) If given a source image with GL_RGBA, does the DDS writer swap R and
B to write BGRA? As far as I can tell,it doesn't, because the actual
"write" call in line 894 (of ReaderWriterDDS.cpp) just dumps the
image->data to file in order. <br>

<br>

3) In terms of byte mask order, the _reader_ looks right to me : line 346 has : <br>

            {
"A8B8G8R8",    32, 0x000000ff, 0x0000ff00, 0x00ff0000,
0xff000000, GL_RGBA, GL_RGBA, GL_UNSIGNED_BYTE }<br>

where the bytemasks are R,G,B,A in order.<br>

<br>

However the writer for the equivalent format, GL_RGBA, has the byte masks (R,G,B,A) as  <br>

           {0x00ff0000; 0x0000ff00; 0x000000ff; 0xff000000}<br>

which would seem to be B,G,R,A.<br>

<br>

4) If I create a blank red image and save it to disk, then examine the
image with 3rd party image viewing tools, going via the png format (for
example) gives me a red image, but going via the dds format gives me a
blue image.<br>

<br>

5) Lastly, as an aside, do any of the other OSG image plugins write 3d (i.e. r>1) images?<br>

<br>

<br>

I didn't want to just to go ahead and submit a fix, because I'm not
familiar with the DDS format. The latest submission on it was from the
10th June, so it is moderately active. Can anybody let me know whether
the described behaviour and code is intentional, i.e. not a bug? If it
is a bug, I'll submit a fix.<br>

<br>

Regards,<br>
<span class="sg">
<br>
David</span>