LucidGrasp 1.2.2

Bug fixes. Local search, indexing and the cache path.

Fixes

An interrupted save could destroy your index

The index cache was written directly to its final location. If the write was interrupted — a crash, a kill, a full disk — it left a truncated file, and the next launch could not tell "never indexed" from "index destroyed", so it rebuilt from scratch. On a whole-filesystem library that is hours of work thrown away by something that looks like a successful run.

Caches are now written to a temporary file and renamed into place only once complete, so the file on disk is always a usable index.

A miscounted size guard could refuse a valid cache

The check that rejects a corrupt cache header counted more fields than the format actually writes, making its threshold too high. A cache whose entries have very short relative paths could therefore be judged corrupt and silently reindexed on every launch. The threshold is now correct. This could only ever cause an unnecessary rebuild, never a wrong search result.

Documentation

Two claims in the README did not match the code, and are now accurate:

• The 45/35/20 weighting between SSIM, ORB and colour histogram is the inner comparison. The score you see is 80% of that plus 20% from the hash ranking, which was not documented.
• Search time does not grow with library size in the way previously stated. The expensive half of the work is capped at 256 candidates; ranking those is a fast in-memory pass. In practice a whole-filesystem search stays in the low milliseconds.

Upgrading

Drop-in replacement. Existing index caches keep working — the format did not change, so nothing needs reindexing.

Built and self-tested on Linux and Windows.