I have a user who sent me a corrupt jpg file. I have a program that is
supposed to uncorrupt jpgs of the very kind he has. However even
though I had a native speaker translate the Flemish instructions into
English, I still can't follow them well enough to fix a file
The program itself is quite easily to handle. But it has (at least)
2 bugs which prevent it from showing appropriate results. Let's have
a look at the functionality:
The program works by inserting one (and only one!) additional byte
on a selected position. The value of the byte is initially 00h, but
can be changed. Any change on the image performed by the program
only relates to that inserted byte. I.e.: You only control position
and value for 1 additional byte.
In detail:
First step is opening the *.jpg. After that the working mode has to
be selected with F1 key. There are 3 modes. The first (b) lets you
move the position for inserting the new byte. It usually skips part
of the jpg-header. That's why it doesn't start from offset 0 (as
shown after loading the image), but (always?) from position 10.
(If you open a new picture without closing the program, the initial
offset will be the last used with the former image, though.)
The second mode (v) lets you change the value of the currently
selected (newly inserted) byte. The third (bv) is for animated
display of predefined changes for both, position and byte value.
Usually, you start with mode 'b' to get near the position of the
(presumably) missing byte. Note, that all position values relate
to the byte position inside the jpg-file and not to positions of
the image. The 'b'-mode lets you move the position pointer from
current position (as indicated by <offset>) a number of bytes
(as defined in <jump>). F3 moves the number of bytes shown in
<jump> backwards, while F4 moves forward.
You have to adjust <jump> according to your needs to get to the
position of the image error. Start by selecting one of the
default jump ranges F9 (10000) / F10 (100) / F11 (1). You can
repeatedly double or halve the <jump> value by hitting F8 or F7.
Because you can't choose any possible offset (but only multiples
of the 3 standard offsets) you usually need to iterate a couple
of position changes (i.e.: several jumps with changing values
for <jump>) to get near the error position.
Depending on the structure of your file, you'll see significant
or barely noticeable changes after position changes. If you get
near the error position you should zoom into the picture area
*before* the error by left mouse clicks. Choose a <jump> value
of 1 at last to trace step by step near the error. Now the 'bv'
mode would come handy. But I'll talk about that one later...
If you think you have the correct position, change the mode to
'v'. Change byte value of that position by F4 (counting upwards)
or F3 (downwards) until the picture looks okay. If no value
results in a non-erroneous picture, then either the position
is wrong, the picture needs additional bytes inserted or can't
be fixed that way at all. The latter can be the cause, if a
byte just needs to be changed (and no byte has to be inserted
first). If that is the case, note the byte position of the
error and edit the byte(s) of that file position (or a bit
afterwards) inside your favorite hex-editor.
The 'v' mode has the first important bug I mentioned earlier.
If it would work okay, the <bytevalue> should take numbers
from 00h to FFh. Unfortunately, the author transformed these
numbers for display into a string. And he, moreover, used
signed numbers for that conversation. That (in itself) would
still not cause a problem. But he limited the output string
to 2 chars. That's why the program crashes with numbers
greater 63h (= 99) and smaller F7h (= -9). :-(
So you just can test values between -9 and 99. All other
have to be done with a hex editor, again. - If needed...
Before I skip to the last mode, I'll discuss the loop keys.
While the F3 and F4 keys only execute the selected command
(position change ['b'] or byte value change ['v']) once, the
F5 and F6 keys permit repeated execution. Use the F12 key to
adjust the repetition factor from 15 to 6589. The current
factor will immediately be displayed. The display updates
after every single step of the repetition cycle. So you can
see the changes and memorize the values for <offset> and
<bytevalue> which show the best effect. The current run
cycle is displayed in <loop>.
As noted, the repetition either changes position ('b' mode)
or byte value ('v' mode). It is immediately clear, that often
neither the correct position nor the needed value are known.
So it would be nice if (after setting the <offset> to a near
error position) the byte insertion point will be moved forward
step by step, and for each position all possible byte values
will be tested. That's the function of the 'bv' mode.
At least, that's what the 'bv' mode is supposed to do. In
reality, the program only checks <bytevalue> 00h to 04h
and advances the <offset> position afterwards. The values
05h to FFh go unchecked. - That's the second major bug.
Hm. That's just it. Maybe one additional hint. A corrupt
image can have an error inside the data or inside the header.
You should first try the data part and jump right into the
midst of the file with 'b' mode until you are directly before
the erroneous part. If changes in that area don't work, you
can try the header. Without structural understanding of the
internals of jpg files, this will result in step by step
value changes along the whole first bytes of the file. There
are several tables in front of a jpg, which all could be
corrupted (Huffman compression, DAC color, quantisation,...).
Small changes in these areas usually will result in very
significant changes within your file.
...So, if anybody's game, can you try to uncorrupt the following:
http://www.pruittfamily.com/images/P7190929.JPG, with the program
http://www.s2services.com/jpg-repair.zip and explain it?
Maybe, you contact the author of the program to fix the bugs. If you
do so, you can ask him to include yet another mode. Otherwise, you
can't use the program to solve the problems with your picture, at all.
If you take a look into your jpg file, you'll see 3 blocks (512 bytes
each) containing nothing but 00h values. These are skipped on decoding
the image and result in the position shifting. If you fill these with
some useful values (take just another block of 512 bytes from the file,
at best from a position near the error), the picture geometry should
look more the less okay. Your big problem will be the colors. Because
encoding depends on previous data, not only the 3 blocks with the
random data you copied look bad, but all the following data, too.
Only chance would be a step-by-step brute force approach. You need
to change one 00h value of each of the 3 blocks after another, until
the result looks okay. Because values depend on each other, you have
to do it for several bytes on every pass. Only you can say, whether
you need the picture *that* urgent. ;-)
Besides - the thumbnail inside the image is undamaged...
I'll donate proceeds if any to the charity of the posters to this
threads choice (or to the fixer's choice if there's just one).
That's a freeware group. You get *everything* for free here. Even
help and advise. ;-)
HTH.
BeAr
, great stuff. I can follow most of your