Not using a cryptographic hash - no.
But you could use a Fuzzy Hash or Locality-sensitive Hashing. Fuzzy hashes are different from normal hashes in that they allow similar content to cluster together in the hash collision space*.
Typically one-way means you can not infer what was hashed - but with fuzzy hashes, if you know a similar file (fingerprint image) that matches the hash (collides) then you know what generally was being hashed.
Whether any functional one-way property can exist for a fuzzy hash depends on whether the attacker has to resort to brute force guessing of inputs to find a matching fuzzy hash. This is called pre-image resistance.
Consider that many unique fingerprints exist, at least as many as the current population of earth (~233) and that a fingerprint fuzzy hash exists that collapses reliably (a very tall order) down to this collision space or larger. You want attackers to have to brute force across 233 entries instead of simply invert the hash.
If such a fuzzy hash existed, you could protect against straight-up inversion by passing the hash through a secondary cryptographic hash. Providing the fuzzy hash collapsed reliably and consistently in the first place, you will lose no matching accuracy after rehashing against a cryptographic hash with a much larger collision space. So good luck knowing what the interim fuzzy hash was, providing that secondary hashing appended a random salt.
The fuzzy component makes it a non-cryptographic one-way hash as the "fuzziness" of the image matches contradicts the property of strong collision resistance.
fuzz() = Mythical_perfectly_consistent_fuzzy_hash_function_for_fingerprints();
salt = application's public random salt
hash_result = SHA-512(salt, fuzz(fingerprint.input))
* At this point, all the cryptographers in the room should scream cold-blooded murder and pull out their Uzis :-)