MODEL IDtopazlabs:proteus@4
live

Topaz Labs Proteus 4

Topaz Labs
by Topaz Labs

Proteus 4 is Topaz Labs' general-purpose video enhancement model for upscaling and restoring a wide range of footage. It improves handling of noise, compression artifacts, faces, interlaced material, and scene transitions while maintaining stronger temporal consistency than earlier Proteus versions. Use it for broad video cleanup and enlargement workflows where the source does not call for a more specialized model.

Topaz Labs Proteus 4

Enhancing interlaced and tape-sourced footage

How to enhance interlaced footage with Topaz Proteus 4: matching settings.videoType to the source, when settings.fieldOrder matters, and what either one gets wrong.

Introduction

Interlaced footage stores two half-frames per frame, captured a moment apart. One holds the odd lines and one holds the even lines, and on anything that moves between those two moments the lines disagree. The result is the horizontal comb teeth along moving edges that anyone who has digitised a tape library has seen.

Proteus is the model in the catalog that knows what to do with those fields, which is why archival and broadcast material lands here. It needs to be told, though. settings.videoType is how you say what the source is, and getting it wrong turns comb teeth into sharpened comb teeth.

Tape sourceDeinterlaced and enhanced

The reception clip is a digitised tape, combing hard on the dancers and the guests behind them. Declared as interlaced, the model weaves the fields back into whole frames before it enhances anything, so the edges come back solid rather than striped.

Telling the model what the source is

settings.videoType takes progressive, interlaced, and progressiveInterlaced. It is the first thing to set on any tape-sourced clip, because every later repair is applied to whatever frames this setting produces.

The interlaced source
videoType: progressive, the wrong call
videoType: interlaced

Comb teeth are a few pixels tall, so at page width they read as a vague softness rather than as stripes. At 100% the three takes separate cleanly:

In the source, every moving edge is cut into horizontal bands, worst on the two players and the crowd behind them. Declared progressive, the model never recognises those bands as fields, so it works around them: the stripes turn into ghosting and smear that trails each player, cleaner than the source but soft and dirty. Declared interlaced, the fields are recombined before anything else happens and both players come back solid. Fast lateral movement is where the gap is widest, because that is where the two fields disagree most.

Field order

Fields have a temporal order, and settings.fieldOrder is where you name it. topFirst means the field holding the upper lines was captured first, bottomFirst means the lower lines came first, and auto asks the model to work it out.

The football clip is top field first. Run it once with the order named correctly and once with it reversed:

The interlaced source, top field first
fieldOrder: topFirst, matching the source
fieldOrder: bottomFirst, reversed

Reversing the order does not bring the comb teeth back. Both takes are cleanly deinterlaced, and what changes is when each frame lands: the fields are woven in the opposite temporal sequence, so the action plays out on a different schedule from the one the camera recorded. Step through the two and the players sit at different points in the same stride.

When field order cannot matter

The conference recording tells the other half of the story. It is a locked-off wide shot, and running it with the right order and the wrong one returned pixel-identical files.

SourceEnhanced

The reason is physical rather than a quirk of the model. Field order only means something when the subject moved between the two fields. On a static shot the two fields hold nearly the same picture, so weaving them in either sequence produces the same frame, and the setting has nothing to act on. The deinterlace and the enhancement still do their work, as the comparison above shows.

That is also why auto is the sensible default. Detection has plenty to work with exactly when the setting matters, and when detection would be hardest, on a shot with no motion, the answer no longer changes the result.

fieldOrder only applies to an interlaced source, and the API enforces it. Sending it with videoType set to progressive, or with no videoType at all, fails validation. Set videoType to interlaced or progressiveInterlaced in the same settings object.

import { createClient } from '@runware/sdk'

const client = await createClient({ apiKey: process.env.RUNWARE_API_KEY })
await client.connect()

const [result] = await client.run({
  model: 'topazlabs:proteus@4',
  deliveryMethod: 'async',
  width: 1440,
  height: 1080,
  inputs: {
    video: 'https://vm.runware.ai/video/os/a14d18/ws/2/vi/8192a3b4-c5d6-4e7f-a819-2a3b4c5d6e7f.mp4'
  },
  settings: {
    videoType: 'interlaced',
    fieldOrder: 'auto',
    enhancement: {
      mode: 'relative',
      compression: 0.4
    }
  }
})
import asyncio
import os

from runware import Runware


async def main():
    async with Runware(api_key=os.environ["RUNWARE_API_KEY"]) as client:
        results = await client.run({
            "model": "topazlabs:proteus@4",
            "deliveryMethod": "async",
            "width": 1440,
            "height": 1080,
            "inputs": {
                "video": "https://vm.runware.ai/video/os/a14d18/ws/2/vi/8192a3b4-c5d6-4e7f-a819-2a3b4c5d6e7f.mp4"
            },
            "settings": {
                "videoType": "interlaced",
                "fieldOrder": "auto",
                "enhancement": {
                    "mode": "relative",
                    "compression": 0.4
                }
            }
        })


asyncio.run(main())
curl https://api.runware.ai/v1 \
  -H "Authorization: Bearer $RUNWARE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '[
    {
      "taskType": "upscale",
      "taskUUID": "b9c0d1e2-3f4a-4b5c-c6d7-e8f9a0b1c2d3",
      "model": "topazlabs:proteus@4",
      "deliveryMethod": "async",
      "width": 1440,
      "height": 1080,
      "inputs": {
        "video": "https://vm.runware.ai/video/os/a14d18/ws/2/vi/8192a3b4-c5d6-4e7f-a819-2a3b4c5d6e7f.mp4"
      },
      "settings": {
        "videoType": "interlaced",
        "fieldOrder": "auto",
        "enhancement": {
          "mode": "relative",
          "compression": 0.4
        }
      }
    }
  ]'
runware run topazlabs:proteus@4 \
  deliveryMethod=async \
  width=1440 \
  height=1080 \
  inputs.video=https://vm.runware.ai/video/os/a14d18/ws/2/vi/8192a3b4-c5d6-4e7f-a819-2a3b4c5d6e7f.mp4 \
  settings.videoType=interlaced \
  settings.fieldOrder=auto \
  settings.enhancement.mode=relative \
  settings.enhancement.compression=0.4
{
  "taskType": "upscale",
  "taskUUID": "b9c0d1e2-3f4a-4b5c-c6d7-e8f9a0b1c2d3",
  "model": "topazlabs:proteus@4",
  "deliveryMethod": "async",
  "width": 1440,
  "height": 1080,
  "inputs": {
    "video": "https://vm.runware.ai/video/os/a14d18/ws/2/vi/8192a3b4-c5d6-4e7f-a819-2a3b4c5d6e7f.mp4"
  },
  "settings": {
    "videoType": "interlaced",
    "fieldOrder": "auto",
    "enhancement": {
      "mode": "relative",
      "compression": 0.4
    }
  }
}
Response
[
  {
    "taskType": "upscale",
    "taskUUID": "b9c0d1e2-3f4a-4b5c-c6d7-e8f9a0b1c2d3",
    "videoUUID": "5f607182-93a4-4b5c-d6e7-f8091a2b3c4d",
    "videoURL": "https://vm.runware.ai/video/os/a14d18/ws/2/vi/5f607182-93a4-4b5c-d6e7-f8091a2b3c4d.mp4"
  }
]

Tape-sourced material is usually 4:3, so the envelope above is 1440 × 1080 rather than 16:9. The aspect ratio of the source is preserved either way, as covered in upscaling and enhancing video.

Declaring interlaced when it is not

The mistake also runs the other way, and that direction is the one that gets made in batches. A folder of digitised material usually holds some progressive files, and sending the whole folder through with videoType set to interlaced treats those clips as something they are not.

A progressive source
videoType: progressive, correct
videoType: interlaced, the wrong call

A deinterlacer applied to progressive frames splits whole lines into fields that were never separate, then recombines them. What comes back is softer than what went in, and no repair weight downstream gets that resolution back. Check the source rather than assuming, since a batch is rarely uniform.

Mixed sources

progressiveInterlaced is for a clip that changes cadence partway through, which is common in digitised material assembled from several originals: a progressive title card cut against interlaced camera footage, or a tape that captured broadcast content of mixed origin. It tells the model to expect both rather than committing to one.

Split the clip when you can. A source that is genuinely half one and half the other gets a better result from two passes with the right setting on each than from one pass hedging across the join.

Tips

  1. Check the source before you batch. Step through a moving section frame by frame. Comb teeth on motion mean interlaced, clean edges mean progressive, and a folder of digitised material often holds both.

  2. Never leave videoType at progressive for tape. It is the one setting that makes the result worse than the input, because the enhancement sharpens the comb teeth into the picture.

  3. Leave fieldOrder on auto. It has something to detect exactly when the setting matters, on footage with motion, and on a static shot the order changes nothing anyway. Name it explicitly only when you know the format for certain, since DV tapes are usually bottom field first while HD broadcast formats are usually top first.

  4. Read the symptom to find the setting. Comb teeth in the result mean the wrong videoType. A clean result whose motion does not match the source's timing means the wrong fieldOrder.

  5. Deinterlace before you tune anything else. Compression and noise weights land on the frames this setting produces, so a wrong call here makes every later weight work on the wrong picture.

  6. Keep the 4:3 aspect. Tape-sourced material is usually 4:3, and the envelope preserves whatever the source has. Ask for 1440 × 1080 rather than a 16:9 box that the result will never fill.