indianajohn / akaze-rust Goto Github PK

Hey, I am interested in if you would support integrating this crate with rust-cv. That would involve using rust-cv types like ImageKeyPoint. I have started doing a little image matching with rust-cv crates such as arrsac, eight-point, cv-core, and sample-consensus.

Much of the binaries and examples you have today can be effectively implemented now on top of the rust-cv ecosystem, but there is more work that needs to be done. Specifically, I would like to create types for the descriptors and integrate them with matching via the hnsw crate. If the akaze crate produced these descriptors (with SIMD alignment) directly, it would make the amount of glue logic necessary to perform matching much smaller. I can perform the work necessary to undergo this process. This would involve adding the descriptor types, creating abstractions around feature extraction (similar to Feature2D), and using the ImageKeyPoint type. We can also refactor the binaries out into various exectuables that support choosing from multiple feature extraction techniques at runtime so that we can benchmark, compare, and use them all together.

Let me know if you think this is a good idea. If so, I will get to work on it right away. If not, I can make an adapter crate to integrate it, but I will probably need to file a follow-up issue for refactoring the crate to reduce allocations since right now it performs a great deal of allocations. I will probably also need to work on SIMD integration since SIMD typically goes faster when all your memory is properly aligned. It also should support #![no_std] for embedded use cases, as I am trying to do that for all rust-cv crates.

If you are interested in moving the crate to the rust-cv organization, feel free to. I am inviting you to the org right now as an owner, so if you accept you should have full privileges. Feel free to join the discord as well. We have a bunch of CV people on there at this point, including the maintainer of OpenMVG.

The readme field in the Cargo.toml needs to point to ../README.md. This was broken when I changed to a workspace in #4.

I would like it if the binaries were separated out of the crate so they could be built independently of the library, perhaps in an akaze-utils crate. As it stands, clap and other dependencies are pulled into the library simply because the binary needs them. On its own, akaze is pulling in around 200 dependencies right now. I would like to modify the dependency chain to only use the features akaze needs to slim it down, but I think the first step in this will need to be separating out the binaries.

Is this acceptable?

If so, I can open a PR taking the binaries out and if you create an akaze-utils (or another similar name) I can submit a PR re-adding the binaries from the revision history. Feel free to do that yourself if that is easier for you.