Use ImageProcessing gem for ActiveStorage variants #32471

janko · 2018-04-06T00:38:28Z

ImageProcessing gem is a wrapper around MiniMagick and ruby-vips, and implements an interface for common image resizing and processing. This is the canonical image processing gem recommended in Shrine, and that's where it developed from. The initial implementation was extracted from Refile, which also implements on-the-fly transformations.

Some features that ImageProcessing gem adds on top of MiniMagick:

resizing macros
automatic orientation
automatic thumbnail sharpening
avoids the complex and inefficient MiniMagick::Image class
will use magick CLI instead of convert on ImageMagick 7 in the near future

However, maybe the biggest feature of the ImageProcessing gem is that it has an alternative implementation that uses libvips. Libvips is an alternative to ImageMagick that can process images very rapidly (we've seen up to 10x faster processing compared to ImageMagick).

What's great is that the ImageProcessing gem provides the same interface for both implementations. The macros are named the same, and the libvips implementation also does auto orientation and thumbnail sharpening; only the operations/options specific to ImageMagick/libvips differ. The integration provided by this PR should work for both implementations.

The PR should maintain almost 100% backwards compatibility; there are two incompatibilities:

users would now have to include the image_processing gem into their Gemfiles instead of mini_magick
:combine_options was removed because ImageProcessing::MiniMagick builds a single convert command, so it's not needed anymore

I know that Rails 5.2 is on feature freeze before the release, but I think if we agree we want ImageProcessing to be used for Active Storage, it's better to get it in now, due to the two mentioned backwards incompatibilities.

In short, Active Storage relying on ImageProcessing means it will have much better MiniMagick defaults, it will get libvips support for free (which is a big deal in terms of performance), it will get convenient resizing macros that work on both implementations, and it means the Active Storage project will have minimal maintenance in the image processing department.

rails-bot · 2018-04-06T00:38:31Z

Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @kamipo (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

This repository is being automatically checked for code quality issues using Code Climate. You can see results for this analysis in the PR status below. Newly introduced issues should be fixed before a Pull Request is considered ready to review.

Please see the contribution instructions for more information.

y-yagi · 2018-04-06T01:58:26Z

r? @georgeclaghorn

rafaelfranca · 2018-04-06T16:05:31Z

The shipt for Rails 5.2 has really sailed, no new features or changes that are not going to fix regression bugs are going to be introduced a this point.

It looks like we can implement this in a way that those two incompatibilities can be managed.

The gemfile change is not a problem. We can support the two backends in Rails 6.0, deprecating the old one.

We can also deprecate the combine_options option when the backend is image_processing.

In rails 6.1 we remove the support to mini_magick and we get all the benefits of image_processing.

Am I missing something why this can't wait to 6.0?

janko · 2018-04-06T18:03:59Z

You’re probably right, it should be doable later in the way you described. When I created the PR I thought Rails 5.2 was still in the beta phase, and thought it makes sense to squeeze it in.

Let’s then take the time to properly discuss it after 5.2 is released.

janko · 2018-04-14T08:05:44Z

I added backwards compatibility with the MiniMagick implementation and :combine_options. Let me know if there is anything else missing.

ImageProcessing gem is a wrapper around MiniMagick and ruby-vips, and implements an interface for common image resizing and processing. This is the canonical image processing gem recommended in [Shrine], and that's where it developed from. The initial implementation was extracted from Refile, which also implements on-the-fly transformations. Some features that ImageProcessing gem adds on top of MiniMagick: * resizing macros - #resize_to_limit - #resize_to_fit - #resize_to_fill - #resize_and_pad * automatic orientation * automatic thumbnail sharpening * avoids the complex and inefficient MiniMagick::Image class * will use "magick" instead of "convert" on ImageMagick 7 However, the biggest feature of the ImageProcessing gem is that it has an alternative implementation that uses libvips. Libvips is an alternative to ImageMagick that can process images very rapidly (we've seen up 10x faster than ImageMagick). What's great is that the ImageProcessing gem provides the same interface for both implementations. The macros are named the same, and the libvips implementation does auto orientation and thumbnail sharpening as well; only the operations/options specific to ImageMagick/libvips differ. The integration provided by this PR should work for both implementations. The plan is to introduce the ImageProcessing backend in Rails 6.0 as the default backend and deprecate the MiniMagick backend, then in Rails 6.1 remove the MiniMagick backend.

georgeclaghorn

Nice work, @janko-m! Thanks for your patience.

georgeclaghorn · 2018-04-20T15:01:49Z

activestorage/lib/active_storage/engine.rb

@@ -45,6 +45,7 @@ class Engine < Rails::Engine # :nodoc:
      config.after_initialize do |app|
        ActiveStorage.logger     = app.config.active_storage.logger || Rails.logger
        ActiveStorage.queue      = app.config.active_storage.queue
+        ActiveStorage.processor  = app.config.active_storage.processor || :mini_magick


The name of this configuration option is more generic than the feature it controls. Let‘s name it something like image_processor or variant_processor.

Good point, I chose variant_processor – f01e249

georgeclaghorn · 2018-04-22T17:12:25Z

activestorage/app/models/active_storage/variant.rb

+      download_blob_to_tempfile do |image|
+        variant = transform image
+        upload variant
+        variant.close!


transform generates the variant, so it can close the variant as well, and take care to do so even if uploading fails:

def process download_blob_to_tempfile do |input| transform image do |output| upload output end end end # ... def transform(image) format = "png" unless WEB_IMAGE_CONTENT_TYPES.include?(blob.content_type) result = variation.transform(image, format: format) begin yield result ensure result.close! end end

Agreed, updated in 0d811fd.

dixpac · 2018-04-23T08:14:45Z

activestorage/test/models/variant_test.rb

@@ -6,7 +6,7 @@
 class ActiveStorage::VariantTest < ActiveSupport::TestCase
  test "resized variation of JPEG blob" do
    blob = create_file_blob(filename: "racecar.jpg")
-    variant = blob.variant(resize: "100x100").processed
+    variant = blob.variant(resize_to_fit: [100, 100]).processed


Since you are maintainer of image_processing gem, is there a way to add resize in the gem.
If I understood well, inside image_processing gem resize_to_fit is resize from IM...just proposing this so there is no need to change all resize calls to resize_to_fit inside existing apps 😀

ImageProessing gem still supports all ImageMagick operations, the changes in tests and documentation are just to show/test the usage of macros. Any operation sent that is not a macro (#resize_to_fit, #resize_to_limit etc.) is interpreted to be an ImageMagick operation (via #method_missing).

So, with this change you still use :resize and any other ImageMagick operations, but you can also additionally use :resize_to_fit, :resize_to_limit and others.

Ahh, that makes sense 👍 ....not sure tho that we need change in documentations/guides then, for me
resize "100x100" feels nicer than resize_to_fit [100, 100], but this is just mine preference 😀

Yeah, in this particular case resize "100x100" is probably nicer. The difference shows in resize_to_limit [100, 100] which is resize "100x100>" (I find the > a bit cryptic), or resize_to_fill and resize_and_pad which are macros of multiple ImageMagick operations.

While we're here, we should probably recommend using resize "100x100>" (or #resize_to_limit), as when you physically enlarge an image that is smaller than specified dimensions, it will generally look worse than if you just display the unchanged image enlarged. That of course won't happen with thumbnails as small as 100x100, but it could with larger thumbnails.

What do you think?

Actually, then people would have to remember to add the width/height HTML attributes to the <img> tags. I'll just revert to using resize, and additionally show an example of using a resize_* macro.

Updated in 7fc8b6d.

This is not true anymore, the image will be downloaded into a temporary file in a streaming fashion.

janko · 2018-04-23T10:27:08Z

I also removed the comment that the image will be downloaded into memory, because that's not true anymore, even before this pull request. In both cases #download_blob_to_tempfile is used, which streams the file into disk.

janko · 2018-04-23T10:55:40Z

@dixpac Actually, I just remembered, one advantage of #resize_to_fit over #resize is that it also sharpens the thumbnail after resizing. You can see an example showing the difference in my blog post:

In short, when an image is resized, the algorithm will make the thumbnail appear a bit blurry compared to original (regardless of compression settings). That's why some image programs like Adobe Photoshop will automatically sharpen the image after resizing, and you can do the same with ImageMagick/libvips.

So, I think #resize_to_fit would be a better default.

dixpac · 2018-04-23T11:40:24Z

@janko-m that is a great point, I didn't know this.Thanks.
I thought that resize_to_fit is same as resize. So image_processing gem is automatically sharping the image. Indeed then resize_to_fit feels as better default then :)

Just curious, how much overhead sharpening adds over regular resize :)?

janko · 2018-04-23T17:05:36Z

Ok, I made some benchmarks. As expected, the sharpening overhead depends on the thumbnail size – the smaller the thumbnail is, the less time it takes to sharpen it. With ImageMagick I've observed the following for a 1600x900 source image:

800x800 – 1.87x slower
500x500 – 1.40x slower
300x300 – 1.18x slower
100x100 – 1.05x slower

For large source images the difference is naturally much smaller, as it takes more time to resize it and equal time to sharpen the resized image. But 1600x900 is probably a better average measure.

On libvips it doesn't go above 1.20x slower, on average it's only about 1.10x slower.

georgeclaghorn

Thanks, @janko-m! Here are a few more comments. This also needs a changelog entry.

georgeclaghorn · 2018-04-23T18:15:48Z

guides/source/active_storage_overview.md


-To enable variants, add `mini_magick` to your `Gemfile`:
+To enable variants, add `image_processing` gem to your `Gemfile`:


Add "the" before image_processing.

georgeclaghorn · 2018-04-23T18:16:22Z

guides/source/active_storage_overview.md

-You can pass any [MiniMagick](https://github.com/minimagick/minimagick)
-supported transformation to the method.
+To create variation of the image, call `variant` on the Blob. You can pass
+any transformation to the method supported by the procecssor. The default


Correct "procecssor" to "processor."

janko · 2018-04-23T19:28:09Z

@georgeclaghorn Done!

georgeclaghorn · 2018-04-23T20:01:50Z

activestorage/test/models/variant_test.rb

+    ensure
+      ActiveStorage.variant_processor = :mini_magick
+    end
+  end


This test is failing in CI:

Error: ActiveStorage::VariantTest#test_works_for_vips_processor: NoMethodError: undefined method `source' for #<String:0x00000000043b5728>

Can you take a look?

Fixed in f2e2cef. Requiring ruby-vips will raise a LoadError if libvips is not installed, and the #processor method was accidentally swallowing it.

We don't use `mini_magick` directly since rails#32471.

see also. rails/rails#32471

* 💎 Use image_processing gem see also. rails/rails#32471 * List resized image * Change image limit size: 500x500 → 700x700

rails-bot assigned kamipo Apr 6, 2018

janko force-pushed the use-image_processing-gem branch 2 times, most recently from c174e93 to 340080f Compare April 6, 2018 01:03

y-yagi added the activestorage label Apr 6, 2018

rails-bot assigned georgeclaghorn and unassigned kamipo Apr 6, 2018

janko force-pushed the use-image_processing-gem branch from 340080f to 8e618c9 Compare April 14, 2018 08:02

janko force-pushed the use-image_processing-gem branch from 8e618c9 to 1b2107f Compare April 18, 2018 15:38

janko force-pushed the use-image_processing-gem branch from 1b2107f to ca12968 Compare April 18, 2018 15:48

rafaelfranca requested a review from georgeclaghorn April 20, 2018 03:22

georgeclaghorn suggested changes Apr 22, 2018

View reviewed changes

janko added 2 commits April 22, 2018 23:40

Rename ActiveStorage.processor to .variant_processor

f01e249

Ensure result file is deleted on uploading errors

0d811fd

dixpac reviewed Apr 23, 2018

View reviewed changes

janko added 2 commits April 23, 2018 12:21

Show ImageProcessing macros in a dedicated example

7fc8b6d

Remove warning that image will be loaded into memory

e400916

This is not true anymore, the image will be downloaded into a temporary file in a streaming fashion.

Replace :resize_to_fit with :resize in the guide

dc97f6c

georgeclaghorn reviewed Apr 23, 2018

View reviewed changes

janko added 2 commits April 23, 2018 21:04

Recommend using :resize_to_fit after all

eef0bd0

Correct typos

7e4ad3f

Add CHANGELOG entry

151167e

georgeclaghorn reviewed Apr 23, 2018

View reviewed changes

Don't swallow LoadError raised for missing libvips

f2e2cef

georgeclaghorn approved these changes Apr 23, 2018

View reviewed changes

georgeclaghorn merged commit ef5902a into rails:master Apr 23, 2018

janko deleted the use-image_processing-gem branch April 23, 2018 21:28

utilum mentioned this pull request Apr 24, 2018

Segmentation fault in AR evented_file_update_checker_test #32705

Closed

tgxworld pushed a commit to tgxworld/rails that referenced this pull request Apr 24, 2018

Fix test method name

7e81541

We don't use `mini_magick` directly since rails#32471.

MarcusRiemer mentioned this pull request Jul 25, 2018

support for ImageMagick 7.0.x rmagick/rmagick#256

Closed

msdundar mentioned this pull request Aug 8, 2018

Image processing kütüphanesi seç omu/nokul#187

Closed

toshimaru added a commit to toshimaru/RailsTwitterClone that referenced this pull request Aug 2, 2021

💎 Use image_processing gem

e5ec01a

see also. rails/rails#32471

toshimaru mentioned this pull request Aug 2, 2021

Image resizing with image_processing toshimaru/RailsTwitterClone#1204

Merged

toshimaru added a commit to toshimaru/RailsTwitterClone that referenced this pull request Aug 4, 2021

💎 Use image_processing gem

20f03c5

see also. rails/rails#32471

toshimaru added a commit to toshimaru/RailsTwitterClone that referenced this pull request Aug 14, 2021

💎 Use image_processing gem

5dd59a9

see also. rails/rails#32471

toshimaru added a commit to toshimaru/RailsTwitterClone that referenced this pull request Aug 21, 2021

💎 Use image_processing gem

1d1a753

see also. rails/rails#32471

toshimaru added a commit to toshimaru/RailsTwitterClone that referenced this pull request Aug 29, 2021

💎 Use image_processing gem

a64ce5b

see also. rails/rails#32471

toshimaru added a commit to toshimaru/RailsTwitterClone that referenced this pull request Sep 1, 2021

Image resizing with image_processing (#1204)

28f1308

* 💎 Use image_processing gem see also. rails/rails#32471 * List resized image * Change image limit size: 500x500 → 700x700

junan mentioned this pull request Sep 21, 2021

[Task-8][Backend] As a user I can CRUD Article nimblehq/rails-view-component-blog#22

Merged

akhilgkrishnan mentioned this pull request Oct 10, 2023

Updated the image_processing gem version for new rails apps #49560

Closed

4 tasks

zzak mentioned this pull request Jan 9, 2025

Ensure image_processing is installed for new apps #54166

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Use ImageProcessing gem for ActiveStorage variants #32471

Use ImageProcessing gem for ActiveStorage variants #32471

janko commented Apr 6, 2018 •

edited

Loading

rails-bot commented Apr 6, 2018

y-yagi commented Apr 6, 2018

rafaelfranca commented Apr 6, 2018

janko commented Apr 6, 2018 •

edited

Loading

janko commented Apr 14, 2018

georgeclaghorn left a comment

georgeclaghorn Apr 20, 2018

janko Apr 22, 2018

georgeclaghorn Apr 22, 2018

janko Apr 22, 2018

dixpac Apr 23, 2018

janko Apr 23, 2018 •

edited

Loading

dixpac Apr 23, 2018

janko Apr 23, 2018 •

edited

Loading

janko Apr 23, 2018

janko Apr 23, 2018

janko commented Apr 23, 2018 •

edited

Loading

janko commented Apr 23, 2018 •

edited

Loading

dixpac commented Apr 23, 2018

janko commented Apr 23, 2018 •

edited

Loading

georgeclaghorn left a comment

georgeclaghorn Apr 23, 2018

georgeclaghorn Apr 23, 2018

janko commented Apr 23, 2018

georgeclaghorn Apr 23, 2018

janko Apr 23, 2018


		To enable variants, add `mini_magick` to your `Gemfile`:
		To enable variants, add `image_processing` gem to your `Gemfile`:

Use ImageProcessing gem for ActiveStorage variants #32471

Use ImageProcessing gem for ActiveStorage variants #32471

Conversation

janko commented Apr 6, 2018 • edited Loading

rails-bot commented Apr 6, 2018

y-yagi commented Apr 6, 2018

rafaelfranca commented Apr 6, 2018

janko commented Apr 6, 2018 • edited Loading

janko commented Apr 14, 2018

georgeclaghorn left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

janko Apr 23, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

janko Apr 23, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

janko commented Apr 23, 2018 • edited Loading

janko commented Apr 23, 2018 • edited Loading

dixpac commented Apr 23, 2018

janko commented Apr 23, 2018 • edited Loading

georgeclaghorn left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

janko commented Apr 23, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

janko commented Apr 6, 2018 •

edited

Loading

janko commented Apr 6, 2018 •

edited

Loading

janko Apr 23, 2018 •

edited

Loading

janko Apr 23, 2018 •

edited

Loading

janko commented Apr 23, 2018 •

edited

Loading

janko commented Apr 23, 2018 •

edited

Loading

janko commented Apr 23, 2018 •

edited

Loading