Re: [RFC] Managing input images for tests

From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2019-07-03 19:32:20

On 19-07-03 14:45:49, stefan wrote:
>On 2019-06-27 3:14 a.m., Mateusz Loskot wrote:
>>
>>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.

Yes, it is not a bad option in terms of dependencies accessibility.
I just think that a human-readable format has that advantage of easy construction
and easy inspection of pixel/channel values, what is quite useful for testing
and debugging purposes. Technically, easier than with binary formats.

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

Yes, good point about the API compatibility. We should be able to keep current
structure of headers with little help of some proxy headers.

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

Thank you. Soon, I will propose a PR moving PNM as a core I/O format.

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