Fair enough, it's been two or three years since I tried to play with them. Most of my work is in the raw bindings currently, which provide the C++ API in Haskell, so much lower level that cv-combinators. If HOpenCV were to incorporate parts of these bindings then cv-combinators would be able to benefit from this work. That said, my effort going forward is to provide something equivalent to cv-combinators in expressiveness. I'm definitely taking inspiration from the library though I'm not basing my work on their source code.
On Sat, Sep 28, 2013 at 12:51 PM, Ivan Perez <ivanperezdoming...@gmail.com>wrote: > I think they do work. cv-combinators depends on HOpenCV, which depends on > OpenCV 2.0. > > > > On 28 September 2013 16:03, Arjun Comar <nru...@gmail.com> wrote: > >> No, these are unrelated. Cv-combinators hasn't really worked since OpenCV >> 2.0 waa released I believe. >> On Sep 28, 2013 8:54 AM, "Ivan Perez" <ivanperezdoming...@gmail.com> >> wrote: >> >>> Cool. Thanks a lot for uploading this. >>> >>> I have a question (and I confess that I haven't checked the link). How >>> is this related to or overlaps with cv-combinators? >>> >>> Cheers >>> Ivan >>> >>> >>> On 28 September 2013 06:18, Arjun Comar <nru...@gmail.com> wrote: >>> >>>> After receiving feedback, I went ahead and split out the raw C wrappers >>>> and Haskell bindings. You can find them at >>>> www.github.com/arjuncomar/opencv-raw. I'll upload it to hackage as >>>> opencv-raw once I have uploader privileges. >>>> >>>> Regards, >>>> Arjun >>>> >>>> >>>> On Fri, Sep 27, 2013 at 4:09 PM, Arjun Comar <nru...@gmail.com> wrote: >>>> >>>>> Hi all, >>>>> I've been hard at work on a new set of OpenCV bindings that will >>>>> hopefully solve a lot of the shortcomings with previous attempts. An >>>>> automatic header parser has been used to generate a full set of Haskell >>>>> bindings for the C++ API, and I'm now working to create a pleasant Haskell >>>>> API. The plan is to expose major functionality through pipes for two >>>>> reasons: 1) OpenCV is not very referentially transparent, and so you're >>>>> stuck in IO for anything non-trivial. Lazy IO is potentially problematic, >>>>> and so immediate incorporation of a proper streaming library is probably >>>>> best. 2) Computer vision algorithms are frequently expressed in terms of >>>>> pipelines of functionality, and a pipes approach can provide a very >>>>> natural >>>>> API for expressing these algorithms. >>>>> >>>>> At this stage, I could very much use input from anyone who's >>>>> interested in these bindings. I've got the basics of a library forming, >>>>> but >>>>> there's a ton to do and help in the form of pull requests are very very >>>>> welcome. I could also use feedback on what's been done so far (especially >>>>> criticisms) as well as feature requests. >>>>> >>>>> The current plan is to develop the pipes API for the core >>>>> functionality. The plan is to provide the major functionality from core, >>>>> highgui, imgproc, features2d, contrib, ml, flann, video, and objdetect as >>>>> quickly as I can before trying to cover any of the more specialized parts >>>>> of the API. The functions and types from these modules (baring a few major >>>>> and important exceptions) are automatically translated into C wrappers and >>>>> raw Haskell bindings. >>>>> >>>>> If there's sufficient interest in these raw bindings separately from >>>>> the API I'm developing, I'll release them as a separate package on >>>>> Hackage. >>>>> I'm calling my project revelation for the moment because I'm bad at naming >>>>> things and it was the best pun I could come up with. >>>>> >>>>> Github: www.github.com/arjuncomar/revelation >>>>> >>>>> Regards, >>>>> Arjun >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe@haskell.org >>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>>> >>>> >>> >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe