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

shape_predictor: allow dpoint as training input #2183

Open
ejoebstl opened this issue Sep 18, 2020 · 8 comments
Open

shape_predictor: allow dpoint as training input #2183

ejoebstl opened this issue Sep 18, 2020 · 8 comments

Comments

@ejoebstl
Copy link

ejoebstl commented Sep 18, 2020

Currently, the shape predictor training example showcases how to provide training and test data using integer coordinates.

Hoever, I would like to train a shape predictor using float coordinate pairs. I hope to gain increased precision by doing so. Since the shape predictor is also giving float numbers as output, I would assume that this should be possible.

However, there is no documentation to be found on the input format.

I'm happy to extend the documentation as soon as I know how this works.

@davisking
Copy link
Owner

This isn't supported by the current API. There isn't any particularly good reason, it's just how the code is setup. It could use floating point coordinates. I am somewhat skeptical that someone can label landmarks to sub-pixel accuracy though. Do you really have a problem domain where humans, or whatever it is that generates the labels, somehow really knows the location of the landmarks to sub-pixel accuracy?

@ejoebstl
Copy link
Author

Thanks for getting back.

I am using this dataset, which supplies float coordinates. The images are quite small, therefore I assumed it might make a difference.

@davisking
Copy link
Owner

davisking commented Sep 21, 2020 via email

@ejoebstl ejoebstl changed the title [Documentation] Document shape_predictor training input shape_predictor: allow dpoint as training input Oct 16, 2020
@dlib-issue-bot
Copy link
Collaborator

Warning: this issue has been inactive for 35 days and will be automatically closed on 2020-11-30 if there is no further activity.

If you are waiting for a response but haven't received one it's possible your question is somehow inappropriate. E.g. it is off topic, you didn't follow the issue submission instructions, or your question is easily answerable by reading the FAQ, dlib's official compilation instructions, dlib's API documentation, or a Google search.

@dlib-issue-bot
Copy link
Collaborator

Warning: this issue has been inactive for 43 days and will be automatically closed on 2020-11-30 if there is no further activity.

If you are waiting for a response but haven't received one it's possible your question is somehow inappropriate. E.g. it is off topic, you didn't follow the issue submission instructions, or your question is easily answerable by reading the FAQ, dlib's official compilation instructions, dlib's API documentation, or a Google search.

@dlib-issue-bot
Copy link
Collaborator

Notice: this issue has been closed because it has been inactive for 45 days. You may reopen this issue if it has been closed in error.

@guilbut
Copy link

guilbut commented May 21, 2021

Hi !
I am developing a software for which I need sub-pixel tracking with coordinates of points in float. Unfortunately the float rounding at the output of the shape predictor causes a jitter that is far too important for my needs. For the learning I have a database annotated very precisely with a sub-pixel accuracy (maybe at 1/4 of pixels). I managed to give numpy matrices with floats as input (hoping they are not truncated internally ), but the shape predictor seems to only output integer points, contrary to the statement of "Since the shape predictor is also giving float numbers as output".
I unfortunately don't have the level in C ++ to do the modification cleanly and to offer a pool request. Does one of you two already tried to start modifying the code to allow dpoint as input to the training and as output of the predictor?
Thanks !

@davisking
Copy link
Owner

Yeah this would be a reasonable thing to upgrade. If someone wants to go replace point with dpoint in the right places and make any necessary attendant adjustments that would be cool. It has to be done in a way that's backwards compatible with old code, but that shouldn't be hard though.

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

No branches or pull requests

4 participants