Processing input via POST /ob/images causes images to become rotated

[placer14]

Report from @drwasho indicates that the POST /ob/images endpoint either persists the rotated image or persists the original image yet returns a rotated image. Whichever the case, the response should be consistent with the original image.

[placer14]

Attempted the following request against a local node using my graphic of choice:
(echo -n '[{"filename": "filename.png","image": "'; base64 ~/Desktop/tmp/sanic-little-steps.jpg; echo '"}]') | curl -H "Content-Type: application/json" -d @- 0.0.0.0:4002/ob/images

Which provided the following response:

[
    {
        "filename": "filename.png",
        "hashes": {
            "large": "QmQsWqKvYAMtUoKWim8f1axPYaUpwkH8yFJosL5Y7rHjWs",
            "medium": "QmdWJaxYVr1xJ8YduBoXtEuVNU5HKHQF58A2rTtBodzW4T",
            "original": "QmQkizhW5JUhCGhSNgnEMn5ySRBYAiuC1Xzh7shK32xYQV",
            "small": "QmZoPMNeSk5QWKwzjRSL2z8nKxMBBknW6Z9TobP6ZvLaAi",
            "tiny": "QmWXpJwaN4ZsKH7DQPZeuBa5167vzP2KmDQWXCLSdQuLbT"
        }
    }
]

Which looks normal when returned by the gateway: https://gateway.ob1.io/ob/images/QmQkizhW5JUhCGhSNgnEMn5ySRBYAiuC1Xzh7shK32xYQV

All seems fine to me.

[placer14]

I was provided with an example case (which involves a JPG) that causes this issue described above. Steps to reproduce.
Using

1. Download file to local filesystem.
2. Start latest master of ob-go.
3. POST the base64-encoded representation of the file to the daemon using the following:

(echo -n '[{"filename": "pic.jpg","image": "'; base64 ./<pathto>/pic.jpg; echo '"}]')  | curl -H "Content-Type: application/json" -d @- 0.0.0.0:4002/ob/images

4. Note the hash of the Original value in the response and load the image on the gateway: https://gateway.ob1.io/ob/images/<hashofcontent>
5. Note that it is rotated from the input.

[placer14]

After examining the ingress of this data and that the encoding really doesn't change as it's processed through, I began looking at the inherent state of the file (because this problem does not occur on all files equally). After taking some additional pictures using an android devices in various orientations, it appears that the EXIF data impacts how these files are interpreted in most GUIs despite the underlying data being different to what's presented. So while the data always "appears" to be right-side up in various utilities, these values are being stripped when processed through the daemon and forced into their natural orientation after processing. ...ultimately, this is the result of golang not considering the EXIF data and expecting this consideration to be handled manually before processing. After understanding the problem, the existing issues were much easier to find around this. (See: golang/go#4341)

Investigating how this can be properly handled in the face of the stdlib's disregard for that metadata.

[jjeffryes]

@placer14 sorry, I should have jumped in here earlier. We had this same issue in the desktop client long, long ago.

This is what we do:

1. detect the orientation from the file when it is uploaded.
2. use that to transform the image data to have the correct orientation.
3. send the transformed image data to the server without any EXIF data.

If the Haven client did the same thing it should work fine. The code is in the onChangePhotoUploadInput method of the views.modals.editListing.EditListings.js file in the desktop repo.

[placer14]

Too little, too late. Nevertheless, after this fix you should be able to simplify the desktop client. 🍻