The badly documented /b switch of pngout allows even smaller file sizes, could it's use be an option in the next version of pnGGauntlet ?
Are you interessed in statistics about file size compression depending on this parameter ?
Do you have info about it ?
Even smaller png files
(5 posts) (4 voices)- Started 5 years ago by ShadowCaster
- Latest reply from counting_pine
- This topic is
not a support question - (no related topics found)
-
I have no info on it. Coupld you please send me whatever information you have?Posted 5 years ago #
-
ShadowCaster
Memberthe b parameter is the value (floating point) of the byte size gain that is considered worth splitting a hufman block code.
pngout recursivly splits blocks according to this parameter until no gain is possible (after a split, resulting blocks can be split again, witch is the reason that the temporary file in memory is rescanned from scratch after each pass where splitting points have been found).
For a given image, with given fixed parameters except the /b one, the file size makes a U shaped curve, with samallest files size around /b256 witch is the reason why /b256 is the default value. But it's generally not the exact optimum and sometimes the optimum is far from 256, making the smallest possible file using the best /b for the file 10% smaller than the default /b256.
A solution would be to compute a few /b parameters (4-6 seems OK to me), use the found sizes/b pairs as points for an interpolation curve, and then use the optimal b of the curve as the guessed aproximation of the optimum.Posted 5 years ago # -
counting_pine
MemberI think having a brute force method with block split thresholds would be a great way to get the most out of Ken's deflate algorithm. And I've thought of something which could speed up the Brute Force process quite a bit.
As I understand it, Ken's block-splitting algorithm computes a set of block split points. As you decrease the threshold, more and more points will be added to the set, as their values become higher than the threshold.
If they're close enough, two different thresholds may produce the same set of block split points, and will deflate exactly the same way. So, if one value for /b generates the same block split points as a previous value, you don't need to waste time running PNGOUT again with that value.
If you run pngout /v, it will tell you what the set of block boundaries is before it deflates the file. If it gives you the same set as before, you can terminate it then, and stop an unnecessary deflate.Posted 4 years ago #
Reply
You must log in to post.