Jump to page: 1 2 3
Thread overview
daffodil, a D image processing library
Jun 30, 2016
Benjamin Schaaf
Jul 01, 2016
rikki cattermole
Jul 01, 2016
Jack Stouffer
Jul 01, 2016
rikki cattermole
Jul 01, 2016
ketmar
Jul 01, 2016
ketmar
Jul 01, 2016
Benjamin Schaaf
Jul 01, 2016
Edwin van Leeuwen
Jul 04, 2016
Manu
Jul 04, 2016
Edwin van Leeuwen
Jul 01, 2016
Rory McGuire
Jul 01, 2016
Benjamin Schaaf
Jul 01, 2016
Michael
Jul 01, 2016
Vladimir Panteleev
Jul 06, 2016
Martin Nowak
Jul 01, 2016
Guillaume Piolat
Jul 01, 2016
Leandro Lucarella
Jul 02, 2016
Benjamin Schaaf
June 30, 2016
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.

July 01, 2016
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.

July 01, 2016
On Friday, 1 July 2016 at 01:24:55 UTC, rikki cattermole wrote:
> Doesn't use allocators or Manu's color work, yup yup not interested.

Way to be a dismissive asshole.

Let me rewrite that sentence for you:

"Hey, nice work, we really need something like this. I'm a bit concerned about the GC usage though, have you checked out std.allocators or the proposed std.color? I think these will help make your library much faster."
July 01, 2016
On 01/07/2016 1:47 PM, Jack Stouffer wrote:
> On Friday, 1 July 2016 at 01:24:55 UTC, rikki cattermole wrote:
>> Doesn't use allocators or Manu's color work, yup yup not interested.
>
> Way to be a dismissive asshole.
>
> Let me rewrite that sentence for you:
>
> "Hey, nice work, we really need something like this. I'm a bit concerned
> about the GC usage though, have you checked out std.allocators or the
> proposed std.color? I think these will help make your library much faster."

I thought I was being quite lighthearted really given how many different implementations there are these days.
If the author would like me to apologize I will.
July 01, 2016
On Friday, 1 July 2016 at 01:24:55 UTC, rikki cattermole wrote:
> Doesn't use allocators
great library! definitely worth a closer look.
July 01, 2016
On Friday, 1 July 2016 at 01:47:44 UTC, Jack Stouffer wrote:
> Way to be a dismissive asshole.

why so serious? it is clearly a joke.
July 01, 2016
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.
July 01, 2016
On Friday, 1 July 2016 at 08:11:37 UTC, Benjamin Schaaf wrote:
> On Friday, 1 July 2016 at 01:24:55 UTC, rikki cattermole wrote:
>> On 01/07/2016 9:35 AM, Benjamin Schaaf wrote:
>>
>> 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.

Also, the only way currently to use Manu's color work is to install his phobos branch. The dub package will throw unittest errors and loads of deprecation warnings.

July 01, 2016
On Fri, Jul 1, 2016 at 10:11 AM, Benjamin Schaaf via Digitalmars-d-announce <digitalmars-d-announce@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.


July 01, 2016
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
« First   ‹ Prev
1 2 3