我注意到有些人在 CGContext
上重绘图像以防止延迟解压缩,这导致我们的应用出现错误。
错误是图像的大小声称保持不变,但 CGImageDataProvider
数据附加了额外的字节。
比如我们从网上下载了一张797x500的PNG图片,AsyncImageView
重绘并返回重绘后的图片。
代码如下:
UIImage *image = [[UIImage alloc] initWithData:data];
if (image)
{
// Log to compare size and data length...
NSLog(@"BEFORE: %f %f", image.size.width, image.size.height);
NSLog(@"LEN %ld", CFDataGetLength(CGDataProviderCopyData(CGImageGetDataProvider(image.CGImage))));
// Original code from AsyncImageView
//redraw to prevent deferred decompression
UIGraphicsBeginImageContextWithOptions(image.size, NO, image.scale);
[image drawAtPoint:CGPointZero];
image = UIGraphicsGetImageFromCurrentImageContext();
UIGraphicsEndImageContext();
// Log to compare size and data length...
NSLog(@"AFTER: %f %f", image.size.width, image.size.height);
NSLog(@"LEN %ld", CFDataGetLength(CGDataProviderCopyData(CGImageGetDataProvider(image.CGImage))));
// Some other code...
}
日志显示如下:
BEFORE: 797.000000 500.000000
LEN 1594000
AFTER: 797.000000 500.000000
LEN 1600000
我决定将每个字节一个一个地打印出来,果然每行都附加了十二个0
。
基本上,重绘导致图像数据成为 800x500 图像的数据。因此,当我们的应用想要查看第 797 * 行 + 列
th 像素时,它正在查看错误的像素。
我们没有使用任何大图像,因此延迟解压不会造成任何问题,但如果我决定使用这种方法重绘图像,我可能会引入一个微妙的错误。
有没有人可以解决这个问题?还是这是 Apple 引入的 bug,我们真的无能为力?
正如您所发现的,行被填充到方便的大小。这通常是为了使向量算法更有效。如果你打算以这种方式使用 CGImage
,你只需要适应那个布局。您需要调用 CGImageGetBytesPerRow
来找出实际分配的字节数,然后根据该值调整偏移量 (bytesPerRow * row + column
)。
这可能最适合您,但如果您需要摆脱填充,您可以通过创建自己的 CGBitmapContext
并渲染到其中来实现。如果您不熟悉它,那将是 Stack Overflow 的一个被广泛讨论的话题。例如:How to get pixel data from a UIImage (Cocoa Touch) or CGImage (Core Graphics)?
关于iOS重绘图像以防止延迟解压导致图像更大,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/43669682/
欢迎光临 OGeek|极客世界-中国程序员成长平台 (http://ogeek.cn/) | Powered by Discuz! X3.4 |