tag:blogger.com,1999:blog-8516651997079965154.post1204763731294047673..comments2012-08-29T07:14:27.673-07:00Comments on Got a Big Plan: gst-opencv design choicesthiagosshttp://www.blogger.com/profile/03801317428445462029noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-8516651997079965154.post-13586521103857780102010-05-17T16:05:12.273-07:002010-05-17T16:05:12.273-07:00Yes, I'm using the C API. I already implemente...Yes, I'm using the C API. I already implemented with option 1, which is anyway the basis for option 2, just add subclasses and hide one parameter from them. And I agree that it is a bad design choice from OpenCV, but I guess option 1 eases maintenance in the longer term, and keeps the elements closer to the C API.<br /><br />AFAIK OpenCV C functions are just wrapping around its C++ versions.thiagosshttps://www.blogger.com/profile/03801317428445462029noreply@blogger.comtag:blogger.com,1999:blog-8516651997079965154.post-69106638213906912982010-05-16T20:12:32.625-07:002010-05-16T20:12:32.625-07:00The comment I just left got me thinking about some...The comment I just left got me thinking about something else. Apparently you are using the C bindings to OpenCV; are you opposed to using C++ directly in the gst-opencv elements? It's funny to see how cvSmooth is implemented (at least as of 2.1) simply as an if/else if structure to call the appropriate C++ methods (boxFilter, medianBlur, etc.)Joshhttps://www.blogger.com/profile/15538481939153235064noreply@blogger.comtag:blogger.com,1999:blog-8516651997079965154.post-67121948123762788162010-05-16T19:36:26.036-07:002010-05-16T19:36:26.036-07:00I would prefer Option 2, as Option 1 propagates a ...I would prefer Option 2, as Option 1 propagates a bad design decision. Just look at how OpenCV exposes the same functions via C++ (<a href="http://opencv.willowgarage.com/documentation/cpp/image_filtering.html" rel="nofollow">http://opencv.willowgarage.com/documentation/cpp/image_filtering.html</a>). I'm fine with a function/element that allows for smoothing/blurring types to be specified via a parameter, but not if the parameters of said types vary from one to the next. Please go for Option 2 and break out such functions into multiple elements!Joshhttps://www.blogger.com/profile/15538481939153235064noreply@blogger.comtag:blogger.com,1999:blog-8516651997079965154.post-82931787162016014532010-05-14T07:44:46.246-07:002010-05-14T07:44:46.246-07:00Option 1 is the best imho. You could just copy ove...Option 1 is the best imho. You could just copy over the documentation for each parameter into the gobject properties descriptions, that'll remove any problems. Also, make the default the same as the method default values.Anonymoushttps://www.blogger.com/profile/00440155533873481574noreply@blogger.com