Building a Browser-Based Bitmap Subtitle Encoder

Bitmap subtitles are one of the last holdouts of the desktop-only post-production workflow. While text-based subtitle formats have been editable in web browsers for years, bitmap subtitles — pre-rendered images used in DVD, Blu-ray, and broadcast delivery — have remained locked behind expensive desktop software.

That changes now. The subtitle tool at timecode.dev can render subtitle text to bitmap images — PNG by default, or palette-indexed TIF for Scenarist compatibility — generate both STL and SST manifests, and bundle everything into a ZIP archive — entirely in the browser. No plugins. No server-side processing. No desktop software required.

What Are Bitmap Subtitles?

Most subtitle formats deliver text. The playback device — a media player, a web browser, a set-top box — receives the text and renders it using whatever font engine and styling capabilities it has. The result looks different on every device.

Bitmap subtitles are different. Instead of delivering text for the device to render, you deliver pre-rendered images. Each subtitle event is a separate image file showing exactly what the viewer should see. The playback device just composites the image onto the video frame at the specified time. No font engine. No styling interpretation. Pixel-perfect, device-independent rendering.

Where bitmap subtitles are used

In all of these, the subtitle stream contains images, not text. The images are typically palette-indexed bitmaps with a small number of colors (2-4 for subtitles), which keeps file sizes manageable while allowing transparency and anti-aliasing.

Why they exist

Bitmap subtitles solve three problems that text-based formats cannot:

1. Rendering consistency. A text subtitle rendered in Arial on Windows looks different from the same text in Arial on macOS, which looks different again on a Linux media player. A bitmap looks identical everywhere because the rendering already happened.
2. Font independence. Text subtitles require the playback device to have the specified font installed. If it does not, the device substitutes a fallback, often with different metrics. Bitmap subtitles have no font dependency — the font was used during rendering and is baked into the image.
3. Transmission constraints. DVD and Blu-ray subtitle streams are defined as image overlays in their respective specifications. These formats do not have a text rendering engine in the player specification. The disc standard requires bitmaps.

The Traditional Workflow

Before browser-based encoding, creating bitmap subtitles required a chain of specialized desktop tools:

1. Author subtitles in a text-based format (SRT, STL, or the tool's native format)
2. Import into Scenarist (or EZTitles, Subtitle Edit Pro, or similar) — an application that costs hundreds to thousands of dollars per license
3. Configure rendering — font, size, color, positioning, anti-aliasing, palette mapping
4. Render to images — the application generates one image per subtitle event, plus manifests
5. QC the output — verify every image renders correctly, timing is accurate, palette is correct
6. Package for delivery — organize files per the disc authoring or broadcast delivery spec

This workflow is manual, slow, and requires specialized software that runs only on Windows (in most cases). A typical feature film might have 1,500-2,000 subtitle events, each rendered as a separate image. The rendering step alone can take minutes on desktop hardware.

What timecode.dev Does Differently

The subtitle tool replaces steps 2 through 6 with a single browser-based operation. Upload any supported subtitle format, configure the rendering parameters, and export as Graphics STL. The output is a ZIP archive containing everything needed for Scenarist import.

The rendering pipeline

1. Parse input. The source subtitle file is parsed with framerate context. Every timestamp is immediately converted to a frame number via the timecodes engine. The internal representation is an array of SubtitleEntry objects with startFrame and endFrame — integers, not milliseconds.
2. Render to Canvas. Each subtitle's text is rendered to an HTML Canvas element at the target resolution (default 1920x1080). The rendering applies the configured font, size, color, outline width, and positioning. Text is centered horizontally and positioned in the lower 10% of the frame, matching standard subtitle placement.
3. Quantize to palette. The RGBA canvas output is converted to a 4-color palette-indexed format matching the Scenarist convention:

   Index	Color	Role
   0	White	Background (remapped by SST Color/Contrast)
   1	Black	Outline
   2	Blue	Anti-alias
   3	Red	Text body

   
   The quantization uses luminance thresholds on the rendered RGBA data. Pixels with alpha below 10% map to background (index 0). Remaining pixels are classified by effective luminance: high luminance maps to text body (index 3), medium to anti-alias (index 2), low to outline (index 1).
   These palette colors are not the final on-screen colors. They are index markers. The SST manifest's Color and Contrast directives tell Scenarist how to remap these indices to the desired display colors and transparency levels during disc authoring.
4. Encode to TIFF. The palette-indexed data is written as an 8-bit uncompressed TIFF file, assembled byte-by-byte using ArrayBuffer and DataView. The TIFF includes:
   • Standard header (little-endian, magic number 42)
   • 19 IFD tags in ascending order per TIFF specification
   • 256-entry color map (the 4-color Scenarist palette, zero-padded to 256)
   • 72 DPI resolution (XResolution, YResolution as RATIONAL values)
   • PageNumber tag (page 0 of 1)
   • Image data as raw palette indices (1 byte per pixel)
5. Generate manifests. Two manifest files are produced:
   STL manifest — Lists timecode in/out pairs with image filenames and global Color/Contrast directives. Uses SMPTE timecodes derived from frame numbers, with correct drop-frame handling for 29.97fps content.
   SST manifest — Scenarist-format file with full metadata: TV type (NTSC/PAL), tape type (DROP/NON_DROP), pixel area, display area, and per-subtitle timecode/filename mappings. This file can be directly imported into Scenarist.
6. Bundle as ZIP. All files — STL manifest, SST manifest, and individual image files — are compressed into a single ZIP archive using DEFLATE compression. The archive is generated client-side using JSZip and downloaded directly to the user's machine.

What this means in practice

A 1,500-subtitle feature film that previously required Scenarist and 10-15 minutes of rendering time can now be processed in under a minute in a modern browser. The output is byte-compatible with Scenarist's expected input format. The timing is frame-accurate because it was never stored as milliseconds.

Technical Details for the Curious

Why 8-bit uncompressed TIFF?

Scenarist expects palette-indexed TIFF files. While the TIFF specification supports numerous compression schemes (LZW, PackBits, DEFLATE), Scenarist's import pipeline is most reliable with uncompressed (Compression = 1) 8-bit palette-indexed images. Using uncompressed data also means the TIFF encoder is simple — no compression algorithm to implement, just raw pixel bytes preceded by the IFD structure.

Why 72 DPI?

The DPI value in a TIFF file is metadata — it does not affect the pixel data. Scenarist uses the pixel dimensions, not DPI, for positioning. 72 DPI is the conventional value used by existing Scenarist-compatible tools, and matching it ensures the output passes any DPI validation checks in the import pipeline.

Why the specific palette convention?

The 4-color palette (white/black/blue/red mapped to background/outline/anti-alias/text) is a Scenarist convention, not a formal standard. These colors are arbitrary markers — the SST manifest's Color and Contrast directives define how Scenarist remaps them during disc compilation. By matching the established convention, the output works with existing Scenarist project templates without requiring palette reconfiguration.

Canvas rendering limitations

The HTML Canvas API's text rendering is font-dependent on the host system. If the configured font is not available on the user's machine, the browser will substitute a fallback. For production use, verify that the intended font is installed before rendering. Web fonts loaded via CSS @font-face are accessible to Canvas after they finish loading.

What Comes Next

Graphics STL with PNG (default) and TIF output covers the Scenarist/broadcast use case. But the same architecture — frame-canonical timing, Canvas rendering, binary encoding — applies to other bitmap subtitle formats:

PGS (Presentation Graphics Stream) — The Blu-ray subtitle format. PGS uses RLE-compressed bitmap segments with a defined composition structure. The Canvas rendering pipeline already produces the source images; what remains is implementing the PGS segment encoding (Palette Definition, Object Definition, Window Definition, Composition) and RLE compression. This is feasible in browser TypeScript.

VOBSUB (DVD) — DVD subtitle streams use run-length encoded 4-color bitmaps in a container derived from MPEG-2 Program Stream. The palette-indexed TIFF output is already in the right color model; the additional work is RLE encoding per the DVD specification and wrapping in the SUB/IDX container format.

Both formats are implementable with the same client-side architecture — no server, no native code, no desktop application. The encoder runs where the browser runs.

Try It

The Graphics STL export is available now in the subtitle tool. Upload any supported subtitle format, select Graphics STL as the output format, configure your rendering parameters (resolution, font, colors), and download the ZIP bundle. The output includes both STL and SST manifests, ready for Scenarist import.

For teams currently licensing desktop software to produce bitmap subtitles: run a comparison. Render the same subtitle file through your existing tool and through timecode.dev. Compare the TIFF output byte-for-byte. Compare the manifest timing against your known program timecodes. The browser-based output holds up.

This is not a toy. It is a production tool that eliminates a significant cost and workflow bottleneck from bitmap subtitle delivery.