Jump to content

  • Log In with Google      Sign In   
  • Create Account


Loading 4-bits textures without converting?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
11 replies to this topic

#1 Vortez   Crossbones+   -  Reputation: 2697

Like
0Likes
Like

Posted 04 January 2014 - 10:45 AM

Hi, i've been working on a project for a while now and have successfully loaded 32,16, and 8 bits textures into opengl without any conversion.

Now im planning to add 1 and 4 bits textures as well, but im not sure if the last one is doable.

 

For the 1-bit texture, im just gonna try that when i have the time, but i can't seem to find any relevant information for 4-bits textures.

 

Any idea?

 

I also dont really understand how glPixelMapfv works exactly, but i understand it can be used for color remapping or something like that.

Do i really need it for 1-bit textures?

 

FYI, that's how my code load textures, for now:

        int GLType = 0;
        int GLFormat = 0;
        int NumElements = 0;

        switch(Format)
        {
        case scrf_32:
                NumElements = 4;
                GLFormat = GL_BGRA;
                GLType = GL_UNSIGNED_BYTE;
                break;
        case scrf_16:
                NumElements = 4;
                GLFormat = GL_BGRA;
                GLType = GL_UNSIGNED_SHORT_1_5_5_5_REV;
                break;
        case scrf_8c:
                NumElements = 3;
                GLFormat = GL_RGB;
                GLType = GL_UNSIGNED_BYTE_2_3_3_REV;
                break;
        case scrf_8g:
                NumElements = 1;
                GLFormat = GL_LUMINANCE;
                GLType = GL_UNSIGNED_BYTE;
                break;
        }

...

glTexImage2D(GL_TEXTURE_2D, 0, NumElements, w, h, 0, GLFormat, GLType, pTex);

Edited by Vortez, 04 January 2014 - 10:51 AM.


Sponsor:

#2 richardurich   Members   -  Reputation: 1187

Like
1Likes
Like

Posted 04 January 2014 - 11:55 AM

You linked to a post with multiple solutions to the 1-bit issue, and didn't specify which option you're planning to use. It looks like all of the solutions work fine for 4-bit in the same way they work for 1-bit.

 

I'll guess you're using the example with glPixelMapfv since you're asking about glPixelMapfv. You do need glPixelMapfv because that 2 in the call is saying your color information is 1-bit wide. To do the same with 4-bit, you'd set up a color map using size 16 (2^4) instead of 2 (2^1). You'd have to use the right 16 colors in index, and probably need an index for R, G, B, and A. For example, if you have 1 bit for each component, you'd repeat 0.0, 1.0 8 times at one end {0.0, 1.0, 0.0, 1.0, 0.0, 1.0...} and 0.0 repeated 8 times, 1.0 repeated 8 times at the other end.



#3 Chris_F   Members   -  Reputation: 2226

Like
4Likes
Like

Posted 04 January 2014 - 12:43 PM

Do you really have a need for 1-bit and 4-bit textures (as well as 16-bit textures) in your game engine, or are you simply trying to be complete with your texture support? I doubt any hardware (desktop anyway) has native support for those formats. I wouldn't be surprised in the slightest if the driver converted them to a higher bit depth, in which case you aren't saving yourself anything. You are probably much better off using compressed texture formats like S3TC (and hopefully in the future ASTC) since those will give you higher quality while at the same time saving space and bandwidth.



#4 Vortez   Crossbones+   -  Reputation: 2697

Like
1Likes
Like

Posted 04 January 2014 - 04:33 PM


You linked to a post with multiple solutions to the 1-bit issue, and didn't specify which option you're planning to use. It looks like all of the solutions work fine for 4-bit in the same way they work for 1-bit.

I'll guess you're using the example with glPixelMapfv since you're asking about glPixelMapfv. You do need glPixelMapfv because that 2 in the call is saying your color information is 1-bit wide. To do the same with 4-bit, you'd set up a color map using size 16 (2^4) instead of 2 (2^1). You'd have to use the right 16 colors in index, and probably need an index for R, G, B, and A. For example, if you have 1 bit for each component, you'd repeat 0.0, 1.0 8 times at one end {0.0, 1.0, 0.0, 1.0, 0.0, 1.0...} and 0.0 repeated 8 times, 1.0 repeated 8 times at the other end.

 

Thanks a lot, im gonna try it out when my code is ready. What i dont get is, why do you have to repeat 0.0 and 1.0 eight time exactly?

 

 

 


Do you really have a need for 1-bit and 4-bit textures (as well as 16-bit textures) in your game engine, or are you simply trying to be complete with your texture support? I doubt any hardware (desktop anyway) has native support for those formats. I wouldn't be surprised in the slightest if the driver converted them to a higher bit depth, in which case you aren't saving yourself anything. You are probably much better off using compressed texture formats like S3TC (and hopefully in the future ASTC) since those will give you higher quality while at the same time saving space and bandwidth.

 

Well, if i was writting a game, i would agree with you and use pretty much 24 or 32 bits textures only, but this code is for a remote desktop application, not a game. Since i already made the other formats (32, 16 and 8), i said what the hell, let's try those last 2. Always loved a good challenge too.


Edited by Vortez, 04 January 2014 - 04:34 PM.


#5 richardurich   Members   -  Reputation: 1187

Like
1Likes
Like

Posted 04 January 2014 - 05:41 PM

Thanks a lot, im gonna try it out when my code is ready. What i dont get is, why do you have to repeat 0.0 and 1.0 eight time exactly?

 

You're dealing with 16 combinations for a 4-bit value, and the pixel maps are just a look-up table. You obviously want entries for each valid look-up value in a look-up table. In R1G1B1A1 format, you'd set up the values to say 1.0 if the bit is set and 0.0 if the bit is not set. For example, the four bits 1010 (value=10) in R1G1B1A1 is R=1, G=0, B=1, A=0. So you'd want dataRed[10]=1.0, dataGreen[10]=0.0, dataBlue[10]=1.0, and dataAlpha[10]=0.0. dataRed would be {0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0} since its bit is 0 for 0-7 and 1 for 8-15 (bold, underline is element 10). If the format is not R1G1B1A1, you're likely dealing with an actual look-up table in the source image and need your glPixelMapfv values to correspond to the pixel map in the image.



#6 Vortez   Crossbones+   -  Reputation: 2697

Like
1Likes
Like

Posted 06 January 2014 - 06:44 PM

Humm, after passing 2 days rewritting part of my code to make this work, i got the 1 bit texture working, but i can't seem to get the 4 bit work. After re-reading your post above, i think you misunderstood me. im not using R1G1B1A1 format, but rather i use 4 bits of grayscale data. I tryed loading the texture this way but it didn't work

	case scrf_32: 
		NumElements = 4;
		GLFormat = GL_BGRA;
		GLType   = GL_UNSIGNED_BYTE;
		break;
	case scrf_16: 
		NumElements = 4;
		GLFormat = GL_BGRA;
		GLType   = GL_UNSIGNED_SHORT_1_5_5_5_REV;
		break;
	case scrf_8c: 
		NumElements = 3;
		GLFormat = GL_RGB;
		GLType   = GL_UNSIGNED_BYTE_2_3_3_REV;
		break;
	case scrf_8g: 
		NumElements = 1;
		GLFormat = GL_LUMINANCE;
		GLType   = GL_UNSIGNED_BYTE;
		break;
	case scrf_4:   // this dont work
		NumElements = 1;
		GLFormat = GL_LUMINANCE4;
		GLType   = GL_UNSIGNED_BYTE;
		break;
	case scrf_1:   //  <--- this work
		float index[] = {0.0, 1.0};

		glPixelMapfv(GL_PIXEL_MAP_I_TO_R, 2, index);
		glPixelMapfv(GL_PIXEL_MAP_I_TO_G, 2, index);
		glPixelMapfv(GL_PIXEL_MAP_I_TO_B, 2, index);
		glPixelMapfv(GL_PIXEL_MAP_I_TO_A, 2, index);

		NumElements = 1;
		GLFormat = GL_COLOR_INDEX;
		GLType   = GL_BITMAP;
		break;
	}

...

glTexImage2D(GL_TEXTURE_2D, 0, NumElements, w, h, 0, GLFormat, GLType, pTex);

Any idea?



#7 Vortez   Crossbones+   -  Reputation: 2697

Like
1Likes
Like

Posted 06 January 2014 - 07:01 PM

I just tryed with this code instead and it also failed

	case scrf_4: 
		{
			float index[16] = {0.0f, (1.0f/15.0f), (2.0f/15.0f), (3.0f/15.0f), (4.0f/15.0f), (5.0f/15.0f), (6.0f/15.0f), (7.0f/15.0f), (8.0f/15.0f), (9.0f/15.0f), (10.0f/15.0f), (11.0f/15.0f), (12.0f/15.0f), (13.0f/15.0f), (14.0f/15.0f), 1.0f};
			
			glPixelMapfv(GL_PIXEL_MAP_I_TO_R, 16, index);
			glPixelMapfv(GL_PIXEL_MAP_I_TO_G, 16, index);
			glPixelMapfv(GL_PIXEL_MAP_I_TO_B, 16, index);
			glPixelMapfv(GL_PIXEL_MAP_I_TO_A, 16, index);
		}

		NumElements = 1;
		GLFormat = GL_COLOR_INDEX;
		GLType   = GL_BITMAP; // Also tryed GL_LUMINANCE4 and GL_LUMINANCE, without luck...
		break;


Edited by Vortez, 06 January 2014 - 07:56 PM.


#8 Vortez   Crossbones+   -  Reputation: 2697

Like
1Likes
Like

Posted 06 January 2014 - 09:19 PM

I got some result using

		NumElements = GL_LUMINANCE4;
		GLFormat = GL_LUMINANCE;
		GLType   = GL_UNSIGNED_BYTE;

but it's all blurry. At least i see something. Gonna make some test app to clear this up.



#9 richardurich   Members   -  Reputation: 1187

Like
0Likes
Like

Posted 06 January 2014 - 10:34 PM

To rule out a bunch of unrelated possible issues, can you ensure mipmapping is completely disabled and use GL_NEAREST instead of GL_LINEAR if you're not already doing so?

 

You might also try loading the data into 32-bit RGBA to help debugging. So you'd load 4-bit greyscale -> 32-bit RGBA. Then you'd at least know if the reading is the part messing up.

 

If you can easily make a test app demonstrating the problem, that would help a lot. I don't actually mess with 4-bit textures, and you're getting far enough along that nothing's just jumping out at me any more. So, congratulations for the progress you've made so far.

 

On a semi-unrelated note, your variable "NumElements" constantly throws me off. You seem to be using it as internalFormat, and I'm constantly ignoring it since I don't really care how many elements you have.



#10 Vortez   Crossbones+   -  Reputation: 2697

Like
1Likes
Like

Posted 07 January 2014 - 02:19 AM


To rule out a bunch of unrelated possible issues, can you ensure mipmapping is completely disabled and use GL_NEAREST instead of GL_LINEAR if you're not already doing so?

 

Yea, turn out i was using GL_LINEAR instead of GL_NEAREST, i have no idea why... but that's not the problem with the image. I did a simple test program, and it turn out it use the whole byte instead of half of it, hence the weird picture. I know the image is ok since im taking it with another test program and draw it using gdi, and it's ok.

 

 

 


On a semi-unrelated note, your variable "NumElements" constantly throws me off. You seem to be using it as internalFormat, and I'm constantly ignoring it since I don't really care how many elements you have.

 

Yea i noticed that too! i really need to change that variable name laugh.png .

 

I also made a thread here so i dont need to repeat what i just wrote.

 

Hope someone will find a solution... otherwise, i give up lol, and that dosen't happen often.

 

I beleive glPixelMapfv is the way to go, but i can't figure out how to use it with 4 bits sad.png

 

EDIT: i guess i could try to make a more portable test project tomorow that don't use my library, im too tired to make it tonigh that's for sure.


Edited by Vortez, 07 January 2014 - 02:25 AM.


#11 richardurich   Members   -  Reputation: 1187

Like
0Likes
Like

Posted 07 January 2014 - 10:35 AM

If you do try the pixel map approach again, one thing you'll definitely want to do is set alpha to 1 for all 16 values instead of x/15. You're basically creating intensity instead of luminance by setting alpha to x/15.



#12 Vortez   Crossbones+   -  Reputation: 2697

Like
1Likes
Like

Posted 07 January 2014 - 11:30 AM

Well thanx, but i decided to do a 4 to 8 bits conversion since it appear that's the only solution. Since im doing the conversion on the recv side of the network im still saving bandwith, and the conversion don't seem to affect performance in a noticable way. Thanx a lot for your help anyway. It's all working now smile.png.

 

EDIT: Yep, it's faster using the 4bpp than 8bpp mode, even with the conversion.


Edited by Vortez, 07 January 2014 - 11:39 AM.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS