bfaure
commented
3 months ago Interesting idea, I think in that case you'd want to encode at the byte-level rather than bit-level since a colored pixel can encode far more than just 1/0. If we said for example that a single colored pixel can store a full byte that would be 8x more efficient than using black/white encoding, you'd just need a mapping between byte-values and colors, e.g.
0: (0, 0, 0) - Black 1: (255, 0, 0) - Red 2: (0, 255, 0) - Green 3: (0, 0, 255) - Blue ... 255: (255, 255, 255) - White
To your point you'd still need to consider the lossy compression issues so you'd probably want to make the "pixels" be larger than a single pixel, maybe 32x32, in which case you'd be able to fit around 8k "pixels", or in other words, 8k bytes per frame in that example.
To compare it to black/white you'd probably need to see how small you can get the "pixels" in both approaches without the compression starting to destroy the file contents, if you can get the pixels in the colored approach to be less than or equal to 8 times larger (if my math is right) then it would be more efficient. Of course each colored "pixel" holds more data but if the colors are too similar the compression algorithm might start to combine them with their neighbors even if they are slightly different colors, which is less likely if the only options are black/white.
ybtx2957
Hey I just thought that maybe instead of using black and white squares we can use colorful squares for better efficiency. Idk if I'm wrong. I haven't thought about the compression. Would that be the problem?