Texture Colors Not exact as Texture

The red and blue channels are probably swapped, ie. your image data comes in BGR component order.

Try GL_BGR as the format parameter to the glTexImage2D call (instead of GL_RGB).

[attachment=5226:Fixed Texture Color Scheme GL_BGR.jpg]

The red and blue channels are probably swapped, ie. your image data comes in BGR component order.

Try GL_BGR as the format parameter to the glTexImage2D call (instead of GL_RGB).

Thanks that was exactly what it was. Do you mind me asking how that happens? Is it just that specific image?

BMP files are stored in BGR color order. If you read the image data directly from the file, that is the format you get.

BMP files are stored in BGR color order. If you read the image data directly from the file, that is the format you get.

Yeah thats the crazy thing. I used SDL to read in the texture, so I think that its kind of strange that the color format was reversed. Well now I am on to reading in .obj files to display my textures on models using blender and opengl. Thanks guys. Any tips?

I don't use SDL but I imagine it is because SDL reads the data and doesn't convert the BGR to RGB automatically for you. You are probably suppose to make some function call into the SDL for it to convert for you.

Or, use SDL to know what the storage format is. If it says BGR then you send the data to OpenGL as BGR.
So, you need to know a little of SDL.

The following code is from freeImage.cpp, it shows how to load an image and swap the RGB channels, I made a copy of the relevant code snippet and posted it first and added some comments to the swapping code. for(int pix=0; pix

This line needs attention drawn to it: // BGR format. Now we could just use the GL_BGR extension
Substitute "could" with "should". Maybe in 1997 or 1998 there was a valid reason to swap in software, but every 3D card since then supports BGR - if you have OpenGL 1.2 or higher you have BGR, simple as that.

You shouldn't even be using gluBuild2DMipmaps anymore or "3" as an internal format
gluBuild2DMipmaps(GL_TEXTURE_2D, 3,

Not even mentioning that the code above invokes undefined behaviour and could possibly lead to memory leaks or even severe heap corruption.

BYTE *bits = new BYTE[FreeImage_GetWidth(dib) * FreeImage_GetHeight(dib) * 3];

[..stuff..]

delete bits;

I took this part out..It really wasn't constructive at all.

mhagain -- I don't appreciate you pointing out the flaws in my code. Please refrain from posting suggestions relating to other people's posts.

V-man -- Can you please explain the modern alternative for producing mipmaps?

Yann L -- Can you please explain what part of that code evokes undefined behaviour, and why it's at risk of leaking memory?

^^ Fixed that for you.

If someone asks me how to build a house and I suggest to him or her to go cut down trees, gather wood, and use a hammer and nails, yes, I have answered his question.
When someone else comes along and says, "You know, that way is deprecated; we use bricks and mortar now," he or she has given an answer that may be more suitable to the original person seeking advice.

In the pursuit of knowledge one must never be stuck in his or her own ways, and admit one's shortcomings with a smile as new things or ways are learned.

I would not be offended if someone suggested a better way than my own. Why were you?

One of the reasons I post here so often is because I can also learn when I give less-than-the-best advice and someone comes along and corrects it. I think I am pretty useful and help often, but I also say stupid things at times and make poor suggestions.

Your reaction to having been corrected is off-the-wall.

Also, Yann L showed you exactly where the error is.
You [or whomever] used new [] but not delete []. You [or whomever] used plain delete.
Instead of looking with an open mind and saying, "Oh I see, I made a mistake. Thank you for finding that because the quality of my software has increased because of it," you just screamed how correct the code is based on it working "on every computer", which is something you didn't even test, and stomped off with flawed code.


L. Spiro

Actually L. Spiro. YOU told us exactly where this particular error is. The other person re-wrote the same mistake and said it was wrong without the correction that you presented. Maybe to you it was obvious that [] should have been added, but not to everyone. I do not get upset because I was corrected, I wasn't corrected, I was instead heckled for attempting to help. If I were building a house as you say and someone came by and critisized me for doing it wrong, then turned around and walked away without any clearly stated "help", I would have no respect for this person's opinion. If those people had put things nicely, and had given some useful advice I would have followed it. If that is how the "experts" around here behave then it is clear that the "experts" need to be told how to behave properly. It rubs me the wrong way when no-it-alls use what they "know" to make themselves feel superior. Simply put, I overreacted, but what I reacted to was most certainly something to react to. And by the way, I've tested that code extensively on many different computers with very different hardware and it works beautifully. I re-compile sometimes half-a-dozen times every few minutes. I have also used this code to load 240 pictures at 1024x1024 all at the same time, if there really were memory leaks and corruption it would have been very obvious, these computers would crash. Maybe the Dev-Cpp compiler fixes errors like these automatically, I will however take you advice on this matter and make the appropriate correction:delete[]. I am aware that Nvidia has posted a document called "fast texture transfers" and in this document it is pointed out that BGR should be used but in most cases even they say that it has little or no performance increase. The response I received was snarky and overblown. I escalated things and I'm sorry.

We;; for my part i wasn't trying to make little of your work; my motive was to point out to the OP that on a more modern GPU using BGR is preferable to swapping the bytes manually. I can see how it could have came across otherwise, and I could have picked my words better.

I have done quite a bit of benchmarking of texture uploads using different format and type parameters, and GL_BGRA is actually the one to use. ;)

Well if you want any openGL help, then you're kind of pissing of the wrong people. Secondly a fact is not an attack:

Not even mentioning that the code above invokes undefined behaviour and could possibly lead to memory leaks or even severe heap corruption.[/quote]

The code posted was bad. For instance why make a new array instead of just swapping the r,g,b values in the original array?

Send your pointless little snippet to the people who built freeImage and tell them that their software isn't written properly.[/quote]
Just because someone gave away free code doesn't mean it is good. It really was bad code, and was a memory leak.

The problem was already solved anyway and then you posted a ton of code and more work than the standard solution of GL_BGR. You can also google things like gluBuild2DMipMaps and find out why he is saying not to use it.

ok

From the Wiki
http://www.opengl.org/wiki/Common_Mistakes#GL_TEXTURE_MAG_FILTER

and also
http://www.opengl.org/wiki/Common_Mistakes#Automatic_mipmap_generation

Secondly a fact is not an attack:[/quote]

Ok fine I'm sorry for being grouchy. Thank you all for helping people fix their code. How's this look? //------------------------------------------------------------------------------------------------------------------------------------------------. void loadTexture(char *textureFileName, GLuint &textureMapID) { FREE_IMAGE_FORMAT fifmt = FreeImage_GetFileType(textureFileName, 0); FIBITMAP *dib = FreeImage_Load(fifmt, textureFileName,0); FIBITMAP *temp = dib; dib = FreeImage_ConvertTo32Bits(temp); FreeImage_Unload(temp); if( dib != NULL ) { glGenTextures( 1, &textureMapID ); glBindTexture( GL_TEXTURE_2D, textureMapID ); BYTE *pixels = (BYTE*)FreeImage_GetBits(dib); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_MIRRORED_REPEAT_ARB); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_MIRRORED_REPEAT_ARB); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR_MIPMAP_NEAREST); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_NEAREST); glTexParameteri( GL_TEXTURE_2D, GL_GENERATE_MIPMAP_SGIS, GL_TRUE ); glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, FreeImage_GetWidth(dib), FreeImage_GetHeight(dib), 0, GL_BGRA, GL_UNSIGNED_BYTE, pixels); free(pixels); FreeImage_Unload(dib); } } //------------------------------------------------------------------------------------------------------------------------------------------------. Maybe now we are closer to having a proper image loader for people to make use of. The SGIS mip map generator appears to be hardware accelerated, almost twice as fast on a low end quadro, and about 1/3 faster on a budget intel graphics machine. Is a performance comparison like this inappropriate? Would it be considered bias or favoritism towards one or the other? I'm happy for both running faster now. There do not appear to be memory leaks. The dual core Intel with 2GB RAM and mobile 4 series graphics running on Win7 handled the loading of 100 1024x1024 images, then 200 1024x1024 images, then 300 1024x1024 images.