Git Product home page Git Product logo

akaze-rust's Introduction

A-KAZE Feature Detector, Extractor, and Matcher for Rust

This repository is deprecated.

This used to be the home for the akaze-rust crate, but I transferred ownership of that crate to the rust-cv organization. For the latest version of this code, go here:

https://github.com/rust-cv/akaze

Original README

This repository contains a Rust implementation of the A-KAZE algorithm. I would like to thank the original authors of the A-KAZE algorithm, who provided the implementation I used as a reference here:

A-KAZE original authors' GitHub repository

The work in this paper was first published in the following papers.

Fast Explicit Diffusion for Accelerated Features in Nonlinear Scale Spaces. Pablo F. Alcantarilla, J. Nuevo and Adrien Bartoli. In British Machine Vision Conference (BMVC), Bristol, UK, September 2013

KAZE Features. Pablo F. Alcantarilla, Adrien Bartoli and Andrew J. Davison. In European Conference on Computer Vision (ECCV), Fiorenze, Italy, October 2012

In case you found this elsewhere, this code lives here: https://github.com/indianajohn/akaze-rust/

Summary

The algorithm used here was heavily inspired by that repository, but differs in places. The resulting implementation produces results very similar to the original code, albeit a bit more slowly. The code in this crate is 100% safe Rust, as are most of the dependencies.

Results

This crate can be used to extract keypoints and descriptors from an image using a non-linear scale space. Keypoints Keypoints

It also includes a function to do matching with the 8-point algorithm. Matches

Example

 extern crate akaze;
 use std::path::Path;
 let options = akaze::types::evolution::Config::default();
 let (_evolutions_0, keypoints_0, descriptors_0) =
     akaze::extract_features(
       Path::new("test-data/1.jpg").to_owned(),
       options);

 let (_evolutions_1, keypoints_1, descriptors_1) =
     akaze::extract_features(
       Path::new("test-data/1.jpg").to_owned(),
       options);
 let matches = akaze::match_features(&keypoints_0, &descriptors_0, &keypoints_1, &descriptors_1);
akaze::types::feature_match::serialize_to_file(&matches, Path::new("matches.cbor").to_owned());
println!("Got {} matches.", matches.len());

Running Demonstrations

Note: These demonstrations are part of the akaze-util crate.

# All executables (and your code probably) should be run in release mode, otherwise
# these can be quite slow.
# Extraction
cargo run --release --bin extract_features -- test-data/2.jpg output.bin

# Matching
cargo run --release --bin extract_and_match -- -m matches.png test-data/1.jpg test-data/2.jpg testname

# Output visualizations of detected features and scale space to directory `visualization`.
cargo run --release --bin extract_features -- test-data/2.jpg output.bin -d visualization

License

This code is released under the MIT license. See LICENSE.md for more details. You're free to use this however you'd like.

Disclaimer

I chose to do this project to learn Rust. It's entirely possible this code does not follow what some would consider the best Rust style. Use at your own risk.

akaze-rust's People

Contributors

indianajohn avatar vadixidav avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar

Forkers

vadixidav

akaze-rust's Issues

Separate bin targets out of crate

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.

Integration into rust-cv

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.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.