一面亲膜上边奶一个膜边_政治热议_iPhone又出bug一面亲膜上边奶一个膜边了，这次是冲着你的相册截图来的。

iPhone又出bug一面亲膜上边奶一个膜边了，这次是冲着你的相册截图来的。_ZAKER新闻

中国是经济全球化和投资便利化的受益者，更是贡献者。上周，世贸组织《投资便利化协定》文本谈判成功结束。这是全球首个多边投资协定，将进一步推动全球投资增长。谈判过程中，中方先后提出15份正式提案，并多次就谈判难点提出务实解决方案，发挥了重要作用。

也许是印度的程序员铁子们知道咱快过年了， " 特意 " 在 iOS 18.2 的系统更新上，新增了一个挺喜庆的 bug。事情是这样的，有些网友的 iPhone 更新到了 iOS 18.2，在相册里查看图片、截图，然后查看截图、再截图，套娃几次，图片颜色就会越来越红。我愿称之为果粉的春节限定。。。调侃归调侃，托尼其实挺好奇这个 bug 到底是因为啥？网上有种说法是这样的， iPhone 在相册里查看图片时，用的是 sRGB 色域，而在系统截图的时候，图片则保存成 P3 色域模式。问题是 P3 的色彩描述范围比 sRGB 大，所以 sRGB 理解的红色跟 P3 理解的红色是不一样的。就比如说， sRGB 色域下的纯红标记为（255 ， 0 ， 0），括号中的（R ， G ， B）值，就是颜色在色彩空间中的位置坐标。如果将它正确映射到到 P3 色域的话，纯红应该被标记为（234 ， 51 ， 35）。目前来看， iPhone 在颜色的映射上不知道出了啥差错，总之就是没对应上。重复截图就相当于在俩不一致的色域范围之间反复横跳，不断叠加这个 bug ，就导致颜色偏差越来越大，照片最后就 " 红温 " 了。。。当然这只是网友的一个说法，不过托尼也简单测试了一下。我先是找到了一张原始色域为 sRGB 的图片，然后发现，假如在全屏显示的状态下截图，就不会变红。但是如果带一点系统 UI （比如状态栏和后台界面啥的），就会截图成 P3 色域，再截图就会越来越红，大概率就是系统界面的 P3 色域映射出了问题。全屏状态下截图，依旧为 sRGB 色域；露出系统 UI 状态下截图，就保存成了 P3 色域以前都没啥问题，现在突然有这个 bug ，很难不让人联想到苹果前一阵儿宣布的系统新功能——是这么回事儿，苹果在 WWDC24 全球开发者大会上，推出了新 HDR 标准—— Adaptive HDR （自适应高动态范围）。这个新标准，不光相册、信息、快速查看和预览支持 HDR ，甚至连截图和录屏的文件也要支持 HDR 的渲染和显示。。。于是苹果的截图就用上了色域更广、色彩更多的 P3 色域，但目前看来代码没调好。按照预想的剧情，苹果本是想秀一把自家高标准的，但是实际情况，却是整出了新 bug。不过，具体原因到底是不是这么一回事，可能还得等苹果官方的结论，不过刷到这次 iOS 18 出 bug 的新闻之后，托尼脑袋里立马就想到了当年安卓的一档子事。稍微上了点岁数的差友们可能还有印象，在那个贴吧、论坛斗图盛行的年代，很多表情包每多保存、上传一次，画面就会变糊一点，到最后，甚至颜色还会诡异地变绿， " 电子包浆 " 就是这么来的。为啥图片会变糊？表面上的原因大家都知道，无非是用户在上传照片时没有选择原图，再加上平台为了节省存储空间和网络带宽，对图片进行了压缩处理。但实际上，即使是压缩，最多也就是清晰度变差，也不应该变绿。所以本质上，还是当年的安卓在进行转换的时候，压缩算法捅出了大篓子。具体来说，大部分显示设备，比如咱手里的手机、显示屏啥的，都是基于 RGB 色彩模式工作的。但在图像和视频存储传输的过程中，有一种更简略的、更省计算量的色彩模式，叫做 YUV。对这部分感兴趣的差友，可以自行搜索一下，托尼这里就不啰嗦了。总之～在正常情况下，由 RGB 转向 YUV 色彩模式的算法已经很成熟了。就算数据转换过程中有点儿画质损失，也不至于出啥幺蛾子。但是安卓这边压缩图片的接口，准确的说是一个叫做 Skia 的图像库，为了优化运行速度，想了个偷懒方案：标准的 JPEG 图像在做色彩空间转换的时候，会用至少 16 比特精度（也就是 2^16 种不同的亮度或色度级别），但 Skia 降低到了 8 比特。仅展示位深的对比效果是的，就是直接降低运算精度，纯偷懒。。。这就导致颜色偏差会越来越大。再加上安卓为了加快运算过程，在算法方面也出了一些问题。一般来说，绝大多数的 RGB 值经过复杂的公式，转换到 YUV 值时，都会出现小数，但是安卓选择了直接舍弃小数点后面的部分取整。。。注意是直接舍弃，这个操作直接让用惯了 " 四舍五入 " 的托尼喷出一口老血。于是最后造成的结果就是：亮度值 Y 不断变小，图片不断变暗，色度值 UV 也变小了，颜色就不断向绿色偏移。再经过斗图传播时图片的不断保存、上传，色彩空间变换算法反复压缩，图片就越来越绿。这个 bug 直到 2016 年 4 月中旬（ Android 7 ）才被修复，留下的梗也流传至今。相信通过安卓这个编码错误转换的例子，大家已经看出来了，计算机上的色彩显示是一个非常复杂的过程，尤其是现在还有好多种常用的不同色域。比如标准的 sRGB ，还有厂商们推崇的色域更广的 P3，或者当你看 HDR 视频的时候，要切换的 BT2020 色域等等。。。显示这门功课变得越来越复杂，不光苹果和安卓在色彩空间这件事上翻过车，实际上，微软到现在也还有问题呢。。。比如我们每天都在用的 Windows 电脑和 Chrome 浏览器，就有一个已经持续存在了两年，都没有得到修复的 bug：在使用 HDR 显示器的时候，画面经常会映射出一种 " 惨白 " 的错误显示效果（图左），就导致托尼虽然买了支持 HDR 的显示器，但日常使用还是要关闭 HDR 选项。。。已经熟练掌握通过截屏的方式稳定复现该 bug讲到这里，可能有一部分小伙伴会有疑问，不是一直都夸苹果的色彩管理方案做得好？那这些问题苹果也有么？其实可以在屏幕显示性能的测试网站 wide-gamut 上，通过经典的广色域测试页面验证一下（网站链接塞在阅读原文里了，可一键直达）。如果用的是安卓手机或者其他设备，可能只有将图片保存到系统相册，才能看见图片中暗色的 "W" ，而在浏览器里是看不到的。。。用 iPhone 就完全没有这个问题。网站里的图片长这个样子，但不是下面这张压缩过的哦虽然安卓手机，或者其他设备做到了广色域显示，但是没完全打通第三方，很多时候就只能尴尬地孤芳自赏，在系统相册里 " 独美 " 。。。但在苹果阵营，就不需要区分设备、界面和 APP ，用户能得到基本一致的显示效果。而且直到今天，绝大多数安卓手机和 Windows 电脑，在查看 sRGB 之外的色彩空间内容时，要么需要研究复杂的配置文件，要么需要安装专业软件。。。可以说基本没啥色彩管理可言。最后回到 iPhone 截图变红的问题，根据目前获取到的信息，托尼基本相信，就是引入截图 HDR 导致的。希望苹果能尽快修复这个 bug，毕竟，苹果已经是所有各家系统里，在色彩管理、 HDR 等等方面走得最远的厂商了。。。