[RFC] Managing input images for tests

From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2019-06-27 07:14:08

Hi,

TL;TRL We must test GIL core using real images, e.g. from reference datasets, and
question is how to approach the format and dependencies requirements.

I've been thinking for a while about a most convenient way to use input
images for tests, and I see the following options:

1. Use and require the I/O extension, and their dependencies.
   For convenience, we could limit the required dependencies to
   libpng and/or libjpeg.

2. Use text-based human-readable images onlfor example
   For example, the I/O extension provides implementation of the Portable aNyMap
   (PNM) format and it does not require any third-party libraries.
   Perhaps, it could be considered as a 'reference I/O format' and moved from I/O
   extension to I/O core. Then, it could serve as format for any test images.
   The PNM images could be easily prepared with ubiquitous tools like ImageMagick
   or GraphicsMagick, or as well as optional GIL-based utility.

   An example of similar approach from the wild could be Boost.Geometry, where
   text-based formats, i.e. CSV (DSV), SVG and WKT, are extensively used for
   testing, debugging and visualising. So, implementation of the three formats is
   part of core and not Geometry I/O extension.

3. Use C++ byte arrays.
   This technique is currently used in the legacy tests
   https://github.com/boostorg/gil/blob/develop/test/legacy/sample_image.cpp

   At first, it seems convenient but preparation of images is cumbersone and we
   would have to provide a utility program based on the I/O extension to
   convert any images to byte arrays. So, regardind required dependencies,
   it is equivalent of the option 1.

I am inclined towards the option 2, that is because:
- I prefer human-readable formats, especially for testing and debugging
- I think it would be very useful to have GIL core providing I/O for at least one
  image format out of the box.
- Git can revision text files.

I'd like to encourage some brainstorming about that issue,
so any feedback is very welcomed.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
Fingerprint=C081 EA1B 4AFB 7C19 38BA  9C88 928D 7C2A BB2A C1F2