Vadim,
You're correct. As far as python is concerned, it would be calling a
single C function (which was actually written in cython and consists
of multiple calls to the opencv library) and is free to do other
things while that function is executing.
There is branch of python being done by the google engineers called
Unladen Swallow which seeks to reimplement the python VM in a register
based LLVM with JIT compilation, thus getting rid of the gil.
It looks promising (they already have a working release), and they
have a page on google code.
Chris
On Thu, Jul 2, 2009 at 3:35 PM, Vadim
Pisarevsky<vadim.pisarevsky@gm...> wrote:
> Chris,
> Ok, I seem to understand the rationale and your approach. So, from the
> Python interpreter point of view, these multiple chained functions would
> look as a single call to a C function, right?
> I did not know much of Python internals, but it now seem to me that this is
> quite a problem with GIL - looks like Python is not catching up with
> multi-core trends.
> Hopefully, Python developers find a way to eliminate the problem completely
> in some not very distant future.
> Regards,
> Vadim
> On Thu, Jul 2, 2009 at 9:37 PM, Chris Colbert <sccolbert@gm...> wrote:
>>
>> Alright, I'll continue development work on my wrapper then.
>>
>> the reason i started in in the first place is that the ctypes wrapper
>> has one main flaw. It returns control to python after every function
>> call. So while the GIL is released during function execution, its
>> picked back up again right after, thus limiting multi-threaded
>> performance.
>>
>> In my cython wrapper, behavior is essentially the same as in ctypes in
>> that each function releases the GIL and then picks it up again on
>> function return. However, using the interface I expose allows the user
>> to chain multiple functions together IN CYTHON that all execute
>> outside the GIL. So where in ctypes, you would have to write a c
>> script and compile to a dll. Now, you write a cython script which
>> compiles to a python module. But in the cython script, you'll work
>> with my cython api which has already done much of the work for you.
>>
>> Of course, when the wrapper gets more mature and complete, I'll put
>> out some examples.
>>
>> Chris
>>
>> On Thu, Jul 2, 2009 at 1:19 PM, Vadim
>> Pisarevsky<vadim.pisarevsky@gm...> wrote:
>> > Hi Chris,
>> > I'm copying it to the group since others may be curious as well.
>> > See below
>> > Regards,
>> > Vadim
>> >
>> > On Thu, Jul 2, 2009 at 7:26 PM, Chris Colbert <sccolbert@gm...>
>> > wrote:
>> >>
>> >> What's the new python wrapper based on, if it's not ctypes or swig?
>> >
>> > Perhaps, James would be the best person to answer that, but as I
>> > understand,
>> > it's special, tailored for OpenCV, Python script that generates the
>> > wrapper
>> > (as a C source file) based on some manually prepared description file
>> > that
>> > lists all the functions and their parameters.
>> > Since we can fully control generator, the generated Python API is not
>> > just
>> > replication of C API, it's more Pythonic, e.g. output parameters become
>> > the
>> > return value (or a tuple, in case of multiple output parameters), e.g:
>> > cvErode(A, B) in C becomes B = erode(A) in Python.
>> > One benefit of using this instead of ctypes and Cython is that it does
>> > not
>> > rely on the ABI, and thus the new C++ interface can also be wrapped.
>> >
>> >>
>> >> I spent another day hacking out my Cython wrapper yesterday and it
>> >> basically amount to redeclaring everything from the opencv header
>> >> files and the implementing them in Cython. Relatively straight
>> >> forward, just time consuming. The nice thing about the cython wrapper
>> >> is maintainability and easy manipulation of the GIL.
>> >>
>> >> At any rate, If there will be significant changes to header file
>> >> structure for the 2.0 release, it would ammount to a large code
>> >> re-write for my wrapper.
>> >
>> > While in this release we introduced the new API, the previous-gen API
>> > from
>> > 1.1pre, 1.0 etc. (see cxcore.h, cv.h etc.) is still maintained and
>> > supported, so the existing Python wrappers should work fine with 2.0.
>> >
>> >>
>> >> In which case it my efforts might be better
>> >> served helping Mr. Bowman with the new wrapper.
>> >
>> > Of course, multiple variants of wrappers can be used with OpenCV, it's
>> > open-source world in the end. Though, if we consolidate our efforts on
>> > 1-2
>> > of them, we'll likely get more with the same amount of work. So you are
>> > welcome to join us (and let me repeat once more that API compatibility
>> > is
>> > preserved, all your wrappers should work fine)
>> >
>> >>
>> >> Cheers,
>> >>
>> >> Chris
>> >>
>> >>
>> >>
>> >> On Thu, Jul 2, 2009 at 10:01 AM, Vadim
>> >> Pisarevsky<vadim.pisarevsky@gm...> wrote:
>> >> > Dear OpenCV developers and other readers of this list,
>> >> > Sorry for posting this late, but finally here is the preliminary
>> >> > information
>> >> > about OpenCV 2.0 (right, there will be no 1.1) plans and release
>> >> > schedule
>> >> > that can be discussed here and adjusted if need:
>> >> > 1. In 2-3 weeks we plan to release OpenCV 2.0 beta version.
>> >> > 2. OpenCV 2.0 gold release is planned for beg. of August.
>> >> > Here is a nice chart, representing the new
>> >> > version: http://opencv.willowgarage.com/wiki/OpenCV200906
>> >> > And here is the TODO lists for beta and for the release:
>> >> > 1. 2.0 beta:
>> >> > * c-descriptor and one-way descriptor, introduced by V.
>> >> > Lepetit, M.
>> >> > Calonder and others, along with the stable keypoint detector.
>> >> > * self-similarity features
>> >> > * boundary fragments (?)
>> >> > * bundle adjustment (a.k.a. sparse LM) engine. It's still
unclear
>> >> > whether we will add some camera pose estimation functionality, or
in
>> >> > this
>> >> > version it will be left to user to provide the initial estimates.
>> >> > * updated haartraining application, now called
"traincascade",
>> >> > that
>> >> > uses
>> >> > Boosting implementation from MLL and can be potentially adapted
for
>> >> > use
>> >> > with
>> >> > arbitrary features;
>> >> > currently it supports haar features and LBP (local
binary
>> >> > patterns).
>> >> > The output XML format of produced classifiers is generally
different
>> >> > from
>> >> > haartraining, but in case of haar features the application can
also
>> >> > produce
>> >> > the output compatible with the existing format and existing
>> >> > cvHaarDetectObjects.
>> >> > * documentation for the new C++ interfaces
>> >> > 2. 2.0 release:
>> >> > * fix bugs
>> >> > (https://sourceforge.net/tracker/?group_id=22870&atid=376677)
>> >> > * polish documentation and add new samples, especially for
the
>> >> > C++
>> >> > part.
>> >> > * add more tests, probably written in Python
>> >> > * repair IPP & MKL support for key functions, may be some
other
>> >> > minor
>> >> > optimizations
>> >> > * probably, integrate brand-new Python interface
>> >> >
>> >> >
>> >> >
(see http://sourceforge.net/projects/opencvpython/, http://opencv.willowgarage.com/wiki/PythonInterface)
>> >> > that does not use neither ctypes nor SWIG. The existing Python
&
>> >> > Octave
>> >> > wrappers will be retained.
>> >> > We appreciate any feedback on these plans and the schedule.
>> >> > Given a late notification, there is probably not much time left
for
>> >> > some
>> >> > radical changes or big contributions (I believe, the development
>> >> > process
>> >> > became more dynamic and more open since the last release, but I
>> >> > realize
>> >> > that
>> >> > there is still a big room for improvements in communitication
part).
>> >> > Anyhow,
>> >> > any suggestions about possible new features or corrections are
>> >> > welcome.
>> >> > If you have some bug reports or feature requests that you would
like
>> >> > to
>> >> > see
>> >> > resolved in 2.0, please, add them to the tracker:
>> >> > https://sourceforge.net/tracker/?group_id=22870&atid=376677
>> >> > Regards,
>> >> > Vadim
>> >> >
>> >> >
>> >> >
>> >> >
------------------------------------------------------------------------------
>> >> >
>> >> > _______________________________________________
>> >> > Opencvlibrary-devel mailing list
>> >> > Opencvlibrary-devel@li...
>> >> > https://lists.sourceforge.net/lists/listinfo/opencvlibrary-devel
>> >> >
>> >> >
>> >
>> >
>
>
|
