Use canonical tag names from Exiv2 project - #30
Conversation
|
@lovell Any thoughts on this? I published a beta package from my fork and it works quite well for me. |
lovell
left a comment
lovell
left a comment
There was a problem hiding this comment.
I've tested this change with the sharp unit tests via lovell/sharp@0ec30c8 and all is good. I've left a comment inline about a possible changelog too.
|
@papandreou Hi Andreas, as someone who maintains packages that depend on |
papandreou
left a comment
papandreou
left a comment
There was a problem hiding this comment.
No objections from me 🚀
Co-authored-by: Andreas Lind <andreaslindpetersen@gmail.com>
Co-authored-by: Andreas Lind <andreaslindpetersen@gmail.com>
Co-authored-by: Andreas Lind <andreaslindpetersen@gmail.com>
|
@devongovett , @lovell can I do anything else, so that we can merge and publish a version? |
|
All good, thank you Christian. If no one has any objections I can tag the latest as v2.0.0 and publish to npm. |
|
@atombrenner Thanks again. Would you be able to start the deprecation process for the |
|
@lovell,@akwodkiewicz Started the deprecation process, see DefinitelyTyped/DefinitelyTyped#66885 |
3 participants
My proposal for #29
Use the canonical tag names from the Exiv2 project. This gives us tag names that are aligned with the Exif standard. It enables generation of more specific typescript types. It will also prevent potential wrong information as the former version defined a few duplicate tag names.
This is a major version change, as group and tag names will change. See below:
Duplicate Tag Names
This is most probable a bug in exif-reader, as those tags would return wrong results if
they exist in the same file:
Changed Tag Names
New Tag Names
Non standard Tag Names (removed)
A sampling of those values on https://exiftool.org/TagNames/EXIF.html indicates that they are either
offsets to vendor specific IFDs or are not part of any IFD (basicly undocumented on exiftool)