Comparing AI image models: how Axiris tests
A useful comparison does not look for the best model: it asks a precise question, fixes the conditions and documents what is observed. How a test reads at Axiris (the date, the hardware, the conditions, the before / after comparator) and where the published tests are.
Comparing AI image models is not about naming the best: a model that excels at one task is mediocre at another. A useful comparison starts with a precise question (which one respects the composition, keeps a character consistent, edits without destroying the rest, runs on my hardware) and is then carried out with the same intention and known conditions: the model and its version, the settings, the references and the hardware, all documented. At Axiris, every published test carries its date, its hardware and its conditions, separates what the maker announces from what we measured, and whenever possible shows a before / after comparator that you drag yourself; the tests live in the guides and the news.
Comparing without manufacturing a ranking
Model comparisons often take the form "model A versus model B: which is best?". Axiris avoids that question when it does not match a real need: a model can be excellent at one task and far less interesting at another.
This page says how we compare. The tests themselves are in the guides and the news.
Defining the test
A useful comparison starts with a precise question: which one best respects a composition? best keeps a character consistent? edits an image most precisely without touching the rest? produces the best photorealism? best understands a complex instruction? works best locally? integrates best into ComfyUI? matches our hardware?
Two opposite conclusions on the same subject almost always mean the question was badly asked.
Same intention, known conditions
A test reduces needless differences. We document the model and its version, the description and the settings, the references, the hardware, the workflow, and our observations. Same description, same settings, same seed: what changes between two renders is then the model, and nothing else.
The goal is not a podium. The goal is to understand the model's behaviour: what it does well, what it does badly, and under which conditions.
What the maker announces, what we measure
The specifications and benchmarks published by developers are useful. They do not replace real use in a graphics pipeline. Axiris therefore always separates the announced capabilities from our own tests and observations, and says so plainly. When we relay a vendor's figure before having measured it, we write it down: the news item on SoL-Refiner (6 October 2026) quotes the times announced by NVIDIA while stating that they are NVIDIA's figures, not yet ours, while our own measurement is under way.
How it reads at Axiris
Every published test carries the date, the hardware, the conditions, and, when the subject lends itself to it, a before / after comparator that you drag yourself, in image and in video, to judge on the pixels rather than on a claim. The first complete example is the news item DLSS 5 in ComfyUI: we publish our pack, and what we understood (10 October 2026): three comparators, five measured conclusions, one of which contradicts our first hypothesis.
The same principle governs day-to-day work: "the rest does not move" is checked on the pixels at every pass; it is not a promise. See Building the image by areas.
Which model to choose?
In the end, the comparison has to help you decide. If a model that is less spectacular on a benchmark lets the creative keep more control (correcting an area without starting over, holding an identity, replaying a render), it is the best choice for that workflow. Next: How to choose an AI image model?, and what we use today: Models of the moment.
Contact request: a first conversation, free and with no commitment. Every practice is different; it is by listening to you that we propose what suits you.