# Compression with YCoCg or other model?

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

## 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 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 on other sites
Quote:
 Original post by Medium9I 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.

// EncodingavgColour = (lightmap0 + lightmap1 + lightmap2) / 3Co = avgColour.r/2 - avgColour.b/2Cg = -avgColour.r/4 + avgColour.g/2 - avgColour.b/4Y0 = lightmap0.r/4 + lightmap0.g/2 + lightmap0.b/4Y1 = lightmap1.r/4 + lightmap1.g/2 + lightmap1.b/4Y2 = lightmap2.r/4 + lightmap2.g/2 + lightmap2.b/4luminanceMap = (Y0, Y1, Y2)   // Mapped to appropriate rangehueMap = (Co, Cg)// Decoding (before this the textures are mapped to appropriate range)R0 = luminanceMap.r - hueMap.r - hueMap.gG0 = luminanceMap.r + hueMap.gB0 = luminanceMap.r - hueMap.r - hueMap.gR1 = luminanceMap.g - hueMap.r - hueMap.gG1 = luminanceMap.g + hueMap.gB1 = luminanceMap.g - hueMap.r - hueMap.gR2 = luminanceMap.b - hueMap.r - hueMap.gG2 = luminanceMap.b + hueMap.gB2 = luminanceMap.b - hueMap.r - hueMap.g

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

1. 1
Rutin
23
2. 2
3. 3
JoeJ
20
4. 4
5. 5

• 32
• 41
• 23
• 13
• 13
• ### Forum Statistics

• Total Topics
631742
• Total Posts
3001986
×