daffodil, a D image processing library

Benjamin Schaaf via Digitalmars-d-announce digitalmars-d-announce at puremagic.com
Fri Jul 1 07:30:17 PDT 2016


On Friday, 1 July 2016 at 11:09:49 UTC, Relja Ljubobratovic wrote:
> On Thursday, 30 June 2016 at 21:35:37 UTC, 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.
>
> Hi there. Took a quick look at the source and it seems really 
> nice! I like your idea of extensibility for color conversion. 
> Also, image I/O seems to be set up quite nicely for a starting 
> point. Although I have to comment that bit depth shouldn't be a 
> template argument, in my opinion. When loading images, bit 
> depth should be determined in the runtime, depending on the 
> image you'd be loading at the moment. Or am I wrong? - do you 
> have some other way of handing this case?
>
> Also wanted to let you know I've been working on a similar 
> library for some time now [1].
> Hope we could merge some modules and learn from each other, and 
> not have multiple different implementations of the same stuff. 
> Please let me know if your interested.
>
> [1] https://github.com/ljubobratovicrelja/dcv

The problem with not knowing bit depth at compile time, is that 
you're now forced to store the image internally as plain bytes. 
So if you wanted to add two colors, you end up with ubyte[4] + 
ubyte[4] instead of int + int. At some point you're going to have 
to use a proper numerical representation (ie. long), or be faced 
with slow calculations (ie. bigint).

Other libraries (eg. ImageMagick) get around this by just using 
longs as the internal representation. Daffodil allows you to 
control this. So if you know you will never use more than 4 bytes 
per color, you don't have to pay for anything more. If you don't 
know, you can just use 8 and essentially have the same behaviour 
as ImageMagick.


More information about the Digitalmars-d-announce mailing list