Timeline for Are certain solid colors more likely to survive hardware texture compression unchanged?
Current License: CC BY-SA 4.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 18, 2022 at 15:16 | comment | added | Nicol Bolas | @Sparr: Then do the math. Normalization conversions 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. | |
| Aug 18, 2022 at 13:43 | comment | added | Sparr | then I'm looking for the colors that go through that strongly defined conversion function and come back with no/minimal change. | |
| Apr 25, 2022 at 14:53 | comment | added | Nicol Bolas | @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. | |
| Apr 25, 2022 at 14:44 | comment | added | Sparr | 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. | |
| Mar 1, 2022 at 14:27 | comment | added | Nicol Bolas | @Sparr: "survives X% of known/popular/common image compressors" That's not how lossy image compression works. | |
| Mar 1, 2022 at 5:54 | comment | added | Sparr | 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. | |
| Mar 1, 2022 at 5:53 | comment | added | Sparr | 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. | |
| Feb 7, 2022 at 15:50 | comment | added | Nicol Bolas | @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" 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. | |
| Feb 7, 2022 at 15:09 | comment | added | Sparr | 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? | |
| Jan 21, 2022 at 3:07 | comment | added | Nicol Bolas | @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. | |
| Jan 21, 2022 at 2:23 | comment | added | Sparr | 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. | |
| Jan 20, 2022 at 15:12 | comment | added | Nicol Bolas | @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. | |
| Jan 20, 2022 at 15:09 | comment | added | Sparr | 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. | |
| Jan 18, 2022 at 16:45 | history | answered | Nicol Bolas | CC BY-SA 4.0 |