For all previous competitions, postprocessing with some kind of query expansion, graph NN, spatial verification ( DELF or SIFT) + RANSAC were an important part of winning solutions. Now nothing is possible and we are stick to boring metric learning competition. \nWhy? I understand that simple knn is faster in production, but still...
", "messages": [ { "id": 911077, "postDate": "2020-07-01T14:56:38.777Z", "content": "For all previous competitions, postprocessing with some kind of query expansion, graph NN, spatial verification ( DELF or SIFT) + RANSAC were an important part of winning solutions. Now nothing is possible and we are stick to boring metric learning competition. \nWhy? I understand that simple knn is faster in production, but still...
", "rawMarkdown": "For all previous competitions, postprocessing with some kind of query expansion, graph NN, spatial verification ( DELF or SIFT) + RANSAC were an important part of winning solutions. Now nothing is possible and we are stick to boring metric learning competition. \nWhy? I understand that simple knn is faster in production, but still...", "votes": 18 }, { "id": 911172, "postDate": "2020-07-01T15:45:37.360Z", "content": "We enjoyed the creative solutions that came out of the previous landmarks challenges and were happy to see new approaches involving global+local feature combinations, query expansion and clever re-ranking. For this year's challenge, we wanted to put the emphasis on feature development only, to see how much improvement is possible in this field. Note that we are also going to have another round of the landmark recognition challenge (starting soon), which will allow more freedom in terms of methods.
", "rawMarkdown": "We enjoyed the creative solutions that came out of the previous landmarks challenges and were happy to see new approaches involving global+local feature combinations, query expansion and clever re-ranking. For this year's challenge, we wanted to put the emphasis on feature development only, to see how much improvement is possible in this field. Note that we are also going to have another round of the landmark recognition challenge (starting soon), which will allow more freedom in terms of methods.", "votes": 10, "replies": [ { "id": 911178, "postDate": "2020-07-01T15:47:25.257Z", "content": "Next round is good news. Thank you!
", "rawMarkdown": "Next round is good news. Thank you!", "votes": 1 }, { "id": 911180, "postDate": "2020-07-01T15:47:50.267Z", "content": "@tobwey Would be nice if you gave us a set date on the Timeline page of the competition overview.
", "rawMarkdown": "@tobwey Would be nice if you gave us a set date on the Timeline page of the competition overview.", "votes": 3 }, { "id": 915650, "postDate": "2020-07-05T01:30:37.533Z", "content": "@tobwey Tobias, I am a newbie to computer vision so may I know what feature development do you mean here?
\n\nFor this year's challenge, we wanted to put the emphasis on feature development only, to see how much improvement is possible in this field.
By \"feature\" I meant image representations, or embeddings, which is the output of the submitted models.
", "rawMarkdown": "By \"feature\" I meant image representations, or embeddings, which is the output of the submitted models.", "votes": 1 } ] }, { "id": 911438, "postDate": "2020-07-01T18:26:07.323Z", "content": "Hey, Dmytro: I, for one, definitely don't hate local features / RANSAC / postprocessing! 😃
\n\nIndeed, the solutions for previous landmark retrieval competitions involved many extra steps beyond global feature retrieval. But some of them were impractical, and there was a concern among the workshop organizers that it became difficult to understand where progress/gains were coming from. This was a core motivation for this year's challenge format, and a lot of thought went into it. Let's see how things go -- we will definitely be paying attention and learning from this new experience as much as possible (feedback is always welcome).
\n\nAs Tobias already mentioned, we are also planning on having a separate landmark recognition competition where submissions can enjoy greater latitude in terms of methods to be used. As you probably have already seen per recent papers, local feature re-ranking ends up being more important for recognition tasks than retrieval ones (so, today, we believe it's more important to support local features in a recognition problem setup, rather than retrieval).
", "rawMarkdown": "Hey, Dmytro: I, for one, definitely don't hate local features / RANSAC / postprocessing! 😃 \n\nIndeed, the solutions for previous landmark retrieval competitions involved many extra steps beyond global feature retrieval. But some of them were impractical, and there was a concern among the workshop organizers that it became difficult to understand where progress/gains were coming from. This was a core motivation for this year's challenge format, and a lot of thought went into it. Let's see how things go -- we will definitely be paying attention and learning from this new experience as much as possible (feedback is always welcome).\n\nAs Tobias already mentioned, we are also planning on having a separate landmark recognition competition where submissions can enjoy greater latitude in terms of methods to be used. As you probably have already seen per recent papers, local feature re-ranking ends up being more important for recognition tasks than retrieval ones (so, today, we believe it's more important to support local features in a recognition problem setup, rather than retrieval).", "votes": 7, "replies": [ { "id": 912081, "postDate": "2020-07-02T07:52:31.383Z", "content": "While I agree that RANSAC + local features can be slow and impractical, I definitely cannot say that for the query expansion/diffusion or more advanced techniques. Nor I cannot say that the effect is small for retrieval.\nBut thanks for the explanation, I will wait for the recognition competition then :)
", "rawMarkdown": "While I agree that RANSAC + local features can be slow and impractical, I definitely cannot say that for the query expansion/diffusion or more advanced techniques. Nor I cannot say that the effect is small for retrieval.\nBut thanks for the explanation, I will wait for the recognition competition then :)", "votes": 1 } ] }, { "id": 911140, "postDate": "2020-07-01T15:32:14.247Z", "rawMarkdown": "", "isDeleted": true, "replies": [ { "id": 911144, "postDate": "2020-07-01T15:33:57.127Z", "content": "Kaggle kernels can easily handle all the things I mentioned...
", "rawMarkdown": "Kaggle kernels can easily handle all the things I mentioned..." }, { "id": 911150, "postDate": "2020-07-01T15:37:23.503Z", "content": "Sorry - my mistake. However your point on production speed is valid.\nIt does make sense that Google would want something better suited for production models because normally image competitions use very cumbersome methods. \nThey are willing to sacrifice novel ideas for production speeds.
", "rawMarkdown": "Sorry - my mistake. However your point on production speed is valid.\nIt does make sense that Google would want something better suited for production models because normally image competitions use very cumbersome methods. \nThey are willing to sacrifice novel ideas for production speeds.", "votes": 1 } ] } ], "comments": [ { "id": 911172, "author_name": "Tobias Weyand", "author_url": "", "post_date": "2020-07-01T15:45:37.360000", "content": "We enjoyed the creative solutions that came out of the previous landmarks challenges and were happy to see new approaches involving global+local feature combinations, query expansion and clever re-ranking. For this year's challenge, we wanted to put the emphasis on feature development only, to see how much improvement is possible in this field. Note that we are also going to have another round of the landmark recognition challenge (starting soon), which will allow more freedom in terms of methods.
", "votes": 10, "replies": [ { "id": 911178, "author_name": "old-ufo", "author_url": "", "post_date": "2020-07-01T15:47:25.257000", "content": "Next round is good news. Thank you!
", "votes": 1, "replies": [] }, { "id": 911180, "author_name": "Trigram", "author_url": "", "post_date": "2020-07-01T15:47:50.267000", "content": "@tobwey Would be nice if you gave us a set date on the Timeline page of the competition overview.
", "votes": 3, "replies": [] }, { "id": 915650, "author_name": "FP", "author_url": "", "post_date": "2020-07-05T01:30:37.533000", "content": "@tobwey Tobias, I am a newbie to computer vision so may I know what feature development do you mean here?
\n\nFor this year's challenge, we wanted to put the emphasis on feature development only, to see how much improvement is possible in this field.
By \"feature\" I meant image representations, or embeddings, which is the output of the submitted models.
", "votes": 1, "replies": [] } ] }, { "id": 911438, "author_name": "Andre Araujo", "author_url": "", "post_date": "2020-07-01T18:26:07.323000", "content": "Hey, Dmytro: I, for one, definitely don't hate local features / RANSAC / postprocessing! 😃
\n\nIndeed, the solutions for previous landmark retrieval competitions involved many extra steps beyond global feature retrieval. But some of them were impractical, and there was a concern among the workshop organizers that it became difficult to understand where progress/gains were coming from. This was a core motivation for this year's challenge format, and a lot of thought went into it. Let's see how things go -- we will definitely be paying attention and learning from this new experience as much as possible (feedback is always welcome).
\n\nAs Tobias already mentioned, we are also planning on having a separate landmark recognition competition where submissions can enjoy greater latitude in terms of methods to be used. As you probably have already seen per recent papers, local feature re-ranking ends up being more important for recognition tasks than retrieval ones (so, today, we believe it's more important to support local features in a recognition problem setup, rather than retrieval).
", "votes": 7, "replies": [ { "id": 912081, "author_name": "old-ufo", "author_url": "", "post_date": "2020-07-02T07:52:31.383000", "content": "While I agree that RANSAC + local features can be slow and impractical, I definitely cannot say that for the query expansion/diffusion or more advanced techniques. Nor I cannot say that the effect is small for retrieval.\nBut thanks for the explanation, I will wait for the recognition competition then :)
", "votes": 1, "replies": [] } ] }, { "id": 911140, "author_name": "", "author_url": "", "post_date": "2020-07-01T15:32:14.247000", "content": "", "votes": 0, "replies": [ { "id": 911144, "author_name": "old-ufo", "author_url": "", "post_date": "2020-07-01T15:33:57.127000", "content": "Kaggle kernels can easily handle all the things I mentioned...
", "votes": 0, "replies": [] }, { "id": 911150, "author_name": "Trigram", "author_url": "", "post_date": "2020-07-01T15:37:23.503000", "content": "Sorry - my mistake. However your point on production speed is valid.\nIt does make sense that Google would want something better suited for production models because normally image competitions use very cumbersome methods. \nThey are willing to sacrifice novel ideas for production speeds.
", "votes": 1, "replies": [] } ] } ], "raw_markdown_by_id": { "911077": "For all previous competitions, postprocessing with some kind of query expansion, graph NN, spatial verification ( DELF or SIFT) + RANSAC were an important part of winning solutions. Now nothing is possible and we are stick to boring metric learning competition. \nWhy? I understand that simple knn is faster in production, but still...", "911172": "We enjoyed the creative solutions that came out of the previous landmarks challenges and were happy to see new approaches involving global+local feature combinations, query expansion and clever re-ranking. For this year's challenge, we wanted to put the emphasis on feature development only, to see how much improvement is possible in this field. Note that we are also going to have another round of the landmark recognition challenge (starting soon), which will allow more freedom in terms of methods.", "911438": "Hey, Dmytro: I, for one, definitely don't hate local features / RANSAC / postprocessing! 😃 \n\nIndeed, the solutions for previous landmark retrieval competitions involved many extra steps beyond global feature retrieval. But some of them were impractical, and there was a concern among the workshop organizers that it became difficult to understand where progress/gains were coming from. This was a core motivation for this year's challenge format, and a lot of thought went into it. Let's see how things go -- we will definitely be paying attention and learning from this new experience as much as possible (feedback is always welcome).\n\nAs Tobias already mentioned, we are also planning on having a separate landmark recognition competition where submissions can enjoy greater latitude in terms of methods to be used. As you probably have already seen per recent papers, local feature re-ranking ends up being more important for recognition tasks than retrieval ones (so, today, we believe it's more important to support local features in a recognition problem setup, rather than retrieval).", "911140": "" } }