Texture pixel formats

I am revising my texture loading code 'cos I have to support new formats, more hardware and develop our propietary image format for a broader range of apps.
Several questions have arisen:

1 Are OpenGL's internal formats always RGB ordered?
2 Is specifying source BGR formats faster than doing a swizzle beforehand?
3 Are there OGL implementations out there that won't take BGR source formats?
4 Any point in supporting ARBTC or should we just stick to S3TC?
5 What channel ordering does D3D use internally?
6 Any way/chance of seeing 565 formats supported?

It seems that practically all image formats store channels in BGR order, but OpenGL only defines BGR and BGRA, all more specific formats are RGB (ie RGB5).

Essentially, my main concerns are supporting a wide range of pixel formats, having the fastest possible texture downloads for all and matching internal and external formats as closely as possible. If you have any illuminating insights on things I may have overlooked, feel free to comment .

Cheers,
Madoc

  1. Depends on the hardware, but on Windows I think most are BGR, BGRA

  2. Depends on the hardware

  3. Nope. Since 1.2, this is part of the core.
    Check you extension string/gl version

  4. your choice

  5. the hardware just has a circuit for both APIs

  6. hmmm, dont know. I thought it was

6: If you mean support for RGB 565 source formats, then it’s a part of the core since 1.2, just like BGR-formats. Check the EXT_packed_pixels extension for more information (or the spec of course).

Originally posted by V-man:
[b]1. Depends on the hardware, but on Windows I think most are BGR, BGRA
Isn’t that a bit of a contradiction?

  1. Depends on the hardware
  1. Nope. Since 1.2, this is part of the core.
    Check you extension string/gl version
  1. your choice
  1. the hardware just has a circuit for both APIs
  1. hmmm, dont know. I thought it was[/b]
  1. Isn’t that a bit of a contradition?

  2. Of course, I mean typically or on more popular hardware.

  3. Not every OpenGL implementation is 1.2. The one 1.1 I have access to supports BGR. (Yes, I have to be that backwards compatible).

  4. I havent’ actually had a proper look at the spec yet. I thought someone might have some pros and cons that aren’t obvious. I suppose there isn’t much difference then. But if ARB simply replaces S3, won’t S3 begin to dissapear?

  5. Okay, but it could also do both. What about source formats?

I’m basically trying to figure out whether there’s ever any advantage to either one or the other. Should I just leave the hardware out of that consideration?

Originally posted by Bob:
6: If you mean support for RGB 565 source formats, then it’s a part of the core since 1.2, just like BGR-formats. Check the EXT_packed_pixels extension for more information (or the spec of course).

It’s not in my copy of the 1.4 spec…

glTexImage2D(GL_TEXTURE_2D,level,GL_RGB5,
    level_width,level_height,0,
    GL_RGB,[b]GL_UNSIGNED_SHORT_5_6_5[/b],data);

It’s not in my copy of the 1.4 spec…

Don’t know what strange copy you have, but this is how I find the packed pixel formats in the 1.4 spec.

[ol]

[li]Using the navigation pane in Acrobat, I navigate myself to Rasterization->Texturing->Texture Image Specification, which takes me to section 3.8.1 on page 119. Under glTexImage3D, I read this: format, type, and data match the corresponding arguments to DrawPixels (refer to section 3.6.4), so I go to section 3.6.4 on page 95.[/li]
[li]On page 97, table 3.5 has a list of valid types. The values that begins with UNSIGNED has a Yes in the column ‘Special Interpretation’, and below the table is says Special interpretations are described near the end of section 3.6.4.[/li]
[li]In the end of page 99, you find information on packed pixel formats.[/li][/ol]

[This message has been edited by Bob (edited 05-07-2003).]

Bob, sorry, I should have made it clear. I intend as an internal format, I’m not concerned about having to convert it but whether it’s ever any use to an OpenGL app.
Pity it isn’t, 16 bit is clearly better than 15.

I guess my questions sounds a bit like newbie questions, I basically just wanted to know what people’s choice would be between RGB, BGR and so forth seeing as I have to write a lot of image related code and make it kind of final.

>>>I guess my questions sounds a bit like newbie questions, I basically just wanted to know what people’s choice would be between RGB, BGR and so forth seeing as I have to write a lot of image related code and make it kind of final.<<<

I already answered this. BGR is preferable to RGB and BGRA is prefered over RGBA on windows. Quite a lot of image format are stored BGR or BGRA. So you dont need to flip bytes before uploading.

  1. Okay, but it could also do both. What about source formats?

It does both because the drivers swaps bytes for you if you dont match the internal format.
Your source should match the internal format.
Some vendors like intel sis and such dont have detailed documents.
Just advertisements. Maybe someone can post some links to their docs? Thanks in advance.

I can safely say that everyone here prefers ARB or EXT extensions over vendor specific ones.

Now you are left with questions like : should I upload 5_6_5 format or something else would be better?

I see a couple things in this discussion that make it confusing.

The format and internal format parameters seem to be getting confused. The internal format has no bearing on component order. This is why there is no BGR5. The implementation can store it however it wants. The format parameter informs GL of the order of the incoming components, and therefore requires tokens like BGRA. These tokens are NOT sized. Finally with packed pixels or GL 1.2(I think), you can specify the type parameter such that the components are extracted from a single type.

From a practical standpoint, RGB5 will alomst always give you 6 bits of green. As far as component order and upload speed, I generally suggest BGRA order as it can be slightly faster. (I haven’t seen it slower on a PC)

Finally, use ARB_tc. It is much better specified than S3TC, and it gives you access to more compressed formats. S3TC isnt likely to go away soon though. (The last time I looked Quake 3 still used it)

-Evan

Man,you shoud see the image uploading function of my engine.All possible internal formats,formats,conversations and etc.And just cause it’s not enough i support paletted textures and S3 texture compression.Bet you haven’t seen a function like that.It will even create a texture image from a dried grass

Originally posted by V-man:
[b]I already answered this. BGR is preferable to RGB and BGRA is prefered over RGBA on windows. Quite a lot of image format are stored BGR or BGRA. So you dont need to flip bytes before uploading.

  1. Okay, but it could also do both. What about source formats?

It does both because the drivers swaps bytes for you if you dont match the internal format.
Your source should match the internal format.[/b]

I stated that image formats are usually BGR in my original post.
I know that source formats should match internal ones, that’s the entire point of this post.

If there’s going to be any conversion or swizzling then my opinion is that I might as well do it myself, I’ll probably do it faster than a lot of drivers and I know it works.
I already support over 20 pixel formats and have to be able to (already do for most) convert between them all. Getting the driver to do it for me is really the last thing I’m looking for. I want to do it myself and, as much as possible, provide formats that are an exact match with intenal formats.

Originally posted by ehart:
The format and internal format parameters seem to be getting confused. The internal format has no bearing on component order. This is why there is no BGR5. The implementation can store it however it wants. The format parameter informs GL of the order of the incoming components, and therefore requires tokens like BGRA. These tokens are NOT sized. Finally with packed pixels or GL 1.2(I think), you can specify the type parameter such that the components are extracted from a single type.)

I know all this very well indeed, my questions wouldn’t even make sense if I didn’t. I would personally answer “RTFM” to anyone asking for this even in the begginer forums.

Originally posted by ehart:
From a practical standpoint, RGB5 will alomst always give you 6 bits of green. As far as component order and upload speed, I generally suggest BGRA order as it can be slightly faster. (I haven’t seen it slower on a PC)

This is exactly what I would like to hear. If I knew that RGB5 would result in 565 then it would be worth storing images in 565 format. I also wanted to know whether BGR ordering might give faster uploads than RGB.

I don’t mean to sound anal, I appreaciate that you’re all just trying to help and that’s cool but you also seem to be assuming that I don’t know what I’m talking about.
I guess it’s habit from answering all the posts that appear on this “advanced” forum.

Cheers,
Madoc

>2 Is specifying source BGR formats faster than doing a swizzle beforehand?

A few months ago I asked my users to benchmark their raw texture uploading speed with various texture formats. I’ve got results from around 200 systems, and most times the differences between 32 bit RGBA (components:GL_RGBA8,type:GL_UNSIGNED_BYTE,format:GL_RGBA) and 32 bit BGRA (GL_RGBA8,GL_UNSIGNED_BYTE,GL_BGRA_EXT) were not very big.

Generally I could tell that Ati R7xxx were fastest with BGRA, while all other Ati Radeon cards were fastest with RGBA. nVidia cards (TNT1/2, GF1-GF4, no GFFX at this time, sorry) were fastest with BGRA. Most other vendors (Matrox, 3dfx, Sis) were better again with RGBA, just the Kyro2 cards were BGRA
flavoured. Ah, and no card was fastest with ABGR (GL_RGBA8,GL_UNSIGNED_BYTE,GL_ABGR_EXT), this format was often as fast as BGRA/RGBA, but never the fastest.

Of course the best texture upload speed you can get with packed 16 bit textures, if you don’t mind the reduced colors/alpha vals
(“GL_RGB5_A1,GL_UNSIGNED_SHORT_5_5_5_1_EXT,GL_RGBA” was always the fastest format, but beware of “GL_RGBA4, GL_UNSIGNED_SHORT_4_4_4_4_EXT,GL_RGBA”… this format is very slow on ATI cards… no speed problems with nVidia, though).

I appologize if you felt I was not genuine in my concern.

You asked if all internal formats were RGB in nature, and then said something about it offering only BGR and BGRA for order differences and only more specific ones (RGB5) in rgb order.

Since BGR and RGB5 can’t be used in the same parameter I assumed you were confusing the different parameters.

-Evan

Evan, I’m not offended. I see what you mean, I did make a little confusion there, apologies. I just have a couple of old functions to convert my own pixel formats to OGL ones, one for 1.2 and one for 1.1. The values in there are straight off the spec tables, they certainly don’t give BGR internal formats.

Basically, all I wanted to know is which ordering I’m better off with and whether there’s any point in supporting 565. These are issues with specification of our file format.
I was thinking that RGB naming might be from OGL history while on today’s platforms the internal form is more likely to be BGR.

Now, I’ve had a brief look at the ARB_TC spec. I’m quite disconcerted by how no specific compressed formats are defined. With S3TC we can just distribute DDS and if the compression isn’t supported we decompress. With ARB_TC there doesn’t appear to be any way of knowing whether the formats will be supported nor how they were compressed making it impossible for the client to decompress them. What?!!?
This is what I understood the first time I looked at the spec but I was incredulous. How do people effectively make use this compression system?

Thanks PeteBernert, this is exactly the kind of information I was looking for.
Good, another reason to not support RGBA4, 12 bit colour is almost always so ugly that I decided to give it a miss long ago.
We mostly use BGR5 or DXTC, from Targa and DDS respectively, but lately we’ve had need for a lot of 24 and 32 bit maps.