On Friday, 1 July 2016 at 21:18:28 UTC, Vladimir Panteleev wrote:
In case anyone from this thread haven't seen it, I have my own
image library, which I wrote about here:
https://blog.thecybershadow.net/2014/03/21/functional-image-processing-in-d/
There is also a very nice and somewhat popular
On Monday, 4 July 2016 at 15:10:30 UTC, Manu wrote:
On 1 July 2016 at 18:19, Edwin van Leeuwen via
Digitalmars-d-announce
wrote:
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
On 1 July 2016 at 18:19, Edwin van Leeuwen via Digitalmars-d-announce
wrote:
> 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
On Friday, 1 July 2016 at 21:18:28 UTC, Vladimir Panteleev wrote:
Generally most use cases for using an image library can be
divided into:
1. You have full control over the images being loaded. This is
the case when you're loading graphical assets for your
application which otherwise
On Friday, 1 July 2016 at 23:37:59 UTC, Leandro Lucarella wrote:
On Thursday, 30 June 2016 at 21:35:37 UTC, Benjamin Schaaf
wrote:
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
On Thursday, 30 June 2016 at 21:35:37 UTC, Benjamin Schaaf wrote:
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.
Where can I get the Sphinx extension? :-D
On Friday, 1 July 2016 at 11:09:49 UTC, Relja Ljubobratovic wrote:
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?
Generally most use cases for using an image library can be
divided into:
1. You have
On Friday, 1 July 2016 at 14:30:17 UTC, Benjamin Schaaf wrote:
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
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:
[...]
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
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
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.
Nice.
Minor nitpick, please make the width and
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
On Fri, Jul 1, 2016 at 10:11 AM, Benjamin Schaaf via Digitalmars-d-announce
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
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
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.
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.
On Friday, 1 July 2016 at 01:24:55 UTC, rikki cattermole wrote:
Doesn't use allocators
great library! definitely worth a closer look.
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
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
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
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
21 matches
Mail list logo