<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 1, 2016 at 10:11 AM, Benjamin Schaaf via Digitalmars-d-announce <span dir="ltr"><<a href="mailto:digitalmars-d-announce@puremagic.com" target="_blank">digitalmars-d-announce@puremagic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Friday, 1 July 2016 at 01:24:55 UTC, rikki cattermole wrote:<br>
</span><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 01/07/2016 9:35 AM, Benjamin Schaaf wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
daffodil is a image processing library inspired by python's Pillow<br>
(<a href="https://pillow.readthedocs.org/" rel="noreferrer" target="_blank">https://pillow.readthedocs.org/</a>). It is an attempt at designing a<br>
clean, extensible and transparent API.<br>
<br>
<a href="https://github.com/BenjaminSchaaf/daffodil" rel="noreferrer" target="_blank">https://github.com/BenjaminSchaaf/daffodil</a><br>
<a href="https://benjaminschaaf.github.io/daffodil/" rel="noreferrer" target="_blank">https://benjaminschaaf.github.io/daffodil/</a><br>
<br>
The library makes full use out of D's templates and metaprogramming. The<br>
internal storage mechanism is entirely configurable from almost every<br>
endpoint. File headers are directly loaded into structs defining them,<br>
removing most of the difficulties in reading them according to spec. The<br>
image type and loading API is entirely extensible, making extra image<br>
formats entirely self-contained.<br>
<br>
Currently only loading and saving of simple BMP images is supported,<br>
with convolution and Gaussian Blur filters and flip transformations. Its<br>
still early in development, but I'd love to get some feedback on it.<br>
<br>
Example:<br>
---<br>
import daffodil;<br>
import daffodil.filter;<br>
import daffodil.transform;<br>
<br>
void main() {<br>
    auto image = load!32("daffodil.bmp");<br>
<br>
    image.gaussianBlurred(1.4).save("blurry_daffodil.bmp");<br>
<br>
    image.flipped!"y".save("upside_down_daffodil.bmp");<br>
}<br>
---<br>
<br>
The license is MIT, so feel free to do whatever you want with the code.<br>
Issues and pull requests are of course welcome ;)<br>
<br>
Alongside I've also written (an admittedly hacky) sphinx<br>
(<a href="http://www.sphinx-doc.org/en/stable/" rel="noreferrer" target="_blank">http://www.sphinx-doc.org/en/stable/</a>) extension that provides a domain<br>
and autodocumenter for D, using libdparse and pyd.<br>
</blockquote>
<br>
Doesn't use allocators or Manu's color work, yup yup not interested.<br>
</blockquote>
<br></div></div>
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.<br>
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.<br>
<br>
I haven't looked into using allocators yet, but I've put it on the horizon.<br>
</blockquote></div><br></div><div class="gmail_extra">Yeah, good choice.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div></div>