ImageVerifier

[peterkrogh]

Dan,
The hash is less useful for files that do change.  The change could be caused by virus or malware, and at that point, a reset hash might give a false sense of security.

The hash is most useful for files that are never expected to change.
Peter

[danaltick]

Peter,

I see.  Makes sense.  Thanks for clearing that up.

Dan

[danaltick]

Marc,

Just wanted to let you know that I've been unsuccessful at running IV on any of my buckets so far.  It always aborts for me, but I'm sure my images are ok.  I can open them fine in both Camera Raw and PS.  I've seen it abort on both JPEG's and DNG's.  I'm running with 1.1.01B3.  Can you recommend an earlier version that I could try under Windows.  Thanks.

Dan

[Marc Rochkind]

Dan--

I'll be getting back to IV in a week or two... there's no earlier version, but most likely a problem in IV itself on Windows.

--Marc

[danaltick]

Marc,

No hurry.  Sounds good.

Dan

[matthewjheaney]

What's unusual about IV's approach is that the hash is associated with an ID for the image file that's location independent, so if you move the file from one archive to another or back it up, IV can still find its previously-recorded hash.

Another possibility is to store the hash keys in the database associated with your DAM app.  I think xMedia lets you create custom fields, so that would be one use for it.

I've been using the Microsoft utility fciv.exe to generate the hash keys.  You could write an xMedia script to call fciv.exe for a file, and then write the result to a custom metadata field, or you could use MSXML from the script to extract the hash keys from an already-generated fciv (xml) database.

-Matt

[peterkrogh]

Matt,
I agree that it could be useful fro the hash values to be stored in a database.

The new DNG spec makes this unnecessary (for DNG files), as it provides for the ability to hash just the source data (and the embedded raw file, if it's there) and stores the hash in metadata.  This will enable the files to essentially be self-validating.

This will greatly simplify the process (at least for DNG files).
Peter

[Marc Rochkind]

Peter and Matt--

Just to clarify things, the hash values are stored in an SQLite3 database, one per user.

--Marc

[matthewjheaney]

Just to clarify things, the hash values are stored in an SQLite3 database, one per user.

Right, I think I read that about ImageVerifier.  I was just trying to simplify things: xMedia (really, any DAM app) is already a kind of database, so if I already have xMedia that I don't need anything else.  I'm adding base64 support to the COM component now, so this will allow me to get rid of fciv.exe.

I hadn't heard about the new DNG spec.  It's a bit odd that a file can store its own hash value, since you'd be generating a hash value derived in part from the value of the hash.  Perhaps they have a distinguished area of the DNG file (to store the hash value) that doesn't contribute to computing the hash.

-Matt

[peterkrogh]

Matt,
Right. There are two parts to the file that should *never* change.  The Raw image data, and the Raw file (if it's embedded). Since these are the most important parts of the file, and never change, it's a pretty neat trick just to hash them.

I believe that this functionality will lead to a lot of people realizing that they have a corruption problem that they did not realize.
Peter