再给你说个更容易理解的例子

在高清蓝光（ 1920x1080 分辨率）出来之前 日本还只有 320x240 的电视显示的时候

日本 CG 动画和数码化的原稿就是 2048x1536 绘制

这也是为什么后来电视日本很多都蓝光化

难道你觉得当时用 2048x1536 绘制是为了 320x240 的设备么？
当时 sony 对电视台制作人员可都是提供 1600 线的 bvm 监视器

@wushan “这种技术不是为了现在这种高亮度的 HDR 显示而存在的，恰恰是为了 SDR 。”你补充的帖子里说的就是这个错误的

显示的拍摄 存储 生成 显示技术 并不是同步发展的

在第一台彩色电视机器 1954 年生产出来之前 可就有彩色电视节目了
你能说拍摄彩色电视节目是为了黑白电视机么？

HDR 就是 10bit 或者 12bit 的彩色亮度信息

早在 2005 年很多电影电视剧就都采用 10bit 来拍摄了

但是直到 2015 年才有建立在 bt.2020 规格下的 hdr 显示设备

当年大多数设备不能正确显示 10bit 的亮度信息 不代表当年就是为了这些设备拍摄的 10bit 信息

就像彩色电视节目比彩色电视机早十几年一样

@icaolei 你这比喻真赞 太形象了

@wushan hdr 技术没有任何混乱 是你对 hdr 理解就有错误

hdr 就是高动态范围成像

无论是拍摄的技术 显示的技术 电脑 CG 演算的技术

最后得出的都是一回事 也就是亮度由 8 位信息提升到 10 位或者 12 位

这既可以通过提高摄像管的数模转换精度由 1600 万个电子位提高到 10.8 亿电子位达成
也可以让电脑生成 CG 的时候演算 8 倍的光栅达成
也可以让显示器的对比度由 500 提高到 10000 达成
自然也能用拍摄多张不同曝光度的照片累加而达成

只不过这是面向不同的方向 拍摄 存储 生成 显示

@wushan 咋不能 建议你还是稍微了解下 jpeg 的版本和 exif 吧 那些相机厂玩这个的时候 苹果还在一边要倒闭一边做随身听呢

@10RR 一样能 所以这真的没什么可吹的

@movq 他们甚至都不敢给 ipad pro 一个 mac os 系统

基本上什么时候 ipad 有 mac os 了 也就宣告 macbook 死了

@wushan 是你根本就不了解 hdr 这技术从胶片机时代就有 最早能追溯到 1997 年 而民用领域 1999 年的 adobe ps 5.5 就能让你拍摄三张胶片照片的扫描图混合成 hdr 照片 png 和 jpeg2000 还专门支持这个模式
比 iphone4 早得多的 05 年左右的 宾得 k 佳能 s3 尼康 D80 柯尼卡美能达 1000 sony 的 alpha 哪个不能拍摄 hdr 照片？那些相机拍摄的 hdr 照片一眼能通过伽马重映射显示在现在的 hdr10 设备上

这主要是因为 hdr10 的显示设备对过去 hdr 照片的兼容性 哪里是苹果的功劳？

而且 hdr 显示设备也不是现在才有得 2005 年 sony 的 crt 显示器 BVM-D20F 是被认为第一个能显示 hdr 的设备 通过色彩重映射 他能显示 sony 多摄像管机 A200 所拍摄的 高范围图像 并应用在多部早期蓝光电影的拍摄工作上

windows 配合 nvidia 40 系显卡的 RTX HDR 技术 可以把 136 年前第一部电影变成 hdr 的

所以一个 10 年前拍摄的 hdr 照片 用现在的 hdr 设备能播放出来有啥好稀奇的？

@tagtag
@Building
@dilidilid

苹果新硬件设计师说 要是把 mac mini 做得更小就不像电脑了 这访谈苹果官网就有 去看一眼能死？

乔纳森还在人世的时候（ x ）的访谈说 他们在拿到 slicon 的时候 就觉得可以把 mac mini 做的像机顶盒大小

但是经过了数个月的讨论 库克拒绝了他们这么做（因为制造了太多的 mac mini 的外壳？）

于是得编个理由 之后乔纳森离职了

新的首席设计师 咕噜咕噜咕 pia 恰 就得到了这么一个艰巨的任务

在 mac mini m2 库克仍旧不准修改外观后

咕噜咕噜 pia 恰想到了一个借口

如果 mac mini 做到 apple tv 大小 那在苹果店里展示的时候 客户可能不认为它是一台电脑

所以虽然 mac mini 有 85%的没用的空体积 我们也绝对不会让它变得更小的

苹果的软件生态现在变得特别不友好了

就连正版 adobe 也变得三天两头不能用

公司里除了我还在坚持 mac 其他人都放弃了

@ysc3839 并不是

微软就曾经出面说过 intel 的 atom 和标准 cpu 以及高通 arm 和 amd 的算法都不一样 不能进行横向对比
一个比较明显的例子是 在 windows xp 酷睿和 Phenom 时期 跑 julia 的时候 amd 的 cpu 会显示跑满了 cpu 而 intel 的标压产品就不会显示跑满 atom 则和 amd 的一样会显示跑满

这是因为 intel 和 amd 的设计原理和权重不一样 对纯浮点算法 intel 的 cpu 可以再跑个整数指令 而 amd 的 3d now ！指令集会接管 julia 算法的大多数运算

当然 windows 11 后微软重构了任务管理器的代码 win11 的 cpu 利用率的实现方式似乎和之前有区别了 大多数第三方工具读取利用率的时候都需要调用额外的 api 不过我仍然不认为微软纯使用了占空比

主流系统的 cpu 利用率（ windows mac 安卓 ios linux ）并不完全代表 cpu 的繁忙程度

现代 cpu 十分复杂 每种晶体管都有自己独特的作用

所以硬件调度器会根据预先的判断来给正在进行的工作一个预期

对每个晶体管是否繁忙进行加权 最后生成一个百分比

这个百分比就是 cpu 利用率

所以 cpu 利用率低 也并不代表 cpu 就不繁忙

解压缩就是其中之一

cpu 的内从控制器要进行复杂的从硬盘到内存再到 3 级缓存 2 级缓存的调度工作

而且类似 7z 等压缩算法 是一环套一环的 你必须完成了前面的才能解压缩后面的

这就导致内存控制器和三级缓存很容易跑满

由于 cpu 利用率对内存控制器和三级缓存的加权并不高 所以才会让你觉得 cpu 不忙 但解压缩速度却不能更快

使用更大的三级缓存的 cpu 比如 x3d 系列 或者更高带宽的内存 可以加快解压缩速度