ImageVerifier 1.2.02 Beta
Updated on 14 Jul 2011
By Anthony Buckner
By Anthony Buckner
1.9 MB Safe To Install
Advertising
Specifications
License:
Demo (Free to try)
Updated:
Downloads:
136
Platform:
Windows XP / Vista
Publisher:
Marc Rochkind(more)
Website:
Unknown
User Reviews:
Other versions:
Do you like
ImageVerifier?
ImageVerifier?
Publisher's Descriptions
ImageVerifier (IV for short) traverses a hierarchy of folders looking for image files to verify. It can verify TIFFs, JPEGs. PSDs, DNGs, and non-DNG raws (e.g., NEF, CR2).
IV is designed to process large numbers of images. Folder hierarchies with 100,000 images or more should be no problem. In one test run, IV ran for 14 hours.
There are two kinds of verification that IV performs: Structure checking and hash checking.
All structure verification other than for non-DNG raws is built-in; for DNGs IV uses Adobe's DNG SDK directly. JPEGs and TIFFs are verified using built-in libraries as well. PSDs are validated using a method designed specifically for ImageVerifier that follows Adobe documentation for the PSD format. Non-DNG raws (e.g., NEFs) are verified by running them through Adobe DNG Converter.
For all image files, structure checking is performed by reading the actual image data, decompressing as necessary. This can find many errors, but not all, as some errors are indistinguishable for image data.
The real work is done by subprocesses, so IV can take advantage of multiple CPU (or multiple core) computers. For example, if you have 4 CPUs, ImageVerfier should be capable of fully loading all of them at once.
For each verification run, called a job, you can choose the folders, whether to process subfolders or just the top level, what kinds of images to process (TIFF, JPEG, PSD, DNG, and/or non-DNG raw), the maximum number of errors to report, and whether to store the results in a built-in database.
Structure checking is verifying the image file by reading through its various structures and decompressing any compressed image data, looking for errors. This can be effective in finding damage if the damage is large and/or the image is compressed. For highly compressed images like JPEGs, damage detection is very good. It's not so good for uncompressed raws, such as the DNGs that come straight from a Leica M8. It's better for compressed DNGs, but not as good as it is for JPEGs.
Another approach entirely is hash checking, which is maintaining for each image known to be good a fixed-length hash computed from all the bytes in the file so that it's unlikely that two different files will produce the same hash. (Not impossible, since the hash is of fixed length and the number of possible image files is infinite.) If the two files are the good one and a copy (or even the original) that's been damaged, then comparing hashes of the two files will show that the files are not the same.
Comparing the actual files is even better, but in the case of a single file that's been damaged you don't have two files. All you have is the damaged file and the hash from when it used to be good. Also, reading one file to compute its hash takes half as long as reading two files.
The nice thing about structure checking is that no bookkeeping is involved-each file stands on its own. Hash checking, however, does create complications because you need to put the hash somewhere, and you need a way of associating the image with its hash. This is easy for a DAM system that controls all the assets, but much harder with a passive utility like ImageVerifier.
Putting the hash inside the file is one approach, but this has two problems: It's safe only for certain formats for which it's allowed, such as DNG, and it requires IV to write into the file, which I don't want to do because it raises the possibility of damage to the file during verification and because many photographers don't want to use any utilities that write into their files.
So, here's the scheme that IV uses: For each file, a key is generated that's rich enough so that two different images won't have the same key. The key is the concatenation of the filename (not the path, just the last component), the size, the modification date/time of the file, the EXIF DateTimeDigitized, the EXIF SubSecTimeDigitized, and the EXIF DateTimeOriginal (also called plain DateTime).
It's still possible for two different images to have identical keys, but the worse that will happen in that case is that IV will erroneously say that they are different, and then later you can determine that they are not.
IV is designed to process large numbers of images. Folder hierarchies with 100,000 images or more should be no problem. In one test run, IV ran for 14 hours.
There are two kinds of verification that IV performs: Structure checking and hash checking.
All structure verification other than for non-DNG raws is built-in; for DNGs IV uses Adobe's DNG SDK directly. JPEGs and TIFFs are verified using built-in libraries as well. PSDs are validated using a method designed specifically for ImageVerifier that follows Adobe documentation for the PSD format. Non-DNG raws (e.g., NEFs) are verified by running them through Adobe DNG Converter.
For all image files, structure checking is performed by reading the actual image data, decompressing as necessary. This can find many errors, but not all, as some errors are indistinguishable for image data.
The real work is done by subprocesses, so IV can take advantage of multiple CPU (or multiple core) computers. For example, if you have 4 CPUs, ImageVerfier should be capable of fully loading all of them at once.
For each verification run, called a job, you can choose the folders, whether to process subfolders or just the top level, what kinds of images to process (TIFF, JPEG, PSD, DNG, and/or non-DNG raw), the maximum number of errors to report, and whether to store the results in a built-in database.
Structure checking is verifying the image file by reading through its various structures and decompressing any compressed image data, looking for errors. This can be effective in finding damage if the damage is large and/or the image is compressed. For highly compressed images like JPEGs, damage detection is very good. It's not so good for uncompressed raws, such as the DNGs that come straight from a Leica M8. It's better for compressed DNGs, but not as good as it is for JPEGs.
Another approach entirely is hash checking, which is maintaining for each image known to be good a fixed-length hash computed from all the bytes in the file so that it's unlikely that two different files will produce the same hash. (Not impossible, since the hash is of fixed length and the number of possible image files is infinite.) If the two files are the good one and a copy (or even the original) that's been damaged, then comparing hashes of the two files will show that the files are not the same.
Comparing the actual files is even better, but in the case of a single file that's been damaged you don't have two files. All you have is the damaged file and the hash from when it used to be good. Also, reading one file to compute its hash takes half as long as reading two files.
The nice thing about structure checking is that no bookkeeping is involved-each file stands on its own. Hash checking, however, does create complications because you need to put the hash somewhere, and you need a way of associating the image with its hash. This is easy for a DAM system that controls all the assets, but much harder with a passive utility like ImageVerifier.
Putting the hash inside the file is one approach, but this has two problems: It's safe only for certain formats for which it's allowed, such as DNG, and it requires IV to write into the file, which I don't want to do because it raises the possibility of damage to the file during verification and because many photographers don't want to use any utilities that write into their files.
So, here's the scheme that IV uses: For each file, a key is generated that's rich enough so that two different images won't have the same key. The key is the concatenation of the filename (not the path, just the last component), the size, the modification date/time of the file, the EXIF DateTimeDigitized, the EXIF SubSecTimeDigitized, and the EXIF DateTimeOriginal (also called plain DateTime).
It's still possible for two different images to have identical keys, but the worse that will happen in that case is that IV will erroneously say that they are different, and then later you can determine that they are not.
Do you like ImageVerifier
ImageVerifier Disclamer
Please be aware FindMySoft.com accepts no responsibility for the file you are downloading. The same applies to the information provided about the software products listed.
We do not allow the inclusion of any ImageVerifier serial, keygen or crack and we disclaim any liability for the inappropriate use of ImageVerifier.
FindMySoft advises that ImageVerifier should be only used in accordance with the rules of intellectual property and the existing Criminal Code.
For your own protection ALWAYS check downloaded files for viruses.
We do not allow the inclusion of any ImageVerifier serial, keygen or crack and we disclaim any liability for the inappropriate use of ImageVerifier.
FindMySoft advises that ImageVerifier should be only used in accordance with the rules of intellectual property and the existing Criminal Code.
For your own protection ALWAYS check downloaded files for viruses.
Advertising
Popular News
The soon to be released Samsung Galaxy S3 is shaping up to be an event bigger commercial success than its predecessor, the Samsung Galaxy S2
Linux fans once again have the chance to take part in the annual Linux Foundation T-Shirt Design Contest, now in its 3rd edition
Your Rating
1.7
out
of
5
of
5
Rated By
3 Users
3 Users
Top Downloads
2.
Opera5.
Trillian8.
AIM9.
Skype10.
Ad-Aware12.
Nero13.
Google Earth14.
Picasa15.
Winamp16.
iTunes17.
RealPlayer18.
uTorrent19.
eMule20.
WinRAR21.
BitComet22.
WinZip23.
Shareaza24.
CCleaner25.
Recuva26.
Tweak UI27.
CuteFTP Home29.
Adobe Reader30.
NewsPiperBecome A Fan!
Link To Us!
ImageVerifier
HTML Linking Code
HTML Linking Code
Latest Reviews