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

Add a serialization option for EXIF dictionaries #129

Open
wants to merge 4 commits into
base: develop
Choose a base branch
from

Conversation

EtiennePelletier
Copy link
Contributor

Many have requested this feature for a while (#59, #110). With Python 2 being dropped in the next release, the task to add a serialization option becomes slightly more simple.

Converting IfdTags to native Python types cannot be done exclusively after parsing the EXIF tags currently because there is no way to know if the IfdTag.values were converted to a meaningful printable value (could be an enum, a make_string, etc) during processing (this depends on the tag definitions). This pull request adds a prefer_printable attribute to the IfdTag class that allows an external function to do the conversions properly.

In order to use the suggested conversion function, convert_ifdtag=True kwarg can be added to calls to process_file:

exifread.process_file(..., convert_ifdtags=True, ...)

A few fields contain or may contain binary data, preventing immediate dump to JSON (if chosen as serialization format, although databases like MongoDB handle storing binary natively). The tags are mainly JPEGThumbnail, TIFFThumbnail, EXIF MakerNote and MakerNote Tag 0x####, but there are more.
If JSON is strictly preferred, binary values can be handled afterwards in any appropriate way depending on the use case, or mainly excluded from the output dictionary with exifread.process_file(..., details=False, ...).

I updated the utils.get_gps_coords function to support both Exif tags where values are either IfdTag or native types.

All changes in this pull request are fully backwards compatible with current develop branch. I am open to any feedback!

🐍 🤹‍♂️

@ianare
Copy link
Owner

ianare commented Nov 6, 2020

This is great, thank you. I would like to take some time for testing and analysis but globally it looks good to me.

@EtiennePelletier
Copy link
Contributor Author

Hi @ianare , have you been able to have a look? A new release with this would be awesome! Thanks!

@EtiennePelletier
Copy link
Contributor Author

PR has been updated to fix conflicts from develop branch changes and account for import structure changes.

@ianare ianare force-pushed the develop branch 6 times, most recently from 05fe609 to 04efa3f Compare May 3, 2023 00:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants