--- title: Enhancing interlaced and tape-sourced footage — Topaz Labs Proteus 4 | Runware Docs url: https://runware.ai/docs/models/topazlabs-proteus-4/guides/interlaced-sources description: "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](https://runware.ai/docs/models/topazlabs-proteus-4/guides/interlaced-sources#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 source**: [Watch video](https://runware.ai/docs/assets/source-wedding.DCNCUzyD.mp4) **Deinterlaced and enhanced**: [Watch video](https://runware.ai/docs/assets/output-wedding.CFbx2jIM.mp4) 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](https://runware.ai/docs/models/topazlabs-proteus-4/guides/interlaced-sources#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. **Source**: [Watch video](https://runware.ai/docs/assets/source-football.CkZ8WXyO.mp4) *The interlaced source* **Declared progressive**: [Watch video](https://runware.ai/docs/assets/output-football-progressive.CUi-omhx.mp4) *videoType: progressive, the wrong call* **Declared interlaced**: [Watch video](https://runware.ai/docs/assets/output-football-interlaced.BYMfZ7zQ.mp4) *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: ![A close-up crop of two football players mid-stride, every moving edge cut into horizontal stripes](https://runware.ai/docs/assets/crop-source-football.DWhJcgh__Z1cdiXa.jpg) *Source · 100% crop* ![The same crop declared progressive, the stripes replaced by smeared ghosting along the players](https://runware.ai/docs/assets/crop-progressive-football.Cz9eI06__ZAvh2P.jpg) *videoType: progressive* ![The same crop declared interlaced, both players solid and sharp with no striping](https://runware.ai/docs/assets/crop-interlaced-football.Dz2yXQ6j_Z2ergvm.jpg) *videoType: interlaced* 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](https://runware.ai/docs/models/topazlabs-proteus-4/guides/interlaced-sources#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: **Source**: [Watch video](https://runware.ai/docs/assets/source-football.CkZ8WXyO.mp4) *The interlaced source, top field first* **topFirst**: [Watch video](https://runware.ai/docs/assets/output-football-interlaced.BYMfZ7zQ.mp4) *fieldOrder: topFirst, matching the source* **bottomFirst**: [Watch video](https://runware.ai/docs/assets/output-football-bottomfirst.DT6gZXpm.mp4) *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](https://runware.ai/docs/models/topazlabs-proteus-4/guides/interlaced-sources#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**. **Source**: [Watch video](https://runware.ai/docs/assets/source-conference.4RFUJkxP.mp4) **Enhanced**: [Watch video](https://runware.ai/docs/assets/output-conference-auto.BOvYcawG.mp4) 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. > [!WARNING] > `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. **TypeScript**: ```typescript 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 } } }) ``` **Python**: ```python 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**: ```bash 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 } } } ]' ``` **CLI**: ```bash 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 ``` **JSON**: ```json { "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**: ```json [ { "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](https://runware.ai/docs/models/topazlabs-proteus-4/guides/upscaling-video). ### [Declaring interlaced when it is not](https://runware.ai/docs/models/topazlabs-proteus-4/guides/interlaced-sources#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. **Source**: [Watch video](https://runware.ai/docs/assets/source-training.CDtsOwSH.mp4) *A progressive source* **Declared progressive**: [Watch video](https://runware.ai/docs/assets/output-training-progressive.CNtS5Rjd.mp4) *videoType: progressive, correct* **Declared interlaced**: [Watch video](https://runware.ai/docs/assets/output-training-interlaced.Dw1rjbod.mp4) *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](https://runware.ai/docs/models/topazlabs-proteus-4/guides/interlaced-sources#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](https://runware.ai/docs/models/topazlabs-proteus-4/guides/interlaced-sources#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.