问题标签 [cgbitmapcontextcreate]

首先，从 SO 的其他地方查看这个非常方便的CALayer扩展。它可以帮助您确定图层内容分配的CGImageRef中的点是否中的某个点是否透明。

注意：不能保证图层contents可以表示或响应，就好像它是CGImageRef 一样。（这可能对更广泛地使用上面提到的扩展产生影响，授予。）但是，在我的情况下，我知道我正在测试的层contents被分配了一个CGImageRef。（希望这不会在我分配后改变！另外我注意到它contents被保留了。）

好的，回到手头的问题。这是我使用扩展的方式。对于初学者，我已将选择器从更改containsPoint:为containsNonTransparentPoint:（我需要保留原始方法。）

现在，我有一个使用七个CALayer对象的UIImageView子类。这些用于基于不透明度的动画（脉冲/发光效果和开/关状态）。这七层中的每一层都有一个已知的CGImageRef，它有效地“覆盖”（空中引号）整个视图的一部分，并带有自己的颜色。其各自图层中的每个图像的其余部分都是透明的。contents

在子类中，我注册了单击手势。当一个到达时，我遍历我的层以查看哪个被有效地点击（也就是说，哪个有一个我点击的不透明点，第一个找到获胜）然后我可以做任何需要做的事情。

这是我处理手势的方式：

好消息？所有这些都可以在 iOS 4.3.2 的 iPhone 模拟器上完美运行。（FWIW，我在 Lion 上运行 Xcode 4.1。）

然而，在我的 iPhone 4（使用 iOS 4.3.3）上，它甚至没有接近！我的水龙头似乎都没有与我期望它们匹配的任何层相匹配。

即使我尝试使用CGContextSetBlendMode的建议在绘制 1x1 像素上下文时

我希望这是飞行员的错误，但我还没有弄清楚差异是什么。水龙头确实有图案，但不是可辨别的。

也许存在数据边界问题。也许除了将 y 坐标翻转到图像的左下角之外，我还需要做一些事情。只是还不确定。

如果有人可以请阐明可能有什么问题，我将不胜感激！

2011 年 9 月 22 日更新：获得第一个啊哈时刻！问题不在于 Simulator-vs-iPhone。这是视网膜与非视网膜！使用 Retina 版本时，模拟器中也会出现相同的症状。也许解决方案以某种方式/形状/形式围绕缩放（CTM？）。Quartz 2D Programming Guide 还建议“iOS 应用程序应该使用UIGraphicsBeginImageContextWithOptions ”。我觉得我非常接近这里的解决方案！

当一个按钮被触摸时，我试图在 dataBuffer 的帮助下在 UIImage 上画一条线，但是 drawRect: .. methode 没有被调用。（所以，我想画的线没有出现）

我真的不知道问题出在哪里，所以我发布了更多代码。对于那个很抱歉。

顺便说一句，我正在开发一个基于视图的应用程序。

这是我的代码：

如何？...我正在尝试使用 CGBitmapContextCreateImage() 获取高质量图像，并尝试使用以下代码来实现。

但是，我无法获得模糊图像，因此渲染图像和原始屏幕图像之间存在一些差异。我不知道原因。请帮我...

我正在使用以下代码（从其他地方收集）标准化图像的方向和最大尺寸：

此代码正确返回一个 UIImage，其旋转转换为 UIImageOrientationUp，如果超过最大图像大小，图像可能会按比例缩小。此代码适用于在 UIView 中显示 UIImage。

但是，如果我采用新的 UIImage 并将其 CGImage 内容提取到位图上下文中，则会在下一步出现我的问题。

然后将其转换回 UIImage 所有颜色都是错误的。我检查了从 inImage 获取的 CGImageGetAlphaInfo 以设置设置为 kCGImageAlphaPremultipliedFirst 的上下文，如果我强制 AlphaInfo 为 kCGImageAlphaPremultipliedLast 我至少可以看到图像，但红色显然显示为蓝色。最后，我发现位图中的 RGBA 数据已转置为 ABGR，通过创建一个循环将字节顺序转回 RGBA，我发现我可以再次使用从 CGImage 创建的上下文重新创建正确的 UIImage。

只有当我通过缩放和旋转方法时，我才会遇到这个 ABGR 问题。我的理解是，我应该能够将 UIImage 转换为 CGbitmapContext 并再次使用它自己的元数据作为上下文参数来接收完全相同的图像。

我的问题是：为什么位图像素字节顺序更改为 ABGR？CGImage 元数据如何变得混乱，以至于我无法直接从其自身创建的 BitmapContext 重新创建 CGImage？

提前致谢！

CGBitmapContextCreate 遇到问题并获得：

错误：不支持的像素描述 - 1 个分量，每分量 8 位，每像素 8 位

使用此代码：

根据：http: //developer.apple.com/library/ios/#documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/dq_context/dq_context.html

它是每个像素 8 位，每个组件 8 位。不知道为什么我会收到错误消息。我在这里看到了一些其他关于如何正确处理的帖子，但大多数都处理编辑图像而不是创建新图像，因此可以从原始图像中获取一些设置。

我迫切需要创建一个没有 alpha 通道的 CGContextRef。不幸的是，对于 Core Graphics，您不能使用 CGBitmapCreateContext 指定 kCGImageAlphaNone。

有人可以发布一个工作示例，说明如何在没有 alpha 通道的情况下创建 CGContextRef 吗？

我需要这个的原因是因为我最终试图调用 CGImageCreateWithMaskingColors，当然，如果提供的 CGImageRef 有一个 alpha 通道，这将不起作用。

请发布一个工作示例。如果你这样做了，你可以享受这样一个事实，即你将处于最前沿，并将成为第一个这样做的人！请发帖！

我写了这段代码：

当我这样做时，CGBitmapContext 是在复制我的 bitmapData，所以在这些行之后我应该写

我正在使用以下功能。每当我调用它时，它都会增加我的内存使用量。我检查了所有泄漏。甚至，我在功能结束时立即释放对象。在这里，我提供我的代码供参考。请提供指导。

//函数开始时的内存 Memory in use (in bytes): 38936576

//函数结束时的内存（池耗尽后）正在使用的内存（以字节为单位）：39272448

//功能

谢谢。

大多数创建位图上下文的代码使用kCGImageAlphaPremultipliedFirst, 来创建 ARGB，而不是kCGImageAlphaPremultipliedLast创建 RGBA。是否有首选 ARGB 的原因？

（用法）：

如果它在 UIKit 中，包括drawRect，是否会自动处理 Retina 显示的高清方面？那么这是否意味着drawRect1024 x 768 视图的当前图形上下文实际上是 2048 x 1536 像素位图上下文？

（更新：如果我使用当前上下文创建图像drawRect并打印其大小：

然后在新 iPad 上，禁用状态栏，打印 2048 和 1536，iPad 2 将显示 1024 和 768）

我们实际上享受自动为我们处理的 1 点 = 4 像素的奢侈。

但是，如果我们使用CGBitmapContextCreate，那么那些真的是像素，而不是点？（至少如果我们为那个位图提供一个数据缓冲区，那么缓冲区的大小（字节数）显然不是为了更高分辨率，而是为了标准分辨率，即使我们NULL作为缓冲区传递，以便CGBitmapContextCreate为我们处理缓冲区，大小可能和我们传入一个数据缓冲区一样，只是标准分辨率，而不是 Retina 的分辨率）。

我们总是可以为 iPad 1 和 iPad 2 以及新 iPad 创建 2048 x 1536，但它会浪费内存、处理器和 GPU 能力，因为只有新 iPad 才需要它。

那么我们是否必须使用 aif () { } else { }来创建这样的位图上下文，我们实际上是如何做到的呢？并且我们所有的代码CGContextMoveToPoint都必须针对 Retina 显示器进行调整以使用x * 2和y * 2与非 Retina 显示器一样使用x, y？这对代码来说可能非常混乱。（或者也许我们可以定义一个局部变量scaleFactor并将其设置[[UIScreen mainScreen] scale]为 1 表示标准分辨率，2 表示视网膜，所以我们的xandy将永远是x * scaleFactor，而y * scaleFactor不是当我们使用 绘制时，等等）xyCGContextMoveToPoint

如果传入 0.0 的比例，似乎UIGraphicsBeginImageContextWithOptions可以自动为 Retina 创建一个，但如果我需要创建上下文并保留它（并使用 ivar 或 UIViewController 的属性来保存它），我认为它不能使用. 如果我不使用 释放它UIGraphicsEndImageContext，那么它会保留在图形上下文堆栈中，所以看来我必须CGBitmapContextCreate改用它。（或者我们只是让它留在堆栈的底部而不担心它？）