Re: [RFC] Managing input images for tests

From: stefan (stefan_at_[hidden])
Date: 2019-07-03 18:45:49

On 2019-06-27 3:14 a.m., Mateusz Loskot wrote:
> 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.

Not a bad option, given how ubiquitous those two formats (and libraries) 
are.

>
> 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.

That's also a good argument: given that our PNM implementation doesn't 
require an external library, we could move it from extension into core 
(we can keep the existing extension API for compatibility), and then 
base tests on that format.

>
> 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 agree, and thus like option 3 the least.

>
> 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.

I'm with you: I also think option 2 is best (if we can identify one 
"builtin" format), but option 1 wouldn't be bad either.

Stefan

--
       ...ich hab' noch einen Koffer in Berlin...