iOS:抗锯齿失败(CALayer 中的 PNG)
我试图在屏幕上绘制此图像:
这是代码:
CALayer* dullLayer = [CALayer layer];
{
dullLayer.frame = CGRectMake(0,0,BUTTON_SIZE,BUTTON_SIZE);
dullLayer.position = CGPointFromPoint2D( btnCenter );
dullLayer.opacity = topQuadrant ? 1.0 : 0.5;
[wheelLayer addSublayer: dullLayer];
}
UIImage* test = [UIImage imageNamed: @"OuterButton_Dull.png"];
dullLayer.contents = (id) [test CGImage];
这就是我得到的:
给出了什么?为什么边缘如此锯齿?将此与以完全相同的方式合成到屏幕上的罗马数字图像进行对比。
我已经尝试过
dullLayer.edgeAntialiasingMask = 0x0f; // binary 1111
但没有成功。
编辑: http://lists.apple.com/archives/可可-dev/2008/Feb/msg02070.html
I'm attempting to draw this image on screen:
This is the code:
CALayer* dullLayer = [CALayer layer];
{
dullLayer.frame = CGRectMake(0,0,BUTTON_SIZE,BUTTON_SIZE);
dullLayer.position = CGPointFromPoint2D( btnCenter );
dullLayer.opacity = topQuadrant ? 1.0 : 0.5;
[wheelLayer addSublayer: dullLayer];
}
UIImage* test = [UIImage imageNamed: @"OuterButton_Dull.png"];
dullLayer.contents = (id) [test CGImage];
This is what I get:
What gives? Why are the edges so jagged? Contrast this with the Roman numeral images that have been composited to screen in exactly the same way.
I have tried
dullLayer.edgeAntialiasingMask = 0x0f; // binary 1111
to no avail.
EDIT: http://lists.apple.com/archives/cocoa-dev/2008/Feb/msg02070.html
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
如果您发布的结果图像与屏幕上显示的大小相同,那么您使用的图像太大了。 PNG 图像不是矢量图像,因此缩小它总会产生一些锯齿;规模越小,情况就越糟糕。在这种情况下,抗锯齿效果有限。
您在数字图像中看不到它的事实部分是因为它不像其他图像那样包含任何精细的高对比度线条,部分原因可能是您使用了较小的图像。
如果您将原始图像作为矢量图像,请尝试将其缩小到正确的尺寸,然后再将其转换为 PNG。如果您的应用程序中的其他地方需要更高分辨率的版本,请考虑创建多个 PNG,每个 PNG 具有不同的分辨率。
如果您没有原始图像作为矢量图像,您应该尝试寻找替代图像。网络上有一些免费剪贴画文件的好来源,例如 http://www.openclipart.org/ 或 http://www.clker.com/。
If the result image that you posted is the same size as it appears on the screen then you are simply using too large an image. A PNG image is not a vector image, so scaling it down will always give some aliasing; the further you scale down the worse it gets. Antialiasing will have limited effect in such cases.
The fact that you don't see it for the numeral images is partly because it doesn't contain any fine, high contrast, lines like the other image does and partly perhaps because you are using smaller images for them.
If you have the original image as a vector image, try scaling that down to the right size before converting it to PNG. If you need a higher resolution version somewhere else in your app, consider creating multiple PNGs, each at different resolutions.
If you don't have the original image as a vector image, you should try finding a replacement. There are a couple of good sources for free clip art files on the web, such as http://www.openclipart.org/ or http://www.clker.com/.
我刚刚就此发表了一篇文章: http://kellenstyler.com/?p=1360
有如果您通过代码添加图像,您可以做一些事情以及一些可以让您清理得更多的技巧。
看看以下代码中的任何内容是否有帮助:
I just did a post on this: http://kellenstyler.com/?p=1360
There are a few things you can do if you add the images via code along with a few tricks that will allow you to clean it up a little more.
See if anything in the following code helps:
戴斯蒙德已经做到了。
Apple 框架中的抗锯齿功能似乎仅适用于相邻像素。因此,如果将图像缩小 4 倍,像素 0,0 将针对像素 2,0 进行平均,即像素 1,0 被完全丢弃。所以如果你有锋利的边缘,这不会破坏它。
解决办法是反复将图像缩小50%,直到<50%。 2 倍所需尺寸。
如果我逐步缩小原始 600 x 600 图像,每次将其减半,并将结果显示到 256 x 256 CALayer 中,则会发生以下情况:
第三张图像实际上已缩小到目标尺寸以下。奇怪的是,进一步缩小(自动放大 75 -> 256 以便显示)实际上看起来最好。
所以实际上在这种情况下,解决方案是缩小它,直到它实际上小于所需的尺寸,然后让苹果的图形框架根据需要扩展它。
Desmond has nailed it.
It seems that anti-aliasing in Apple's frameworks only operates on neighbouring pixels. so if you reduce an image by 4x, pixel 0,0 is going to be averaged against pixel 2,0 ie pixel 1,0 is completely discarded. so if you have sharp edges, this isn't going to hack it.
The solution is to repeatedly reduce the image by 50% until it is < 2x the desired size.
Here is what happens if I progressively reduce the original 600 x 600 image, halving it each time, and displaying the result into a 256 x 256 CALayer:
The third image has actually scaled down to below the target size. Strangely, a further diminution (which automatically gets up-sized 75 -> 256 in order to be displayed) actually looks best of all.
So actually in this case the solution was to reduce it until it is actually smaller than the desired size, and then let Apple's graphical framework expand it as necessary.