Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MozJPEG 3.0

calendar.perfplanet.com

Post reply on HN
Print view View original

61–68 of 68 posts

Re: MozJPEG 3.0

#61

Post by Daiz »

CookWithMe wrote: post #55

Since it's mentioned in the article: Does anyone have experience with lossy png tools? I'm currently working on a project that needs alpha channels. I've been optimizing the images with pngcrush, which helped (interestingly, images put out with Adobe products where already pretty optimized, but I'm generating thumbnails locally with sips, where pngcrush often saves 60+%). Still, for photographic images, file size oft…

>Does anyone have experience with lossy png tools?

I do. Lossy PNGs work great for images with not a lot of colors. I use pngquant and optipng a lot in my work to compress a lot of PNG images with practically no visual quality loss.

For very colorful images, lossy (quantized & dithered) PNGs just don't work, though. They just end up looking nasty with larger filesizes than what high quality JPG gives you.

Re: MozJPEG 3.0

#62

Post by nailer »

CookWithMe wrote: post #55

Since it's mentioned in the article: Does anyone have experience with lossy png tools? I'm currently working on a project that needs alpha channels. I've been optimizing the images with pngcrush, which helped (interestingly, images put out with Adobe products where already pretty optimized, but I'm generating thumbnails locally with sips, where pngcrush often saves 60+%). Still, for photographic images, file size oft…

Ditto what Diaz said. The author of this article BTW also makes some rad lossy PNG tools. I took a 3MB website down to under 1MB recently, the majority of which were screenshots.

Re: MozJPEG 3.0

#63

Post by d0ugie »

cbr wrote: post #45
d0ugie wrote: post #42

Earlier quoted context omitted.

An nginx redirect based on user agents to an apology and a list of download links to WebP friendly browsers. I used to include a link to a Firefox fork that supported WebP natively, but no one bothered. I made a sort of Google+ companion to the site which I'd bump them onto but I still haven't gotten the hang of not getting banned.

ngx_pagespeed would be another way of serving WebP to supporting browsers and JPEG to others.

Yes, but not when storage, bandwidth, money, a desire to deliver only the best user experience (or nothing) and pushing WebP are concerns.

By the way, it's remarkable when running an image-heavy site how much bot/mass downloader traffic relative to humans vanish when turning away Firefox user agents.

Re: MozJPEG 3.0

#64

Post by pornel »

Daiz wrote: post #61
CookWithMe wrote: post #55

Since it's mentioned in the article: Does anyone have experience with lossy png tools? I'm currently working on a project that needs alpha channels. I've been optimizing the images with pngcrush, which helped (interestingly, images put out with Adobe products where already pretty optimized, but I'm generating thumbnails locally with sips, where pngcrush often saves 60+%). Still, for photographic images, file size oft…

>Does anyone have experience with lossy png tools? I do. Lossy PNGs work great for images with not a lot of colors. I use pngquant and optipng a lot in my work to compress a lot of PNG images with practically no visual quality loss. For very colorful images, lossy (quantized & dithered) PNGs just don't work, though. They just end up looking nasty with larger filesizes than what high quality JPG gives you.

There's also a method for true-color lossy PNGs that blurs instead of dithering: https://speakerdeck.com/pornel/lossy-png-for-true-color-imag... (https://github.com/pornel/mediancut-posterizer). It's not as efficient as PNG8, but still better than nothing :)

Re: MozJPEG 3.0

#65

Post by tracker1 »

CookWithMe wrote: post #55

Since it's mentioned in the article: Does anyone have experience with lossy png tools? I'm currently working on a project that needs alpha channels. I've been optimizing the images with pngcrush, which helped (interestingly, images put out with Adobe products where already pretty optimized, but I'm generating thumbnails locally with sips, where pngcrush often saves 60+%). Still, for photographic images, file size oft…

I use optipng and pngquant together myself... it's been a while since I've looked though... here's the contents of my "!Drag PNG here to Optimize (pngquant and optipng as png8).bat" file ... should be able to do similar in bash/zsh script.

    @echo off

    set batchdir=%~d0%~p0

    :start
     
    "%batchdir%pngquant.exe" --ext .q.png --force --verbose 256 %1
    "%batchdir%optipng.exe" -force -o4 -out "%~dpn1.opt.png" "%~dpn1.q.png"

    del "%~dpn1.q.png"

    shift
    if NOT x%1==x goto start

    rem pause

Re: MozJPEG 3.0

#66

Post by mzs »

joshmoz wrote: post #32

FYI, I plan to officially release mozjpeg 3.0 tomorrow. Thanks for the writeup and your work on this release, Kornel!

Thank you for your work. As a heads-up, I do not see any reference to -quant-table option as mentioned in the linked blog in cjepg.1 on GH.

Also, I have a little script that uses imagemagick to watermark an image and then create a resized image smaller image for web. Does mozjpeg's cjpeg support 48bpp png or is there some better way to no lose some detail due to rounding by avoiding going from 24-bit RGB out of imagemagick to YCbCr?

Re: MozJPEG 3.0

#67

Post by uniclaude »

joshmoz wrote: post #53
mikhailt wrote: post #16

Earlier quoted context omitted.

How can you not tell the difference? Look at the "Humor, empathy, resilience", the characters 'r'/'i'/'n' are damaged. There are more in the fourth column.

Thanks for pointing this out! Filed a bug: https://github.com/mozilla/mozjpeg/issues/139 I said in another comment that we'd release 3.0 tomorrow, we'll probably hold up the release to investigate this.

Wow, that was fast.

They already fixed the bug. I'm impressed.

Re: MozJPEG 3.0

#68

Post by mikhailt »

uniclaude wrote: post #67
joshmoz wrote: post #53

Earlier quoted context omitted.

Thanks for pointing this out! Filed a bug: https://github.com/mozilla/mozjpeg/issues/139 I said in another comment that we'd release 3.0 tomorrow, we'll probably hold up the release to investigate this.

Wow, that was fast. They already fixed the bug. I'm impressed.

Awesome to hear that.

@joshmoz Hopefully, you can re-run the image and share it with us in case we can find something else. :D

Post reply on HN