[HN Gopher] OptiPNG vs. PNGcrush vs. Gimp to Reduce PNG Size
___________________________________________________________________
OptiPNG vs. PNGcrush vs. Gimp to Reduce PNG Size
Author : pmoriarty
Score : 59 points
Date : 2022-06-07 15:19 UTC (7 hours ago)
(HTM) web link (rubysash.com)
(TXT) w3m dump (rubysash.com)
| jandrese wrote:
| One of the best things you can do for a great many PNG files is
| to convert them to platted images using something like
| libimagequant. If you are willing to accept some image loss you
| can even apply this to images with more than 256 colors. In most
| cases it will be difficult to find the difference with just your
| human eyeball, and most of those cases you should probably be
| using webm or even JPEG instead.
|
| The file size savings can be enormous, way more than you achieve
| with just twiddling the block sizes and compression levels.
| pmoriarty wrote:
| _" If you are willing to accept some image loss..."_
|
| That's the critical part. PNG is an archival format for me.
| Image formats come and go, but as long as the archive image's
| format is lossless it can always be converted to another format
| without degradation if need be.
|
| I'd be happy to switch away from PNG to a more efficient
| format, but only if that format was lossless and well
| supported.
| Tagbert wrote:
| Generally people have separate concerns for published files
| vs archived files.
|
| Archived files can be considered like source code. They are
| probably unoptimized and may contain extra layers and
| components used to create them.
|
| Published files would generally focus on compact size and
| would strip the extra components and might use a degree of
| lossiness to enhance the compression if appropriate.
| discreditable wrote:
| I use optipng and advdef from advancecomp. #
| Linux People find -iname *.png | xargs optipng -o7
| find -iname *.png | xargs advdef -z4i50 #
| PowerShell People gci -include *.png | % { optipng -o7 $_
| ; advdef -z4i50 $_ }
|
| advdef uses the zopfli or 7-zip compressor for png's deflate
| compression. If you want to be fancy you can use gnu parallel on
| linux to parallelize the compression and make the script a one-
| liner. (I know xargs can do it but I stopped using xargs after
| adopting gnu parallel). If you're powershell 7+ you add -parallel
| after %.
|
| If you want to do quantization you can use imagemagick's -colors
| to reduce to as many as you need. It doesn't even have to be <=
| 256. You can do say 300, 500, or even 1000 colors. This doesn't
| allow you to use a palette but fewer colors in a png often make
| things easier for the compressor to compress well. This is not
| lossless compression but can work well for simple artwork.
| themodelplumber wrote:
| Pngcrush was always awesome for web and similar work. I remember
| using it to get image slices lowered way down in size...for
| tables...in emails. Blech.
|
| Maybe this is an appropriate place to say that lately I am
| wishing for a video format that can do dithering and indexed
| colors without jpeg/mpeg-style blurry/blocky compression. Even 1
| bit color would be fine...
|
| My dream is that it would allow something like a pixelcast as an
| alternative to a video stream, with an impressive rate of
| compression and no blur at all. Any tips on formats or tools
| would be appreciated.
| a1369209993 wrote:
| > a video format that can do dithering and indexed colors
| without jpeg/mpeg-style blurry/blocky compression.
|
| GIF actually does this, and you can convince ffmpeg to mux it
| into a generic container like matroska, although most video
| players won't decode it: ffmpeg4 -i A.mp4 -f
| matroska -vcodec gif -acodec mp3 A.gif.mkv
|
| > The playback of [A.gif.mkv] requires a video/x-unknown
| decoder plugin which is not installed.
| Zababa wrote:
| I've tried a few, the best one was pingo (https://css-
| ig.net/pingo). pingo -s9 gives better results than oxipng with
| Zopfli, while being usually two order of magnitudes faster. It's
| also faster than "regular" oxipng while being better. I can
| usually shave of 15%/20% of the size of png files I encounter.
| One thing I didn't check is that you might pay that in decoding
| time, I've never seen anybody talking about that though.
| lifthrasiir wrote:
| There are a myriad of PNG (and in general DEFLATE) optimizers
| and pingo hosts its own benchmark [1]. I believe ECT [2] is the
| only tool comparable to pingo in terms of compression ratio and
| speed. But pingo still lacks a license statement and it's even
| unclear whether you can use this for any purpose at all,
| probably because it is still "experimental", so if you don't
| like that you can try ECT instead.
|
| > One thing I didn't check is that you might pay that in
| decoding time, I've never seen anybody talking about that
| though.
|
| PNG and in general DEFLATE-based formats are mostly free from
| this concern because they are comparably simple. The maximum
| "overhead" you can intentionally trigger is a very large LZ77
| window and a very deep prefix code tree; the former is however
| capped to 32 KB in DEFLATE, and the latter will mostly result
| in an inferior compression (a longer prefix code means a larger
| file).
|
| [1] https://css-ig.net/benchmark/png-lossless
|
| [2] https://github.com/fhanau/Efficient-Compression-Tool
| bscphil wrote:
| Yes. I have no idea why ECT gets left off of lists so often,
| because it's almost always within 1% of the best tools on
| size, and at least several times faster than them on speed.
|
| As far as I can tell, pingo isn't cross platform or open
| source, in addition to the issue you mention with the license
| statement, which makes it extremely limiting for e.g.
| automated processing of images on a server. I think ECT is
| absolutely a reasonable choice for most use cases.
| Zababa wrote:
| I didn't know about ECT even after searching for a while.
| Maybe it's lacking in visibility? I'll give it a try.
|
| As for pingo, I can run it without issues with wine. I
| would personally prefer an open source tool though, so if
| ECT is really around 1% of pingo and not too much slower, I
| would prefer it.
| bscphil wrote:
| As is unfortunately typical for tutorials like this, the best and
| most effective PNG compressors like oxipng or ECT [1] are
| strangely left off.
|
| I compressed the original PNG shown on the site with ECT. It took
| only 6.5 seconds on my old laptop, and resulted in a file 95.7%
| of the size of their pngcrush result. I don't see why you'd want
| to leave 4-5% more efficiency on the table in a case like this.
|
| Similarly, I reproduced their pngcrush result on the same laptop.
| It took 10.834 seconds. Getting a better result doesn't even take
| more time!
|
| Commands: ect --strict -9 pngcrush
| -brute
|
| [1] https://github.com/fhanau/Efficient-Compression-Tool
| dontbenebby wrote:
| Thanks for dropping a citation, when the CPU cost is low and
| the code is on Github it's relatively easy to add a tool or two
| to a script if you're benchmarking. (IMHO)
|
| But speaking as a paranoid hacker: why is it more common to run
| unknown code in the graphics world than others?
|
| |I've noticed a lot of trust in that community, versus the
| felonious infosec mantra of "oh, you typed something from the
| internet into the terminal without understanding it? Of course
| someone stole everything on your hard drive, why didn't you've
| have seven layers of veracrypt volume around your diary or
| whatever?" mentality.
|
| I don't know a ton about image visualization, but I'm super
| appreciative of tools like GIMP and VLC that save me time and
| money in a variety of ways.
|
| (Remember back when downloading a keygen meant risking a
| trojan? Or is that something the next generation of hackers has
| only heard about in stories? :-) )
| jart wrote:
| Their Windows binary comes up clean on VirusTotal. Running on
| Linux under strace is squeaky clean. There should be a rule
| against fud like this from anons because open source is built
| on trust and without trust open source couldn't exist. Worst
| case scenario I imagine is you forget to use --strict when
| compressing your whole image collection and since it's
| pre-1.0 you get an artifact here and there.
| navjack27 wrote:
| Ok what about https://imageoptim.com/mac or
| https://nikkhokkho.sourceforge.io/static.php?page=FileOptimi...
|
| Like, fileoptimizer uses tons more PNG optimisers.
| xsmasher wrote:
| Imageoptim is my go-to tool for crushing PNGs. It strips
| metadata and then tries multiple methods in combination to get
| the smallest possible file.
|
| If I am OK with reduced quality then I will run PNGyu first to
| reduce it from 32 bits per pixel -> 8 bit or lower.
| pineconewarrior wrote:
| And https://squoosh.app/ which has a CLI!
| adamredwoods wrote:
| I really like quantized PNG8 ! If anyone wants a internet-free
| app on OSX, try ImageAlpha! It's great, lots of settings to try
| and optimize PNGs.
|
| https://pngmini.com/ (needs Python 2, apparently outdated)
|
| Based off of: https://pngquant.org/
| oofabz wrote:
| If anyone is interested in lossy PNG compression, please check
| out my project at https://github.com/foobaz/pngloss
|
| It doesn't compress as well as JPEG or other formats that are
| designed to be lossy. But if you need PNG for some reason like
| alpha channel or application requirements, or if your image is
| particularly well-suited to my compression algorithm, it might be
| a good choice. For many images it does compare favorably to an
| 8-bit indexed PNG.
| riidom wrote:
| Nice! For images that lean well to indexing, I always use png,
| it's amazingly small. How hard (for an amateur) would it be to
| plug your algorithm into GIMP? But should have live preview,
| because judging by your example images, there is a bit of
| trying involved.
| stewx wrote:
| This is a strange test to do. The image he used is not really
| suited to PNG. It is more like a photograph, which is better in
| JPEG format, than an illustration, which is better as a PNG.
|
| Furthermore, he doesn't even post the resulting compressed
| versions from each piece of software, just some console output
| and then a single "optimized PNG" image.
| pmoriarty wrote:
| _" The image he used is not really suited to PNG. It is more
| like a photograph, which is better in JPEG format, than an
| illustration, which is better as a PNG."_
|
| I use PNGs to archive photographs because it's lossless,
| supports 16-bit images, and is well supported across most
| software.
|
| Not sure why you think it wouldn't be suitable for that.
|
| JPEGs, on the other hand, would not be at all suitable for this
| purpose, as they're lossy and only support 8-bit images.
| ricardobeat wrote:
| Archiving vs delivering images on the web, are pretty much
| extreme opposites in terms of size/bandwidth/quality
| requirements.
| jhgb wrote:
| Have you made any comparisons of your PNG files to, say,
| lossless WebP files? (Apparently there's also lossless mode
| in JPEG XS nowadays but that seems to be a very new option.)
| dontbenebby wrote:
| Thanks a ton, I wish more programs would aid folks in using PNG
| settings to efficiently use PNG, rather than nudge towards
| JPG/JPEG for realistic photos.
|
| There's a lot of "tricks" like that we taught designers long ago
| that hold the web back absent more technical folks allowing new
| paradigms to flourish.
| beagle3 wrote:
| It's actually time to switch to JPEG XL. Just one format, does
| lossless and lossy (and usually smaller than PNG when lossless,
| always smaller than JPEG when lossy)
| dontbenebby wrote:
| Maybe. Is it patent encumbered?
| Beltalowda wrote:
| https://jpegxl.io/articles/faq/#isjpegxlroyalty-free?
|
| No.
| dontbenebby wrote:
| If it's also efficient, sounds interesting.
|
| Thanks for the cite! I'll bookmark it.
| xeeeeeeeeeeenu wrote:
| Unfortunately, it seems that despite being inferior to JPEG
| XL, AVIF will become the next main image format.
|
| JXL still has zero browser support (out of the box; Firefox
| and Chromium have it hidden behind a feature flag) and it
| doesn't seem that the browser developers are interested in
| changing that.
| theandrewbailey wrote:
| Browsers don't support it out of the box (yet), so probably
| not time to switch. Try AVIF instead. It has similar
| efficiency and feature set and is better supported.
|
| https://caniuse.com/jpegxl
|
| https://caniuse.com/avif
| dontbenebby wrote:
| >Browsers don't support it out of the box (yet), so
| probably not time to switch.
|
| Ok, so do we skip even trying to use more well tested stuff
| like APNG to use this? Or just accept the moment is as gone
| as the blink tag?
|
| (I'm only being half joking -- I'm not a data visualization
| expert but I learned digital photography when you'd shoot
| onto a floppy jammed into the camera, so while I don't know
| algos well, I've also seen scores of security
| vulnerabilities stem from browser cruft.
|
| Classic example being that prior to FTP support being
| removed from firefox, you could do things like say go to tr
| usteddomain.nameofschool.edu@badsitethatistotallyfullofputi
| nsmalware.ru and very easily infect any sort of kiosk
| running Firefox, Firebird, or in one especially hilarious
| case... Internet Explorer.
|
| I'm not even joking... my target was still using Internet
| Explorer, on a kiosk, years after the switch to Edge.
|
| (Luckily all I did was redirect to a search engine to find
| an ISBN number. I could have done much worse.)
| brycewray wrote:
| AVIF will be a good choice in time, but right now it takes
| a lot of horsepower (read: battery juice) for some devices
| to use it. Not sure how/when that'll get resolved. From
| "The ROI of Adopting AVIF for Websites" on the Cloudinary
| Blog, 2021-11-29[0]:
|
| > . . . since AVIF decoding consumes a lot of CPU and
| battery, mobile devices are taking a while to jump on the
| AVIF bandwagon.
|
| [0]: https://cloudinary.com/blog/the_roi_of_adopting_avif_f
| or_web...
| aidenn0 wrote:
| Can I embed a JPEG XL in a PDF yet? That's what keeps me on
| jp2k
| Phrodo_00 wrote:
| > PNG is "lossless" meaning, you can save (nearly) all of the
| original data.
|
| I was under the impression that no data was lost in PNG. Anyone
| know why the author added that (nearly) in there? Does it maybe
| have to do with bit depth? Are there cameras shooting in more
| than 16 bit depth?
| trey-jones wrote:
| Let me project my own reasoning onto the author, but I have a
| habit of not using absolute language, and words like "nearly"
| are good for hedging against being wrong. I think _probably_
| (wink) this habit intrudes into statements were absolute would
| be correct.
| jansan wrote:
| If you want better lossless compression you may want to try WebP,
| which is now supported by all modern browsers and offers better
| lossless compression than PNG. For the example image I got
| 187kBytes compared to 267kBytes with PNG.
|
| Can I use WebP: https://caniuse.com/webp
|
| WebP on Wikipedia: https://en.wikipedia.org/wiki/WebP
| dchest wrote:
| Indeed! For one of the my images, which had lots of non-linear
| gradients and shadows (an app icon), an optimized (with the
| best algorithm using ImageOptim) 457 KB PNG got compressed to
| 36 KB WebP (lossless, of course).
| pmoriarty wrote:
| Unfortunately WebP only supports 8-bit images.
|
| One of the main reasons I use PNG is that it can handle 16-bit
| images, so if I converted my archival 16-bit PNGs to WebP I'd
| lose data.
| pineconewarrior wrote:
| WebP isn't perfect but it's fantastic for raster web graphics
| requiring transparency!
| perardi wrote:
| Although it's best practice to run images through a compressor at
| some point in the build/deploy practice...in reality not everyone
| does that.
|
| But if you work with Photoshop-generated PNGs with alpha
| transparency: try to work in some sort of post-Photoshop
| compression. I can get _significant_ improvements on these type
| of images.
|
| https://imgur.com/ouTiSrP
|
| _(Yes, this would be a dumb image to save as a PNG, versus an
| SVG with a shadow, but, just for quick demo purposes.)_
| minimaxir wrote:
| Oxipng is both good and fast as well:
| https://github.com/shssoichiro/oxipng
| ricardobeat wrote:
| The 'indexed' PNG is not an apt comparison. Using an 8-bit
| palette doesn't mandate terrible dithering, you can get this
| image down to 70-80kB with quantized 80-120 colors, and because
| of the solid surfaces it doesn't need any dithering at all. Or
| you could use WebP to get a 30KB file that has better quality
| than the JPEG.
|
| I recommend using https://squoosh.app for this, it has OxiPNG and
| runs the compressors in-browser with WASM so you can fine tune
| the parameters live.
___________________________________________________________________
(page generated 2022-06-07 23:01 UTC)