I've been working on a pure Ruby JPEG encoder and a bug led me to an effect I wanted. The output looked just like the "crunchy" JPEGs my 2000-era Kodak digital camera used to put out, but it turns out the encoder wasn't following the zig-zag pattern properly but just going in raster order. I'm now on a quest to figure out if some early digital cameras had similar encoding bugs because their JPEG output was often horrendous compared to what you'd expect for the filesize.
The interesting thing about the situation I mentioned is that while the encoding algorithm was wrong, the actual output was valid JPEG that simply didn't look quite visually correct. But you're right, invalid encoding can be a problem too, and I have noticed during testing that a lot of decoders are quite forgiving of it.
Ah yeah that is an interesting case. In my situation, a thermal camera I got was inserting an invalid frame at the start which likely got used by their proprietary program to store data. VLC would view it but most of Mac/iOS would refuse to play the video until I used ffmpeg to delete the invalid frame.
Yes. The size is slightly different here to show it off better, but compare left and right in https://peterc.org/misc/queen.png (both are the same "quality" and file size but the right hand one has incorrect quantization ordering)
Also it turns out it wasn't a Kodak camera, but a Casio QV 10 I had much earlier. You can sorta see what I meant here: https://medium.com/people-gadgets/the-gadget-we-miss-the-cas... .. though the resolution is far lower too. The weird blocky color aberrations aren't just JPEG artefacts but related to the same quantization ordering issue I think.
My assumption also, but once this thing spat out those images by accident, I started to wonder if maybe broken code ended up in the firmware of these cameras and just.. stayed there :-D Might be a fun project one day if I can get hold of one and rip out the firmware!
