Paid gig: port 2,200 lines of clean C++ to Rust


Rust needs a face detection lib. I need a face detection lib.

There’s a 2kloc C++ implementation (Seeta) that is BSD-licensed and has no third-party dependencies. I’m not great at C++, but the code seems tiny, clean, and well organized to me. Seems like a straightforward and self-contained (and fun) project.

Is anyone interested in doing this as a paid gig? Result would be BSD/MIT licensed.

C++ Source

If you want to contact me directly, my email address is

Ideas for a 3-6 month project

As @juleskers said once, don’t RIIR (needlessly).

Why would you want to convert it to Rust if it already works in C++ ? You could make a crate that calls the library instead.

I don’t want to sound too rude. I would like bindings more than something that has been rewritten.
Because if something is changed tomorrow, you don’t have to change all of your code to follow the changes.

This is my two cents, tell me if I’m wrong here.


Maybe to leverage / cargo, or to ensure memory and thread safety?


Plus, adapting the C++ library so it has a clean C API that Rust can interface with, might be almost as much work as just RIIR in the first instance!


Also it’s fun!


If the C++ library had an active maintainer or any kind of sec audit history, I’d be against RIIR, and would just write bindings.

I plan to use this in an image proxy, so unverified C++ isn’t appetizing.

A Rust version is easier to integrate with my build system, easier for me to maintain, and easier for me to audit.

AFAICT, there’s no upstream; Seeta just did a one-time code dump.


Will you be the active maintainer of rusty-face ?


if you need a maintainer. ping me :slight_smile:


I’m so sorry, I didn’t see the code wasn’t maintained!
Go for it then ! This is a perfect occasion, I will look into the code as you progress, but I don’t don’t know anything in this subject and I’m quite occupied.
This will be a cool project.


Good luck being the RIIR Police :policeman:


The C++ Seeta can be built using SSE. Is x86 your target platform as well?
And, a porting would also require some test-vectors that are known to work for the original code.


HAHA! I don’t think I can do it. Actually I was tired when I wrote that, now that I thought about it, I don’t care. People can make what they want, RIIR is just annoying for maintainers of projects that get told: “Why not convert it in Rust, it’s way better than insert language here”.

Thinking about it, I learned Rust by doing this: Taking a project of mine (done in PHP of all things) and converting it to Rust. I now have a backend for my website that can do way more things that it ever could.


Yeah true. Well it depends. It makes sense only when you see a clear advantage of writing something in Rust over another language.


Hey is a nice project!!!

are you using an existing Image processing library for Rust?


I’m thinking that I’ll eventually use this in imageflow (which focuses on server environments).

Imageflow targets x86, x86_64, x86_64 + haswell (AVX) , x86_64 + sandybridge (AVX2), so those are the targets I care the most about.

SIMD acceleration would be great. I haven’t really evaluated any crates for that, but and the standard SIMD crate seem promising.

I’m up for using any Rust crates that are reasonably safe.

As far as the timeline, within 60 days would be ideal. I’m open to the ideal of a longer deadline at lower cost - I may create a temporary C API and bindings in that case, though.


Since I’m being quoted as the “don’t RIIR” point, I’d like to add a “needlessly” in there :wink:
The quote is from a discussion about giving (massive, countless personyears) IDE’s the rust treatment. This seems to be a very well defined, small task, so my worries are similarly smaller.

Having said that, I’m not sure if it’s already the right time for face detection in Rust. Anything doing image analysis will probably want to wait for stable SIMD to land. SIMD is practically a hard requirement for performance in anything doing image processing. I didn’t check the original code, but if @frehberg says it uses SSE, I believe that qualifies…

Having it in cargo and thread safety might be very valid reasons for the use case, I can’t judge from here :slight_smile:

I AM very happy to see people willing to put their money where their mouth is on Rust. Kudos to @lilith for that!


Use in wasm could be a good reason to port it.


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 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.


I can’t commit to doing the project on my own, but if the port is open source I’d at least like to help.

I am much more familiar with C++ than Rust (much to my dismay).


Hi guys, @kornel gave me a link to this topic in response to my request for small project ideas, so I decided to give it a try. Here’s a link to github: Please disregard the pic for now, I just could not stand the temptation to make it look stylish (kinda) :slight_smile:

On the serious note, the code seems to work, but I haven’t been able to use SSE and OpenMP yet. The tests are also lacking; it should not be difficult to add ITs, which I’m going to address shortly, but creating unit tests might be a bit tricky, considering that in many cases the tested function operates on pointers and binary buffers.