On Fri, Jul 1, 2016 at 10:11 AM, Benjamin Schaaf via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
> On Friday, 1 July 2016 at 01:24:55 UTC, rikki cattermole wrote: > >> On 01/07/2016 9:35 AM, Benjamin Schaaf wrote: >> >>> daffodil is a image processing library inspired by python's Pillow >>> (https://pillow.readthedocs.org/). It is an attempt at designing a >>> clean, extensible and transparent API. >>> >>> https://github.com/BenjaminSchaaf/daffodil >>> https://benjaminschaaf.github.io/daffodil/ >>> >>> The library makes full use out of D's templates and metaprogramming. The >>> internal storage mechanism is entirely configurable from almost every >>> endpoint. File headers are directly loaded into structs defining them, >>> removing most of the difficulties in reading them according to spec. The >>> image type and loading API is entirely extensible, making extra image >>> formats entirely self-contained. >>> >>> Currently only loading and saving of simple BMP images is supported, >>> with convolution and Gaussian Blur filters and flip transformations. Its >>> still early in development, but I'd love to get some feedback on it. >>> >>> Example: >>> --- >>> import daffodil; >>> import daffodil.filter; >>> import daffodil.transform; >>> >>> void main() { >>> auto image = load!32("daffodil.bmp"); >>> >>> image.gaussianBlurred(1.4).save("blurry_daffodil.bmp"); >>> >>> image.flipped!"y".save("upside_down_daffodil.bmp"); >>> } >>> --- >>> >>> The license is MIT, so feel free to do whatever you want with the code. >>> Issues and pull requests are of course welcome ;) >>> >>> Alongside I've also written (an admittedly hacky) sphinx >>> (http://www.sphinx-doc.org/en/stable/) extension that provides a domain >>> and autodocumenter for D, using libdparse and pyd. >>> >> >> Doesn't use allocators or Manu's color work, yup yup not interested. >> > > In terms of std.experimental.color, one of the things I focused on was > extensibility. What if someone came along and had their own color space > they needed to implement? With std.experimental.color, the only option you > currently have is editing the library. If it gets included into phobos, > then suddenly your "I want to implement my own color space" has turned into > editing the standard library. > Albeit currently rough around the edges, all you have to do to implement > your own color space in daffodil, is to implement the ColorSpace interface. > > I haven't looked into using allocators yet, but I've put it on the horizon. > Yeah, good choice. I lean more towards the standard library defining a set if inspection templates (to avoid forcing use of classes/interfaces) and a default implementation rather than tying us so close to the standard library, D is better than that.