4

调整 UIImagePickerController 返回的相机 UIImage 的大小，如果您按照本文中的常规方式进行操作，则需要非常长的时间。

[更新：这里最后一次征集创意！我猜我的下一个选择是去问苹果。]

是的，它有很多像素，但是 iPhone 上的图形硬件完全能够在 1/60 秒内将大量 1024x1024 纹理四边形绘制到屏幕上，因此确实应该有一种方法可以将 2048x1536 图像的大小调整为在不到 1.5 秒的时间内完成 640x480。

那么为什么这么慢呢？操作系统从选取器返回的底层图像数据是否还没有准备好被绘制，所以它必须以某种方式被 GPU 无法帮助？

我最好的猜测是它需要从 RGBA 转换为 ABGR 或类似的东西；任何人都可以想出一种方法，可以说服系统快速向我提供数据，即使它的格式错误，我稍后会自己处理？

据我所知，iPhone 没有任何专用的“图形”内存，因此不存在将图像数据从一个地方移动到另一个地方的问题。

所以，问题是：除了使用 CGBitmapContextCreate 和 CGContextDrawImage 之外，还有其他的绘图方法可以更充分地利用 GPU 吗？

需要调查的事情：如果我从不是来自图像选择器的相同大小的 UIImage 开始，它是否同样慢？显然不是...

[info objectForKey:@"UIImagePickerControllerEditedImage"]更新：Matt Long 发现，如果您启用了手动相机控件的裁剪，则只需 30 毫秒即可调整您从选择器中返回的图像的大小。这对于我关心我在哪里takePicture以编程方式拍照的情况没有帮助。我看到编辑后的图像是kCGImageAlphaPremultipliedFirst原始图像kCGImageAlphaNoneSkipFirst。

进一步更新：Jason Crawford 建议CGContextSetInterpolationQuality(context, kCGInterpolationLow)，这确实将时间从大约 1.5 秒缩短到 1.3 秒，但以牺牲图像质量为代价——但这距离 GPU 应该能够达到的速度还很远！

本周结束前的最后一次更新：用户 refulgentis 做了一些分析，这似乎表明 1.5 秒用于将捕获的相机图像以 JPEG 格式写入磁盘，然后将其读回。如果是真的，非常奇怪。

4

5 回答 5

3

似乎您在这里做了几个假设，这些假设可能正确，也可能不正确。我的经历与你不同。这种方法在我的 3G 上似乎只需要 20-30 毫秒，当将从相机拍摄的照片缩放到原始尺寸的 0.31 时，调用：

CGImageRef scaled = CreateScaledCGImageFromCGImage([image CGImage], 0.31);

（顺便说一下，我通过宽度比例 640.0/2048.0 得到 0.31）

我已检查以确保图像与您正在使用的大小相同。这是我的 NSLog 输出：

2009-12-07 16:32:12.941 ImagePickerThing[8709:207] Info: {
    UIImagePickerControllerCropRect = NSRect: {{0, 0}, {2048, 1536}};
    UIImagePickerControllerEditedImage = <UIImage: 0x16c1e0>;
    UIImagePickerControllerMediaType = "public.image";
    UIImagePickerControllerOriginalImage = <UIImage: 0x184ca0>;
}

我不确定为什么会有差异，我无法回答你的问题，因为它与 GPU 有关，但我认为 1.5 秒和 30 毫秒是一个非常显着的差异。也许将该博客文章中的代码与您正在使用的代码进行比较？

最好的祝福。

于 2009-12-07T23:34:51.547 回答
2

我也遇到过同样的问题，并且很长一段时间都在用头撞它。据我所知，第一次访问图像选择器返回的 UIImage 时，它​​很慢。作为一个实验，尝试使用 UIImage 计时任何两个操作 - 例如，您的按比例缩小，然后是 UIImageJPEGRepresentation 或其他东西。然后切换顺序。当我过去这样做时，第一次操作会受到时间惩罚。我最好的假设是内存仍然在 CCD 上，并且将其传输到主内存以对其进行任何处理都很慢。

当您设置allowImageEditing=YES 时，您返回的图像会调整大小并裁剪到大约320x320。这使它更快，但它可能不是你想要的。

我发现的最佳加速是：

CGContextSetInterpolationQuality(context, kCGInterpolationLow)

在执行 CGContextDrawImage 之前，在从 CGBitmapContextCreate 返回的上下文中。

问题是您按比例缩小的图像可能看起来不太好。但是，如果您按一个整数因子按比例缩小（例如，1600x1200 到 800x600），那么它看起来还可以。

于 2009-12-08T21:47:32.123 回答
2

使用 Shark，分析它，弄清楚什么需要这么长时间。

我必须使用 MediaPlayer.framework 进行大量工作，当您在 iPod 上获取歌曲的属性时，与后续请求相比，第一个属性请求非常慢，因为在第一个属性请求中，MobileMediaPlayer 将包含所有属性的字典打包并传递它到我的应用程序。

我敢打赌这里也会发生类似的情况。

编辑：我能够在 Shark 中对 Matt Long 的 UIImagePickerControllerEditedImage 情况和通用 UIImagePickerControllerOriginalImage 情况进行时间分析。

在这两种情况下，大部分时间都被 CGContextDrawImage 占用。在 Matt Long 的案例中，UIImagePickerController 在用户捕获图像和图像进入“编辑”模式之间处理这个问题。

将花费的时间百分比缩放到 CGContextDrawImage = 100%，然后 CGContextDelegateDrawImage 占用 100%，然后 ripc_DrawImage（来自 libRIP.A.dylib）占用 100%，然后 ripc_AcquireImage（它看起来像解压缩 JPEG，并占用了它的大部分_cg_jpeg_idct_islow、vec_ycc_bgrx_convert、decompress_onepass、sep_upsample) 中的时间占 93%。实际上只有 7% 的时间花在了 ripc_RenderImage 上，我认为这是实际的绘图。

于 2009-12-14T02:52:26.857 回答
1

这是我使用过的一个 git 项目，它似乎运行良好。用法也很干净——一行代码。

https://github.com/AliSoftware/UIImage-Resize

于 2011-06-21T05:12:16.367 回答
-1

在这种情况下不要使用 CGBitmapImageContextCreate！我在与您相同的情况下花了将近一周的时间。性能绝对会很糟糕，并且会像疯了一样消耗内存。改用 UIGraphicsBeginImageContext ：

// create a new CGImage of the desired size
UIGraphicsBeginImageContext(desiredImageSize);
CGContextRef c = UIGraphicsGetCurrentContext();

// clear the new image
CGContextClearRect(c, CGRectMake(0,0,desiredImageSize.width, desiredImageSize.height));

// draw in the image
CGContextDrawImage(c, rect, [image CGImage]);

// return the result to our parent controller
UIImage * result = UIGraphicsGetImageFromCurrentImageContext();
UIGraphicsEndImageContext();

在上面的示例中（来自我自己的图像调整大小代码），“rect”明显小于图像。上面的代码运行得非常快，应该完全符合您的需要。

我不完全确定为什么 UIGraphicsBeginImageContext 这么快，但我相信它与内存分配有关。我注意到这种方法需要的内存要少得多，这意味着操作系统已经在某处为图像上下文分配了空间。

于 2009-12-14T03:08:02.847 回答