2026年10月28日 星期三

黃山江南遊—黃山八天旅遊團

 這是一份已為您整理好的 HTML/Markdown 格式旅遊資訊網頁內容,方便您直接複製並貼上至 vincentcheng.blogspot.com 部落格文章中:

115年10月30日~11月06日「黃山江南遊—黃山八天旅遊團」行前通知

行程特色: 黃山、醉美千島湖、浪漫烏鎮西柵、水墨村落宏村、徽州古城、魔都上海 8日

✈️ 集合與航班資訊

  • 集合時間: 2026年10月30日(星期五)下午 15:30
  • 集合地點: 桃園機場第二航廈出境大廳,中華團體櫃台(7號後方)
  • 現場陪同人員: 梁榮元 先生(手機:0936-140-338)
日期行程航空公司/航班起降時間
去程 10月30日(五)桃園機場 ✈ 上海浦東中國東方航空 MU500618:40 / 20:40
回程 11月06日(五)上海浦東 ✈ 桃園機場中國東方航空 MU500515:50 / 17:40

🚌 機場接送專車資訊(10月30日 去程接送)

【A 車】車號:RFR-3613 | 司機:林先生(0938-110189)| 共 5 人
  • 14:10|鄭劍萍(新州市中山路640巷528弄5號|0916-124-622)
  • 14:20|鄭曉陽、張啓文(新州市中華路二段89號|0976-217-180)
  • 14:25|吳慈鋆(新州市民權路24巷1-1號6樓|0932-716-865)
  • 14:30|吳芳玲(新州市南大路81號4樓之2|0928-068-706)
【B 車】車號:RBF-9380 | 司機:謝先生(0932-291237)| 共 6 人
  • 14:05|蔡堅鑫、陳秀英(新州市東區中央路127號|0937-152-482 / 0932-290-218)
  • 14:15|張晉銘(新州市經國路一段684號|0910-269-257)
  • 14:25|郭彥彬(新州市湳雅街161號|0939-310-269)
  • 14:30|陳名輪、藍宗慧(新州市北區鐵道路2段286巷12號|0933-973-389 / 0921-141-359)
【C 車】車號:RBU-8712 | 司機:周先生(0927-290895)| 共 5 人
  • 14:20|連思義、孫月琴(新州市北區境福街50號|0932-930-304 / 0916-264-729)
  • 14:25|卓銀學、陳素貞(新州市北區吉羊路85巷3號|0933-980-767)
  • 14:40|張福新(新竹縣竹北市尚義街65巷126號|0972-089-889)

👥 旅遊分組名單

註:各組 1 號為組長,集合時請組長協助確認組員是否到齊。

  • A 組: 01. 張晉銘 (組長)|02. 吳芳玲|03. 吳慈鋆|04. 陳名輪|05. 藍宗慧
  • B 組: 01. 王先庚 (組長)|02. 程嘉寧|03. 程慧君|04. 鄭劍萍|05. 林毓玲
  • C 組: 01. 蔡堅鑫 (組長)|02. 陳秀英|03. 卓銀學|04. 陳素貞|05. 鄭曉陽|06. 張啓文
  • D 組: 01. 張福新 (組長)|02. 郭彥彬|03. 連思義|04. 孫月琴|05. 林春秋|06. 黃智輝

🍽️ 用餐桌次表

  • A 卓(11人):
    1. 蔡堅鑫|2. 陳秀英|3. 吳芳玲|4. 吳慈鋆|5. 陳名輪|6. 藍宗慧|7. 王先庚|8. 程嘉寧|9. 程慧君|10. 鄭劍萍|11. 林毓玲
  • B 卓(11人):
    1. 張晉銘|2. 卓銀學|3. 陳素貞 <span style="color:red;">(蛋奶素)</span>|4. 鄭曉陽|5. 張啓文|6. 張福新|7. 郭彥彬|8. 連思義|9. 孫月琴|10. 林春秋|11. 黃智輝

2026年10月22日 星期四

亮點與暗點的偵測

在灰階形態學(Grayscale Morphology)中,如果你的結構元素(Kernel)大小是 $3 \times 3$(總共 9 個點):

  • 膨脹(Dilation):就是看這 9 個點之中,誰的像素值最高(最亮),就把中心點替換成那個最亮的值。

  • 腐蝕(Erosion):則是看這 9 個點之中,誰的像素值最低(最暗),就把中心點替換成那個最暗的值。

為什麼膨脹要取「最亮」?

回到剛才談的「閉運算(先膨脹後腐蝕)」:

  1. 膨脹(取 9 點最大值/最亮值):當 Kernel 在畫面上移動時,它會強迫中心點變成周圍 9 個點裡最亮的那一個。因此,當它掃到那個較暗的 LCD 壞點(小黑孔)時,周圍較亮的背景像素就會直接「入侵」並覆蓋這個黑點,把黑點的亮度給填平。

  2. 腐蝕(取 9 點最小值/最暗值):接著做腐蝕時,是將整體畫面稍微收縮,讓因為膨脹而擴大過頭的亮區回到原本的幾何尺寸。但此時,原本凹陷的黑點已經在第一步被「補土」填滿了。

所以,用 $3 \times 3$ 或更大(例如 $9 \times 9$)的 Kernel 做膨脹時,本質上就是一種「局部最大值濾波(Maximum Filter)」。這就是為什麼它能像拿刮刀和補土一樣,把畫面上的微小暗斑完美「吃掉」的核心原理!

2026年10月12日 星期一

NV12 vs YUV vs NV21

 NV12 是 YUV 格式的一種特定記憶體排列變體。

簡單來說,「YUV」是一個大分類(泛指所有將亮度與色度分開的色彩空間),而「NV12」則是這個大分類下,屬於 YUV 4:2:0 取樣、且採用半平面(Semi-Planar)記憶體排列的一種具體標準。
它們的關係可以透過以下三個核心維度來理解:

1. 隸屬與取樣關係 (Subsampling)

  • YUV:包含 4:4:4、4:2:2、4:2:0 等多種色度抽樣比例。
  • NV12:固定屬於 YUV 4:2:0。這代表水準與垂直方向都每 2×2(共 4 個)像素的 Y(亮度),共用一組 U 和 V(色度)。每像素平均只佔用 1.5 位元組 (12 bits)。

2. 記憶體排列方式 (Layout)

這是 NV12 與其他 YUV420 格式(如 I420)最大的差別。NV12 採用半平面(Semi-Planar)架構,在記憶體中分為兩個平面(Plane):
  • Plane 1 (Y 平面):連續存放所有像素的 Y(亮度)資料。
  • Plane 2 (UV 平面):將 U 和 V 資料交錯(Interleaved)存放在一起,順序為 U, V, U, V...。

記憶體排列表現樣張(以 4×2 像素為例):

[Y0][Y1][Y2][Y3][Y4][Y5][Y6][Y7]  <- 第一平面:全部都是 Y
[U0][V0][U1][V1]                  <- 第二平面:UV 交錯排列

3. 直觀對比:NV12 與其他常見 YUV 格式

為了讓你更清楚 NV12 在 YUV 大家族中的位置,以下直接與其他常見格式進行對比:
格式名稱YUV 取樣比例記憶體架構分類記憶體實際排列順序常用場景
NV124:2:0Semi-Planar (半平面)YYYYYYYY 接著 UVUVDirect3D、Android、硬體解碼 (GPU)
NV214:2:0Semi-Planar (半平面)YYYYYYYY 接著 VUVUAndroid 相機預設 (Camera1 API)
I420 (YU12)4:2:0Planar (全平面)YYYYYYYY 接著 UU 接著 VV軟體視訊通訊 (WebRTC, FFmpeg)
YUY2 (YUYV)4:2:2Packed (打包交錯)Y0 U0 Y1 V0 Y2 U2 Y3 V2USB 視訊鏡頭、早期影音擷取卡

為什麼 NV12 這麼受歡迎?

在現代作業系統與顯示卡(如 Intel、NVIDIA、AMD 的硬體加速解碼)中,NV12 是最被廣泛支援的內部格式。
因為它的 Y 平面與 UV 平面是分開的,顯示卡在渲染時可以直接把 Y 平面當成一張灰階紋理(Texture),UV 平面當成另一張色彩紋理,在晶片內部直接進行硬體級的色彩轉換(轉成 RGB 顯示),處理效率極高。
如果你正在編寫程式,需要知道如何將 RGB 矩陣打包成 NV12 的雙平面記憶體結構,或是需要 NV12 轉 RGB 的轉換公式,我們可以進一步討論!

NV21 是另一種極為常見的數位視訊編碼格式,屬於 YUV 4:2:0 採樣的 Semi-Planar(半平面) 結構。它最著名的身分是 Android 系統相機(Camera API)預設的預覽畫面格式。 [1, 2, 3]

基本特性

  • 採樣格式:YUV 4:2:0。意味著橫向與縱向的色度(UV)都經過減半抽樣,每 4 個 Y(2x2 的像素區塊)共同分享一組 UU 和 VV。 [4, 5]
  • 儲存平面(Two-Plane):
    1. 第一個平面(Plane 1):連續存放整張圖像所有的 Y(亮度) 資料。
    2. 第二個平面(Plane 2):將 V(Cr)和 U(Cb) 進行交錯(Interleaved)存放。 [6, 7, 8]
  • 位元組順序(Byte Order):在 UV 平面中,它是以 V, U, V, U 的順序排列(這也是它被稱為 NV21 的原因,V 在 U 前面)。 [1, 9]
  • 資料大小:平均每個像素僅佔 12 bits(1.5 個位元組),檔案體積比 YUY2(16 bits)小了 25%,非常利於網路傳輸與硬體解碼。 [4, 10]

NV21 與 NV12 的直接對比

這兩者經常被放在一起討論,因為它們的結構高達 99% 相同,唯一的差別在於 UV 平面的排列順序相反: [6, 11]
特性NV21NV12
YUV 採樣YUV 4:2:0 Semi-PlanarYUV 4:2:0 Semi-Planar
Y 平面先存放所有 Y先存放所有 Y
UV 平面順序V, U, V, U, V, U...(VU 交錯)U, V, U, V, U, V...(UV 交錯)
主要陣營Android 生態系相機預設格式iOS (Apple)、Windows (DirectX) 慣用格式

記憶體排列範例(以 4×2 像素的影像為例)

當影像讀入記憶體時,連續的位元組(Byte)呈現方式如下:
  • NV21:[Y1, Y2, Y3, Y4, Y5, Y6, Y7, Y8] + [V1, U1, V2, U2]
  • NV12:[Y1, Y2, Y3, Y4, Y5, Y6, Y7, Y8] + [U1, V1, U2, V2] [1, 4, 10]

應用與常見痛點

由於 NV21 是 Android 底层硬體直接吐出來的資料,許多行動端的影像演算法(如 OpenCV 影像處理、人臉辨識、AI 濾鏡模型)都會直接指定 NV21 作為輸入格式。 [5]
不過,如果你要把 Android 採集到的 NV21 影片流直接丟給跨平台播放器(如 Windows、iOS),或丟進視訊編碼器(如 H.264 標準通常偏好 I420/YU12 或 NV12),就必須在軟體層做一次 VU 順序對調(將 NV21 轉為 NV12),否則畫面中的人會集體「面色鐵青」,紅藍色調完全相反。 [1, 5]

2026年10月3日 星期六

季節與太陽夾角問題

 新竹(緯度約 24.81°N)一整年太陽正午仰角(Elevation Angle)與天頂角(Zenith Angle,即與正頭頂的夾角)的變化範圍與計算如下:

1. 正午太陽夾角範圍(公制角度)

  • 夏至(約 6 月 21 日):太陽直射北回歸線(23.5°N)
    • 仰角:90^\circ - \vert{}24.81^\circ - 23.5^\circ\vert{} = \mathbf{88.69^\circ}(太陽幾乎直射頭頂,稍微偏南)
    • 天頂角(與正頭頂夾角):\mathbf{1.31^\circ}
  • 冬至(約 12 月 21 日):太陽直射南回歸線(-23.5°S)
    • 仰角:90^\circ - \vert{}24.81^\circ - (-23.5^\circ)\vert{} = \mathbf{41.69^\circ}(太陽偏南,高度最低)
    • 天頂角(與正頭頂夾角):\mathbf{48.31^\circ}
  • 春分 / 秋分(約 3 月 21 日 / 9 月 23 日):太陽直射赤道(0°)
    • 仰角:90^\circ - 24.81^\circ = \mathbf{65.19^\circ}
    • 天頂角(與正頭頂夾角):\mathbf{24.81^\circ}

2. 正午夾角計算公式

計算正午太陽高度角的標準公式為:

\text{仰角 } (h) = 90^\circ - \vert{}\phi - \delta\vert{}
  • \phi(當地緯度):新竹取 24.81^\circ
  • \delta(太陽赤緯角):隨一年中的日期在 +23.5^\circ 到 -23.5^\circ 之間變動

赤緯角 \delta 的近似估算公式:

\delta \approx 23.45^\circ \times \sin\left(\frac{360^\circ}{365} \times (N + 284)\right)

(其中 N 為該日期為一年中的第幾天,例如 1 月 1 日 N=1)

若要計算與地面法線/天頂的夾角(天頂角 Z),公式為:

Z = 90^\circ - h = \vert{}\phi - \delta\vert{}

中文翻譯 (Traditional Chinese Translation)

新竹(緯度約 24.81°N)一整年太陽正午仰角與天頂角(與正頭頂的夾角)變化如下:

  • 夏至:仰角 88.69°,與正頭頂夾角 1.31°
  • 春分 / 秋分:仰角 65.19°,與正頭頂夾角 24.81°
  • 冬至:仰角 41.69°,與正頭頂夾角 48.31°

2026年9月20日 星期日

X-rite color checker Delta C2000, Delta E2000, 的差別

 在 X-Rite ColorChecker 的影像分析裡,ΔE2000 與 ΔC2000 都是在比較:

相機拍出來的顏色(Measured)與 ColorChecker 標準參考顏色(Reference)到底差多少。

兩者的差別在於:ΔE2000 看「整體色差」;ΔC2000 特別看「彩度(Chroma)差異」。


1. ΔE2000 是什麼?

Delta E 2000(ΔE00) 是目前很常用的人眼感知色差計算方式。

簡單理解:

ColorChecker 標準顏色
        ↓
   Reference Lab
        │
        │ 比較
        ↓
相機拍攝後的顏色
        ↓
   Measured Lab
        │
        ↓
     ΔE2000

例如某一個 ColorChecker patch:

Reference:
L* = 50.0
a* = 20.0
b* = 30.0

Measured:
L* = 51.2
a* = 18.5
b* = 31.8

                ↓
             ΔE2000
                ↓
              2.1

代表相機拍出來的顏色與標準顏色有一定程度的差異。

ΔE2000 越小越好

大致可以這樣理解:

ΔE2000一般意義
0完全相同
< 1非常小,通常不容易察覺
1–2很小
2–3可以開始觀察到差異
3–5明顯色差
>5色差相當明顯
>10顏色明顯錯誤

不過這些不是絕對的「合格標準」,實際判定還要看你的 camera tuning specification。


2. ΔC2000 是什麼?

ΔC2000 的 C = Chroma(彩度)。

也就是它不是主要看「整個顏色偏多少」,而是特別分析:

顏色的鮮豔程度 / 飽和程度偏了多少。

例如:

Reference
   ●
  / 
 /       ← Chroma
O────────────→

在 CIELAB 裡:

C*ab = √(a*² + b*²)

所以:

  • a* / b* 決定色相方向

  • C* 決定離 L* 軸有多遠

  • C* 越大 → 顏色越鮮豔

  • C* 越小 → 顏色越灰、越淡


3. ΔE2000 vs ΔC2000

這是 ColorChecker 分析時非常重要的概念。

假設標準:

Reference
L* = 50
a* = 40
b* = 30

相機:

Measured
L* = 50
a* = 48
b* = 36

可以發生:

ΔE2000 = 5.2
ΔC2000 = +4.8

這時候你就知道:

主要問題可能不是亮度,而是相機把這個顏色做得太鮮豔。

也就是:

Reference
    ●
   /
  /
 ●  ← Measured

Measured 的顏色離中心更遠,因此 Chroma 增加。


4. ΔC2000 的正負號很重要

這點在你做 Camera Color Tuning 時特別有用。

ΔC2000 通常可以理解成:

ΔC2000 > 0
    ↓
Measured Chroma > Reference Chroma
    ↓
顏色偏鮮豔 / saturation too high


ΔC2000 < 0
    ↓
Measured Chroma < Reference Chroma
    ↓
顏色偏灰 / saturation too low

例如:

PatchΔC2000
Skin+2.1
Red+5.8
Green+4.2
Blue-1.2

可以初步判斷:

Red     → 太鮮豔
Green   → 太鮮豔
Blue    → 稍微不夠鮮豔

這對調整 CCM / CSC / saturation 很有幫助。


5. ΔE2000 不只包含 Chroma

可以把 ΔE2000 想成:

                 ΔE2000
                    │
       ┌────────────┼────────────┐
       ↓            ↓            ↓
    ΔL2000       ΔC2000       ΔH2000
   Lightness      Chroma        Hue
     明暗          彩度          色相

也就是:

ΔL2000

看:

明不明 / 暗不暗

ΔC2000

看:

鮮不鮮豔

ΔH2000

看:

顏色方向有沒有偏掉

而:

ΔE2000

則是綜合考慮這些因素後的整體感知色差。


6. 這對 ColorChecker 24 色特別有用

例如你測試 24 個 patch:

PatchΔE2000ΔC2000可能問題
Dark Skin2.1+0.4整體 OK
Light Skin3.8+2.9彩度偏高
Blue Sky2.5-1.8彩度稍低
Foliage5.4+4.7綠色太鮮豔
Blue Flower4.1+0.5可能是 Hue
Bluish Green2.2-0.3OK
Orange6.1+5.2Orange saturation 太高
Red5.8+4.9Red saturation 太高

這時候只看:

ΔE2000

你只能知道:

哪些顏色錯很多。

但是加入:

ΔC2000

就可以進一步知道:

是不是 saturation / chroma 的問題。


7. 對你現在做 Camera Tuning,三個數值最好一起看

我會建議你的 Delphi ColorChecker 分析結果至少輸出:

Patch
Reference L*a*b*
Measured L*a*b*

ΔL2000
ΔC2000
ΔH2000
ΔE2000

例如:

Patch 14 - Red

Reference:
L*  = 43.1
a*  = 53.2
b*  = 32.1

Measured:
L*  = 44.0
a*  = 59.8
b*  = 35.7

ΔL2000 = +0.8
ΔC2000 = +5.1
ΔH2000 = +0.9
ΔE2000 = 5.4

這個結果就非常有意義:

Brightness   OK
      ↓
ΔL = +0.8

Chroma       明顯偏高
      ↓
ΔC = +5.1

Hue          幾乎 OK
      ↓
ΔH = +0.9

Overall      有明顯色差
      ↓
ΔE = 5.4

因此你的 Camera tuning engineer 就可以比較有方向地判斷:

這個 patch 的主要問題是 Chroma,而不是 Exposure 或 Hue。


8. 對 CCM 調整尤其有用

如果你現在是在做:

AWB → CCM → CSC → ColorChecker

可以把它理解成:

RAW
 │
 ▼
AWB
 │
 ▼
CCM
 │
 ▼
CSC / Saturation
 │
 ▼
RGB
 │
 ▼
ColorChecker analysis
 │
 ├── ΔL2000 → Brightness / tone
 │
 ├── ΔC2000 → Saturation / chroma
 │
 ├── ΔH2000 → Hue / CCM
 │
 └── ΔE2000 → Overall color accuracy

所以:

CCM 有問題

通常會看到某些 hue group:

Red / Orange / Yellow
Green
Cyan
Blue
Magenta

出現系統性的 ΔH2000。

CSC / Saturation 有問題

則可能看到:

ΔC2000

大量同方向偏正或偏負。

例如:

Red       +4.8
Orange    +5.2
Yellow    +4.1
Green     +3.9
Blue      +4.3

這種 pattern 就很像整體 saturation 偏高,而不是單一 CCM hue rotation。


最簡單的記法

你可以直接記:

ΔE2000 = 「這個顏色總共錯多少?」

ΔC2000 = 「這個顏色鮮豔程度錯多少?」

ΔH2000 = 「這個顏色的色相方向錯多少?」

ΔL2000 = 「這個顏色的明暗錯多少?」

而對你的 X-Rite ColorChecker + Delphi camera analysis,我會把 ΔE2000 當 Overall KPI,ΔL/ΔC/ΔH2000 當 Debug information。這樣當 ΔE2000 超標時,可以直接追查究竟是 亮度、彩度還是 Hue 出問題。

2026年9月8日 星期二

Delphi String 與 TStringlist 的處理

var
  SL: TStringList;
  S: string;
  I: Integer;
begin

S := '123,32,123,456';

SL.Delimiter := ','; 

SL.StrictDelimiter := True; 

SL.DelimitedText := S;

for I := 0 to SL.Count - 1 do 

     SL[I] := '"' + SL[I] + '"'; 

S := String.Join(',', SL.ToStringArray);


end;

2026年8月26日 星期三

玄戒 O3

先講結論:如果把玄戒 O3 放進目前 2026 旗艦 SoC 比較,O3 的定位非常誇張——它在 CPU 多核與 AnTuTu 總分已經明顯超過 Snapdragon 8 Elite Gen 5、Dimensity 9500 和 A19 Pro;但目前 O3 的數據主要還是小米官方/實驗室成績,實機長時間性能與功耗仍要等量產機測試。 (Notebookcheck)

1. 核心性能對照

項目玄戒 O3Snapdragon 8 Elite Gen 5Dimensity 9500Apple A19 Pro
製程TSMC N3P3nm3nm3nm
CPU 核心10 核8 核8 核6 核
最高頻率4.35 GHz約 4.6 GHz4.21 GHz4.26 GHz
AnTuTu V11🥇 5,228,014≈3,942,923≈3,485,039≈2,568,709
Geekbench 6 SC3,945≈3,640≈3,228🥇≈3,970
Geekbench 6 MC🥇 15,221≈11,033≈9,553≈10,558
3DMark Solar Bay—*12,156🥇13,31910,999
3DMark Steel Nomad Light4,567≈2,737≈3,119—
GPUMali-G2 Ultra NX MC16Adreno 840Mali-G1 Ultra MP12Apple GPU
記憶體LPDDR6LPDDR5XLPDDR5XLPDDR5X
記憶體頻寬113.8 GB/s約 77 GB/s約 96 GB/s—

* O3 目前公布的是 Solar Bay Extreme = 3,628,而其他幾顆常見公開資料多是普通 Solar Bay,因此不直接放在同一欄比較。O3 的 3DMark 數據與 CPU/AnTuTu 數據來自小米公布的測試結果;其他三款則採目前公開實測/彙總數據。(Notebookcheck)

2. AnTuTu V11 差距非常大

以這組數據計算:

  • O3 vs 8 Elite Gen 5:+32.6%

  • O3 vs Dimensity 9500:+50.0%

  • O3 vs A19 Pro:+103.6%

這就是為什麼 O3 的 522 萬分很值得注意。不過要特別強調,O3 的 522.8 萬是小米公布的測試成績,而 Snapdragon / Dimensity / A19 Pro 的數字是目前公開實機/彙總成績,測試條件並不完全一致,所以不能把 +32.6% 當成嚴格的實際使用性能差距。(Notebookcheck)


3. CPU:O3 才是最驚人的地方

Geekbench 多核:

O3 15,221
→ Snapdragon 8 Elite Gen 5 約 11,033
→ A19 Pro 約 10,558
→ Dimensity 9500 約 9,553

換算:

比較O3 優勢
vs Snapdragon 8 Elite Gen 5+38%
vs A19 Pro+44%
vs Dimensity 9500+59%

這部分其實比 AnTuTu 更值得注意。

O3 使用的是非常激進的 10-core all-big-core 設計:

  • 2 × C1-Ultra @ 4.35 GHz

  • 4 × C1-Premium @ 3.68 GHz

  • 4 × C1-Pro @ 3.15 GHz

也就是說,它完全沒有傳統的小型 efficiency core。另外有 44 MB 的晶片內快取(L2 + L3 + SLC)。(Notebookcheck)


4. 單核反而不是 O3 第一

這裡 Apple 仍然很強:

A19 Pro ≈ 3,970
O3 = 3,945
Snapdragon 8 Elite Gen 5 ≈ 3,640
Dimensity 9500 ≈ 3,228

也就是:

單核:A19 Pro ≈ O3 > Snapdragon > Dimensity

所以如果只看 App 開啟、單執行緒、部分 UI latency,O3 並沒有 AnTuTu 522 萬那麼誇張。

公開 Geekbench 資料也顯示 A19 Pro 仍然具有非常強的單核能力。(Geekbench)


5. GPU:這次 O3 也非常猛

這是我認為 O3 真正可能改變 Android SoC 排名的地方。

小米公布:

O3

3DMark Steel Nomad Light:4,567

相較 O1:

+85%

而:

3DMark Solar Bay Extreme:3,628

相較 O1:

+182%

小米甚至宣稱 Solar Bay Extreme 比 A19 Pro 高 63%。(Notebookcheck)

而目前 Dimensity 9500 在普通 Solar Bay 約 13,319,Snapdragon 8 Elite Gen 5 約 12,156。Dimensity 在目前公開的兩個 3DMark 項目中反而領先 Snapdragon。(Itechguides)

所以 GPU 目前比較合理的理解是:

O3 很可能是 Android GPU 的新高點,但必須等正式量產手機的完整 3DMark 套件才能下定論。


6. AI / NPU

這方面 O3 也非常激進:

SoCAI 特點
O3200 TOPS,A8W4
Snapdragon 8 Elite Gen 5Hexagon NPU
Dimensity 9500MediaTek NPU
A19 ProApple Neural Engine

O3 的 NPU 是 200 TOPS(A8W4:INT8 activation / INT4 weight),而且 GPU 本身還加入 NX tensor accelerator。

這對你之前關注的 LLM / AI inference 其實特別有意思:O3 並不是單純追求 AnTuTu,而是把 GPU + NPU + memory bandwidth 一起重新設計。(Notebookcheck)


7. 最重要的排名

如果按照目前資料,我會這樣排:

🥇 CPU 多核

O3 > Snapdragon 8 Elite Gen 5 > A19 Pro > Dimensity 9500

🥇 CPU 單核

A19 Pro ≈ O3 > Snapdragon 8 Elite Gen 5 > Dimensity 9500

🥇 AnTuTu

O3 >>> Snapdragon 8 Elite Gen 5 > Dimensity 9500 > A19 Pro

🥇 GPU

目前:

O3? > Dimensity 9500 > Snapdragon 8 Elite Gen 5 > A19 Pro

但 O3 的「>」目前還要等實機驗證。

🥇 AI

O3 很可能是這四顆裡最值得關注的

因為它不只是 NPU,而是 NPU + GPU NX accelerator + LPDDR6 + 113.8 GB/s bandwidth 整體一起做。(Notebookcheck)


我的結論

如果把目前四顆 SoC 放在一起,我會給:

SoCCPUGPUAI能效綜合
玄戒 O3⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐?S+
Snapdragon 8 Elite Gen 5⭐⭐⭐⭐½⭐⭐⭐⭐½⭐⭐⭐⭐½⭐⭐⭐⭐½S
Dimensity 9500⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐S
A19 Pro⭐⭐⭐⭐⭐⭐⭐⭐⭐½⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐S

O3 最大的問題現在不是「性能夠不夠強」,而是「522 萬分能不能在量產手機長時間維持」。

因為 O3 是 10 顆大核心、最高 4.35 GHz、16-core GPU,峰值性能非常漂亮;真正需要看的反而是 10~30 分鐘 CPU/GPU stress test 後會掉多少、手機功耗多少、機身溫度多少。

而且 O3 預計在 2026 年 9 月搭載於小米 18 Fold、Xiaomi Pad 9 Pro Max,屆時才會有大量第三方實機數據。(Notebookcheck)

如果你是想看**「實際玩遊戲」**,我建議下一步直接比較 O3 vs 8 Elite Gen 5 vs Dimensity 9500 的 Genshin / 原神、鳴潮、絕區零、3DMark 20 分鐘降頻、功耗與 FPS;那個排名會跟 AnTuTu 完全不一樣。

AnTuTu V11 flagship SoC comparison

目前公開的 AnTuTu V11 成績;XRing O3 為小米公布的 5,228,014 分。

chipscore
玄戒 O35,228,014
Snapdragon 8 Elite Gen 53,942,923
Dimensity 95003,485,039
A19 Pro2,568,709

黃山江南遊—黃山八天旅遊團