Hi everyone!

For a while I was looking for a computer vision library in D on the web, but haven't found any. There were few libraries I found, providing some basic image processing functionality, but none that could be remotely compared to opencv or other similar open source computer vision toolkits present for other languages. Surely for a year, even maybe two, this has been stopping me to switch completely to D from C/C++.

Anyhow, lately I've started working on such library [1]. The plan at first was to implement the most basic computer vision algorithms, on top of which other more complex algorithms could be built on. So far, I've mostly had experience with feature correspondence, optical flow and stereo vision, so those would probably be the first few modules I'd implement.

But I was really hopping to find other computer vision people in the D community, that would like the idea and help out. I'm not well experienced in D, and also It's fair to say that I'm not experienced well enough in computer vision area to take on an undertaking such as writing this library alone. So I feel it's evident that I'd need some help, to make this library usable to other computer vision scientists and engineers.

Is there anyone who would like to join me?

Cheers,
Relja

[1] https://github.com/ljubobratovicrelja/dcv

On Tuesday, 19 April 2016 at 17:01:12 UTC, Relja Ljubobratovic wrote:
> [1] https://github.com/ljubobratovicrelja/dcv

Standard modules for color conversion already exists. See for instance

https://github.com/TurkeyMan/color
https://github.com/adamdruppe/arsd/blob/master/color.d

Great that you've made compatible with ndslice!

On Tuesday, 19 April 2016 at 17:01:12 UTC, Relja Ljubobratovic wrote:
> Hi everyone!
>
> For a while I was looking for a computer vision library in D on the web, but haven't found any. There were few libraries I found, providing some basic image processing functionality, but none that could be remotely compared to opencv or other similar open source computer vision toolkits present for other languages. Surely for a year, even maybe two, this has been stopping me to switch completely to D from C/C++.
>

OpenCV has a C interface. 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?

On 19.04.2016 19:01, Relja Ljubobratovic wrote:
> [1] https://github.com/ljubobratovicrelja/dcv

You've got a bad @trusted here:

https://github.com/ljubobratovicrelja/dcv/blob/3b7e4908bfb535536f4b71862239ee071d22461d/source/dcv/core/algorithm.d#L23

You're trusting Range's empty, front, and popFront, but they may be unsafe. You're also trusting arbitrary code that's passed in via comparator.

On Tuesday, 19 April 2016 at 17:01:12 UTC, Relja Ljubobratovic wrote:
> Hi everyone!
>
> For a while I was looking for a computer vision library in D on the web, but haven't found any. There were few libraries I found, providing some basic image processing functionality, but none that could be remotely compared to opencv or other similar open source computer vision toolkits present for other languages. Surely for a year, even maybe two, this has been stopping me to switch completely to D from C/C++.
>
> Anyhow, lately I've started working on such library [1]. The plan at first was to implement the most basic computer vision algorithms, on top of which other more complex algorithms could be built on. So far, I've mostly had experience with feature correspondence, optical flow and stereo vision, so those would probably be the first few modules I'd implement.
>
> But I was really hopping to find other computer vision people in the D community, that would like the idea and help out. I'm not well experienced in D, and also It's fair to say that I'm not experienced well enough in computer vision area to take on an undertaking such as writing this library alone. So I feel it's evident that I'd need some help, to make this library usable to other computer vision scientists and engineers.
>
> Is there anyone who would like to join me?
>
> Cheers,
> Relja
>
> [1] https://github.com/ljubobratovicrelja/dcv

Hi Relja,

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.

https://github.com/DlangScience/mir

Best regards,
Ilya

On Tuesday, 19 April 2016 at 17:01:12 UTC, Relja Ljubobratovic wrote:
> Hi everyone!
>
> For a while I was looking for a computer vision library in D on the web, but haven't found any. There were few libraries I found, providing some basic image processing functionality, but none that could be remotely compared to opencv or other similar open source computer vision toolkits present for other languages. Surely for a year, even maybe two, this has been stopping me to switch completely to D from C/C++.
>
> [...]

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.

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.

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?

Its one of the things I need for my work e.g. windowing + image.

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.

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!

On Wednesday, 20 April 2016 at 04:31:33 UTC, Relja Ljubobratovic wrote:

>> 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.

I have an implementation of BFGS in D (except [open]BLAS :). BFGS is an algorithm for unconstrained optimization of nonlinear smooth functions. It is NOT L-BFGS and requires O(n*n) memory for optimizing f: R^n -> R. The linesearch may be useful to implement other algorithms.

It works fine for me, but needs some refactoring. Given existing bindings for nlopt: would this be useful? If so, I start the refactoring.

For now, there are no benchmarks, but it is definitely faster/fewer iterations than optim(method="BFGS") in R and the algorithm should be better than the version in GSL (if n is not too large, GSL uses some kind of L-BFGS).