nonamethanks said:
The issue is that whatever software twitter uses to process images received a corrupted file, and basically took a random row of pixels close to the end of the file and slapped it where the missing data was. Maybe it's not corrupted in the sense that it won't raise an error if you try to open it, but it's still corrupted by any other definition of the term. It's a garbled file, though only for one or two rows of pixels.
If the edge between the normal and incorrect image data was at a height that’s a multiple of 16, I’d agree. The corrupted images are JPEGs and if a JPEG has corrupted data, you’ll get a 16x16 block of garbage. If data is missing somewhere, you’ll get garbage until the end of the image, but it’ll start at a 16x16 block. However, in the five examples above, that’s not the case. The incorrect data starts at a height that’s not a multiple of 16, so this is clearly Twitter’s image processing clobbering image data that should be there, or, more likely, tacking on extra image data, thereby enlarging the image. My guess is that this is a decoding error in the normally invisible gutter. As every block must be 16x16 pixels (If the image has chroma subsampling, which is pretty common. Otherwise it’s 8x8.) but the image might not have a matching height, the last row of blocks is encoded as if it had some extra lines to fill up to 16, but those extra lines are never shown because the correct height is saved in the JPEG header. Now if the image decoder is bugged, it will decode the full 16 pixels high last row of blocks and then not discard the invisible pixel rows, instead filling it with some other part of the image. It’s actually quite likely that the extra data is actually leaked memory because the decoder allocated memory for the full 16 rows, which contained old data from a few steps ago, and then overwrote only the ones it was supposed to decode. Either way, I’m pretty sure this is an artifact of incorrectly decoding a perfectly fine JPEG. This is also why all the “broken” images (that I’ve seen) have a height that’s a multiple of 16.
Edit: The post #3844117 that you mentioned uses 8x8 blocks (because of no chroma subsampling) and the corrupt blocks are all 8x8, so this is an actually corrupt file.