问题描述
我使用libpng convertraw图像数据（3通道，8位，没有元数据）到PNG，并将其存储在缓冲区中。我现在有一个问题，为它写入PNG数据分配适当的缓冲区空间量。对我来说清楚的是，压缩数据可能大于原始数据（参见1x1图像的开销）
有关压缩数据大小相对于图像的上边距的一般规则大小和不同的过滤/压缩选项？如果这太泛泛，让我们假设我们使用 PNG_COLOR_TYPE_RGB，PNG_INTERLACE_NONE，PNG_COMPRESSION_TYPE_DEFAULT，PNG_FILTER_TYPE_DEFAULT
p>
PNG开销为8（签名）+ 25（IHDR）+12（第一IDAT）+12当大小超过zlib缓冲区大小（通常为8192）时，每个额外的IDAT加上12个字节.Zlib开销为6（2字节标头和4字节校验和）。放大开销是5字节加上5字节每增加32k大小。
所以图（1.02 *（3 * W + 1）* H）+68。 >
如果使用较大的Zlib缓冲区大小，您可以减小1.02因子;如果使用较小的缓冲区大小，则可以增大它。例如，使用1000000字节缓冲区大小（每个IDAT块大小为1000000字节）压缩的256x256 RGB PNG将只有一个IDAT块，总开销大约为330字节，或小于0.2％，而如果压缩它具有非常小的缓冲器大小，例如100字节，则将存在大约2000个IDAT块，并且开销将为大约12％。
参见RFC-1950，RFC -1951和RFC-2083。
I am using libpng to convertraw image data (3 channel, 8 bit, no metadata) to PNG and store it in a buffer. I now have a problem to allocate the right amount of buffer space for writing the PNG data to it. It is clear to me, that the compressed data might be larger than the raw data (cf. the overhead for a 1x1 image)Is there any general rule for an upper margin of the compressed data size with respect to the image size and the different filtering/compression options? If that is too generic, let's say we use PNG_COLOR_TYPE_RGB, PNG_INTERLACE_NONE, PNG_COMPRESSION_TYPE_DEFAULT, PNG_FILTER_TYPE_DEFAULT.
Thank you
PNG overhead is 8 (signature) + 25 (IHDR) +12 (first IDAT) + 12 (IEND) plus 1 byte per row (filter byte), plus 12 bytes per additional IDAT when the size exceeds the zlib buffer size which is typically 8192. Zlib overhead is 6 (2-byte header and 4-byte checksum). Deflate overhead is 5 bytes plus 5 bytes per additional 32k in size.
So figure (1.02 * (3*W+1) * H) + 68.
You can decrease the 1.02 factor if you use a larger Zlib buffer size or increase it if you use a smaller buffer size. For example, a 256x256 RGB PNG compressed with a 1000000-byte buffer size (1000000 bytes per IDAT chunk) will have only one IDAT chunk and the total overhead will be around 330 bytes, or less than .2 percent, while if you compress it with a very small buffer size, for example 100 bytes, then there will be around 2000 IDAT chunks and the overhead will be about twelve percent.
See RFC-1950, RFC-1951, and RFC-2083.
这篇关于最差的PNG压缩场景的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！