Add image_diff comparison method for test output verification using images

[kostrykin]

As part of the Imaging Hackathon in Freiburg.

This PR adds the image_diff comparison method for test output verification using images.

Previous comparison methods comprise diff, re_match, lines_diff, re_match_multiline, contains, and sim_size, all of which are either unsuitable for image data, or dangerous to be used (because the size of a file does not really represent its content). This PR adds the image_diff comparison method, which is specifically tailored for single-channel and multi-channel image data (e.g., RGB), and can be used like this:

<test>
    <param name="in" value="actual.png" />
    <output name="out" value="expected.tif" compare="image_diff" metric="mae" />
</test>

The difference of a pair of images is quantified as the pixel-wise distance between the images, for which different metrics can be used. For different applications and different types of images (e.g., intensity vs. label images), different types of metrics are common. The following metrics are added for intensity images:

metric	Corresponding metric (for intensity images)
mae	Mean absolute error
mse	Mean squared error
rms	Root mean squared error
fro	Frobenius norm

For label images (label maps), it is usually irrelevant which particular label is used for labeling an image region, but only the sets of pixels corresponding to individual image regions need to be compared. This can be accomplished using one minus the intersection over the union of the regions:

metric	Corresponding metric (for label images)
iou	One minus the intersection over the union

To decide whether a pair of images is equal, a tolerance is required, because different compression algorithms (or different versions thereof) can lead to different compression artifacts. A pair of images is considered to be equal in terms of the specified metric, if the distance of the images computed with respect to the metric is not above a threshold eps (0.01 by default).

How to test the changes?

(Select all options that apply)

• I've included appropriate automated tests.
• This is a refactoring of components with existing test coverage.
• Instructions for manual testing are as follows:
  1. [add testing steps and prerequisites here if you didn't write automated tests covering all your changes]

License

• I agree to license these and all my past contributions to the core galaxy codebase under the MIT license.

[nsoranzo]

@kostrykin I've added the changes to the package requirements, and also some type annotations if you'd like to double check them.

@jmchilton Are you OK with numpy and pillow being added as requirements to the galaxy-tool-util package?
If yes, I can also move the functions that currently use pillow conditionally (i.e. those for which I've added type annotations here) from lib/galaxy/util/ to tool_util/ .

[jmchilton]

This is really, really cool stuff - sorry about being a bit picky about the packaging stuff.

[kostrykin]

@kostrykin I've added the changes to the package requirements, and also some type annotations if you'd like to double check them.

Thanks, the type annotations look right to me!

[nsoranzo]

@jmchilton I've added the extra as you suggested, thanks!

[nsoranzo]

Thanks @kostrykin !