DCV v0.2.0 - adaptation to the new ndslice
Hi everyone, I wanted to let you know that we've released new version of DCV[1], an open source computer vision library, written in D programming language, with goal to provide tools for solving most common computer vision problems - various image processing tasks, feature detection and tracking, camera calibration, stereo etc. Major change in this one is the integration of new ndslice package[2], Ilya Yaroshenko has been working on for past couple of months. These major API braking changes have initiated following refactoring of the library[3]. We've recognized some critical design errors, and until those are sorted out, we've paused the implementation of new features. But, with help of more experienced colleagues at libmir org[4], hopefully we'll soon have a stable API, upon which we'll safely build new computer vision algorithms. Best regards, Relja [1] https://github.com/libmir/dcv [2] https://github.com/libmir/mir-algorithm [3] https://github.com/libmir/dcv/issues/87 [4] https://github.com/libmir
Re: Vibrant 2.0, major update
On Monday, 13 February 2017 at 14:22:25 UTC, Guillaume Piolat wrote: It's the 10th update for this abstract shooter made in D. This is the first time I've heard of this game. Downloaded the demo, and first impressions were mind blowing! Gameplay seems very fluid and well calibrated. But, I've got to say - most awesome element of the gameplay is definitely the music! This might be the most impressive sound I've heard coming from my macbook since I've bought it! Truly drives the mood in the game. :) I've gladly payed for the full version, and will spread the word of this game whenever I can. Congrats, and thank you!
Re: macOS: debugging hell - strange behavior in lldb and gdb
On Tuesday, 14 February 2017 at 20:32:53 UTC, John Colvin wrote: The docs say it is, but they could be wrong. Could you run dub with -v (and without any manually added -gc) and share the output? Sure, here's what I'd think is the relevant part: Performing "debug" build using ldc2 for x86_64. File '/Users/relja/Projects/dlangplayground/dub.json' modified, need rebuild. dlangplayground ~master: building configuration "application"... ldc2 -mcpu=haswell -of.dub/build/application-debug-posix.osx-x86_64-ldc_2071-A59B2D18A3A7E59FF17DA8905B6773B0/dlangplayground -d-debug -g -w -oq -od=.dub/obj -d-version=Have_dlangplayground -Isource/ source/app.d -vcolumns So, no -gc. Btw. it seems like I'm using dub v1.1.2 from homebrew: $ dub --version DUB version unknown, built on Jan 16 2017 $ readlink /usr/local/bin/dub ../Cellar/dub/1.1.2/bin/dub I'll test this with newer releases in the next few days, and if situation is the same, I'll file a bug. Once again, thanks man - feels fantastic having a debugger once again! :) Cheers, Relja
Re: Compiling to shared library with static dependencies
On Wednesday, 14 December 2016 at 22:17:25 UTC, Tanel L wrote: First of all thanks Johan for urging me to compile it with only with that flag. It worked! Previously I tried to compile it with only BUILD_SHARED or both - and that failed. But I got it working. Thanks! More details below. Awesome! Thanks, I will use this as a template in the future. Please don't :) - consider other options (D is full of them, I'm sure you'll find much more elegant solution), I pulled this just as a quick test! Thanks, I don't need ffmpeg and I will surely use your advice. I am not worried about the size much. Is there any way to include many/most of them into the binary? Or should I just ship the deps alongside the shared lib? You could build ffmpeg for static linking, but I'm not sure about ggplotd's deps - I suppose there's a way I just haven't done it before. Success! Thank you both so much. With this I can successfully move forward with using D in our company :) Congrats! - if it's possible keep us posted of your endeavors for which you're using Mir and DCV! And of course, feel free to make a question, bug report, feature request etc at our repositories: https://github.com/libmir/mir https://github.com/libmir/dcv All of the best, Relja
Re: Compiling to shared library with static dependencies
On Wednesday, 14 December 2016 at 21:41:53 UTC, Relja Ljubobratovic wrote: use just dcv:core with imageformats[1] http://code.dlang.org/packages/imageformats
Re: Compiling to shared library with static dependencies
On Wednesday, 14 December 2016 at 20:46:15 UTC, Tanel L wrote:
Hi, thanks for the answer.
I had tried disabling all imports, but now I created a clean
new project to test this - it worked.
Awesome. So LDC compile-link is ok, and also python runtime
linking is good.
After that I moved the compiling and linking over to DUB, with
dependencies:
dependency "dcv" version="0.1.7"
dependency "mir" version="0.22.0"
targetPath "output"
targetType "dynamicLibrary"
dflags "-defaultlib=phobos2"
Why are you defining defaultlib explicitly here? - wouldn't this
work fine without it? Also, like I said before, try removing mir
from dependencies since its included with dcv.
The library source:
import std.stdio;
import dcv;
import core.runtime:Runtime;
extern (C) int doit(int a, int b) {
return a*b + dcv.imread("1.jpg").width.to!int;
}
Did you actually call Runtime.initialize before calling doit?
Also, did you try the same code in ordinary D app? Anyways, this
works for me:
D source
import std.stdio;
import core.runtime;
extern (C) void initd()
{
Runtime.initialize;
}
extern (C) void terminated()
{
Runtime.terminate();
}
extern (C) void showim()
{
import dcv;
auto im = imread("img.jpg");
imshow(im);
waitKey();
}
Python source
from ctypes import *
d = CDLL("libctypestest.so")
d.initd()
d.showim()
d.terminated()
This created an .so with huge amount of all kinds of external
so deps, but it still failed with the same error:
OSError: libdynlibtest.so: undefined symbol: _d_eh_personality
All kinds of external deps are expected since dcv is linking to
ggplotd and ffmpeg, which also link to whole lotta libraries. I'm
not sure about the binary size though. If you can, use only
dcv:core which has no other dependencies other than Mir. Also,
dcv:io links to ffmpeg at the moment, but if you need only image
i/o and would like to avoid linking to ffmpeg, you could use just
dcv:core with imageformats[1] (dcv wraps it's io methods in
imread). If you need help with this let me know.
Otherwise:
Linux Mint 18 (basically Ubuntu 16.04)
LDC - the LLVM D compiler (1.1.0-beta6):
based on DMD v2.071.2 and LLVM 3.9.0
built with LDC - the LLVM D compiler (1.0.0)
gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
DUB version 1.1.1, built on Nov 30 2016
Thank you for helping! :)
Hey, no sweat - its a pleasure! I'm really glad you'd like to use
D (and Mir and DCV for that matter). I'd really like to help you
out as much as I can, so this can work out for you! :)
Cheers,
Relja
Re: Compiling to shared library with static dependencies
On Wednesday, 14 December 2016 at 12:33:04 UTC, Tanel L wrote:
Hello,
Hi Tanel,
I have just tried replicating the task you describe, and it
worked flawlessly for me.
I am very new to the D world - but serious in moving over to it
after I have seen what a cool language it really is.
I am trying to incorporate D into our main product as an
externally loadable module.
Basically I have a minimal project:
./app.d
./helpers/image.d (mir and dcv libraries imported)
./helpers/utils.d
I am using the latest (statically compiled) ldc2
In my app file(besides the void main) I have a test function
which I am trying to call from python using ctypes:
extern (C) int doit()
Probably a dumb question - have you tried compiling your library
without dependencies, and using it through ctypes? Does this work?
Currently I have gotten as far as getting a loading error in
python:
library.so: undefined symbol: _d_eh_personality
Googling disclosed that this is satisfied by libdruntime.so,
but I don't have a shared libdruntime anywhere. I guess I have
to compile ldc2 in dynamic mode and use the libdruntime.so from
there?
My build steps until now:
dub.sdl (pseudocode):
project_description "nudesc"
dependency "mir"
dependency "dcv"
targetPath "lib"
dflags "-relocation-mode=pic"
dub build --compiler ldc2
cp .dub/obj/*.o lib/
cd lib
ldc2 -of library.so helpers.image.o helpers.utils.o nudesc.o
-shared -defaultlib=phobos2
Why are you linking manually? Why not let dub do the job? Also, I
believe if you're adding dcv as dependency, you don't need to add
mir, since mir is the dependency of dcv. (it has worked for me
this way so far) but this has nothing to do with errors you
describe.
strace shows that ldc2 loads "phobos2" from DMD:
"/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libphobos2.so"
The LDC2 folder only seems to contain libphobos2-ldc.a, no
.so's.
Compilation succeeds, but trying to load the so from python:
python -c "from ctypes import *; CDLL('library.so',
mode=RTLD_GLOBAL)"
OSError: library.so: undefined symbol: _d_eh_personality
I figured that I don't have druntime.so available because
druntime is incorporated into LDC2, but mine is statically
compiled (downloaded precompiled from github i think).
Again, dumb one (and I'm quite sure this is not the issue) - have
you initialized druntime in the doit function?
So I tried to compile LDC2 dynamically:
cmake .. -DBUILD_SHARED=ON
But I get a bunch of these errors before the LDC2 build fails:
/home/tanel/thirdparty/ldc-dynamic/build/bin/ldc2: error while
loading shared libraries: libldc.so: cannot open shared object
file: No such file or directory
runtime/CMakeFiles/druntime-ldc.dir/build.make:93: recipe for
target 'runtime/src/core/bitop.o' failed
make[2]: *** [runtime/src/core/bitop.o] Error 127
Basically I am cornered... I really need to be able to compile
dcv and mir into my dynamic libraries. Probably LDC2 is a must
because DMD and GDC have given me compilation errors on the
project even in regular mode. Also LDC2 seems to be the best.
Any ideas what to do or how to proceed?
Thanks a bunch!
What is your configuration - OS, ldc and gcc version etc.?
Anyhow, I'm surely not the best person to help here - I hope some
of more experienced guys will drop a word to help you out...
And for the end, have you tried creating the python module with
pyd[1]?
Cheers,
Relja
[1] https://github.com/ariovistus/pyd
Re: Mir Blog: Writing efficient numerical code in D
On Tuesday, 13 December 2016 at 15:31:00 UTC, Mike Parker wrote: https://www.reddit.com/r/programming/comments/5i42vc/writing_efficient_numerical_code_in_d/ Thank you, Mike!
Re: Mir Blog: Writing efficient numerical code in D
On Tuesday, 13 December 2016 at 05:27:01 UTC, Andrei Alexandrescu
wrote:
I'm about to fall asleep, but I made a quick pass through the
piece. Here are a few nits:
Thanks for an extensive feedback, Andrei! I've followed up 99% of
fixes given here[1], but unfortunately I'll be unavailable for
the rest of the day, so I'm passing the torch (or the hot potato)
to Ilya.
* "we’ve been actively refactoring" -> define the team; so far
the article referred to the author as a single person
I've done the coding, but couldn't have done it without Ilya's
consulting, so I put the 'Mir team' there. Hope thats ok.
* "On my machine" -> "On a Core i7 laptop with xyz GB or RAM
and xyz other relevant parameters..."
There are specs shown at the top of the post, so I thought it
would be best just to remove the "On my machine part". Again, I
hope that's alright.
I suggest making two passes through the piece: (a) one pass
should reduce fillers that are abundant ("as you can see", "as
I'll show you", "as said in the docs"...) A few are fine
(perhaps 2-3 in the whole article. Then (b) one pass looking
for unified use of "I" (most likely: the author, use
sparingly), "you" (the reader, use sparingly), and "we" (most
likely: the author and reader looking together at something).
As I've demonstrated, I'm quite unexperienced with writing. :)
So, thanks for the feedback, I've learned a lot! If I catch some
time during the day, I'll be sure to take another glance at it!
The results are terrific, congrats Ilya and Relja!
Andrei
Thanks a lot Andrei!
Relja
[1] https://github.com/libmir/blog/pull/32
Re: Mir Blog: Writing efficient numerical code in D
On Monday, 12 December 2016 at 22:34:32 UTC, Johan Engelen wrote: On Monday, 12 December 2016 at 21:58:23 UTC, Relja Ljubobratovic wrote: Hey guys, We have just published another post on "Writing efficient numerical code in D", to Mir's Blog[1]. Nice :) Thanks! :) Some comments: - You can make the numbers in the table more readable by adding commas? For example, 1624687 --> 1,624,687. Probably even better is to only show the most significant digits. 1624687 us --> 1.625 s for example. Great suggestion - I was focusing on the speedup, so I didn't pay attention to run time, but obviously other people will. - Add a sentence about the benchmarking set up. " The numbers shown are the best times of 10 trials, with LDC commandline options `ldc2 -O3 -release`" Something like that. Or add it to the configuration table. Thanks, will do. I agree there's an explanation missing on how benchmark is configured. - For the "convolution" example, could you elaborate on why the Mir-based implementation is so much faster than the C-like implementation? From the big table, I see that the speedup for DCV's convolution algorithms is not as large as 10x. DCV's convolution is parallelized, which I believe, could be the reason. Ilya is probably the best man to elaborate the speedup vs C implementation. - The "threshold" algorithm has a 19x speed up?! (I would remove "threshold" from the average improvement calculation. The numbers are already awesome, no need to oversell it!) I agree. I was thrilled when I saw the comparison at first, but to be honest, I'm not sure what's the main reason. Here's the commit diff if anyone is interested to explain: https://github.com/libmir/dcv/pull/58/commits/0c744a7bb7308f07bd45d041c6e88e906c905fcf - Overall, does this mean that DCV became more than twice as fast? How does it stack up to other vision libs after this massive speed boost? I'm not sure. But I'm afraid we're not even close to opencv, since its base image processing (and other) algorithms have been intensively (manually) optimized with SIMD, but also have almost 100% coverage with OpenCL (and CUDA from 3.x). Anyhow, I'd like not to bother with comparisons like this until we are satisfied with DCV - there's much work yet to be done, IMHO. cheers, Johan Thanks for the feedback Johan!
Mir Blog: Writing efficient numerical code in D
Hey guys, We have just published another post on "Writing efficient numerical code in D", to Mir's Blog[1]. In this post we are focusing on mir.ndslice.algorithm usage in DCV[2], computer vision library that has recently joined libmir organization. We've had great success in optimizing DCV's algorithms mostly by replacing loop-style code with mir.ndslice.algorithm multidimensional iteration utilities[3], and we thought it was worth blogging about. Any grammar (or any other type of) fix report is greatly appreciated! Also, we'd like to ask Mike Parker to forward this to reddit if it's not too much trouble? :) Maybe only wait few days so we could weed out some mistakes from the text. Cheers, Relja [1] http://blog.mir.dlang.io/ndslice/algorithm/optimization/2016/12/12/writing-efficient-numerical-code.html [2] https://github.com/libmir/dcv [3] https://github.com/libmir/dcv/pull/58
Re: Neural Networks / ML Libraries for D
On Tuesday, 25 October 2016 at 11:17:29 UTC, Saurabh Das wrote: Hello, Are there any good ML libraries for D? In particular, looking for a neural network library currently. Any leads would be appreciated. Thanks, Saurabh There is also Henry Gouk's dnnet library[1]. I'm not sure how far is it in development, since there's no dub project registered at code.dlang.org, but you could give it a spin. AFAIK it relies another package of his, dopt[2][3], which depends on CUDA (cuBLAS and cuDNN). [1] https://github.com/henrygouk/dnnet [2] https://github.com/henrygouk/dopt [3] http://code.dlang.org/packages/dopt
Re: Neural Networks / ML Libraries for D
On Wednesday, 26 October 2016 at 12:13:16 UTC, Ilya Yaroshenko wrote: https://github.com/ljubobratovicrelja/mir.experimental.model.rbf Now moved to https://github.com/libmir/mir-neural
Re: ndslice: feature deprecation voting / discussion
On Sunday, 2 October 2016 at 16:36:14 UTC, jmh530 wrote: Wouldn't it be more flexible to allow both ways? If D can handle the case without brackets without any issue, why force it? In Matlab, writing ones(2, 2) produces a 2x2 matrix of ones. In numpy, I would write np.ones((2, 2)) I find it annoying that in numpy I have to constantly remember to put in the second set of parentheses. This idea is basically forcing the same issue into ndslice. I think it's a bad idea. I feel the same way. +1 here
Re: From the D Blog: Martin Nowak on the DMD release process
On Monday, 15 August 2016 at 08:37:16 UTC, Mike Parker wrote: Hi, Relja. Now that this is on my radar, I'll be in touch with you about putting a post together some time in the next couple of weeks. Hi, Mike. That's awesome, thanks!
Re: From the D Blog: Martin Nowak on the DMD release process
On Monday, 15 August 2016 at 07:41:59 UTC, Ilya Yaroshenko wrote: On Monday, 15 August 2016 at 07:37:25 UTC, ZombineDev wrote: On Monday, 15 August 2016 at 07:32:34 UTC, Ilya Yaroshenko wrote: On Monday, 15 August 2016 at 06:55:18 UTC, Suliman wrote: On Friday, 29 July 2016 at 12:09:46 UTC, Mike Parker wrote: [...] I do not know with whom I should contact, but this release https://github.com/ljubobratovicrelja/dcv should be mention in D blog. +1 and my 0.02$: please add the note that it is based on ndslice! I think it would be great if you and the other people involved with using "D for science" make a series of blog posts about the great work you've all been doing with those libraries. Yes, we will do it this month after the next Mir release, which will include first part of generic linear algebra subroutines, ndslice.algorithm draft and our GSoC project - Flex. Thanks guys for recognizing DCV project as D blog material! If I can offer any help, please let me know - I'd be glad to contribute. Ilya, just wanted to say I'm already trying to promote ndslice, wherever I can- note the "API" section in site's home page[1]! If you have any suggestions or requirements for content related to ndslice or mir project on DCV site, please let me know. Cheers, Relja [1] https://ljubobratovicrelja.github.io/dcv
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 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 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: Commercial video processing app in D (experience report)
Awesome! Thanks so much for such detailed explanation! Btw, if you're interested in an image processing app in pure D, I've got one too: http://www.infognition.com/blogsort/ (sources: https://bitbucket.org/infognition/bsort ) Great, I'll check it out - Thanks!
Re: Commercial video processing app in D (experience report)
On Wednesday, 27 April 2016 at 12:42:05 UTC, thedeemon wrote: Hi, I just wanted to share some experience of using D in industry. Recently my little company released version 2.0 of our flagship product Video Enhancer, a video processing application for Windows, and this time it's written in D. http://www.infognition.com/VideoEnhancer/ Awesome work, congratulations! Can you share with us some of your experience working on image and video processing modules in the app, such as are filters here: http://www.infognition.com/VideoEnhancer/filters.html If I may ask, was that part implemented in D, C++, or was some 3rd party library used? Thanks, and again - big congrats! Relja
Re: Computer Vision Library in D
On Thursday, 21 April 2016 at 16:13:31 UTC, Bill Baxter wrote: Fortran has some linear algebra functions in the standard library. :-) Java and many other modern languages are pretty much actively hostile to doing numerical computation, so including a linear algebra package in the standard library of those languages would just highlight how bad they are at it. C++ has a tradition of not having a standard library for anything you might actually need to get work done, so I wouldn't follow their example. --bb Nice point about the Fortran, and also about the C++. :) I'd have to say I'm convinced - if there's a vote about such module joining Phobos, count me in! :) But really, when you look at it - the ndslice has made it to the Phobos, now it's probably natural to have some more extensive use of it in the standard library. Linear algebra stuff could be build nicely on top of the ndslice, you agree?
Re: Computer Vision Library in D
On Wednesday, 20 April 2016 at 04:37:10 UTC, rikki cattermole wrote: On the note of linear algebra. Would you be willing to improve gfm:math (or start from scratch I don't really care too much) for Phobos inclusion? Frankly, I didn't know about the gfm project - it seems nice! About the math module, I'm not really sure how (or where) it would fit into Phobos? Seems to me that such module really should be kept as a library. Isn't there a isolated 3D math library present in dub? Anyways, I'll look into it more closely when I find time! Also how much do you know about color theory? Manu really needs help to get his color work to support blending (its mostly time thing really) and that would really help since its meant for Phobos. I've given it only a quick look just now, and it seems great! - I'll definitely look into it!
Re: Computer Vision Library in D
Hey guys, thank you all for responding! Standard modules for color conversion already exists. See for instance That's awesome, thanks! - I'll look into it! Wouldn't it be easier to just write bindings to C interface of OpenCV, or make a thin D-style wrapper over that API, and use a proven widely supported computer vision library rather than try to reinvent the wheel? I've given this a lot of thought. I use OpenCV daily on the job, and I'm very familiar with it. I too believe it would probably be smarter, faster and safer to wrap its C interface with D, from the user's point of view. The reason why I chose not to do it is it's complexity - OpenCV has everything implemented/integrated inside - linear algebra, machine learning, optimization and all the other submodules that are needed for cv. In the dcv project, I'd really like to rely on third party libraries for such functionality - actualy I was encouraged and inspired to do it because of DlangScience guys. I'm hopping that scid and other such libraries would get a interface with ndslice in time, which is the reason I chose to use it as main array structure in the library. I believe (as many do I'm sure) that through the ndslice, D would get numeric ecosystem nice and well integrated as python, which I think would be a great success for the language. So the long story short - we could build a opencv wrapper, but here I wanted to start building something that would more nicely fit with DlangScience and other D libraries. You've got a bad @trusted here Thanks - I'll fix it and try to learn bit more about @trusted! I am happy to see that you use ndslice. We start to build numeric library for science and machine learning. SVM, which is used in CV is in out TODO list. You are welcome for feature request and for contributing. Hey Ilya! The text above tells that I've been closely following your work, and that I hope ndslice plays important part in D's numeric future. I will of course watch the SVM and other such projects from you guys, and will contribute whenever I can - thanks a lot for your effort! I'm interested in contributing towards parts that involve machine learning/numerical optimisation. I have written some of my own CV/ML programs with D in the past, but none of them are particularly well engineered since they were all intended for just my own use. That's great, thanks Henry! As I've noted above, I think it would be wise to keep modules like ML and optimization apart from this library, and to integrate dcv with them through ndslice. Maybe it's more likely that you could contribute to DlangScience's SVM libray with those parts? But any of your previous CV experience is more than welcome for DCV - I'll contact you on the github so we could discuss this further, hope that's ok.
