EvTexture: event-driven video super-resolution on an expired toolchain

The journal extension is accepted and still not released

The single most important fact about this repository is a gap between two dates.

The paper was accepted by ICML in May 2024, and the repository was initialised on 2024-05-25. Video demos followed on 2024-06-07, pretrained models and test sets and a Docker image on 2024-06-08, dataset preparation details on 2024-06-28, and a Colab file for a quick test on 2024-07-02. The single release, v0.0, is dated 2024-06-19 and is described as pretrained models, test sets and visual results rather than as code.

Then the news entry for 2026-02-02: the journal extension EvTexture++ has been accepted by IEEE TPAMI. And in the highlighted note above the news list, the README states that the source code and pre-trained models for EvTexture++ are currently under preparation and will be released in this repository in due course.

The last push to the repository was on 2026-06-11. That is four months after the acceptance announcement, and the sentence saying the code is under preparation is still the current state of the README.

So the situation is: there is an ICML 2024 implementation, released as repository code with a v0.0 tag that covers assets only, and there is a TPAMI 2026 extension that is the newer and presumably better method, announced in February 2026 and not yet available in June 2026.

That matters more than a normal unreleased-feature gap, because a journal extension of a conference paper in this field is usually a substantial revision rather than an erratum. Video super-resolution with event data is a topic where the last two years have moved the state of the art on the datasets involved, and the TPAMI version is the one that would have been measured against it. Anyone starting this work today is therefore choosing between reproducing a 2024 result with a 2024 environment, or writing the extension themselves from the paper.

The papers themselves are both reachable. The ICML version is on arXiv at 2406.13457, with a poster link. The TPAMI version is on IEEE Xplore at document 11369964, with its own poster and a separate project page at dachunkai.github.io. The authors are Dachun Kai, Jiayao Lu, Yueyi Zhang and Xiaoyan Sun, at the University of Science and Technology of China.

The honest reading for an evaluator is that this is a research artefact in the state research artefacts are usually in: the conference version is complete and reproducible, the journal version is announced, and the gap is a matter of one author's bandwidth rather than a decision not to release.

Inference on your own video is a commented-out checklist item

There is a line in the README's news list that is worth reading slowly, because it defines the boundary of the project better than any feature description.

The news list is a markdown checklist of dated milestones, and the first entry is commented out with HTML comment markers. It reads, unchecked: provide a script for inference on the user's own video.

So the capability to run EvTexture on your own footage is a considered item that was written down and then deliberately disabled. It is not a missing feature someone forgot to mention, and it is not something the documentation is silent about in a way you would have to guess at. The author listed it, left the box empty, and commented the line out.

Why that would be the case is not stated, and the plausible reasons are worth separating. The preprocessing that produces the event data is non-trivial and dataset-specific: the test sets are shipped as HDF5 files with events already computed, which means the pipeline that pairs a low-resolution video with an event stream is not in the repository. Without that pairing, a user with their own video has no way to construct the model input. That is a substantial piece of work, and it is the kind of work that is specific to a paper's experimental setup rather than general.

A second possibility is licensing or provenance. Event data for REDS and Vid4 comes from a public event dataset, and a script that ingests arbitrary user video would have to handle event streams the authors have never seen, including the case where a user has no event camera at all, in which case the whole premise of the method does not apply.

Either way, the practical consequence is firm. This repository reproduces published benchmark numbers. It is not a tool for enhancing your own video, and if that is what you need, the closest routes are to reimplement the event preprocessing yourself against the paper's description, or to use a conventional video super-resolution method that does not require a second sensor modality.

The Colab file released on 2024-07-02 is a quick test, and a quick test on the provided test data is a different thing from inference on arbitrary input. That distinction is worth keeping in mind when you see a Colab link in a repository of this kind: it lowers the barrier to running the benchmark, not to running your own footage.

This is also the kind of honest negative that makes the rest of the README more trustworthy. A project that quietly implied you could run it on your own video would be harder to evaluate than one that lists the item and comments it out.

Python 3.7, CUDA 11.1 and setup.py develop: the install path has expired

The installation section is precise about versions, which is good practice, and every version it names is out of support.

The dependencies are Miniconda, CUDA Toolkit 11.1.1, torch 1.10.2+cu111 and torchvision 0.11.3+cu111, and the wheel URLs in the README are explicitly cp37 and linux_x86_64. So this is a Python 3.7, CUDA 11.1, x86-64 Linux environment, and the conda create line says python=3.7 explicitly.

Python 3.7 reached end of life in June 2023. CUDA 11.1 was released in 2021. PyTorch 1.10.2 is from late 2021. So the documented stack is three to five years old, and the Python version is one that no longer receives security fixes.

The install block is:

conda create -y -n evtexture python=3.7
conda activate evtexture
pip install torch-1.10.2+cu111-cp37-cp37m-linux_x86_64.whl
pip install torchvision-0.11.3+cu111-cp37-cp37m-linux_x86_64.whl
git clone https://github.com/DachunKai/EvTexture.git
cd EvTexture && pip install -r requirements.txt && python setup.py develop

The last line is the one that will fail on a current machine. python setup.py develop has been deprecated for years and removed from modern setuptools, and pip no longer runs setup.py install paths for packages that declare a pyproject build backend. This repository has setup.py and setup.cfg but no pyproject.toml, so it relies on the legacy path, and a recent pip will refuse or error rather than doing what the README says.

The workaround is not hard. pip install -e . with a pinned older setuptools in the environment will do it, since you are already creating a Python 3.7 environment specifically for this. But it means the documented first-try path is broken and anyone attempting it will spend time on an error that is about packaging tooling rather than about the code.

The Docker route has the same problem in a different place. The image is published on Alibaba Cloud at registry.cn-hangzhou.aliyuncs.com/dachunkai/evtexture:latest, and there is a Dockerfile in the docker directory you can build yourself. If the image was built in 2024 it has the same old Python and the same old setuptools inside it, so the develop step will fail there too unless the image pins a working setuptools. The README's own follow-up command is:

source activate evtexture && cd EvTexture && python setup.py develop

which is the same deprecated call, run inside the container.

The nvidia-docker prerequisite is stated properly, with a link to the container toolkit installation guide, and the note that the pulled or self-built image contains a complete conda environment named evtexture is useful. So the container route is the more likely to work of the two, provided the image is not too old to still be pullable.

The broader point is not that an old toolchain is a defect. A paper artefact should pin the environment it was written in, and pinning torch 1.10.2 is exactly right for reproducibility. The point is that the project has not been touched since June 2024 in its install path, and the ecosystem it depends on has moved past it.

Bicubic at 4x only, with the event data baked into HDF5 files

The scope of what is released is narrow, and the narrowing is consistent across the models, the scale and the data.

There are exactly two pretrained weights. EvTexture_REDS_BIx4.pth is trained on the REDS dataset with BI degradation for 4x SR scale, and EvTexture_Vimeo90K_BIx4.pth is trained on Vimeo-90K with BI degradation for 4x SR scale.

So both are 4x, and both use BI degradation, which is bicubic downsampling. That is the cleanest possible degradation model. Real video goes through a camera sensor, a codec and a network before it reaches you, and its low-resolution counterpart is not a bicubic downsample of a high-resolution original. Training and evaluating exclusively on bicubic is the standard convention in the super-resolution literature because it isolates the upsampling problem from the degradation problem, and it is what makes numbers comparable across papers. It is also the condition under which a method's real-world behaviour is least tested.

If your interest is the benchmark comparison, this is exactly right and there is nothing to complain about. If your interest is sharpening video you have, bicubic-trained weights are a mismatch, and the project offers no other scale, no other degradation and no training script in the repository listing.

The test data is equally specific. Two preprocessed test sets are provided, Vid4_h5 and REDS4_h5, described as HDF5 files containing preprocessed test datasets, including events, and the README is explicit that the events are included.

That is the second hard boundary. The method consumes two modalities: a video stream and an event stream from an event camera. The event stream is what the paper's contribution is built on, and it is the part you cannot synthesise. The preprocessing that pairs a low-resolution video with a synchronised event stream, resamples them, and packs them into the shape the network expects is not in the repository. The datasets directory is there and the options directory is there, but the recipe that turns raw REDS plus raw events into Vid4_h5 is not shipped.

The reference outputs are available, though. The README says the inference results on REDS4 and Vid4 can be downloaded, alongside the video demos, which are described as 4x upsampling results on those same two test sets. So the full reproduction chain exists: weights, inputs with events, and expected outputs. What does not exist is a way to substitute your own input.

The test entry points are worth noting for the hardware question. They are distributed test scripts:

./scripts/dist_test.sh [num_gpus] options/test/EvTexture/test_EvTexture_Vid4_BIx4.yml

with a matching one for REDS4. The GPU count is a positional argument, so single-GPU testing means passing 1. The configuration lives in a YAML file under options/test/EvTexture/, which is the BasicSR convention and means the test settings are inspectable and editable rather than baked into the script.

basicsr/ is vendored whole, so this is an architecture plugin

The repository listing explains the shape of the codebase in one line, and it changes what adopting this means.

The top level is .gitignore, EvTexture_test.ipynb, LICENSE, README.md, VERSION, basicsr/, datasets/, docker/, experiments/, options/, requirements.txt, scripts/, setup.cfg and setup.py.

basicsr/ is at the top level, and the network architecture file is at basicsr/archs/evtexture_arch.py. So the entire BasicSR framework is vendored into this repository, and EvTexture is registered as one architecture inside it.

That is a significant fact for an evaluator. BasicSR is a general-purpose image and video restoration framework with its own conventions: architectures go in archs/, configurations in options/, training and test scripts in scripts/, pretrained models in experiments/pretrained_models/, and the dataset and result directories follow the same pattern. EvTexture inherits all of it, including its strengths and its constraints.

The strengths are real. You get a mature, well-documented restoration training and evaluation pipeline rather than a bare model definition. The dist_test.sh and train scripts, the YAML option files, the pretrained_models convention and the results directory all come from a framework that many restoration papers have been built on, so the setup is one other researchers will recognise.

The constraints are equally real. You inherit BasicSR's dependency set, which is where the twenty-four entries in requirements.txt come from. You inherit its setup.py-based install, including the version file generation pattern, since the setup.py at the root writes basicsr/version.py from a VERSION file plus a git hash. And you inherit its Python compatibility, which is the source of the 3.7 floor.

The VERSION mechanism is worth a look because it shows the framework's fingerprint. setup.py reads a plain text file called VERSION at the repository root, splits it on dots, writes a generated basicsr/version.py containing a timestamp, the short version, the git hash and a parsed version tuple, and packages that. There is a commented-out alternative branch in the get_hash function that would read the version from basicsr/version.py instead of from git, with a comment saying it is currently ignored.

So the version is a hand-maintained text file at the root, the git hash is appended automatically, and the fallback that would read the version back from the generated module is disabled. That is the BasicSR pattern almost exactly, and it explains why the one release tag is v0.0: the version file is what the package reports, and the tag is a separate thing that nobody has updated in two years.

The practical adoption question is therefore not whether to use EvTexture but whether to run BasicSR. If you already have a BasicSR setup, adding this is a file in archs/ and a YAML in options/. If you do not, you are adopting a restoration framework to run one architecture, and you should read BasicSR's own documentation as part of your evaluation.

Four mirrors, an Alibaba Cloud registry, and two ways to try it

The distribution side of this project is unusually well organised for a research repository, and the details are worth listing because they are the difference between reproducing a result in an evening and not reproducing it at all.

The pretrained models and the preprocessed test sets are available from four places: GitHub Releases, OneDrive, Google Drive and Baidu Cloud. All four are linked, and the README gives the Baidu extraction code inline. Two models, two HDF5 test sets, and the reference inference results, all reachable from four independent services.

That matters practically. A research artefact hosted only on Google Drive becomes unavailable when a quota is hit, and an artefact hosted only on GitHub Releases becomes unavailable if a large file is removed for policy reasons. Four mirrors is defensive, and the Baidu Cloud link plus the Alibaba Cloud Docker registry together suggest the authors expect a significant share of users in China, where Google Drive is blocked and GitHub is slow.

The Docker image is on Alibaba Cloud's registry at registry.cn-hangzhou.aliyuncs.com. That is a public container registry operated by Alibaba Cloud in its Hangzhou region, and it is a reasonable place to publish for a project with Chinese authors and a Chinese user base. The alternative is to build from the Dockerfile in the docker directory, which the README offers as Option 2 with a single command.

Both containers and a local conda environment are offered, and the Colab file from 2024-07-02 is a third route for a quick test with no local setup at all. Plus there is EvTexture_test.ipynb in the repository root, a Jupyter notebook. So a new user has four ways in: a Colab notebook, a Docker image, a local conda environment, or a local Jupyter notebook.

That is a lot of options, and it is worth noticing what each is for. The Colab file and the test notebook are for evaluating whether the method does what the paper claims. The Docker image is for reproducing a benchmark result with the exact environment. The local conda environment is for anyone who needs to modify the code, and it is the one with the deprecated setup.py develop step.

The two-project-page structure is also a small sign of care. The ICML version has its project page at dachunkai.github.io/evtexture.github.io and the TPAMI version has a different one at dachunkai.github.io/evtexture-project-page. Maintaining two sites rather than collapsing them into one means the older paper's demos and the newer extension's material are both reachable, which is what a reader arriving from either citation would expect.

The one thing missing from the distribution story is any statement about long-term availability. No archive.org link, no DOI for the artefacts, no Zenodo deposit. If the Alibaba Cloud container and the four cloud drives disappear, the pretrained models and the preprocessed event test sets are gone, and they cannot be regenerated from the repository because the preprocessing is not shipped. That is the fragility to be aware of when deciding whether to build on this.

requirements.txt lists argparse, both tensorboards, and nothing pinned

The dependency list has a few entries that are wrong in ways worth naming, because they are the kind of thing that signals an inherited file rather than a maintained one.

The full list is: addict, argparse, einops, future, h5py, lpips, lmdb, matplotlib, numpy, opencv-python, pandas, Pillow, pyyaml, requests, scikit-image, scipy, setuptools, tensorboard, tensorboardX, torch, torchvision, tqdm, wandb and yapf.

Three observations.

argparse is a Python standard library module. It has been in the standard library since Python 2.7 and is not installable from PyPI in any meaningful way, so listing it as a requirement either does nothing or installs an unrelated ancient package. This is a leftover from a pre-Python-3 requirements file.

tensorboard and tensorboardX are both listed. tensorboardX was a third-party backport written to provide a TensorBoard-compatible summary writer before TensorFlow shipped one natively. TensorFlow 1.x is long gone and TensorFlow 2.x has had a native TensorBoard for years, so having both is redundant. Installing both can produce two summary writers competing over the same log directory, and it is a dependency-hygiene signal.

setuptools is listed as a runtime requirement. It is a build tool, and while it is true that you need it to run setup.py, it does not belong in a requirements file for a package that is being installed as a develop or editable install.

The pinning is the larger issue. Three of the twenty-four have version floors: numpy at 1.17 or newer, torch at 1.10.2 or newer, torchvision at 0.11.3 or newer. The other twenty-one are completely unpinned, including lpips, opencv-python, numpy's own ecosystem neighbours and every transitive dependency they pull in. So pip install -r requirements.txt on the Python 3.7 environment resolves whatever was latest on the day you run it, in a Python version that those packages no longer support.

That is the concrete risk: numpy has had several releases where the newest version dropped Python 3.7, and scikit-image, opencv-python and scipy have all moved their minimum Python versions upward. On a fresh install today, pip's resolver should pick compatible versions, so this is more likely to produce an older stack than a broken one. But it is a resolution performed at your machine's expense rather than one the author performed, and the result is not the stack the results were produced on.

Two entries in the list are worth understanding on their own terms. lpips is a learned perceptual image patch similarity metric, and its presence alongside scikit-image tells you the evaluation is not only PSNR and SSIM but also a perceptual metric, which for a super-resolution paper is the right set. wandb and tensorboard together mean experiment tracking is supported by two services, which is generous rather than minimal, and is presumably a holdover from experimentation that tried both.

And yapf is the formatter, rather than black. That is a style choice inherited from BasicSR, and it is a reasonable one for an older codebase, though it means a contributor with black configured by habit will get different results.

Editorial conclusion

Use EvTexture if you are reproducing the ICML 2024 results on the Vid4 or REDS4 benchmarks, because that is the one thing the repository fully supports: pretrained weights, preprocessed test sets with events, distributed test scripts and reference outputs across four download mirrors. Do not adopt it as a video super-resolution tool for your own footage, because the script for inference on a user's own video is a commented-out, unchecked item in the README's own news list, so there is no supported path. Do not wait for EvTexture++, since it was accepted by IEEE TPAMI on 2026-02-02 and the README still said the code and models were under preparation as of the last push on 2026-06-11. Verify four things. Whether you can build the documented environment at all, because Python 3.7 reached end of life in June 2023, the CUDA 11.1.1 wheels are from 2021, and the install instruction uses setup.py develop, which current setuptools has removed. Whether your degradation model matches, since both released weights are trained for bicubic at 4x only, and real video has compression artefacts that bicubic training does not represent. Whether you have the event data, since the test sets are HDF5 files with events pre-baked in and the preprocessing is not shipped. And how many GPUs you need, because the test entry point is a distributed script that takes a GPU count. The deciding fact is that this is a paper artefact with complete benchmark reproduction and nothing beyond it, and the toolchain it was written against expired while the code sat unchanged.

Frequently asked questions

Official sources

1. DachunKai/EvTexture on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases