0

Using ddrescue I rescued most of an old harddisk and afterwards recovered files using photorec. There is plenty of photos fully restored, which is great. But there is also plenty of broken JPEGs that are either half readable and stop somewhere in the middle or have broken headers and wont open at all.

For now, I used GIMP to open them because on the ones where a portion of data is corrupted in the middle of the file, GIMP at least shows the image until the corruption occurs.

Is there any tool which:

  • can open the intact portions of the file and merge them together (not stopping at the corruption, errors in GIMP "Premature end of JPEG file", "Invalid JPEG file structure: two SOI markers", etc. )
  • can assist in finding the right header settings to recover at least some parts of corrupted files that are not possible to open at all

1 Answer 1

0

Reconstructing the "tail" of an image without the header is hard:

Sadly, that's in general impossible by how image compression and JPEG especially works.

First of all, JPEG, in its final stage is Huffman encoded (usually, Arithmetic encoding is rare, or so I'm told). Which means that you need a table (or another encoding of a binary tree) that tells you what a symbol of compressed data means as uncompressed data.

In JPEG, you can either use one of the ready-made tables that the JPEG standard provides, or you look at your data and construct one that's better for the exact image you're encoding. Usually, cameras and software encoders do the latter. It's cheap enough and saves space – losslessly.

But that means without the table, your data just looks like totally random bits and can't be decoded.

With a bit of luck, though, the camera you used only uses precomputed "custom" tables for similar images (to be somewhat better than using the very general JPEG-standardized ones, but not need to compute statistics for every picture anew). Then, recycling the Huffman tables would, indeed, work.

But the problem really is that prior to knowing the table, you can't decode. And then you can't know how many 8×8 blocks of image data are in the readable tail. But it's a rectangular image with a fixed amount of blocks. So if you just put the beginning of another file in place of your broken beginning, it depends on how well that compressed whether you get more or fewer blocks than you should! That still leaves you with a broken image.

TL;DR: nope, hard, gonna be a lot of trial & error, even if you're lucky.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .