这个欧拉角度计算是不是有问题啊

[lucaslu1987]

误差非常大

[luckynote]

误差非常大

确实有问题，不过还是可以得到一版不错的模型，正在尝试改这段代码

[guoqiangqi]

当时偷懒欧拉角计算代码直接用了开源的代码，我在自己环境下测试了dlib的68关键点计算的还好，单位是degree，不是rad，是这个问题吗。

[lucaslu1987]

你的代码 euler_angles_landmark = [] for index in TRACKED_POINTS: euler_angles_landmark.append(lanmark[index]) euler_angles_landmark = np.asarray(euler_angles_landmark).reshape((-1, 28)) pitch, yaw, roll = calculate_pitch_yaw_roll(euler_angles_landmark[0]) 调用calculate_pitch_yaw_roll函数没有指定图像宽高，默认是256，而我们训练数据是112，这样算出来不是错的么。

[guoqiangqi]

你改成112误差还大吗？

[lucaslu1987]

你改成112误差还大吗？

我用另外一种5个点的建模方式，感觉那个更准。

[zhunge]

你改成112误差还大吗？

我用另外一种5个点的建模方式，感觉那个更准。

你用的哪种5个点的建模方式？

[lucaslu1987]

你改成112误差还大吗？

我用另外一种5个点的建模方式，感觉那个更准。

你用的哪种5个点的建模方式？

可以参考https://github.com/yinguobing/head-pose-estimation， 简单测了几张，肉眼感觉更准。特别是仰俯角，不过对整体训练应该影响不大

[zhen8838]

作者好，我对欧拉角计算也有疑问，不角度转换为弧度制的话，1-tf.cos在-180~180是周期函数了，不是线性增加的函数了，是不是应该把角度转换下？

还有一个问题就是attributes_w_n，这个是按照batch中的类别均值来计算的，但是如果batch比较小的情况下，就会出现某几个样本权重为0的情况，比如我取batch为16时：

attributes_w_n [2. , 2.,  5.2, 0.,  0.,  0.,  8.,  5.2, 8.,  2.,  2.,  3.2, 5.2, 0.,  2.,  3.2]

这个情况是不是不期望出现的？需要batch较大才好？

感谢开源代码，希望作者大大能回复下 :)

[guoqiangqi]

1-tf.cos(pre-gt)函数能保证训练收敛，使得pre-gt=0+2*pi，转换不转换影响应该不大。

425418567@qq.com

发件人： 郑启航 发送时间： 2019-08-23 21:36 收件人： guoqiangqi/PFLD 抄送： Guoqiang QI; Comment 主题： Re: [guoqiangqi/PFLD] 这个欧拉角度计算是不是有问题啊 (#42) 作者好，我对欧拉角计算也有疑问，不角度转换为弧度制的话，1-tf.cos在-180~180是周期函数了，不是线性增加的函数了，是不是应该把角度转换下？ 还有一个问题就是attributes_w_n，这个是按照batch中的类别均值来计算的，但是如果batch比较小的情况下，就会出现某几个样本权重为0的情况，比如我取batch为16时： attributes_w_n [2. , 2., 5.2, 0., 0., 0., 8., 5.2, 8., 2., 2., 3.2, 5.2, 0., 2., 3.2] 这个情况是不是不期望出现的？需要batch较大才好？ 感谢开源代码，希望作者大大能回复下 :) — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[guoqiangqi]

正常来说是batch越大越好，数据的分布随机性越低，但是由于wflw的属性标注存在全为0的情况，大batch也会出现，在bp中属性全为0时的样本就不参与训练。

425418567@qq.com

发件人： 郑启航 发送时间： 2019-08-23 21:36 收件人： guoqiangqi/PFLD 抄送： Guoqiang QI; Comment 主题： Re: [guoqiangqi/PFLD] 这个欧拉角度计算是不是有问题啊 (#42) 作者好，我对欧拉角计算也有疑问，不角度转换为弧度制的话，1-tf.cos在-180~180是周期函数了，不是线性增加的函数了，是不是应该把角度转换下？ 还有一个问题就是attributes_w_n，这个是按照batch中的类别均值来计算的，但是如果batch比较小的情况下，就会出现某几个样本权重为0的情况，比如我取batch为16时： attributes_w_n [2. , 2., 5.2, 0., 0., 0., 8., 5.2, 8., 2., 2., 3.2, 5.2, 0., 2., 3.2] 这个情况是不是不期望出现的？需要batch较大才好？ 感谢开源代码，希望作者大大能回复下 :) ― You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[zhen8838]

十分感谢回复！

[lucaslu1987]

1-tf.cos(pre-gt)函数能保证训练收敛，使得pre-gt=0+2*pi，转换不转换影响应该不大。 425418567@qq.com 发件人： 郑启航 发送时间： 2019-08-23 21:36 收件人： guoqiangqi/PFLD 抄送： Guoqiang QI; Comment 主题： Re: [guoqiangqi/PFLD] 这个欧拉角度计算是不是有问题啊 (#42) 作者好，我对欧拉角计算也有疑问，不角度转换为弧度制的话，1-tf.cos在-180~180是周期函数了，不是线性增加的函数了，是不是应该把角度转换下？ 还有一个问题就是attributes_w_n，这个是按照batch中的类别均值来计算的，但是如果batch比较小的情况下，就会出现某几个样本权重为0的情况，比如我取batch为16时： attributes_w_n [2. , 2., 5.2, 0., 0., 0., 8., 5.2, 8., 2., 2., 3.2, 5.2, 0., 2., 3.2] 这个情况是不是不期望出现的？需要batch较大才好？ 感谢开源代码，希望作者大大能回复下 :) — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

还想问一下，在做数据增强的时候，为什么特征点超过（0，1）范围的脸舍去，这样实际应用的时候会不会有问题啊

[github-luffy]

euler_angles_landmark = np.asarray(euler_angles_landmark).reshape((-1, 28))这句代码应该有问题吧，改成：euler_angles_landmark = np.asarray(euler_angles_landmark).transpose((1, 0, 2)).reshape((-1, 28))

[guoqiangqi]

1-tf.cos(pre-gt)函数能保证训练收敛，使得pre-gt=0+2*pi，转换不转换影响应该不大。 425418567@qq.com 发件人： 郑启航 发送时间： 2019-08-23 21:36 收件人： guoqiangqi/PFLD 抄送： Guoqiang QI; Comment 主题： Re: [guoqiangqi/PFLD] 这个欧拉角度计算是不是有问题啊 (#42) 作者好，我对欧拉角计算也有疑问，不角度转换为弧度制的话，1-tf.cos在-180~180是周期函数了，不是线性增加的函数了，是不是应该把角度转换下？ 还有一个问题就是attributes_w_n，这个是按照batch中的类别均值来计算的，但是如果batch比较小的情况下，就会出现某几个样本权重为0的情况，比如我取batch为16时： attributes_w_n [2. , 2., 5.2, 0., 0., 0., 8., 5.2, 8., 2., 2., 3.2, 5.2, 0., 2., 3.2] 这个情况是不是不期望出现的？需要batch较大才好？ 感谢开源代码，希望作者大大能回复下 :) — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

还想问一下，在做数据增强的时候，为什么特征点超过（0，1）范围的脸舍去，这样实际应用的时候会不会有问题啊

特征点都是归一化的正常情况是不会出现超过（0，1），这个是之前有用其他数据集，它标注质量比较差，所以做了个判断。

[guoqiangqi]

euler_angles_landmark = np.asarray(euler_angles_landmark).reshape((-1, 28))这句代码应该有问题吧，改成：euler_angles_landmark = np.asarray(euler_angles_landmark).transpose((1, 0, 2)).reshape((-1, 28))

有什么问题呢，我没怎么明白为什么要transpose

[github-luffy]

-1表示样本数，即batchsize大小，28应该是一个样本的十四个点（28个数字），但是不加transpose，十四个点好像是没对上的，你可以打印出来看看。

[guoqiangqi]

28是98个点取出来的14个点的坐标，可能是取点时没对上，我找时间确认下哈。

425418567@qq.com

发件人： 叶修强 发送时间： 2019-08-26 14:17 收件人： guoqiangqi/PFLD 抄送： Guoqiang QI; Comment 主题： Re: [guoqiangqi/PFLD] 这个欧拉角度计算是不是有问题啊 (#42) -1表示样本数，即batchsize大小，28应该是一个样本的十四个点（28个数字），但是不加transpose，十四个点好像是没对上的，你可以打印出来看看。 — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[guoqiangqi]

哦哦，我想起来了，我用的欧拉角的计算代码是在dlib中68点找14个点，所以我在wflw中找了14个与dlib比较接近的点，所以可能无法完全对应。

425418567@qq.com

发件人： 叶修强 发送时间： 2019-08-26 14:17 收件人： guoqiangqi/PFLD 抄送： Guoqiang QI; Comment 主题： Re: [guoqiangqi/PFLD] 这个欧拉角度计算是不是有问题啊 (#42) -1表示样本数，即batchsize大小，28应该是一个样本的十四个点（28个数字），但是不加transpose，十四个点好像是没对上的，你可以打印出来看看。 — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[luckynote]

应该不是这个问题，我在68点上计算euler角也是存在问题对

---原始邮件--- 发件人: "Guoqiang QI"notifications@github.com 发送时间: 2019年8月26日(星期一) 下午2:33 收件人: "guoqiangqi/PFLD"PFLD@noreply.github.com; 抄送: "luckynote"1550272577@qq.com;"Comment"comment@noreply.github.com; 主题: Re: [guoqiangqi/PFLD] 这个欧拉角度计算是不是有问题啊 (#42)

哦哦，我想起来了，我用的欧拉角的计算代码是在dlib中68点找14个点，所以我在wflw中找了14个与dlib比较接近的点，所以可能无法完全对应。

425418567@qq.com

发件人： 叶修强 发送时间： 2019-08-26 14:17 收件人： guoqiangqi/PFLD 抄送： Guoqiang QI; Comment 主题： Re: [guoqiangqi/PFLD] 这个欧拉角度计算是不是有问题啊 (#42) -1表示样本数，即batchsize大小，28应该是一个样本的十四个点（28个数字），但是不加transpose，十四个点好像是没对上的，你可以打印出来看看。 — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[github-luffy]

14个点不是从98个点或者68个点取的不对，而是在这些样本中没对上，例如第一行的28个数字是：第一张的第一个点，第二张图的第一个点，第三张图的第一个点。。。。。。依次往下类推，我打印出来看的，你们可以试试。

[luckynote]

@github-luffy 你说的是对的　@guoqiangqi 计算euler角需要用当前图片大小的真实坐标，但我们代码中却依旧使用的归一化landmark坐标，导致错误计算。需要修正如下： euler_angles_landmark.append([lanmark[index][0]*img.shape[0],lanmark[index][1]*img.shape[1]])

[guoqiangqi]

嗯嗯，确实是，但是之前提到的“第一行的28个数字是：第一张的第一个点，第二张图的第一个点，第三张图的第一个点”的问题存在吗？

425418567@qq.com

发件人： luckynote 发送时间： 2019-08-26 15:38 收件人： guoqiangqi/PFLD 抄送： Guoqiang QI; Mention 主题： Re: [guoqiangqi/PFLD] 这个欧拉角度计算是不是有问题啊 (#42) @github-luffy 你说的是对的　@guoqiangqi 计算euler角需要用当前图片大小的真实坐标，但我们代码中却依旧使用的归一化landmark坐标，导致错误计算。需要修正如下： euler_angles_landmark.append([lanmark[index][0]img.shape[0],lanmark[index][1]img.shape[1]]) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[luckynote]

嗯嗯，确实是，但是之前提到的“第一行的28个数字是：第一张的第一个点，第二张图的第一个点，第三张图的第一个点”的问题存在吗？ 425418567@qq.com 发件人： luckynote 发送时间： 2019-08-26 15:38 收件人： guoqiangqi/PFLD 抄送： Guoqiang QI; Mention 主题： Re: [guoqiangqi/PFLD] 这个欧拉角度计算是不是有问题啊 (#42) @github-luffy 你说的是对的　@guoqiangqi 计算euler角需要用当前图片大小的真实坐标，但我们代码中却依旧使用的归一化landmark坐标，导致错误计算。需要修正如下： euler_angles_landmark.append([lanmark[index][0]img.shape[0],lanmark[index][1]img.shape[1]]) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

按照我的修改，没有这个问题

[guoqiangqi]

嗯嗯，确实是，但是之前提到的“第一行的28个数字是：第一张的第一个点，第二张图的第一个点，第三张图的第一个点”的问题存在吗？ 425418567@qq.com 发件人： luckynote 发送时间： 2019-08-26 15:38 收件人： guoqiangqi/PFLD 抄送： Guoqiang QI; Mention 主题： Re: [guoqiangqi/PFLD] 这个欧拉角度计算是不是有问题啊 (#42) @github-luffy 你说的是对的　@guoqiangqi 计算euler角需要用当前图片大小的真实坐标，但我们代码中却依旧使用的归一化landmark坐标，导致错误计算。需要修正如下： euler_angles_landmark.append([lanmark[index][0]img.shape[0],lanmark[index][1]img.shape[1]]) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

按照我的修改，没有这个问题

点赞。