To be clear, I am not the maintainer of HOpenCV. I have used a fork of that library for experimenting with OpenCV interfaces over the past few years, and written quite a few kloc using it in several robotics oriented projects with computer vision needs. None of my experiments with HOpenCV are on hackage as they are experiments, but I have helped others get started with them over time.
I am totally supportive of Arjun's new efforts: OpenCV has changed a lot, and there is reason to be optimistic that he will be able to provide a much better foundation for Haskell bindings than we have ever had. As the low level bindings come online, we will be able to introduce some of the extra type-driven code paths and static checks that have proven successful in the existing fragmented Haskell-OpenCV ecosystem. Anthony > On Sep 28, 2013, at 2:31 PM, Arjun Comar <nru...@gmail.com> wrote: > > I've been talking to Anthony Cowley who I think is the current maintainer of > HOpenCV and Ville Tirronen who has been developing the CV bindings. Basically > the consensus is that these raw bindings provide a new base to work from, and > it's worthwhile to rethink the API we provide with a fresh start. > > >> On Sat, Sep 28, 2013 at 2:23 PM, Ivan Perez <ivanperezdoming...@gmail.com> >> wrote: >> The people working on HOpenCV are very open to incorporating other's >> programmer's patches. Maybe you can incorporate your changes to >> cv-combinators? (Project's been halted since 2010, I'm sure they'll be very >> happy to see that sb is contributing). >> >> >>> On 28 September 2013 19:13, Arjun Comar <nru...@gmail.com> wrote: >>> 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
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
