glupescu's profile - activity

but I'm looking into guidance on what algorithms would suit work-group reduce OP... how can I turn that into an issue ?

[ SHORT ] Are you aware of any particular algorithms that would benefit from the work-group reduce add/min/max ? - maybe something SIMD oriented that would though require moderate thread communication / map-reduce type operation.

[ DETAIL ] I'm working to improve the work-group reduce functions in a Linux OpenCL stack for GPGPUs. The work-group functions are briefly described here [1] - in short they enable add/min/max collaborative work between threads in the same work-group. For instance work-group_reduce_add with 4 local threads would do (1, 2, 3, 4, 5, 6, 7, 8) => {(10, 10, 10, 10), (26, 26, 26, 26)}, while work-group_reduce_min with 2 local threads would be {(1, 1), (3, 3), (5, 5), (7, 7)}. I'm looking at OpenCV as a source for real world problems that would benefit from the work-group reduce functions.

[1] https://software.intel.com/en-us/arti...

Yes. I mean i have an idea how to make it faster but would like to write it for GPUs using OpenCL and that would take some time. And if i manage to improve it by a % margin why would anyone bother integrating it or checking it out if contour extraction itself isn't very used (assuming) hence the current OpenCV findCountour would be enough for most people.

It was more of an assumption than a confirmation. I previously worked on image vectorization (raster->vector, e.g. algorithm [1],[2]) and noticed that contour extraction was one of the problems on large scale images (such as maps). The question is actually more oriented towards "are there any problems that require fast contour extraction" or is there a scenario where "contour extraction is the slowest step" ? I think image vectorization is not enough for me to continue and invest time into this topic.

[1]http://www.imageprocessingplace.com/downloads_V3/root_downloads/tutorials/contour_tracing_Abeer_George_Ghuneim/intro.html [2] http://potrace.sourceforge.net/potrace.pdf

For current vision algorithms (e.g. object detection, object enhancing) does findCountours perform fast enough ? I've studied the algorithm behind it [1] and by a first look it's rather difficult to perform in parallel especially on SIMD units like GPUs. I took a usage example from [2] and did a simple trace of findCountours on [3] and [4]. While [3] requires 1ms, [4] requires about 40ms (AMD 5400K @3.6ghz). If high resolution video processing frame by frame is considered these results could be problematic. I think i may have an ideea for a faster algorithm oriented towards SIMD units. So i would like some feedback from people who have worked in vision problems to the question:

Is findCountours fast enough for current problems on current hardware ? Would improving it help in a significant way any specific algorithm ?

Thank you in advance, Grigore

[1] http://tpf-robotica.googlecode.com/svn-history/r397/trunk/Vision/papers/SA-CVGIP.PDF [2] http://docs.opencv.org/doc/tutorials/imgproc/shapedescriptors/find_contours/find_contours.html [3] http://jerome.berbiqui.org/eusipco2005/lena.png [4] http://www.lordkilgore.com/wordpress/wp-content/uploads/2010/12/big-maze.png