3 ms·

It's not the core issue, and it's misleading to suggest that it is. I suggest reading the aptly named "Root Cause Analysis" section of the linked article.

Waterluvian 4y ago
I’m trying to follow the article. So it’s not the image format specifically that is holding on to the blacked out pixels, it’s the compression method that the image format uses, or more specifically, how Google’s code is handling that work? Is this possibly a helpful feature or is it really just a terrible hack/bug that has no practical use holding on to a sort of edit history inside a PNG? I would love a way to track some level of history in a commonly supported image format (but of course being aware of needing to strip it when appropriate)
- Retr0id 4y ago
  It's neither a feature nor a hack, it's simply a bug related to missing the O_TRUNC flag when opening the file for modification. No deliberate attempt was made to "hold onto" any data.
  - Waterluvian 4y ago
    I feel like we’re talking past each other. I’ll find my answers elsewhere. Thanks for your time!
    - tslater2006 4y ago
      My (limited) understanding is that if you have say a 5mb file, and you open it for writing and wrote 3mb. You might expect the file to be 3mb, but...if you didn't specify the truncate flag (the bug here) the file is still actually the 5mb it was. The image appears cropped because the relevant metadata has the new sizes etc, but that 2mb of extra data is still there by mistake. This can be used to recover some of the original image.
      - Waterluvian 4y ago
        Aha! Thanks. So this behaviour is likely unfit to be used as a feature, but could in some cases be used as a clever hack to, in a way, preserve some edited (cropped) data.
        Retr0id 4y ago
        No, it is not suitable as a clever hack. It doesn't work reliably or well enough for that.
    - andybak 4y ago
      With all due respect, it's simply that you haven't properly understood the article. You sound like you're probably fairly smart but I suspect you're rushing this one and commenting before you've properly grasped the topic.

Waterluvian 4y ago

I’m trying to follow the article. So it’s not the image format specifically that is holding on to the blacked out pixels, it’s the compression method that the image format uses, or more specifically, how Google’s code is handling that work? Is this possibly a helpful feature or is it really just a terrible hack/bug that has no practical use holding on to a sort of edit history inside a PNG? I would love a way to track some level of history in a commonly supported image format (but of course being aware of needing to strip it when appropriate)

Retr0id 4y ago
It's neither a feature nor a hack, it's simply a bug related to missing the O_TRUNC flag when opening the file for modification. No deliberate attempt was made to "hold onto" any data.
- Waterluvian 4y ago
  I feel like we’re talking past each other. I’ll find my answers elsewhere. Thanks for your time!
  - tslater2006 4y ago
    My (limited) understanding is that if you have say a 5mb file, and you open it for writing and wrote 3mb. You might expect the file to be 3mb, but...if you didn't specify the truncate flag (the bug here) the file is still actually the 5mb it was. The image appears cropped because the relevant metadata has the new sizes etc, but that 2mb of extra data is still there by mistake. This can be used to recover some of the original image.
    - Waterluvian 4y ago
      Aha! Thanks. So this behaviour is likely unfit to be used as a feature, but could in some cases be used as a clever hack to, in a way, preserve some edited (cropped) data.
      - Retr0id 4y ago
        No, it is not suitable as a clever hack. It doesn't work reliably or well enough for that.
  - andybak 4y ago
    With all due respect, it's simply that you haven't properly understood the article. You sound like you're probably fairly smart but I suspect you're rushing this one and commenting before you've properly grasped the topic.