Core Image 的高级应用

本文内容归纳整理自 Core Image 你需要了解的那些事~，仅作学习用途。如有侵权，请联系博主删除。

一、获取 CIImage

为了获取 CIImage 图像，很多同学会直接通过 UIImage.CIImage 的方式去获取，但是这样的方式是无法保证获取到 CIImage 对象的。CIImage 属性定义如下：

@property(nullable,nonatomic,readonly) CIImage *CIImage NS_AVAILABLE_IOS(5_0);
 // returns underlying CIImage or nil if CGImageRef based

这里已经明确说明了，UIImage 对象可能不是基于 CIImage 创建的（比如它是由 imageWithCIImage: 生成的），这样就无法获取到 CIImage 对象。

正确的方式应为：

CIImage *ciImage = [[CIImage alloc] initWithImage:[UIImage imageNamed:imageName]];

二、CIContext

在创建结果 UIImage 的时候，最简单的方式就是通过 imageWithCIImage: 来实现。这种情况下，不需要显示的定义 CIContext 对象，因为 imageWithCIImage: 方法内部自动完成了这个步骤。这使得使用 Core Image 更加的方便。当然，它也引起了另外一个问题。每次都会重新创建一个 CIContext 对象 ，而创建 CIContext 对象的代价是非常高的。

并且，CIContext 和 CIImage 对象是不可变对象，在线程之间共享这些对象是安全的。所以多个线程可以使用同一个 GPU 或者 CPU 的 CIContext 对象来渲染 CIImage 对象。

所以，重用 CIContext 是很有必要的。这意味着，我们不应该使用 imageWithCIImage: 方法来生成 UIImage，而应该自己创建维护 CIContext。

比如：

self.context = [CIContext contextWithOptions:nil];

...
 
CGImageRef cgImage = [self.context createCGImage:outputImage fromRect:[outputImage extent]];
UIImage *image = [UIImage imageWithCGImage:cgImage];

三、GPU / CPU

Core Image 的另外一个优势，就是可以根据需求选择 CPU 或者 GPU 来处理。在 CIContext 创建的时候，我们可以给它设置为基于 GPU 还是 CPU。

基于 GPU 的话，处理速度更快。以为利用了 GPU 的硬件并行优势。可以使用 OpenGL ES 或者 Metal 来渲染图像。这种方式 CPU 完全没有负担，应用程序的运行循环不会受到图像渲染的影响。

但是 GPU 受限于硬件纹理尺寸，而且如果你的程序在后台继续处理和保存图片的话，那么需要使用 CPU。因为当应用切换到后台状态时，GPU 处理会被打断。使用 CPU 渲染的 iOS 会采用 GCD 来对图像进行渲染。这保证了 CPU 渲染在大部分情况下更可靠，比 GPU 渲染更容易使用，可以在后台实现渲染过程。

综上，对于复杂图像滤镜，使用 GPU 更好。但如果在处理视频过程中，保存文件或保存照片到照片库中时，为避免程序进入后台对图片保存造成影响，这时应该使用 CPU 进行渲染。

用官方的一句话来描述再合适不过了：

CPU is still what will give you the best fidelity where as the GPU will give you the best performance.
大体意思：GPU 总是能提供最好的性能，而 CPU 能给你提供最好的精确性。

四、GPU / CPU 的创建方式

具体设置方式：

// 创建基于 CPU 的 CIContext 对象 (默认是基于 GPU，CPU 需要额外设置参数)
context = [CIContext contextWithOptions: [NSDictionary dictionaryWithObject:[NSNumber numberWithBool:YES] forKey:kCIContextUseSoftwareRenderer]];

// 创建基于 GPU 的 CIContext 对象
context = [CIContext contextWithOptions: nil];

// 创建基于 GPU 的 CIContext 对象
EAGLContext *eaglctx = [[EAGLContext alloc] initWithAPI:kEAGLRenderingAPIOpenGLES2];
context = [CIContext contextWithEAGLContext:eaglctx];

同样是基于 GPU 的，它们之间也是有区别的。

1. contextWithOptions 创建的 context 并没有实时性能，虽然渲染是在 CPU 上执行，但是其输出的 image 是不能显示的。只有当其被复制回 CPU 存储器上时，才会被转成一个可被显示的 image 类型，比如 UIImage。

它的渲染过程大致如下：

contextWithOptions 创建的基于 GPU 的 context 处理流程
当使用 Core Image 在 GPU 上渲染图片的时候，先是把图像传递到 GPU 上，然后执行滤镜相关操作。但是当需要生成 CGImage 对象的时候，图像又被复制回 CPU 上。最后要在视图上显示的时候，又返回 GPU 进行渲染。这样在 GPU 和 CPU 之前来回切换，会造成很严重的性能损耗。

2. contextWithEAGLContext 创建的 context 支持实时渲染，渲染图像的过程始终在 GPU 上进行，并且永远不会复制回 CPU 存储器上，这就保证了更快的渲染速度和更好的性能。当然，这个前提是利用实时渲染的特效，而不是每次操作都产生一个 UIImage，然后再设置到视图上。比如 OpenGL ES:

// 设置 OpenGLES 渲染环境
EAGLContext *eaglContext = [[EAGLContext alloc] initWithAPI:kEAGLRenderingAPIOpenGLES2];
self.glkView.context = eaglContext;
self.context = [CIContext contextWithEAGLContext:eaglContext];
...
  
// 实时渲染
[self.pixellateFilter setValue:@(sender.value) forKey:@"inputRadius"];

[self.context drawImage:_pixellateFilter.outputImage inRect:_targetBounds  fromRect:_inputImage.extent];
[self.glkView.context presentRenderbuffer:GL_RENDERBUFFER];

它的渲染过程大致如下：

contextWithEAGLContext 创建的基于 GPU 的 context 处理流程
iOS8 后增强了 GPU 渲染，在后台也能继续使用 GPU 进行处理。所以，应该尽可能的使用 GPU 去做图像处理。

另外，Apple 对 Core Image 内部进行了优化，如果通过

// 创建基于 GPU 的 CIContext 对象
context = [CIContext contextWithOptions: nil];

创建 context ，那么它内部的渲染器会根据设备最优选择。依次为Metal、OpenGL ES、Core Graphics。

PS：Metal 需要 iOS8 + A7，且模拟器不支持 Metal。OpenGL ES3 需要 iOS7 + A7
测试结果：
iPhone 6s，iOS 10， 模拟器：OpenGL ES3
iPhone 6s，iOS 10，真机：Metal
iPhone 5， iOS 8， 模拟器：OpenGL ES

五、CIFilter 注意点

之前提到过 CIContext 是线程安全的，然而 CIFilter 并不是线程安全的。这意味着一个 CIFilter 对象不能在多个线程间共享。如果你的操作是多线程的，每个线程都必须创建自己的 CIFilter 对象。否则，你的应用将产生不可预期的后果。

六、Core Image 和 GPUImage 的对比

Core Image 与其他图像处理方案的对比，这里比较有争议的就是 OpenGL ES 和 Core Image 了。

在 OpenGL ES 部分，拿主流的 GPUImage 来做对比，分析一下它们各自的优缺点。只有对比了才知道，Core Image 好在哪里，是否值得使用。

PS：以下的优势阐述，撇去了两个框架都具备的，仅保留对比后各自的优势。
另外，GPUImage 我没有深入学习过，对于它的一些优势，主要是总结它的开发者 Brad 描述的，以及简单的 Demo 进行对比。

GPUImage 的优势：

• 最低支持 iOS4.0，iOS5.0 之后就支持自定义滤镜。
• 在低端机型上面，GPUImage 有更好的表现。
• GPUImage 在视频处理上有更好的表现。
• GPUImage 的代码完全公开，实现透明。
• 可以根据自己的业务需求，定制更加复杂的管线操作。可定制程度高。

Core Image 的优势：

• 官方框架，使用放心，维护方便。
• 支持 CPU 渲染，可以在后台继续处理和保存图片。
• 一些滤镜的性能更强劲。例如由 Metal Performance Shaders 支持的模糊滤镜等。
• 支持使用 Metal 渲染图像。而 Metal 在 iOS平台上有更好的表现。
• 与 Metal、SpriteKit、SceneKit，Core Animation 等更完美的配合。
• 支持图像识别功能。包括人脸识别、条形码识别、文本识别等。
• 支持自动增强图像效果，会分析图像的直方图、图像属性、脸部区域，然后通过一组滤镜来改善图像效果。
• 支持对原生 RAW 格式图片的处理。
• 滤镜链的性能比 GPUImage 高。
• 支持对大图进行处理，超过 GPU 纹理限制（4096 * 4096）的时候，会自动拆分成几个小块处理（Automatic tiling）。GPUImage 当处理超过纹理限制的图像时候，会先做判断，压缩成最大纹理限制的图像，导致图像质量损失。

至此，我觉得 Core Image 的优势已经很明显了，尤其是与 Metal 的配合，自动增强图像效果，支持处理大图以及滤镜链的优化。

下面关于这几点优化，做个简单的描述。

1. 滤镜链

if you chain together a sequence of filters, Core Image will automatically concatenate these subroutines into a single program.The idea behind this is to improve performance and quality, by reducing the number of intermediate buffers.

Core Image 对滤镜链的处理

Core Image 会自动把多个滤镜组合成一个新的程序（program），通过减少中间缓存区的数量，来提高性能和质量。

2. 支持大图
   超过 GPU 纹理限制（4096 * 4096）的时候，会自动拆分成几个小块处理（Automatic tiling）。

图片大小：（8374，7780），验证结果：

PS： rois 表示当前处理区域。 extent 表示图像实际大小。
这个输出是 Core Image 在处理过程中打印的。

(1) rois=[0 0 2092 3888] extent=[0 0 8374 7780]  
(2) rois=[2092 0 2092 3888] extent=[0 0 8374 7780]
(3) rois=[0 3888 2092 3892] extent=[0 0 8374 7780]
(4) rois=[2092 3888 2092 3892] extent=[0 0 8374 7780]
(5) rois=[4184 0 2092 3888] extent=[0 0 8374 7780]
(6) rois=[6276 0 2098 3888] extent=[0 0 8374 7780]
(7) rois=[4184 3888 2092 3892] extent=[0 0 8374 7780]
(8) rois=[6276 3888 2098 3892] extent=[0 0 8374 7780]

如果按序讲每个区域进行拼凑，就是原图的实际区域了。

Automatic tiling 原理图

另外，Core Image 对大图和小图的处理上，也有所不同。小图提前解码，大图延迟解码 !

当传入的 image 是小图 (size < inputImageMaximumSize)时，在调用 initWithCGImage 获取输入图像 CIImage 的时候，这个 image 就被完全解码了。这是很有必要的。因为小图可能多次被用到，把编码的工作提前并且只做一次，一定程度上优化性能。

而对于大图来说，它的解码操作是尽可能延后的（being lazy），直到真正需要显示， CIContext 执行 render 相关操作。因为大图的解码代价较大，并且不常用，无脑提前解码，放到内存中是没有必要的。

下面是验证结果，选了两个相差不大的图片，但是 size 介于 4096 左右。
4000 * 4000，小图：

小图内存占用
小图程序处理过程
很明显的，Memory 占有率高，并且调用了 decode 相关操作。

4100 * 4100，大图：

大图内存占用
大图程序处理过程
这里的 Memory 占用较低，并且没有看到 decode 相关操作。

同样的，当通过 CIImage 获取输出 CGImage 的时候，如果输出 CGImage 是小图的话，那么当 [CIContext createCGImage] 调用的时候，image 就被完全渲染了。而对于大图，要等到 CGImage 真正需要渲染显示的时候，这个 image 才会被渲染。

经过这样的优化处理后，对于大图，Session 514 给出了直观的数据对比：

iOS7 与 iOS8 图像处理对比

3. GPU 优化
   另外一个很重要的优化就是：提高了 iOS 上 Core Image 使用 GPU 进行渲染的性能。具体体现在：

   1. 后台操作
   • 短时间内，进入后台后会依旧使用高效的 GPU 进行渲染。
   • 后台操作的 GPU 优先级低，不会对前台的渲染造成性能影响。
   2. 多线程
   • 在 iOS8 之前，如果主线程使用 GPU 进行相关操作，次要线程想要使用 Core Image 的时候，通常要使用安全的 CPU 来实现，避免引起意想不到的问题。
   • 在 iOS8 之后，可以在次要线程设置 Context 的 kCIContextPriorityRequestLow 值为 YES，这样就标记为当前 Context 在 GPU 上渲染的时候优先级低，从而不影响到 GPU 上高优先级的渲染。

CIContext *context = [CIContext contextWithOptions: [NSDictionary dictionaryWithObject:[NSNumber numberWithBool:YES] forKey:kCIContextPriorityRequestLow]];

所以，应该尽可能的使用 GPU 进行渲染，来提高性能。

总结

综上，我认为在某需求 Core Image 能实现的时候，使用 Core Image 应该是 iOS 平台上最好的选择。

参考链接

Core Image 你需要了解的那些事~