# Large image resize - why only 64% scaling at most?

**URL:** <https://meta.discourse.org/t/large-image-resize-why-only-64-scaling-at-most/38347>\
**Category:** Support\
**Created:** [January 22, 2016, 4:05pm UTC](https://meta.discourse.org/t/large-image-resize-why-only-64-scaling-at-most/38347 "2016-01-22T16:05:53Z")\
**Posts on this page:** 1\
**Showing post:** 5

<div class="post-metadata">

**Author:** ![scottfsmith](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/scottfsmith/32/50976_2.png) [@scottfsmith](https://meta.discourse.org/u/scottfsmith)\
**Post date:** [June 20, 2016, 2:54am UTC](https://meta.discourse.org/t/large-image-resize-why-only-64-scaling-at-most/38347/5 "2016-06-20T02:54:06Z")

</div>

Following up on my old post here.. I noticed after a recent update we were not getting any resizing to work. In looking at the code, there are a couple of recent commits to uploads\_controller.rb that look like it broke the resizing.

One is loop exit condition `break if downsized_size >= uploaded_size || downsized_size < max_image_size_kb` in fact always holds the first time through the loop since the first time through `downsized_size` is equal to `uploaded_size` (this condition can fire before the first resize). So, the resize code is currently unreachable and no resizing will ever happen.

Another issue is the 10mb hard coded constant was turned into

`maximum_upload_size = [SiteSetting.max_image_size_kb, SiteSetting.max_attachment_size_kb].max.kilobytes`

but the problem is a catch-22 arises with the line

` if 0 < uploaded_size && uploaded_size < maximum_upload_size && ...`

– if a resize is needed, uploaded\_size (size of actual upload initially) is probably bigger than SiteSetting.max\_image\_size\_kb (i.e. its too big and needs shrinking), but the above condition will often cause resizing to abort (it always does with the default settings for example).

To get around these glitches, I set max\_attachment\_size\_kb to 10mb in the admin panel, and also removed the condition `downsized_size >= uploaded_size` since it should never arise (or, maybe it should be just `>` to fix the initial loop bug). Since the maximum upload size is the bigger of max image/attachment size, this hack allows maximum\_upload\_size to be big compared to the image and allow the resize code to run.

Here is also some suggested code to do a bit more resizing, it uses a mini-table to figure out how much to resize. I tested this code on a development server with max\_image\_size\_kb at both 1000 and 3000, and max\_attachment\_size\_kb at 10000, and it worked OK and got big images down to 1MB ones. This code also has the faulty condition removed.

```
 break if downsized_size < max_image_size_kb # removed faulty >= condition here
            image_info = FastImage.new(tempfile.path) rescue nil
            w, h = *(image_info.try(:size) || [0, 0])
            break if w == 0 ||h == 0
            if downsized_size / 9 > max_image_size_kb
              downsize_ratio = 0.3
            elsif downsized_size / 3 > max_image_size_kb
              downsize_ratio = 0.6
            else
              downsize_ratio = 0.8
            end
            dimensions = "#{(w * downsize_ratio).floor}x#{(h * downsize_ratio).floor}"

```

In theory I could try to put in a PR on this, but first I don’t know Ruby and am Googling for every bit of syntax, and second I don’t know what the goal is here - the hard-coded 10MB was a useful limit it seems in terms of what size uploaded was even allowed by the browser, but I’m not sure where it went in the design space.

---

_[View the full topic](https://meta.discourse.org/t/large-image-resize-why-only-64-scaling-at-most/38347)._