0

我想知道是否有明显的理由使用jimp与imagemin-mozjpeg来压缩 jpeg（我已经在我的项目中同时使用 imagemin 和 jimp，imagemin-webp 用于提供下一代图像，以及 jimp 将 png 转换为 jpeg在极少数情况下）所以我更多地寻找基于以下内容的推理：

  1. 表现
  2. 可靠性（我注意到有一些 JPEG 文件 mozjpeg 有问题并且失败了。特别是我使用 GNU Image Manipulation Program [GIMP] 的那些。）

但是，如果有人有充分的理由与上述两个不一致，我仍然想听听他们的意见。

如果有人需要，这里有一些 NPM 包的快速链接：
imagemin-
mozjpeg jimp

4

2 回答 2

2

表现

imagemin-mozjpeg使用mozjpeg处理图像。而mozjpeg本身是用C语言制作的。而jimp使用 javascript 来处理它。

如主存储库jimp中所述：

一个完全用 JavaScript 编写的 Node 图像处理库，具有零原生依赖项。

我们知道 Javascript 和 C 之间的性能差异。

可靠性

我不想在这部分发表太多意见。但是我们可以直接看到每个存储库的统计情况。

莫兹佩格：

  • 星级：4.1k
  • 未解决的问题：76
  • 已关闭的问题：186

吉普：

  • 星级：10.3k
  • 未解决问题：157
  • 已关闭的问题：430

我也不赞成。他们都运作良好。我非常感谢库的维护者和贡献者所做的工作。

于 2020-06-24T23:56:46.150 回答
1

是的，它远远超出了压缩过程的性能（即压缩图像需要多长时间，这也很重要）或库开发的相对活动（可以说不那么重要）。

我强烈推荐阅读WebP 真的比 JPEG 更好吗？（和这个讨论），这表明即使在 JPEG 压缩库中，实现也会对压缩率产生重大影响。

简而言之，MozJPEG 生成的 jpeg 文件比参考 JPEG 实现 (libjpeg) 生成的 jpeg 文件小 10%。更有趣的是，对于大于 500px 的图像，MozJPEG 实际上会生成比 WebP更小的 jpeg 文件。

这就引出了一个有趣的问题。这将完全取决于您的用例和优先级，但实际上简化和使用 MozJPEG 并完全放弃 WebP 可能是有意义的。

展望未来，AVIF 可能会成为真正的下一代格式（提供缩小 30% 的图像），但浏览器支持“即将推出”。或者，JPEG XL 看起来也很有希望，但标准尚未最终确定。HEIC 是有问题的，我不会指望广泛的支持。

关于 jimp 的警告：

由于 jimp 是用纯 JavaScript 实现的，所有图像操作最终都会阻塞 JS 线程。这在 node.js 中是灾难性的。

您必须手动使用新的Worker Threads API在线程上运行 jimp。

最后，关于在 node.js 世界中选择图像处理库的警告：

据我所见，他们中的大多数最终将临时文件写入磁盘，然后调用子进程来完成实际工作，然后将结果读回。（例如，类似的东西child_process.exec('imageresizer -in temp/file.jpg -out temp/resized.jpg')）。

这不是执行此操作的理想方法，当 API 看起来像 时，可能会特别令人惊讶var img = await resizeImg(buffer)，它看起来不像是写入磁盘。

imagemin 就是这样一个库；我会在性能很重要的地方避免它。

相反，在 libuv 线程池上搜索实现与本机代码绑定的模块。这通常是处理图像的最高效方式，因为操作发生在节点进程中的线程上，并且内存复制最少——而且根本没有磁盘 I/O。

我从未使用过它，但node-mozjpeg看起来是一个不错的候选者。

于 2020-06-25T03:30:35.757 回答