ImageMagick在Mac/Linux版本之间不一致的行为。Linux上损坏的CMYK文件
我是批量转换PDF的TIFF图像。
bash脚本在Mac上编写和测试，然后推送到Ubuntu机器上进行生产运行。(它有更好的规格)
奇怪的是，一些页面(大约每100个页面中就有一个)导出的图像被损坏。在多次运行后，镜像损坏发生在相同的页面上，这表明这不是随机的运行时错误。
使用相同的InDesign /X4配置文件从Adobe PDF CC2020导出页面。所有内容都遵循类似的文本合成和样式，放置在单色图像上。
左:正确/右:损坏
为了完整起见，我尝试了im6 (ubuntu20.4默认) convert命令，但得到了相同的结果。
这是我运行批处理的选项(通过GNU并行)。在我的脚本中，我可能做错了什么吗？
convert \
-verbose \
-alpha off \
-colorspace Gray \
-contrast-stretch 0 \
-depth 8 \
-compress zip \
-units PixelsPerInch \
-density 1200 \
${1} \
${1%.*}.tiff通过搜索，我发现im6和im7之间可能存在问题，以及它们如何处理颜色配置文件，但它们的版本匹配情况如下：
magick --version显示的版本
Mac (homebrew):
Version: ImageMagick 7.0.11-14 Q16 x86_64 2021-05-31 https://imagemagick.org
Copyright: (C) 1999-2021 ImageMagick Studio LLC
License: https://imagemagick.org/script/license.php
Features: Cipher DPC HDRI Modules OpenMP(5.0)
Delegates (built-in): bzlib fontconfig freetype gslib heic jng jp2 jpeg lcms lqr ltdl lzma openexr png ps tiff webp xml zlib
Ubuntu20.04 (v7 installed with https://github.com/SoftCreatR/imei/ )
Version: ImageMagick 7.0.11-14 Q32 x86_64 2021-05-17 https://imagemagick.org
Copyright: (C) 1999-2021 ImageMagick Studio LLC
License: https://imagemagick.org/script/license.php
Features: Cipher DPC HDRI Modules OpenMP(4.5)
Delegates (built-in): bzlib cairo djvu fftw fontconfig freetype gslib gvc heic jbig jng jp2 jpeg jxl lcms lqr ltdl lzma openexr pangocairo png ps raqm raw rsvg tiff webp wmf x xml zip zlib下面是从PDF文件中识别命令结果：
识别结果: PDF文件存在导出问题
Image:
Filename: 05.pdf
Format: PDF (Portable Document Format)
Mime type: application/pdf
Class: DirectClass
Geometry: 380x533+0+0
Resolution: 72x72
Print size: 5.27778x7.40278
Units: Undefined
Colorspace: CMYK
Type: ColorSeparation
Endianness: Undefined
Depth: 16/8-bit
Channel depth:
Cyan: 1-bit
Magenta: 1-bit
Yellow: 1-bit
Black: 8-bit识别结果: PDF文件没有问题：
Image:
Filename: 06.pdf
Format: PDF (Portable Document Format)
Mime type: application/pdf
Class: DirectClass
Geometry: 380x533+0+0
Resolution: 72x72
Print size: 5.27778x7.40278
Units: Undefined
Colorspace: sRGB
Type: PaletteAlpha
Base type: Undefined
Endianness: Undefined
Depth: 16/8-bit
Channel depth:
Red: 8-bit
Green: 8-bit
Blue: 8-bit
Alpha: 8-bit我注意到我似乎在使用CMYK色彩空间的文件时遇到了问题，而不是sRGB。
然而，对我来说，这并不能解释为什么它可以在Mac上运行，但不能在Ubuntu上运行。
也许是Ubuntu版本，包含了不同于Mac版本的CMYK库？有没有办法证实我的怀疑？
回答 1
Stack Overflow用户
发布于 2021-06-10 15:59:16
我可能已经到了一个工作地点。
问题似乎是从这一部分产生的：
Channel depth:
Cyan: 1-bit
Magenta: 1-bit
Yellow: 1-bit
Black: 8-bit原始图像用于单色打印。使得CMY的除K之外的所有通道都不包含数据，存储为比特深度1。
目前还不清楚为什么它可以在Mac上运行，但这里有一个版本也可以在Linux上运行：
convert \
-verbose \
-alpha off \
-colorspace CMYK \
-contrast-stretch 0 \
-depth 8 \
-channel black -negate -separate \
-compress zip \
-units PixelsPerInch \
-density 1200 \
${1} \
${1%.*}.tiff关键是首先在CMYK中渲染，因为原始PDF是用来渲染的。
然后剥离CMY通道，以创建纯灰度图像。(注:K通道需取反)
上面的代码片段在Mac/Linux上都可以一致地工作。
https://stackoverflow.com/questions/67914713
复制相似问题
腾讯云开发者
