Mobile image upload turns sideways


(TomG) #16

Bit more googling suggests that Samsung devices handle rotated images differently, although I haven’t found a good source to confirm.

Seems like non-samsung devices might handle image orientation by simply switching X and Y, i.e. actually taking a landscape image as landscape.

Samsung devices apparently take all images with the same X and Y and then tag landscape ones with the relevant EXIF info.

So it seems like the issue here is actually a Discourse one as it really should be honouring EXIF orientation metadata.

@Roy_ILGM if you could post the same S8 image twice, once with untouched EXIF and one with the Image Orientation field set to blank then that might be proof enough to ask for it to be looked at.


(Joffrey Jaffeux) #17

@Roy_ILGM can you upload an unaltered image on s3 or something like this so we can reproduce this easily ?


#18

@joffreyjaffeux @hutchinsfairy


(Joffrey Jaffeux) #19

no it’s not what I mean :slight_smile: you need to upload it outside of discourse and give us the url please.


#20

For this one I “emptied” the image orientation field using Edit EXIF, IPTC, XMP data in JPEG photo online - IMG online


#21

@joffreyjaffeux And here’s one I uploaded to google drive from my device

https://drive.google.com/open?id=0B_oW0mBNwjf4MThGODFpQ3lPaG8


(Mittineague) #22

Back in 2014 there was a discussion about the EXIF “leaking” location being a privacy concern. AFAIK, the decision was to remove all EXIF data

Remove location EXIF data from uploaded photos

There was somewhat more recent discussion about adding EXIF data but l don’t know if anyone has done any work in that direction

Add EXIF data of the uploaded photo


(TomG) #23

Could the image be rotated according to the EXIF instructions prior to scrubbing?


(Régis Hanol) #24

It is rotated according to the EXIF prior to scrubbing all the metadata :wink:


(Christoph) #25

Really? All metadata? So people cannot specify their copyright or creative commons license?


(Scott Smith) #26

I am getting some complaints on my forum recently about this as well, and I had the same problem on my S6 recently. One forum user pointed out the following:

It’s related to a camera setting “Tag Locations” that I had turned off a few weeks back. I didn’t like the idea of my GPS coordinates being attached to my photos as Exif data. So I turned off the Tag Location feature. Apparently, the feature adds more than just lat/long coordinates. It must add other data such as photo orientation, shutter speed, etc.

Basically advanced users might turn this option off since it sounds like it is leaking security information. I must have done the same thing as I also started losing rotation information on uploads.

I don’t think anything can be done about this on the Discourse side if the EXIF rotation data was removed prior to upload. Maybe file a bug report with Android? They should either rotate before upload or keep that EXIF information on. This user has an LG G6 phone, the problem may be with Nougat.


(Régis Hanol) #27

I don’t understand. If there is no orientation information in the image, then there is nothing to fix.

Would you mind uploading the original image that appears broken in Discourse on any file hosting service so that I can check it out?


(Scott Smith) #28

Yes, I expect there is no orientation information in the image when uploaded from the phone and I don’t think anything on the Discourse side can be done to fix it.

If I copy the image off the phone it keeps the EXIF, it seems only in an upload via whatever library the phone browser is using (Chrome in my case) will there be problems. I just tried using the Drobox webpage from the phone to upload an image and interestingly the rotation information was not wiped then.

I will put an image up with full EXIF and PM you the link. My GPS wiper seems to also wipe the rotation info.


(TomG) #29

If you image has some EXIF rotational data in it then the location data setting is surely a red herring.

The OP has posted the same image with and without rotational data and the two images appear indentical to me, suggesting that the data is not being acted upon.

It seems unlikely to be a browser upload issue as I believe the OP is using an online editor to view the data. Should be easy to test either way.

@joffreyjaffeux did you get a chance to try recreate the issue with file provided by the OP?


(Scott Smith) #30

The problem with the OP’s file is it was uploaded to Picasa which stripped all the EXIF information off. Its a pain to figure out whats going on due to this kind of issue.

I looked into this a bit more and found the following good overview site:

http://www.daveperrett.com/articles/2012/07/28/exif-orientation-handling-is-a-ghetto/

The particular problem I am having on my phone uploads is with the case where the image orientation value is 6 (see the above link where they show all the values and what they mean). The above link has test images to try out and interestingly the tests all work on Discourse so generally Discourse is doing very well (you will see on the above page that many very well-known sites are screwing it up, including Github itself).

I PM’d @zogstrip with an image and have not heard back from him on it. Here is my image as it uploads to discourse:

It is clearly broken, it is 90 degrees ccw from what it should be and the cropping is also backwards (click to get the large version to see that). Here is the image EXIF on the original image:

exiftags -iv 20170603_164907.jpg 
Image-Specific Properties:

Image Width: 5312
Image Height: 2988
Image Orientation: Right-Hand, Top
Horizontal Resolution: 72 dpi
Vertical Resolution: 72 dpi
Image Created: 2017:06:03 16:49:07
Exposure Time: 1/60 sec
F-Number: f/1.9
Exposure Program: Normal Program
ISO Speed Rating: 200
Lens Aperture: f/1.9
Brightness: 1.7 EV
Exposure Bias: 0 EV
Metering Mode: Center Weighted Average
Flash: No Flash
Focal Length: 4.30 mm
Color Space Information: sRGB
Image Width: 5312
Image Height: 2988
Exposure Mode: Auto
White Balance: Auto
Scene Capture Type: Standard
Unique Image ID: B16LSIA00SM B16LSJL02SM_
Time (UTC): 20:49:07
Date (UTC): 2017:06:03

Other Properties:

Resolution Unit: i
Chrominance Comp Positioning: Centered
Exif IFD Pointer: 238
Image Width: 480
Image Height: 272
Compression Scheme: JPEG Compression (Thumbnail)
Image Orientation: Right-Hand, Top
Horizontal Resolution: 72 dpi
Vertical Resolution: 72 dpi
Resolution Unit: i
Offset to JPEG SOI: 1146
Bytes of JPEG Data: 24522
Exif Version: 2.20
Image Generated: 2017:06:03 16:49:07
Image Digitized: 2017:06:03 16:49:07
Shutter Speed: 1/60 sec
GPS Info Version: 2.2.0.0
Latitude Reference: N
Longitude Reference: W
Altitude Reference: 0

(only GPS info removed from the above)

The above reference site has the following analogous image, taken with more width than height pixels and with an Image Orientation value of 6 (exiftags prints 6 as “Right-Hand, Top”.) The source image is at https://github.com/recurser/exif-orientation-examples/blob/master/Portrait_6.jpg:

– this one works on Discourse. Here are its EXIF tags:

exiftags -iv Portrait_6.jpg 
Image-Specific Properties:

Image Orientation: Right-Hand, Top
Horizontal Resolution: 72 dpi
Vertical Resolution: 72 dpi
Image Width: 600
Image Height: 450

Other Properties:

Resolution Unit: i
Exif IFD Pointer: 90

Notice this image has the same orientation, 6, as my failing image, and also has more width than height pixels. In other words, it looks like the same case. My image does have some oddities in the data however which could be messing up Discourse: it has three different versions of Image Width / Height, and it has two versions of Image Orientation. My guess is it has something to do with the duplicate versions of the Image orientation information, it is in “Other Properties” as well as being in “Image Properties”. I can’t seem to find an EXIF tags editor but my guess is if the Image Orientation tags were removed from Other Properties it would all work. And my guess is the rotation done by Discourse is getting un-done by this extra copy of the information.

EDIT: I found a better command-line tool, exiftool, and it gives a much better EXIF dump (and also supports editing once I figure it out). It turns out the other version of Orientation was for the thumbnail. Here is the full exiftool dump for my failing image:

$ exiftool -a -u -g1 20170603_164907.jpg
---- ExifTool ----
ExifTool Version Number         : 10.53
Warning                         : [minor] Unknown APP4 segment
Warning                         : [minor] Unknown APP5 segment
---- System ----
File Name                       : 20170603_164907.jpg
Directory                       : .
File Size                       : 5.3 MB
File Modification Date/Time     : 2017:06:20 14:24:02-04:00
File Access Date/Time           : 2017:06:20 14:30:08-04:00
File Inode Change Date/Time     : 2017:06:20 14:24:20-04:00
File Permissions                : rw-r--r--
---- File ----
File Type                       : JPEG
File Type Extension             : jpg
MIME Type                       : image/jpeg
Exif Byte Order                 : Little-endian (Intel, II)
Image Width                     : 5312
Image Height                    : 2988
Encoding Process                : Baseline DCT, Huffman coding
Bits Per Sample                 : 8
Color Components                : 3
Y Cb Cr Sub Sampling            : YCbCr4:2:2 (2 1)
---- IFD0 ----
Image Width                     : 5312
Image Height                    : 2988
Make                            : samsung
Camera Model Name               : SM-G928P
Orientation                     : Rotate 90 CW
X Resolution                    : 72
Y Resolution                    : 72
Resolution Unit                 : inches
Software                        : G928PVPU3DQC5
Modify Date                     : 2017:06:03 16:49:07
Y Cb Cr Positioning             : Centered
---- ExifIFD ----
Exposure Time                   : 1/60
F Number                        : 1.9
Exposure Program                : Program AE
ISO                             : 200
Exif Version                    : 0220
Date/Time Original              : 2017:06:03 16:49:07
Create Date                     : 2017:06:03 16:49:07
Shutter Speed Value             : 1/60
Aperture Value                  : 1.9
Brightness Value                : 1.73
Exposure Compensation           : 0
Max Aperture Value              : 1.9
Metering Mode                   : Center-weighted average
Flash                           : No Flash
Focal Length                    : 4.3 mm
User Comment                    : 
Flashpix Version                : 0100
Color Space                     : sRGB
Exif Image Width                : 5312
Exif Image Height               : 2988
Exposure Mode                   : Auto
White Balance                   : Auto
Focal Length In 35mm Format     : 28 mm
Scene Capture Type              : Standard
Image Unique ID                 : B16LSIA00SM B16LSJL02SM.
---- MakerUnknown ----
Unknown 0x0001                  : 0100
Unknown 0x0002                  : 73728
Unknown 0x000c                  : 0
Unknown 0x0010                  : undef
Unknown 0x0040                  : 0
Unknown 0x0050                  : 1
Unknown 0x0100                  : 0
---- IFD1 ----
Image Width                     : 480
Image Height                    : 272
Compression                     : JPEG (old-style)
Orientation                     : Rotate 90 CW
X Resolution                    : 72
Y Resolution                    : 72
Resolution Unit                 : inches
Thumbnail Offset                : 940
Thumbnail Length                : 24522
Thumbnail Image                 : (Binary data 24522 bytes, use -b option to extract)
---- Samsung ----
Time Stamp                      : 2017:06:03 16:49:07-04:00
---- Composite ----
Aperture                        : 1.9
Image Size                      : 5312x2988
Megapixels                      : 15.9
Scale Factor To 35 mm Equivalent: 6.5
Shutter Speed                   : 1/60
Circle Of Confusion             : 0.005 mm
Field Of View                   : 65.5 deg
Focal Length                    : 4.3 mm (35 mm equivalent: 28.0 mm)
Hyperfocal Distance             : 2.11 m
Light Value                     : 6.8

And here is the full dump for the Portrait_6 image that worked:

$ exiftool -a -u -g1 Portrait_6.jpg 
---- ExifTool ----
ExifTool Version Number         : 10.53
---- System ----
File Name                       : Portrait_6.jpg
Directory                       : .
File Size                       : 126 kB
File Modification Date/Time     : 2017:06:20 13:09:06-04:00
File Access Date/Time           : 2017:06:20 13:40:47-04:00
File Inode Change Date/Time     : 2017:06:20 13:09:06-04:00
File Permissions                : rw-r--r--
---- File ----
File Type                       : JPEG
File Type Extension             : jpg
MIME Type                       : image/jpeg
Exif Byte Order                 : Big-endian (Motorola, MM)
Image Width                     : 600
Image Height                    : 450
Encoding Process                : Baseline DCT, Huffman coding
Bits Per Sample                 : 8
Color Components                : 3
Y Cb Cr Sub Sampling            : YCbCr4:2:0 (2 2)
---- JFIF ----
JFIF Version                    : 1.01
Resolution Unit                 : inches
X Resolution                    : 72
Y Resolution                    : 72
---- IFD0 ----
Orientation                     : Rotate 90 CW
X Resolution                    : 72
Y Resolution                    : 72
Resolution Unit                 : inches
---- ExifIFD ----
Exif Image Width                : 600
Exif Image Height               : 450
---- Composite ----
Image Size                      : 600x450
Megapixels                      : 0.270

Here also is an upload of my image if you want to test for yourself, I used exiftool to remove only GPS: http://slant.com/pix/20170603_164907.jpg.

EDIT 2: OK, I think I have finally found the bug and it is in Discourse. The Portrait 6 image above is much smaller, it does not need to be scaled server-side by Discourse. The server-side scaling is the root of the problem. I confirmed this with an image which was a bit smaller and was within the limit I set on my own Discourse server but for which meta needed to scale (I have a bigger size limit than meta, 5MB). The image uploads properly to my server but fails on meta.


(Jeff Atwood) #31

Great thanks for that research, hopefully that gives @zogstrip something to work towards.


(Régis Hanol) #32

Just pushed a fix which adds the -auto-orient parameter to all our convert calls (which also means we don’t need a specific step to fix orientation anymore)


(Jeff Atwood) #33

We should backport that fix @zogstrip unless it is risky


(Régis Hanol) #34

:back: ported to stable & beta.


(Régis Hanol) #35

This topic was automatically closed after 24 hours. New replies are no longer allowed.