[Added] Ability to save 72 PPI into PNG file vs explicitly stripping PPI info (PNG-pHYs value)
- forum_adm
- Site Admin
- Posts: 1819
- Joined: Fri Dec 23, 2016 9:41 am
- Location: Germany
- Country: Germany
- Contact:
Re: Ability to save 72 PPI into PNG file vs explicitly stripping PPI info (PNG-pHYs value)
Exif is only written if the file contains an Exif record. That is the normal behavior.
Re: Ability to save 72 PPI into PNG file vs explicitly stripping PPI info (PNG-pHYs value)
Ad 5) More detailed Exif manipulation in batch.
- Thanks for confirming that the current behavior is the expected behavior.
- Do you consider to manipulate Exif not only via the metadata menu of the editor but by a capable batch action?
- Or would this workaround work maybe: If I would record a macro in the editor in which I use the Metadata/Exif menu to strip/add/manipulate certain Exif values, could that macro be "replayed" in the batch correctly? This would be an acceptable workaround. Just better wanted to ask before too much trial and error, if that is supposed to work at all.
Ad 4) Research question: Does your contemporary macOS 13 Ventura's Spotlight Importer already parse resolution info in Exif of WebP files?
- I think you indirectly answered that in your post regarding Core Media in macOS Ventura handling resolution in Exif of WebP correctly.
- Does mdls and Preview.app in macOS Ventura also get the PPI for WebP files correctly?
What about my other open questions?
2) Achieving feature parity between dialog and batch action.
3) Possibility for user to specify value in dimension unit of own choice
- Thanks for confirming that the current behavior is the expected behavior.
- Do you consider to manipulate Exif not only via the metadata menu of the editor but by a capable batch action?
- Or would this workaround work maybe: If I would record a macro in the editor in which I use the Metadata/Exif menu to strip/add/manipulate certain Exif values, could that macro be "replayed" in the batch correctly? This would be an acceptable workaround. Just better wanted to ask before too much trial and error, if that is supposed to work at all.
Ad 4) Research question: Does your contemporary macOS 13 Ventura's Spotlight Importer already parse resolution info in Exif of WebP files?
- I think you indirectly answered that in your post regarding Core Media in macOS Ventura handling resolution in Exif of WebP correctly.
- Does mdls and Preview.app in macOS Ventura also get the PPI for WebP files correctly?
What about my other open questions?
2) Achieving feature parity between dialog and batch action.
3) Possibility for user to specify value in dimension unit of own choice
- forum_adm
- Site Admin
- Posts: 1819
- Joined: Fri Dec 23, 2016 9:41 am
- Location: Germany
- Country: Germany
- Contact:
Re: Ability to save 72 PPI into PNG file vs explicitly stripping PPI info (PNG-pHYs value)
4) Yes, Preview onto Ventura shows the dpi/ppi correctly.
Re: Ability to save 72 PPI into PNG file vs explicitly stripping PPI info (PNG-pHYs value)
I converted my stack of images through various stages, kept each main stage as its folder.
Now my last folder with PNGs is like this:
1) All normalized to sRGB but with no ICC embedded (nor a sRGB reference flag , btw I am waiting for an answer whether you want to offer that for GC or not) so web browsers will interpret them as sRGB.
2) Exif stripped, no unnecessary metadata. Less data to download is good and less attributes to parse/interpret makes rendering faster, SEO better.
3) Resolution info is stored in PNG-pHYs.
The good news: When you now batch convert those "almost barebone PNG files" of that folder to the output format WebP with the file format options "Metadata: [√] Exif" then GC does the following:
GC creates the Exif chunk in the RIFF container of the WebP file and stores the resolution info there.
So when you have a PNG w/o metadata and change the PPI value, and save as PNG with Exif, GC does NOT create an Exif header in order to write the resolution tags there. But for WebP it does this! By whatever abstraction/logic, you know your code.
Now my last folder with PNGs is like this:
1) All normalized to sRGB but with no ICC embedded (nor a sRGB reference flag , btw I am waiting for an answer whether you want to offer that for GC or not) so web browsers will interpret them as sRGB.
2) Exif stripped, no unnecessary metadata. Less data to download is good and less attributes to parse/interpret makes rendering faster, SEO better.
3) Resolution info is stored in PNG-pHYs.
The good news: When you now batch convert those "almost barebone PNG files" of that folder to the output format WebP with the file format options "Metadata: [√] Exif" then GC does the following:
Re: Ability to save 72 PPI into PNG file vs explicitly stripping PPI info (PNG-pHYs value)
Closing this feature request issue as [Added] Thanks!