Data Recovery Case File · Cameras, Drones & Cards · Where the Decoding Stopped
An Image That Renders Partly and Then Turns to Colour Ran Out of Valid Data
Her enquiry describes the damage precisely enough to locate it. A card reformatted in error where the content now appears with "a block of colour over most of the pictures" and video that has "gone all pixelated and jumpy" — with nothing recorded since. Those are not random symptoms: they are what a partly-readable file looks like when a decoder reaches the point where valid data stops.
| Media | Camera memory card reformatted in error — images rendering partially with uniform colour blocks, video exhibiting blocking and irregular motion; no subsequent recording |
| Reported situation | Memory card in a camera reformatted in error · images appearing with a block of colour across most of the frame · video appearing heavily blocked and irregular · no photographs or video recorded since the reformat · professional recovery sought |
| Fault class | Partially recovered image and video data — file openings intact with continuation lost or misassembled; content retained pending overwriting |
| Equipment used | Render failure point interpreted as the boundary of valid data rather than as file corruption throughout · card removed from use before assessment · imaged write-blocked before any further scanning · file extents rebuilt from internal structure rather than estimated length · recovered images and clips validated by opening and playback in full |
The decode: what the colour block is, and what it tells us
How a compressed image is stored: as a stream that must be read in order. Each part of the picture is described relative to what came before, so decoding proceeds from the top and depends on everything preceding it being correct.
What happens when that stream becomes invalid partway: the decoder stops making sense of it. It fills the remainder with a single value, which renders as a flat block of colour — grey, green or magenta depending on the software.
Why that block is diagnostic rather than merely ugly: its top edge marks the exact point where valid data ended. Everything above it decoded correctly, which means the beginning of each file survived and the continuation did not.
Why the same cause produces the video symptoms she describes: video is compressed by describing changes between frames. A stream missing sections produces frames built on absent references, which appear blocked, and timing that jumps — pixelated and jumpy is precisely the expected result.
What that pattern says about the reformat: the file openings are being found and their continuations are not. A format replaces the index that records where each file continues, so recovery software locates a beginning and then has to guess how far it runs.
Why that guess is where the loss occurs: content is not always written in one continuous run. A file split into several regions is reassembled correctly only if all its parts are found in order, and a wrong continuation produces exactly this.
Why that makes the outcome improvable rather than fixed: the data is present and mis-assembled. Rebuilding extents from the internal structure of the file rather than from an estimate frequently returns complete images where a first attempt returned partial ones.
How that is done: compressed streams contain markers and internal consistency that indicate where a file genuinely continues. Following those instead of guessing at length is what separates a partial render from a whole one.
Why her not recording since is what makes it possible: nothing has been written over the regions holding the continuations. The missing parts are still on the card, and the task is locating rather than recovering them.
What must not happen: no returning the card to the camera, and no accepting any further offer to format. The regions holding the continuations are exactly what a camera would write into next.
On the bench
The render failure point was interpreted as the boundary of valid data rather than as corruption throughout — compressed images being decoded in order with each part described relative to what preceded it, so an invalid stream causes the decoder to fill the remainder with a single value that renders as a flat colour block whose top edge marks where valid data ended. Video compressed by inter-frame difference produces blocking and irregular timing from the same cause. Extents were rebuilt from internal structure rather than estimated length.
The outcome
The render failure point read as the boundary of valid data, the card imaged before further scanning, and extents rebuilt from internal structure. Free assessment, one fixed written figure including VAT; on cards where content has been deleted or overwritten, the figure is payable upfront. The decode: that colour block is a measurement. Its top edge is where valid data stopped, so the start of each file survived — and the continuations are still on the card because you have written nothing since.
Recovered images that render partly and then go flat
Keep the card out of the camera and refuse any further format offer, because the regions holding the missing parts of your files are exactly what a camera writes into next. Read the colour block as useful rather than as damage: compressed images decode in order, and when the stream stops making sense the decoder fills the rest with one value — so the top edge of that block marks precisely where valid data ended, and everything above it came through. Video blocking and jumping is the same cause. The missing continuations are usually still there, just mis-assembled.
Keep the card out of the camera — call Manchester Data Recovery on 0161 871 0788; render failure read as the boundary of valid data, imaged before scanning, extents rebuilt from internal structure.
Request a quote online →
Our case files are drawn from genuine enquiries received by our laboratory over the past ten years, anonymised to protect client confidentiality. Each one describes the diagnostic and recovery procedure our engineers apply to that fault, using the equipment listed.