Exception IOError("EXIF APP1 segment not found") raised when opening an image without EXIF

[Tomaszek]

Greetings!

It's a great library! However, it seems that when I'm trying to open an image that doesn't contain EXIF I'm getting IOError("EXIF APP1 segment not found") exception.

It is an issue since I'm trying to process a number of files where only some of them have EXIF data. It would be great to handle non-EXIF images without throwing an exception as this is a quite expensive operation and in my case will have a significant impact on performance.

Or am I missing something and there is a recommended way to handle images without EXIF?

[TNThieding]

Thank you for reaching out. Currently, users must use a try/except block as you mentioned above. Do you have any suggestions for a different way of handling this use case? I'd love to get your perspective and hear your use case as a user of the library.

[Tomaszek]

Hi Tyler,

My use case is this: I analyze thousands, potentially tens of thousands of images a day, stored in S3 bucket. Extracting data from Exif is one of the steps in this analysis. Some of those images, potentially all of them, uploaded on a given day, might not have an Exif. This means that I need to consider the handling of an image without Exif as a normal flow in my application rather than the exception, as it could become quite expensive. In terms of execution time but in the case of AWS also quite literally.

I'm coming from the .NET world and only writing in Python in the last 6 months or so, therefore I don't feel comfortable to suggest any solution that would be a clean pythonic way. From my simplistic perspective Image() could succeed just fine and then dir() would return an empty list in case of such an image.

[gilesknap]

In my use of this library, I do use exceptions to handle missing exif and there is no need to worry about the cost of exceptions for python code (a good discussion is here https://softwareengineering.stackexchange.com/questions/351110/are-exceptions-for-flow-control-best-practice-in-python ). At first, I was not sure about the silent handling of missing Exif in Image() because I want to know if about it. But in truth what I want to know is if there is a UID for the image and there might not be one even if there is Exif, so I already check for this. Thus my code would be simplified by this change. I still think you want a way to explicitly check if exif is found and "len(Image(file).dir()) == 0" is a bit long winded and non-obvious. So, I think having Image() always succeed but then have an 'Image.has_exif' field would be quite nice. Also, this gives a way to provide the API to add Exif to an existing file that has none. (That is once adding of new Exif fields is supported - something that I promised to take a look at some time ago #8)

…

On Thu, Jul 4, 2019 at 1:01 PM Tomaszek ***@***.***> wrote: Hi Tyler, My use case is this: I analyze thousands, potentially tens of thousands of images a day, stored in S3 bucket. Extracting data from Exif is one of the steps in this analysis. Some of those images, potentially all of them, uploaded on a given day, might not have an Exif. This means that I need to consider the handling of an image without Exif as a normal flow in my application rather than the exception, as it could become quite expensive. In terms of execution time but in the case of AWS also quite literally. I'm coming from the .NET world and only writing in Python in the last 6 months or so, therefore I don't feel comfortable to suggest any solution that would be a clean pythonic way. From my simplistic perspective Image() could succeed just fine and then dir() would return an empty list in case of such an image. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#21?email_source=notifications&email_token=AAHLRWZOVNESJPNW5OUATBLP5XRCJA5CNFSM4H42I4DKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZHHDTI#issuecomment-508457421>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHLRW4F5X2BKEN3LQT4HLDP5XRCJANCNFSM4H42I4DA> .

[Tomaszek]

there is no need to worry about the cost of exceptions for python code (a good discussion is here https://softwareengineering.stackexchange.com/questions/351110/are-exceptions-for-flow-control-best-practice-in-python ).

Thanks for that! The post you quoted provides an in-depth explanation, so thanks again for the link. I'm taking that exception catching in Python is not as expensive. However, in this post the timings (and some answers) indicate a significant overhead when catching the exception vs if-else statement.

[TNThieding]

I just released version 0.8.0 of the package (see https://gitlab.com/TNThieding/exif/merge_requests/21) which adds the has_exif attribute and removes the IOError exceptions. Don't hesitate to follow-up with an additional issue if necessary.