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

Lazily use ImageFileDirectory_v1 values from Exif #4031

Merged
merged 4 commits into from Sep 9, 2019

Conversation

@radarhere
Copy link
Member

radarhere commented Aug 18, 2019

ImageFileDirectory_v1 is lazy, performing operations when a value is accessed.

However, accessing all of those values to create a dictionary when loading the data undoes that speed increase.

#3663 set out to fix this by adding a new class - however, it had conflicts once #3625 was merged and a different class was added to deal with Exif data. This PR takes a different approach towards the original goal, for the new context.

It also uses this change by swapping calls in JpegImagePlugin and MpoImagePlugin from _getexif to getexif, switching from JpegImagePlugin creating a dict of all the values to using the now-lazy Exif class.

Copy link
Contributor

Glandos left a comment

The use of getexif instead of _getexif is not completely idempotent.

src/PIL/JpegImagePlugin.py Show resolved Hide resolved
@@ -92,7 +92,7 @@ def seek(self, frame):
n = i16(self.fp.read(2)) - 2
self.info["exif"] = ImageFile._safe_read(self.fp, n)

exif = self._getexif()
exif = self.getexif()

This comment has been minimized.

Copy link
@Glandos

Glandos Aug 20, 2019

Contributor

The main difference is that getexif from Image class does not cache the parsed Exif tags.
So this call is done and forget when the user will need it.

This is not what we should expect.

This comment has been minimized.

Copy link
@radarhere

radarhere Aug 21, 2019

Author Member

I'm not following, sorry. Yes, using _getexif would create a cache of the parsed exif tags, but it would also iterate over all the values.

From my understanding, the point of these PRs is to reduce operations on load to potentially increase speed - we don't need to work out all of the EXIF values when a user might not even be interested in them. When JpegImagePlugin and MpoImagePlugin only need two EXIF values each, isn't decoding all the values overkill?

This comment has been minimized.

Copy link
@Glandos

Glandos Aug 21, 2019

Contributor

Sorry for the unclear review.
Yes, calling getexif is better, but right now, when reading an image, the _getexif function is called, and the result is cached so that if the user called it once again, the computation will not happen a second time.
This is not the case with getexif. If I trace a call to Image.open("my_image.jpg").getexif(), then the dictionary loading and some decoding will happens twice.

In my opinion, the Exif object should be stored into the Image instance once loaded. And if the user needs to modify it, this object could be cloned.

I hope it is clearer now 😄

This comment has been minimized.

Copy link
@radarhere

radarhere Aug 22, 2019

Author Member

Okay, see what you think of this idea - I have pushed a commit that changes im.getexif() so that it returns a shared instance of the Exif class, meaning that getexif decoding of EXIF values is now cached. This actually makes the _getexif "parsed_exif" cache largely redundant, because _getexif uses getexif, so I have removed that. Hopefully, that should make all scenarios faster.

This comment has been minimized.

Copy link
@Glandos

Glandos Aug 24, 2019

Contributor

Very nice now :) Iterating 1000 times over an image (open().getexif()), I go from 18.0s to 8.11s. Confirmed by %timeit in IPython, going from 3.69ms per loop to 1.68ms per loop.

The last step (for me) is to get rid of _fixup_dict call of the tag 0x8769, but this should be in another PR.

@radarhere radarhere force-pushed the radarhere:exif branch 4 times, most recently from 573d25e to e9e3431 Aug 22, 2019
@radarhere radarhere force-pushed the radarhere:exif branch from e9e3431 to f3ed44a Aug 22, 2019
@hugovk

This comment has been minimized.

Copy link
Member

hugovk commented Sep 7, 2019

Thanks @radarhere for the PR and @Glandos for the review (and other PRs)!

Most of the changes are covered by existing tests. 👍

Would this benefit from adding simple tests to directly test some of the changed/added functions?

If I'm following this report correctly, it looks like at least this __str__ isn't covered by any tests at all:

image

https://codecov.io/gh/python-pillow/Pillow/compare/a44e918a5b647d5eb75e0bf3fe3df4d6501cb78d...f3ed44a5662ea2728fae2139bbdde9419356302a/diff#D1-3299

@radarhere radarhere force-pushed the radarhere:exif branch 3 times, most recently from b102453 to a866b61 Sep 7, 2019
@radarhere radarhere force-pushed the radarhere:exif branch from a866b61 to 5a66877 Sep 8, 2019
@radarhere

This comment has been minimized.

Copy link
Member Author

radarhere commented Sep 9, 2019

Okay, I've added a test for __str__.

The externally visible changes are the removal of info["parsed_exif"] and the fact that getexif() now returns a shared instance. I've added a test for the shared instance.

@hugovk

This comment has been minimized.

Copy link
Member

hugovk commented Sep 9, 2019

Thanks all!

@hugovk hugovk merged commit e5f6b86 into python-pillow:master Sep 9, 2019
18 checks passed
18 checks passed
codecov/patch 94.91% of diff hit (target 85.44%)
Details
codecov/project 85.49% (+0.04%) compared to da39d40
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
python-pillow.Pillow Build #20190908.1 succeeded
Details
python-pillow.Pillow (Lint Python37) Lint Python37 succeeded
Details
python-pillow.Pillow (alpine) alpine succeeded
Details
python-pillow.Pillow (amazon_1_amd64) amazon_1_amd64 succeeded
Details
python-pillow.Pillow (amazon_2_amd64) amazon_2_amd64 succeeded
Details
python-pillow.Pillow (arch) arch succeeded
Details
python-pillow.Pillow (centos_6_amd64) centos_6_amd64 succeeded
Details
python-pillow.Pillow (centos_7_amd64) centos_7_amd64 succeeded
Details
python-pillow.Pillow (debian_10_buster_x86) debian_10_buster_x86 succeeded
Details
python-pillow.Pillow (debian_9_stretch_x86) debian_9_stretch_x86 succeeded
Details
python-pillow.Pillow (fedora_29_amd64) fedora_29_amd64 succeeded
Details
python-pillow.Pillow (fedora_30_amd64) fedora_30_amd64 succeeded
Details
python-pillow.Pillow (ubuntu_16_04_xenial_amd64) ubuntu_16_04_xenial_amd64 succeeded
Details
python-pillow.Pillow (ubuntu_18_04_bionic_amd64) ubuntu_18_04_bionic_amd64 succeeded
Details
@radarhere radarhere deleted the radarhere:exif branch Sep 9, 2019
@radarhere radarhere mentioned this pull request Sep 14, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants
You can’t perform that action at this time.