如何处理大小为 2-4Mb 的图像(png)
我正在处理大小为 2 到 4MB 的图像。我正在通过执行缩放、平移和旋转操作来处理分辨率为 1200x1600 的图像。我想在上面添加另一张图像并将其保存到相册中。在我成功编辑一张图像并保存到照片后,我的应用程序崩溃了。我认为它的发生是因为图像大小。我想保持图像的 90% 分辨率。
当我收到内存警告时,我会释放一些图像。但它仍然崩溃,因为我正在处理 2 个大小为 3MB 的图像和大小为 1200x1600 的上下文,并同时从上下文中获取图像。
有什么方法可以压缩图像并使用它吗?
I am working with images of size 2 to 4MB. I am working with images of resolution 1200x1600 by performing scaling, translation and rotation operations. I want to add another image on that and save it to photo album. My app is crashing after i successfully edit one image and save to photos. Its happening because of images size i think. I want to maintain the 90% of resolution of the images.
I am releasing some images when i get memory warning. But still it crashes as i am working with 2 images of size 3MB each and context of size 1200x1600 and getting a image from the context at the same time.
Is there any way to compress images and work with it?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我对此表示怀疑。即使压缩和解压缩图像而不对其进行任何操作也会丢失信息。我怀疑任何处理压缩图像的算法都会造成无可救药的损失。
话虽如此,这在技术上可能是可行的。例如,旋转傅里叶变换也会旋转原始图像。但实际的图像压缩通常并不像计算傅立叶变换那么简单。
或者,您可以编写分段算法,将图像分成小块,转换这些块,然后重新组装它们。您还可以通过将相同的变换应用于完整图像的较小版本来提供过程的实时视图。
I doubt it. Even compressing and decompressing an image without doing anything to it loses information. I suspect that any algorithms to manipulate compressed images would be hopelessly lossy.
Having said that, it may be technically possible. For instance, rotating a Fourier transform also rotates the original image. But practical image compression isn't usually as simple as just computing a Fourier transform.
Alternatively, you could write piecemeal algorithms that chop the image up into bite-sized pieces, transform the pieces and reassemble them afterwards. You might also provide a real-time view of the process by applying the same transform to a smaller version of the full image.
关键是永远不要将整个图像以全尺寸完全解码到内存中。
如果您需要显示图像,则没有理由以全尺寸显示图像 - iPhone 上的显示屏太小,无法利用这一点。对于用于显示的图像对象,以缩小的形式解码图像。
为了进行处理,您需要编写适用于像素流而不是内存数组的自定义代码。我不知道这是否已经在 iPhone 上可用,但您可以通过直接写入 libpng 库 API 来自己编写。
例如,您现在的代码可能看起来像这样(伪代码)。
要理解的关键是,在这种情况下,
img
不是 PNG 文件(2MB)中的数据,而是完全未压缩的图像(~6mb)。 RotateImage(或无论它被称为什么)返回另一个大约相同大小的图像。如果你扩大规模,那就更糟了。您想要看起来更像这样的代码(但可能没有任何 API 可供您执行 - 您可能必须自己编写)
在这个算法中,您从来没有一次将整个图像存储在内存中 - 您读取它一块一块地拿出来并保存起来。您可以编写类似的算法来进行缩放和裁剪。
代价是它会比仅仅将其解码到内存中慢——这取决于图像格式和执行 ReadRect() 的代码。不幸的是,PNG 并不是为这种像素访问而设计的。
The key will be never to full decode the entire image into memory at full size.
If you need to display the image, there's no reason to do that at full size -- the display on the iPhone is too small to take advantage of that. For image objects that are for display, decode the image in scaled down form.
For processing, you will need to write custom code that works on a stream of pixels rather than an in-memory array. I don't know if this is available on the iPhone already, but you can write it yourself by writing to the libpng library API directly.
For example, your code right now probably looks something like this (pseudo code)
The key thing to understand, is that in this case,
img
is not the data in the PNG file (2MB), but the fully uncompressed image (~6mb). RotateImage (or whatever it's called) returns another image of about this same size. If you are scaling up, it's even worse.You want code that looks more like this (but there might not be any API's for you to do it -- you might have to write it yourself)
In this algorithm, you never had the entire image in memory at once -- you read it out piece by piece and saved it. You can write similar algorithms for scaling and cropping.
The tradeoff is that it will be slower than just decoding it into memory -- it depends on the image format and the code that's doing the ReadRect(). Unfortunately, PNG is not designed for this kind of access to the pixels.