Textureformat ARGB is BGRA?

[John Withe]

I have a texture which has format ARGB. I write into it using a graphics
stream and a byte array (managed directx).
It turns out that when I write 255,255,0,0, 255,255,0,0 and so on, I do not
get solid red as I expect.
I get a bluegreen color with alpha zero.
I need to write the bytes blue, green, red, alpha.

Why is that? Is there a way arround the problem? I have my data located
somewhere else in ARGB ordering and I would like to be able to just copy the
data from there into the texture, but as it is now, I have to flip the bytes
arround which makes the whole procedure quite slow.

Note that there exist no pixelformat og BGRA which I could try to see if it
would then also beinvertex into ARGB.
I could store the data in oposite ordering and then flip it in a shader, but
it seems like more of a hack than a proper solution.

[Tim Roberts]

"John Withe" <a...@b.de> wrote:
>
>I have a texture which has format ARGB.

How did you define this? What format value did you set? Microsoft itself
is inconsistent in the way it uses its terms. Their A8R8G8B8 format, for
instance, seems to describe the format in a register, meaning BGRA in
memory.

>I write into it using a graphics
>stream and a byte array (managed directx).
>It turns out that when I write 255,255,0,0, 255,255,0,0 and so on, I do not
>get solid red as I expect.
>I get a bluegreen color with alpha zero.
>I need to write the bytes blue, green, red, alpha.
>
>Why is that?

Probably because most graphics cards expect their textures in BGRA format.
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.

[Richard [Microsoft Direct3D MVP]]

[Please do not mail me a copy of your followup]

The format enumeration of the surface implies the bit packing of the
channels within the data. See chapter 2 of my book on Direct3D, pg. 54.
<http://www.xmission.com/~legalize/book/download/02-Direct3D.pdf>
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>

Legalize Adulthood! <http://blogs.xmission.com/legalize/>

[John Withe]

I use the texture to render a moie into. I read framesand write them to the
texture which is used in the scene.

> How did you define this?

texture = new Texture(device, width,height, Usage.None, Format.A8R8G8B8,
Pool.Managed);

I write into it by readingbyte arays containing my data
GraphicsStream graphicsStream = texture.LockRectangle(0, LockFlags.None);
graphicsStream.Write(videoData[currentFrame],0,width*height*4);

texture.UnlockRectangle(0);

In the above example, I can simply reverse the bytes. The problem is when I
am reading it directly from diskto save memory. I do not have time to flip
them there. I am considering reading in my frames, reversing the bytes and
writing them to diskin a raw format. That will work just fine. Probably even
give me slightly better performance, but I would like to have confirmation
that I actually need to do that so I know that it was not just a dumb
uninformed hack that I did.

> Probably because most graphics cards expect their textures in BGRA format.

Seems odd to then define it as ARGB. The run length encoded quicktime which
I am reading stored A first and B last, as its format states. Too bad that
they do not at least agree on being backwards ;-)

Nb. Am I feeding the pixels to the texture the fastest way possible, or
could I optimize on that part as well? I wonder if I could use compressed
textures for this withoutloosing too much quality? I have howeer not been
able to find much specific information on compressed textures and how they
work. I am using managed directx. Any hints in that regard would be very
apressiated.

[John Withe]

> The format enumeration of the surface implies the bit packing of the
> channels within the data. See chapter 2 of my book on Direct3D, pg. 54.
> <http://www.xmission.com/~legalize/book/download/02-Direct3D.pdf>

Ok. So first bit is most significant and with the system being little endian
its reversed. Hm.
Seems I just need to preprocess the data and flip the order.... or read 32
bit words and write them one by one, which will be very slow.

[Richard [Microsoft Direct3D MVP]]

[Please do not mail me a copy of your followup]

"John Withe" <a...@b.de> spake the secret code
<47c150f9$0$89176$157c...@dreader1.cybercity.dk> thusly:

>> The format enumeration of the surface implies the bit packing of the
>> channels within the data. See chapter 2 of my book on Direct3D, pg. 54.
>> <http://www.xmission.com/~legalize/book/download/02-Direct3D.pdf>
>
>Ok. So first bit is most significant and with the system being little endian
>its reversed. Hm.

I don't know what you mean by "reversed". The most significant bits
are in the most significant place in a 32-bit quantity.

[John Withe]

> I don't know what you mean by "reversed". The most significant bits
> are in the most significant place in a 32-bit quantity.

I mean that in the written format ARGB, A is the first and B is the last,
when reading left to right as you normally do.
In memory A is the last and B is the first if read the memory from low to
high address.
I also mean that when I have a movie frame which has A on a lower address
than B, I need to reverse the bytes in order for it to be directly copyable
to the texture. Is is really not that complicated what I mean ;-)

I see in your book that you describe compressed texture formats in some
detail. I read it but was unable to conclude if it would be usable for me.
It seems that the different formats generally all compress by defining start
and end values for a small range and then interpolate in between. This would
degrade image quality, though it might be invisible to the naked eye. Is
this correctly understood?
I was wondering why there are no RLE format. Many textures would benefit
from that, I would mean. It should be fast enough to "unpack" and it would
not degrade quality at all.
If you have textures with ARGB pixel format and you want each pixel to have
its own specific 32 bit color values, with no interpolation, would
compressed textures be an option then? If you could accept that the alpha is
interpolated, would it then only save 2 bytes for every four pixels? With
every pixel in the 4 pixel segment having its own RGB but with alpha
interpolated from start to end?

[Jan Bruns]

"John Withe":

>> I don't know what you mean by "reversed". The most significant bits
>> are in the most significant place in a 32-bit quantity.

> I mean that in the written format ARGB, A is the first and B is the last,
> when reading left to right as you normally do.
> In memory A is the last and B is the first if read the memory from low to
> high address.
> I also mean that when I have a movie frame which has A on a lower address
> than B, I need to reverse the bytes in order for it to be directly copyable
> to the texture. Is is really not that complicated what I mean ;-)

Ok, but as long as you 1.) always put texture pixels in the same "order"
and 2.) use swizzling (fully free) in a pixel shader, ou can still use
the memcopy, even if all your source images use another packing.

> I see in your book that you describe compressed texture formats in some
> detail. I read it but was unable to conclude if it would be usable for me.
> It seems that the different formats generally all compress by defining start
> and end values for a small range and then interpolate in between. This would
> degrade image quality, though it might be invisible to the naked eye. Is
> this correctly understood?

yes. The all store 2 colors ("start" and "end", if you want), interpolate
some (one or two) more colors from these, to finally use 2 bits per pixel
to choose from the just generated colors. This all happens on a 4x4 quad,
so that we have a sum of 4 bits per pixel (2*16 + 4*4*2) / (4*4).

It's only 2 explicit "real" colors for 16 Pixels, and one or two more
colors beeing "guessed". Each of the 16 Pixels can then choose one of these
4 colors.

> I was wondering why there are no RLE format. Many textures would benefit
> from that, I would mean. It should be fast enough to "unpack" and it would
> not degrade quality at all.

Because RLE is completly inappropriate for use with textures, because nearly
the whole image data needs to be processed even if you need to read just
a single pixel. Texture-formats need to be suitable for random read access.

> If you have textures with ARGB pixel format and you want each pixel to have
> its own specific 32 bit color values, with no interpolation, would
> compressed textures be an option then?

It's lesser a question of what images you have, but merely a question of
what image quality you need at all. To keep it simple, DXT-compression
tends to smoothen up hard edges, but typically keeps image quality much
higher compared to an image sampled down to equal memory consumption.

> If you could accept that the alpha is
> interpolated, would it then only save 2 bytes for every four pixels?

There isn't such a texture format in d3d.

Gruss

Jan Bruns

[John Withe]

> Ok, but as long as you 1.) always put texture pixels in the same "order"
> and 2.) use swizzling (fully free) in a pixel shader, ou can still use
> the memcopy, even if all your source images use another packing.

Yes, I realize that. That is why I previously noted that I could do it in a
shader but just wanted confirmation that there was no simple fix like
setting an argument somewhere.

> yes. The all store 2 colors ("start" and "end", if you want), interpolate
> some (one or two) more colors from these, to finally use 2 bits per pixel
> to choose from the just generated colors. This all happens on a 4x4 quad,
> so that we have a sum of 4 bits per pixel (2*16 + 4*4*2) / (4*4).
>
> It's only 2 explicit "real" colors for 16 Pixels, and one or two more
> colors beeing "guessed". Each of the 16 Pixels can then choose one of
> these
> 4 colors.

Thanks. That made it more clear. I will probably make it an option. The user
is then free to select between the pros and cons of compression.

[Tim Roberts]

legaliz...@mail.xmission.com (Richard [Microsoft Direct3D MVP]) wrote:

>[Please do not mail me a copy of your followup]
>
>"John Withe" <a...@b.de> spake the secret code
><47c150f9$0$89176$157c...@dreader1.cybercity.dk> thusly:
>
>>> The format enumeration of the surface implies the bit packing of the
>>> channels within the data. See chapter 2 of my book on Direct3D, pg. 54.
>>> <http://www.xmission.com/~legalize/book/download/02-Direct3D.pdf>
>>
>>Ok. So first bit is most significant and with the system being little endian
>>its reversed. Hm.
>
>I don't know what you mean by "reversed". The most significant bits
>are in the most significant place in a 32-bit quantity.

His confusion is quite natural. When the rest of the world says "ARGB"
(OpenGL, for instance), they are referring to the order of bytes in memory.
That seems to be exactly the opposite of what Microsoft means by A8R8G8B8.