SkalskiP/top-cvpr-2024-papers: A Curated Shortlist of CVPR 2024, Sorted by Topic

What the CVPR 2024 shortlist is, and who it is for

CVPR is large enough that the accepted-paper list is not a reading list. The README states the scale directly: 11,532 papers were submitted for 2024 and 2,719 were accepted. Nobody reads 2,719 abstracts to decide what to implement. This repository exists to cut that number down.

The audience is narrow and specific. You are a computer vision engineer or a graduate student who wants to know which 2024 papers have code you can actually clone, a demo you can try, or a poster you can skim before committing to the PDF. The README frames the goal as helping you "search for crème de la crème of CVPR publications" and points anyone whose paper is missing to the official accepted-papers page on cvpr.thecvf.com. That sentence is the honest description of scope: this is a shortlist, not an index.

It is not for someone writing a literature review. A survey needs recall, and this list optimizes for precision. If your job is to cite everything published on a topic in 2024, the official accepted-paper list is the correct starting point and this repository is a detour.

How entries are structured and generated

Every entry follows the same shape. A poster thumbnail (or, for papers without one, just the title) links to the CVPR poster PDF. The title is bolded and links to arXiv. Authors are listed on one line. Then a bracketed row of links: paper, code, video, demo, colab, depending on what the authors released. Two labeled fields close the entry: Topic and Session, where Session gives the day, time and poster number in EDT.

That link row is the most useful part of the format. A paper with a code link and a Hugging Face demo is a different proposition from one with only an arXiv link, and the layout makes the difference visible without opening anything. Florence-2, for example, carries paper, video, demo and colab links; OmniGlue carries paper, code and a demo; ViewDiff carries paper, code and video.

The critical structural fact is the HTML comment above the list: the papers section is autogenerated, and the comment tells readers not to edit it manually but to follow CONTRIBUTING.md instead. The repository layout confirms this, with a top-level automation directory alongside CONTRIBUTING.md, LICENSE and README.md. So the list is a build artifact. Any change you want to see has to go through whatever CONTRIBUTING.md prescribes, not through a pull request that edits the README body.

Papers are grouped under topic headings such as "3d from multi-view and sensors", "deep learning architectures and techniques", "document analysis and understanding" and "efficient and scalable vision". A flame emoji marks highlighted papers in the source, though it carries no documented criteria. Nothing in the README explains how a paper earns the highlight, which means you should read it as emphasis rather than a ranking.

Reading the list without cloning anything

There is nothing to install. The project ships no package, no CLI and no configuration file; the README is the entire interface, and the repository layout is .gitignore, CONTRIBUTING.md, LICENSE, README.md and automation/. The README does not document any install command, and none should be invented for it.

The practical first step is to open the README on GitHub, where the poster thumbnails and the bracketed link rows render as clickable images and text. From there, the fastest way to work through it is by topic heading. Each entry prints its own Topic field, so a heading such as "3d from multi-view and sensors" or "document analysis and understanding" tells you exactly which papers sit underneath it, and the Session field gives the day, time and poster number in EDT if you want to cross-check against the conference schedule.

The one thing worth knowing before you start reading is that the list is not editable by hand. The README contains an explicit warning that the papers list is automatically generated and that changes must be made through CONTRIBUTING.md, with the generation logic living in the automation directory. If you plan to contribute a paper, read CONTRIBUTING.md first. If you only plan to read, the warning is irrelevant to you, and the README alone is enough.

Where the shortlist breaks down

The list is one person's selection, and the README does not publish the criteria. There is no stated rule for what counts as exciting or influential, and no documented threshold for the highlighted papers. That is a real limitation, not a stylistic quibble: you cannot audit a selection whose criteria are absent, and you cannot tell whether a topic is thin because few good papers were accepted there or because the maintainer did not cover it.

Coverage is another boundary. The README links to sibling repositories for 2023, 2025 and 2026, which tells you this repository is scoped to a single conference year by design. If your work spans years, you are maintaining four bookmarks, and there is no combined view.

There is also a decay problem that the format does not address. Code links point at author repositories, and the list records nothing about whether those repositories build today, which dependencies they need, or whether the code matches the arXiv version. A paper entry can look complete, with paper, code, video and demo links, while the code link leads somewhere you cannot run. The list tells you a release exists. It does not tell you the release works.

Finally, the poster thumbnails and demo links are external assets. If a poster PDF is moved on cvpr.thecvf.com or a Hugging Face Space is taken down, the entry degrades silently, because nothing in the repository checks those links.

How it differs from Papers with Code and the official proceedings

The obvious alternative is Papers with Code, which indexes papers against implementations automatically and across many conferences. The difference in approach is the point. Papers with Code optimizes for breadth and machine matching: if a paper has a linked implementation anywhere, it tends to surface. This repository optimizes for a human shortlist within one conference, and the maintainer's judgment is the filter. You get fewer entries and more curation, at the cost of transparency about how the curation happens.

The other alternative is the official CVPR accepted-paper list and the proceedings themselves, both referenced from the README. Those give you the complete set of 2,719 accepted papers and the authoritative record. What they do not give you is the link row. On the official list you find a title; here you find whether the authors shipped code, a video or a demo, in one line, next to a poster thumbnail and the poster session time.

So the honest comparison is recall versus triage. If you need to know whether a specific paper was accepted at CVPR 2024, the official list is authoritative and this repository may simply not mention it. If you need to pick five papers to read this month from a field of thousands, the curated format does work the official list does not.

Maintenance, licence and the cost of keeping up

The last push to the repository was on 2026-04-15, roughly five months before this writing, so the repository is not archived but it is also not being touched continuously. For a list tied to a conference that finished in June 2024, that is a reasonable state: the paper set is fixed, and the remaining work is link repair and additions.

The upgrade cost is low but not zero, and it is concentrated in one place. Because the paper list is autogenerated, pulling a newer version of the README can conflict with any local edits you made to it. If you fork the repository to add papers for your own team, expect to reapply those changes after each upstream update, or better, change the automation inputs as CONTRIBUTING.md describes so your additions survive regeneration.

The licence is CC0-1.0, which places the repository's own content in the public domain. That covers the list, the README text and whatever the automation directory contains. It does not cover the papers, the poster images hosted on cvpr.thecvf.com, or the code in the linked author repositories, each of which carries its own terms. Reusing the curated list is unencumbered; reusing what it points to is a separate question you have to check per paper. This is a description of the licence field, not legal advice.

Editorial conclusion

Adopt this if you want a reading shortlist for CVPR 2024 that already separates papers with released code or demos from those without, and you are willing to treat the selection as one person's editorial call. Skip it if you need the complete accepted-paper list, full proceedings, or coverage of CVPR 2023, 2025 or 2026, which live in sibling repositories rather than here. Before relying on it, open CONTRIBUTING.md and the automation directory, because the paper entries are generated and manual edits will be overwritten.

Frequently asked questions

Official sources

1. Issues
2. License: CC0-1.0
3. README
4. SkalskiP/top-cvpr-2024-papers on GitHub