Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use EXIF or XMP for screenshot metadata #774

Open
jonnyawsom3 opened this issue Apr 21, 2024 · 8 comments
Open

Use EXIF or XMP for screenshot metadata #774

jonnyawsom3 opened this issue Apr 21, 2024 · 8 comments
Labels
feature New feature or request niche Niche request/bug fix

Comments

@jonnyawsom3
Copy link

Currently metadata is stored as raw text inside a PNG chunk. This means external programs either ignore it or can't read the text. Even exiftool refuses to export the data because it's not a recognised type.

This is especially annoying when trying to convert screenshots into a newer format. I've managed to halve the size of my screenshots losslessly, but the text chunk is always ignored making it useless...

Storing the metadata inside an EXIF chunk instead would mean more programs can read it, and the metadata would be preserved when converting to newer file formats too.

Alternatively, turning the text chunk into an XMP chunk is also an option. Then you can store the metadata in custom fields rather than filling up EXIF's description tag.

Ideally there'd be a button in the screenshot manager section to convert older files to the new format too

@jonnyawsom3 jonnyawsom3 added the feature New feature or request label Apr 21, 2024
@Myrkie
Copy link
Contributor

Myrkie commented Apr 21, 2024

the current implementation was done on purpose as to make sure it doesn't get stripped by sharing platforms like discord.

@jonnyawsom3
Copy link
Author

Discord only removes metadata from jpegs, and the XMP is still a text chunk with some extra formatting

@jonnyawsom3
Copy link
Author

jonnyawsom3 commented Apr 21, 2024

Test

Here's an example with both EXIF and XMP, it kept both when uploaded to Discord

@Myrkie
Copy link
Contributor

Myrkie commented Apr 21, 2024

Test

Here's an example with both EXIF and XMP, it kept both when uploaded to Discord

back then discord stripped all exif data this was during time of implementation of vrcxs feature, this is no longer the case and discord now only stripes exif data for GPS tags. back then it was a requirement, now its a stuck in feature and changing it would require migrating thousands of user pictures with wouldn't at all go off perfectly and could risk corruption, don't fix what isn't broken.

@Myrkie
Copy link
Contributor

Myrkie commented Apr 21, 2024

in your own example EXIF is stripped from that image we just tested it through vanilla discord clients ORG image

image

after being ran through discord through the vanilla client

image

@jonnyawsom3
Copy link
Author

Huh, so it does actually parse the EXIF chunk. Guess XMP would be the option then, although you already said no

@Myrkie
Copy link
Contributor

Myrkie commented Apr 21, 2024

Huh, so it does actually parse the EXIF chunk. Guess XMP would be the option then, although you already said no

well even if this wasn't the case it would still require migrating possibly thousands of user images to a new format and if we don't do that maintain the old format as well, we don't want to find ourselves in the middle of some funky migrator stage.

@GroovyTeacup
Copy link
Contributor

IIRC I looked into storing exif data at first but went with iTxT bc the PNG format < 1.2 doesn't really support exif data (at least in many decoders/editing software) and would be pointless to force in bc a lot of programs didn't even process it/detect it correctly, even if png 1.2 technically supports it on paper. Even now, imagemagick is about the only thing that detects the metadata we store.

It was part of the problem of going from the original implementation of the mod that did the same thing, but converted images to JPG and then stored metadata, which would be likely more involved and costly to do working on files after they've already been captured/saved.

@Natsumi-sama Natsumi-sama added the niche Niche request/bug fix label Apr 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request niche Niche request/bug fix
Projects
None yet
Development

No branches or pull requests

4 participants