Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possibility of choosing quality versus speed trade-offs to decrease frame processing times? #42

Open
mathieu-b opened this issue May 9, 2018 · 2 comments
Labels

Comments

@mathieu-b
Copy link

Hi

First of all, thanks for the great work you are doing with 4dface and all the other related libraries.

I ran the latest pre-built release and it works correctly, however the example runs at about 5 FPS.

I have the following question: what would be the best ways / parameters that could be tweaked to decrease processing times, at the expense of losing some of the accuracy?

For example:

  • would input image down-scaling help reduce times?
  • could a simpler face mesh (with less vertices) help decrease mesh fitting times?

These the specs of the machine I'm using:

  • Microsoft Windows 10 Pro
  • NVIDIA GeForce GTX 1080
  • Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz, 4001 Mhz, 4 main processors, 8 logic processors
  • 32.0 GB of RAM
  • Logitech C930e Webcam (USB 2.0, max FPS seems to be 30)

Regards

@mathieu-b mathieu-b changed the title Possibility of choosing quality versus precision trade-offs to decrease processing times? Possibility of choosing quality versus speed trade-offs to decrease processing times? May 9, 2018
@mathieu-b mathieu-b changed the title Possibility of choosing quality versus speed trade-offs to decrease processing times? Possibility of choosing quality versus speed trade-offs to decrease frame processing times? May 9, 2018
@patrikhuber
Copy link
Owner

patrikhuber commented May 23, 2018

Hi Mathieu,

Thank you very much! And apologies for the late reply.

I would suggest that you profile the code (e.g. run the Visual Studio profiler), and see in what function it spends most of the time.
From the top of my memory, the landmark detection and texture extraction would be the slow parts.
For the landmark detection, the slowest part is the HOG feature extraction. You could theoretically use a different, faster detector, like dlib. Or you could retrain an rcr-detector with fewer landmarks, so that fewer HOG features have to be extracted. I believe there's some other closed tickets either here or in the superviseddescent repo with a number of suggestions.
For the texture extraction, you could just program that in OpenGL, that would make it a lot faster. I think there's some (closed?) issues discussing this as well.

The fitting from eos, and the mesh, shouldn't be a slow-down, that should be less than 5ms per frame. If that's an issue there's some parameters that you can tune when calling the fit_shape_and_pose function but I think it'll be useless because the detector and texture extraction use up much more time.

If you're interested in a commercial solution, you could drop me an email, we're working on most of these things (or have already solved some of them).

@mathieu-b
Copy link
Author

Hi Patrik

Ok, thanks for your answer :)
Good to know that you are working on a commercial option.

Regards

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants