ps怎么用jpeg压缩技术_用Guetzli进行JPEG压缩

ps怎么用jpeg压缩技术

A little while ago Google released its Guetzli JPEG encoder, which claims a 20-30% improvement in file size over libjpeg. Being intrigued, I decided to give it a go. My tool of choice for optimizing JPEGs has long been jpeg-recompress, one of the binaries available in the jpeg-archive project. It's highly configurable, reasonably fast, and really delivers on optimizing JPEGs. But how does Guetzli compare?

不久前， 谷歌发布了Guetzli JPEG编码器 ，该文件声称文件大小比libjpeg提高了20-30％。 出于好奇，我决定试一试。 长期以来，我选择的用于优化JPEG的工具一直是jpeg-recompress，它是jpeg-archive项目中可用的二进制文件之一。 它是高度可配置的，相当快的，并且确实可以优化JPEG。 但是格茨利如何比较？

基本的测试用例 (A rudimentary test case)

To get started, I used a portrait of myself:

首先，我用自己的画像：

What you see above is a much smaller version of the the unoptimized JPEG source I worked with. The original image is 2560x2561, and weighs in at 861 KB. When I processed this image with Guetzli, I used the following command:

上面看到的是我处理过的未经优化的JPEG源的小得多的版本。 原始图像为2560x2561，大小为861 KB。 当我使用Guetzli处理此图像时，我使用了以下命令：

guetzli unoptimized.jpg guetzli.jpg

This took a while. Quite a while, in fact. This isn't a surprise, though, considering that Google explains in the project readme that you should expect about a minute of CPU time for every megapixel (my test image was 2.5 megapixels). When Guetzli finished, the output file's size was 770 KB. About 11% smaller than the source. Not bad. Them I ran jpeg-recompress on the unoptimized source using this command:

这花了一段时间。 半响 ，其实。 不过，考虑到Google在项目自述文件中解释说，您应该期望每兆像素大约需要一分钟的CPU时间(我的测试图像为2.5兆像素)，因此这并不奇怪。 Guetzli完成后，输出文件的大小为770 KB。 比来源小11％。 不错。 我使用以下命令在未优化的源上运行了jpeg-recompress：

jpeg-recompress --accurate --strip unoptimized.jpg guetzli.jpg

jpeg-recompress fared a bit better for me with an output file size of 662 KB, about 23% smaller than the unoptimized source, and 15% smaller than the Guetzli-optimized version. Does this mean that jpeg-recompress is the undisputed winner? It really depends. The way jpeg-recompress works is by iterating over an image within a default quality range of 40 to 95 to find the best compromise between quality and file size. You can specify the amount of loops, but the default (which is usually sufficient) is 6. When optimizing my portrait JPEG, jpeg-recompress landed on a quality of 80. Guetzli's default quality setting is 95. So what happens if I set Guetzli to a comparable setting? Unfortunately, I couldn't. Guetzli doesn't allow you to specify a quality setting less than 84. So to make things a little more comparable to the jpeg-recompress output, I went with the minimally allowed setting of 84:

jpeg-recompress对我来说要好一些，输出文件大小为662 KB ，比未优化的源小23％，比Guetzli优化的版本小15％。 这是否意味着jpeg-recompress是无可争议的赢家？ 真的要看 jpeg-recompress的工作方式是对默认质量范围为40到95的图像进行迭代，以找到质量和文件大小之间的最佳折衷方案。 您可以指定循环数，但是默认值(通常足够)是6。优化我的肖像JPEG时，jpeg-recompress的质量为80。Guetzli的默认质量设置为95。因此，如果我设置Guetzli，会发生什么情况到可比的环境？ 不幸的是，我不能。 Guetzli不允许您指定小于84的质量设置。因此，为了使事情与jpeg-recompress输出更具可比性，我采用了最小允许设置84：

guetzli --quality 84 unoptimized.jpg guetzli-q84.jpg

The final result? After a (long) wait, the Guetzli-optimized version at a quality setting of 84 was 636 KB. 26 KB smaller than jpeg-recompress at a quality setting of 80. How does Guetzli stack up to the competition when it comes to visual quality? In the case of my portrait image, both optimized versions are nearly indistinguishable.

最终结果？ 经过长时间的等待，质量设置为84的Guetzli优化版本为636 KB 。 在质量设置为80时，比jpeg-recompress小26 KB。在视觉质量上，格兹利如何与竞争对手竞争？ 就我的肖像图像而言，两个优化版本几乎无法区分。

Of course, this is just a one-off example. What does Guetzli performance look like across a whole set of images? Let's take a look!

当然，这只是一个例子。 整个图像上的格兹利性能看起来如何？ 让我们来看看！

Guetzli在一组图像上的表现 (Guetzli performance across a set of images)

A single test case of a couple image optimizers can be useful, but really only provides a narrow view of performance. If we want to get a broader sense of how well an optimizer works, we should test it across a large set of images. I used several image optimizers on a set of nearly 500 unoptimized images. These images were of various foods. The type of imagery you'd be used to seeing on a recipe website. I used the find command to process the image batch (using the technique I described in this blog post). The unoptimized payload of these images was 37,388 kilobytes. In each case, I aimed for a target quality of 84, the lowest quality allowed by the Guetzli encoder. I also used the time command to get a sense of how long each optimizer takes. Below are the results showing the command used for each optimizer, the time each one took to process the batch of unoptimized images, and the cumulative size of the optimized output:

几个图像优化器的单个测试用例可能会有用，但实际上只能提供性能的狭窄视图。 如果我们想更广泛地了解优化器的工作原理，则应该在大量图像上对其进行测试。 我在一组近500张未优化的图像上使用了几个图像优化器。 这些图像是各种各样的食物。 您习惯在食谱网站上看到的图像类型。 我使用find命令来处理图像批处理(使用我在本博文中描述的技术)。 这些映像的未优化有效负载为37,388千字节。 在每种情况下，我的目标质量都是84，这是Guetzli编码器允许的最低质量。 我还使用了time命令来了解每个优化器需要多长时间。 以下结果显示了用于每个优化器的命令，每个优化器处理一批未优化图像所需的时间以及优化输出的累积大小：

Note: The cjpeg binary used is from mozjpeg 3.1

注意：使用的cjpeg二进制文件来自mozjpeg 3.1

Now for the takeaway: Guetzli beats out all of the other optimizers at the lowest allowable quality setting of 84, but it takes a brutal amount of time to do so. While most optimizers will get reasonably close, they can do so several orders of magnitude faster.

现在的外卖：Guetzli击败了所有在84的最低允许质量设置其他优化的，但它需要时间的残酷量这样做。 尽管大多数优化程序会相当接近，但它们可以将速度提高几个数量级。

Moreover, a minimum quality setting of 84 isn't as low as we should be aiming for when it comes to web imagery. We have to treat image quality as a subjective issue, because any number of variables are involved in how the user assess image quality. What about viewing distance, physical device size, or screen resolution? The rules are simple: If you can't tell the difference between an unoptimized image and optimized one, your users won't be able to. If you can tell the difference, that's still no guarantee that your users will be able discern its quality, because they likely won't have a higher version of the same image for reference.

此外，对于网络图像，最低质量设置84并不像我们应达到的目标那么低。 我们必须将图像质量视为一个主观问题，因为用户评估图像质量的方式涉及许多变量。 观看距离，物理设备大小或屏幕分辨率如何？ 规则很简单：如果您无法区分未优化的图像和优化的图像之间的区别，则用户将无法做到。 如果您能分辨出差异，那仍然不能保证您的用户能够辨别其质量，因为他们可能不会使用同一图像的更高版本作为参考。

When running jpeg-recompress with a specified quality range of 30-70 across the same set of images, I was able to achieve an output size of 11,114 KB. That's another couple megabytes below the best that Guetzli could do. Even though the output quality was lower, the results were still acceptable (albeit subjectively so).

在同一组图像上以指定的30-70的质量范围运行jpeg-recompress时，我能够实现11,114 KB的输出大小。 这比格兹利所能达到的最佳性能低了几兆字节。 即使输出质量较低，结果仍然可以接受(尽管主观上如此)。

Another thing to consider is that Guetzli cannot encode progressive JPEGs. Progressive JPEGs are usually a smidge smaller than baseline JPEGs. Better yet, because of how progressive JPEGs load, they minimize layout shifting. Less layout shifting means less page re-rendering. Less rendering means less device battery consumed for processing.

要考虑的另一件事是Guetzli无法编码渐进JPEG。 渐进式JPEG通常比基准JPEG小。 更好的是，由于渐进式JPEG的加载方式，它们使布局偏移最小化。 更少的版式移位意味着更少的页面重新呈现。 更少的渲染意味着更少的设备电池消耗。

While Guetzli is highly effective in situations where quality is the paramount concern, I personally prefer other optimizers. While Guetzli handily outdoes the competition at comparable quality settings, it doesn't allow you to optimize images at a setting lower than 84. Because of this limitation, how incredibly CPU-intensive it is, and its lack of progressive JPEG support, I don't feel comfortable recommending it. Don't take my word for it, though. Check out this list of articles about Guetzli and form your own opinions:

尽管Guetzli在质量至上的情况下非常有效，但我个人更喜欢其他优化器。 尽管Guetzli在可比较的质量设置下轻而易举地超过了竞争对手，但它不允许您在低于84的设置下优化图像。由于这一限制，CPU占用率高得令人难以置信，并且缺乏渐进式JPEG支持，推荐它不舒服。 不过，请不要相信我。 查看有关Guetzli的文章列表，并发表自己的见解：

• Announcing Guetzli: A New Open Source JPEG Encoder

  宣布Guetzli：一种新的开源JPEG编码器

• Google Releases Guetzli Open Source JPEG Encoder Generating 20 to 35% Smaller Files Compared to Libjpeg

  Google发布Guetzli开源JPEG编码器，与Libjpeg相比，生成的文件小20％至35％

• Guetzli, Google's New JPEG Encoder

  Google的新型JPEG编码器Guetzli

However you decide to optimize your images, realize that something is always better than nothing. No matter which optimizer you go with, you're doing right by your users, and that's really what matters.

但是，您决定优化图像，要意识到总有总有没有比没有好。 无论使用哪种优化器，用户都在正确地进行操作，这才是真正重要的。

翻译自: https://davidwalsh.name/jpeg-compression-guetzli

ps怎么用jpeg压缩技术