[Added] WebP gets new file format option: Always generate Exif to save the resolution
Posted: Sat Nov 26, 2022 12:04 am
@forum_adm notified me via email about build 5672
Now JPEG, PNG and WEBP are "en par" in terms of storing resolution.
Summarized (please correct if something is wrong):
1) JPEG stores resolution info in the JFIF header. JFIF always stays intact during all operations. Cannot be "muted/stripped" neither in Editor nor by any action in a "Convert & Modify" batch. But it can be changed by menu or batch action.
2) PNG now has a file format option "Store Resolution" which stores resolution value into PNG-pHys as PPM (pixels per meter), and if Exif was in a file prior editing/converting it and if PNG file format options > Metadata > "Exif" is enabled, then resolution info is stored in Exif too.
3) WebP now has a file format option "Always generate Exif to save the resolution".
WebP resolution metadata tested in build 5672
• The resolution values are written only once (152 bytes more compared to not writing Exif at all).
• Not twice as in 5671 (were 204 bytes more compared to not writing Exif at all).
• So 52 bytes per file have been saved from this bugfix.
Checked in the "Exif" tab of the browser:
But I have some remaining concerns
The Exif information in a JPEG file is in the header of the file.
So in the first few bytes. So that interpretation can already begin early on:
Whereas the Exif chunk in the WebP file as GC build 5672 produces them are at the end of the file.
So the whole file must be downloaded / read-in before interpretation of the resolution tag can begin.
Not ideal, especially in a web context I assume.
Is this normal? Can you control this? If so could you move it from the tail to the header of the file?
WebP file format options got a new option:
[√] Store Metadata
[√] Exif
[√] Always generate Exif to save the resolution ← This is new
Now JPEG, PNG and WEBP are "en par" in terms of storing resolution.
Summarized (please correct if something is wrong):
1) JPEG stores resolution info in the JFIF header. JFIF always stays intact during all operations. Cannot be "muted/stripped" neither in Editor nor by any action in a "Convert & Modify" batch. But it can be changed by menu or batch action.
2) PNG now has a file format option "Store Resolution" which stores resolution value into PNG-pHys as PPM (pixels per meter), and if Exif was in a file prior editing/converting it and if PNG file format options > Metadata > "Exif" is enabled, then resolution info is stored in Exif too.
3) WebP now has a file format option "Always generate Exif to save the resolution".
WebP resolution metadata tested in build 5672
• The resolution values are written only once (152 bytes more compared to not writing Exif at all).
• Not twice as in 5671 (were 204 bytes more compared to not writing Exif at all).
• So 52 bytes per file have been saved from this bugfix.
Checked in the "Exif" tab of the browser:
- Resolution in EXIF chunk of WEBP files - b5671 twice b5672 once.png (415.58 KiB) Viewed 2345 times
But I have some remaining concerns
The Exif information in a JPEG file is in the header of the file.
So in the first few bytes. So that interpretation can already begin early on:
- Exif in header of JPEG file.png (103.67 KiB) Viewed 2345 times
Whereas the Exif chunk in the WebP file as GC build 5672 produces them are at the end of the file.
So the whole file must be downloaded / read-in before interpretation of the resolution tag can begin.
Not ideal, especially in a web context I assume.
Is this normal? Can you control this? If so could you move it from the tail to the header of the file?
- Diff b5672 MetaNone vs b5672 MetaExif 1x - Diff 3.png (192.63 KiB) Viewed 2345 times
Closing as [Added] because GraphicConverter now has this option and performs it.
On my remaining worry regarding the Exif chunk being at the end of the file instead of in the header I will research and inquire at the Google WebP Developer site.