ios vimage_iOS中vImage的注意事项

ios vimage

iOS offers two frameworks for hardware-accelerated image-processing:

iOS提供了两个用于硬件加速图像处理的框架：

• Core Image
  核心形象

• vImage

  影像

What are some differences between them?

它们之间有什么区别？

First, Core Image runs on the GPU [1]. By contrast, vImage runs on the CPU only, using vector instructions.

首先 ，Core Image在GPU上运行[1]。 相比之下，vImage仅使用矢量指令在CPU上运行。

Second, vImage is a C library. There are no classes, only structs and global functions that take them as parameters. Core Image, on the other hand, is an object-oriented library: images are represented by a CIImage object.

其次 ，vImage是一个C库。 没有类，只有将它们作为参数的结构和全局函数。 另一方面，Core Image是一个面向对象的库：图像由CIImage对象表示。

Third, Core Image has a lot of magic going on. For example, if you crop an image, you get back a new CIImage object. CIImage objects are immutable. You get back a new object rather than having the existing one change.

第三 ，Core Image正在进行很多魔术。 例如，如果裁剪图像，则将获得一个新的CIImage对象。 CIImage对象是不可变的。 您取回一个新对象，而不是对现有对象进行更改。

But the actual crop isn’t done till the results are needed. But if you modify the underlying buffer of the source image, the destination CIImage, which is supposed to be immutable, changes. So the abstraction can break.

但是实际的作物直到需要结果时才完成 。 但是，如果您修改了源映像的基础缓冲区，则应该是不变的目标CIImage会更改 。 因此，抽象可能会中断。

If you blend two images A and B, then blend the result with C, resulting in D, and release A, B and C, because of lazy evaluation, D has internal references to A, B and C. If you do this in a loop, you consume an unbounded amount of memory. This took me weeks to debug since I didn’t know what Core Image was doing internally.

如果混合两个图像A和B，然后将结果与C混合，得到D，然后释放A，B和C，这是由于懒惰求值，D在内部引用了A，B和C。循环，您将消耗无限的内存。 由于我不知道Core Image在内部做什么，这花了我数周的时间进行调试。

If you perform a sequence of operations, Core Image can sometimes merge them into one, for better performance. A CIImage isn’t an image — it’s a recipe to produce an image when needed.

如果执行一系列操作，Core Image有时可以将它们合并为一个，以获得更好的性能。 CIImage不是图像，而是在需要时生成图像的方法。

vImage is much simpler — a vImage_Buffer represents an actual bitmap. There’s no lazy evaluation, no magic. For Futurecam, I’d have preferred no magic.

vImage更加简单-vImage_Buffer代表实际的位图。 没有懒惰的评价，没有魔术。 对于Futurecam ，我希望没有魔术。

Fourth, Core Image is faster. In one test, Core Image processed 12MP images at 100+ FPS, while vImage processed at 20 FPS.

第四 ，Core Image更快。 在一项测试中，Core Image以100+ FPS的速度处理12MP图像，而vImage以20 FPS的速度处理。

关于vImage的注意事项 (Notes About vImage)

vImage represents an image buffer using a vImage_Buffer. This is a simple C struct containing a pointer, width, height and pixel format.

vImage表示使用vImage_Buffer的图像缓冲区。 这是一个简单的C结构，包含指针，宽度，高度和像素格式。

vImage offers different pixel formats, both floating point and integer.

vImage提供了不同的像素格式，包括浮点数和整数。

The integer ones are only 8 bits per channel. This may be fine for storing an image, but when processing it, say averaging two images by adding them and then dividing by 2, you don’t want the result of the addition to overflow if the sum is > 255. So it helps to have a higher range. That’s why you should consider a floating-point pixel format, where each channel is a 32-bit float. vImage offers two such formats: RGBA_FFFF or ARGB_FFFF.

整数为每个通道只有8位。 这对于存储图像可能很好，但是在处理图像时，例如将两个图像相加然后除以2，就可以得出平均值，如果总和> 255，您不希望相加的结果溢出。因此，这样做有助于有更高的射程 因此，您应该考虑浮点像素格式，其中每个通道都是32位浮点数。 vImage提供了两种此类格式：RGBA_FFFF或ARGB_FFFF。

vImage is internally multi-threaded: different rows [2] of the image are processed using different threads. Don’t create a thread pool to perform vImage operations in parallel, since there’s already one inside the vImage framework.

vImage是内部多线程的：使用不同的线程处理图像的不同行[2]。 不要创建线程池来并行执行vImage操作，因为vImage框架中已经存在一个线程池。

vImage is part of the Accelerate framework, which has other libraries like vDSP and vecLib.

vImage是Accelerate框架的一部分，该框架具有其他库，例如vDSP和vecLib 。

[1] Though you can set a flag to force it to use the CPU.

[1]尽管可以设置一个标志来强制它使用CPU。

[2] Or columns or whatever.

[2]或栏或其他内容。

翻译自: https://medium.com/@karti/notes-on-vimage-in-ios-437d117a6804

ios vimage