To add new features in JPEG-Repair or JpegDigger it is not like me sitting and wondering ‘what will I add now’?
It is much a demand driven process. Real cases present themselves and if they can’t be solved by my own tools or 3rd party tools I consider if it’s worth the effort of adding functionality to my tools to solve a specific problem. Some times it is trivial stuff.
JPEG-Repair changes and what inspired them
For example a user of JPEG-Repair asked me if I ever considered adding a cross-hair to the magnifier. In fact I have but it was fiddly and it never made it to release. There are several conversions done from the pointer on the preview and the magnifier and probably due to rounding off errors I never got it right. Current implementation isn’t one I am 100% happy with but it appears to work. Rather than me trying to get it exactly right, the user can calibrate the cross-hair (double click magnifier).
Other recent changes in JPEG-Repair were mostly the result of me needing it to repair a number of JPEG and CR2 photos that were the victim on STOP / Djvu ransomware.
JpegDigger changes and what sparked them
Recent changes in JpegDigger were result of more serious matters. JpegDigger is a recovery tool, but most cases it ends up getting used in were came in as ‘repair’ cases. In the most recent version lots of changes were made that aren’t very visible. For example I repaired errors in the block size and start of data area detection, and also stream lined code that handled no file system detected situations.
The more visible changes and what prompted me to add those:
Canon CR3 detection: I was contacted by a photographer with a card full of corrupt CR3 files. CR3 files weren’t detected yet because unlike CR2 they’re not TIFF based. In fact thy look more like movies. Current CR3 detection is based on experiments with only a limited number of files.
Deep scan: User of Recuva tried to repair corrupt CR2 files on a memory card by recovering them. Now under circumstances you actually can repair files by recovering them and I wrote several posts on it. But in those cases you need a tool that ignores the file system, so a carver like JpegDigger. Anyway, since Recuva didn’t repair the files it the Recuva user decided to format the drive and try again. Result was:
- Files could not be recovered using the file system (due to the format).
- Files could not be recovered using a carver due to header corruption of the files.
A carver normally looks at the first few bytes of a block, a block being a sector or a cluster. Files normally start at block boundaries. I decided it should be possible to still get at least the embedded full resolution JPEGs from the corrupt, lost CR2 files, however these are NOT block aligned. Hence the deep scan.
Virtual cluster list: Is actually a result of wanting to be able to view the clusters the gap carve feature selects. That and I have been intrigued by this article for a long time, I wouldn’t mind adding a similar feature to JpegDigger. So then adding the option to tick clusters yourself and process that selection then was a logical next step. I then tried this on 10 or so real world memory cards and it worked surprisingly well! I was able to recover quite a large number of fragmented files within a reasonable amount of time.