5 ms·

No? If it were to be visible it would be because your editing software failed to blend the layers together properly during compositing and rasterization. JPEG e

No? If it were to be visible it would be because your editing software failed to blend the layers together properly during compositing and rasterization. JPEG encoding comes after this.

cultureulterior 4y ago
I think they mean the original compression of the original text file (if in jpeg) would have crafted specific DCT coefficients that reach across to the secret text. When that is later decoded to pixels and re-encoded, new DCTs are burned into the image, but only on top of the previous.
- thrdbndndn 4y ago
  That's not how it works. it is "on top" of the previous, sure, but the same way as if I add 8 to 2 and give you 10, you can't possibly get the original number is 2.
  - cultureulterior 4y ago
    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
  - laudecum 4y ago
    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.
    - ummonk 4y ago
      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.
    - BoorishBears 4y ago
      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.
    - addaon 4y ago
      > 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).
      - laudecum 4y ago
  - skupig 4y ago
    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!

No? If it were to be visible it would be because your editing software failed to blend the layers together properly during compositing and rasterization. JPEG encoding comes after this.

cultureulterior 4y ago

I think they mean the original compression of the original text file (if in jpeg) would have crafted specific DCT coefficients that reach across to the secret text. When that is later decoded to pixels and re-encoded, new DCTs are burned into the image, but only on top of the previous.

thrdbndndn 4y ago
That's not how it works. it is "on top" of the previous, sure, but the same way as if I add 8 to 2 and give you 10, you can't possibly get the original number is 2.
- cultureulterior 4y ago
  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
- laudecum 4y ago
  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.
  - ummonk 4y ago
    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.
  - BoorishBears 4y ago
    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.
  - addaon 4y ago
    > 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).
    - laudecum 4y ago
- skupig 4y ago
  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!