I hear you about timing. I started imageflow way too early in Rust’s development, and it bit me harder than I can politely describe. But this seems comparatively simple.
I’m OK with requiring a nightly compiler, and I can move it over to stable once it’s practical.
A few more notes:
I’m also OK with depending on pre-1.0 third party crates, as long as they are “reasonably safe” - i.e., the scope of thier unsafe bits is easy to verify. SIMD crates would qualify, for example, as they don’t (AFAICT) corrupt lifetimes.
Documentation can be minimal - I would want unexpected and non-obvious things documented. It’s a simple interface.
For testing, pairs of images and result rectangles should be fine. (i.e, we can generate a CSV based on the C++ code and compare it to the rust CSV).
There are many good image sets, but http://mmlab.ie.cuhk.edu.hk/projects/WIDERFace/ seems the most diverse.
The budget is $1,500 USD (most bids have been under this amount anyway).
My suggestion would be to expose a 1 or 2 method C API and bind it so that Rust test code can be reused.
If the bound API is usably functional, then the timeline can be 90 days instead of 60. If the developer is uncomfortable with binding C I can make them.