Hello, I have just begun trying XnView and I am extremely impressed so far!
I would love to use the categories and ratings features, but I find if the files are moved or copied they may lose any categories/ratings I have added using XnView. In my testing it appears the categories are matched against the full pathname of the file.
I think if the database could be 'synced' against file CRCs or even match categories against CRCs in real time that would be excellent solution. How do other people work around this?
Ps. I do not wish to use embedded data (JPG) as it alters the file hash, and obviously only works on some file types.
Match categories using CRC?
Moderators: helmut, XnTriq, xnview
-
foxyshadis
- Posts: 395
- Joined: Sat Nov 18, 2006 8:57 am
Eventually xnview will get categories that keep track of files as long as you file them within xnview, which will fix half of the problem.
I like your idea of hashing - a crc wouldn't work, too short and have collision problems. But with an md5/sha, a hash can be stored in the category database, and when a file is seen matching that, it can take over the entry if the old file is gone. I think it would work because xnview always has to read the file to get basic information and a thumbnail out of it anyway. Even if it had to close and reopen the file to do it, there'd be no speed hit on newer systems or drives that use disk caching.
Potential problems:
* If thumbnail metadata exists, xnview would normally only read the header and not continue. I don't think reading a whole file is too burdensome, though.
* If a file is copied and later deleted, and the doppelganger is hashed in between, it won't take over. Presumably a rare event?
* Or just automatically create a new entry for every copy, since they are the same image after all. Might be annoying?
Don't get your hopes up on seeing it soon, it's just an idea here.
I like your idea of hashing - a crc wouldn't work, too short and have collision problems. But with an md5/sha, a hash can be stored in the category database, and when a file is seen matching that, it can take over the entry if the old file is gone. I think it would work because xnview always has to read the file to get basic information and a thumbnail out of it anyway. Even if it had to close and reopen the file to do it, there'd be no speed hit on newer systems or drives that use disk caching.
Potential problems:
* If thumbnail metadata exists, xnview would normally only read the header and not continue. I don't think reading a whole file is too burdensome, though.
* If a file is copied and later deleted, and the doppelganger is hashed in between, it won't take over. Presumably a rare event?
* Or just automatically create a new entry for every copy, since they are the same image after all. Might be annoying?
Don't get your hopes up on seeing it soon, it's just an idea here.