Unable to preserve image resolution

[stromb0li]

Affected version

2.3.7

In 2.3.x, it appears images are always resized client side prior to upload, even if under attachments, we set image optimization to "Do not optimize".

If I take a 300 dpi image that is about 20MB and upload, it is compressed down to about 2MB (which is great for those that don't want the original images), and then depending on your image processor, the DPI is stripped to the default value: it looks like the PHP built-in GD image library defaults to 96 dpi and Imagick defaults to 72 dpi upon upload; altering the photo.

Our use-case is we allow submission of photos for publication, but when uploaded via XenForo, the original file is altered.

Given we have "Do not optimize" enabled, our expectation is the client would not compress the image prior to upload and the original resolution / dpi of the image would be retained.

 

[beerForo]

If you have size restrictions set, and it resizes the image, it also optimizes, I believe at 85%. So the file size will be a lot smaller based on size and optimization.

 

[stromb0li]

In Admin CP, we left the restrictions blank and also tried setting as 0 and still saw compression applied to the images.

 

[beerForo]

If size is blank and webp is off yeah, that's a strange one.

 

[stromb0li]

Per the HYS threads back when 2.3 was released, I also read this.

As a developer, if you wish to opt-out of this behaviour for any reason, you can do so with the following one-liner:

$upload->setImageOptimize(false);

I've tried the following and still see the image compressed to the 2.1MB filesize.

...
    
                $upload = $this->request->getFile('upload', false, false);
                if ($upload)
                {
                    $upload->setImageOptimize(false);
                    $attachment = $manipulator->insertAttachmentFromUpload($upload, $error);
                    if (!$attachment) return $this->error($error);

...

 

[stromb0li]

Sorry to bubble this up, but does anyone have any ideas on a workaround for this, even if it's a crude hack?

 

[Kirby]

This is most likely caused by image rotation, if the original image needs rotation according to its EXIF data the XenForo HTTP upload will rotate it before it is passed to downstream components (attachments, profile banner, avatar).
This unavoidably causes receencoding the image after rotation.

It is not possible to turn this behaviour off, you would have to patch the code or use an Add-on so uploads for attachments are not initially rotated but instead are only rotated to generste thumbs.

 

[stromb0li]

I'm fairly certain this is a javascript bug. When webp is disabled, you can see the original blob image size is correct when the browser tries to attach (in my case, a 20MB image):


When upload actually happens, you can see the original client image payload is compressed to 3.3MB:


When image optimize is set to false, I think client side that value is not actually being honored client side in 2.3.x

 

[Kirby]

Yep, I think you're right.

You can try the following template modification
In helper_js_global, find <xf:corejs /> and add

<xf:if is="contains(array_keys($xf.app.templater.getIncludedJs())|join(','), 'xf/attachment_manager')">
<xf:js>
XF.AttachmentManager = XF.extend(XF.AttachmentManager,
{
    __backup: {
        'init': 'noImagesResizeInit',
    },

    init () {
        this.noImagesResizeInit();
        this.options.resizeImages = false;
    }
});
</xf:js>
</xf:if>

below that.

 

[stromb0li]

That did it!!!