<p>There are two possibilities: you either are in control of the image format or you're not.</p>
<p>If you are in control of the image format, and you need a color to be exact, then use an image format that gives you that exact color. If the color you want cannot be represented in a 5:6:5 format, <em>don't use them</em>.</p>
<p>If you have no control over the image format, then you're going to have to look at what image format you're <em>told</em> to use and find something that's good enough. For basic 5:6:5, that's not too hard. But if you're being forced to use actual texture compression... you're out of luck.</p>
<p>Note that JPEG <em>does not care</em> about &quot;web-safe colors&quot;; it will do whatever it wants to the image. The same goes for texture compression schemes. By using texture compression, you have decided to sacrifice image accuracy for smaller space. That's just the nature of the beast.</p>

CC BY-SA 4.0
2022-01-20T15:09:08.367Z
I have updated the question to more explicitly specify hardware compression. This is about compression happening after my image is loaded, as part of sending it to the GPU, not about storing the image in a compressed image format.
Sparr
CC BY-SA 4.0
2022-01-20T15:12:22.803Z
@Sparr: Then you've already made a mistake. *You* should compress your images before loading them. Not only will you be able to see the results before sending them (and thus modifying the image if it is not satisfactory), you'll be able to use better compressors than ones that have to sacrifice quality for reasonable performance.
Nicol Bolas
CC BY-SA 4.0
2022-01-21T02:23:27.623Z
I don't have control over all the image processing pipelines that my textures might go through. Someone will JPEGify them. Someone will apply hardware texture compression. Someone will downsample them. This post is about proofing them against one of those operations. This is not a mistake, it's simply a use case you refuse to acknowledge.
Sparr
CC BY-SA 4.0
2022-01-21T03:07:25.530Z
@Sparr: "*I don't have control over all the image processing pipelines that my textures might go through.*" Then you have no control over your image, and you therefore must accept that it can be changed in ways you cannot control and therefore cannot account for. Even if there were some answer for one compression technique, who's to say that someone wouldn't invent a new one tomorrow that such a technique doesn't work for? At the end of the day, if you have no control over manipulations to your image, then you're out of luck. Lossy compression techniques are called "lossy" for a reason.
Nicol Bolas
CC BY-SA 4.0
2022-02-07T15:09:07.790Z
Your argument would declare web-safe colors useless and pointless, despite their clearly demonstrated usefulness. Do you have an argument that does not apply equally to web safe colors as to my request?
Sparr
CC BY-SA 4.0
2022-02-07T15:50:20.467Z
@Sparr: "*Your argument would declare web-safe colors useless and pointless*" They're useful within the context of a web page. Images, and image compressors, do not follow the rules of web pages. It also needs to be understood that ["web safe colors"](https://www.computerhope.com/jargon/w/web-safe-colors.htm) are more or less irrelevant now. They mattered a lot in the early days when many display chips used 256 colors. That's not today.
Nicol Bolas
CC BY-SA 4.0
2022-03-01T05:53:40.153Z
Maybe what I'm looking for would take the form of each color being given a "survives X% of known/popular/common image compressors" score, then using a palette composed of the highest scoring colors.
Sparr
CC BY-SA 4.0
2022-03-01T05:54:32.417Z
I think the world of hardware texture compression changes slowly enough that answers to this question would be useful on time scales of years. A perfect answer today would probably still be a good answer 3-5 years from now. I am certain that a perfect answer from 5 years ago would still be very useful to me today.
Sparr
CC BY-SA 4.0
2022-03-01T14:27:02.027Z
@Sparr: "*survives X% of known/popular/common image compressors*" That's not how lossy image compression works.
Nicol Bolas
CC BY-SA 4.0
2022-04-25T14:44:57.057Z
I'm not talking about that sort of image compression. I'm talking about the sorts of compression that downsamples colors, which I've called out examples of elsewhere on this page.
Sparr
CC BY-SA 4.0
2022-04-25T14:53:26.973Z
@Sparr: How things like 5:6:5 maps to output floating-point values is very well defined by OpenGL. I wouldn't try to do any equality tests with floats in shaders or anything, but the conversion function from normalized to float is strongly defined.
Nicol Bolas
CC BY-SA 4.0
2022-08-18T13:43:21.703Z
then I'm looking for the colors that go through that strongly defined conversion function and come back with no/minimal change.
Sparr
CC BY-SA 4.0
2022-08-18T15:16:02.027Z
@Sparr: Then do the math. [Normalization conversions](https://www.khronos.org/opengl/wiki/Normalized_Integer) aren't even hard math. When I said "very well defined by OpenGL", that means you can go look at the specification and see what the conversion is. By definition, for a 565 image, there are exactly 2^16 colors that can be stored exactly, so... there's your palette.
Nicol Bolas
CC BY-SA 4.0
2022-01-18T16:45:56.157Z
2022-01-18T16:45:56.157Z
Nicol Bolas
<p>I have encountered two solid grey textures, #303030 and #1b1b1b, being put through <a href="https://www.reedbeta.com/blog/understanding-bcn-texture-compression-formats/" rel="nofollow noreferrer">BCn texture compression</a> and coming out as #313031 (changed) and #1b1b1b (unchanged), presumably due to the 32-bit (8:8:8) to 16-bit (5:6:5) stage. For a texture with many colors I understand that texture compressor could pick arbitrary endpoints for the palette and I am effectively at the mercy of chance regarding which colors change how much. However, with single solid color textures, I am hopeful that there is some modern equivalent of <a href="https://en.wikipedia.org/wiki/Web_colors#Web-safe_colors" rel="nofollow noreferrer">web-safe colors</a> that I could at least somewhat rely on. Does this exist?</p>

CC BY-SA 4.0
2022-01-18T11:54:05.423Z
I dont see any reason why you can not pick colors that dont change in the 5:6:5 change. But seriously your neglecting to tell what compression yor using. Diferent compressions have different features. Theres no generic rule as how all compressions work. Also be a bit careful when talking about 32 bit color and 16 bit color. In general we are past using total bits per color and instead talk about bits per channel.
joojaa
CC BY-SA 4.0
2022-01-20T15:06:20.230Z
@joojaa I am not choosing a compression. Engines and drivers and hardware are doing it, in the same way that web designers don't get to choose the web browsers their colors appear in.
Sparr
CC BY-SA 4.0
2022-01-20T15:10:10.763Z
@joojaa Would you elaborate on how to pick such a color in an answer, please? I am not aware of a standard mapping of 8:8:8 to 5:6:5 colors that would make such a selection straightforward or reliable.
Sparr
CC BY-SA 4.0
2022-01-20T16:09:05.370Z
Normally webdesigners would compress the image and then view it on several simulations. Websafe hasnt been a thing in ages.
joojaa
CC BY-SA 4.0
2022-01-21T02:24:22.953Z
If "load the texture in several engines on several different OSes / drivers / graphics cards and see how it looks" is really the best solution, feel free to submit that as an Answer
Sparr
CC BY-SA 4.0
2022-01-21T06:12:41.907Z
and different monitors.
joojaa
<texture><compression>
Are certain solid colors more likely to survive hardware texture compression unchanged?
Sparr
# Are certain solid colors more likely to survive hardware texture compression unchanged?

(Asked by: username_0 on 2022-01-17)

I have encountered two solid grey textures, #303030 and #1b1b1b, being put through [BCn texture compression](https://www.reedbeta.com/blog/understanding-bcn-texture-compression-formats/) and coming out as #313031 (changed) and #1b1b1b (unchanged), presumably due to the 32-bit (8:8:8) to 16-bit (5:6:5) stage. For a texture with many colors I understand that texture compressor could pick arbitrary endpoints for the palette and I am effectively at the mercy of chance regarding which colors change how much. However, with single solid color textures, I am hopeful that there is some modern equivalent of [web-safe colors](https://en.wikipedia.org/wiki/Web_colors#Web-safe_colors) that I could at least somewhat rely on. Does this exist?

**Tags:** texture, compression

> **Comments:**
> **username_1**: I dont see any reason why you can not pick colors that dont change in the 5:6:5 change. But seriously your neglecting to tell what compression yor using. Diferent compressions have different features. Theres no generic rule as how all compressions work. Also be a bit careful when talking about 32 bit color and 16 bit color. In general we are past using total bits per color and instead talk about bits per channel.  
> **username_0**: @username_1 I am not choosing a compression. Engines and drivers and hardware are doing it, in the same way that web designers don't get to choose the web browsers their colors appear in.  
> **username_0**: @username_1 Would you elaborate on how to pick such a color in an answer, please? I am not aware of a standard mapping of 8:8:8 to 5:6:5 colors that would make such a selection straightforward or reliable.  
> **username_1**: Normally webdesigners would compress the image and then view it on several simulations. Websafe hasnt been a thing in ages.  
> **username_0**: If "load the texture in several engines on several different OSes / drivers / graphics cards and see how it looks" is really the best solution, feel free to submit that as an Answer  
> **username_1**: and different monitors.  

---

## 1 answers

### Answer by username_2 on 2022-01-18. Score: 1

There are two possibilities: you either are in control of the image format or you're not.

If you are in control of the image format, and you need a color to be exact, then use an image format that gives you that exact color. If the color you want cannot be represented in a 5:6:5 format, *don't use them*.

If you have no control over the image format, then you're going to have to look at what image format you're *told* to use and find something that's good enough. For basic 5:6:5, that's not too hard. But if you're being forced to use actual texture compression... you're out of luck.

Note that JPEG *does not care* about "web-safe colors"; it will do whatever it wants to the image. The same goes for texture compression schemes. By using texture compression, you have decided to sacrifice image accuracy for smaller space. That's just the nature of the beast.

> **Comments:**
> **username_0**: I have updated the question to more explicitly specify hardware compression. This is about compression happening after my image is loaded, as part of sending it to the GPU, not about storing the image in a compressed image format.  
> **username_2**: @username_0: Then you've already made a mistake. *You* should compress your images before loading them. Not only will you be able to see the results before sending them (and thus modifying the image if it is not satisfactory), you'll be able to use better compressors than ones that have to sacrifice quality for reasonable performance.  
> **username_0**: I don't have control over all the image processing pipelines that my textures might go through. Someone will JPEGify them. Someone will apply hardware texture compression. Someone will downsample them. This post is about proofing them against one of those operations. This is not a mistake, it's simply a use case you refuse to acknowledge.  
> **username_2**: @username_0: "*I don't have control over all the image processing pipelines that my textures might go through.*" Then you have no control over your image, and you therefore must accept that it can be changed in ways you cannot control and therefore cannot account for. Even if there were some answer for one compression technique, who's to say that someone wouldn't invent a new one tomorrow that such a technique doesn't work for? At the end of the day, if you have no control over manipulations to your image, then you're out of luck. Lossy compression techniques are called "lossy" for a reason.  
> **username_0**: Your argument would declare web-safe colors useless and pointless, despite their clearly demonstrated usefulness. Do you have an argument that does not apply equally to web safe colors as to my request?  
> **username_2**: @username_0: "*Your argument would declare web-safe colors useless and pointless*" They're useful within the context of a web page. Images, and image compressors, do not follow the rules of web pages. It also needs to be understood that ["web safe colors"](https://www.computerhope.com/jargon/w/web-safe-colors.htm) are more or less irrelevant now. They mattered a lot in the early days when many display chips used 256 colors. That's not today.  
> **username_0**: Maybe what I'm looking for would take the form of each color being given a "survives X% of known/popular/common image compressors" score, then using a palette composed of the highest scoring colors.  
> **username_0**: I think the world of hardware texture compression changes slowly enough that answers to this question would be useful on time scales of years. A perfect answer today would probably still be a good answer 3-5 years from now. I am certain that a perfect answer from 5 years ago would still be very useful to me today.  
> **username_2**: @username_0: "*survives X% of known/popular/common image compressors*" That's not how lossy image compression works.  
> **username_0**: I'm not talking about that sort of image compression. I'm talking about the sorts of compression that downsamples colors, which I've called out examples of elsewhere on this page.  
> **username_2**: @username_0: How things like 5:6:5 maps to output floating-point values is very well defined by OpenGL. I wouldn't try to do any equality tests with floats in shaders or anything, but the conversion function from normalized to float is strongly defined.  
> **username_0**: then I'm looking for the colors that go through that strongly defined conversion function and come back with no/minimal change.  
> **username_2**: @username_0: Then do the math. [Normalization conversions](https://www.khronos.org/opengl/wiki/Normalized_Integer) aren't even hard math. When I said "very well defined by OpenGL", that means you can go look at the specification and see what the conversion is. By definition, for a 565 image, there are exactly 2^16 colors that can be stored exactly, so... there's your palette.  

---

