The default label names for the first 10 labels are (1-9). However, they should be (00, 01, ... 09). Otherwise, when dlib reads the XML files and reorders the labels in ascending order the labels get messed up. For instance, 13 labels from (0-12) are mapped like the following by dlib before training. The right column is the original label and order of the landmarks in the .XML files. The left column is how the dlib training code perceives as their order. For example, the original 10th point is mapped to the 2nd point, the original 11th to 3rd etc. This results due to the missing 0 in front of 0-9 labels.
I used 10 images as both training and testing dataset. I achieved zero MAE on both testings and training. However, the order of the landmarks was all messed up. As I was getting 0 MAE that means the problem was happening with the XML reader of the dlib training functions.
I manually added the 0s to the labels and then the training was correct.
I know I can just manually add the 0s when labelling images using the tool. However, when going for thousands of images, this is a very unnecessary waste of time. I might for now write an XML parser script that will append the zeros.
To Reproduce
Steps to reproduce the behavior:
Label a few images with the default labels. Use around 15 labels. Use the same images for training and testing.
Get zero MAE on both training and testing as we are just testing an overfitted model.
See that the correct key points were detected but the ordering of the landmarks are messed up.
Screenshots
Ground truth:
Predicted Landmarks:
But MAE was zero. So that means DLIB is reordering the landmarks after reading. And then using that sorted list as the new ground truth order of the landmarks.
This repository is currently out of maintenance due to insufficient time. Any bug, feature, or query may take longer time than expected or may lose in void.
The default label names for the first 10 labels are (1-9). However, they should be (00, 01, ... 09). Otherwise, when dlib reads the XML files and reorders the labels in ascending order the labels get messed up. For instance, 13 labels from (0-12) are mapped like the following by dlib before training. The right column is the original label and order of the landmarks in the .XML files. The left column is how the dlib training code perceives as their order. For example, the original 10th point is mapped to the 2nd point, the original 11th to 3rd etc. This results due to the missing 0 in front of 0-9 labels.
I used 10 images as both training and testing dataset. I achieved zero MAE on both testings and training. However, the order of the landmarks was all messed up. As I was getting 0 MAE that means the problem was happening with the XML reader of the dlib training functions.
I manually added the 0s to the labels and then the training was correct. I know I can just manually add the 0s when labelling images using the tool. However, when going for thousands of images, this is a very unnecessary waste of time. I might for now write an XML parser script that will append the zeros.
To Reproduce Steps to reproduce the behavior:
Screenshots Ground truth:
Predicted Landmarks:
But MAE was zero. So that means DLIB is reordering the landmarks after reading. And then using that sorted list as the new ground truth order of the landmarks.