--
You received this message because you are subscribed to the Google Groups "Ceres Solver" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceres-solver...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/ab8284b8-443c-4db4-91a7-3bf388613fda%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Hi Aitor,I wrote the libmv planar tracker, which as you have probably noticed uses Ceres instead of a custom KLT loop. I'd love to hear what your application is, and perhaps you would consider improving the one in libmv instead of making a separate one. With that said, I think you will not have a great time doing inverse-compositional tracking using Ceres. If you modify the parameters during a solve, you are breaking one of Ceres's key invariants, producing undefined behavior. At a fundamental level, ICT is making an approximation assumption that is not valid in the general case, and so Ceres does not offer a way to exploit it.
Have you tried using the libmv tracker? It has a bunch of tweaks to make it fast, including prediction using a Kalman filter. The Kalman filter prediction is extremely cheap and often shaves off 80% of the Ceres iterations since the prediction is so close to the minima already. In some cases the Kalman predictions make a 20X overall tracking speed improvement, due to avoiding brute-force search for fast moving targets.
Thanks,KeirOn Thu, May 7, 2015 at 1:22 PM, Aitor Aldomà Buchaca <aldoma...@gmail.com> wrote:Hi folks,--
since this is my first post here, let me say that I have been using Ceres for a while now and I am really happy with it (great performance, aufodiff rocks and documentation is excellent).
That said, I am implementing an inverse compositional planar tracker that minimizes photodiscrepancy between a template and the current image. To give some context, it is similar to the planar tracker in blender from libmv but with the difference that the jacobian remains constant through the whole tracking process since it depends only on the template close to the identity warp. In a nutshell, at each iteration a parameter increment is computed around the identity, inverted and composed with the current estimate (i.e. a warp from template location to current image) to form the estimate for the next iteration. Before the next iteration, the parameters are set back to the identity again and repeat with the updated estimate.
I have been able to compute the jacobian at the identity using the internal::AutoDiff::Differentiate wrapper and worked well.
Then, I have used the base costFunction (analytic derivatives style) to feed the constant jacobian into ceres as well as the residuals.
My initial plan was using the IterationCallback to reset the parameter block to be again at the identity (if the iteration was successful) before the next iteration so that the next perturbation happens again at the identity but with the updated current estimate (within iteration callback). The problem I am facing now is that the parameter block address used internally by ceres (and given as parameter to the cost function) differs from the one allocated in the user code. So, I have no control about the parameter estimate as far as I have understood.
My question is then if its possible to do something like this in Ceres or if you know of any viable alternatives that I could use to integrate this kind of scheme. I would really like to be able to use the cool features in ceres (solvers, loss functions, ...) instead of coming up with a sloppy homemade solver implementation.
Sorry for the rather lengthy text and thanks in advance for any help. Please, let me know if clarification is needed.
Cheers,
Aitor
P.S: The forward tracker does well in terms of convergence, however it spends too much on the computation of the jacobian, thus the interest on the inverse compositional scheme.
You received this message because you are subscribed to the Google Groups "Ceres Solver" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceres-solver...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/ab8284b8-443c-4db4-91a7-3bf388613fda%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to a topic in the Google Groups "Ceres Solver" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ceres-solver/sUUTll74nXI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ceres-solver...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/CADpYijEBbQrNjiX%3D7Kx5W_CZ3w%3DYBEd3MJ1p2Ty4e-uMjAD3iQ%40mail.gmail.com.
That said, I am implementing an inverse compositional planar tracker that minimizes photodiscrepancy between a template and the current image. To give some context, it is similar to the planar tracker in blender from libmv but with the difference that the jacobian remains constant through the whole tracking process since it depends only on the template close to the identity warp. In a nutshell, at each iteration a parameter increment is computed around the identity, inverted and composed with the current estimate (i.e. a warp from template location to current image) to form the estimate for the next iteration. Before the next iteration, the parameters are set back to the identity again and repeat with the updated estimate.
I have been able to compute the jacobian at the identity using the internal::AutoDiff::Differentiate wrapper and worked well.
Then, I have used the base costFunction (analytic derivatives style) to feed the constant jacobian into ceres as well as the residuals.
My initial plan was using the IterationCallback to reset the parameter block to be again at the identity (if the iteration was successful) before the next iteration so that the next perturbation happens again at the identity but with the updated current estimate (within iteration callback). The problem I am facing now is that the parameter block address used internally by ceres (and given as parameter to the cost function) differs from the one allocated in the user code. So, I have no control about the parameter estimate as far as I have understood.
My question is then if its possible to do something like this in Ceres or if you know of any viable alternatives that I could use to integrate this kind of scheme. I would really like to be able to use the cool features in ceres (solvers, loss functions, ...) instead of coming up with a sloppy homemade solver implementation.
Sorry for the rather lengthy text and thanks in advance for any help. Please, let me know if clarification is needed.
Cheers,
Aitor
P.S: The forward tracker does well in terms of convergence, however it spends too much on the computation of the jacobian, thus the interest on the inverse compositional scheme.
--