This is really cool!

I think you want just the count field (which is the total); the extra_count field is used to keep track of how many k-mers were in their canonical orientation in the original file (for quality/filtering purposes). You should be able to get the k-mer length for most of our sketches from the raw k-mer sequence, but this isn't guaranteed to exist in the spec (for example, we sometimes strip these out in our internal downstream code to save space).

As an aside (and this probably isn't clear because we don't have any developer docs!), the MinHashKmers struct is our working heap implementation and it doesn't track a lot of the metadata you probably want for generic interop (like the hash seed). You can still use it if you're using finch directly from the sketching step, but internally we mostly use Vec<KmerCount>s instead.

I'm actually in the middle of a big refactor (that I really need to finish and merge soon; hopefully still this week) to add support for the binary mash format that also cleans up some of our internal code around this. The new implementation of our "generic" sketch struct is: https://github.com/onecodex/finch-rs/blob/binary_support/src/serialization.rs#L33 (the exact commit may be subject to rebase changes, but the pub stuct Sketch itself is pretty final). There's also a MultiSketch that stores all the exact k-mer size, hash seed, hash type, etc details, but this may not be appropriate if you just want to convert one sketch at a time.

Now that 0.1.6 is released I updated the PR and... everything just worked?

@bovee I don't have a higher level struct yet (what would be the sourmash signatures or the finch Sketch), but when I have it I'll take a look into doing a better job at integrating it properly.

(long story short: sourmash-rust only implement the low level data structures, but all the metadata and JSON serialization is done in Python. It may change in the future, tho =])