val.log中的PSNR值时高时低？

[One1209]

从我的val.log情况来看，为什么会出现PSNR值时高时低呢？不应该是随着迭代次数的增多，PSNR值稳步提升吗？
以下是我的val.log记录：
找了很久都没发现原因，恳请告知！

24-04-17 15:22:06.665 - INFO: <epoch: 7, iter: 10,000> psnr: 2.1367e+01
24-04-17 16:40:16.885 - INFO: <epoch: 14, iter: 20,000> psnr: 1.7173e+01
24-04-17 17:58:24.560 - INFO: <epoch: 20, iter: 30,000> psnr: 1.8179e+01
24-04-17 19:16:39.499 - INFO: <epoch: 27, iter: 40,000> psnr: 2.1871e+01
24-04-17 20:34:55.209 - INFO: <epoch: 34, iter: 50,000> psnr: 1.8104e+01
24-04-17 21:53:01.576 - INFO: <epoch: 40, iter: 60,000> psnr: 1.5948e+01
24-04-17 23:11:02.831 - INFO: <epoch: 47, iter: 70,000> psnr: 1.6152e+01
24-04-18 00:28:56.065 - INFO: <epoch: 54, iter: 80,000> psnr: 1.4302e+01
24-04-18 01:46:35.971 - INFO: <epoch: 60, iter: 90,000> psnr: 1.9275e+01
24-04-18 03:04:25.122 - INFO: <epoch: 67, iter: 100,000> psnr: 1.9152e+01
24-04-18 04:22:17.947 - INFO: <epoch: 74, iter: 110,000> psnr: 1.6359e+01
24-04-18 05:40:04.073 - INFO: <epoch: 80, iter: 120,000> psnr: 1.8555e+01
24-04-18 06:58:01.322 - INFO: <epoch: 87, iter: 130,000> psnr: 2.0622e+01
24-04-18 08:15:53.929 - INFO: <epoch: 94, iter: 140,000> psnr: 1.6522e+01
24-04-18 09:33:48.300 - INFO: <epoch:100, iter: 150,000> psnr: 1.9023e+01
24-04-18 10:51:47.212 - INFO: <epoch:107, iter: 160,000> psnr: 1.7184e+01
24-04-18 12:09:51.140 - INFO: <epoch:114, iter: 170,000> psnr: 1.9060e+01
24-04-18 13:27:48.133 - INFO: <epoch:120, iter: 180,000> psnr: 2.4105e+01
24-04-18 14:45:56.058 - INFO: <epoch:127, iter: 190,000> psnr: 1.6243e+01
24-04-18 16:03:52.822 - INFO: <epoch:134, iter: 200,000> psnr: 1.7937e+01
24-04-18 17:21:34.655 - INFO: <epoch:140, iter: 210,000> psnr: 2.1026e+01
24-04-18 18:39:27.664 - INFO: <epoch:147, iter: 220,000> psnr: 1.9718e+01
24-04-18 19:57:23.373 - INFO: <epoch:154, iter: 230,000> psnr: 1.7403e+01
24-04-18 21:15:04.094 - INFO: <epoch:160, iter: 240,000> psnr: 2.0071e+01
24-04-18 22:32:57.280 - INFO: <epoch:167, iter: 250,000> psnr: 2.0279e+01
24-04-18 23:50:52.820 - INFO: <epoch:174, iter: 260,000> psnr: 1.7413e+01
24-04-19 01:08:33.645 - INFO: <epoch:180, iter: 270,000> psnr: 1.8354e+01
24-04-19 02:26:23.701 - INFO: <epoch:187, iter: 280,000> psnr: 1.7029e+01
24-04-19 03:44:22.464 - INFO: <epoch:194, iter: 290,000> psnr: 1.7357e+01
24-04-19 05:02:08.237 - INFO: <epoch:200, iter: 300,000> psnr: 1.6554e+01
24-04-19 06:19:56.945 - INFO: <epoch:207, iter: 310,000> psnr: 1.8061e+01
24-04-19 07:37:48.817 - INFO: <epoch:214, iter: 320,000> psnr: 1.8480e+01
24-04-19 08:55:34.300 - INFO: <epoch:220, iter: 330,000> psnr: 1.9598e+01
24-04-19 10:16:14.327 - INFO: <epoch:227, iter: 340,000> psnr: 1.8503e+01
24-04-19 11:38:57.797 - INFO: <epoch:234, iter: 350,000> psnr: 1.7704e+01
24-04-19 13:01:18.061 - INFO: <epoch:240, iter: 360,000> psnr: 1.5860e+01
24-04-19 14:24:21.144 - INFO: <epoch:247, iter: 370,000> psnr: 1.7670e+01

[ranformer]

请问你找到原因了吗？我也遇到了同样的问题

[tongdaxu]

Hi @One1209 @ranformer,

This phenomena is known as perception-distortion trade-off. The output psnr is computed by E[X0|Xt, y]. In the first step, it is given by E[X0|XT, y]. Technically speaking, the optimal PSNR is given by E[X0|y], which is an average of XT~N(0,I).

It is expected that the psnr get worse as the diffusion process proceed. And theoretically, the ending PSNR should be around 3dB worse than init PSNR. So the result printed is quite normal.

For more information, see [The Perception-Distortion Tradeoff]

[Alignmentsreies]

你好,请问你是否解决？困扰了我很久,无论怎么修改代码,psnr始终很低