linux - Docker 容器上的 ImageMagick 生成格式错误的 PNG 图像-6ren

linux - Docker 容器上的 ImageMagick 生成格式错误的 PNG 图像

转载作者：塔克拉玛干更新时间：2023-11-03 01:16:02

我将尝试在这里非常具体，所以这可能会很长。

目标:尝试在 Docker 容器中将 SVG 文件转换为 PNG

问题:ImageMagick 在容器中生成格式错误的 PNG 图像，而在普通机器上它没问题

SVG 文件:https://jsfiddle.net/ochaws/qezxnwfo/3/

Dockerfile:

FROM ubuntu:bionic
RUN apt-get update 
ADD . /home
CMD /bin/bash

命令:$ convert mychart.svg mychart.png

主机上的结果 PNG:

容器上的结果 PNG:

不仅图像的 3/4 完全乱七八糟，而且矩形也没有填充，线条也被重新绘制。我不知道 imagemagick 如何转换它。

我尝试过的事情:

我。检查二进制文件差异 比较主机和容器 (ldd|md5sum) 之间 imagemagick 及其依赖项的二进制文件，以获得可能触发可能错误的二进制文件之间的差异:

在容器上:

root@73075bf64797:/var/www/html# ldd /usr/bin/convert | grep -Eo '/(usr|lib)/.*\s' | xargs md5sum | sort
015730545ba1a5ff1e0f500ffbb651d5  /usr/lib/x86_64-linux-gnu/libMagickCore-6.Q16.so.3
0a2ec219b7d2050e4c0916d1dee14853  /lib/x86_64-linux-gnu/librt.so.1
24492a17e8dd9a9e853cd1cfdf5fc0a3  /usr/lib/x86_64-linux-gnu/libMagickWand-6.Q16.so.3
27ce2618cfd426b2f8eefa6536e0824c  /usr/lib/x86_64-linux-gnu/libltdl.so.7
2b7d964ae89f9782df099985e73c707b  /lib/x86_64-linux-gnu/libpcre.so.3
3b053e7e77c4a5857607de25806a6e90  /usr/lib/x86_64-linux-gnu/libfftw3.so.3
4c659326fdbac8a684298ccba999cc5c  /lib/x86_64-linux-gnu/libm.so.6
50390b2ae8aaa73c47745040f54e602f  /lib/x86_64-linux-gnu/libc.so.6
65fd13ef7996608743284fc1210113f1  /lib/x86_64-linux-gnu/libz.so.1
6809901459f3a5ca2c38add3190b539c  /lib/x86_64-linux-gnu/libbsd.so.0
724ac03acbf82b09cb490b03e1714f76  /usr/lib/x86_64-linux-gnu/libxcb.so.1
7444e02ab2de54f5503acd626c99d4b0  /lib/x86_64-linux-gnu/libgcc_s.so.1
79381074c86ff3a86f4fd442892a99b3  /usr/lib/x86_64-linux-gnu/libfreetype.so.6
a01caee197b17c9586543a876bf6fd0a  /lib/x86_64-linux-gnu/libdl.so.2
a1282326e753a31f0810161768948999  /usr/lib/x86_64-linux-gnu/libX11.so.6
a4566a3af75553930d970377533deb14  /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
a5300acb8e2e5c04a078fa0f6949f18a  /usr/lib/x86_64-linux-gnu/libfontconfig.so.1
ae99268b6d518fb9b24c234ccfa6f791  /lib/x86_64-linux-gnu/libpthread.so.0
b34ed25caf9e14f71b7b41af34f1890f  /usr/lib/x86_64-linux-gnu/libpng16.so.16
b4cbe573b069bfd23039332e6cc113b7  /usr/lib/x86_64-linux-gnu/libgomp.so.1
b62a4e6888012062c60c41dea847f565  /lib/x86_64-linux-gnu/libexpat.so.1
b880122a03e775f6f5c548167e7bf179  /usr/lib/x86_64-linux-gnu/libXdmcp.so.6
ba7877e10828c3985c6246381569e58c  /lib/x86_64-linux-gnu/libbz2.so.1.0
c265ba007d786e5086e209e6260839ce  /usr/lib/x86_64-linux-gnu/libXau.so.6
c599b6af9146a6730ce1a35f63d0233f  /usr/lib/x86_64-linux-gnu/libXext.so.6
cacf55a898630c666e17233bbcd174f5  /usr/lib/x86_64-linux-gnu/liblqr-1.so.0
df13a9c0be51bcb5ba09787c6594e264  /usr/lib/x86_64-linux-gnu/liblcms2.so.2

在主机上:

[0|0] /home $ ldd /usr/bin/convert | grep -Eo '/(usr|lib)/.*\s' | xargs md5sum | sort
015730545ba1a5ff1e0f500ffbb651d5  /usr/lib/x86_64-linux-gnu/libMagickCore-6.Q16.so.3
0a2ec219b7d2050e4c0916d1dee14853  /lib/x86_64-linux-gnu/librt.so.1
24492a17e8dd9a9e853cd1cfdf5fc0a3  /usr/lib/x86_64-linux-gnu/libMagickWand-6.Q16.so.3
27ce2618cfd426b2f8eefa6536e0824c  /usr/lib/x86_64-linux-gnu/libltdl.so.7
2b7d964ae89f9782df099985e73c707b  /lib/x86_64-linux-gnu/libpcre.so.3
3b053e7e77c4a5857607de25806a6e90  /usr/lib/x86_64-linux-gnu/libfftw3.so.3
4c659326fdbac8a684298ccba999cc5c  /lib/x86_64-linux-gnu/libm.so.6
50390b2ae8aaa73c47745040f54e602f  /lib/x86_64-linux-gnu/libc.so.6
65fd13ef7996608743284fc1210113f1  /lib/x86_64-linux-gnu/libz.so.1
6809901459f3a5ca2c38add3190b539c  /lib/x86_64-linux-gnu/libbsd.so.0
724ac03acbf82b09cb490b03e1714f76  /usr/lib/x86_64-linux-gnu/libxcb.so.1
7444e02ab2de54f5503acd626c99d4b0  /lib/x86_64-linux-gnu/libgcc_s.so.1
79381074c86ff3a86f4fd442892a99b3  /usr/lib/x86_64-linux-gnu/libfreetype.so.6
a01caee197b17c9586543a876bf6fd0a  /lib/x86_64-linux-gnu/libdl.so.2
a1282326e753a31f0810161768948999  /usr/lib/x86_64-linux-gnu/libX11.so.6
a4566a3af75553930d970377533deb14  /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
a5300acb8e2e5c04a078fa0f6949f18a  /usr/lib/x86_64-linux-gnu/libfontconfig.so.1
ae99268b6d518fb9b24c234ccfa6f791  /lib/x86_64-linux-gnu/libpthread.so.0
b34ed25caf9e14f71b7b41af34f1890f  /usr/lib/x86_64-linux-gnu/libpng16.so.16
b4cbe573b069bfd23039332e6cc113b7  /usr/lib/x86_64-linux-gnu/libgomp.so.1
b62a4e6888012062c60c41dea847f565  /lib/x86_64-linux-gnu/libexpat.so.1
b880122a03e775f6f5c548167e7bf179  /usr/lib/x86_64-linux-gnu/libXdmcp.so.6
ba7877e10828c3985c6246381569e58c  /lib/x86_64-linux-gnu/libbz2.so.1.0
c265ba007d786e5086e209e6260839ce  /usr/lib/x86_64-linux-gnu/libXau.so.6
c599b6af9146a6730ce1a35f63d0233f  /usr/lib/x86_64-linux-gnu/libXext.so.6
cacf55a898630c666e17233bbcd174f5  /usr/lib/x86_64-linux-gnu/liblqr-1.so.0
df13a9c0be51bcb5ba09787c6594e264  /usr/lib/x86_64-linux-gnu/liblcms2.so.2

结论:二进制文件在主机和容器中完全相同，所以我想我可以推出它。

二。使用 valgrind 在两种环境中检查内存行为:

在容器上:

root@b0b319995ed0:/home# valgrind --leak-check=full convert blue_charts.svg blue_charts.png
==1390== Memcheck, a memory error detector
==1390== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==1390== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==1390== Command: convert blue_charts.svg blue_charts.png
==1390== 
==1390== 
==1390== HEAP SUMMARY:
==1390==     in use at exit: 191,228 bytes in 2,905 blocks
==1390==   total heap usage: 359,830 allocs, 356,925 frees, 146,363,268 bytes allocated
==1390== 
==1390== 288 (256 direct, 32 indirect) bytes in 1 blocks are definitely lost in loss record 85 of 129
==1390==    at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1390==    by 0x628E8ED: ??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.10.1)
==1390==    by 0x628F096: ??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.10.1)
==1390==    by 0x6290377: ??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.10.1)
==1390==    by 0x62959C3: ??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.10.1)
==1390==    by 0x8011DE7: ??? (in /lib/x86_64-linux-gnu/libexpat.so.1.6.7)
==1390==    by 0x8012BBB: ??? (in /lib/x86_64-linux-gnu/libexpat.so.1.6.7)
==1390==    by 0x8010802: ??? (in /lib/x86_64-linux-gnu/libexpat.so.1.6.7)
==1390==    by 0x80114C4: ??? (in /lib/x86_64-linux-gnu/libexpat.so.1.6.7)
==1390==    by 0x801508C: XML_ParseBuffer (in /lib/x86_64-linux-gnu/libexpat.so.1.6.7)
==1390==    by 0x6294B42: ??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.10.1)
==1390==    by 0x6294F75: FcConfigParseAndLoad (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.10.1)
==1390== 
==1390== 912 bytes in 3 blocks are possibly lost in loss record 100 of 129
==1390==    at 0x4C31B25: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1390==    by 0x40134A6: allocate_dtv (dl-tls.c:286)
==1390==    by 0x40134A6: _dl_allocate_tls (dl-tls.c:530)
==1390==    by 0x7ADA227: allocate_stack (allocatestack.c:627)
==1390==    by 0x7ADA227: pthread_create@@GLIBC_2.2.5 (pthread_create.c:644)
==1390==    by 0x76A1209: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==1390==    by 0x76980DD: GOMP_parallel (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==1390==    by 0x4F5A1D0: SetImageOpacity (in /usr/lib/x86_64-linux-gnu/libMagickCore-6.Q16.so.3.0.0)
==1390==    by 0x4E98930: SetImageAlphaChannel (in /usr/lib/x86_64-linux-gnu/libMagickCore-6.Q16.so.3.0.0)
==1390==    by 0x4EFAD4D: ??? (in /usr/lib/x86_64-linux-gnu/libMagickCore-6.Q16.so.3.0.0)
==1390==    by 0x4F0465B: DrawPrimitive (in /usr/lib/x86_64-linux-gnu/libMagickCore-6.Q16.so.3.0.0)
==1390==    by 0x4F0674C: DrawImage (in /usr/lib/x86_64-linux-gnu/libMagickCore-6.Q16.so.3.0.0)
==1390==    by 0xDA1636F: ???
==1390==    by 0x4EC098E: ReadImage (in /usr/lib/x86_64-linux-gnu/libMagickCore-6.Q16.so.3.0.0)
==1390== 
==1390== LEAK SUMMARY:
==1390==    definitely lost: 256 bytes in 1 blocks
==1390==    indirectly lost: 32 bytes in 1 blocks
==1390==      possibly lost: 912 bytes in 3 blocks
==1390==    still reachable: 190,028 bytes in 2,900 blocks
==1390==         suppressed: 0 bytes in 0 blocks
==1390== Reachable blocks (those to which a pointer was found) are not shown.
==1390== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==1390== 
==1390== For counts of detected and suppressed errors, rerun with: -v
==1390== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)

在主机上:

[0|0] /home $ valgrind --leak-check=full convert blue_charts.svg blue_charts_local.png 
==17898== Memcheck, a memory error detector
==17898== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==17898== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==17898== Command: convert blue_charts.svg blue_charts_local.png
==17898== 
==17898== 
==17898== HEAP SUMMARY:
==17898==     in use at exit: 98,349 bytes in 23 blocks
==17898==   total heap usage: 4,253 allocs, 4,230 frees, 6,204,037 bytes allocated
==17898== 
==17898== LEAK SUMMARY:
==17898==    definitely lost: 0 bytes in 0 blocks
==17898==    indirectly lost: 0 bytes in 0 blocks
==17898==      possibly lost: 0 bytes in 0 blocks
==17898==    still reachable: 98,349 bytes in 23 blocks
==17898==         suppressed: 0 bytes in 0 blocks
==17898== Reachable blocks (those to which a pointer was found) are not shown.
==17898== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==17898== 
==17898== For counts of detected and suppressed errors, rerun with: -v
==17898== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

结论:与主机(6,204,037 字节)相比，容器上的 imagemagick 占用了大量内存(146,363,268 字节)。此外，当在容器上运行时，libfontconfig 和 libMagickCore-6.Q16 存在一些内存泄漏，而且我不知道它们在哪里(不能在 Docker 中运行 GDB 或 strace)，而且我也不太愿意下去这条路因为相同的二进制文件表现得很奇怪，因为容器是唯一的区别。

抱歉，文本太大，但我没有调试它的选项。有帮助吗？

最佳答案

我也遇到了同样的问题。使用 Docker 时图像格式不正确，因为容器尚未安装 Inkscape。显然，Imagemagic 使用 Inkscape 转换 SVG(如果它在路径上)。

因此将以下行添加到 Dockerfile 可以解决问题:

RUN apt-get update && apt-get -y install inkscape

有more information在 Imagemagic 论坛上。

关于linux - Docker 容器上的 ImageMagick 生成格式错误的 PNG 图像，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/51733717/

文章推荐： c++ - C++中对象的动态内存分配

文章推荐： java - 单元测试在 Debug模式下终止

文章推荐： c++ - 奇怪的 C++ 模板方法特化问题

文章推荐： c++ - 您如何跟踪每个功能提供的异常安全保证

javascript - 单击 [提交] -> 隐藏 DIV 容器 1 -> 显示 DIV 容器 2 -> 加载在 DIV 容器 2 中的 .PHP 文件中找到的 DIV
这是我想做的 1 - 点击提交 2 - 隐藏 DIV 容器 1 3 - 显示 DIV 容器 2 4 - 将“PricingDisclaimer.php”中找到的所有 DIV 加载到 Div 容器 2
ios - 如何访问另一个应用程序的 iCloud 容器(使用另一个开发人员配置文件开发的应用程序和在该配置文件中创建的 icloud 容器)？
我有一个 ios 应用程序，它使用 iCloudcontainer 来保存用户的一些数据，例如用户的“到期日期”。我要用不同的方式创建应用程序的副本开发者账号。我要将用户从第一个应用程序迁移到第二个应
docker - 如何从一个 docker 容器 ssh 到另一个 docker 容器？
这是场景。我有三个容器。 Container1、container2 和 container3(基于 Ubuntu 的镜像)，其中 container2 充当容器 1 和容器 2 之间的路由器。我
java - 容器是什么意思？ Web 容器、JSP 容器还是 Spring 容器？
关闭。这个问题需要多问focused 。目前不接受答案。想要改进此问题吗？更新问题，使其仅关注一个问题 editing this post . 已关闭 9 年前。 Improve this ques
docker - Jenkins:从与代理(另一个 Docker 容器)一起运行的阶段连接到 Docker 容器
我正在改造管道以使用声明式管道方法，以便我能够 to use Docker images在每个阶段。目前我有以下工作代码，它执行连接到在 Docker 容器中运行的数据库的集成测试。 node {
java - 部署到 Web 容器、捆绑 Web 容器或嵌入 Web 容器
我正在开发一个需要尽可能简单地为最终用户安装的应用程序。虽然最终用户可能是经验丰富的 Linux 用户(或销售工程师)，但他们对 Tomcat、Jetty 等并不真正了解，我认为他们也不应该了解。所
kubernetes - 无法获取cpu pod指标，k8s-容器-容器-shim-runsc-v1-gvisor
我从gvisor-containerd-shim(Shim V1)移到了containerd-shim-runsc-v1(Shim V2)。在使用gvisor-containerd-shim的情况下，
docker-compose - docker 容器 A 可以使用什么 URL 访问另一个 docker 容器 B(相同的开发机器，不同的项目)
假设我们只在某些开发阶段很少需要这样做(冒烟测试几个 api 调用)，让项目 Bar 中的 dockerized web 服务访问 Project Foo 中的 dockerized web 服务的最
docker - 使用 Windows 容器(而不是 Linux 容器)时如何在 Docker for Windows 10 中创建数据卷
各位，我的操作系统是 Windows 10，运行的是 Docker 版本 17.06.0-ce-win19。我在 Windows 容器中运行 SQL Server Express，并且希望将 SQL
Azure 容器
谁能告诉我，为什么我们不能在 Azure 存储中的容器内创建容器？还有什么方法可以处理，我们需要在 azure 存储中创建目录层次结构？最佳答案您无法在容器中创建容器，因为 Windows Azu
另一个容器内的c++容器
#include template struct Row { Row() { puts("Row default"); } Row(const Row& other) { puts
tomcat - 容器
按照目前的情况，这个问题不适合我们的问答形式。我们希望答案得到事实、引用或专业知识的支持，但这个问题可能会引发辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开，visit the
06、RDF 容器
RDF容器用于描述一组事物例如，把一本书的所有作者列在一起 RDF容器有三种类型： <Bag> <Seq> <Alt> <rdf:
仅当基础类型执行相等时才实现相等的 F# 容器
编辑:从到目前为止添加的答案和评论看来，我没有正确解释我想要什么。下面是一个例子: // type not supporting any type of comparison [] [] type b
php - 有没有办法在子进程中传递服务/容器？
我正在测试 spatie 的异步项目。我创建了一个这样的任务。 use Spatie\Async\Task; class ServiceTask extends Task { protecte
Azure Blob 容器
我想使用 Azure Blob 存储来上传和下载文档。有一些公司可以上传和下载他们的文档。我想保证这些文件的安全。这意味着公司只能看到他们的文件。不是别人的。我可以在 blob 容器中创建多个文件夹
Azure 容器 - 与远程容器实例上的文件交互
我正在尝试与 Azure 中的容器实例进行远程交互。我已执行以下步骤: 已在本地注册表中加载本地镜像 docker load -i ima.tar 登录远程 ACR docker登录--用户名--密码
docker - 带有Dockerfile项目的Dokku多进程(容器)
我正在研究http://progrium.viewdocs.io/dokku/process-management/，并试图弄清楚如何从单个项目中运行多个服务。我有一个Dockerfile的仓库:
依赖于其他容器中的文件的 Docker 容器
我有一个想要容器化的单体应用程序。文件夹结构是这样的: --app | |-file.py <-has a variable foo that is passed in --configs
保留数据的 Docker 容器
我正在学习 Docker，并且一直在为 Ubuntu 容器制作 Dockerfile。我的问题是我不断获取不同容器之间的持久信息。我已经退出，移除了容器，然后移除了它的图像。在对 Dockerfil

塔克拉玛干

个人简介

我是一名优秀的程序员,十分优秀！

作者热门文章

滴滴打车优惠券免费领取

全站热门文章

首页

博学

6Ren·AI

商城

linux - Docker 容器上的 ImageMagick 生成格式错误的 PNG 图像

我尝试过的事情: