Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarification on "filter_palette_zero" #187

Open
MasterInQuestion opened this issue Mar 18, 2024 · 0 comments
Open

Clarification on "filter_palette_zero" #187

MasterInQuestion opened this issue Mar 18, 2024 · 0 comments

Comments

@MasterInQuestion
Copy link

    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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant