Fragmented CR2s & bruteforce?

Using PhotoRec to recover lost data
Post Reply
Message
Author
keithbcg
Posts: 3
Joined: 22 Aug 2012, 04:11

Fragmented CR2s & bruteforce?

#1 Post by keithbcg » 22 Aug 2012, 04:59

Photorec is amazing!
...but it doesn't cope with fragmented .cr2 files...

Would it be possible to apply the bruteforce logic to the raw data portion of .cr2 files to help this?

According to these links, the raw image data in the .cr2/tiff file is compressed in lossless Jpeg format starting at the tiff IFD#3 till the end of the file...
http://lclevy.free.fr/cr2/#key_info
http://wildtramper.com/sw/cr2/cr2.html

Background: I'm trying to undelete a bunch of .cr2's from an image of an external disk (HFS+) with lots of fragmented files.
Photorec (6.14-WIP compiled under OS X) does an amazing job finding the jpegs and jpeg previews, but the fragmentation is resulting in corrupt raw data for most of the cr2s themselves (which are 15-27MB)

Either way, thanks for making photorec available - it's been a life saver!

--Keith

Sponsored links

User avatar
cgrenier
Site Admin
Posts: 3399
Joined: 18 Feb 2012, 15:08
Location: Le Perreux Sur Marne, France
Contact:

Re: Fragmented CR2s & bruteforce?

#2 Post by cgrenier » 31 Aug 2012, 11:12

Unfortunately the brute-force method only really works for jpg files

keithbcg
Posts: 3
Joined: 22 Aug 2012, 04:11

Re: Fragmented CR2s & bruteforce?

#3 Post by keithbcg » 04 Sep 2012, 02:36

That's a pity.
Can you quickly explain how the jpg defragging code works? (Or point me at the right thread if you've already answered that somewhere...)
Thanks - K

User avatar
cgrenier
Site Admin
Posts: 3399
Joined: 18 Feb 2012, 15:08
Location: Le Perreux Sur Marne, France
Contact:

Re: Fragmented CR2s & bruteforce?

#4 Post by cgrenier » 11 Sep 2012, 07:55

PhotoRec uses libjpeg or libjpeg-turbo to check if a recovered jpg is valid or not. If the file is corrupted, it's discarded.
The picture decoding is done line by line. In brute-force mode, PhotoRec tries to determine which data block is foreign to the picture, which bloc causes the decoding to stop. The next step is appending data from the following blocs in the hope it fixes the file. This process is very slow and not very reliable: sometimes you get a valid jpg composed from two different pictures.

Post Reply

Who is online

Users browsing this forum: No registered users and 0 guests