Huahua’s Tech Road

Apple ProRes 实战分析 | 码率 | 压缩比 | 信噪比

By zxi on May 11, 2025

ProRes是苹果推出的一组有损视频编码格式，经常用作视频剪辑时候的中间编码。现在也有不少相机提供机内录制ProRes的选项。

ProRes优点有

All-Intra/帧内编码（每一帧都是独立压缩）
编解码效率高（使用硬件加速的情况下）
全线支持10bit 422（也有444和4444的选项）
可变码率（”简单”的画面压缩比高）

当然一切都是有代价的，All-Intra就意味着在相同画质的情况下，码率会比LongGOP帧间编码（H.265 / HEVC)高不少。好在ProRes提供了一些预设来满足不同的画质/码率需求，码率从高到低分别是：

HQ (High Qaulity) 高画质
ST (Standard) 标准
LT (Light) 轻量级
Proxy 代理

接下来我们就来一起看下不同预设在不同场景下的表现。

测试环境和方法：由于ProRes是All-Intra的，所以拿照片和视频得到的结论是一样的，为了方便起见我就都用单张照片来进行测试。

照片是RAW转16bit TIFF，3840×2160，再用ffmpeg压缩成ProRes 30fps，编码器使用的是Mac上的硬件编码器prores_videotoolbox，默认参数。硬件编码器的画质肯定不如CPU编码，但速度要快上好几个数量级。

首先出场的是最难压缩的东西：噪声，来测试一下ProRes码率的上限和画质的下限。

Profile	Bitrate (Mbps)	Compression Ratio	PSNR
HQ	941.82	5.04	13.86
ST	647.12	7.33	13.07
LT	373.77	12.70	12.71
PROXY	143.35	33.11	12.69

首先我们看到的是PSNR惨不忍睹，就算HQ的码率高达942Mbps，信噪比也不到14，信噪比随着码率下降而下降，不过不到1dB。

接下来看一下风光照，一般光圈比较小，场景中有大量的纹理细节。

Profile	Bitrate (Mbps)	Compression Ratio	PSNR
HQ	872.01	5.44	41.67
ST	570.42	8.32	38.96
LT	394.29	12.04	36.36
PROXY	175.28	27.08	31.72

这个时候就很明显的看到各档拉出了明显的差距，信噪比从最高的HQ的近42dB，慢慢降低到Proxy的32dB。但就算全屏观看（不放大），Proxy的画质也相当能打了。30dB是”高画质”底线。

再看另一张，无论是码率还是信噪比都惊人的接近。

Profile	Bitrate (Mbps)	Compression Ratio	PSNR
HQ	882.20	5.38	41.47
ST	568.93	8.34	39.06
LT	398.37	11.91	36.25
PROXY	178.90	26.53	30.82

之前的强度太强了，我们来一个easy case。有大量平滑色块和很强的背景虚化的照片，这种就属于比较容易压缩的。

Profile	Bitrate (Mbps)	Compression Ratio	PSNR
HQ	749.11	6.34	48.48
ST	555.70	8.54	47.95
LT	386.50	12.28	47.27
PROXY	93.45	50.79	45.73

对于简单场景，连Proxy都拿到了近46dB的PSNR，拉不开差距，而且各档码率都下降了不少。

人像

接着我们来看几张人像，结果介于风光和简单场景之间。

Profile	Bitrate (Mbps)	Compression Ratio	PSNR
HQ	852.40	5.57	43.33
ST	568.61	8.35	42.58
LT	372.84	12.73	41.47
PROXY	157.54	30.13	39.78

Profile	Bitrate (Mbps)	Compression Ratio	PSNR
HQ	886.42	5.35	39.72
ST	553.79	8.57	39.55
LT	350.24	13.55	39.24
PROXY	188.87	25.13	38.58

Profile	Bitrate (Mbps)	Compression Ratio	PSNR
HQ	850.07	5.58	34.12
ST	537.04	8.84	34.06
LT	392.76	12.08	34.00
PROXY	160.87	29.50	33.77

不知道为什么对于一些人像照片来说，各个档位拉不开差距。还用什么HQ，直接Proxy得了。

总结

Profile	4K 30fps Bitrate (Mbps)	4K 60fps Bitrate (Mbps)	Compression Ratio	Avg PSNR
HQ	880.00	1760.00	5.39	40.06
ST	570.00	1140.00	8.33	38.84
LT	400.00	800.00	11.87	37.46
PROXY	180.00	360.00	26.37	34.94

ProRes HQ/ST虽然画质不错，但仅有5-8的压缩比做为录制编码来说码率太高了，不太实用，要知道NRAW压缩比也在5左右。ProRes LT压缩比为12:1左右，4K30 “仅需” 400Mbps，在码率和画质上取得一个不错的平衡点。但4K 60码率就翻倍了达到800Mbps。这也算是All-intra的一个弊端了，码率和帧率成正比, 即便是ProRes LT 4K 120fps也要1600Mbps。Proxy可以提供30:1的压缩比，4K 60也就360Mbps，都和H.265差不多了，平均35的PSNR估计是要比H.265低一些，不过对于一般的情况来说也够用了。希望相机厂商能提供更多的ProRes编码选项，其实也就是几组参数的事情。个人希望加一个Proxy的高码率版，压缩比20:1左右，4K 60 475Mbps左右，V60的SD就行了，那就非常Nice了。

想当年，JPEG以8:1~12:1的压缩比傲视群雄，我的第一台单反D90就能拍摄720p的MJPEG，同样也是All-Intra，720p超过25Mbps的码率（压缩比13.5:1) 在当时来说高的吓人。但仅从画质上来讲，ProRes系列并没有比（目前最好的）MJPEG好多少。毕竟帧内压缩是有极限的，个人感觉40:1 – 50:1估计到头了。AI超分+帧生成或许是以后的发展方向，码率降到1/16不是梦。

Nikon Z8/Z9 HLG Deepdive | HLG 详解 VS N-LOG

By zxi on May 3, 2025

网上关于HLG的资料相对来说还是比较匮乏的，更别说是针对Nikon Z系列了。之前做过一期简单的HLG直出视频，但是没人感兴趣…

首先HLG是一条用于交付的Gamma曲线，向下兼容SDR内容，这也就注定了它的上限比较低，这也是为什么大部分人对它不感兴趣的原因(另一个原因是它是HDR）。HLG的动态范围(尤其高光)比不过N-LOG，更别说Slog3了。暗部表现则比其他LOG曲线要好一些。它最大的优点就是所见即所得，不需要LUT还原，也(基本)不需要向右曝光，特别适合HDR直出。不过如果你只做SDR的话，还是选N-LOG吧。只是2025年了，拍N-LOG/NRAW获得12+档动态范围，然后再压缩到8档，我只能说历史的包袱太沉重了。可以参见：再谈苹果XDR显示器与HDR之殇

响应曲线

我在Z8上实测响应曲线，测试方法：调整曝光，记录不同曝光值下中灰的IRE，并和理论值做对比。为了统一起见，我将中灰(Stop 0)都曝光到36%。Note: HLG中灰的理论值应该是38%，不过差别不大，大概0.2档左右。结果实测N-LOG的时候，同样用了95 (37.2%)的斑马线，最后得到的曝光是38%，不管了，差不多就行了。

Z8 HLG实测曲线和理论曲线在[-7, +3]的范围内贴合的非常不错。实测的HLG底噪大约是3%,。两者在高光部分差别比较大，HLG中灰以上一档就开始变成对数曲线，和Stops应该是线性关系，但实测下来，Nikon对+3档以上的高光做了一些保护，曲线非常平滑，因此也比理论多了1档的高光，中灰以上5.3档才会完全过曝。但比起N-LOG还是差了一档多。另外HLG模式下，IRE最大值不是100，而是97左右，斑马线需要设置在245才会有效果。

N-LOG的曲线大致上贴合的还是不错的。noise floor，13%左右。-7档开始就贴着了。只有在+1档到+2档的附近有点波动。高光部分的斜率还是太大了，竟然比理论值还大一些。中灰以上6档就过曝了。只比HLG好了不到1档。

名义ISO

众所周知，N-LOG的基础ISO是800，第二档则是ISO 4000。HLG的基础ISO是400，第二档是ISO 2000。无论是N-LOG还是HLG，它们的ISO都是名义ISO，或者说等效ISO。在相同照度下，我使用相同的参数(1/400s F/4 ISO800)拍摄灰卡，N-LOG和HLG的IRE是36%左右，SDR则为52%。三者还原之后中灰的亮度大体上相同（SDR稍微亮了一点），证实了”名义”ISO。但实际上传感器使用的ISO是多少呢？其实都是ISO 100左右，如何证明呢？拍摄同样的白卡，记录刚刚过曝时的曝光参数。
N-LOG: 1/30s F/4 ISO 800
HLG: 1/30s F/4 ISO 400
SDR: 1/30s F/4 ISO 80 (NL profile, Active D-lighting off)
进光量相同，传感器同时过曝了，表明实际ISO是相同的。
等效ISO也可以这么理解：
N-LOG拍摄时欠曝3档，后期还原时把中灰提亮3档，以起到保护高光的目的。
HLG拍摄时欠曝2档，后期还原时把中灰提亮2档，以起到保护高光的目的。
这也就是为什么按照标准曝光（将中灰曝到36% IRE)，N-LOG暗部噪点爆炸，需要使用向右曝光的原因之一。
HLG则相当于找了一个平衡点，欠曝2档，等效于使用ISO 400拍视频，对于全画幅来说勉强可以接受吧。

HLG quality 设置

由于是面向直出的交付曲线，只有H.265编码支持HLG。虽然Nikon贴心的提供了HLG质量选项，但这里有个坑，在默认的设置下，相机是会对HLG的画面进行锐化的，导致使用超级锐的Z卡扣镜头时会产生过度锐化的情况。需要将Quick Sharp设置成-1才能获得未锐化的画面。有需要的话，也可以将对比度和饱和度也降低一些，推荐-1。

不同Quick Sharp模式下的波形图

调整对比度

调整饱和度

再谈苹果XDR显示器与HDR之殇

By zxi on April 26, 2025

我之前有一篇文章聊过苹果的MBP的XDR显示器，以及为什么“正确”调色过的SDR在它上面效果如此之好，以至于连HDR都黯然失色。Why SDR looks so good on Apple’s XDR display that even shadows HDR?

其实很简单：苹果的XDR显示器把普通的SDR内容HDR化了，高光部分没动，只是把暗部压暗了很多，接近5档！

一谈HDR，很多人上来就吹什么动态元数据什么的。抛开色彩不谈，HDR的字面意思就是高动态范围，就是指内容最终在显示设备上呈现时最亮的地方和最暗的地方的比值，能超过一个数值（比如10档/1024）就可以称为HDR了，物理学就是这么简单。

XDR显示器在呈现Rec. 709 (Gamma 2.22)的内容时，IRE 50%～100%时和标准曲线基本吻合。但在50%以下的部分，对比度会慢慢增加，低于10%之后，黑化愈发明显。播放有损压缩视频时，暗部色块和断层基本不可见，显示效果大幅提升，正所谓一黑遮百丑。谁叫人家能黑的下去呢！标准的Rec. 709曲线在最大亮度500nit时，1% IRE的亮度为1.11nit，动态范围8.8档。但在XDR显示器上，实测100% IRE 450nit, 1% IRE 0.04 nit，动态范围13.5档，这还不算HDR吗？

Rec. 709在普通LCD显示器和XDR显示器上的暗部区别巨大（相机直拍）

后记

XDR的MBP发布已经近4年了，现在最新的iPhone/iPad以及安卓阵营在SDR最大亮度上早已超过了它，达到1000nit或以上，至少14档的显示动态范围使得SDR被HDR化有过之无不及。最高2000nit的激发亮度使得HDR的高光也就比SDR多1档，食之无味弃之可惜，普及遥遥无期～此时JPEG说我真的还能再活500年！

中年大叔的赛博保温杯：开源掌机的尴尬与自洽

By zxi on April 19, 2025

地铁玻璃倒映着我和身旁穿JK制服的姑娘，她耳机里流淌着抖音神曲，我膝盖上躺着台RG35XXH。当《魂斗罗》的BGM突然炸响时，她瞥见我布满茧子的拇指在AB键上翻飞，像看恐龙般瞪大了美甲精致的眼睛。

三十年前，我在百货大楼隔着玻璃抚摸GameBoy时，绝对想不到四十岁生日礼物会是台能模拟三万款游戏的开源掌机。中年男人的油腻保温杯里泡枸杞，我的电子保温杯里炖着整个游戏编年史。妻子总说我在客厅搓手柄的样子像返祖，可当马里奥跃过旗杆的瞬间，后颈分明掠过1995年新华书店门口的穿堂风。

开源掌机像台时光切片机，把FC红白卡带的塑料味、PS1光驱的嗡鸣、GBA像素的颗粒感，统统封印在系统的玻璃棺材里。社区论坛里，年轻极客们讨论超频和魔改系统，而我沉迷给《塞尔达传说：缩小帽》打金手指——就像给褪色的青春描眉画眼。

深夜加班后，我蹲在车库给开源掌机刷Linux固件。楼上的钢琴声与焊接声此起彼伏，邻居孩子练习车尔尼599，我试图复活二十年前的电子宠物。当拓麻歌子像素蛋在开源系统里破壳时，忽然觉得我们这代人就像游戏ROM，被时代反复转码却始终保留着某种顽固的比特基因。

如今Switch在年轻人手里漂移，手游在打工人屏幕上996，我的开源掌机永远停在标题画面。那些通关存档不再重要，重要的是每次按下电源键时，总能在3.5英寸的微光里打捞出那个攥着五毛钱硬币，在游戏厅门口徘徊的瘦小男孩。

全文由 DeepSeek R1生成，花花稍作修改并配图。

花花酱 LeetCode 3517. Smallest Palindromic Rearrangement I

By zxi on April 16, 2025

这题考查的是排序吧… 还有rbegin的使用。

普通排序：时间 O(nlogn) / 空间 O(1)

前半部分顺序排序，后半部分逆序排序。

class Solution {

public:

string smallestPalindrome(string s) {

const int n = s.length();

sort(begin(s), begin(s) + n / 2);

sort(rbegin(s), rbegin(s) + n / 2);

return s;

}

};

计数排序：时间：O(n)，空间：O(n) -> O(1)

首尾一起写

// 7 ms, 54.65MB

class Solution {

public:

string smallestPalindrome(string s) {

vector<int> f(128);

for (size_t i = 0; i < s.size() / 2; ++i)

++f[s[i]];

auto h=begin(s);

auto t=rbegin(s);

for (char c = 'a'; c <= 'z'; ++c)

while (f[c]--)

*h++ = *t++ = c;