JarvisArt drives 200 Lightroom tools and states exactly one number for itself

The key explaining the author superscripts is inside a comment

The author block lists eleven names, each with an affiliation number and, for some of them, a symbol. Yunlong Lin, Zixu Lin and Kunjie Lin carry the number 1 and an asterisk. Xinghao Ding carries 1 and a dagger. Wenbo Li carries 3 and a club. Shuicheng Yan carries 5 and a dagger. The other five carry an affiliation number alone.

The line that explains those three symbols is present in the page and is not rendered. It reads as an HTML comment giving the asterisk as equal contributions, the club as project leader and the dagger as corresponding author.

So the affiliations are legible and the roles are not. A reader can tell that Xinghao Lin and Shuicheng Yan are the corresponding authors and that Wenbo Li is the project leader only by reading the page source, because on the rendered page those marks are unexplained glyphs attached to names.

The same pattern appears elsewhere. A line claiming acceptance at CVPR 2025 is commented out directly beneath the affiliations block, left over from before the NeurIPS acceptance that the title and the update list both record. A commented-out title line sits in the header. And the top of the update list has its first entry commented out, dated 2025.12.8, for the complete data generation pipeline.

One performance number, no metric named and no baseline value

The overview paragraph ends with the project's only self-assessment, and it is a single figure.

JarvisArt is described as outperforming GPT-4o with a 60 percent improvement in pixel-level metrics for content fidelity while maintaining comparable instruction-following capabilities.

Three things are missing from that sentence. Which pixel-level metric, since content fidelity can be measured more than one way. The baseline value it improves on, since a 60 percent improvement means different things depending on where you start. And the instruction-following capability it is said to be comparable on, which is asserted as comparable rather than measured.

The surrounding claims are structural rather than numeric: a multimodal agent that understands user intent, mimics the reasoning of professional artists, and coordinates over 200 tools in Adobe Lightroom, trained with chain-of-thought supervised fine-tuning for foundational reasoning followed by Group Relative Policy Optimization for Retouching, named GRPO-R, to improve decision-making and tool proficiency.

The evaluation data is named, MMArt-Bench, and it was released on 2025.12.8 along with the data construction scripts. So the numbers exist somewhere; they are simply not on this page, and a 60 percent improvement with no named metric is not a claim anyone can act on.

The provenance FAQ exists because the public data is narrower than the paper

There is a section whose stated purpose is clarification rather than explanation. It opens by saying it is there to clarify data provenance for MMArt, including the distribution summary shown in the paper.

The first bullet restates the paper: MMArt is constructed from PPR10K and other licensed open-source collections. The second bullet then says that in this repository the currently public dataset releases are a specific and shorter list, beginning with MMArt-PPR10K.

That structure is an admission. The paper describes a 55K sample dataset assembled from several sources, and what is actually downloadable is one named release. Everything about the rest of the distribution has to come from the paper rather than from the repository.

The one release that is public is described in the update list with its own provenance. MMArt-PPR10k went live on Hugging Face Datasets on 2025.10.1, built upon PPR10K, described as an open-source dataset containing diverse user instructions alongside Lightroom Lua and XMP files and corresponding original and edited images, and released under the Apache 2.0 license.

The Lua and XMP detail is the interesting part for anyone building on it. The dataset does not just pair images with instructions; it carries the Lightroom side of the edit as a script and as metadata, which is what makes tool-level supervision possible rather than only pixel-level training.

Weights, space and datasets sit under two Hugging Face owners

Five Hugging Face destinations are linked from the header, and they are not all under the same account.

The online demo space is `LYL1015/JarvisArt-Preview`, under the individual author's account. The model weights are `JarvisArt/JarvisArt-1208`, under an organisation account, as are both datasets, `JarvisArt/MMArt-PPR10k` and `JarvisArt/MMArt-Bench`. The paper page is linked separately.

So the model and the data live under the project organisation while the runnable demo lives under the author. For a citation or a dependency pin that split matters, and it is not explained anywhere on the page.

The weight repository name is the other loose end. `JarvisArt-1208` is a date-like string, and the update log says the weights became available on 2025.6.28, which does not obviously correspond to it. Nothing on the page says whether that suffix is a release date, a training run identifier or a version.

The repository itself is named after the author, `LYL1015/JarvisArt`, and the project page is hosted separately again. Three naming schemes for one project, none of them cross-referenced beyond the header.

The update list ends in December 2025 and the branch moved in April 2026

The updates section is dated, which makes the gaps readable. There are twelve entries between 2025.6.16 and 2025.12.8.

The first half is a release cadence: project page on 2025.6.16, paper on arXiv on 2025.6.20, Gradio demo and model weights on 2025.6.28, online demo space on 2025.7.3, inference code on 2025.7.12, NeurIPS acceptance on 2025.9.18, the dataset on 2025.10.1, Agent-to-Lightroom Protocol support on 2025.10.7, and then training and evaluation code on 2025.12.7 with the evaluation set on 2025.12.8.

The remaining entries are not releases. A third party wrote a tutorial on Lightroom preset creation and it is credited on 2025.7.14, the project was featured on Twitter on 2025.7.9, and a Chinese blog post is linked on 2025.7.4.

So four of the twelve entries are promotion rather than software, and the two most substantial artefacts, the training scripts and the data construction scripts, arrived in the same two-day window at the very end. Nothing has been added to the list since 2025.12.8, while the default branch was last pushed on 2026-04-04. The repository has no GitHub releases at all, so there is no tag history to compare that against.

The successor project is already announced in the same page: JarvisEvo, described as a self-evolving photo editing agent with synergistic editor-evaluator optimisation, at CVPR 2026, with a partially different author list.

A directory named dependence/ and no install command in reach

The top level of the repository is a research layout rather than a packaged one. It holds `src/`, `utils/`, `tools/`, `dependence/`, `envs/`, `docs/`, `data_scripts/`, `lrc_scripts/`, `assets/`, four loose Python entry points named `demo.py`, `demo.sh`, `inference.py` and `inference_e2e.py`, a `.gitmodules` file, and `LICENSE`.

`dependence/` is the name to notice. It is a directory where most projects use something like `dependencies/`, `deps/` or `third_party/`, and its presence tells you the vendored or external components are expected to be committed alongside the code rather than resolved by a package manager. The `.gitmodules` file alongside it points to the same conclusion.

The documentation the readme links does exist in the tree, at least by path: `docs/README_Demo.md`, `docs/README_Inference.md`, `docs/README_Training.md`, `docs/README_Evaluation.md`, `data_scripts/README.md` and `lrc_scripts/clients/agent_to_lightroom/README.md`. The navigation lists six getting-started documents and the readme body names five of them across its update entries.

What the page does not give you is an install command or a requirements file. There is no `requirements.txt` or `pyproject.toml` in the top-level listing, so the environment has to be assembled from `envs/` or from the documents, which is consistent with a release whose primary audience is people reproducing the paper.

The repository licence is unresolved while the dataset states Apache 2.0

Repository metadata reports no recognised licence for this project. There is a `LICENSE` file at the root of the tree, and the file listing cannot tell you what is in it, so the code's terms are not something a reader can confirm from the metadata.

The contrast with the data is sharp. The update entry for the dataset states that MMArt-PPR10k is released under the Apache 2.0 license, and it is built upon PPR10K, which is itself a third-party open-source dataset with its own provenance.

So there are three separate licensing questions stacked on top of each other: the repository's own code, the derived dataset under Apache 2.0, and the upstream collection the derived dataset was built from. Only the middle one is stated with a named licence.

The proprietary surface sits under all three. The agent's whole design is coordinating over 200 tools inside Adobe Lightroom, and the local client speaks an Agent-to-Lightroom Protocol documented in the repository. A licence file covers the code; it does not cover the application it drives, and the page does not raise that distinction anywhere.

Editorial conclusion

JarvisArt is a research release rather than a product, and the useful question is what is actually in the box. The agent coordinates over 200 tools in Adobe Lightroom rather than calling an editing API, which means it operates inside the catalog where presets, masks and develop settings already live. The training recipe is given in enough detail to be reproducible in outline: chain-of-thought supervised fine-tuning for the reasoning, then Group Relative Policy Optimization for Retouching for the tool use. The inference code, the training code, the evaluation code, the data construction scripts and the weights are all linked from the readme.

Two things to check before you build on the evaluation. The headline result is a single figure, a 60 percent improvement over GPT-4o in pixel-level metrics for content fidelity, with no metric named, no baseline value and no evaluation set size on the page, so it cannot be checked from the readme alone; MMArt-Bench is the released evaluation set, and the number to look for is in its own documentation. Second, the dataset provenance section states that the paper describes MMArt as built from PPR10K and other licensed open-source collections, while the currently public releases are a narrower set. That gap is disclosed rather than hidden, which is to the authors' credit, and it means the 55K figure and the public data are not the same thing.

The repository's own licence is unresolved while the dataset it builds on is stated as Apache 2.0, so sort out what you may do with the code separately from what you may do with the data. And note that the newest entry in the readme's update list is dated 2025.12.8 while the default branch was last pushed on 2026-04-04.

Frequently asked questions

Official sources

1. Issues
2. LYL1015/JarvisArt on GitHub
3. README