Earlier quoted context omitted.
ok thats pretty wild, you would take the zlib deflate/inflate code, (for example in a library like lodepng) and then like chunk 95% of it in the garbage? so basically every block would just be uncompressed? kind of funny but it would probably work pretty well and your code size could get down way way smaller than the current typical png code. seems like the downside is that this is "worse than nothing" compression, t…
Many PNG compressors allow you to specify the zlib compression level, where 0 = no compression. This will effectively give you an uncompressed image, perhaps with some format overhead. Your math is a bit off - a 1024x1024 at 32bpp would be 4MB, ignoring overhead. I've actually done something like this in the past - create PNGs with 0 compression, then compress it with something stronger than Deflate (like LZMA). Beca…
CPNG, a backwards compatible fork of PNG
121–122 of 122 posts
Re: CPNG, a backwards compatible fork of PNG
#122Earlier quoted context omitted.
Many PNG compressors allow you to specify the zlib compression level, where 0 = no compression. This will effectively give you an uncompressed image, perhaps with some format overhead. Your math is a bit off - a 1024x1024 at 32bpp would be 4MB, ignoring overhead. I've actually done something like this in the past - create PNGs with 0 compression, then compress it with something stronger than Deflate (like LZMA). Beca…
right but the "compression/decompression" code essentially becomes, like what, 10 lines of C? down from several thousand
In such a case, you could also skip the PNG filtering as well (whilst for my case, you wouldn't want to).
I think it'd make more sense to go with BMP for a 'simple as possible' image format, that has wide support, than with PNG. PNG is definitely more geared towards a compressed image (as well as all sorts of other features you may not care about).