Novus Examples
Read a spec sheet and use what it tells you
Every file in the library ships with its exact properties — noise sigma, silence timestamps, form fields, encodings, dimensions, and the seed that produced it. Here is how to use them.
The spec sheet is the reason this library is different from a folder of downloaded files. Every file is produced by a deterministic script, so its properties are not measured after the fact — they were specified before it existed.
That changes what a test can tell you. Instead of "the tool handled this file badly", you get "the tool fails above this noise level, at this encoding, in this colour space", which is a sentence someone can act on.
Contents
Two ways to finish
Pick a fixture
Use the sheet to choose the right difficulty.
Explain a failure
Use the sheet to name the property that broke it.
- 1
1. Know what a sheet carries
Depending on the category, a sheet states things like dimensions, colour space, bit depth, encoding, noise sigma, silence timestamps, sample rate, channel layout, form field inventory, and the seed used to generate the file.
The seed is the quietly important one. It means the file is reproducible: anyone with the seed and the generator gets a byte-identical fixture, which is what makes a bug report from this library reproducible in a way an attached file is not.
- Category-appropriate properties, stated rather than measured.
- The generating seed makes every file reproducible.
- Reproducible fixtures make bug reports reproducible.
- 2
2. Use it to choose difficulty deliberately
Before downloading, read the sheet and decide what you are testing. If you want to establish a baseline, take the clean, ordinary fixture. If you want to find the edge, take the one whose sheet says it sits near the limit of what a tool should handle.
Testing blind — grabbing whatever is at the top of the list — produces results you cannot interpret, because you do not know whether the file was easy or hard.
- 3
3. Turn a failure into a property
When something fails, read the sheet and identify which stated property is likely responsible, then confirm by testing a fixture that differs only in that property. This is where the library earns its keep: the controlled comparison is one download away.
The output of that process is a claim with a boundary — "handles sRGB, fails on CMYK", "fine to 4096px, fails above" — which is what a maintainer needs to fix something.
- 4
4. Watch for encoding and colour-space traps
A large share of silent image bugs come from two properties on the sheet: colour space and alpha. A tool that assumes sRGB will shift a CMYK file's colours without erroring; one that ignores an alpha channel will produce black boxes or fringes without erroring either.
Both are the kind of failure that ships to production because nothing crashed. Reading those two lines on the sheet before testing turns them from mysteries into expectations.
- 5
5. Quote the sheet in your bug report
Paste the relevant properties and the seed into the report. A maintainer can then regenerate the exact fixture rather than working from an attachment that may have been re-encoded by an email client or a chat app on its way to them.
This is a small habit with a disproportionate effect on how quickly a report gets acted on.
- 6
6. Keep the sheet with the fixture in your test suite
When you add a fixture to a regression suite, record its properties alongside it. Six months later, the person debugging a newly failing test needs to know what that file was supposed to be, and the sheet is that answer.
A fixture without its spec is just a file, and a file with no stated properties is exactly the situation this library exists to get you out of.
Specified, not measured
Read the sheet before you download so you know whether a fixture is easy or hard. When something fails, find the property responsible and confirm it with a fixture that differs only in that. Quote the properties and the seed in bug reports — a maintainer can regenerate a byte-identical file from them.
Frequently asked questions
Quick answers to common questions about this topic.
What is on a spec sheet?
Category-appropriate properties — dimensions, colour space, bit depth, encoding, noise sigma, silence timestamps, sample rate, channel layout, form field inventory — plus the seed that generated the file.
Why does the seed matter?
Because it makes the file reproducible. Anyone with the seed and the generator gets a byte-identical fixture, so a bug report referencing it can be reproduced exactly rather than from an attachment.
Which properties cause the most silent bugs?
Colour space and alpha. A tool that assumes sRGB shifts CMYK colours without erroring, and one that ignores alpha produces black boxes or fringes without erroring — failures that ship because nothing crashed.
Should I keep the sheet with a regression fixture?
Yes. Six months later, whoever is debugging a newly failing test needs to know what the file was supposed to be. A fixture without its spec is just a file.