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