New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
This implements the SRDCF tracker #454
base: 4.x
Are you sure you want to change the base?
Conversation
@GustavHager, thanks for the code submission! Actually, as I see, Eigen is used in the module. This dependency should be removed. |
Hi @vpisarev thanks for self-assigning! Do you have a time estimate to work on this, just curious when I can start testing this guy out. Thanks! |
I will submit a new pull request in a few weeks without eigen, until then the matlab implementation exists at http://www.cvl.isy.liu.se/research/objrec/visualtracking/regvistrack/index.html |
std::vector<cv::Mat> outer_products = construct_sample_data(data); | ||
std::vector<float> real,imag; | ||
|
||
int sparse_mat_size = 2 * real.size() * feature_dim; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
real.size() is actually 0 in this case, since you haven't initialized the real vector. This leads to exception thrown when you try to declare a SparseMat of 0 size in line 481.
No it is not, i am working on a new pull request with less bugs and less Eigen at the moment on my own fork. |
@vpisarev Any update on this? Can we expand on this for a GSoC? @GustavHager I've not read the poster again but is there space for OpenCL acceleration? /cc @lenlen |
The main problem is that the current formulation requires sparse matrices and sparse solvers to compute the model updates in a timely manner. Hence the use of eigen in the pull request. I have implemented a variant using the OpenCV sparse matrices, but this proved significantly slower than the eigen or matlab code we prototyped with. Unfortunately i ran out of time to try to speed it up, and i am not sure if it is due to the sparse representation in opencv or the solver itself. Since there seems to be some interest i could try to speed up the current opencv sparse implementation over the weekend, hopefully that should be enough to get acceptable performance and this pull request could be closed More generally, most of the algorithm should be trivial to parallelize and it is something me and Martin have thought of but never had time to implement. |
@GustavHager If you can push an updated version I'll try to put a student to profile it. |
hello all, last year I implemented KCF and CN algorithm which are similar to SRDCF in some aspects, how about the status of this pull request? |
I have more or less ironed out all the outright bugs in the implementation now, but there is still quite a bit of optimization to be done for it to be properly useful, i will submit a proper pull request on Monday with these fixes. It might be a decent summer project to optimize the implementation, or make some components such a the feature extraction more general though. Alternatively there is a number of extra features that could be added to the current implementation. |
@GustavHager Have you give up for the code? I really want to try out your tracker even it is not part of opencv? any suggestions? |
@berkerlogoglu they provide the Matlab version, check here https://www.cvl.isy.liu.se/research/objrec/visualtracking/regvistrack/ |
@kurnianggoro thanks but I need c/c++ codes. |
@berkerlogoglu I think you can use the PR as is since the problems stated by the build bot (checked linux x64 and docs) are trivial
Then you have a current master with this PR included |
@Dikay900 Thanks! it actually built without any problems. I could also make it work. BUT!, it does not update the bounding box! :( |
I have the same problem, it does not update the bounding box! //get the first frame bool initialized = false; for ( ;; )
} return 0; |
I also encountered the same problem. It does not update the bounding box, and box flies to the upper left corner. Does anyone solve it? |
i just tried it, the boundingbox indeed never moves. tracked it down to the filterf mat returned from assemble_filters being all |
Error in function SRDCF::compute_filter
|
Was the winner of the opencv challenge in tracking.