Rocket.chat: Image rotation leads to quality loss

[stleitner]

Description:

Big images are changed/scaled/manipulated during upload

Steps to reproduce:

1. Drag image file (6000x4500 pixels; 300dpi; RGB; 4.2 MB) in chat (OSX or Firefox browser)
2. Download file from chat

Expected behavior:

File is not changed/scaled/manipulated (I know it does not save bandwidth, but it breaks our processes)

Actual behavior:

Downloaded image is not the same (6000x4500 pixels; 72dpi; RGB; 0.5 MB). In the server file system the file size is 0.5MB

Server Setup Information:

• Version of Rocket.Chat Server: 0.66.2
• Operating System: Ubuntu
• Deployment Method: snap
• Number of Running Instances: 1
• DB Replicaset Oplog:
• NodeJS Version: v8.11.3
• MongoDB Version: v3.0.15

Additional context

Is there an configuration option for this? Account preferences -> save mobile bandwidth = false does not change anything

Relevant logs:

There are no messages on the browser console.

[reetp]

I have a feeling there has been a lot of messing around with compressing images and you may have been caught with this.

There was a specific bug I read that might have explained this, but of course now I want it, I can't find it. Have a look for in bugs for 'compress' or 'image'

I think the problem is that some want big images compressed for speed, and some don't. Depending on usage. However, I think the defaults have been changed to force compression for all images now.

"Save bandwidth" I think only affects images downloaded to mobile.

[stleitner]

I found this one https://github.com/RocketChat/Rocket.Chat/issues/1988 but there is no reference for this feature.

I built a patch with a setting option to disable scaling on upload:
https://gist.github.com/stleitner/f379621c4e474e37aecdf979b77bc9d0

[Impamark]

Try a merge request - seems a great idea.....

[thepowerprocess]

I am still getting this when I upload from Android app.

[stleitner]

It is not in the master version, yet. I open a pull request and @tassoevan requested a review from @sampaiodiego and @engelgabriel added it to the September milestone , but there is no progress.

Checks show:

ci/circleci: build-and-test/hold Pending — Your job is on hold on CircleCI!

[reetp]

Can we bump this?

Another Merge request languishing about.

[sampaiodiego]

sorry guys for letting this unanswered.

I don't know at that time (at version 0.66.2) but we don't resize image uploads, we only rotate them, we do resize only avatars (and there is a setting for it already).

as @cloudsandladders mentioned though our mobiles apps do resize images, but there is nothing we can do from this side. Please feel free to open an issue there https://github.com/RocketChat/Rocket.Chat.Android or https://github.com/RocketChat/Rocket.Chat.iOS

[stleitner]

@sampaiodiego : in 0.73.2snap images are still "optimized"/manipulated on upload when using the browser (Firefox 65).

Uploaded image: (6000x4500 pixels; 300dpi; RGB; 4.2 MB; Quality 99%)
Downloaded image: (6000x4500 pixels; 72dpi; RGB; 0.5 MB; Quality 73%)

[sampaiodiego]

sry @stleitner but I cannot reproduce it, tried on Firefox 65 as well.

I'll have to try the snap image, but I don't think I'll get different results.. in any case, can you describe what are your file upload storage preferences? have you tried using uploading via REST API (to make sure it's nothing on your browser that is doing that)

[sampaiodiego]

I was using this image to test btw https://en.wikipedia.org/wiki/File:Pizigani_1367_Chart_10MB.jpg

[stleitner]

You are right, this has a JPEG quality of 29% and it is not manipulated. It seems that there is a minimum quality for images which are manipulated (more than 86%), below this they are not manipulated.

Try this one (99% quality): https://upload.wikimedia.org/wikipedia/de/6/6c/Fanta_zero_logo_300dpi.jpg

This one is not manipulated (86%):
https://upload.wikimedia.org/wikipedia/commons/a/a3/Wyclefjean2_%28300dpi%29.jpg

[stleitner]

My file upload storage preferences:

File Uploads Enabled: True
Maximum File Upload Size (in bytes): 2097152000
Accepted Media Types: all
Protect Uploaded Files: True
Only authenticated users will have access
Storage Type: Filesystem
File Uploads Enabled in Direct Messages: True

[stleitner]

using Safari 12.0.3 and Chrome 72, the image is also manipulated

[sampaiodiego]

thanks @stleitner .. we found the issue is actually there is a Orientation data on the EXIF and because of that we rotate the image which then make it lose quality.

see:

16:27:38 ✔ diegosampaio:/tmp$ exif Fanta_zero_logo_300dpi.jpg 
EXIF tags in 'Fanta_zero_logo_300dpi.jpg' ('Motorola' byte order):
--------------------+----------------------------------------------------------
Tag                 |Value
--------------------+----------------------------------------------------------
Orientation         |Top-left
X-Resolution        |300,0000
Y-Resolution        |300,0000
Resolution Unit     |Inch
Software            |Adobe Photoshop CS4 Macintosh
Date and Time       |2012:09:25 10:36:22
Compression         |JPEG compression
X-Resolution        |72
Y-Resolution        |72
Resolution Unit     |Inch
Color Space         |Internal error (unknown value 65535)
Pixel X Dimension   |1000
Pixel Y Dimension   |1000
Exif Version        |Exif Version 2.1
FlashPixVersion     |FlashPix Version 1.0
--------------------+----------------------------------------------------------
EXIF data contains a thumbnail (11923 bytes).

so we'll have to find the proper fix for it.. we'll need to still rotate images (to show them on the correct orientation) but not losing quality.

[sampaiodiego]

I have updated issue title to reflect the atual issue.

[stleitner]

I can confirm that our original test image also has orientation information attached

[stleitner]

we'll need to still rotate images (to show them on the correct orientation) but not losing quality.

My opinion is that the file should not be manipulated at all. Only make manipulations on thumbnail files or make manipulations as an option (see my merge request) or rotate the image in frontend (css transform:rotate(x)). Everybody should know that the files are changed, to avoid searching error sources in the workflow!

[stleitner]

Any updates on this issue?

[stleitner]

@sampaiodiego is there a way to get a solution for this problem soon? Would a renamed settings option (e.g. Disable JPEG rotation) of my previous settings option be able to make it in the master branch, or isn‘t it worth the effort?
I‘m not deep enough in the rocket chat programming to provide a solution for the complete problem. But the settings option would provide a solution for these who have this problem.

[sampaiodiego]

I'm sorry the lack of response.

thinking on a final solution for this, I'm not sure this should be an admin option (applied to all uploads within the server) or a personal option selected during the upload.

also need to test if the browser (and mobile apps) respects the orientation metadata to display the image orientation correctly (if not fixed during upload)..

and the last thing about the pull request you sent last time, we still would like to have that identify information, that's one of the reasons you cannot abort that early..

we unfortunately doesn't have time to look into this scenarios right now, but I could evaluate a PR again.

[stleitner]

@sampaiodiego I viewed the app/file-upload/server/lib/FileUpload.js code again and figured out that even when EXIF info is present and the image has normal orientation(Top-left), the image rotation function is called unnecessarily.
I renamed the settings option and moved the abortion after the identity information reading. PR 15196

CSS image orientation is not working in all browsers yet: https://caniuse.com/#search=image-orientation , and even worse some mobile browsers (iOS Safari and iOS Firefox) are auto rotating based on EXIF without considering the CSS image orientation styles. CSS transform:rotate(x) style may be the only solution, but perhaps we need a fix for the mobile browsers.

[stleitner]

@sampaiodiego I addionally tested a different approach https://github.com/stleitner/Rocket.Chat/tree/exif-rotate which rotates the images using css transform in the frontend. This works good in the upload preview window and within the message embeded images, but it does not work with the photoswipe gallery. Photoswipe does not support EXIF orientation https://github.com/dimsemenov/PhotoSwipe/issues/725 and there is no built-in event to change dimensions after photoswipe recalculated the image dimensions, parseVerticalMargin is too early. It scales the images depending on raw image width/height before transformation, but not on how it is displayed. The images are rotated correctly but they are displayed too big or too small. Test images: https://github.com/recurser/exif-orientation-examples

Without another gallery library which supports EXIF or rewriting photoswipe, this is a dead end.

Another approach could be to rotate the image for the frontend at the backend and save it as a second file and provide the original image file for the download.