Issue description
When a user selects photos for upload in the form, or takes fresh ones with the camera, the photo is not always displayed correctly in Topincs depending on the client. This applies to the immediate display of the selected photo in the form (before the upload) and afterwards in the fact sheet. Another influencing factor is whether the photos are downscaled in the browser (to decrease upload duration) or not.
Developer comments
The user group where this behavior resurfaced is using iPhones exclusivly. The correct display of thumbnails in the form was implemented 2015 in Topincs 7.4.1 in [5526, issue 5526]. There is a nightly test using chromium that confirms that this is working and it never raised any attention.
The general behavior of Topincs is to leave the file as is and evaluate the orientation in EXIF by applying CSS classes which do the magic M1 causing images to be displayed correctly. When client side downscaling is active, the EXIF orientation is read and a new image is created. As it is anyway transformed, the magic M1 is performed in the creation of the new image together with the downscaling. The resulting file does not have any EXIF orientation.
The reason for the new problems is that browser vendors agreed to automatically transform the image, if EXIF orientation is present in the JPEG. In technical terms, the attribute value %from-image% becomes default for %image-orientation%. The behavior of most browser so far was to not apply any transformation, only exception was Safari. It is quite obviously a breach of a technical contract, even if it was an implicit one. This is unfortunate, as it creates tons of unnecessary work for everyone who implemented EXIF orientation application. How much work depends on how much you care about your users and how big the variety of their browsers is. In particular in-between stages where EXIF application in the browser is only present partially creates lots of headscratching.
Moderinzr offers detection of exif-orientation support in browsers. The test works by creating an %img%-Element, setting the %src%-Attribute to a data url which contains a JPEG which is encoded in landscape format, but due to the exif orientation of 6 it is intended to be displayed as a portrait. The encoded width is 2 pixel and height 1 px. If the browser evaluates and adheres to the EXIF orientation, the visible image should have a width of 1 pixel and a height of 2.
This works well on some browsers, but not all. There is false negatives. There is browsers which support it, but the test says it does not. This can be circumvented by adding the img-Element to the DOM. It is not necessary to measure the width of the client bounding rectangle. This was attempted (when deeply lost in the jungle), but did not contribute anything.
In addition an older Safari version (10.0.2) shows contradicting behavior. It applies the magic M1 sometimes, but not always. This causes downscaled images to be displayed incorrectly in the form, but non-downscaled images are ok. So far the issue was either present or not.
When dealing with this subject, i figured out which exif orientation code is set depending how the iPad is held when the photo is taken:
* 1: home button is to the right, landscape
* 3: home button is to the left, landscape
* 6: home button is on the bottom, portrait
* 8: home button is on the top, portrait
|
Work sessions2
Start |
2020-06-01T04:22:34
|
End |
2020-06-01T09:54:32
|
Participant |
Robert Cerny
|
Start |
2020-06-01T15:39:13
|
End |
2020-06-01T16:53:56
|
Participant |
Robert Cerny
|
|