BrutePNG Alpha 0.0

[SvenBent]

BrutePNG is a little PNG Compressing improvement utility.
It works like a frontend for other PNG optimizing utilities. It's the next generation of my PNGbest.bat
In its current state it only uses PNGwolf and PNGout (Which mustbe in the same directory as BrutePNG.exe
But its multi threaded in the PNGout phase.

Plans are to integrate defluff deflopt and huffmix as well and support both CLI and Drag and drop GUI.

Usage:
BrutePNG <PNGfilename> <Iterations>

Still needs a lot of work

[Jyrki Alakuijala]

PNGout

Perhaps a silly question, but why PNGOUT instead of ZopfliPNG?

[SvenBent]

Not silly at all.

The reason is because pngwolf uses zopfli so its already zopfli compressed at that stage. Then pngout is used since its a different compression engine.
sometimes zopfli is smaller sometimes PNGout is smaller.

But there will be a zopfli compression stages later again incase pngout wins, to merge blocks from zopfli and pngout. it just not implanted yet.

The Iterations parameter controls the amount of zopfli iterations in PNGwolf. and later one as well as PNGout /r iterations.

[necros]

Hi Sven, hmm maybe silly question but what`s wrong with FileOptimizer?

[SvenBent]

I might be totally wrong as i only tried file optimizer shortly. But file optimizer did not improve on any of mu tested PNG Compared to PNGbest.bat. i believe i teste with kodak suit. and imgsrc 8bits/channe; color suit.
I think ( defiantly not sure) that Fileoptizimer has a cap on zopfli iterations and don't use PNGout /r trials ( again i might be wrong). also i dont think its multi threadead.

When i made PNGbest bat I tested different optimizers and removed those from my last that dint bring any improvement on final size. Optipng and advPNG didn improve a single file so i removed those.

This is the next generation of PNGbest.bat but its a total rewrite and I believe i can get even more multi threading working so hopefully shorter encoding times.
PNGbest.bat and soon in BrutePNG as well there will be certain smart checks to evaluate if further optimizing is going to add anything or not and skip certain slow phases..
E.G in case Zopfli seems to be superior to PNGout's compression engine there is no need to run all those PNGout/r trials

A smarter block threshold handling is in the plans as well as i notice that block threshold size in PNGout i most often have a Bell curve efficiency. So instead of brute forcing all of them and find the smallest one, i should be able to just brute force a handful and find the optimal a lot faster.


But most of all I just needed something to do in my lunch break hours

[Jaff]

Win32 executable?

[SvenBent]

next version will be win32 instead of win64. really no need for it to be win64 its just my default setting and i forgot to correct it.
howeve this weekend im working overtime at my company due to moving the entire company to other facilities, which have not gone by scheduled plan.
so hopefully next weekend i should get some extended time to get it up in shape. so far rezop and huffmix has been intergreated, and im running some test on treshold to see if my bell curve method work or not

[dado023]

i tried it against ECT, with command "brutepng testimage.png 10000", but compression is not comparable. ECT wins

Should i maybe do brutepng testimage.png 1 million iterations to get better result? or result would be similar to 10000 iterations?

[SvenBent]

i tried it against ECT, with command "brutepng testimage.png 10000", but compression is not comparable. ECT wins

Should i maybe do brutepng testimage.png 1 million iterations to get better result? or result would be similar to 10000 iterations?

BrutePNG is far from in a full functional state. Right now the compression is definitely sup par.

If you want to know what compression level BrutePNG is going to have you can use PngBest.bat
http://encode.su/threads/1978-PngBes...ng-optizmizing
Use the first version as the second one has some issues with certain file name.

If you do run a comparison against ECT i would love to see some results as i haven't been playing with ECT at all.


Increasing iterations will have diminishing returns i seldom go above 99

[dado023]

BrutePNG is far from in a full functional state. Right now the compression is definitely sup par.

If you want to know what compression level BrutePNG is going to have you can use PngBest.bat
http://encode.su/threads/1978-PngBes...ng-optizmizing
Use the first version as the second one has some issues with certain file name.

If you do run a comparison against ECT i would love to see some results as i haven't been playing with ECT at all.


Increasing iterations will have diminishing returns i seldom go above 99

Hm, i am curious, as soon as i get all those exe files needed with bestpng.bat, i will test it and see what happens.


For high compression, what command would you recommend?

maybe? pngbest testimage.png Strenght 15 pal
or those settings are low in compression?

[SvenBent]

for high compression i would do 50+
50 seems to be the most common high compression zopfli iteration ( At least in pngwolf)

[dado023]

Update:

i tried it with this command: pngbest testimage.png Strenght 500 brutal
Compared to ECTv0.6, it is behind in compression for 3143 bytes

[SvenBent]

Sorry i misread your prior post

pngbest testimage.png 500

Is the correct command

[dado023]

Sorry i misread your prior post

pngbest testimage.png 500

Is the correct command

oh, i see....well, i just finished test with pngbest testimage.png 500 command, it compresses file down to 184,559 bytes, while ETC outputs down to 183,151 bytes

I am not sure, but maybe it is because some exe files a bit old....or maybe command with 500 is not enough?...should i try with 5000? will it make any further difference?

[SvenBent]

#14 i hoenstly dont think going to 5000 reduce it much more

ECT looks pretty interesting.

[SvenBent]

i jsut made a very quick and dirty test

First page from LFG. and conveterd it form gif to png paletted

ECT64 -M5	 80 KB (287,278 bytes)
PngBest 99	279 KB (286,562 bytes)

[dado023]

so far, ECTv0.6 gave me the best compression result, with command:
ECT_x86.exe -60500 --allfilters-b --pal_sort=120 testimage.png




Though, i am not sure what LFG is.

[fhanau]

so far, ECTv0.6 gave me the best compression result, with command:
ECT_x86.exe -60500 --allfilters-b --pal_sort=120 testimage.png




Though, i am not sure what LFG is.

Yes, you should make sure that you're using the latest version.
For more speed, especially on palette images, you could also try ECT.exe -7 --allfilters --pal_sort=10 testimage.png

[dado023]

Yes, you should make sure that you're using the latest version.
For more speed, especially on palette images, you could also try ECT.exe -7 --allfilters --pal_sort=10 testimage.png

I m using v0.6 x86, instead of 0.6.1 because it gives slightly better compression.

One newbie question, how do i know if some image is palette image?

[SvenBent]

You can right click it and see if windows says it 24bit 32bit or 8bits. if its 8 bits its a palette image

[SvenBent]

i just tested with ECT_x64_default.exe (6.1)


1st picture is the page no 1000 from Order of the stick

ECT -9 --allfilters-b	1.49 MB (1,572,266 bytes)
PNGbest 99	1.49 MB (1,563,111 bytes)

2nd picture is the map og online communities form XKCD

ECT -9 --allfilters-b	3.84 MB (4,036,172 bytes)
PNGbest 99	3.80 MB (3,995,581 bytes)

Both of these are low collors comic looking but still contains more collors than what can be expressed in a palleted image
ussually in my previous test pngout ( which are in pngbest) has mostly been superioe than zopfli compression on comic looking pictures.

I'll try som photo realistic pictures next


what type pf pixture did you use dado023?

[dado023]

what type pf pixture did you use dado023?

I tested it on 32bit picture (16,7 Million (32 BitsPerPixel) irfanfiew info)

[SvenBent]

i just tested with with kodim12.png ( two ppl on the beach) looks liek a typical holiday pictures

ECT -9 --allfilters-b   493 KB (504,934 bytes)
PNGbest 99              493 KB (504,843 bytes)

The gab get close but pngbest still edges out

also timewise :

ECT        Global Time  =   222.250 = 00:03:42.250 = 100%
PNGbest    Global Time  =   102.078 = 00:01:42.078 = 100%

But this is on a I7 with HT so 8 threads can be handled at a time on PNGbest utilize them all in the bruteforce/mixing phase, whereas ECT is single threaded
on anything less than 4cores ECT will be faster.


Running ect -9 --allfilters-b on the PNGBest output files did not improve any


im about to try out catheradl in greytones as well from http://www.imagecompression.info/test_images/

[Paul W.]

i believe i teste with kodak suit. and imgsrc 8bits/channe; color suit.

What is the imgsrc suite you're referring to? (I''m guessing it's images from imgsrc.ru, but is there a standard set?)

[SvenBent]

What is the imgsrc suite you're referring to? (I''m guessing it's images from imgsrc.ru, but is there a standard set?)

These Too

Kodak
http://r0k.us/graphics/kodak/

ImageCompr
http://imagecompression.info/test_images/


oh now i see the typo
not imagesrc but imagecompression

[dado023]

In most of cases i am usually crunching PNGs files that are rather low resolution, max 480p.

@SvenBent , if possible, could you bundle all tools needed in one PNGbest zip file, so we are sure we use the same exe files.

[SvenBent]

I would love to but licenses issues forbid that. PNGout does not allow redistribution.
However I can make one without PNGout.
http://TechCenter.dk/New%20folder%20(2).zip


I'm just leaving it up for 24 hours as i want to make sure i don;t break ppl licenses/wishes with how their tools are distributed

[nikkho]

I would love to but licenses issues forbid that. PNGout does not allow redistribution.
However I can make one without PNGout.
http://TechCenter.dk/New%20folder%20(2).zip


I'm just leaving it up for 24 hours as i want to make sure i don;t break ppl licenses/wishes with how their tools are distributed

You can ask them for permission. I myself did that for FileOptimizer, and they agree with the only requirement I do not charge for the program.

[fhanau]

On kodim12.png, ECT --allfilters -20050 kodim12.png yields 504.798 Bytes in 77.914s which is both faster and smaller than PNGbest even though it is using a single thread.
Can you attach PNGbest's file anyway, I want to find out whether the filtering is better as ECT decided to always use filter 1 and I guess PNGwolf can do better.
Edit: --allfilters-b is generally not recommended as it has O(n²) complexity regarding the number of lines in the image.

[SvenBent]

fhanau i dont have the same kodim12.png anymore but i have one for a new test i did on the full suite. The size is the same as above.
I dont know about ECT internal functions. but pngbest uses pngouts with random initialization vectors. Which means one run might not give the same output as another even thoug the settings are the same

i did the full kodak test suit with the following settings
PNGbest.bat <filename> 99
ECT_x64_default -9 --allfilters-b <filename>


ECT - 13.9 MB (14,584,719 bytes) - Global Time = 5540.157 = 01:32:20.157 = 100%
PNGbest - 13.8 MB (14,534,563 bytes) - Global Time = 3045.781 = 00:50:45.781 = 100%

There is no doubt that ECT is way more processor efficient. and in a case where you can handle multiple files in parallel for multi threading. ECT would be way faster

But for maximum compression (unless there are other options to enable) pngbest still edges out in this suits, but NOT on all files.
But remember pngbest can ( might?) be set to stronger with increasing zopfli iterations and brute forcing pngouts /r trials
i will try with image compression test suits later


Here are the individuel file sizes

ECT:
07/25/2016  23:10           685,038 kodim01.png
07/25/2016  23:13           594,073 kodim02.png
07/25/2016  23:16           479,797 kodim03.png
07/25/2016  23:20           605,405 kodim04.png
07/25/2016  23:25           750,510 kodim05.png
07/25/2016  23:27           587,595 kodim06.png
07/25/2016  23:31           536,774 kodim07.png
07/25/2016  23:35           738,330 kodim08.png
07/25/2016  23:43           539,339 kodim09.png
07/25/2016  23:48           555,921 kodim10.png
07/25/2016  22:16           575,946 kodim11.png
07/25/2016  22:20           504,934 kodim12.png
07/25/2016  22:23           794,642 kodim13.png
07/25/2016  22:26           663,662 kodim14.png
07/25/2016  22:32           572,949 kodim15.png
07/25/2016  22:36           504,979 kodim16.png
07/25/2016  22:36           572,405 kodim17.png
07/25/2016  22:42           746,536 kodim18.png
07/25/2016  22:50           624,319 kodim19.png
07/25/2016  22:50           469,109 kodim20.png
07/25/2016  22:56           607,971 kodim21.png
07/25/2016  23:00           679,353 kodim22.png
07/25/2016  23:07           532,577 kodim23.png
07/25/2016  23:07           662,555 kodim24.png

PNGbest
07/25/2016  21:52           681,344 kodim01.png
07/25/2016  21:53           587,246 kodim02.png
07/25/2016  21:55           480,047 kodim03.png
07/25/2016  21:56           601,564 kodim04.png
07/25/2016  21:58           749,871 kodim05.png
07/25/2016  22:00           587,567 kodim06.png
07/25/2016  21:23           536,783 kodim07.png
07/25/2016  22:01           738,094 kodim08.png
07/25/2016  22:03           524,968 kodim09.png
07/25/2016  21:28           554,018 kodim10.png
07/25/2016  21:29           574,210 kodim11.png
07/25/2016  21:31           504,843 kodim12.png
07/25/2016  21:32           789,597 kodim13.png
07/25/2016  21:34           665,899 kodim14.png
07/25/2016  21:35           569,436 kodim15.png
07/25/2016  21:37           504,566 kodim16.png
07/25/2016  21:38           574,946 kodim17.png
07/25/2016  21:39           744,272 kodim18.png
07/25/2016  21:40           619,358 kodim19.png
07/25/2016  21:45           468,656 kodim20.png
07/25/2016  21:46           609,550 kodim21.png
07/25/2016  21:47           673,922 kodim22.png
07/25/2016  21:49           531,095 kodim23.png
07/25/2016  21:51           662,711 kodim24.png