Comment by Waterluvian
3 years 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)
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.
I feel like we’re talking past each other. I’ll find my answers elsewhere. Thanks for your time!
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.
2 replies →
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.