daffodil, a D image processing library

[Rory McGuire via Digitalmars-d-announce]

On Fri, Jul 1, 2016 at 10:11 AM, Benjamin Schaaf via Digitalmars-d-announce
<digitalmars-d-announce at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-announce/attachments/20160701/b37678c9/attachment.html>