1

我使用 imageWithData 方法创建了一个 UIimage:

- (void)imagePickerController:(UIImagePickerController *)picker didFinishPickingMediaWithInfo:(NSDictionary *)info
{
UIImage *chosenImage = [info objectForKey:@"UIImagePickerControllerOriginalImage"];
NSData *data1 = UIImageJPEGRepresentation(chosenImage, 1);
NSData *data2 = UIImageJPEGRepresentation(chosenImage, 0.5);
NSLog(@"data1 = %lu;;;;;;;data2 = %lu",[data1 length],[data2 length]);

UIImage *nimg = [UIImage imageWithData:data2];
NSData *data30 = UIImageJPEGRepresentation(nimg, 1);
NSData *data31 = UIImageJPEGRepresentation(nimg, 0.8);
NSLog(@"data30 = %lu;;;;;;data31 = %lu;;;;;;",[data30 length],[data31 length]);
}

我得到这个输出:

data1 = 1751828;;;;;;;data2 = 254737

data30 = 1368455;;;;;;data31 = 387174;;;;;;

为什么data30比data2大这么多?

4

1 回答 1

5

因为它仍然代表以 JPEG 允许的最少数据丢失量存储的该分辨率的图像。

这是一个(不完美的)类比。想象一下,拿一张 CD(全质量音频)并将其翻录成质量非常低的 MP3 文件。该文件将非常小,听起来很糟糕。现在使用 iTunes 将该 MP3 文件刻录到 CD-R 上。如果你播放那张 CD,它听起来仍然很糟糕,但那是可怕的声音数据的全尺寸存储。现在CD-R 翻录成最高质量的 MP3。您是否希望它产生与用于刻录 CD 的低质量 MP3 相同的大小?不,因为您要求 iTunes 以非常高的质量对全尺寸声音信号进行编码。您正在做大量工作以高质量地“保存”碰巧是糟糕的声音数据流。

与您的图像相同。您正在以某个分辨率 X*Y 拍摄原始位图。您正在对它进行非常有损的编码,其设计目的是通过丢弃大量信息来占用少量磁盘空间。然后你将它解码,回到一个完整的 X*Y 大小的位图,它现在有自己的一组(不同的)复杂性,这些复杂性源于它碰巧被压缩的方式。然后,您正在以非常高的质量对该位图进行编码。这将保留几乎所有可见的复杂性,但仍然很难看。

data1(您确实看到了和之间的实质性差异data30,这是这里最接近的苹果对苹果的比较。data1当您保留 JPEG 允许的尽可能多的信息时会发生什么。大小的下降data30表明您在经历时丢失了什么首先将其编码的步骤data2。)

于 2015-03-04T03:34:44.467 回答