You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note there are some malapropos ideas in the PNG book.
Notably:
"So how does an encoder actually choose the proper filter for each row? Testing all possible combinations is clearly impossible: ..."
<^> It's actually suggested by the PNG standard as the optimal optimization method...
If speed is not of primary concern.
.
"The first rule is that filters are rarely useful on palette images, so don't even bother with them."
<^> No filtering does not necessarily cause best compression in such cases. (mere mostly)
It's mostly as a performance optimization.
.
"The theory, to some extent based on empirical evidence, is that switching filters too often can have a deleterious effect on the main compression engine."
<^> Data, are no more than data. It is all upon: the interpretation.
For any proper general purpose compressor, this shouldn't make a difference.
.
“In particular, you cannot treat color values and transparency values as if they are separate, unrelated entities.
Attempting to partition the palette into a "color part" and a "transparent part":
Makes no more sense, than attempting to partition a standard RGB palette into: red, green, and blue parts.”
<^> https://www.awaresystems.be/imaging/tiff/tifftags/planarconfiguration.html https://gist.github.com/Jim-Bar/3cbba684a71d1a9d468a6711a6eddbeb#packed-planar-and-semi-planar
Planar in certain cases may be noticeably more compressible than Packed.
(the opposite may occur too, much dependent on the input)
The text was updated successfully, but these errors were encountered:
For Palette images and those of < 8bpc (bit-depth per component):
https://github.com/lvandeve/lodepng/blob/87032dd9c379892e08bba71c647bdaca793aee3c/lodepng.cpp#L5914-L5928
https://github.com/lvandeve/lodepng/blob/87032dd9c379892e08bba71c647bdaca793aee3c/lodepng.h#L823-L827
The PNG standard didn't suggest so:
https://www.w3.org/TR/png/#12Filter-selection
; it's suggested by the "libpng" book...
http://www.libpng.org/pub/png/book/chapter09.html#INDEX-682
Note there are some malapropos ideas in the PNG book.
Notably:
"So how does an encoder actually choose the proper filter for each row? Testing all possible combinations is clearly impossible: ..."
<^> It's actually suggested by the PNG standard as the optimal optimization method...
If speed is not of primary concern.
.
"The first rule is that filters are rarely useful on palette images, so don't even bother with them."
<^> No filtering does not necessarily cause best compression in such cases. (mere mostly)
It's mostly as a performance optimization.
.
"The theory, to some extent based on empirical evidence, is that switching filters too often can have a deleterious effect on the main compression engine."
<^> Data, are no more than data. It is all upon: the interpretation.
For any proper general purpose compressor, this shouldn't make a difference.
.
“In particular, you cannot treat color values and transparency values as if they are separate, unrelated entities.
Attempting to partition the palette into a "color part" and a "transparent part":
Makes no more sense, than attempting to partition a standard RGB palette into: red, green, and blue parts.”
<^> https://www.awaresystems.be/imaging/tiff/tifftags/planarconfiguration.html
https://gist.github.com/Jim-Bar/3cbba684a71d1a9d468a6711a6eddbeb#packed-planar-and-semi-planar
Planar in certain cases may be noticeably more compressible than Packed.
(the opposite may occur too, much dependent on the input)
The text was updated successfully, but these errors were encountered: