Part II: File recovery (30 pts) I accidentally deleted all of my photos (JPEG fo
ID: 3665759 • Letter: P
Question
Part II: File recovery (30 pts) I accidentally deleted all of my photos (JPEG format) from my digital camera's CompactFlash (CF) card. Luckily, in the computer world, "deleted" tends not to mean deleted so much as "forgotten". My computer tells me the flash card is blank, but I'm sure that the image data still exists on the card, just the file names and locations have been deleted. For this assignment, write a program Recover.java to recover the photos from my flash card Recover java will need to read over a copy of my CF card, looking for JPEG signatures. The first four bytes of most JPEGs are either: 0xff 0xd8 0xff 0xe0 0xff 0xd8 0xff 0xel Odds are if you find one of these patterns of bytes on a disk known to store photos, they mark the start of a JPEG. Each time you find a signature, open a new file for writing and start filling that file with bytes from my CF card, closing the file once you encounter another signature. File names should be 1.jpg, 2.jpg, I've made a copy of the CF card that you can open directly by your program, i.e. do not copy to your local directory: /home/linux/ieng6/cs11wb/public/HW5/card.raw To ensure your program works correctly, try opening each of the generated *.jpg(s). If you open them and don't see anything, something went wrong. I won't tell you how many images should be recovered, but it is more than 5 Additional Information: Digital cameras tend to store photographs contiguously on CF cards. So, the start of a JPEG usually marks the end of another. Digital cameras generally initialize CF cards with a FAT file system whose "block size" is 512 bytes, meaning they only write to those cards in blocks of 512 bytes. JPEG's can span contiguous blocks. Otherwise, no JPEG could be larger than 512 B. Thus a photo that's 1 MB (i.e. 1,048,576 B) takes up 1048576/512 2048 blocks on a CF card The last byte of a JPEG might not fall at the very end of a block. A photo that uses a few bytes less than 1MB, e.g. 1,048,574 B, will still use 2048 blocks. Because the CF card was brand new when started taking pictures, it was most likely "zeroed" (i.e. filled with 0s) by the manufacturer, in which case any slack space will be filled with Os. It's ok if those trailing Os end up in the JPEGs you recover Rather than reading the card's bytes one at a time, you can read 512 B at once into a buffer for efficiency's sake. Thanks to FAT, the JPEG's signatures will be "block-aligned". That is, you need only look for those signatures in a block's first four bytes.Explanation / Answer
using the javax.ImageIO library
I took a look at the JPEG format, and to my understanding a final EOI (end-of-image) segment of two bytes (FF D9) should be last.