jpg二次压缩能避免二次损失吗？
如果别人把一推jpg转成png发给了我，明知道画质一样只是体积变大了，有办法再转回jpg并避免二次损失吗？ 没有 png就是无损的吧…所以不会有损失。 png等效于bitmap加上透明通道，自带无损压缩。 3# 4# 大概没看懂lz什么意思。lz大概是好好的jpg被一个脑瘫反转成了png画质没增加还徒增体积，他现在要转回去
我觉得没有…… 不能，jpg本身自带无可挽回的信息损失，转png再转jpg相当于二压。 2020年了当然是HEIF 如果在意观感的话可以用现在的超分辨率算法帮你补一点让眼睛看得舒服的信息再压，如果是在意代表真实的信息量的话那没救了 男女平等运动服 发表于 2020-8-31 16:23
之前看到有个帖这么说
JPG图片或许也能用类似的方法还原到接近原始档案再重新压缩？ ...
引用内容写的有点，好像说了什么，但又好像什么都没说，的感觉。
jpg本身是有损压缩，原信息损失了不可能重生出来。
现有的超分辨率算法一般是通过神经网络，人工造了一些信息，使得图片分辨率提高，但这些信息也不是原来图片损失的信息。不过对于人眼可能感觉不出来有什么差别罢了。
jpg到png是无损过程，png到jpg是有损过程。不过可以把jpg质量调高，这样人眼看起来没什么区别。或者你就存着png，硬盘不缺这几M空间。
—— 来自 Xiaomi Redmi K20 Pro Premium Edition, Android 10上的 S1Next-鹅版 v2.4.1 这个问题，等于把jpg图片再进行一次jpg压缩。
— from HUAWEI DUK-AL20, Android 9 of S1 Next Goose v2.2.0 既然jpg转png这一步是无损，按理来说应该存在逆过程。 你没什么洁癖的话直接转回去就是了，参数不是太拉跨一般你不放大是看不出区别的 你这操作就是JPG压JPG，如果只是看图，你只要不手欠压什么50%，压缩率保持一致或更高，肉眼基本不可见
当然你非要从信号角度讨论这个问题就是另外一回事了…… Kaltsit 发表于 2020-9-2 21:57
既然jpg转png这一步是无损，按理来说应该存在逆过程。
png是bmp的无损压缩，因此我们以bmp为准。
jpg解压到bmp的时候，解压过程有浮点数计算，最后存在一个浮点数截断转化为整数的过程。
所以数学上可以认为损失的一些信息。但是对于同一个jpg转化出来的bmp总是一致的，所以也可以认为是没有损失。（因为不存在jpg原图，也就没有损失的概念）
Bmp压缩到新jpg的时候，同样存在浮点计算，存在量化过程，如果我们采用与解压算法相同的压缩参数，压缩出来的新jpg和原jpg应该非常一致，但很难保证数学上完全相同。（存在量化误差）
简单说，如果jpg和bmp存的都是浮点数，那么jpg到bmp就存在无损的可逆过程。但是由于计算过程中存在量化，所以正逆过程都是有损的。如果压缩参数与解压参数一致，损失应该不大，肉眼应该看不出来。
所以可以直接把png转回jpg，需要就把jpg质量调高。
最后，如果一开始生成的图像是bmp，然后压缩成jpg，bmp和jpg图片还是有差别的，尤其是在图片锐利的边缘部分。如果获得的bmp或者png，是通过jpg转化来的，那他们已经是jpg的形状了，再压缩回去也没有什么大的差距。
—— 来自 Xiaomi Redmi K20 Pro Premium Edition, Android 10上的 S1Next-鹅版 v2.4.1 jpg就是分块DCT，然后量化
你的png已经是量化之后的，分块这部分和原来的一样，DCT也和原来的一样，除了浮点误差之外应该没差别 真田源次郎信繁 发表于 2020-9-3 00:42
jpg就是分块DCT，然后量化
你的png已经是量化之后的，分块这部分和原来的一样，DCT也和原来的一样，除了浮 ...
照你这理论，只要用相同的JPEG参数，任何图迭代压缩无限次等价于压缩一次，显然不成立 转换成PDF怎么样 disrupt 发表于 2020-9-3 07:50
照你这理论，只要用相同的JPEG参数，任何图迭代压缩无限次等价于压缩一次，显然不成立 ...
理论上应该是这样。但是每次有量化误差，多次累积的结果也不太好说。
—— 来自 Xiaomi Redmi K20 Pro Premium Edition, Android 10上的 S1Next-鹅版 v2.4.1 可以的，你穷举所有jpeg参数去压缩这个png，肯定会有一组参数压出来的jpg和png完全一样 谭浩强 发表于 2020-9-3 09:24
可以的，你穷举所有jpeg参数去压缩这个png，肯定会有一组参数压出来的jpg和png完全一样 ...
这只是理论。然而事实上还是有不同编码器的算法上的差别。你不能否认有人没用主流编码器，而是魔改了一下来提高压缩率的可能性。 易恒泰上这种jpg转出来的png尤其的多
而且用png也就算了，黑白漫用8位灰度图就够了，还非要弄成24位色的
wangh 发表于 2020-9-3 21:07
易恒泰上这种jpg转出来的png尤其的多
而且用png也就算了，黑白漫用8位灰度图就够了，还非要弄成24位 ...
24位没什么好黑的。超大体积的单页，但还是扫图渣，没做后处理的到是很普遍，反正我看那个被骂大街的风啥来着的小体积和其他组的大体积，也没啥区别
—— 来自 HMD Global Nokia 7 plus, Android 9上的 S1Next-鹅版 v2.2.2.1 男女平等运动服 发表于 2020-9-3 12:17
看来我对jpg压缩的理解不对……
找到个重复压缩的测试，参数合适的话不管重复几次压缩出的jpg图片md5完全 ...
他的说法没错，最典型的案例就是电子包浆表情包发绿问题
理论的归理论，工程的归工程，软件解决这个问题的方法是Meta里做个标记，同一个工具迭代时不进行操作——很多小型图片处理软件都这么处理 男女平等运动服 发表于 2020-9-3 12:17
看来我对jpg压缩的理解不对……
找到个重复压缩的测试，参数合适的话不管重复几次压缩出的jpg图片md5完全 ...
你没仔细看吧，这个SE讨论串里面做的实验，结论是“相同参数重复压缩 许多 次后，残差 最终 会收敛到0，之后MD5就不变了”
然而这并不等于“不管重复几次”。需要很多次才收敛到0，前几次必然是有损的
21赞的回答有实例图，重复压缩8次后收敛，然而这时候画质已经很差了 男女平等运动服 发表于 2020-8-31 16:23
之前看到有个帖这么说
JPG图片或许也能用类似的方法还原到接近原始档案再重新压缩？ ...
这个只是逆向猜测拉伸算法缩回去
你要用jpg得出原始档案那是拿bd还原出母带
页:
[1]