Open a library full of generative video and you learn something quickly: a grid of identical grey placeholders is not a library. It is a list of filenames wearing a costume.
AI output stopped being only images a while ago. Video models moved from novelty to production tool quickly, audio generation followed, and 3D is arriving on the same curve. Most asset tools have not caught up, because they were built on an assumption that is quietly load-bearing: that an asset is a picture, and a preview is a smaller copy of that picture.
That assumption breaks the moment a library holds more than one kind of thing.
A preview you cannot read is a findability failure disguised as a cosmetic one.
The Broken-Image Problem
When a catalogue does not understand a format, it does not usually fail loudly. It renders a broken image icon, or worse, tries to display an audio file as though it were a picture and shows you nothing at all. The asset is there. It is stored, it is safe, it is catalogued. It is also, in practical terms, invisible — because the only way to find it is to already know its name.
This is a findability failure disguised as a cosmetic one. Scanning is how people navigate a large library. Remove the ability to scan and you have forced every lookup through search, which only works when you can already describe what you are looking for.
What Changed
Numonic now generates real previews for the formats that were previously guesswork:
- Video gets true thumbnails and a first-frame poster, generated on the server rather than depending on whatever the browser manages to do. A video asset now looks like the video.
- 3D models get thumbnails on import, so a 3D asset is recognisable in a grid rather than a generic placeholder.
- Audio and video are no longer rendered as images. Each format gets presentation that suits it.
- Media-type icons appear on every card, so you can tell at a glance what kind of asset you are looking at even where the preview is ambiguous.
- Video arriving through the API is treated the same as video imported by hand. Assets ingested programmatically get the same previews as assets dragged in — which matters because automated pipelines are increasingly how assets arrive at all.
What each format gets now
| Preview | Also | |
|---|---|---|
| Video | Server-generated thumbnail and first-frame poster | Same treatment when it arrives through the API |
| 3D models | Thumbnail generated on import | Media-type icon on its card |
| Audio | Presented as audio, not a broken image | Media-type icon on its card |
The API point is worth dwelling on. A catalogue that behaves differently depending on how an asset arrived is a catalogue you cannot automate against with confidence. If the API path produces second-class assets, every pipeline eventually needs a human to tidy up after it, and the automation was never really automation.
Multi-Format Is the Normal Case Now
A production that mixes formats is no longer unusual. A single sequence might involve stills for look development, generated video for motion, an audio bed, and a 3D element — produced across four tools, by different people, over several weeks.
The organising problem that creates is not really about previews. It is that these assets are related, and the relationships are invisible unless something records them. Previews are the precondition: you cannot reason about a library you cannot see. But the reason to get this right is what it enables afterwards — treating a multi-format production as one body of work rather than four unrelated piles.
Key Takeaways
- Generative output is multi-format now; catalogues built for images alone silently hide everything else.
- Video assets get server-generated thumbnails and first-frame posters.
- 3D models get thumbnails at import; audio and video are no longer rendered as images.
- Media-type icons make format obvious at a glance.
- Assets ingested through the API get the same treatment as manual imports, so pipelines do not produce second-class assets.