-
Notifications
You must be signed in to change notification settings - Fork 359
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
Bad projection ? #30
Comments
I have a similar question. The
According to the PyTorch bmm Doc, the bmm will multiply the Not hundred percent sure. |
@ericryanchan also found the question about projection |
Also the same problem, and I changed the projection to [xy, xz, yz] with the following code:
After that, the visual quality of the image appears to have deteriorated instead. Both images are generated at 201kimg (Top: Official version, Bottom: Changed version) |
Hey, I met similar deteriorated results as your top image shown. Did you strictly preprocess the FFHQ according to the given script? From my experience, if you use the original well-cropped FFHQ, the training results will be like the top image. I can confirm it is caused by the mismatch between the camera pose and face images since I've got the expected training results after re-cropping. I think you can try to re-crop the images from FFHQ in-the-wild images first, then train the model with the changed projection code to see if it works. BTW, if you cannot process all the images (70k in total), you can choose to make up a subset, say 5k images. Please let me know If you have some updates, thank you. |
Hi @bd20222 , Thanks for your kind advice, I used the same dataset as the official version, which is got by sending an email to Eric. After training for a longer time, the model seems to generate much better results. I do not have many ideas about the scenario. Personally, I think it might be induced by different initializations. I also attached the generated images below for your kind perusal. As for the projection, I think both strategies should work, as they both include different coordinates, even though the original result is [xy, xz, zx], it did include the z-coordinate. But I think the revised version might align with the strategy mentioned in the paper and my intuition. Best regards, |
Cool, mine is at 2400kimg, but I used a subset of FFHQ to train. (~5K training images). Have a nice day. : ) |
Please see the relevant post here: #67 |
Hello,
I have notice something strange in the definition of "generate_planes" and "project_onto_planes". If I have well understood, you define three transfer matrices in "generate_planes" that are used to project coordinates in "project_onto_planes" before to keep only the first two coordinates of your projection.
Problem:
If we set P=coordinates[0][0], since out[:3,0,:] is the projection, it is supposed to return:
[P[0], P[1]]
[P[1], P[2]]
[P[2], P[0]]
However, I got:
[P[0], P[1]]
[P[0], P[2]]
[P[2], P[0]]
If you prefer, I have: [(X,Y), (X,Z), (Z,X)]
Reason:
If I am right, I have found the reason. You defined planes by the following matrices:
[[1, 0, 0],[0, 1, 0],[0, 0, 1]]
[[1, 0, 0],[0, 0, 1],[0, 1, 0]]
[[0, 0, 1],[1, 0, 0],[0, 1, 0]]
Let us call the matrices M1, M2 and M3. Their inverts are:
If I have a point P=(X,Y,Z), I got:
P @ M1^{-1} = (X,Y,Z)
P @ M2^{-1} = (X,Z,Y)
P @ M3^{-1} = (Z,X,Y)
Then, if I keep only the two coordinates, I have: [(X,Y), (X,Z), (Z,X)]
Possible solution:
Update "generate_planes" to:
Do not hesitate to tell me if I am misunderstanding something.
The text was updated successfully, but these errors were encountered: