1 | initial version |
It's an abstract method, since not every algorithm may support model updates and by default an exception is thrown. Since FaceRecognizer::update
is a virtual method and overridden for the LBPH FaceRecognizer, it is called by the rules of late binding in C++. I'll contact the JavaCV developers and see what's the simplest way to wrap.
2 | No.2 Revision |
It's an abstract method, since not every algorithm may support model updates and by default an exception is thrown. Since FaceRecognizer::update
is a virtual method and overridden for the LBPH FaceRecognizer, it is called by the rules of late binding in C++. I'll contact the JavaCV developers and see what's the simplest way to wrap.wrap in Java.
3 | No.3 Revision |
It's an abstract method, since not every algorithm may support model updates and by default an exception is thrown. Since FaceRecognizer::update
is a virtual method and overridden for the LBPH FaceRecognizer, it is called by the rules of late binding in C++. And so does it work in C++ and also the Python wrapper of OpenCV.
JavaCV is a Java wrapper around OpenCV, which I have no control of. I'll contact the JavaCV developers developer and see what's the simplest way to wrap in Java.for him from Java. And update this post accordingly.
4 | No.4 Revision |
It's an abstract method, since not every algorithm may support model updates Here's the problem. In the trunk of the OpenCV repository, the method is virtual and overriden by default an exception is thrown. Since the LBPH FaceRecognizer::update
is a virtual method and overridden for FaceRecognizer, FaceRecognizer. So it is gets called by the rules of late binding binding in C++. And so does it work in This works for C++ and also all the Python wrapper wrappers. Everything is fine! But and here is the problem: In the 2.4 branch of OpenCV.
JavaCV is a Java wrapper around OpenCV, which I have no control of. OpenCV the team wants to guarantee binary compability and so the virtual keyword was removed from the method signature. This causes the problem, because the overriden methods don't get called anymore. I'll contact the JavaCV developer and see what's the simplest way to wrap for him from Java. And update this post accordingly.when it is fixed.
5 | No.5 Revision |
Here's the problem. In the trunk of the OpenCV repository, the method is virtual and overriden by the LBPH FaceRecognizer. So it gets called by the rules of late binding in C++. This works for C++ and all the wrappers. Everything is fine! But and here is the problem: In the 2.4 branch of OpenCV the team wants to guarantee binary compability and so the virtual keyword was removed from the method signature. This causes the problem, because the overriden methods don't get called anymore. I'll update this post when it is fixed.
Sorry, I forgot to update. So... The method was virtual, when I commited it to the OpenCV 2.4 trunk. Now the OpenCV team wants to ensure Binary Compability through the versions, so in the OpenCV 2.4 BRANCH (from which OpenCV 2.4.3 is created) the virtual keyword was removed. This of course caused the errors described in here. When I was contacted, that it's not working I looked up the OpenCV TRUNK and the method was still virtual. So the trunk worked fine. At this point I noticed it was only changed in the BRANCH and contacted Vadim to find out what's going on. Vadim then commited some kind of fix, by leaving the method non-virtual and dynamically upcasting the FaceRecognizer object.
6 | No.6 Revision |
Here's the problem. In the trunk of the OpenCV repository, the method is virtual and overriden by the LBPH FaceRecognizer. So it gets called by the rules of late binding in C++. This works for C++ and all the wrappers. Everything is fine! But and here is the problem: In the 2.4 branch of OpenCV the team wants to guarantee binary compability and so the virtual keyword was removed from the method signature. This causes the problem, because the overriden methods don't get called anymore. I'll update this post when it is fixed.
Sorry, I forgot to update. So... The method was virtual, when I commited it to the OpenCV 2.4 trunk. Now the OpenCV team wants to ensure Binary Compability through the versions, so in the OpenCV 2.4 BRANCH (from which OpenCV 2.4.3 is created) the virtual keyword was removed. This of course caused the errors described in here. When I was contacted, that it's not working I looked up the OpenCV TRUNK and the method was still virtual. So the trunk worked fine. At this point I noticed it was only changed in the BRANCH and contacted Vadim to find out what's going on. Vadim then commited some kind of fix, by leaving the method non-virtual and dynamically upcasting the FaceRecognizer object.object. So the problem should be resolved by now.