To recover log footage you scan for a normal video container, because a log clip is an ordinary MP4, MOV, MXF, or BRAW file holding an ordinary codec stream. The hard part begins after the bytes come back. Log data is only usable if the curve, the base ISO, and the color matrix travel with it, and a signature scan can rebuild a video stream faithfully while leaving those values behind.
So treat this as two jobs: get the samples back, then rebuild the grading context around them. A clip that plays correctly and grades incorrectly is the most common outcome of a log recovery, and it is usually fixable.
Why a Recovered Log Clip Can Still Look Wrong
A recovered log file has three separate levels of success, and only the third one matters on a paid job.
| Outcome | What it looks like | Typical cause | Fix |
|---|---|---|---|
| Bytes recovered | File exists, correct size and duration | Directory entry lost, data blocks intact | None needed |
| File plays | Opens in a player, audio present | Index was rebuilt or survived | Verify against the camera’s preview |
| File grades | Correct contrast and color after a transform | Curve and base ISO reconstructed | Rebuild the grade from camera and mode |
The jump between the second row and the third is where log recovery differs from recovering standard footage. A standard-profile clip that decodes correctly is finished. A log clip that decodes correctly is only a starting point, because log is a tone curve rather than a delivery format — the concept is covered in what log footage actually is.
The practical consequence is that “the file is fine but the color is wrong” is a normal, expected intermediate state, not evidence that the recovery failed.
What a Log Clip Carries Besides Pixels
Five pieces of information decide whether a recovered clip can be brought back to a normal image. Where each one lives determines whether recovery keeps it.
| Value | Why it matters | Where it is usually stored |
|---|---|---|
| Curve identification | Distinguishes S-Log3 from a standard profile | Container user-data or metadata track |
| Base ISO | Anchors code values to scene luminance | Per-clip metadata |
| Exposure index offset | Records a deliberate over- or under-exposure | Clip metadata, sometimes absent |
| White balance and camera matrix | Restores color from the desaturated log state | Clip metadata |
| Look reference | Points to the intended transform | Sidecar .cube or .XML file |
The first four travel inside the container’s metadata region when the camera writes them there, which means a recovery that rebuilds the media stream but not the surrounding metadata region returns a clip with no grading instructions. The fifth is different: it is a separate file on the card, and deleting or losing the card’s directory loses it independently of the footage.
Cameras vary here. Some embed all five. Some write the curve flag into the container and the look reference into a sidecar. A few write camera metadata into blocks that are not contiguous with the media data — the uncomfortable case, because a recovery can faithfully reassemble a continuous run of video samples and still miss the header that explains how to interpret them. The field layout used by different codecs is described in container and codec structure in camera files.
Scanning for Log Clips: What the Recovery Tool Sees
Log does not produce a distinctive file signature. The scanner is looking for containers, not curves, which is good news: a deep scan finds log clips using exactly the same markers it uses for any other video.
| Format | Marker the scan looks for | Typical log footage |
|---|---|---|
| MP4 / MOV (H.264, HEVC) | ftyp, mdat, moov atoms | S-Log3 in XAVC HS, D-Log in H.265 |
| ProRes in MOV | icpf atom, apcn / apch codec tags | V-Log, F-Log2, Apple Log |
| MXF | KLV packets, 0x060E2B34 key prefix | S-Log3 XAVC-I on professional bodies |
| BRAW | Fixed-length frame headers, .braw sidecar structure | Blackmagic log and RAW pipelines |
Two habits make the scan productive. Sort the results by the camera’s file-name pattern, since most bodies use a sequential clip number that lets you match recovered files to shots you remember and spot gaps. And expect fragments: a long-GOP clip written across a fragmented area can return as several candidates, of which the largest is usually the real stream and the others are partial runs.
If the clip comes back complete in size but refuses to open, the fault is almost always the index rather than the image data, and the rebuild path is the same one used for any camera video. The general procedure is covered in recovering camera video files and the specific index case in repairing a file with a missing index.
When the Curve Flag Is Gone: Rebuilding the Grade
If the metadata region did not survive, the clip can still be graded — deliberately, not by guesswork. Four signals identify the curve.
The camera and the recording mode. S-Log3 comes from a Sony body set to a specific picture profile; V-Log from a Panasonic body in its log mode. If you know which camera shot the clip and which mode it was in, you know the curve.
The bit depth and codec. A 10-bit HEVC clip from a Sony FX body in log is not going to be S-Log2, which is an 8-bit-era design. Bit depth narrows the candidates quickly.
The code values. Sample a known reference in the frame — a neutral gray card if one is in the shot, or the average of a midtone area. A midtone that lands near 128 indicates a standard gamma; a value pushed toward 400 in 10-bit indicates a log curve. Comparing the measured level against published curve data identifies it.
Rebuilding base ISO is the part that produces false alarms. Grade a clip assuming the wrong base sensitivity and the shadows crush or the highlights blow, which reads as sensor damage or as an error in the recovery. On most systems the base ISO for the log mode is a published constant — around ISO 800 for S-Log3 on many bodies — and any exposure index offset you dialed in on set has to be recreated by hand. If the offset was never recorded, grade to taste and note that the original exposure intent is unrecoverable.
Reapplying a LUT Without the Original Cube
A missing .cube file feels worse than it is. Two different things get called a LUT on a log shoot, and they have very different consequences when lost.
The technical transform converts the log curve to a viewing space such as Rec.709. This is not creative work — it is a defined mathematical conversion, and every camera manufacturer publishes the matching LUT for each of its log curves. Download the right one, or use the built-in log-to-Rec.709 transform in any grading application, and the conversion is recovered exactly.
The creative look was applied for monitoring only. It was never baked into the recorded file; the sensor data on the card is unaffected by whatever the director’s monitor showed. Losing it costs nothing except the ability to reproduce the on-set preview, and if you need that, it is a new grade rather than a recovery problem.
One rule protects the recovered latitude: never bake a LUT into the recovered file itself. Apply the transform in the timeline and keep the log original untouched. A log clip re-encoded to a delivery format has thrown away the dynamic range that made it worth recovering, and that step is irreversible. Verify the transform by comparing the graded result against any proxy, thumbnail, or camera-generated preview from the same take.
RAW-Based Log: BRAW, R3D, and Cinema RAW Light
RAW formats sit outside this workflow in one important way. A BRAW or R3D clip stores sensor readings rather than encoded frames, so there is no log curve applied to the data at all — the “log look” comes from metadata that describes how the RAW values should be developed.
That changes the recovery picture. There is no curve flag to lose in the same sense, because the transform is chosen at development time rather than recorded at capture. The metadata that does matter is a sidecar or an embedded block describing white balance, ISO, and the camera’s color science. If it is missing, most RAW pipelines can still open the clip and apply default development settings from the camera model. What is lost is the record of the intended look, not the ability to develop the image.
Clips where the image data itself is stored this way are handled by different tools and a different set of expectations, described in recovering cinema RAW video and, for the extraction and development stage specifically, in recovering BRAW and R3D files. If a RAW clip opens but shows no image at all, that is usually a development-side problem rather than a media one, and the checks in what to do when a RAW file will not open apply.
If you are on Windows and the card is still detected by a computer, a purpose-built recovery tool such as XRecovery (xappset.com) can scan SD, microSD, CFexpress, and other memory cards for deleted or formatted video, including 10-bit HEVC and ProRes log clips. As with any recovery tool, stop writing to the card first and always save recovered files to a different drive.
Verifying a Recovered Log Clip Before You Trust It
Grading is the strictest test available, because it multiplies every imperfection in the image. Four checks catch the failures that a casual playback misses.
- Play the clip end to end in two different applications. A clip that one decoder hides errors in is not a clip you want as the only copy of a take.
- Magnify the shadows after applying the transform. This is where reconstructed frames and banding appear. If a segment of the clip looks clean ungraded and falls apart when graded, some predicted frames were rebuilt incorrectly.
- Check the frame ordering and duration. A clip that is the right length but stutters at a consistent interval usually has a mis-ordered run of frames, not missing frames.
- Confirm the audio is in sync at the end of the clip, not just the start. A drift that grows toward the tail points to a reassembly problem rather than a decoding one.
A structured pass through these checks, along with file-level hash verification, is described in how to verify recovered files. For clips where the media stream is intact but the file will not decode at all, the repair route is fixing corrupted video files.
Frequently Asked Questions
Can log footage be recovered if the metadata is missing?
Yes. The video stream is ordinary codec data and recovery tools find it without any log-specific information. The curve, base ISO, and matrix can be reconstructed from the camera model, the recording mode, the bit depth, and the measured code values of a known reference in the frame.
Does losing the on-set LUT make recovered log footage unusable?
No. A monitoring LUT is applied to the preview only and is never written into the recorded file. The technical conversion from log to a viewing space is available from the camera manufacturer for every log curve, so the clip can be brought back to normal appearance.
Why does my recovered log clip look gray and flat?
That is what ungraded log footage looks like. Log curves spread code values evenly across exposure stops instead of concentrating them in the midtones, so the flat appearance is correct, not damage. Apply the matching log-to-Rec.709 transform and the contrast returns.
Can a log clip with a missing index be fixed?
Usually, yes. A clip that is complete in size but refuses to open is typically missing its index rather than its image data. Rebuilding the index from a reference clip recorded with the same camera, resolution, and codec restores playback without touching the video samples.