atduskgreg's profile - activity

I would like to work with the ConDensation algorithm for object segmentation in the Java bindings, but I can't seem to find any mention of it in the java docs. Is it supported yet in the bindings?

That OpenCV library for Processing is very old and hasn't been maintained. I'm not surprised it doesn't work on Windows 7. There are currently two options for working with OpenCV in Processing: JavacvPro and OpenCVPro. JavacvPro is available here (website in French):

http://www.mon-club-elec.fr/pmwiki_reference_lib_javacvPro/pmwiki.php

It requires building opencv on your platform. It uses JavaCPP and JavaCV. It leaks memory.

The other option, OpenCVPro, is a new Processing library I am working on for OpenCV:

http://github.com/atduskgreg/opencvpro

It is very new (I've only been working on it for about a month). And I haven't tested it yet on Windows. However, it is built off of the new officially-supported OpenCV java bindings. If you'd like to help me get it working on Windows it might be a good solution for you. If not, I will likely add basic Windows support in the next month.

The Java bindings have Core.bitwise_and(), Core.bitwise_or(), and Core.bitwise_xor(), but what about bit-shifting? Is it possible to bitshift a Mat without iterating through its entries?

I've seen C++ code before that looks like:

Mat mat8uc4 = merge((mat32sc1 >> 16) & 0xFF, (mat32sc1 >> 8) & 0xFF, (mat32sc1 >> 0) & 0xFF,(mat32sc1 >> 24) & 0xFF);

and I want to do the same thing in Java.

There don't seem to be any conversion options for ARGB. cvtColor raises an assertion if either the src or dst mat are 32S: "Assertion failed (depth == CV_8U || depth == CV_16U || depth == CV_32F)" Is your data in the Mat as floats or as signed ints? I'm guessing from your segfault that you've got CV_32S. You can use Mat convertTo() to turn your Mat into CV_32F depth and then you can successfully call cvtColor().

However, I've found that calling cvtColor() on an ARGB image with COLOR_RGBA2BGRA as the conversion type leads to wacky results like this. This leads me to believe that RGBA is not actually the same as ARGB and/or that signed/unsigned/float format conversions may be causing some truncation or other issues (I think the former is probably the real cause).

I noticed in your other thread that you mentioned the Android BitmapToMat conversion functions. I think something in the spirit of these are exactly what you need here (though in sounds like you're working in the C++ api so those won't be much help to you even with a bunch of hacking). I might try poking around the source for those function to see if there's some hints about what APIs they're calling that you could maybe use.

Other than that, there's always iterating through the Mat manually and reorganizing it.