Use Imagick/Gmagick

[mzur]

For possible future support of TIFF and other formats and maybe to address #69 we can think about using Imagick or Gmagick instead of php-gd. InterventionImage (our PHP graphics processing library) supports Imagick out of the box. The people of Gmagick claim their library would be better, though.

First, check if we want to use Gmagick over Imagick. Then check if we need InterventionImage or if it can be configured to run with Gmagick, too.

We use InterventionImage to have automatic image caching for remote volumes (among other things) so it might be nice to be able to keep it.

[mzur]

Identify some problematic images and see if Imagick handles them better than GD.

[mzur]

I have another argument for Imagick: It is not bound to PHPs memory limit. That's a huge bonus.

Our Biigle instance is currently processing the imported annotations of the NOC images which are stitched together tiles. These images get really big in terms of pixel number. While generating the annotation patches GD very frequently exceeds the memory limit (which already is artificially increased for the patch generation) that crashes the worker process. If the workers crash too often Solaris svc will put them in maintenance mode, stalling all processing until the service is manually cleared. With Imagick there would be no such problem.

But be aware of ImageTragick!

[mzur]

Gmagick seems to be the preferred library since it is said to be faster and more memory efficient. Maybe we should consider a fork of InterventionImage to add support for Gmagick?

[mzur]

I'm now thinking about switching to Imagine instead of InterventionImage. Imagine is somehow lower-level but is still not too complicated for our basic use case. It also supports GD, Imagick and Gmagick out of the box. We'd have to write a thin wrapper, though, so we still can easily swap the libraries with a config value.

I got discouraged from doing a fork of InterventionImage to add support for Gmagick because their tests are kind of messed up. Adding Gmagick support would be a significant amount of work. Also we should be able to easily replace the InterventionImage Cache with the native cache of Laravel.

[mzur]

After experimenting with Imagine for a while I've now concluded that we stick to InterventionImage. Although Imagine supports Gmagick and has a smaller codebase it didn't behave as well as InterventionImage. For one it didn't allow a negative offset for annotation patches at all. InterventionImage just draws anything "outside" the image black. And then the image caching didn't work as expected since PHP can't serialize resource objects. InterventionImage does an extra encoding step to circumvent this.

This means that we can't use Gmagick. I'll have Support install Imagick on our production machine and then we switch the InterventionImage driver from GD to Imagick. The default can stay GD so our installation requirements don't change.

In the long run we can implement support, e.g. for TIFF images as well but this means that our installation requirements will change and the environments of all our Biigle instances need to be updated.

[mzur]

Changing plans again. In order to support large images with tiling we will switch to vips. I've got a version running nicely in our experimental Docker setup (#85). Closing this in favor of #101.