Image Resizing

[seth-shaw-unlv]

It is useful to resize images (if that is what we are uploading) locally since 1) desktop processor time is essentially free and 2) we can make thumbnails for the GUI editor before upload.

We could use imagemagick but users need to install it on their machine before the workbench is installed. (Searching for ways to include it natively have not worked.)

We could use the Python Pillow library (the original PIL doesn't have a Python 3 release). Presumably we could wrap calls there like we do for the ingester, although I don't know the implications for building the distribution binaries.

Another option is the Node.js Sharp module which, in some testing, performs faster than an Javascript wrapper around imagemagick. The benefit of this is we know it can integrate with an Electron app. The downside is that it doesn't appear to support Jpeg2000.

[seth-shaw-unlv]

I just came across an npm trends graph for the most common image manipulation libraries:

It introduces jimp as another (popular) option, although it doesn't include JPEG 2000 support either.

I'm wondering how important JPEG 2000 support is. If most users are scanning TIFFs then all of these options work fine. Perhaps we start with that and then implement Pillow for JP2K if time permits?

[mjordan]

@seth-shaw-unlv I've been thinking about a "pre-ingest" hook system of some sort.... basically allowing users to configure arbitrary commands/scripts executed on binaries before they are PUT up to Islandora. I've had luck with similar techniques in other apps I've worked on, like Move to Islandora Kit's post-write hooks. What I'm thinking is:

• within workbench's per-CSV row execution loop, we provide a call out to the shell, passing in the path to the original file. the desired output path, and the path to the workbench config file as arguments. For each file in the CSV file column, this call will be executed.
• in the config file, user identifies the command and any additional arguments the command requires.
• we could even allow definition of a target CSV field so that the output is identified (or even inserted as a blob) into that field, satisfying the thumbnail requirement

What I'm describing here might be OK for usage of workbench as a CLI app, where most people probably wouldn't want to rely on npm. But, in the context of a desktop GUI app which already operates in the npm environment, we could allow it to do any preprocessing on the input it wanted to, including jimp, Sharp, etc.

As for JPEG2000 support, my hunch is that most Islandora users consider it to be a derivative and not a master format. But, I think it would be useful to poll the community to see if that is accurate.