nodejs 在 JIMP 和 MOZJPEG 之间进行选择

Question

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

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

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

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

Answer 1

表现

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

如主存储库jimp中所述：

一个完全用 JavaScript 编写的 Node 图像处理库，本地依赖项为零。

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

可靠性

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

莫兹佩格：

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

吉普：

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

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

Answer 2

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

我强烈推荐阅读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 中是灾难性的。

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

---

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

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

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

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

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

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