Guetzli: A New Open-Source JPEG Encoder • Hacker News Board

Re: Guetzli: A New Open-Source JPEG Encoder

#131

Post by janwas » Sun, Mar 19, 2017, 5:33 PM UTC

saltysalty wrote: post #120

I am not an expert, but AFAIK JPEG is a lossy format. The comparison is purely based on the size, and I couldn't find anything in the paper about data loss compared to other encoders. Can someone please explain why is this a fair comparison?

We did an experiment with comparisons of Guetzli and (slightly larger) libjpeg output: https://arxiv.org/abs/1703.04416 Turns out that 75% of the 614 ratings are in favor of the Guetzli version.

Re: Guetzli: A New Open-Source JPEG Encoder

#132

Post by underlines » Tue, Mar 21, 2017, 12:16 PM UTC

if it may benefit anyone, i used this simple batch file to test out the lower bound -quality 84 with drag and drop of one/multiple images on win 86-64:

  echo Drag and drop one or multiple jpg or png files onto this batch file, to compress with google guetzli using a psychovisual model
  if [%1]==[] goto :eof
  :loop
  echo compressing...
  guetzli_windows_x86-64.exe -quality 84 %1 "%~dpn1_guetzlicompressed%~x1"
  shift
  if not [%1]==[] goto loop
  echo DONE

i'm concerned about the color changes that are clearly visible throughout the whole image.

Re: Guetzli: A New Open-Source JPEG Encoder

#133

Post by sam-mueller » Wed, Mar 22, 2017, 2:26 AM UTC

Are there any plans to make Guetzli available as a library for iOS and Android? Would be great to process images right on device with this level of compression.

Re: Guetzli: A New Open-Source JPEG Encoder

#134

Post by JyrkiAlakuijala » Wed, Mar 22, 2017, 7:46 AM UTC

underlines wrote: post #132

if it may benefit anyone, i used this simple batch file to test out the lower bound -quality 84 with drag and drop of one/multiple images on win 86-64: echo Drag and drop one or multiple jpg or png files onto this batch file, to compress with google guetzli using a psychovisual model if [%1]==[] goto :eof :loop echo compressing... guetzli_windows_x86-64.exe -quality 84 %1 "%~dpn1_guetzlicompressed%~x1" shift if not […

Guetzli runs the whole image to the same specified quality -- when artefacts start to emerge, they are everywhere, not just in one sensitive area. Guetzli can be more likely worth its cpu cost at a higher quality, around 92-96.

Re: Guetzli: A New Open-Source JPEG Encoder

#135

Post by robryk » Mon, Mar 27, 2017, 6:39 PM UTC

londons_explore wrote: post #76

SloopJon wrote: post #15

The Github README says, "Guetzli generates only sequential (nonprogressive) JPEGs due to faster decompression speeds they offer." What's the current thinking on progressive JPEGs? Although I haven't noticed them recently, I don't know whether they're still widely used.

I don't really understand why they would be slower to decode. It's really just the same data ordered differently in the file. I can see that if you try to render an incomplete file you might end up "wasting" effort blitting it to the screen and stuff before the rest of the data is decoded. But if thats a concern, one can simply rearrange the data back to scanline order and decode as normal?

They are slower to decode mostly due to decreased cache locality. In sequential JPEGs you read one block worth of data, make pixels out of it, and write the pixels out. In progressive encoding, you need to write the pieces of coefficients back to memory at every scan -- the whole image won't fit into cache -- so there's one more memory roundtrip for every pixel. Also, there's just more symbols to decode in total.