Robert Obryk

When would you envision the version to increase? Only when a significant number of images will produce different output of on such releases as 1.0.1 too?

There is no transparency support in JPEGs as they are supported by most viewers.

@pornel Guetzli's quality was mapped so as to correspond to libjpeg's quality for yuv444 (more precisely, Butteraugli score for quality X is the median Butteraugli score libjpeg generated at quality...

> Given that there is generation loss, I would agree with @jyrkialakuijala that it's best not to process an image more than once unless the size saving is more important...

It's true that Guetzli is really slow to compress. As a rough order of magnitude estimate, it takes ~ 1 minute / MPixel on a 2.6 GHz Xeon. The time...

@DanielBiegler If you have 200 pictures, I'd echo @jan-wassenberg's suggestion: run multiple instances of Guetzli and thus process multiple pictures in parallel. This will be more effective parallelization than anything...

@pornel We didn't try to optimize Guetzli in ways that could make it harder to modify. That means that there's likely both some speedup available by just optimizing single routines...

@slatted The runtime grows slightly faster than linearly with image size. If you want some inkling into what's happening, you might wish to pass `--verbose` commandline flag.

@clouless The image you're trying to compress has ~70MPix (its size is 8333x8333). According to the [readme](https://github.com/google/guetzli/blob/master/README.md#using) Guetzli uses ~300MB per MPix, so you should expect it to use ~21GB...

@clouless I use ImageMagick's `identify` or an image viewer to find the dimensions of the image and multiply them together to get the total number of pixels. I'd expect the...