DJV: an image review player for high bit-depth EXR sequences
Free EXR file viewer. DJV is a free, open-source high bit-depth image sequence player built for professional film, VFX & animation workflows. Use it for frame-accurate dailies, shot review, and A/B comparisons. Available for Linux, macOS, and Windows.
At a glance
- What is it?
- DJV is a free, open source media player built for professional image review, with real-time high bit-depth EXR playback, A/B comparison in wipe, overlay and difference modes, OpenTimelineIO timelines, OpenColorIO colour management and multi-track audio. Its deliberate limitation is the codec set: the packaged builds ship only patent-free codecs, so a camera movie needs external FFmpeg.
- Who is it for?
- DJV fits a VFX, animation or film team reviewing high bit-depth image sequences who need a real A/B comparison and a timeline rather than a slideshow. It does not fit a workflow built on camera originals, because the packaged builds exclude H.264, HEVC, ProRes, DNxHD, DV and AAC, and it does not fit a Python 3.14 environment today, since the OpenTimelineIO dependency has no prebuilt wheel there.
- Can I use it commercially?
- Yes. BSD-3-Clause is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly C++, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A player for judging renders, not for watching movies
DJV is described as a free, open source media player built for professional image review, with real-time high bit-depth EXR playback, A/B comparison, OTIO colour management and more, under the slogan that you should never compromise on your renders again.
The audience is a studio or a pipeline engineer, not a consumer. The repository topics are cineon, dpx, jpeg, openexr, playback, png, quicktime, tga, tiff, vfx and viewer, and the README's summary names the workflow explicitly: frame-accurate dailies, shot review and A/B comparisons. The description calls it a high bit-depth image sequence player built for professional film, VFX and animation workflows.
That framing explains the technical centre of the project. A frame sequence is not a video file. It is thousands of individual images, each of which might be 16-bit or 32-bit float, and the player has to hold the colour pipeline intact while showing them at whatever speed the machine allows. The feature list leads with support for high resolution and high bit depth images for that reason.
DJV is written in C++ and is available for Linux, macOS and Windows, and it is built on two libraries from the same organisation, tlRender for the rendering and playback side and feather-tk for the user interface. The project is BSD-3-Clause licensed and is published as a production stable application, with the pyproject classifier reading Development Status :: 5 - Production/Stable.
A/B comparison is the feature that justifies a separate player
The core of DJV is the comparison, and the README shows it twice with screenshots: two images being compared with a wipe, and two images being compared with a horizontal layout.
Three comparison modes are listed, wipe, overlay and difference. Each answers a different question about a render. A wipe puts two versions side by side with a moving boundary, which is how a supervisor decides whether a shot has changed. An overlay superimposes one on the other, which shows displacement and timing differences that a side-by-side view hides. A difference mode shows what changed rather than what is there, and it is the one that turns a review session into a technical conversation.
None of this exists in a general purpose media player, and that is the whole argument for a separate tool in this category. The difficulty is not the wipe itself, it is doing it correctly on 16-bit or float EXR data with a consistent colour transform across two images, at interactive speed, while a supervisor is watching. A comparison that is subtly wrong in the colour pipeline is worse than no comparison, because it invites a decision based on a rendering artefact.
The other features sit around that centre. There is a timeline with OpenTimelineIO, so a sequence can be reviewed against a cut. There is colour management with OpenColorIO, so the display transform is explicit rather than implied. There is multi-track audio with variable speed and reverse playback, which matters when a review includes scratch dialogue. And there is experimental support for USD files, which is listed as experimental and should be treated as a direction of travel rather than a settled feature.
The codec list is short on purpose, and the README says so
The most important paragraph for anyone about to install DJV is the codec note, and the project is unusually direct about it.
The download packages and the pip install include only the video and audio codecs that need no patent license. The list is AV1, APV, VP8 and VP9, MPEG-2 and MPEG-4, MJPEG, FFV1, CineForm, UT Video, HuffYUV, MagicYUV, Dirac, PNG and v210 for video, and FLAC, Opus, Vorbis, ALAC, MP3 and PCM for audio.
What is not in that list matters more: H.264, HEVC, ProRes, DNxHD, DV and AAC are not among them, so a camera movie does not open out of the box.
There are two documented ways around that, and they differ in approach. You can install FFmpeg yourself and point DJV at the external FFmpeg command, with the details in the documentation. Or you can build from source, where the codecs are compiled in.
The distinction is not cosmetic. The external command path keeps the application binary small and legally uncomplicated, and it means the codec support is whatever the FFmpeg you install happens to provide. The source build bakes the codecs into the player, which is a heavier build with a heavier licence surface, and it is the only option that gives a single self-contained binary that opens a camera original with no external dependency.
For a studio that reviews camera originals alongside renders, that choice should be made deliberately, because the difference shows up as a broken first open on the day it matters.
pip install DJV-viewer, and the hyphen is not a typo
DJV can be installed with pip for Python 3.12 or newer on Linux, macOS and Windows, and the two commands are:
pip install DJV-viewer
djvThe djv command runs the application. The name of the distribution carries a hyphen for a specific reason, and the pyproject file explains it in a comment: the djv name on PyPI belongs to another project, so this one is named after the subreddit, r/DJV_viewer, with the hyphen that PyPI shows it with. The package imports as djv and the command is djv all the same.
The bindings are importable, and they are not only the application's own module. The README says the bindings DJV is built from are importable as djv, alongside tlrender and feather_tk, with the details in the Python documentation. So a pipeline can drive the viewer from a script rather than by hand.
There is one environment caveat and it is specific. Python 3.12 or 3.13 is the easy choice for now. The bindings depend on OpenTimelineIO, which has no prebuilt wheels yet for Python 3.14, or for Intel macOS, and there pip builds it from source, which needs a C++ compiler and the Python development files, python3-dev on Debian and Ubuntu and python3-devel on Fedora and Rocky.
That is the cost of the pip path on a newer Python or on an Intel Mac: a source build of a dependency, which on a machine without a compiler means the pip install is not the shortcut it appears to be.
A super build with pinned wheels, and why the pins matter
DJV is built with CMake, and a super build is provided that builds the dependencies and then DJV, driven by a script per platform:
sh DJV/sbuild-linux.sh
sh DJV/sbuild-macos.shOn Windows the equivalent is the batch file, DJV\sbuild-win.bat. The system packages each platform needs, the build options, and how to build against a distribution's own packages are all in the building documentation.
The dependency pins in pyproject.toml are explained in comments, and those comments are the most useful part of the file for anyone building it. tlRender is pinned to one release, here and in the dependencies below, and feather-tk to the one that release pins, because DJV is built against those wheels' headers and loads their libraries. A DJV release needs the tlRender it was built with on PyPI first.
The nanobind pin has a different reason. nanobind is the version feather-tk's module is built with, and the modules share types only when they match. That is a Python binding detail with a hard consequence: if the nanobind version differs between the two modules, the types they exchange are not the same types, and the failure appears at runtime as a type error rather than at build time.
The build requirements in the file are scikit-build-core, nanobind, tlRender and feather-tk, with the scikit_build_core.build backend, and the project declares a single runtime dependency, tlRender==0.25.0. The repository also carries a .gitmodules file and a deps directory, so some dependencies are fetched as submodules rather than resolved by the package manager, and there is a sanitize.sh script next to the build scripts, which tells you the project expects to be built under sanitizers at least some of the time.
BSD-3-Clause, releases every few days, and a pipeline behind it
The licence is BSD-3-Clause, with LICENSE.txt at the root of the repository and the same identifier in the pyproject license field and in the license-files list. For a studio tool, that is the licence you want: no copyleft obligations on a pipeline that renders and reviews in-house, and no requirement to publish internal tooling.
The release cadence is fast and regular. Version 3.7.1 was published on 2026-10-02, 3.7.4 on 2026-10-04 and 3.7.5 on 2026-10-15, and the last push to the repository was on 2026-10-19. For a tool that people use to judge renders, that matters more than it would for a library, because a crash during a review session is a broken session, and a release every few days means the fix is already out.
The repository structure also tells you this is a product rather than a demo. There is a lib directory for the code, a bin directory, a tests directory, a docs directory, an etc directory for the icons and images the README embeds, a cmake directory, a deps directory, an examples directory with a python subdirectory, and a ChangeLog.md. Packaging scripts exist per platform as package-linux.sh, package-macos.sh and package-win.bat, and the CI workflow has its own badge in the README.
The one thing to check before depending on it is the Python floor, which is 3.12, combined with the OpenTimelineIO wheel situation. A studio standardising on a newer Python will hit a source build of that dependency, and the cost of that is a C++ toolchain on every machine that installs the viewer.
Editorial conclusion
DJV fits a VFX, animation or film team reviewing high bit-depth image sequences who need a real A/B comparison and a timeline rather than a slideshow. It does not fit a workflow built on camera originals, because the packaged builds exclude H.264, HEVC, ProRes, DNxHD, DV and AAC, and it does not fit a Python 3.14 environment today, since the OpenTimelineIO dependency has no prebuilt wheel there. Before you install, decide whether you will point it at an external FFmpeg or build from source, and pin Python to 3.12 or 3.13 rather than 3.14.
Frequently asked questions
What is DJV used for?
DJV is a free, open source media player built for professional image review, used for frame-accurate dailies, shot review and A/B comparisons of renders. It supports high resolution and high bit depth images and is available for Linux, macOS and Windows.
Why will DJV not open my H.264 or ProRes camera footage?
The download packages and the pip install include only the codecs that need no patent license, so H.264, HEVC, ProRes, DNxHD, DV and AAC are not included. You can install FFmpeg yourself and point DJV at the external FFmpeg command, or build from source where the codecs are compiled in.
How do I install DJV with pip?
Run pip install DJV-viewer and then the djv command. The package is named DJV-viewer because djv on PyPI belongs to another project, but it imports as djv and the command is djv. Python 3.12 or newer is required.
Which Python versions work with the DJV bindings?
Python 3.12 or 3.13 is the easy choice for now, because the bindings depend on OpenTimelineIO, which has no prebuilt wheels yet for Python 3.14 or for Intel macOS, so pip builds it from source and needs a C++ compiler plus the Python development files.
What licence is DJV released under?
BSD-3-Clause, declared in pyproject.toml with the LICENSE.txt file listed in license-files. The project also ships OpenTimelineIO timeline support, OpenColorIO colour management and experimental USD support.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/grizzlypeak3d-djv)Was this useful?