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.


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.

import daffodil;
import daffodil.filter;
import daffodil.transform;

void main() {
    auto image = load!32("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.

Reply via email to