Support image processing by an image server

[matthias-ronge]

The image processing logic based on ImageMagick is to be replaced alternatively implemented by calling an image server. Cantaloupe is a reference implementation here. The folder configuration image generation can remain largely unchanged with the already available options. Another option should be added to configure all possible image server options by manually encoding the URL. A selection should be introduced to either generate the images in advance or to call the image server in real time.

Additional information:

• Cantaloupe
• Cantaloupe Image Server :: Getting Started
• Image Request Parameters

[henning-gerhardt]

A question: is the image server a replacement for the ImageMagick based implementation or should this a second possible implementation for displaying / converting imges which you can configure to use ImageMagick or the image server?

[matthias-ronge]

The image server is intended to be a replacement.

[henning-gerhardt]

IMHO is this a bad decision: one more complex software to install, administrate and maintaince - at least at our environment and I can blow away all planings for the ImageMagick integration. Why is there an API which allow many different implementations but the default implementation is a complex one?

[matthias-ronge]

As I understood @sebastian-meyer, the image server is not a big deal, and/or many larger institutions already operate one (if not an entire farm), in which case no additional installation is required. If it is as easy as with ElasticSearch that you only have to install a program from the repository and start it, I have no worries.

I personally have nothing against keeping the existing module as long as it continues to work. At the moment, the API does not support different modules for the same function within the same instance (see bug #3154), but a constant selection of exactly one module should be possible.

There are several reasons for replacing the module in the long term: It produces surprisingly complex commands in the legacy ImageMagick 6 command line syntax, which was changed with the release of ImageMagick 7 in mid-2016, something we weren’t aware of until current Linux distributions upgraded their ImageMagick to version 7. The makers of ImageMagick announced to provide an LTS version of ImageMagick 6 for at least ten years after the release of version 7:

Now that ImageMagick version 7 is released, we continue to support and enhance version 6 for a minimum of 10 years. (source)

So the existing plugin can probably be used until 2026. Over the years, however, due to the increase in the amount and type of digitized media, such as multimedia content, the switch to standard technology should be considered, and Kitodo should be ready to support it.

Another advantage of a rendering farm is that it takes care of caching, at the same time, derivatives do not have to be kept around forever for all processes. So this is also a resource decision, and as a result an economic decision.

[sebastian-meyer]

I think, choosing an image server over ImageMagick is more than just a replacement. Those are two entirely different approaches to image handling:

While the current approach aims at statically generating all necessary image derivatives and placing them in the configured folders, an image server would aim at making the need for these derivatives obsolete (instead of just generating them in another way).

To be clear: I fully support the idea of using image servers in Kitodo, but I think this should be an alternative to the current approach and not a replacement.

[henning-gerhardt]

For our Kitodo.Production SLUB environment with at least 3 stages (experimental, test, productive) we need at least same amount of image servers because the path are the same but using different underlying NFS shares which providing the real data of the used stage. So we must maintenance more servers with no or only little benefit. The Kitodo.Presention SLUB environment will use their own image server as their data is different from the Kitodo.Production data.

[Erikmitk]

I came across https://github.com/imazen/imageflow. Maybe that's a viable alternative.

libimageflow has ~10x the throughput of ImageMagick, yet puts security first. It is correct, fast, and has an evolvable JSON API. Imageflow doesn’t try to be ImageMagick; it supports only the core image operations and web-safe image formats needed by most applications and websites. This focus allows libimageflow to have a tiny and auditable codebase.