-
Notifications
You must be signed in to change notification settings - Fork 124
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
Implement possible size optimizations from Palette sorting from TruePNG #74
Labels
I-Medium
Issues that are breaking core functionality, but have a known workaround
T-Compression
Relates to improving the compression ratio of images
T-Feature
Requests for a new feature to be added
T-Needs Tests
Comments
7 tasks
shssoichiro
added
T-Needs Tests
T-Feature
Requests for a new feature to be added
labels
Jul 21, 2017
shssoichiro
added
the
I-Medium
Issues that are breaking core functionality, but have a known workaround
label
Oct 1, 2017
shssoichiro
added
the
T-Compression
Relates to improving the compression ratio of images
label
Dec 12, 2018
shssoichiro
pushed a commit
that referenced
this issue
Jul 11, 2023
This adds a new palette sorting algorithm that attempts to minimise entropy by an approximate solution to the Traveling Salesman Problem. The algorithm comes from "An efficient Re-indexing algorithm for color-mapped images" by Battiato et al (https://ieeexplore.ieee.org/document/1344033). It's fast and effective and works in addition to the luma sort (which remains the single most effective sort). In order to keep lower presets fast though, I've only enabled this for o3 and higher. Results on a set of 190 indexed images at `-o5`: 18,932,727 bytes - master 18,578,306 bytes - PR 18,559,863 bytes - PR + #509 (These images may be particularly suited to alternative sorting methods - the gains here are not necessarily what should be expected on average) Note I looked into the 120 different palette sorting methods from TruePNG, as mentioned in #74 (and seen in action in the Zopfli KrzYmod fork). They're... largely ineffective. The combination of all 120 methods are outperformed by just the existing luma sort plus this new one. That's not to say there's nothing further to be gained from them, but trying to brute force all the combinations definitely seems like a bad idea. There are other algorithms I hope to explore in future... @ace-dent Thought this might interest you UPDATE: I realised a quick tweak to alpha values in the luma sort can provide a great improvement on images with transparency. The following numbers were taken with PR #509 as base. `-o2`: 19,065,549 bytes - base (luma sort) 18,949,747 bytes - modified luma sort `-o5`: 18,922,165 bytes - base (luma sort) 18,559,863 bytes - new sorting algorithm + luma sort 18,544,813 bytes - new sorting algorithm + modified luma sort
@andrews05 - here's a tough paletted image to add to your corpus! |
@ace-dent Nice. What's your analysis so far, how does oxipng fare? |
@andrews05 - I'm collecting images that compress better with oxipng- but haven't analysed them yet. For palette sorting, there still doesn't seem to be one program that is consistently the best. |
Pr0methean
pushed a commit
to Pr0methean/oxipng
that referenced
this issue
Dec 1, 2023
This adds a new palette sorting algorithm that attempts to minimise entropy by an approximate solution to the Traveling Salesman Problem. The algorithm comes from "An efficient Re-indexing algorithm for color-mapped images" by Battiato et al (https://ieeexplore.ieee.org/document/1344033). It's fast and effective and works in addition to the luma sort (which remains the single most effective sort). In order to keep lower presets fast though, I've only enabled this for o3 and higher. Results on a set of 190 indexed images at `-o5`: 18,932,727 bytes - master 18,578,306 bytes - PR 18,559,863 bytes - PR + shssoichiro#509 (These images may be particularly suited to alternative sorting methods - the gains here are not necessarily what should be expected on average) Note I looked into the 120 different palette sorting methods from TruePNG, as mentioned in shssoichiro#74 (and seen in action in the Zopfli KrzYmod fork). They're... largely ineffective. The combination of all 120 methods are outperformed by just the existing luma sort plus this new one. That's not to say there's nothing further to be gained from them, but trying to brute force all the combinations definitely seems like a bad idea. There are other algorithms I hope to explore in future... @ace-dent Thought this might interest you UPDATE: I realised a quick tweak to alpha values in the luma sort can provide a great improvement on images with transparency. The following numbers were taken with PR shssoichiro#509 as base. `-o2`: 19,065,549 bytes - base (luma sort) 18,949,747 bytes - modified luma sort `-o5`: 18,922,165 bytes - base (luma sort) 18,559,863 bytes - new sorting algorithm + luma sort 18,544,813 bytes - new sorting algorithm + modified luma sort
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
I-Medium
Issues that are breaking core functionality, but have a known workaround
T-Compression
Relates to improving the compression ratio of images
T-Feature
Requests for a new feature to be added
T-Needs Tests
https://css-ig.net/articles/truepng.php
The text was updated successfully, but these errors were encountered: