This is it.

Let’s say you’re covering a red pixel with a black pixel. There’s no way that red pixel will in any way “survive JPEG compression” because the compression happens on the raw pixel data; the raw pixel data no longer has a red pixel.

If the red pixel affected the encoding of nearby pixels in the compressed original, which you've now neglected to redact, then the data very well could persist.

That's not the point the other posts are making.

They're saying that before encoding the red dot could have been X pixels wide, and to the naked eye it would seem that after encoding it's still only X pixels wide... but due to compression artifacts it may now actually be affecting an area X+Y pixels wide. So only covering X pixels could leak Y pixels of information.

It honestly sounds a bit paranoid to me, but it's definitely possible.

> Let’s say you’re covering a red pixel with a black pixel. There’s no way that red pixel will in any way “survive JPEG compression” because the compression happens on the raw pixel data; the raw pixel data no longer has a red pixel.

This is trivially untrue for JPEG; JPEG often stores chroma info as 4:2:0, that is at a quarter the resolution of luminance info. In this common case, covering a single red pixel in the decoded form only removes a quarter of the chroma information from its presence (and this is easy to not notice if, for example, the other three pixels that share its chrominance are nearly black).

Except maybe your 2 was previously stored in the LossyNumber(TM) format which can only approximate integers, and it turned into 2.033. You add 8 to it, send it to me in a less lossy encoding, and I see 10.033. My knowledge of LossyNumber artifacts lets me know you started with 2!

Yes, but you know what the bare DCTs of the square box should be, so if they differ from that, it must be from the original image