Feature #30492

Replace rmagick with minimagick

Added by Go MAEDA 4 months ago. Updated 21 days ago.

Status:NewStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Gems support
Target version:Candidate for next major release
Resolution:

Description

Redmine uses ImageMagick via rmagick to generate thumbnails and gantt png export. I think it is beneficial to replace rmagick with minimagick for the following reasons:

  • Smaller footprint. The author says that the memory occupation is "much smaller compared to RMagick".
  • Supports the latest ImageMagick 7. rmagick does not yet.
  • Completely written in Ruby. Unlike rmagick, minimagick never causes build errors when installing the gem.

30492-replace-with-minimagick.patch Magnifier (17 KB) Yuichi HARADA, 2019-02-07 05:24

gantt_rmagick@2x.png (64.6 KB) Yuichi HARADA, 2019-02-07 05:24

gantt_minimagick@2x.png (64.8 KB) Yuichi HARADA, 2019-02-07 05:24


Related issues

Related to Redmine - Feature #22995: Replace ImageMagick thumbnail creating with GD Graphics L... New
Related to Redmine - Patch #30821: Stay in RMagick 2.16.0 and don't update to 3.0.0 Closed

History

#1 Updated by Go MAEDA 4 months ago

  • Related to Feature #22995: Replace ImageMagick thumbnail creating with GD Graphics Library aka libgd added

#2 Updated by Yuichi HARADA 4 months ago

Go MAEDA wrote:

Redmine uses ImageMagick via rmagick to generate thumbnails and gantt png export.

Redmine does not use rmagick to generate thumbnails, but it directly executes the ImageMagick convert command.

rmagick is using only Redmine::Helpers::Gantt#to_image . This method is called when gantt png export.
I replaced rmagick with minimagick. I attached a patch.

  • gantt png export with rmagick.
  • gantt png export with minimagick. (Today's red line is different as we export it with rmagick and export it with minimagick the next day.)

#3 Updated by Anonymous 4 months ago

Definitely +1 if it takes less memory :)

But I also wanted to take a look into doing all the image processing and saving stuff on the front end instead. Now that you can create canvas objects with 2d and webgl contexts as variables of javascript, it makes all these image generation and manipulations super easy even on the front end and thus there is little to no reason to bother a server with image processing. These tools already integrated in browsers (even IE11), require no libraries at all and definitely should be used. Imho server should just supply the required links to resources, JS should pick it up to process and store the processed into cache to request next time from the cache instead of resizing all the time (for best optimization).

And that would also be -1 back-end dependency.

#4 Updated by Go MAEDA 4 months ago

Max Johansson wrote:

But I also wanted to take a look into doing all the image processing and saving stuff on the front end instead. Now that you can create canvas objects with 2d and webgl contexts as variables of javascript, it makes all these image generation and manipulations super easy even on the front end and thus there is little to no reason to bother a server with image processing. These tools already integrated in browsers (even IE11), require no libraries at all and definitely should be used. Imho server should just supply the required links to resources, JS should pick it up to process and store the processed into cache to request next time from the cache instead of resizing all the time (for best optimization).

Do you mean that the patch should not be committed and we should wait for someone to submit a JavaScript-based patch?

Generating gantt PNG images with JavaScript is a nice option but I think it is better to go with mini_magic for now because no one is currently working on JavaScirpt-based gantt export. This mini-magick-based patch can be delivered in 4.1.0, but no one knows when a JavaScript-based patch will be submitted. Of course, it is really nice if someone submits a JavaScript-based patch in the future.

#5 Updated by Bernhard Rohloff 4 months ago

I also agree to commit this patch as we don't have a working JS alternative by now and it will definitely take it's time to develop and test it. In the meantime it's a nice improvement.
+1

#6 Updated by Marius BALTEANU 4 months ago

Go, Bernhard, should we run some tests with both libraries (with new version of rmagick)? Also, I'm observing that rmagick is going to release a new version soon with a lot of refactoring and has new maintainers.

According to Travis, minimagick doesn't run the tests on ruby 2.6, should we create a PR before changing to it?

#7 Updated by Anonymous 4 months ago

Go, sorry, I meant, I totally agree with committing the change to mini magic for now as current solution, I just wanted to also inform that this could definitely be improved even more in the future by trying out JS. I have other things at the moment, but surely, I'll take a look at it in the future. :)

#8 Updated by Go MAEDA 3 months ago

  • Related to Patch #30821: Stay in RMagick 2.16.0 and don't update to 3.0.0 added

#9 Updated by Go MAEDA 3 months ago

RMagick 3.0.0 has released on 2019-02-16 but it does not support ImageMagick 7.0 yet. In addition, it narrowed the supported version. The minimum supported version of ImageMagick has raised from 6.4.9 to 6.8.9.

#10 Updated by Go MAEDA 3 months ago

  • Target version set to Candidate for next major release

#11 Updated by Go MAEDA 3 months ago

  • Description updated (diff)

#12 Updated by Go MAEDA 3 months ago

Marius BALTEANU wrote:

According to Travis, minimagick doesn't run the tests on ruby 2.6, should we create a PR before changing to it?

I have just sent a pull request.
https://github.com/minimagick/minimagick/pull/475

#13 Updated by Goh Matsumoto 2 months ago

RMagick 3.0.0 has released on 2019-02-16 but it does not support ImageMagick 7.0 yet. In addition, it narrowed the supported version. The minimum supported version of ImageMagick has raised from 6.4.9 to 6.8.9.

I don't oppose replacing rmagick with minimagick.
But It seems that this isn't quite persuasive enough.

As described in the comment, ImageMagick 6.8.9 was released at nearly 4 years ago.
https://github.com/rmagick/rmagick/issues/392#issuecomment-466100509

And Redmine 3.4.0 released 2 years ago.
Do you think Redmine has to work with ImageMagick 6.8.8 or former?

#14 Updated by Go MAEDA 2 months ago

Goh Matsumoto wrote:

Do you think Redmine has to work with ImageMagick 6.8.8 or former?

Yes, I think so because some major Linux distributions still bundle older ImageMagick. For example, CentOS 7.6 and Amazon Linux AMI 2018.03 bundles ImageMagick 6.7.8.9.

You cannot install Redmine on such distributions without a trick like "bundle install --without rmagick". But I think it is difficult for admins who are not familiar with Ruby to find the solution. The installation process should be as simple as possible.

#15 Updated by Marius BALTEANU about 1 month ago

Rails 6 is deprecating the MiniMagick backend and replacing the library with ImageProcessing gem. More details can be found in the Changelog.

#16 Updated by Go MAEDA about 1 month ago

Marius BALTEANU wrote:

Rails 6 is deprecating the MiniMagick backend and replacing the library with ImageProcessing gem. More details can be found in the Changelog.

I didn't know that. Thanks.

Although Rails 6 does not directly depend on mini_magick, image_processing gem seems to require mini_magick. Please see: https://rubygems.org/gems/image_processing/versions/1.8.0

Maybe the change in Rails adds image_processing as a wrapper for libvips or mini_magick.

#17 Updated by Ronan Chagas about 1 month ago

Goh Matsumoto wrote:

I don't oppose replacing rmagick with minimagick.
But It seems that this isn't quite persuasive enough.

Some distributions, like openSUSE Leap 15.0, does not ship ImageMagick 6 anymore. Currently, there is no official way to install ImageMagick 6 on Leap 15.0, 15.1, and Tumbleweed. Hence, it is not possible to install Redmine with `rmagick` since it won't build against ImageMagick 7.

EDIT: By the way, this patch is working perfectly and, even installing ImageMagick6 in openSUSE (latest version), I am getting and error when exporting Gantt to PNG.

#18 Updated by Jun NAITOH about 1 month ago

Go MAEDA wrote:

Goh Matsumoto wrote:

Do you think Redmine has to work with ImageMagick 6.8.8 or former?

Yes, I think so because some major Linux distributions still bundle older ImageMagick. For example, CentOS 7.6 and Amazon Linux AMI 2018.03 bundles ImageMagick 6.7.8.9.

You cannot install Redmine on such distributions without a trick like "bundle install --without rmagick". But I think it is difficult for admins who are not familiar with Ruby to find the solution. The installation process should be as simple as possible.

rmagick 3.1.0 seems to extend the range of support for ImageMagick.

ImageMagick 6.7.7 or later

#19 Updated by Jun NAITOH about 1 month ago

Redmine's PDF output feature uses the rbpdf library, now.
The image processing of the rbpdf library has parts depending on RMagick.
If Redmine migrates to minimagick, (and in environments where RMagick is not installed), PDF will not display images other than 8bit PNG (GIF, JPEG, non 8bit PNG).

#20 Updated by Go MAEDA about 1 month ago

Jun NAITOH wrote:

Redmine's PDF output feature uses the rbpdf library, now.
The image processing of the rbpdf library has parts depending on RMagick.
If Redmine migrates to minimagick, (and in environments where RMagick is not installed), PDF will not display images other than 8bit PNG (GIF, JPEG, non 8bit PNG).

Thank you for pointing it out. I didn't know that the PDF export feature depends on RMagick.

I have changed my mind by knowing that. We had better not to commit the patch for now because replacing RMagick with MiniMagick because may break the PDF export feature.

#21 Updated by Go MAEDA 21 days ago

  • Category changed from Attachments to Gems support

Also available in: Atom PDF