好的,所以我尝试使用imagemagick命令:
"convert picA.png -interlace line picB.png"
制作我的.png图片的隔行扫描版本。大多数时候,我得到的结果图像比原始图像大,这有点正常。但是,在某些图像上,生成的图像尺寸较小。
所以我想知道为什么会这样?我真的不希望我的新图像由于命令而失去任何质量。
此外,隔行扫描.png图像是否存在兼容性问题?
编辑:我想我的问题是原始图像没有尽可能好地压缩。
答案 0 :(得分:2)
以下内容仅适用于像素大小> = 8位的情况。我没有调查其他案件,但我希望得到类似的结果。
内容相同的隔行扫描的PNG图像文件几乎总是会更大,这是因为需要额外的数据来处理通过扫描线的过滤器类型描述。这是我根据PNG RFC this web page在RFC2083中详细解释的内容。 简而言之,这是因为以下每个隔行扫描隔行扫描类型描述的字节数之和几乎总是大于图像高度(这是非隔行图像的过滤类型数):
nb_pass1_lines = CEIL(height/8)
nb_pass2_lines = (width>4?CEIL(height/8):0)
nb_pass3_lines = CEIL((height-4)/8)
nb_pass4_lines = (width>2?CEIL(height/4):0)
nb_pass5_lines = CEIL((height-2)/4)
nb_pass6_lines = (width>1?CEIL(height/2):0)
nb_pass7_lines = FLOOR(height/2)
尽管,从理论上讲,可能是{strong>偶然地降低了数据的熵/复杂度,因此Adam7 interlacing使得通常是可以通过用于PNG格式的deflate compression来补偿隔行滤波器类型所需的额外空间。这将是一个特殊的情况,因为通过隔行解构可以使图像数据的一致性降低,因此随着隔行扫描,熵/复杂度可能会增加。
我使用“偶然”一词是因为降低数据熵/复杂度并不是Adam7隔行扫描的目的。其目的是允许通过传递机制逐步加载和显示图像。而降低熵/复杂度是PNG filtering的目的。
我使用“通常”一词是因为,例如explanation web page中所示,无论是否隔行,都将通过相同长度的未压缩数据来描述1像素图像。因此,在这种情况下,不需要额外的空间。
当涉及到PNG文件大小时,隔行扫描的大小可能由于以下原因导致:
如果必须检查2个PNG图像文件是否等效像素,我将在bash提示符中使用以下命令:
diff <( convert non-interlaced.png rgba:- ) <( convert interlaced.png rgba:- )
应该没有任何区别。
对于兼容性问题,如果PNG编码器和PNG解码器实现了PNG RFC的强制性规定,那么我认为隔行扫描没有理由导致兼容性问题。
编辑2018年11月13日:
此处解释了一些基于具有小生境机制(驻留在https://en.oga.jod.li上的自动进化的分布式遗传算法的实验): https://jod.li/2018/11/13/can-an-interlaced-png-image-be-smaller-than-the-equivalent-non-interlaced-image/
这些实验表明,等效PNG图像的隔行扫描尺寸可能比非隔行扫描图像小。最好的图像是高图像,它们具有一个像素的宽度,并且具有随机出现的像素内容。但是,形状并不是隔行图像要比非隔行图像小的唯一重要方面,因为具有相同形状的随机情况会导致大小差异不同。
是的,有些PNG图像在像素方面可以相同,并且与非像素相关,但是隔行扫描的大小要小于非隔行扫描的大小。
答案 1 :(得分:1)
所以我想知道为什么会这样?
来自PNG规范的Interlacing and pass extraction部分。
未完全填充整数字节的扫描线按照7.2: Scanlines中的定义进行填充。
注意如果参考图像包含少于五列或少于五行,则某些过程将为空。
我认为您遇到的行为是Adam7 method需要额外填充的结果。