Feature #30492

Replace rmagick with minimagick

Added by Go MAEDA about 1 month ago. Updated about 5 hours ago.

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

0%

Category:Attachments
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 about 1 month ago

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

#2 Updated by Yuichi HARADA about 1 month 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 about 1 month 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 about 1 month 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 about 1 month 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 about 1 month 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 about 1 month 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 about 1 month 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 about 1 month 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 about 1 month ago

  • Target version set to Candidate for next major release

#11 Updated by Go MAEDA about 1 month ago

  • Description updated (diff)

#12 Updated by Go MAEDA 27 days 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 about 17 hours 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 about 5 hours 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.

Also available in: Atom PDF