Images EXIF issue (PW 3)

[tpr]

When I upload an image that has an EXIF orientation data, it displays rotated in the admin (that is, it seems to have the right orientation).

However when I echo it on the page (frontend) the item display non-rotated, that is the EXIF orientation is not applied. First I thought that I just crop it a bit and it will show up fine, but unfortunately after the crop a portrait image is turned into a landscape image, cutting off most of its area.

I could remove the EXIF and rotate the images into the right position before the upload but unfortunately it's the client who does the upload.

Is there something I could do, or is this a bug?

Btw, is there a way to rotate an image in the admin?

[horst]

What exactly is displayed in the right orientation in the admin?

Expected behave is:

• original image with wrong orientation shows up as is, with wrong orientation
• every variation, even a copy of the original image, just with a setting for a lower quality, shows up corrected! *

* this only works if:

• correct exif orientation information are embedded in the original image
• the server supports reading exif information

 

If it does behave other than above, what exactly is the upload and manipulation process? (inkl. which image field is involveld, other modules that are hooked into upload ??)

[tpr]

You're right, the original image display with wrong orientation in the admin.

Every variation shows up corrected: true

However, applying a crop results in an upside down and incorrectly cropped image.

Here is the image in question - I don't know if its EXIF is correct or not. Tried it on two different servers and results are the same (PHP 7, imagick is available and used, function_exists('exif_read_data') returns true).

There are no image related modules installed, only IMagick Image Sizer.

Original image:

https://dl.dropboxusercontent.com/u/17407690/20160831_085238-original.jpg

Cropped (removed only a few pixels from each sides):

https://dl.dropboxusercontent.com/u/17407690/20160831_085238-cropped.jpg

PW infos:

Spoiler

ProcessWire: 3.0.36
PHP: 7.0.11
Apache: Apache
MySQL: 5.5.52-cll-lve

allow_url_fopen: 1
max_execution_time: 120 (changeable)
max_input_nesting_level: 64
max_input_time: 120
max_input_vars: 1000
memory_limit: 128M
post_max_size: 64M
upload_max_filesize: 64M
xdebug: 
xdebug.max_nesting_level: 

mod_rewrite: 1
mod_security: 

GD: bundled (2.1.0 compatible)
GIF: 1
JPG: 1
PNG: 1

EXIF Support: 1
FreeType: 1
Imagick Extension: 1

AdminOnSteroids: 0.7.7
AdminRestrictBranch: 0.3.9
BatchChildEditor: 1.3.8
EmailObfuscation: 1.0.4
FieldtypeAssistedURL: 1.0.0
FieldtypeRepeaterMatrix: 0.0.3
FieldtypeTable: 0.1.3
FrontEndEditLightbox: 1.3.4
InputfieldAssistedURL: 1.0.1
InputfieldRepeaterMatrix: 0.0.3
InputfieldTable: 0.1.3
MarkupSEO: 0.8.7
MarkupSrcSet: 0.0.7
PageRenameOptions: 0.3.2
PageimageRemoveVariations: 0.0.3
PrevNextTabs: 0.0.5
ProcessChildrenCsvExport: 1.3.8
ProcessHannaCode: 0.2.0
ProcessLoginHistory: 1.2.8
ProcessLoginHistoryHooks: 1.1.2
ProcessMigrator: 0.6.9
ProcessTemplateEditor: 1.6.1
ProcessWireUpgrade: 0.0.7
ProcessWireUpgradeCheck: 0.0.7
TemplateLatteReplace: 0.2.1
TextformatterHannaCode: 0.2.0
TextformatterMultiValue: 1.3.4
TextformatterVideoEmbed: 1.1.1
TracyDebugger: 3.3.8
NetteFormsHelper: 0.2.3
AutoSmush: 0.8.0

 

[netcarver]

@horst

A quick question on a related note, does EXIF data get stripped from variations when they are produced? I guess this might depend on the method used (CroppableImage3 etc)

[horst]

1 hour ago, netcarver said:

@horst

A quick question on a related note, does EXIF data get stripped from variations when they are produced? I guess this might depend on the method used (CroppableImage3 etc)

Yep, GD-lib doesn't support any Image-Markers. Every thing get stripped. But in times where everyone tries to decrease page- and imagesizes, I think this is good. You always can access the EXIF of the original image. And to be consistent across different ImageREnderingEngines, the default is to strip all markers, but not IPTC(!). That's because IPTC will not be available in an image until someone has explicitly added it, not like with EXIF.

 

@tpr: thanks! And yes, this is known to be an issue. It is an issue of the croptool(s). I remember that there were dev testing from Ryan and others, on how to solve this. But until know, nothing went into the code base.

Every visually editor, like the crop tool or CroppableImage3, should detect the needed orientation correction and behave accordingly.

ATM, all of those tools

• display the images uncorrected,
• determine the correct crop positions and dimensions,
• pass that to the imagesizer,
• imagesizer first detect wrong orientation and swap width / height
• but not for the passed crop positions / dimensions

That results in totally wrong crops.

What we need here is a standardized way to

• A) display wrong orientated orig. images corrected via CSS or JS in the cropping tools,
• B) a calculation function that can swap those "wrong" calculations to apply correct for orientation corrected images.
  Should this calculation be called by the cropping tools, before they pass the positions to imagesizer, or should they simply add a flag to show imagesizer to apply that calculation too with the orientation correction?

A year back, I have experimented a bit with CSS  transform: rotate(90deg), but lost the focus on it.

[flod]

Any news on that? In my case, the problem is still there.

[horst]

Cropping now can be done via a focus point, directly in the core image fields: https://processwire.com/blog/posts/pw-3.0.89/