Samuel Debionne

@stefanseefeld You got my question right, thanks for the thorough answer! My goal is to build a flexible processing pipeline using GIL's algorithms on views (and more specific algorithms). My...

@mloskot Thanks! I'll use the prebuilt alternative for consistency with CMake.

GIL being a header only library, I guess `Boost::boost` should be enough? Or are you using Boost.GIL standalone (if that is even possible)?

A rationale could be that `int` is used almost [everywhere](https://github.com/boostorg/gil/blob/develop/include/boost/gil/color_base_algorithm.hpp) to identify the channel. I think it helps writing compile-time recursion for per-channel operation but if it' not the case...

> Everywhere - except where it is not used. Sorry, I meant "everywhere" in core. Image processing is a recent addition to the library (that I dont know much about...

I also define my own typedefs for `float` and `double` when pixel are not exactly colors (photon counts in my case). But this is easily done in the app, no?...

GIL stands for Generic Image Library, what kind of text manipulation support are you expecting from an *image* library? Rendering text?

I would recommand to check this (old) contribution then, it might be a good start: [FreetypeGIL] by Tom Brinkman - A Freetype wrapper for GIL. Renders text onto GIL views....

@mloskot Boost.Iterator provides it's own Concept checking classes in `#include ` that matche the (new for the time) Boost.Iterator concepts that never made it to the standard. Since we want...

> I guess we may run out of time to squeeze it into Boost 1.80. What do you think @sdebionne ? Indeed, I underestimate the work and overestimate the time...