koobas.hobune.stream
Texture color values changing slightly despite compression settings
In a project I'm working on, we have built a system that samples color info from a series of 2048 x 1024 textures (in gif format if that matters. Only one frame) and uses it to set up data. In order for the system to work, the sampled pixels must be the precise RGBA values. Previously, the system had been working so long as our textures were set to not be compressed. We have since updated to Unity 2018.2.0f2 Personal to take advantage of unrelated features, but since doing so it seems that our images are now all being slightly compressed, and roughly 40% of our RGBA values are off by one in one direction or the other. I have tried many different settings, and none of them seem to make any difference. It's tough to find information on this, as most people can't tell and don't care if their colors are off by one 255th. Mostly I've been using the Default texture type, as none of the other settings are particularly appropriate, although I have also tried Editor GUI & Legacy GUI. I've tried sRGB on and off. I've set the alpha source to none (our textures don't use alpha). Non Power of 2 is inactive, presumably due to the dimensions of the image. Read/Write must be enabled, or else we can't sample the pixels. I've turned off both streaming and generate mip maps. I've set wrap mode to Clamp. I've set filter mode to Point. Ansio is inactive. On default settings the max size is 2048 or higher. I've tried both Bilinear and Mitchell. Compression is set to none. I've tried flagging override for PC, Mac & Linux and setting the format to RGB16, RGB24, ARGB16, RGBA32, and RGBA Half. And yes, I am hitting "Apply" afterwards. Despite all of this tweaking, the colors are still always slightly compressed. I would appreciate any guidance in this matter. Have I overlooked something? Or is this a bug with the version of Unity? I would prefer to not have to roll back to an earlier version of Unity if I can get away with it.
Nevermind. Further investigation shows that we updated a 3rd party script, and the updated code now converts a Color32 to a Color and back to a Color32, resulting in a floating point rounding issue.
