3

我们的计算机一次获取数百张图像，我们需要尽可能快地旋转和调整它们的大小。旋转 90、180 或 270 度。

目前我们正在使用命令行工具GraphicsMagick来旋转图像。旋转图像 (5760*3840 ~ 22MP) 大约需要 4 到 7 秒。

以下python代码遗憾地给了我们相同的结果

import cv
img = cv.LoadImage("image.jpg")
timg = cv.CreateImage((img.height,img.width), img.depth, img.channels) # transposed image

# rotate counter-clockwise
cv.Transpose(img,timg)
cv.Flip(timg,timg,flipMode=0)
cv.SaveImage("rotated_counter_clockwise.jpg", timg)

有没有更快的方法来利用显卡的力量来旋转图像？想到 OpenCL 和 OpenGL，但我们想知道性能提升是否会显着。

我们使用的硬件相当有限，因为设备应该尽可能小。

该软件是带有官方（闭源）radeon 驱动程序的 debian 6。

4

3 回答 3

12

您可以执行无损旋转，只修改 EXIF 部分。这将更快地旋转您的图片。

并查看执行无损 jpeg 修改的 jpegtran 实用程序。 https://linux.die.net/man/1/jpegtran

于 2012-07-09T14:33:32.777 回答
4

irfanview有一个 jpeg no-recompression 插件，IIRC 可以在不重新压缩的情况下旋转和调整图像大小（以简单的方式），它还可以运行图像目录 - 这应该快得多

GPU可能无济于事，您几乎可以肯定在opencv中受到I / O限制，它并不是真正适合高速文件访问

于 2012-07-09T14:27:10.273 回答
1

我不是 jpeg 和压缩主题方面的专家，但是由于您的问题几乎受到 I/O 限制（假设您可以在没有大量与解码/编码相关的计算的情况下旋转），您可能无法在你拥有的 GPU 上加速它。(Un) 幸运的是，您的参考资料是一个相当慢的 Atom CPU。

我假设 Radeon 有单独的主内存。这意味着数据需要通过 PCI-E 进行通信，与 CPU 执行相比，这是额外的延迟，并且在不隐藏的情况下，您可以确定它是瓶颈。这是您在 GPU 上使用 OpenCV 的代码很慢的最可能原因（除了您执行两个内存绑定操作，转置和翻转，而不是单个操作）。

关键是通过使用multi-buffering尽可能多地隐藏计算的 PCI-E 传输时间。仅当相关卡具有双 DMA 引擎（如高端 Radeon或NVIDIA Quadro/Tesla 卡）时，才能通过利用 PCI-E 的全双工功能将 GPU 与 GPU 之间的传输与计算重叠——我非常怀疑。

如果您的 GPU 计算时间（GPU 进行旋转所需的时间）低于传输所需的时间，您将无法完全重叠。HD 4530 有一个相当慢的内存接口，峰值只有12.8 Gb/s，旋转内核应该是相当受内存限制的。但是，我只能猜测，但我想说的是，如果您达到约 1.5 Gb/s（4x PCI-E AFAIK）的峰值 PCI-E 传输速率，计算内核将比传输快几倍，而您将能够重叠很少。您可以简单地分别对各个部分进行计时，而无需复杂的异步代码，并且您可以估计获得具有最佳重叠的事物的速度。

您可能要考虑的一件事是获得不会将 PCI-E 视为瓶颈的硬件，例如：

  • 基于AMD APU的系统。在这些平台上，您将能够页面锁定内存并直接从 GPU 使用它；
  • 与主机共享主存的集成 GPU；
  • 一个快速的低功耗 CPU，例如移动 Intel Ivy Bridge，例如i5-3427U，它的消耗几乎与Atom D525一样少，但支持 AVX，并且应该快几倍。
于 2012-07-10T23:15:10.987 回答