QualityScaler is MIT with Steam and itch.io listings, and its release tags skip a quarter

MIT source with two storefront listings and calendar version numbers

The top of the file links two storefronts before it links anything else.

There is an itch.io page and a Steam store page for the application. The badge row underneath points at the GitHub releases, the licence file, and the stargazers page, with the releases link appearing twice.

So the same software is reachable three ways: source under a permissive licence, and two paid storefronts. Nothing in the file explains the relationship, and nothing suggests the source is a reduced version.

The release history explains the versioning. The three most recent tags are `2026.4`, `2026.2`, and `2026.1`, dated August 2026, March 2026, and January 2026. There is no `v` prefix and there is no 2026.3, so the sequence skips a quarter.

The roadmap shows how that scheme arrived. Earlier versions are organised as 1.X, 2.X, 3.X, and 4.X, each with its own list of completed items. The final group is headed 2026.X, which is where the calendar numbering begins.

So the project renumbered itself mid-life, from minor-version lines to calendar versions, and did not retroactively reissue the tags for the years it had already shipped under the old scheme.

The GPU path is DirectX 12 rather than a vendor runtime

The requirements table is three rows and the third one is the interesting one.

The operating system minimum is Windows 10 or Windows 11. Memory is 8 GB or more. And the GPU line asks for any DirectX 12 compatible card with at least 4 GB of video memory.

That last row is the whole architecture in one sentence. There is no CUDA requirement, no ROCm requirement, and no vendor-specific runtime, because the inference engine is the DirectML build of ONNX Runtime, which is the only pinned dependency in the requirements file at a specific version.

The roadmap confirms it. An early item in the 1.X list is a switch to a DirectML build in order to support all DirectX 12 compatible GPUs, naming AMD, Intel, and Nvidia.

So the application runs on a discrete AMD or Intel card the same way it runs on an Nvidia one, at the cost of giving up the vendor-specific paths. On a machine with a modern Nvidia card that means the DirectML path rather than a CUDA path, which is a real performance question the file does not discuss.

There is a second GPU-related feature in the list: multiple GPU support, and a roadmap item that describes it as being for a machine with two GPUs, an integrated one and a dedicated one.

Two Python frameworks are credited and the engine moved between them

The how-it-is-made section lists seven dependencies and then says the application is completely written in Python, from backend to frontend.

Two of those entries are machine learning frameworks rather than interface libraries, and the roadmap records a migration between them.

An early item in the 1.X list switches to a DirectML build of PyTorch in order to reach all DirectX 12 cards. Then, in the 3.X list, there is a new AI engine powered by DirectML ONNX Runtime, and a later 4.X item is an updated AI engine of the same kind.

So the engine moved from PyTorch to ONNX Runtime, twice over the project's life.

What makes that worth noting is that PyTorch is still in the credited stack while the engine it was migrated away from is named in the same list. The requirements file does not include either framework directly; it includes the ONNX Runtime DirectML build and a converter library, which is consistent with the engine being ONNX at the end.

The interface stack is smaller and separate: a custom widget toolkit for the desktop interface, OpenCV for image work, and PyInstaller for packaging the result into an executable. The last of those is the reason there is no install script.

Eight of nine requirements are unpinned and the OpenCV build is the headless one

The dependency file is eleven lines long and organised into commented groups.

numpy
opencv-python-headless
Pillow
natsort
psutil
pywin32
winotify
pyinstaller

Only one package in the whole file carries a version. The ONNX Runtime DirectML build is pinned to an exact release. The other eight are bare names.

That means a fresh install of the requirements file resolves whatever is current for each of them, on whatever date the install runs. For an application whose model behaviour depends on the runtime version, the one dependency that would matter most is the one that is pinned, and the eight that float are the ones that would move underneath it.

Two details in the list are worth a second look.

The OpenCV package is the headless build, which is the variant with no graphical windowing support, in an application whose entire user interface is a desktop window. That is a deliberate choice for avoiding a conflicting system install, and it also means the application never uses OpenCV to display anything.

Two of the remaining packages are Windows-only by nature rather than by choice, one for Windows notifications and one for Windows API access, which follows from the requirements table rather than being a surprise.

The file also ends with an empty group header, a comment line with no packages under it.

The AI models come from a third-party file host

The section on running it yourself lists four prerequisites, and two of them are downloads from outside the project.

Python installed, an editor installed, the AI models downloaded, and ffmpeg downloaded.

The models link is not a release asset. It points at a free file hosting service, and the models are then extracted into a directory inside the project named for the model format.

So the application itself needs no internet connection, which is the privacy claim on the feature list, but obtaining the models does. Those two statements are both true and they are about different phases.

The ffmpeg prerequisite is more specific than most: a release build rather than a snapshot or a distribution package, and a particular archive named in the instruction.

Then the steps. Download the project as a zip, extract it, extract the models into one folder, extract ffmpeg into another folder, open the project in the editor, click the single Python file, install the requirements from the terminal panel, close the editor and reopen it, and press the run button.

There is no command line entry point anywhere in that sequence. The documented way to run from source is a Python file executed by an editor's run button.

Building from source means installing an editor and restarting it to refresh dependencies

Two steps in the source instructions are unusual enough to be the actual cost of this path.

The first is that the editor is a prerequisite. To run the application from source you are told to install VSCode, not a runtime and not a build tool, and then to open the project directory in it and click a file in its sidebar.

The second is the instruction to close the editor and reopen it, with a parenthetical explanation that this refreshes all the installed dependencies.

That step exists because the editor's selected interpreter does not see packages installed into it after the editor started. It is a known property of that workflow rather than a fault in the project, but it is also a step that would not exist in a build where dependencies are installed before the process that uses them starts.

The rest of the path is ordinary: get a zip, extract it, put two archives into two folders, install from a requirements file, run.

What is absent is just as informative. There is no packaging step described, no build command, and no test command in the instructions, even though PyInstaller is a declared dependency. Packaging is what the storefront builds do, and the source instructions stop at running the file in an editor.

A feature depends on a tool named in neither dependency list

The 2.X group of completed items includes metadata extraction and application from the original file to the upscaled file, and it names the tool in parentheses.

That tool is not in the requirements file, and it is not in the list of four prerequisites either.

So a completed, shipped feature depends on a program the project neither installs nor asks you to download. A user following the source instructions exactly would reach that feature and find it does nothing, with nothing in the documentation to explain why.

The same gap exists elsewhere in the file, though less consequentially. The roadmap mentions ffmpeg for frame extraction and for hardware-accelerated encoding, and ffmpeg is a prerequisite, so that one is covered.

Two more dependencies are implied without being named as prerequisites: the conversion path from the training frameworks to the inference format is covered by a converter library in the stack, and the model files themselves are covered by the download step.

The exiftool case is the only one where a shipped capability has no documented way to obtain what it needs. It is one line in a long checklist, which is why it survives.

Two license files, one Python file, and no ignore file above the model folder

The repository root has seven entries, and the shape of them is unusual for an application with this many features.

There are two directories, one for the model files and one for assets. There is a single Python file at the root, which is the entire application. There is the requirements file and the README.

And there are two licence files, one named `LICENSE` and one named `LICENSE.txt`.

Two licence files in one root is the kind of duplication that comes from a rename that was applied to one and not the other, and it means a tool looking for a licence finds two candidates with no way to tell whether they differ.

The single Python file is the other thing to understand before reading anything else. The whole backend and frontend described in the stack section is one file at the root, and every feature on the list, the tiling, the interpolation, the stop and resume, the multi-threading, the metadata copying, is implemented in it. The two directories hold only the things the user supplies.

There is also no ignore file at the top level, while the instructions tell users to extract model archives into a directory inside the project. A user who follows the steps and then initialises a repository around the result would be in a position to commit the models.

Editorial conclusion

QualityScaler suits a Windows user with a DirectX 12 card who wants local upscaling without sending media anywhere, and the tiling behaviour and the stop and resume path are the two features that distinguish it from a command line model runner. Two things to know. The privacy claim covers the application, not the setup, because the models are fetched from a third-party file host rather than a release asset. And the repository is a single Python file with an unpinned dependency list, so building it from source is a development exercise rather than a supported install path; the storefront builds are the ones to take.

Frequently asked questions

Official sources

1. Djdefrag/QualityScaler on GitHub
2. Issues
3. License: MIT
4. README
5. Releases