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看起來是一個不錯的候選者。