Output

One renderer for the preview and the file.

The worst moment in video editing is the one where the export does not look like the preview. In Lumae the player and the exporter drive the same compositor over the same composition, so the question cannot arise: the format is the only thing that differs.

Video: H.264, HEVC, ProRes 422 LT/422/HQ/4444
Containers: MP4, MOV, GIF
Quality: bits per pixel per frame
H.264 high: about 9.3 Mbps at 1080p30
GIF palette: one median-cut, whole clip
Audio: AAC, or LPCM with ProRes

Codecs, and one quality choice

H.264 and HEVC in MP4 or MOV, ProRes in four flavours (422 LT, 422, 422 HQ and 4444) in MOV, and GIF. Invalid pairings cannot be constructed: ProRes only exists in MOV, GIF only in GIF.

Quality for the lossy codecs is expressed in bits per pixel per frame rather than a raw bit rate, so one choice means the same look at 720p and at 4K. High is about 9.3 Mbps at 1080p30; HEVC asks for roughly a third less for the same setting. ProRes takes no bit rate at all, because choosing the flavour is the whole choice, and carries LPCM audio as editors expect.

GIF, quantised against the whole clip

GIF is not a codec AVFoundation writes, so Lumae walks the same frames and encodes them itself, in two passes. The first composites and spools frames to disk, sampling pixels as it goes; then one palette is computed for the whole clip and shared by every frame, because per-frame palettes make flat areas shimmer.

The sample budget is divided between the frames that will actually be captured, not spent on whichever arrive first. That matters more than it sounds: a demo that starts dark and ends light was otherwise quantised entirely against its opening seconds. Frame rate and output size are the levers that reliably shrink a GIF; a smaller palette does not, while dithering is on, because the dither pattern is noise that will not compress.

Size estimates that say what they mean

The Export sheet makes two different claims and words them differently. For H.264 and HEVC it says up to, because the bit rate is a request and the encoder is free to undershoot it, which on simple screen content it does by a lot. For ProRes it says about, because ProRes is constant-quality and intra-frame, so its size tracks raster times frame rate closely enough to predict.

GIF gets no estimate at all. How well a palette compresses is not predictable, and a number that is confidently wrong is worse than no number.

The sheet asks the question twice

Seven codecs in one popup was unreadable. The Export sheet asks for a family first (H.264, HEVC, ProRes, GIF) and then, only for ProRes, a flavour. Every picker is segmented, each button carries its name with the consequence in the caption below it, and the estimate sits in a footer away from the controls.

Output size is the canvas or a smaller standard long edge, always even, with the aspect preserved.

Questions

Why does my export look different from the preview?

It should not. Both run through the same compositor over the same composition, and the export simply uses a larger motion blur sample budget. If you see a difference, it is a bug worth reporting.

How do I make a GIF smaller?

Lower the frame rate or the output size. Shrinking the palette does not help much while dithering is on, because the dither pattern is high-frequency noise that LZW cannot compress, and it drops small coloured accents.

Can an agent export for me?

Yes. export_project is one of the tools Lumae's MCP server exposes, and a long export no longer blocks every other call while it runs.

All features