Hi,

I tried your ExifRead on my Synology on two different images, that both contain tags if read with exiftool.

What details can I provide you?

Linux Synology_NAS 3.2.40 #3810 SMP Wed Nov 6 05:13:41 CST 2013 armv7l GNU/Linux synology_armadaxp_ds214+

Python 3.3.2 (default, Dec 23 2013, 16:12:02) [GCC 4.6.4] on linux

EXIF.py Ver 1.4.2

BR Nippey

I whacked at it until it seems to run under Python 3, but I didn't make the code conditional, so I have a replacement version... any interest? I'm not a git user, so I just grabbed the file, and edited. Tell me where to email the file, if interested. Was pretty straightforward. Otherwise I'll just put it on my web site, and it will acquire bit-rot...

My goal was to extract GPS data, so I added --gps option to print only that.

Seems imports are at fault, the path for makernote* is not automatically found when module is being installed. I modified the imports so that they work. Tested to be working on Python 2.7 and 3.3.

I recently forked the project here: https://github.com/rshk/exif-py/ and started some refactoring/clean up (pull requests coming soon), in order to make it installable from pypi and more efficient / maintainable.

I was wondering: what do you use for testing? Do you have a collection of jpegs along with known tag data? The library is seriously missing some unittests; I'd like to write some, but I miss the data..

Needed to correctly process Makernote of some Canon cameras. For instance Canon Powershot SX60.

After this pull request is accepted, I have two more about HDR tags.

For a particular image, exif-py tells me the latitude is:

EXIF GPS GPSLatitude, [31, 27, 2147/100]

So 31 degrees, 27 minutes, 21.47 seconds.

But if I view the GPS info from Preview in OSX, it tells me 21.468 seconds. An additional digit of accuracy.

Can you help me understand why?

Image and screenshot of exif-py and preview attached.

Add reconyx makernote tag mapping file for hc500 hyperfire, ultrafire and hf2 pro cameras. Ported from https://fossies.org/linux/Image-ExifTool/lib/Image/ExifTool/Reconyx.pm. Currently untested.

stubbed out 'cryptic_maker_note' method in classes.py since these images don't contain a 'make' tag in the exif data. Currently it's hard-wired to assume 'reconyx' make, but probably would be better to make it more generic. Not sure how many cameras have this same issue.

If a large string is read in then calling values.split caused a MemoryError. Even if that is caught, the python internal state became unusable. This patch avoids the problem by only reading up to the null byte.

I was processing a large list of image files and I was getting the error 'TypeError: unsupported operand type(s) for +: 'int' and 'str''. This is the complete output:

Opening: /Users/familypc/Desktop/culprit.jpg
Traceback (most recent call last):
  File "./EXIF.py", line 132, in <module>
    main()
  File "./EXIF.py", line 100, in main
    data = process_file(file, stop_tag=stop_tag, details=detailed, strict=strict, debug=debug)
  File "/private/tmp/exif-py/exifread/__init__.py", line 201, in process_file
    hdr.dump_IFD(exif_off.values[0], 'EXIF', stop_tag=stop_tag)
  File "/private/tmp/exif-py/exifread/classes.py", line 124, in dump_IFD
    entries = self.s2n(ifd, 2)
  File "/private/tmp/exif-py/exifread/classes.py", line 71, in s2n
    self.file.seek(self.offset + offset)
TypeError: unsupported operand type(s) for +: 'int' and 'str'

I was able to track the issue to a particular file:

That file was an Photoshop export from a Nikon RAW image (*.nef) to jpg. I don't know what's wrong with it. I have other files exported the same way and I didn't have issues. The files is perfectly fine because I can open it.

Hi Ianare,

i saw that you have already included some of the modification i did on my fork of your exif-py. I merged those back to my fork and did a few more modification, which i put in this pull request. I hope i did it right, since i'm still more accustomed to svn than to git. I did not change too much:

• i switched from distutils to setuptool and made the EXIF.py script an entry point insteat of a script
• the version number is now in exifread.init and is imported in both the setup.py and the EXIF.py to use with the -v switch

I have a few more things in mind so you can expect some more pull requests if this one works as expected.

Regards, Peter

Hi, First thanks for the excellent work. I'm trying to use this with Python 3.2.3 and have run across some issues.

1. In order to get the if to work for detecting the file type I had to change if data[base:base+2]=='\xFF\xE1': to if data[base:base+2]==b'\xFF\xE1': Adding a b binary flag (this also was fine when running with python2.7
2. Issue with ord() i.e. File "EXIF.py", line 1691, in process_file base=base+ord(data[base+2])*256+ord(data[base+3])+2 TypeError: ord() expected string of length 1, but int found I think if the ord() calls are removed (no convert needed) this fixes it for python3.2.3 (but will have issues on 2.7).
3. It then fails at the following (data[base:base+2] is empty): Segment base 0xCAD0 Unexpected/unhandled segment type or file content.

It would be excellent to have this working for Python 3.2.3 if possible. Works excellently with 2.7. Many thanks.

While writing type stubs for ExifRead (python/typeshed#9403), I've come across a few inconsistencies/bugs that are probably related to the str/bytes changes from Python 2 to Python 3.

1. ord_ is only ever called with a bytes argument, but checks for a str and returns a bytes argument unchanged:

https://github.com/ianare/exif-py/blob/51d5c5adf638219632dd755c6b7a4ce2535ada62/exifread/utils.py#L9-L12

I believe this method is mostly obsolete and could be replaced by straight calls to ord().

2. special_mode() in tags/makernote/olympus.py is (I think) passed a bytes string and returns a regular str. But in the case where the passed in string is empty, it will just return it unchanged (i.e. it will return bytes instead of str), possibly raise a TypeError:

https://github.com/ianare/exif-py/blob/51d5c5adf638219632dd755c6b7a4ce2535ada62/exifread/tags/makernote/olympus.py#L5-L26

Not sure if this was the intended behavior here as get_parser has no flow to return None, however, this change worked for me to load iPhone files, hoping it's helpful for someone else.

With this simple modification, it is possible to use details=False, extract_thumbnail=True. Processing 1156 CR2 images on a SD card-on USB card reader takes: details=True, extract_thumbnail=True (204 s) details=True, extract_thumbnail=True (2.67 s) details=False, extract_thumbnail=True (2.67 s)

So thumbnail extraction is very fast and should be possible to allow it independent of the detailed tags.

As the title says, while testing more images I found that some files use Motorola endian but DJI's makernotes always seem to be in Intel endian (like for Fujifilm makernotes).

This PR fixes that.

I am opening many image file and see absolutely useless warning:

PNG file does not have exif data.
PNG file does not have exif data.
PNG file does not have exif data.
PNG file does not have exif data.
PNG file does not have exif data.
PNG file does not have exif data.
PNG file does not have exif data.
PNG file does not have exif data.
PNG file does not have exif data.
PNG file does not have exif data.
PNG file does not have exif data.
PNG file does not have exif data.

module version:

$ pip3 list | grep ExifRead
ExifRead                3.0.0

If image file does not have exif data we just get empty dict.

Top-level large entries (e.g. MakerNote and UserComment) are usually in data format 7 (unspecified). See: http://www.fifi.org/doc/jhead/exif-e.html#DataForm We should simply ignore its length, read and keep its original values for further use.

But IfdTag entries inside MakerNote still have problems, which requires further investigation.