Sign in to follow this  

Compression with YCoCg or other model?

This topic is 2848 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi I got 3 textures with similiar hue but different luminance. I want to compress the textures from 3->2. Therefore I was thinking of using the YCoCg model and store the independent Y's in one texture and the average CoCg in another. I was just thinking if there is a better approach? Maybe someone know of any recomdended reading. Thanks :)

Share this post


Link to post
Share on other sites
I guess any color model that separates luminance from color would be suitable, however YCC has the nice property of a comparably extremely cheap transformation from/to RGB, wheras HSV/HSL or even more complex formats often make use of trigonometry for that. Thus, from a purely computational POV, I'd say YCC is a good choice.

The one thing I didn't quite get is how you get a ratio of 3:2. If you have say 3 RGB textures with 24bpp (i.e. 72bpp total), you'd need then one texture with 16bpp for color, and 3 textures with 8bpp luminance, making a total of 40bpp, or a ratio of 9:5.

You could even cut down a bit more (no pun intended), if you know how much the maximal difference between two luminance steps is. You might be able to squeeze two delta-Y values into one byte then, quantizing might also be an option to achieve a fit there. You would of course introduce quite some additional bit-operations then, and the neccessity for such steps seem questionable in most general cases.

Share this post


Link to post
Share on other sites
Quote:
Original post by Medium9
I guess any color model that separates luminance from color would be suitable, however YCC has the nice property of a comparably extremely cheap transformation from/to RGB, wheras HSV/HSL or even more complex formats often make use of trigonometry for that. Thus, from a purely computational POV, I'd say YCC is a good choice.

The one thing I didn't quite get is how you get a ratio of 3:2. If you have say 3 RGB textures with 24bpp (i.e. 72bpp total), you'd need then one texture with 16bpp for color, and 3 textures with 8bpp luminance, making a total of 40bpp, or a ratio of 9:5.

You could even cut down a bit more (no pun intended), if you know how much the maximal difference between two luminance steps is. You might be able to squeeze two delta-Y values into one byte then, quantizing might also be an option to achieve a fit there. You would of course introduce quite some additional bit-operations then, and the neccessity for such steps seem questionable in most general cases.


This is the problem I'm facing: When using HL2 lightmaps (3 lightmaps which is computed from different directions and weighted in the pixel shader dependent on the normal map), in some scenes the hue is similar only the luminance differs. The idea is to decode the data in 2 maps instead of 3. With the YCoCg model the luminance(Y) is stored in one RGB map and the hue(CoCg) in the other. I can store the luminance in DXT1 format and the hue in CTX1 (U8V8). If I worked out the numbers right the precision would then be:

DXT1/RGB/YYY - 5+1/3 bits - R/4, G/2, B/4
CTX1/Co - 8 bits - R/2, B/2
CTX1/Cg - 8 bits - R/4, G/2, B/4
R = avg 10/3 bits
G = avg 4 bits
B = avg 10/3 bits

CoCg is based on the average of the 3 lightmaps. Should I weight the green-channel? And Y is computed individually for each lightmap. I was thinking that by dropping this post, someone might got any suggestions or objections to my approach.



// Encoding
avgColour = (lightmap0 + lightmap1 + lightmap2) / 3
Co = avgColour.r/2 - avgColour.b/2
Cg = -avgColour.r/4 + avgColour.g/2 - avgColour.b/4

Y0 = lightmap0.r/4 + lightmap0.g/2 + lightmap0.b/4
Y1 = lightmap1.r/4 + lightmap1.g/2 + lightmap1.b/4
Y2 = lightmap2.r/4 + lightmap2.g/2 + lightmap2.b/4

luminanceMap = (Y0, Y1, Y2) // Mapped to appropriate range
hueMap = (Co, Cg)


// Decoding (before this the textures are mapped to appropriate range)
R0 = luminanceMap.r - hueMap.r - hueMap.g
G0 = luminanceMap.r + hueMap.g
B0 = luminanceMap.r - hueMap.r - hueMap.g

R1 = luminanceMap.g - hueMap.r - hueMap.g
G1 = luminanceMap.g + hueMap.g
B1 = luminanceMap.g - hueMap.r - hueMap.g

R2 = luminanceMap.b - hueMap.r - hueMap.g
G2 = luminanceMap.b + hueMap.g
B2 = luminanceMap.b - hueMap.r - hueMap.g





[Edited by - 51mon on February 28, 2010 10:17:01 AM]

Share this post


Link to post
Share on other sites

This topic is 2848 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this