I happen to have just opened a PR to support indexed PNGs in node-canvas (HTML Canvas impl for node) based roughly on the proposed pixelFormat API [1,2] for the same reason that the space savings can be immense.
It's also straightforward to change the palette of an indexed PNG after it's encoded because you don't need to re-compress the body. This lets you do cool tricks with recoloring images.
But to add to that, it needed to be customised for different screen sizes. So we'd have to have generated a lot of versions server side.
I'm curious if it would've been simpler to use it, albeit less efficient.
Pretty sure that only runs in Chrome anymore.
It would be a fascinating thing to work on, but the OffscreenCanvas API is coming to Chrome, so I suspect it would end up being a lot of work that would be obselete after not all that much time.
Is there a simple way to explain CRC for someone with just a high school mathematics background?
Otherwise, you’d probably have to learn some more advanced math first to understand CRC well enough to implement it.
Writing a minimal uncompressed PNG writer from scratch is a fun exercise; the spec is pretty clear and the only tricky part, really, is getting the uncompressed zlib part right, especially since the block sizes are undocumentedly little-endian, while everything else is big-endian.
Self-contained code for image generation and consumption can be pretty useful. It's one of the reasons that I like farbfeld, suckless's incredible simple binary image format, because libraries for processing it are essentially unnecessary since the format itself is so straightforward.
Yes! That stumped me for a long time. Along the way to solving it I found this great Stack Overflow answer where the creator of ADLER32 popped in to give some advice:
"Also just realized that you are that Mark Adler."
I added a subtitle to the Medium post, but should have considered the fact that it won't show up anywhere else. Not sure it would fit if it was appended to the end of the title here.