On August 21 Runway shipped Ruby — a model that generates nothing at all. It takes a finished SDR clip and redistributes its brightness into HDR: the source pixels and the audio are preserved, nothing is repainted, luma and colour are simply extended into the HDR range. The input can be a file you upload or the output of any other Runway model. Access is on the Max and Enterprise plans, plus a dedicated API endpoint.
There was no public beta: the model landed in the product and in the API at the same time. Runway founder Cristóbal Valenzuela called it one of the most requested features in nearly eight years of building the company — and that part is hard to argue with, because the demand for a proper HDR output has been piling up among everyone who hands AI video to a real edit rather than to a story feed. The phrasing "converts SDR video up to 16-bit HDR", on the other hand, sounds rather more impressive than what actually happens.
What Ruby actually does
The API documentation is more honest than the press release: the output "keeps the source's own pixels — luma and color are extended into the HDR range, nothing is re-synthesized". So this is not a generative repaint of the frame but a very careful neural inverse tone mapping: the model reads the luminance structure of the shot and unrolls 8-bit SDR into the HDR headroom while trying not to drift in colour.
The distinction matters. A generative upscaler invents detail, and it can invent it wrong — a face slides, a texture turns plastic. Ruby is not supposed to touch frame content at all, so its failures are of a different kind: not "drew the wrong thing" but "misjudged where this region should land in brightness".
The 16 bits that aren't those 16 bits
This is where it's worth slowing down. The "up to 16-bit HDR" in the announcement refers first of all to the EXR output, and Runway's EXR is half-float: a 16-bit floating point value per channel, not 65,536 evenly spaced integer levels.
Float16 is one sign bit, five exponent bits and ten mantissa bits. It covers an enormous luminance range with roughly constant relative precision at any signal level, which is exactly why it is the right format for compositing and grading. But "16 bits" here describes how the number is represented, not how much measured information it holds.
And the source holds exactly as much information as 8-bit SDR ever had. Everything in the HDR output beyond that was constructed by the model. Ruby does not bring back blown highlights: if the sky in the source clipped to 255 and went flat white, no inverse tone mapping knows whether there was a cloud or the sun behind it. It only knows how to lift that region plausibly.
Which leaves the one practical question worth asking: how plausibly.
Four output formats
Ruby delivers four profiles, and between them they cover very different ends of the pipeline:
hdr_exr_sequence— a zip of half-float OpenEXR frames. Inside is linear BT.2020 in display light on a "1.0 = 100 nits" scale, alongsidecolorimetry.jsonandprovenance.jsonsidecars (the latter explicitly declares the file an upconvert), plusaudio.wavwhen the source had sound. This is the option for Nuke, Fusion and Resolve, where you do the mastering yourself.hdr_prores— a ProRes .mov, BT.2020 + PQ, with a selectable tier:422,422 HQ(the default) or4444. A classic editorial mezzanine that any NLE will take without argument.hdr10— HEVC Main 10, BT.2020 + PQ, .mp4. The default profile and a near-ready delivery file for an HDR television or YouTube.hlg— the same HEVC Main 10, but on an HLG curve. This one is for broadcast, where backwards compatibility with an SDR receiver is the point.
provenance.json, which marks the file as an upconvert, is a small thing but the right one: six months later nobody remembers where an HDR master came from, and the metadata does.
And here is the documentation wrinkle promised earlier. The announcement talks about "10 and 12-bit ProRes and HEVC", but in the API schema both HEVC profiles are Main 10 — strictly 10 bits. Twelve bits live in exactly one place in this set: ProRes 4444. So "12-bit" is the ceiling of one specific export profile, not a property of the model.
The strength of the release is right here, though: Ruby hands you not just an "EXR for the technical people" but practical master and delivery formats straight away. A generative video model's output usually stops at an 8-bit mp4, and everything after that is your problem.
Limits and cost
Per the API schema the input is an SDR clip no longer than 30 seconds, the same limit that appeared in the interface announcement. There is no resolution cap in the endpoint schema: the upconvert is delivered at the source's own resolution — but the billing does depend on frame size.
Ruby costs 20 credits per second of output, rising to 40 credits per second when the source is larger than 4 megapixels (roughly 4K). A credit in the developer portal is $0.01, so a 30-second clip runs $6, and the same clip in 4K runs $12.
The number gets more interesting in comparison. A second of video generation in Gen-4.5 costs 12 credits, in Aleph 2 — 28. Which means converting a finished clip to HDR costs more than generating it: 20 against 12. Formally that makes sense — every frame has to be processed at source resolution rather than at model resolution. But it inverts the familiar hierarchy of "generation is expensive, post is cheap", and across a series of clips that multiplier shows up in the budget.
The usual API input limits apply: 32 MB for a file by URL, 16 MB for a data URI and 200 MB for an upload through Runway.
The first reactions are impressions, not data
A substantive negative report has already appeared: one user writes that the EXR they got still shows visible banding, and that the shadows and highlights don't gain the volume of information they expected — to them it looks more like a good range expansion than a reconstruction of 16-bit material.
If that holds up, the conclusion is interesting. Banding in a half-float EXR cannot be a quantisation artefact of the container itself — float16 has precision to spare. So the bands are arriving from the source: those are the original 8-bit steps stretched across a wider range. The scale was pulled apart; the gaps between levels were not filled in.
To be clear: that is one report plus my own reasoning about its mechanics, not a test result. Nobody has published a proper A/B yet. On Reddit the Ruby discussion is only starting, and people there are mostly asking the same thing — has anyone compared it to Topaz.
What this changes
Ruby does have a direct competitor: Topaz Hyperion 2.5, which does the same job — inverse tone mapping from Rec.709 to BT.2100 PQ, with 10-bit ProRes and 16-bit float EXR on the way out. Topaz says in plain text that it "generates nothing and adds no resolution", and sells by subscription from $9 a month.
The difference is not the task but where it sits. Topaz is a desktop utility at the end of the pipeline: generate somewhere, download, run it through. Ruby lives inside Runway, takes a generation result directly and is invoked with a single API call. For a studio assembling a conveyor, that changes not the picture quality but the number of steps and people between generation and master.
The second shift is easier to miss. Until now AI video lived in 8 bits and was treated by default as web content. A native output in ProRes 4444 and EXR changes the conversation with an editor: this is no longer "an AI clip" but a source file in a format any professional pipeline accepts. You still have to judge the quality with your eyes on a reference monitor — but before, there was nothing to judge.
Incidentally, you cannot check any of this from someone else's publication: the blog page you're reading is served in SDR, and any "HDR example" here turns back into a tone-mapped picture. Ruby is only worth evaluating on your own footage and your own display.
Where to try Runway
Ruby is not in the GPTunneL catalogue yet. But we think the task is the right one: we plan to add SDR → HDR as a dedicated step in workflow — where the clip is already being generated on the canvas, HDR conversion naturally belongs in the next block, without exporting the file to an outside utility.
What's available from Runway right now:
- Runway 4.5 — the current generation model, $0.26 per second of video;
- Runway Aleph 2 — editing finished video, $0.50 per second;
- Runway Act-Two — transferring an actor's performance onto a character, $0.10 per second.
No subscription needed, you pay for seconds of finished video; the exact figure for your duration is in the calculator on the pricing page.
FAQ about Runway Ruby
Does Ruby generate video? No. It is a grading model: it takes a finished SDR clip and expands its dynamic range into HDR while preserving the source pixels and the audio.
What is the maximum clip length? 30 seconds per the API schema. Resolution is not capped — the output is delivered at the source's resolution — but above 4 megapixels the rate doubles.
Is the output really 16-bit? In EXR, yes, but it is half-float: a 16-bit floating point value per channel, not 65,536 integer levels. And the information in those bits was constructed by the model, not measured by a camera.
How does Ruby differ from Topaz Hyperion? Same task — inverse tone mapping. The difference is placement: Topaz is a desktop app on a subscription, Ruby is an API endpoint inside Runway that takes a generation result without exporting a file.
Is Ruby available in GPTunneL? Not yet: at launch the model is open only on Runway's Max and Enterprise plans. We plan to add the SDR → HDR step to workflow, while generation in Runway 4.5 and editing in Aleph 2 are in the lab today.
Ruby should be measured not by the word "16-bit" in the announcement but by the fact that it removes a manual grade at the exit from generation. Don't expect blown highlights back; do expect an honest A/B against Topaz, and sooner or later it will show up.
New models go live here the day their API opens. Follow the blog.