jcrist's profile - activity

I found better solution without iterating through contours - by using numpy concatenate() function: concat = np.concate

Dear OpenCV team!

If I want to extend list of types, which are wrapped automatically by OpenCV Almighty Java Wrapper Generator (let's call it JWG), how would I do that? Is there any documentation, best practices or how-to's?

Appreciate your help on this, I spent some time analyzing how this thing work and, to be honest, I would say that readability the code is not exactly the best possible.

I'd like to understand the proper way of wrapping parameters in the following cases:

1. Exanple: std::vector<string>. I'd like to map it to List<string> in java
2. Let's say there is a module xxx in opencv_contrib. which contains the type definition typedef vector<A> B; where vector is the class, which JWG knows how to wrap. However, all methods using arguments of B type are skipped by JWG. What is the right approach for fixing this problem?

I've made some progress in resolving this issue but not sure if this is the right approach or not. Seems like the problem is related to the way how include paths are configured in CMake for java module. The following changes are leading to successful compilation:

In the file /opencv_contrib/modules/dnn/cmake/OpenCVFindLibProtobuf.cmake, the following line:

set(PROTOBUF_INCLUDE_DIR "${PROTOBUF_CPP_ROOT}/src")

is to be replaced with

set(PROTOBUF_INCLUDE_DIR "${PROTOBUF_CPP_ROOT}/src" PARENT_SCOPE)

The purpose of this change is to make the PROTOBUF_INCLUDE_DIR variable visible for the CMake script in the main repository.

The next step is to locate the following line in the /opencv/modules/java/CMakeLists.txt:

ocv_module_include_directories("${OpenCV_SOURCE_DIR}/include")

and insert the following code below this line:

if(BUILD_PROTOBUF)
    message(STATUS "PROTOBUF_INCLUDE_DIR=${PROTOBUF_INCLUDE_DIR}")
    ocv_module_include_directories("${PROTOBUF_INCLUDE_DIR}")
endif()

After these changes java wrappers are generated successfully for dnn module.

Dear OpenCV team, need your help.

I'm trying to generate java wrappers for dnn module. I was able to overcome some of the issues but this one is really cumbersome. I get the following exception during compilation of java wrappers:

 In file included from /opencv/build/modules/java/gen/dnn.cpp:17:
/opencv_contrib/modules/dnn/misc/tensorflow/attr_value.pb.h:9:10: fatal error: 'google/protobuf/stubs/common.h' file not found
#include <google/protobuf/stubs/common.h>

It seems like the issue is somehow related to 3rdparty protobuf library, which is building from sources along with OpenCV (BUILD_PROTOBUF=ON). I can find the missing header in the folder /opencv/build/3rdparty/protobuf/protobuf-3.1.0/src/google/protobuf/stubs/common.h but this path seems to be non-visible for the compiler.

Please kindly advise what would be the correct approach to fix this problem.

Ok, I've made some progress resolving this.

Assume we are to wrap a C++ method like void foo(const Ptr<t>& arg). Whenever gen_java.py meets the function parameter of type const Ptr<t>&, it generates the following JNI code:

java:

public void foo(T arg) {
      foo_0(arg.nativeObj);
      return;
}
private static native void foo_0(long arg_nativeObj);

JNI C wrapper

JNIEXPORT void JNICALL Java_org_opencv_<module>_<class>_foo_10 (JNIEnv* env, jclass jclass, jlong arg_nativeObj) {
      static const char method_name[] = "<module>::foo_10()";
      try{
             LOGD("%s", method_name);
             <module>::foo(Ptr<T>((T*) arg_nativeObj)); // NOTE: crash happens here
      } catch(const std::exception &e) {
             throwJavaException(env, &e, method_name);
      } catch (...) {
             throwJavaException(env, 0, method_name);
      }
      return;
}

The line noted above is leading to Java crash, However, if to replace it with the following, the crash is cured:

<module>::foo(*((Ptr<T> *) arg_nativeObj)); // Works fine

So I guess my question can be transformed to this: what is the scenario when we need to keep the original way of wrapping of const Ptr<t> & arg? Which modules/classes/methods use it?

hi berak, added all components as requested. Seems like nothing extraordinary but I may be missing something ...

Found the answer. For some reason the path to old JDK was preserved in the cmake settings so it was pointing to non-existing folder. Here is the fix:

1. run ccmake .. in opencv/build folder
2. toggle advanced mode (press 't')
3. found and changed JNI paths.

This is just in case if anybody will face the similar problem after upgrade of xcode/jdk.

Hello,

I encountered really strange issue, which appeared recently most likely due to XCode/Java updates. Here is my setup:

• OSX EL Capitan 10.11.6
• Xcode Version 8.1 (8B62)
• java version "1.8.0_111"
• Java(TM) SE Runtime Environment (build 1.8.0_111-b14)
• Java HotSpot(TM) 64-Bit Server VM (build 25.111-b14, mixed mode)

My codebase is: commit 6c12533160bc5e6de1f09847d9cd6dd548667a55 Merge: 811eb76 bec3479 Author: Alexander Alekhin [email protected] Date: Mon Oct 31 17:35:41 2016 +0000

Previously I was able to build opencv master from sources with no issues but when I'm trying to build it now, it cannot find jni.h!:

/opencv/modules/java/generator/src/cpp/common.h:8:10: fatal error: 'jni.h' file not found
#include <jni.h>

Appreciate any ideas or hints how to fix this? JAVA_HOME is pointing at correct folder and also include folder is there and jni.h is where it should be ...

One good example is Eclipse - I think they put a lot of good thoughts in the contribution process.

Sure. Is there a list of features or may be new modules, which are planned for the next release? When is the tentative date for the next release? Is there a long-term roadmap? Is there a way for community to suggest new modules/new projects and may be vote for it? Another set of questions is related to backward compatibility with previous releases and versioning of algorithms. Take MSER as an example. Without going too deep in details - this algorithm produces totally different results in ver 3.1 compared to 3.0.0-rc-1 to say nothing about 2.4. Is there a way to understand what triggered this change and why the new implementation is better than the one in the previous versions? I ran through the commits - seems like some refactoring was going on but why it impacted results?

By the way, managing roadmaps could be done using opensource tools. Some people advise Redmine - it seems to be good open source project management tool. I don't have much experience with it but it may solve at least problem of managing releases and roadmaps. Integration with git is also a big plus.

Dear OpenCV team! I have one generic question - is the opencv project being managed by anyone or not really? For example:

• How is the decision being made on whether particular contribution is inline with OpenCV roadmap or not? Is there any release plan available for public?
• Who and how decides whether to remove or update an existing interface? I've seen many changes in recent version (3.1), which break previously available interface (3.0.0-rc1 or 2.4.x). I believe such changes should be discussed with community as we humble users )) expect that opencv versions are backward compatible at least within one release.
• Some of popular algorithms are also changing very dramatically even within one major release. For example, MSER feature detector produces substantially different number of feature points in version 3.0.0-rc1 and 3.1 on the same image. This is very unexpected situation as it is essentially deterring users from upgrading to a newer version. Just an idea - can we have a compiler flag, which enforces backward compatibility on the underlying algorithm level with previous versions? Another alternative is to keep older versions of algorithms with the ability to switch them on or off during compilation from source (for example, MSER 3.0, MSER 3.1 etc).

OpenCV is really cool staff but after playng a bit with it I got an impression (may be totally wrong) that there is no management at all; contributions are sometimes poorly explained and it is not always clear what is driving them.

This looks like the old issue, should be already fixed in the upstream. capture.release() is not yet fixed.

when exactly your code is crashing? Is it at the moment when the capture is released or earlier?

Here is what I found but I'm not sure if this is the right way or not. The make process actually prints out the jar name of the junit tests for OpenCV java wrappers (opencv-test.jar). Here is how to run it.

1. Install JRE for your platform. I have Mac so further examples will work for unix and the likes. MS Win I guess works in the similar fashion, just need to use proper path syntax.

2. Navigate to /opencv/build folder and run the following command:

   java -cp ./modules/java/pure_test/.build/lib/junit-4.11.jar:./modules/java/pure_test/.build/build/jar/opencv-test.jar:./bin/opencv-310.jar -Djava.library.path="./lib" junit.textui.TestRunner org.opencv.test.opencv-package-name.test-class-name

opencv-package-name stands for the name of the corresponding opencv module, for example calib3d, core, features2d, highgui, imgproc, objdetect, photo, utils, video etc.

test-class-name can be any class from that package, which inherits from OpenCVTestCase. For example:

java -cp ./modules/java/pure_test/.build/lib/junit-4.11.jar:./modules/java/pure_test/.build/build/jar/opencv-test.jar:./bin/opencv-310.jar -Djava.library.path="./lib" junit.textui.TestRunner org.opencv.test.utils.ConvertersTest

will produce the following output:

.........................................

Time: 0.295

OK (41 tests)

UPDATE: as expected things are much more simple than we think of them initially )) OpenCV good team did great job already - all tests including java tests can be run from the build directory by this command:

python ../modules/ts/misc/run.py

more information is here. The only confusing part of documentation - seems like this command actually runs all tests so it can be used not only for performance control.

Thank you berak, will try to dig it a beet deeper and will let you know.

Thank you for the prompt answer! Is there any guideline how build and run them locally?

Are there any automated tests included in nightly builds for testing java wrappers? What is the process of contributing tests to OpenCV?