The Log Plate, the 8-Bit Alpha and the Magenta Fringe
You are roto lead on a 72-frame shot, 2048×858, delivered as log-encoded ProRes 4444. The comp department works in linear half-float EXR. A junior artist exports the finished alpha as an 8-bit premultiplied PNG sequence named shot3020_roto_v01.####.png. In the artist's player, which applies a Rec.709 viewing LUT, the matte looks clean. In Nuke, the comp artist reports a bright magenta fringe around the character's shoulders and visible banding in the soft hair edge. The comp artist says, 'Your roto is bad; redo it.' The shot is due in four hours. The character was shot against a blue screen, and the original plate has fine grain. The delivery spec says: straight alpha, 16-bit, 8-frame handles, linear. You have the original ProRes and a Nuke script. What do you check first?
1. Diagnose the likely causes in the correct order. Explain why you would not start by rebuilding the roto.
Read the worked answer
First I would inspect the alpha channel alone. If the silhouette is correct, the problem is delivery, not roto, so rebuilding splines would waste the four hours. Then I would check, in order: whether the PNG was written from a log plate without linearisation and then read as linear or sRGB in Nuke; 8-bit quantisation in the soft edge; premultiplication mismatch, because a premultiplied PNG that Nuke unpremultiplies, or the reverse, produces bright or dark edge fringing; and whether the viewing LUT was baked into the export. Magenta at a blue-screen edge is a strong hint of channel and alpha math at the boundary rather than a bad spline. I would ask the comp artist for the Read node colourspace and whether they are unpremultiplying. I would compare one frame over black, white and 50% grey. Then I would re-export a single test frame as 16-bit half-float EXR, straight alpha, linear, with 8-frame handles and no LUT. That isolates the cause before any re-roto.
2. Specify the correct export settings and a verification step you would complete before sending all 72 frames.
Read the worked answer
I would linearise the source first, then export a 16-bit half-float EXR sequence with straight alpha, no viewing LUT, full frame, and 8-frame handles. I would keep the alpha in its own channel and preserve the full float range, avoiding any compression or 8-bit conversion. The naming would follow the delivery spec, not the artist's local convention. Before sending all 72 frames, I would verify one frame in Nuke: set the Read node to linear, view the alpha over a checkerboard and over black, white and 50% grey, check the min/max values, and confirm that unpremultiplying or premultiplying does not change the edge. I would also confirm the frame range and handles against the spec. I would send the test frame plus a short text note listing the settings, then wait for the comp artist to confirm before rendering the full sequence. This turns a vague 'bad roto' complaint into a testable delivery issue.
3. How would you communicate with the comp artist so the issue is resolved without damaging the working relationship?
Read the worked answer
I would lead with the evidence, not blame: 'The splines look correct on the alpha; the fringe appears when the PNG is read in linear. Can you confirm your Read colourspace and whether you are unpremultiplying?' I would attach the alpha alone, the RGB with the fringe, and a corrected test frame as EXR. I would explain what I changed and ask them to test the EXR in their comp. If the corrected frame works, we agree on the cause and I re-export the rest. If it does not, I would ask for their node settings and compare. I would avoid saying 'you set it up wrong' and avoid accepting 'my roto is bad' without evidence. I would also inform the production coordinator of the revised ETA if the re-export affects delivery. The goal is a shared diagnosis and a clean handoff, not winning the argument.