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