PhotoRescue Advanced : a recovery tutorial.
| PhotoRescue Advanced offers uniquely powerful tools to assist picture recovery. It is however more complex to use than the standard version of PhotoRescue.
This tutorial uses an real
world 16MB compact flash card image. This card was reused many times (leading to picture fragmentation), reformatted on a Mac Intosh. Further, on many occasions, we copied random files and created new subdirectories, overwriting large chunks of data. Finally, we overwrote its MBR (master boot record) with bogus data and it is not recognized by the operating system anymore. As you would expect, the majority of the original pictures are gone. As a matter of fact, I am surprised that PhotoRescue can still find pictures on it! Now, lets go on with the tutorial.
First, we launch PhotoRescue and run a normal recovery procedure: |
| For this tutorial, we will use the default options. As soon as the normal recovery completes, click continue in order to see the recovery results. Since the card was reformatted, all the directory information has been lost and the recovered pictures are in the FOUND directory: |
Let's open it and see what the result of the automatic recovery is. We first see files with strange names such as DESKO~1, OPENFO~1, FINDER.DAT, etc... These files were created by the operating system when the card was inserted into a reader connected to a MacIntosh. Important note: this means that as soon as you insert a card and Mac OS X recognizes it, it creates new files, and possibly overwrites your valuable data. In such cases, pictures whose data has been overwritten are definitively lost !
PhotoRescue still has recovered some nice pictures: see V0000002.JPG file example. |
| We will now try to recover more pictures than the automatic procedure. Press F2 to open the advanced recovery window (it is also available from the popup menu). |
The tree on the left of the recovery windows contains the following branches:
- RECOVERED: all recovered pictures.
- FREE CHUNKS: chunks not belonging to any file.
- FREE CHAINS: fat chains not belonging to any file.
- UNRECOVERED: leftover information about unrecoverable files.
Hiding Recovered Files
We will focus our attention on the RECOVERED files. This is our work area. First of all, let's remove correctly recovered pictures from our consideration. Click on the file name. It's image should appear on the right of the tree. If the picture has no anomalies, right click and select "Hide": |
The following graphic files may be hidden.
AVI_1725.THM: hide
V0000002.JPG: hide
V0000003.JPG: hide
V0000004.JPG: hide
V0010022.JPG: hide
V0000008.JPG: hide
V0000009.JPG: hide
IMG_1721.JPG: hide
IMG_1705.JPG: hide
V0000014.JPG: hide
V0000015.JPG: hide
V0000017.JPG: hide
V0001018.JPG: hide
There is a faster method of cleaning up
the work area. The "mark as recovered" menu item is
available in the main window popup menu. There you can select
several images and hide them at once. The only drawback of
this method is that you see thumbnails and it is difficult
to judge if the picture is perfect. For example, the picture
V0010019.JPG look nice on the thumbnail, but on the enlarged
image you'll see that bottom lines are, in fact, damaged. We will also hide the following non graphic files from the work area because we can not do much with them:
DESKTO~1: hide
FINDER.DAT: hide
OPENFO~1: hide
._502: hide
0.CTG: hide
Temporary Items: hide
502: hide
502: hide
Our workspace now only contains crippled pictures, which we will try to improve. The recovery procedure is iterative goes through two distinct phases:
- the truncation of crippled files where data is wrongly appended.
- the growth of short crippled file.
We will repeat these steps until we recover all pictures or we can't improve on the situation.. |
Truncating Files Let's take, for example, V0010019.JPG.
It is listed to be 479232 bytes long. Press
the "Auto size" button to calculate the minimal size that the
file can have while keeping its appearance - in other words,
we eliminate invisble appended data. V0010019.JPG: calc size: 409600 bytes
But this is not enough : the bottom lines
obviously do not belong to the original picture, so we will
remove them by pressing the "<" button several times. The resulting picture is not complete, but do not worry about it for the moment, just truncate the file to a valid border (press "Truncate"): V0010019.JPG: truncate to 401408 bytes
|
By truncating the file we released clusters
mistakenly appended to the picture. These clusters, which could
have been parts of other pictures, are now available for further
analysis. Let's repeat these steps for the remaining files.
Autosize, manually remove erroneous clusters (press "<" several
times), truncate. N0000001.JPG: calc size: 69632 bytes
N0000001.JPG: truncate to 65536 bytes
Please note the autosize does not always give the correct size of the picture for all the files. For example:
V0010020.JPG: calc size: 217088 bytes
V0010020.JPG: truncate to 98304 bytes
We had to manually specify the real file end. The
easiest way here is to press the "<<" button. This button removes
one contiguous chunk from the file: |
| Here we have to do it manually too. The resulting picture is only a narrow band, but don't worry, we are going to append something to it later: (Keep this image in mind !) |
IMG_1722.JPG: truncate to 12288 bytes
The next file, N0000002.JPG, can not be rendered to a picture at all. The file size is too small, the rest of the pictures is lost for the moment.
N0000003.JPG: truncate to 12288 bytes
V0010021.JPG: calc size: 331776 bytes
V0010021.JPG: truncate to 135168 bytes
V0000006.JPG: truncate to 45056 bytes
N0000004.JPG: truncate to 139264 bytes
V0000007.JPG: truncate to 110592 bytes
V0010023.JPG could not be truncated to a reasonable picture part. So we truncate it to 12288 bytes. If we made it bigger, it would contain parts of other pictures: |
We can make is smaller, but we could remove essential information by doing so. So the safest approach is to truncate it 12288 bytes.
V0010023.JPG: truncate to 12288 bytes
Here the situation is the same.
V0000010.JPG: truncate to 12288 bytes
V0020025.JPG: calc size: 552960 bytes
V0020025.JPG: truncate to 548864 bytes
V0000011.JPG: calc size: 335872 bytes
V0000011.JPG: truncate to 335872 bytes
IMG_1718.JPG: calc size: 311296 bytes
IMG_1718.JPG: truncate to 307200 bytes
N0000005.JPG does not need to be truncated
N0000006.JPG: calc size: 45056 bytes
N0000006.JPG: truncate to 40960 bytes
V0000016.JPG: calc size: 897024 bytes
V0000016.JPG: truncate to 671744 bytes
In the latest case, we had to manually truncate the picture - the lower part of it is shifted.
|
Growing files
We now have cleaner picture beginnigs. We
can try to complete them by pressing the "Grow" button on by
double-clicking on them. Of course we could do it before, but
without all erroneous clusters released to the pool of free clusters
it would not make much sense. PhotoRescue will build all possible
continuations for the picture. For V0001032.JPG the best continuation
is 1301..1331 because it completes the picture. To make sure
that the picture is ok, double click on the thumbnail. The bigger
image will be displayed on the recovery window. We select it
and press OK. |
V0010019.JPG: append 1301..1331 (126976 bytes)
Congratulations! We recovered one picture. But if we try to remove it from our work area, PhotoRescue will complain. Why? Because the new picture now again contains some garbage at the end. We remove it using the autosize-truncate pair:
V0010019.JPG: calc size: 409600 bytes
V0010019.JPG: truncate to 409600 bytes
At this point, we can remove the fully recovered picture from the work area.
V0010019.JPG: hide
We'll try to do the same with other pictures. Most of the time the continuations are plain wrong. But we are lucky with at IMG_1722.JPG:
|
IMG_1722.JPG: append 1303..1331 (118784 bytes)
IMG_1722.JPG: calc size: 131072 bytes
IMG_1722.JPG: hide
It is always a good idea to check the file
size by "autosize" after growing it and eventually re-truncate
it. We are lucky with the next file as well. Initially it could
not be rendered as a picture at all, but now we find two additional
chunks for it. Try to grow it twice: |
N0000002.JPG: append 2743..2774 (131072 bytes)
N0000002.JPG: append 2850..2857 (32768 bytes)
N0000002.JPG: calc size: 180224 bytes
Another picture emerges:
|
N0000003.JPG: append 1881..1907 (110592 bytes)
N0000003.JPG: calc size: 122880 bytes
How nice! We again complete another picture: |
V0010021.JPG: append 1609..1661 (217088 bytes)
V0010021.JPG: calc size: 352256 bytes
V0010021.JPG: hide
One more picture recovered:
|
V0010023.JPG: append 2025..2142 (483328 bytes)
V0010023.JPG: calc size: 315392 bytes
V0010023.JPG: truncate to 315392 bytes
V0010023.JPG: hide
Another picture growing:
|
V0000011.JPG: append 3095..3104 (40960 bytes)
Alas, all other continuations do not make
sense (try them yourself!). The picture N0000004.JPG looks promising
with its continuation 3167..3239, but still there is one cluster
missing and we can not recover it. Now that we have recovered
all pictures we could, the rest is simple: close the recovery
window and save the results in the usual manner. For your convenience,
PhotoRescue keeps log of all your actions for your convenience.
It is appended to the file called "recovery.log" in the current
directory. The automatic recovery on this awfully corrupted card gave us 12 pictures and 1 thumbnail (THM). Our manual recovery, in addition to that, gave us:
- 4 completely recovered pictures
- 3 better recovered pictures
- cleaned up garbage at the bottom of partial pictures
Depending on the data on the card, your results may
be more or less impressive. Some cards have physical defects and the
data is really gone. Sometimes is it overwritten. While automatic recovery
does achieve 95% to 99% in simple cases, heavily fragmented or mistreated
cards are a tougher nut to crack. While the standard version of PhotoRescue
includes an automatic "defragger", nothing can beat the human brain on
very hard cases! The purpose of PhotoRescue advanced is to unleash this
power. |
Hints and tips
- Do not truncate files too much. You can always truncate them more later. But on the other hand, if you see that a cluster does not belong to the file, remove it as soon as possible.
- After truncating a file try to grow all files again. The released clusters may complete a picture. You might want to grow the truncated file too because it might grow to a whole picture.
- If you see that the content of a non-picture file does not correspond to its name, try to delete it instead of hiding it. Chances are that the non-picture file was deleted and a picture was put in its place. By deleting it you return the occupied clusters to the free cluster pool. If you hide a file, the clusters remain occupied.
- Start from the bottom of the work area when growing files. The files at the bottom take less time to compute all continuations.
|
|
