Gulp：当一些图像损坏时对图像进行有损重新压缩答案

【问题标题】：Gulp: lossy recompression of images when some are brokenGulp：当一些图像损坏时对图像进行有损重新压缩
【发布时间】：2016-02-13 01:56:22
【问题描述】：

我有一组大约 18,000 个 jpg 文件需要优化/重新压缩。

我尝试了几乎所有的 gulp 图像优化插件，但每个插件在某些时候都会给出错误，并且没有建议是什么文件是它的原因。以下是gulp-image-resize 的结尾：

事件.js:141 投掷者； // 未处理的“错误”事件 ^ 错误：错误：命令失败：gm 识别：没有此图像格式的解码委托 (/var/folders/ns/85cnwvcx5ysb7jzr8hh_k4r80000gn/T/gmROZu8m)。 gm identify：请求未返回图像。完成时（/Users/mvasin/Sites/process images/node_modules/gulp-gm/index.js:40:21）在通用汽车（/Users/mvasin/Sites/process images/node_modules/async/lib/async.js:485:30）在 emitMany (events.js:108:13) 在 gm.emit (events.js:182:7) 在通用汽车（/Users/mvasin/Sites/process images/node_modules/gm/lib/getters.js:70:16）在 cb (/Users/mvasin/Sites/process images/node_modules/gm/lib/command.js:318:16) 在 ChildProcess.proc.on.onExit (/Users/mvasin/Sites/process images/node_modules/gm/lib/command.js:293:9) 在 emitTwo (events.js:87:13) 在 ChildProcess.emit (events.js:172:7) 在可能关闭（内部/child_process.js:817:16）

这是gulp-gm的蓝屏：

事件.js:141 投掷者； // 未处理的“错误”事件 ^ 错误：流产生空缓冲区在套接字。（/Users/mvasin/Sites/process images/node_modules/gm/lib/command.js:57:17）在 emitNone (events.js:72:20) 在 Socket.emit (events.js:166:7) 在 endReadableNT (_stream_readable.js:893:12) 在 doNTCallback2 (node.js:429:9) 在 process._tickCallback (node.js:343:17) a228：处理图像 mvasin$ gulp GraphicsMagick

gulp-responsive:

事件.js:141 投掷者； // 未处理的“错误”事件 ^ 错误：输入缓冲区包含不受支持的图像格式在错误（本机）

gulp-sharp-resize:

未处理的拒绝错误：输入缓冲区包含不受支持的图像格式在错误（本机）

漂亮！我将整理我所有的 18,000 张图像，并希望能找出“不支持的图像格式”的图像。留下来，我马上回来。
现在来imagemin-jpeg-recompress：

事件.js:141 投掷者； // 未处理的“错误”事件 ^ 错误：不支持的颜色转换请求在子进程。 (/Users/mvasin/Sites/process images/node_modules/imagemin-jpeg-recompress/index.js:101:11) 在 emitTwo (events.js:87:13) 在 ChildProcess.emit (events.js:172:7) 在可能关闭（内部/child_process.js:817:16）在套接字。（内部/child_process.js:319:11）在 emitOne (events.js:77:13) 在 Socket.emit (events.js:169:7) 在 Pipe._onclose (net.js:469:12)

你明白了……

gulp-imagemin 也会因错误而停止。

我尝试求助于桌面 mac 应用 ImageOptim（它在设置的深处有“有损”），但在非常大的图像集上，由于内部错误，它会在中间某个时间静默停止处理。

我还是想保留 gulp 工作流程。

【问题讨论】：

您是否处于可以在终端中针对您的图像运行简单的 shell 命令的环境中？如果是这样，ImageMagick 有一个名为identify 的工具可以检查图像的完整性。您可以将其与GNU Parallel 结合起来，以完成一些非常快速的检查...尝试复制几百个并运行此parallel identify ::: *.jpg
感谢您的提示，马克！如何递归检查图像？它跨越内部目录，parallel identify ::: *.jpg 给出“识别：无法打开图像`**/*.jpg'：没有这样的文件或目录@error/blob.c/OpenBlob/2701”错误。
试试find topDirectory -name \*.jpg | parallel identify {}
它给出了一个非常详细的输出，但我偶尔会找到一种方法：我最后用> test.txt 运行它。它将文件信息打印到test.txt 并将错误文件直接输出到控制台。现在我将尝试手动删除它们，看看它是否有助于吞咽插件。
不，它没有帮助。我检查了两次，运行上面的命令以确保没有错误图像，仍然得到events.js:141 throw er; // Unhandled 'error' event。这是一件很奇怪的事情！这种关于吞咽图像的嗡嗡声，虽然如果源图像文件不是无菌的，那么它对于目前的实际项目并不是很有用。

标签： imagemagick gulp gulp-imagemin

【解决方案1】：

您可以使用gulp-plumber 来防止在不正确的图像上停止 gulp 任务。

它还可以显示哪个图像导致错误。

var gulp = require('gulp');
var $ = require('gulp-load-plugins')();

gulp.task('images', function() {
  return gulp.src('src/*.jpg')
    .pipe($.plumber())
    .pipe($.responsive({
      ...
    }))
    .pipe(gulp.dest('dist'));
});

【讨论】：

【解决方案2】：

使用 GNU Parallel 和 ImageMagick，您可以像这样重新压缩所有 JPEG 图像并剥离 EXIF 数据：

parallel convert {} -quality 70% -strip {} ::: *.jpg

两个{} 分别代表输入文件名和输出文件名。请在您的文件副本上尝试此操作，并检查您是否对结果以及版权和 EXIF 数据被剥离后是否满意，然后再对您的真实数据执行此操作。

如果你有太多的文件需要 shell 扩展，你可以通过stdin 将文件名注入如下：

find TOPDIR -iname *.jpg | parallel convert {} -quality 70% -strip {}

我自己不使用pngcrush，但假设你可以这样做：

parallel pngcrush {} {} ::: *.png

如果您喜欢观看进度表并想要预计到达时间，请在 parallel 后面添加 --eta。

parallel --eta pngcrush {} {} ::: *.png

【讨论】：

成功了！与gulp-shell 一起，它可能会让人大吃一惊。
为什么不将 ImageMagick 也用于 png？
::: 是 GNU Parallel 语法，用于指示命令的结束和参数的开始。

【解决方案3】：

嗯，也许这对某人有帮助：还要花几个小时来围绕这些奇怪的 imagemagick 错误消息。在我的情况下，对源图像路径的简单修正解决了它：

gulp.src('path/to/imagesrc/*') 对比 gulp.src('path/to/imagesrc/*.jpg')

我的 gulp 任务会立即在 imagesrc 文件夹中创建一个缩略图文件夹。这就是问题所在。 * 选择器包含此缩略图文件夹并将其通过管道传递给 imagemagick 函数，这些函数肯定无法处理它。

【讨论】：