faceswap-playground
faceswap-playground copied to clipboard
deepfakes
alignments tool doesn't handle case and filenames correctly in Windows.
I used the tool to draw the landmarks without re-extracting, but it seems to ignore some of the pics in the file.
Step to reproduce:
- Extract faces from a folder with s3fd detector -> result = 998 faces in aligned dir and an alignments file.
- Just after (not changing or deleting any pic): feed alignments file + both folders to "draw" tool.
- Result: 827 faces with landmarks drawn?!?
Expected result: all 998 faces with landmarks drawn. I expect that if a face is present in the aligned dir and in the alignments file, it should be possible to draw the landmarks!
I tried with mtcnn extractor: it finds 991 faces. alignments tool draws... 827 faces, again.
I tried the "extract" tool from the "Aligments" tab too, which is supposed to re-extract the faces quicker, but it gives me the same result again : 827 faces, even though s3fd found 998 and mtcnn 991.
Just to be sure, I re-re-extracted the faces with the Extract tab, this time with "Debug Landmarks" checked (which by the way, are different than the ones generated by the alignments tool), and it drew all the landmarks, with red dots, correctly.
It looks like, for some reason, the tool ignores some of the landmarks. I looked at the pics it ignores: they are nothing special. They are even easy detects.
It still rewrites them as-is in the copy of the alignment.json file it generates though.
Example:
I singled out a pic which is ignored in a json file by itself:
{
"200201241849714_0.JPG": [
{
"x": 46,
"w": 162,
"y": 2,
"h": 231,
"landmarksXY": [
[
40,
91
],
[
40,
116
],
[
43,
138
],
[
46,
160
],
[
56,
182
],
[
68,
201
],
[
81,
211
],
[
97,
223
],
[
122,
233
],
[
147,
223
],
[
163,
211
],
[
175,
201
],
[
188,
182
],
[
197,
160
],
[
204,
138
],
[
207,
116
],
[
207,
91
],
[
52,
59
],
[
62,
50
],
[
78,
44
],
[
90,
47
],
[
100,
50
],
[
150,
50
],
[
160,
47
],
[
172,
47
],
[
188,
50
],
[
194,
63
],
[
125,
81
],
[
128,
97
],
[
128,
113
],
[
128,
125
],
[
112,
141
],
[
119,
141
],
[
125,
144
],
[
134,
144
],
[
141,
141
],
[
68,
85
],
[
78,
78
],
[
90,
78
],
[
100,
85
],
[
90,
88
],
[
78,
88
],
[
150,
85
],
[
160,
78
],
[
172,
78
],
[
178,
85
],
[
169,
91
],
[
160,
88
],
[
93,
179
],
[
106,
173
],
[
119,
170
],
[
125,
170
],
[
131,
170
],
[
147,
173
],
[
156,
176
],
[
144,
185
],
[
134,
188
],
[
125,
192
],
[
112,
192
],
[
103,
185
],
[
93,
179
],
[
115,
176
],
[
125,
176
],
[
134,
176
],
[
153,
176
],
[
134,
179
],
[
125,
179
],
[
115,
179
]
],
"hash": "39a871e366c7288ef6814e49e7475ea546e052cf"
}
]
}
Result in TRACE mode:
Loading...
Please backup your data and/or test the tool you want to use with a smaller data set to make sure you understand how it works.
05/31/2019 13:07:34 INFO Log level set to: TRACE
05/31/2019 13:07:34 INFO [ALIGNMENT DATA]
05/31/2019 13:07:34 VERBOSE Alignments file exists at 'C:\Fakes\test\al.json'
05/31/2019 13:07:34 VERBOSE Using 'json' serializer for alignments
05/31/2019 13:07:34 VERBOSE Alignments filepath: 'C:\Fakes\test\al.json'
05/31/2019 13:07:34 INFO Reading alignments from: 'C:\Fakes\test\al.json'
Drawing landmarks: 0it [00:00, ?it/s]05/31/2019 13:07:34 VERBOSE Destination format set to 'json'
05/31/2019 13:07:34 VERBOSE Using 'json' serializer for alignments
05/31/2019 13:07:34 VERBOSE 1 items loaded
05/31/2019 13:07:34 INFO [FRAMES DATA]
05/31/2019 13:07:34 VERBOSE Folder exists at 'C:\Fakes\test'
05/31/2019 13:07:34 INFO Loading file list from C:\Fakes\test
05/31/2019 13:07:34 VERBOSE 0 items loaded
05/31/2019 13:07:34 INFO [DRAW LANDMARKS]
05/31/2019 13:07:34 INFO 0 Frame(s) output
The "05/31/2019 13:07:34 VERBOSE 0 items loaded" is odd.
IMO, this is a bug.
LOL.
Just after posting this, I had a sudden inspiration, and changed the extension in both json and the file name from JPG to jpg:
09 INFO Loading file list from C:\Fakes\test
05/31/2019 13:21:09 VERBOSE 1 items loaded
05/31/2019 13:21:09 INFO [DRAW LANDMARKS]
05/31/2019 13:21:09 INFO 1 Frame(s) output
Process exited.
Soooo... it's still a bug, but I know the reason now: the alignment tool doesn't handle uppercase extensions on Windows.
New bug:
The manual alignments mode doesn't handle spaces or parenthesis?
The pic appears, but the box on top is black and when trying to modify:
Traceback (most recent call last):
File "C:\Users\Kirin\faceswap\tools\lib_alignments\jobs_manual.py", line 842, in on_event
self.set_bounding_box(x, y)
File "C:\Users\Kirin\faceswap\tools\lib_alignments\jobs_manual.py", line 877, in set_bounding_box
self.move_bounding_box(pt_x, pt_y)
File "C:\Users\Kirin\faceswap\tools\lib_alignments\jobs_manual.py", line 926, in move_bounding_box
self.update_landmarks()
File "C:\Users\Kirin\faceswap\tools\lib_alignments\jobs_manual.py", line 972, in update_landmarks
idx = self.alignments.add_face(frame, alignment)
File "C:\Users\Kirin\faceswap\lib\alignments.py", line 224, in add_face
self.data[frame].append(alignment)
KeyError: '00144 - Copie (2)_0.png'
KeyError suggests it doesn't like the filename.
The filename extension issue is fixed in latest commit. I'll look at Manual over the weekend.
The manual alignments mode doesn't handle spaces or parenthesis?
I can't recreate this at all. I changed my filenames to have spaces, dashes and parenthesis but it still works for me
sample filenames:
