Runway ACEScg EXR: what the September 12 plate-referenced change did

On September 12 Runway changed its ACEScg EXR outputs so that the sequence is built from the source plate, run through an inverse ACES SDR transform with recovered highlights, and records construction: plate-referenced in its colorimetry sidecar. Gen-4.5 ACEScg outputs were not changed. Sume returns MP4 only, so none of this applies to a Sume job's own output.

Everything about Runway below is from its API changelog and pricing page, read 2026-10-03. The Sume statements come from the video generation docs.

Which output ids are involved?

The August 31 entry introduced two deliveries on /v1/video_to_hdr and on Gen-4.5 HDR generations: hdr_exr_acescg_sequence_1_3 and hdr_exr_acescg_sequence_2_0. They are scene-referred ACEScg OpenEXR sequences in the ACES 1.3 and ACES 2.0 variants, each with a matching Output Transform. The zip also holds colorimetry and provenance sidecars, plus an audio.wav when the source has audio.

They bill like every other HDR profile: 20 credits per second, or 40 for sources above 4 megapixels.

What did September 12 change?

Before the change, the sequence was built another way; after it, Runway says the ACEScg output is constructed from the source plate. The practical consequence is that the SDR view of the result should track the plate more closely, while the HDR behavior is kept. The entry also notes the plate-referenced construction is recorded in the colorimetry sidecar, which is how you can tell which build a given delivery used.

That sidecar field is worth checking in a pipeline. If you re-delivered a shot before September 12 and again after, a diff of the sidecar tells you whether the two sequences came from different constructions.

Where does a Sume clip fit in?

A Sume video job ends at an MP4 you fetch from GET /v1/videos/{jobId}/content. The docs list no HDR, EXR or ACEScg option on any model, so a Sume result is an SDR plate. That is exactly what Ruby wants as input, and the plate-referenced build is described as taking its cue from the plate you supply.

The route is therefore generate on Sume, then send the MP4 to Ruby for an ACEScg delivery. Keep the source MP4 untouched in your records, since the sidecar's provenance refers to it.

What should you check before relying on it?

Runway's changelog does not publish a before-and-after comparison image, so this post makes no claim about how large the visual difference is.

• Whether your colorist needs ACES 1.3 or 2.0, since the ids differ.
• The sidecar's construction value on each delivery, for repeat shots.
• That the source is SDR and under 4096 pixels per side, per Ruby's input limits.
• That you are not expecting Sume to produce EXR: it does not.

What does this cost per shot?

Using the pricing page's 20 credits per second, a 10-second 1080p shot delivered as an ACEScg EXR sequence is 200 credits, or $2.00 at $0.01 per credit. The same shot at 3840 by 2160 is above 4 megapixels, so it bills 40 credits per second: 400 credits, or $4.00. A 30-second 4K shot reaches 1,200 credits, or $12.00.

These are Runway's rates for the conversion only. They do not include generating the clip. If you generate on Sume, that part is billed separately at list price times 1.25 against your workspace balance, and the two invoices never merge.

Re-delivering a shot after the September 12 change is a new conversion and is billed again; the changelog does not mention any credit for re-runs, so budget for it if a client asks for a revised grade.