Forum

Thread tagged as: Problem, Error

Image EXIF data error

It seems that Perch is bailing (PHP warning) when PHP can't read the EXIF data on an image.

It looks like Perch is looking for the image orientation on the images using the EXIF. PHP is trying to read the image data and producing a warning (because Adobe has stuck garbage in the EXIF data) which is causing Perch to bail, if the PHP error level is "turned up".

From my research, it seems there are 2 options: (1) suppress the PHP warnings (with an @) or (2) catch the warning with a try/catch. It seems that PHP still parses usable EXIF data, at least when suppressing the warnings – that'd be the method I'd probably go with. Of course you could also detect display errors or the error level and figure it out from there.

One of the images we've had a problem with https://www.pypa.ca/perch/resources/speaker-2-e.jpg The image was exported out of Photoshop using the Export As function. I've reproduced it with a number of images from different sources, but all using the PS Export As function.

We are using Perch 3.0.8 with PHP 7.1.8 with PERCH_PRODUCTION_MODE set to PERCH_DEVELOPMENT.
Darryl Hein

Darryl Hein 0 points

  • 4 years ago
Lexi McGee

Lexi McGee 3 points

4 years ago

We have the same error. Seems like this was fixed a month or so ago. https://bugs.php.net/bug.php?id=72819

Commit https://git.php.net/?p=php-src.git;a=commit;h=e6903d471e45177c248adfb4f1abdfdd5487d7bf
Drew McLellan

Drew McLellan 2638 points
Perch Support

4 years ago

What's the full warning you're getting?
Darryl Hein

Darryl Hein 0 points

4 years ago

Here is the full error:

[Mon Aug 14 18:18:54 2017] [error] [client [...]] FastCGI: server "/dev/shm/site-php.fcgi" stderr: PHP message: PHP Fatal error:  Uncaught Symfony\\Component\\Debug\\Exception\\ContextErrorException: Warning: exif_read_data(phpqFVN4U): Incorrect APP1 Exif Identifier Code in [...]html/perch/core/lib/PerchImage.class.php:534, referer: https://[...]/perch/core/apps/content/edit/?id=16
[Mon Aug 14 18:18:54 2017] [error] [client [...]] FastCGI: server "/dev/shm/site-php.fcgi" stderr: Stack trace:, referer: https://[...]/perch/core/apps/content/edit/?id=16
[Mon Aug 14 18:18:54 2017] [error] [client [...]] FastCGI: server "/dev/shm/site-php.fcgi" stderr: #0 [...]html/perch/core/lib/PerchFieldTypes.class.php(1159): PerchImage->orientate_image('/tmp/phpqFVN4U'), referer: https://[...]/perch/core/apps/content/edit/?id=16
[Mon Aug 14 18:18:54 2017] [error] [client [...]] FastCGI: server "/dev/shm/site-php.fcgi" stderr: #1 [...]html/perch/core/apps/assets/modes/upload.pre.php(34): PerchFieldType_image->get_raw(), referer: https://[...]/perch/core/apps/content/edit/?id=16
[Mon Aug 14 18:18:54 2017] [error] [client [...]] FastCGI: server "/dev/shm/site-php.fcgi" stderr: #2 [...]html/perch/core/apps/assets/upload/index.php(23): include('/chroot/home/...'), referer: https://[...]/perch/core/apps/content/edit/?id=16
[Mon Aug 14 18:18:54 2017] [error] [client [...]] FastCGI: server "/dev/shm/site-php.fcgi" stderr: #3 {main}, referer: https://[...]/perch/core/apps/content/edit/?id=16
[Mon Aug 14 18:18:54 2017] [error] [client [...]] FastCGI: server "/dev/shm/site-php.fcgi" stderr: Next LogicException: Request stack is empty in [...]vendor/symfony/symfony/src/Symfony/Component/HttpKernel/HttpKernel.php:99, referer: https://[...]/perch/core/apps/content/edit/?id=16
[Mon Aug 14 18:18:54 2017] [error] [client [...]] FastCGI: server "/dev/shm/site-php.fcgi" stderr: Stack trace:, referer: https://[...]/perch/core/apps/content/edit/?id=16
[Mon Aug 14 18:18:54 2017] [error] [client [...]] FastCGI: server "/dev/shm/site-php.fcgi" stderr: #0 [internal function]: Symfony\\Component\\HttpKernel\\HttpKernel->terminateWithException(Object(Symfony\\Component\\Debug\\Exception\\ContextErrorException)), referer: https://[...]/perch/core/apps/content/edit/?id=16
[Mon Aug 14 18:18:54 2017] [error] [client [...]] FastCGI: server "/dev/shm/site-php.fcgi" stderr: #1 /chroot/ho..., referer: [...]/perch/core/apps/content/edit/?id=16

Note: we are using Symfony for authentication, so that's why there's some Symfony "stuff" in there and why display errors/etc is turned on.
Drew McLellan

Drew McLellan 2638 points
Perch Support

4 years ago

Do you have mbstring enabled?
Darryl Hein

Darryl Hein 0 points

4 years ago

Yes we do.

From the link Lexi posted, it seems like it's a PHP bug, but a bug that's causing the script to bail (without any messages).
Drew McLellan

Drew McLellan 2638 points
Perch Support

4 years ago

I've added an option to complete disable EXIF for servers where it's causing a problem.
Darryl Hein

Darryl Hein 0 points

4 years ago

Is the EXIF data only used for determining if the image should be rotated?
Drew McLellan

Drew McLellan 2638 points
Perch Support

4 years ago

Yes. When it's disabled Perch will revert to the old Perch 2 behaviour of assuming the user can upload a photo that's already the right way up! :)
Darryl Hein

Darryl Hein 0 points

4 years ago

Okay.

See below before implementing this!

I think I'll implement a hack (ie, manual code edit) in this situation as I'd rather have most images be properly rotated automatically (provided PHP can read the EXIF data) for customers vs have support calls for that.

If anyone is looking for what that manual edit is:

As of Perch 3.0.8, in core/lib/PerchImage.class.php, add an @ before exif_read_data on line 534, as such:

$exif = @exif_read_data($file_path);
Drew McLellan

Drew McLellan 2638 points
Perch Support

4 years ago

That's a bad idea, certainly not recommended. We also don't offer support to anyone who has hacked core files.
Darryl Hein

Darryl Hein 0 points

4 years ago

Why is it a bad idea – please explain. I agree that editing core files is a bad idea and annoying/painful, but unfortunately the code is not written such that it's easy to override parts like this in outside libraries/functions/classes.

The image/EXIF code is setup otherwise to just continue as though there's no EXIF data so it literally does nothing if it fails to read some or all of the EXIF data, provided PHP doesn't cause an error. And, in this situation, it may actually find the orientation data and rotate the image, even if PHP can't read all the EXIF data – a great user experience.
Drew McLellan

Drew McLellan 2638 points
Perch Support

4 years ago

PHP functions don't throw exceptions, so there's nothing to catch. Suppressing errors is bad practise, undebuggable and incredibly slow.

But I'm not going to spend time debating with you various ways of you hacking the software and invalidating your license for reasons that should be obvious.
Darryl Hein

Darryl Hein 0 points

4 years ago

I have done some more testing/searching/reasoning...a few things:

1) This is a bug in PHP, not in Perch, though it happens to "break" Perch. (Unfortunately it seems PHP will break in a number of circumstances with EXIF data it doesn't understand.) 2) To break Perch, error reporting must be in "development" mode (ie, display errors, error reporting, plus probably an error handler that outputs errors). On production sites, this won't be the case and the warning is handled much more gracefully (you won't get a 500 error or blank page and the image will be uploaded successfully, but won't be rotated).

In the end, seems like reading EXIF data can be brittle. Looks like others use the error control (ie https://github.com/avalanche123/Imagine/blob/develop/lib/Imagine/Image/Metadata/ExifMetadataReader.php#L97), I'm guessing with the thought that it's only needed once and it won't be run often (ie, not on every request, only when the image is uploaded).

Thanks for your time Drew and sorry to be a pain. Thanks Lexi for posting the link to the PHP bug.
Lexi McGee

Lexi McGee 3 points

4 years ago

This is mine

PHP Warning:  exif_read_data(image.jpg): Illegal IFD size in /var/www/html/perch/core/lib/PerchImage.class.php on line 534