[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: LuaCV-0.1.4 OpenCV wrapper
- From: Jiří Prymus <jiri.prymus@...>
- Date: Wed, 9 Mar 2011 19:28:51 +0100
Yeah, you are right. I should push only an address of OpenCV object
pointer, whole structure is not necessary.
Thanks for criticism, I'll rewrite it as soon as I can and put on
sourceforge svn.
I think that it will be something like that:
template<typename cvtype>
void luacv_pushObject(lua_State *L,cvtype *data,const char
*type_name,bool copy=false)
{
if (!data) lua_pushnil(L);
else
{
cvtype **object=(cvtype**)lua_newuserdata(L,sizeof(cvtype*));
if (copy)
{
cvtype*c=(cvtype*)luacv_alloc(sizeof(cvtype));
*c=*data;
object=&c;
}
else
object=&data;
luaL_getmetatable(L,type_name);
lua_setmetatable(L,-2);
}
}
regards,
Jiří Prymus
2011/3/9 Gaspard Bucher <gaspard@teti.ch>:
> Reference counting in OpenCV is for Matrix.
> If you push a userdata on the stack, only the pointer is allocated by Lua
> anyway...
> This is what I use to push new objects:
> /** Push a custom type on the stack.
> * Since the value is passed as a pointer, we assume it has been created
> * using 'new' and Lua can safely call delete when it needs to garbage-
> * -collect it.
> */
> template<class T>
> void lua_pushclass(lua_State *L, T *ptr, const char *type_name) {
> T **userdata = (T**)lua_newuserdata(L, sizeof(T*));
> *userdata = ptr;
> // the userdata is now on top of the stack
> // set metatable (contains methods)
> luaL_getmetatable(L, type_name);
> lua_setmetatable(L, -2);
> }
> Usage:
> Mat * retval__ = new Mat();
> lua_pushclass<Mat>(L, retval__, "cv.Mat");
> Destructor:
> /** __gc */
> static int Mat_destructor(lua_State *L) {
> Mat **userdata = (Mat**)luaL_checkudata(L, 1, "cv.Mat");
> if (*userdata) delete *userdata;
> *userdata = NULL;
> return 0;
> }
>
> On Wed, Mar 9, 2011 at 6:10 PM, Jiří Prymus <jiri.prymus@gmail.com> wrote:
>>
>> Hi Gaspard,
>>
>> I'm using this structure as a wrapper for pointer that I pushing onto
>> the lua stack, so Lua allocate only sizeof this structure.
>>
>> template <typename cvtype>
>> struct luacv_obj
>> {
>> cvtype *data;
>> bool dealloc_data;
>> int ref;
>> };
>>
>> cvtype* data - is a pointer to OpenCV object
>>
>> bool dealloc_data - check if garbage collector callback __gc can
>> dealloc data or they are shared by another object (to avoid segfault).
>>
>> int ref - reference on LUA_REGISTRY stack position, I'm using this in
>> cvRelease* functions when I want to break references(luaL_unref()) to
>> this object and kill it, thus call __gc method.
>>
>> As far as I know the reference counting in OpenCV is only for
>> matrices, or isn't?
>>
>> regards,
>> Jiří Prymus
>>
>>
>> 2011/3/9 Gaspard Bucher <gaspard@teti.ch>:
>> > Hi Jiří,
>> > I have scrolled through the code and I do not understand the need for
>> > your
>> > boxed object model (struct luacv_obj). OpenCV has reference counting for
>> > the
>> > data already. Why do you need this extra layer ?
>> > Gaspard
>> >
>> > On Wed, Mar 9, 2011 at 10:28 AM, Jiří Prymus <jiri.prymus@gmail.com>
>> > wrote:
>> >>
>> >> Thanks Gaspard,
>> >>
>> >> your feedback gave me a lot of new powers:). I'm glad that you are
>> >> planning use LuaCV in your Lubyk project, but please consider that
>> >> LuaCV is in early alpha stage. It has functionality, but it wasn't
>> >> tested as far as I want. It has up to 16000 lines of code so be sure
>> >> I've made some mistakes.
>> >>
>> >> And about integrating LuaCV to OpenCV source package. It would be
>> >> awesome, but even if I had a chance I don't do that until I'll be sure
>> >> that LuaCV is relatively bug free.
>> >>
>> >> Btw: I'll take a look on your Lubyk project, it looks promising.
>> >>
>> >> regards,
>> >> Jiří Prymus
>> >>
>> >> 2011/3/8 Gaspard Bucher <gaspard@teti.ch>:
>> >> > Jiří, I love you !
>> >> > I created a first OpenCV binding against a previous version but could
>> >> > not
>> >> > find the time to rework the bindings for 2.2.
>> >> > Your bindings look very good (much better then mine) and much more
>> >> > complete.
>> >> > I will therefore use your work in Lubyk. I'll keep you posted on the
>> >> > integration of OpenCV there: it might be an interesting environment
>> >> > for
>> >> > your
>> >> > projects too (easy access to GUI, live coding, live video, etc).
>> >> > If possible, please consider pushing your bindings to the OpenCV
>> >> > sources
>> >> > (I
>> >> > was given commit access just for this but never considered my work
>> >> > good
>> >> > enough for the move)...
>> >> > Your the man !
>> >> > Gaspard
>> >
>> >
>
>