Re: daffodil, a D image processing library
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 doesn't concern itself for graphical work. 2. You're writing an image editor, or some other program that processes images out of your control, i.e. supplied by the user. Generally the first case is by far the most common one (think GUI applications, video games...). In this case, since you already know or have control over the format of your images, there is no reason to burden your application with performance-killing abstraction layers - you should load and work in the format that your images already are. Additionally, if necessary, it is easy to build such a runtime abstraction layer over a templated library by creating an algebraic type from only the set of formats that you want to support. Doing the inverse is impossible. 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/ Hi Vladimir, thanks for your response and explanation. Also wanted to take the opportunity to say that the blog post about your library was one of the biggest motivations for me to pursue D for computer vision. Thanks a tone for your effort! :) Cheers, Relja
Re: daffodil, a D image processing library
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 libdparse and pyd. Where can I get the Sphinx extension? :-D https://github.com/BenjaminSchaaf/sphinxddoc It has a sphinx language domain for D and an autodocumenter. I've written a python extension using pyd and libdparse to parse D source into a consumable json format. I then use that output to autodocument the code. Its a bit of a hack, but I find having proper control of the output and being able to use sphinx themes is worth it compared to the alternative.
Re: daffodil, a D image processing library
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
Re: daffodil, a D image processing library
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 full control over the images being loaded. This is the case when you're loading graphical assets for your application which otherwise doesn't concern itself for graphical work. 2. You're writing an image editor, or some other program that processes images out of your control, i.e. supplied by the user. Generally the first case is by far the most common one (think GUI applications, video games...). In this case, since you already know or have control over the format of your images, there is no reason to burden your application with performance-killing abstraction layers - you should load and work in the format that your images already are. Additionally, if necessary, it is easy to build such a runtime abstraction layer over a templated library by creating an algebraic type from only the set of formats that you want to support. Doing the inverse is impossible. 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/
Re: daffodil, a D image processing library
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 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. Yes, I'm aware of that problem. But if you store the type information in the image (as enum field), later on you can do the casting to correct types and perform arithmetics the right way. This is how opencv's cv::Mat works under the hood, also I believe numpy.ndarray's c implementation performs the same way. Don't get me wrong, I'm not saying your way is not correct. :) Just explaining my viewpoint. I believe your way is a lot easier - if you could show that it works well in production environment, I'd be glad to adopt it! Cheers, Relja
Re: daffodil, a D image processing library
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 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 This is how responses should be, so thanks for adding to the conversation, unlike the initial commenter. I do think, as there has been multiple proposed libraries for audio/CV/UI models, that some collaboration and merging of the more similar modules would benefit greatly from the combined effort and increased output, as getting these kinds of libraries off the ground seems to be quite slow at first. I'd love to start using some CV libraries in D for video processing.
Re: daffodil, a D image processing library
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.
Re: Ocean preview finally open sourced
On 01/07/16 12:31, Leandro Lucarella wrote: We know that, and again, the license was by far the biggest nightmare of the open sourcing effort. Honestly we don't have the time to take on this, but this is an area where external contributions would be extremely helpful. Anyone can contact the original authors and ask for permission (although to make sure we probably need to check the full Tango history to see all the people that actually contributed, sometimes the Authors section is quite bogus). Walter, or someone, already asked the authors of Tango to re-license it. They said no, I don't recall if not all authors could be tracked down or if it was plain no. -- /Jacob Carlborg
Re: Another audio plugin in D
On 01/07/16 08:07, bitwise wrote: Sorry I haven't had much time to work on this lately. I'm not sure how soon I will have time. If anyone else wanted to champion this effort, we could discuss passing the torch and trying to make use of the work I've done thus far. I still plan to do it at some point, but I don't want to stand in anyone's way if there is an urgent need for it. The native TLS support is merged, so that's one issue out of the way at least. -- /Jacob Carlborg
Re: Ocean preview finally open sourced
On Friday, 1 July 2016 at 10:31:59 UTC, Leandro Lucarella wrote: Oh, well. Sorting out the license(s) were one of the major pains and time consuming tasks we had to do to opensource this, and apparently despite our best efforts there are stuff that we didn't see. *nods* I was only looking at a few random filenames that sounded interesting just to get an idea of what it covered and what it could be useful for :-). We know that, and again, the license was by far the biggest nightmare of the open sourcing effort. Yes, this is often an issue when internal frameworks are open sourced. Non-boost licenses might be less problematic for people who just run the executables on their own servers than for people who release binaries/source.
Re: daffodil, a D image processing library
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 height of an image an int instead of s size_t. We've had numerous discussions about this: https://forum.dlang.org/post/ifjiebtudbyrnaxgm...@forum.dlang.org https://github.com/lgvz/imageformats/issues/24
Re: daffodil, a D image processing library
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
Re: Ocean preview finally open sourced
On Friday, 1 July 2016 at 09:43:53 UTC, Ola Fosheim Grøstad wrote: On Thursday, 30 June 2016 at 16:45:43 UTC, Leandro Lucarella wrote: (although please have a look at the licensing terms, even when all our code is Boost, there is code inherited from Tango that isn't), criticize it, and if you are really nice, fill issues and make pull requests! I find the licensing a bit confusing. For instance https://github.com/sociomantic-tsunami/ocean/blob/v2.x.x/src/ocean/math/Probability.d Lists the licensing as: Tango 3 BSD Clause + Academic Free License v3.0. But the original work Cephes seems to carry this ad-hoc license: https://github.com/jeremybarnes/cephes/blob/master/readme Oh, well. Sorting out the license(s) were one of the major pains and time consuming tasks we had to do to opensource this, and apparently despite our best efforts there are stuff that we didn't see. This comes from Tango, so we kept the original Tango license. I would assume Tango people did a check on this, and had some sort of permission to change the license, but I will try to contact the author to make sure this is the case. If not, then we'll probably remove that module (we removed a lot of Tango modules because of dubious origin/license already). https://github.com/sociomantic-tsunami/ocean/issues/2 « Some software in this archive may be from the book _Methods and Programs for Mathematical Functions_ (Prentice-Hall or Simon & Schuster International, 1989) or from the Cephes Mathematical Library, a commercial product. In either event, it is copyrighted by the author. What you see here may be used freely but it comes with no support or guarantee. The two known misprints in the book are repaired here in the source listings for the gamma function and the incomplete beta integral. » Maybe it would be a good idea to sort out the code that is pure Boost, or obtain a boost license where the authors are known, because complicated licensing is a hindrance even if the "spirit" is the same across the licenses. We know that, and again, the license was by far the biggest nightmare of the open sourcing effort. Honestly we don't have the time to take on this, but this is an area where external contributions would be extremely helpful. Anyone can contact the original authors and ask for permission (although to make sure we probably need to check the full Tango history to see all the people that actually contributed, sometimes the Authors section is quite bogus).
Re: Ocean preview finally open sourced
On Friday, 1 July 2016 at 09:13:46 UTC, Chris wrote: On Friday, 1 July 2016 at 08:54:27 UTC, Leandro Lucarella wrote: But if there is interest, I don't discard the splitting idea in some future. It'd be great, if there was some sort of separation so that users know exactly what to use for cross-platform development and what not. Docs or some sort of a cheat sheet would be nice too. In this way users can see, if Ocean contains something interesting for the task at hand. There's less of a chance of adoption, if you have to go through the source code to see what it does. Yes, the library is fairly well documented but one of our big debts is to build the documentation. Unfortunately the project lacked document generation for basically all its life, so even when some sort of DDoc-ish format is used, it not strictly DDoc because it was never actually generated, so when we start generating the docs we'll need to do a lot of cleanup and fixing. But generating Docs is another thing that is high in our TODO list.
Re: daffodil, a D image processing library
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 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.
Re: Another audio plugin in D
On Friday, 1 July 2016 at 06:07:13 UTC, bitwise wrote: On Monday, 27 June 2016 at 11:02:33 UTC, Guillaume Piolat wrote: Unloading of shared libraries on OS X continues to be a problem though, it would be nice if it worked in 64-bit. Sorry I haven't had much time to work on this lately. I'm not sure how soon I will have time. If anyone else wanted to champion this effort, we could discuss passing the torch and trying to make use of the work I've done thus far. I still plan to do it at some point, but I don't want to stand in anyone's way if there is an urgent need for it. Bit Stefan Koch/UplinkCoder told me he could be interested. TBH I would only need this bug fixed in LDC. https://github.com/ldc-developers/ldc/issues/1071 I've added $200 to the associated bounty, if that even matters.
Re: Ocean preview finally open sourced
On Thursday, 30 June 2016 at 16:45:43 UTC, Leandro Lucarella wrote: (although please have a look at the licensing terms, even when all our code is Boost, there is code inherited from Tango that isn't), criticize it, and if you are really nice, fill issues and make pull requests! I find the licensing a bit confusing. For instance https://github.com/sociomantic-tsunami/ocean/blob/v2.x.x/src/ocean/math/Probability.d Lists the licensing as: Tango 3 BSD Clause + Academic Free License v3.0. But the original work Cephes seems to carry this ad-hoc license: https://github.com/jeremybarnes/cephes/blob/master/readme « Some software in this archive may be from the book _Methods and Programs for Mathematical Functions_ (Prentice-Hall or Simon & Schuster International, 1989) or from the Cephes Mathematical Library, a commercial product. In either event, it is copyrighted by the author. What you see here may be used freely but it comes with no support or guarantee. The two known misprints in the book are repaired here in the source listings for the gamma function and the incomplete beta integral. » Maybe it would be a good idea to sort out the code that is pure Boost, or obtain a boost license where the authors are known, because complicated licensing is a hindrance even if the "spirit" is the same across the licenses.
Re: Ocean preview finally open sourced
On Friday, 1 July 2016 at 08:54:27 UTC, Leandro Lucarella wrote: Maybe in some future we might want to do some sort of separation between the more algorithmic stuff and the more platform-dependent stuff, because we actually spent quite some time and effort in removing some Tango's abstractions. It is a very conscious design decision to remove as many abstraction layers as possible, and for the platform-dependent part, we definitely don't want to go back. We need to work very closely to the OS facilities, so abstractions are plain noise and source of inefficiency for us :) But if there is interest, I don't discard the splitting idea in some future. It'd be great, if there was some sort of separation so that users know exactly what to use for cross-platform development and what not. Docs or some sort of a cheat sheet would be nice too. In this way users can see, if Ocean contains something interesting for the task at hand. There's less of a chance of adoption, if you have to go through the source code to see what it does.
Re: Ocean preview finally open sourced
On Thursday, 30 June 2016 at 21:32:47 UTC, Chris wrote: On Thursday, 30 June 2016 at 21:20:16 UTC, Leandro Lucarella wrote: I'd say some parts should work out of the box (there many things that are completely OS agnostic, like containers, cache, bindings to other libraries like PCRE, etc.), and some other it would be quite some work (for example all the I/O is tied to epoll, there is one class to work with direct I/O that's super Linux specific, etc.). Hm. I'd have to see what works. I can't afford to be stuck to one OS. Maybe in some future we might want to do some sort of separation between the more algorithmic stuff and the more platform-dependent stuff, because we actually spent quite some time and effort in removing some Tango's abstractions. It is a very conscious design decision to remove as many abstraction layers as possible, and for the platform-dependent part, we definitely don't want to go back. We need to work very closely to the OS facilities, so abstractions are plain noise and source of inefficiency for us :) But if there is interest, I don't discard the splitting idea in some future.
Re: daffodil, a D image processing library
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.
Re: daffodil, a D image processing library
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.
Re: one-file pure D decoders for vorbis, flac and mp3
vorbis decoder synced with current stb version (1.06 -> 1.09)
