Astrometry.net 计算特征与异构加速分析

核心结论

Astrometry.net 不是单一类型的计算，而是“规则图像流 + 小规模组合搜索 + 不规则树检索 + 候选验真”的混合流水线。最优方案通常是异构分工，而不是把整个程序原样搬到某一种加速器。

PARALLELISM能并行，但粒度不同

像素、星点、Quad、候选 WCS 和不同图像均可并行；单次树遍历和逐步证据累计存在依赖。

FPGA前端最合适

背景估计、阈值、连通域、质心和 Quad 算术规则，适合流式流水；k-d 树随机访存更困难。

GPU批量吞吐优先

高分辨率图像和大批量任务容易占满 GPU；单幅、少候选、快速提前退出时未必胜过 CPU。

CPU后端控制最自然

分支、递归、随机内存访问、候选提前接受/拒绝和小矩阵求解都更适合低延迟 CPU。

工程上最推荐：相机/图像 → FPGA 或 GPU 完成背景、检测、连通域与质心 → 只把几百个星点交给 CPU 完成 Quad、索引检索、WCS、贝叶斯验真和 SIP。

1. 分析口径与算法边界

Astrometry.net 的公开论文描述了：鲁棒源检测、四星或五星星型几何哈希、预计算索引、候选天体测量解以及贝叶斯模型比较。官方代码结构进一步给出了当前求解路径：源表预处理、A/B 骨架与 C/D 组合、代码 k-d 树搜索、TAN 拟合、候选验证和 SIP 精化。^[1]^[2]

本报告讨论的是单幅图像的求解流水线和多图批处理两种场景。索引构建是离线任务，也可并行，但其频率远低于在线求解，因此只在涉及数据结构时讨论。

重要区分：Astrometry.net 的“几何哈希”最终不是简单整数哈希查表，而是对连续 4D 星型代码进行邻域搜索，官方实现使用紧凑型 k-d 树库 libkd。这决定了后端更像不规则检索，而不是纯向量算术。^[2]^[3]

2. 从图像到 WCS 的计算流水线

PIXEL STREAM背景与噪声局部窗口、中值/近似滤波、差分、平方、统计归约。

OBJECT STREAM检测与质心阈值、局部极值、连通域、像素矩、亚像素坐标。

STAR LIST排序与均匀化亮度 Top-K、空间网格、去直线伪源。

COMBINATIONSQuad 与 4D 代码组合枚举、距离、归一化、几何约束。

IRREGULAR LOOKUP索引检索与 WCSk-d 树范围搜索、参考星读取、小规模拟合。

DECISION贝叶斯验真与 SIP投影、最近邻、似然累积、提前退出、多项式精化。

官方文档明确指出，求解器按亮度逐步加入星点，形成所有新出现的四星组；代码命中后读取索引星的天球坐标，拟合 TAN 投影，调用验证，再在成功后计算 SIP。^[2]

3. 全阶段计算类型、并行性与依赖矩阵

阶段	主要计算	可并行粒度	关键依赖	CPU	GPU	FPGA	工程判断
格式解码/位深转换	FITS/JPEG/PNM 解码、类型转换	行、块、图像	压缩码流可能串行	○	○	○	未压缩传感器流最适合直接接 FPGA；通用压缩解码可留 CPU。
背景估计	局部中值/低通、原图减背景	像素、行、通道	邻域与行缓存	○	◎	◎	规则二维窗口，是 FPGA/GPU 的第一优先级。
噪声估计	差分、平方、求和、方差	样本对、块	末端全局归约	○	◎	◎	Map-Reduce；FPGA 可流式累计，GPU 可块归约。
阈值/局部极值	比较、邻域最大值	像素	固定邻域	○	◎	◎	低成本、高吞吐，易与前级融合。
连通域/去混叠	标签、等价合并、鞍点判断	行、分块、对象	邻居标签与动态状态	○	○	○	可做，但比阈值复杂；FPGA 通常需要定制 CCL/状态机。
亚像素质心	小窗口乘加、除法/拟合	星点	单星内部短依赖	○	○	◎	每个对象独立，DSP 流水友好。
排序/Top-K/均匀化	部分排序、网格分桶	网格、批次	全局或局部次序	◎	○	○	星点只有几百时 CPU 很快；硬件适合做每格 Top-K。
Quad 枚举	组合调度、距离、约束筛选	Quad、A/B 对	当前深度和提前停止	○	◎*	◎*	*批量足够时；否则可能做大量最终用不到的推测工作。
4D 代码	加减乘、平方、倒数、比较	Quad	单 Quad 固定流水	○	◎	◎	算术规则，适合定点化和多引擎复制。
代码 k-d 树	分支遍历、范围搜索、随机访存	查询之间	下一节点地址依赖当前比较	◎	△～○	△	原样移植的最大难点；需批量查询、缓存和数据布局重构。
TAN/WCS 候选	坐标投影、小矩阵、三角函数	候选之间	候选内短链	◎	△	○	工作量小，单独卸载常被通信开销吞噬。
贝叶斯验真	投影、最近邻、似然累积	候选、参考星	前缀累计、匹配状态、提前退出	◎	○*	△～○	*大量候选并行时更合适；单候选控制流偏 CPU。
SIP 精化	多项式基、小矩阵拟合	观测点	矩阵归约与分解	◎	△	△	规模小且只在成功后做，通常不是首要热点。

4. 图像前端：最规则、最适合流式加速

论文中的源检测先进行背景压平和噪声估计，再检测显著像素、连接成对象并求亚像素位置。无论具体滤波窗口如何调整，这一段都具有高算术规则性和强空间局部性。^[1]

4.1 背景估计与行缓存

二维窗口滤波存在“依赖邻近行”的关系，但这种依赖可由行缓存转化为固定流水延迟。缓存填满后，后续像素仍可做到每周期一个或多个。

示意架构。连通域需要动态标签状态，但仍可按扫描线流水。

计算样例 A · 4K 图像的数据量压缩

为什么把源提取放到 FPGA/GPU 前端特别划算

4096 × 4096 × 16 bit = 268,435,456 bit = 33,554,432 byte = 32 MiB / frame

10 frame/s 时原始像素带宽 = 320 MiB/s（不含协议与空白期）

若一帧最后保留 512 个星点，每个星点用 16 byte 保存 x, y, flux, flags：

512 × 16 byte = 8,192 byte = 8 KiB

32 MiB ÷ 8 KiB ≈ 4096 倍的数据量收缩

这意味着 FPGA 直接接传感器时，可以在像素仍位于片上流水线内完成绝大多数带宽密集工作，只把数 KiB 的稀疏星点表交给 CPU。

计算样例 B · 行缓存资源

5×5 与 31×31 窗口的缓存量差异

对宽度 4096、16-bit 灰度图，N×N 滑动窗口至少需要缓存 N−1 条完整前序行：

5×5：4 × 4096 × 16 bit = 262,144 bit = 32 KiB

31×31：30 × 4096 × 16 bit = 1,966,080 bit = 240 KiB

因此小窗口中值可以直接用排序网络；大窗口背景估计更适合直方图中值、分块近似、降采样背景图或 Box/Gaussian 近似，否则比较器和片上存储会迅速膨胀。

4.2 噪声估计：典型 Map-Reduce

若用相隔一定距离的像素对差值 dᵢ 估计单像素噪声，并假设两像素噪声独立、方差相同，则：

Var(d) = 2σ²　⇒　σ = √(mean(dᵢ²) / 2)

计算样例 C · 8σ 阈值

用 8 个像素对差值估计噪声

d = [−4, 2, 0, 4, −2, 2, −4, 2] ADU，mean(d)=0

Σd² = 64，mean(d²)=8，σ = √(8/2)=2 ADU

若局部背景为 100 ADU，8σ 检测阈值 = 100 + 8×2 = 116 ADU

在 FPGA 上，每个样本只需减法、平方和累加；最后一次开方可由 CORDIC、平方根 IP 或 CPU 完成。GPU 则可先在块内归约，再合并块统计量。

4.3 连通域与质心

阈值比较完全并行，连通域则有左、上、左上、右上标签依赖，并可能产生标签等价关系。FPGA 常用单遍扫描 + 标签 RAM + 等价表；GPU 常用分块标签与多轮合并。质心可以边扫描区域边累计：

x̄ = Σ(Iᵢxᵢ)/ΣIᵢ　　ȳ = Σ(Iᵢyᵢ)/ΣIᵢ

计算样例 D · 3×3 星点质心

像素块原点位于图像坐标 (100, 200)

强度矩阵 I(y,x)
[ 0  1  0 ]
[ 1  8  3 ]
[ 0  4  2 ]

ΣI = 19；Σ(I·x) = 23；Σ(I·y) = 24

局部质心 = (23/19, 24/19) = (1.2105, 1.2632)

全图质心 = (101.2105, 201.2632)

乘加可以完全流水，最后两个除法可共享倒数单元。不同星点之间无数据依赖。

相关硬件工作已经证明这一模式可行：一项 2022 年 FPGA 星质心研究对 2048×2048 图像报告约 5.2 ms 的单帧仿真处理时间；一项 2024 年 Zynq-7020 HW/SW 协同工作在 4MP 图像上达到 24 FPS 以上，并把图像预处理、聚类和质心等部分放入可编程逻辑。^[5]^[6]

5. 星点排序、Top-K 与空间均匀化

官方流程会去除近直线排列的伪源、按亮度与背景信息重新排序，并选取空间上较均匀的星点子集。求解器从最亮源开始逐步增加深度。^[2]

CPU

对数百个星点做部分排序、堆或网格分桶非常便宜；低延迟且实现简单。

GPU

可用 radix/bitonic，但数据量太小时 kernel 启动和搬运可能大于计算本身。

FPGA

最适合“每个空间网格保留 K 个最亮点”，避免构建大型全局排序网络。

硬件友好改写：把“全局排序后再均匀化”改写为“流式网格 Top-K → 汇总少量候选 → CPU 最终排序”。它保持算法意图，同时减少片上资源。

6. Quad 枚举与 4D 几何码

四个星点组成的 Quad 先选最远的 A、B 作为骨架，再把 C、D 映射到由 A、B 定义的归一化坐标。不同 Quad 完全独立，算术规则，但组合数量可能爆炸；官方实现通过尺度约束、几何约束和按亮度逐步增加星点来避免全枚举。^[1]^[2]

计算样例 E · 组合数量

如果不剪枝，四星组合增长有多快

N_quad = C(S,4) = S(S−1)(S−2)(S−3)/24

星点数 S	C(S,4)	含义
20	4,845	尚可批量尝试。
50	230,300	已需要强剪枝和提前停止。
100	3,921,225	直接全枚举会制造大量无用计算与索引查询。

GPU/FPGA 可以高速产生大量 Quad，但 Astrometry.net 常在前几个有效 Quad 上就找到解。并行过度会产生“推测执行浪费”。

6.1 数值示例：4D 代码保持不变

将二维点写成复数，并定义：

z(P) = (1+i) · (P−A)/(B−A)，q = (Re z(C), Im z(C), Re z(D), Im z(D))

计算样例 F · 平移、旋转、缩放不变性

原始四点

A=(10,20)，B=(110,120)，C=(50,50)，D=(70,90)

由于 B−A=(100,100)=100(1+i)：

z(C)=(1+i)(40+30i)/(100+100i)=0.4+0.3i

z(D)=(1+i)(60+70i)/(100+100i)=0.6+0.7i

q=(0.4, 0.3, 0.6, 0.7)

整体旋转 90°、放大 2 倍，再平移 (1000,−300)

P′ = 2·R₉₀(P) + (1000,−300)

A′=(960,−280)，B′=(760,−80)，C′=(900,−200)，D′=(820,−160)

重新计算仍得到 q′=(0.4, 0.3, 0.6, 0.7)

这正是几何哈希可以跨图像位置、旋转和尺度检索同一星型的原因。镜像会改变 parity，因此求解器会测试相应排列。

6.2 FPGA 数据通路

Star RAM → 读 A,B,C,D
        → Δx, Δy 与距离平方
        → 选择/验证最长骨架 A-B
        → 倒数或归一化系数
        → C,D 坐标变换
        → 圆内约束、Cx≤Dx、parity 检查
        → 4D code FIFO

单个 Quad 的依赖链固定，可做深流水；多个 Quad Engine 可并行复制。困难主要在组合调度、星表多端口读取、FIFO 背压和一旦成功后的全局取消。

计算样例 G · 定点位宽可行性

用 signed Q2.14 表示归一化坐标

最小步长 LSB = 2⁻¹⁴ = 0.000061035

若 Quad 骨架长度为 2000 pixel，一 LSB 对应 2000×2⁻¹⁴ ≈ 0.122 pixel

这个数量级与亚像素定位误差相近，说明 16-bit 定点可能作为初始设计点；最终位宽仍需用真实图像、索引容差和误匹配率做扫参验证。

7. 4D k-d 树检索：后端加速的真正难点

官方代码在代码 k-d 树中搜索与图像 Quad 近似的索引 Quad；命中后再通过星表 k-d 树读取参考星和验证范围内的星。^[2]

node = root
while node is not leaf:
    axis  = node.axis
    near  = query[axis] < node.split ? left : right
    far   = other child
    visit(near)
    if query ball intersects split plane:
        visit(far)

查询之间

高度并行可交错不同 Quad 的查询彼此独立，可同时保留很多查询上下文。

单次查询内部

地址依赖下一节点地址由当前节点比较决定，路径长度和返回候选数也不固定。

GPU 依靠大量线程隐藏延迟，但会遇到 warp 分支发散；FPGA 可保留多个查询状态机交错发出访存请求。

7.1 为什么 GPU 不一定自动获胜

同一 warp 的线程可能进入不同子树，造成分支发散。
节点访问不连续，缓存命中与内存合并较差。
每个查询返回候选数不同，负载不均衡。
单幅图像可能只做少量查询，无法形成足够并行度。

GPU 更适合索引常驻显存、一次批量提交许多图像或许多 Quad 的场景，并配合数组化节点、Structure-of-Arrays、packet traversal 或广度优先队列。

7.2 FPGA 上的存储问题

完整索引通常远大于片上 BRAM/URAM，因此只能把树顶层和热点目录放片上，底层节点与叶数据放 DDR/HBM。此时性能取决于可并发的查询上下文、外存随机访问效率和候选列表布局。

更硬件友好的替代设计：将连续 4D 代码定点量化成桶 ID，BRAM 保存桶起始地址与长度，DDR/HBM 保存连续候选列表，再由固定流水做精确 4D 距离检查。它可把“逐节点随机访问”改为“目录访问 + 突发读取”，但需要重建索引并评估量化边界、存储膨胀和误匹配率。

8. WCS 候选、贝叶斯验真与 SIP

8.1 TAN/WCS 候选

索引 Quad 命中后，求解器读取对应参考星天球坐标，拟合 TAN 投影并生成候选 WCS。每个候选彼此独立，但单个候选只有小规模坐标变换和矩阵运算，单独卸载到加速器通常不划算。^[2]

8.2 贝叶斯验真

候选并不是“Quad 相似就接受”，而是用更多图像星点和参考星比较真匹配模型与偶然背景模型。证据按亮度顺序逐步累计，并可提前接受或拒绝。^[1]

Lₙ = Lₙ₋₁ + log[p(sₙ|真匹配) / p(sₙ|背景)]

计算样例 H · 前缀依赖与提前退出

示意阈值：接受 +6，拒绝 −3（非官方阈值）

星点序号	正确候选增量	累计 L	错误候选增量	累计 L
1	+1.8	1.8	+0.2	0.2
2	+2.0	3.8	−1.1	−0.9
3	−0.4	3.4	−0.8	−1.7
4	+2.9	6.3 → 接受	−1.5	−3.2 → 拒绝

每颗星的局部似然可以并行算，但是否继续、是否匹配冲突以及累计证据具有状态依赖。最自然的并行方式是“多个候选并行，每个候选内部保留一个短状态机”。

8.3 SIP 畸变精化

SIP 通常包含多项式基函数、残差、矩阵累计与小矩阵求解。观测点可并行累积，但最终分解有依赖；而且它只在候选已经成功后执行一次，所以通常不应列为第一批硬件热点。

9. 前后数据依赖关系：哪些是“可流水依赖”，哪些是“控制依赖”

环节	依赖类型	能否并行	典型解决方式
二维滤波	前 N−1 行与邻域像素	能	行缓存 + 滑动窗口；依赖只产生固定启动延迟。
噪声/直方图	全局统计值决定阈值	能，但有同步点	两遍图像、帧缓存，或上一帧统计用于下一帧。
连通域	邻居标签与等价关系	行/块级	标签 RAM、Union-Find、分块合并。
排序	全局顺序	部分	网格 Top-K、部分排序、批量 radix/bitonic。
Quad	依赖星点列表和当前深度	Quad 间能	候选生成器 + 多个代码引擎 + 取消令牌。
k-d 树	下一地址依赖当前节点	查询间能，查询内弱	多上下文交错、缓存顶层、批量 packet traversal。
贝叶斯验证	证据前缀、匹配状态、提前退出	候选间能	每候选一个线程块/状态机；局部距离并行。
SIP	矩阵归约与分解	数据点间部分并行	并行累积，CPU 完成小矩阵分解。

关键判断：“有数据依赖”不等于“不能并行”。图像窗口是可预测、固定延迟的流水依赖；k-d 树和验真则是地址、分支和提前退出驱动的动态控制依赖。

9.1 跨阶段能否重叠

前端可以在后半帧仍进入时，持续输出前半帧已闭合的星点区域；网格 Top-K 也可边接收边更新。但 Quad 构造通常需要一份足够稳定的星点排名，因此在“前端星点流”和“后端求解”之间会存在帧级或阶段级屏障。

10. CPU、GPU 与 FPGA：性能差异应怎样判断

公开官方实现的核心仍以 C/Python 和 k-d 树库为主；目前没有一组可信的官方“完整 Astrometry.net CPU vs CUDA GPU”一对一基准。因此下面的结论基于计算结构与相关星跟踪硬件实测，而不是宣称固定倍数。^[3]

CPU：低延迟与不规则控制

少量星点和候选时启动成本最低。
分支预测、缓存和递归适合树遍历。
提前成功可立即停止，不浪费大批并行任务。
多图可粗粒度“每核一图”。

GPU：大批量与规则前端

像素滤波、阈值、对象属性计算吞吐高。
Quad 和候选可批量并行。
索引需常驻显存以避免频繁搬运。
树路径发散、任务量太小会降低利用率。

FPGA：流式、低功耗与确定性

直接接相机，避免完整帧往返内存。
固定窗口、CCL、质心和 4D 代码可深流水。
随机大索引超出片上存储，需要 DDR/HBM。
开发成本高，算法变化需要重新综合或重构。

10.1 不同场景的胜负关系

场景	推荐平台	原因
单幅图，已有 x/y 星点表，追求最低响应时间	CPU	数据少、树检索不规则、容易很快提前成功。
单幅 4K/8K 原始图像	GPU 前端 + CPU 后端	像素阶段占带宽，后端候选少。
相机持续流、星载/边缘、功耗与确定性优先	FPGA 前端 + ARM/CPU	流式像素处理和极强数据压缩，控制后端留软件。
数百/数千幅图离线批处理	GPU + 多核 CPU	GPU 可批量前端和候选，CPU 并行处理图像与不规则检索。
只想低风险提升现有软件	CPU 优化	提供尺度/位置提示、缩小索引集合、复用源表，往往比移植硬件更直接。官方文档也强调尺度提示可显著减少索引搜索。^[3]
愿意重建索引并追求极致吞吐	FPGA/HBM 或 GPU	把 k-d 树重构为量化桶或批量无分支结构，收益潜力较大但兼容成本最高。

10.2 相关 FPGA 实测能说明什么

2024 年的 Zynq-7020 星跟踪 HW/SW 协同实现把阈值、聚类和质心等图像处理放入 PL，在 4MP 图像上达到 24 FPS 以上，并报告 8.9× 系统级加速。论文还指出其特定算法中预处理和质心占总体复杂度的 95% 以上。这个比例不能直接套到 Astrometry.net，但强烈支持“前端上 FPGA、匹配留 CPU”的分工。^[6]

11. 加速比算例：为什么必须先 Profile

整套系统的收益由 Amdahl 定律决定。某一模块即使加速很多倍，如果它只占总时间很小，端到端收益仍有限。

Speedup = 1 / Σ(fᵢ / sᵢ)

计算样例 I · 假设一帧原始耗时 100 ms

示意 Profile，不是 Astrometry.net 官方实测

前端 65 ms

Quad 15 ms

树/WCS/验真 20 ms

方案 A：前端 FPGA 加速 20×，Quad 加速 5×，后端不变：

T′ = 65/20 + 15/5 + 20 = 3.25 + 3 + 20 = 26.25 ms

端到端加速比 = 100 / 26.25 = 3.81×

方案 B：只把 Quad 做成 20× 加速器：

T′ = 65 + 15/20 + 20 = 85.75 ms，端到端仅 1.17×

这说明“Quad 很适合 FPGA”并不等于“先做 Quad 一定最值”。真正的优先级必须由目标图像、索引和参数下的 Profile 决定。

11.1 GPU 批量门槛的示意模型

计算样例 J · 调度开销与批量摊销

纯示意，不是产品 benchmark

假设某小任务 CPU 需要 1.5 ms/image；GPU 一次批次有 3 ms 固定启动/传输成本，之后 0.35 ms/image：

CPU：T_CPU=1.5N　　GPU：T_GPU=3+0.35N

3+0.35N < 1.5N ⇒ N > 2.61

在这个示意模型里，批次至少 3 幅图才开始有利。真实门槛取决于图像大小、PCIe/统一内存、索引是否常驻显存和 kernel 融合程度。

12. FPGA 硬件 IP 与可复用模块图谱

不存在主流厂商提供的“完整 Astrometry.net 一键 IP”。可用的是大量基础积木，以及若干星跟踪/质心研究实现。AMD Vitis Vision 当前文档列出了像素级并行、Box/Gaussian/Median、Histogram、Mean/StdDev、Threshold、Custom CCA、倒数和平方根等函数，可通过 HLS 生成硬件内核。^[4]

Astrometry.net 子任务	可复用 IP/库	仍需定制的内容
像素接口	AXI4-Stream、Video DMA、MIPI/Camera 接口、DDR 控制器	帧格式、背压、跨时钟域。
背景与统计	Median/Box/Gaussian、Histogram、Mean/StdDev、Subtract、Accumulate Squared	Astrometry.net 的窗口选择、边界、鲁棒统计。
阈值与局部极值	Threshold、Compare、Min/Max、形态学	动态阈值策略与星点去混叠。
连通域	Custom CCA 示例、定制流式 CCL	流式标签表、区域闭合、资源上限与溢出处理。
质心	DSP MAC、Divider/Reciprocal、Floating Point、CORDIC	中心矩/高斯拟合、异常像素和饱和处理。
Top-K	Sorting Network、sortTopK、BRAM heap	空间网格策略、亮度/背景复合评分。
Quad 代码	乘加、平方根/倒数、定点比较	组合调度、parity、约束、取消控制。
k-d 树	DDR/HBM、缓存、通用图/搜索原语	Astrometry 索引格式、范围查询、多上下文调度；通常没有直接可用 IP。
WCS/SIP	Floating Point、CORDIC、小矩阵 QR/LU	投影模型、数值稳定性和软件兼容。

避免误区：“库里有 CCA/中值/平方根”只代表基本运算可复用，不代表 Astrometry.net 的源提取、Quad 索引和贝叶斯验真可以不经算法重构直接连起来。

13. 推荐的三阶段工程架构

阶段 1：低风险、高收益

这也是相关 SoC FPGA 星跟踪工作的常见分工：PL 加速检测/质心，PS 负责匹配和控制。

阶段 2：在 Profile 证明必要后加入 Quad Engine

把 A/B 对调度、C/D 筛选和 4D 代码生成放到 FPGA/GPU，CPU 仍负责原始索引格式与验证。这样既能保留兼容性，又能避免最难的随机检索硬件化。

阶段 3：重构索引后端

若目标是大批量、高吞吐或星载完全自主求解，可研究 4D 量化桶、HBM 候选列表或 GPU 批量无分支检索。这一步已不是简单“加速 Astrometry.net”，而是保留其 Quad + 全场验真思想、重新设计数据结构。

13.1 推荐开发顺序

在目标数据集上用阶段计时拆分：源提取、排序、Quad、索引、验证、SIP。
先复用 .xyls/.axy 输入路径，分别测“原图求解”和“星点表求解”，隔离前端占比。
做 FPGA/GPU 前端原型，检查星点召回率、假点率和质心误差，而不只看 FPS。
将前端输出送回未修改的 CPU 求解器，验证求解率和误匹配率。
只有当 Quad 或索引成为新瓶颈时，再做下一阶段。

14. 一套可复现的 CPU/GPU/FPGA 基准测试方案

不能只报告“单帧耗时”，因为 Astrometry.net 的长尾高度依赖图像质量、星点数量、已知尺度、所用索引和是否很快找到正确 Quad。

维度	建议分组	必须记录的指标
输入形式	原始 FITS/JPEG；已提取 x/y 列表	前端耗时、后端耗时、传输耗时。
分辨率	1MP、4MP、16MP、64MP	pixel/s、frame/s、内存带宽。
星点数量	20、50、100、300、1000	Quad 数、k-d 查询数、候选数。
先验	完全盲解；给尺度；给位置半径	所加载索引数、求解时间分布。
图像质量	清晰、拖线、云、渐变、畸变、热像素	源召回/假点率、成功率、假阳性。
批量	1、4、16、64、256 幅	首帧延迟、稳态吞吐、P50/P95/P99。
功耗	CPU 包功耗、GPU 板卡功耗、FPGA PL/PS	J/frame、J/solved-frame。

最关键的正确性指标：最终 WCS 成功率、错误接受率、角位置残差、像素残差和困难图像 P95/P99 延迟。只优化源检测 FPS，可能因为漏掉关键亮星而让整套求解更慢或失败。

15. 最终判断

是否可并行：可以。像素、星点、Quad、候选和多幅图像均有并行性；单次树路径、证据前缀和提前退出有依赖。
是否适合 FPGA：背景、统计、阈值、连通域、质心和 4D 代码非常合适；原始 k-d 树、动态验证和 SIP 不应作为第一批模块。
是否有现成 IP：有大量图像处理、统计、浮点、CORDIC、排序和存储接口 IP；没有完整 Astrometry.net IP，星点去混叠、Quad 调度、索引和验真仍需定制。
前后依赖：前端多为可流水的邻域依赖；后端多为分支、随机地址和提前退出依赖。
CPU 与 GPU：单幅低延迟、少量候选和不规则检索通常偏 CPU；高分辨率前端、大批量图像和大量候选更偏 GPU。
最现实路线：FPGA/GPU 源提取 + CPU 求解；第二步才考虑 Quad Engine；最后才考虑重构索引。

参考资料

Lang, D. et al. (2010). “Astrometry.net: Blind astrometric calibration of arbitrary astronomical images.” The Astronomical Journal, 139, 1782–1800. arXiv:0910.2233.
Astrometry.net 官方文档：“Astrometry.net code structure.” 描述从 solve-field、源表预处理、Quad/k-d 树、TAN 拟合、验证到 SIP 的调用路径。官方代码结构页.
Astrometry.net 官方 README：索引尺度、libkd、源表输入、深度策略、尺度提示与性能建议。官方 README.
AMD Vitis Vision Library 2025.2. FPGA/AI Engine 优化的计算机视觉函数，包括像素并行、滤波、统计、阈值、Custom CCA、倒数与平方根等。AMD 官方文档.
Ding, J. et al. (2022). “Implementation of a real-time star centroid extraction algorithm with high speed and superior denoising ability.” Applied Optics 61, 3115–3122. 论文摘要.
Panousopoulos, V. et al. (2024). “HW/SW co-design on embedded SoC FPGA for star tracking optimization in space applications.” Journal of Real-Time Image Processing 21, 16. 开放获取论文.
Astrometry.net GitHub Repository. 当前公开代码、发行版和论文引用信息。GitHub 仓库.

关于文中数字：4K 带宽、行缓存、噪声、质心、Quad、定点、Bayes、Amdahl 和 GPU 批量门槛均为可复算的教学/架构算例；5.2 ms、24 FPS 与 8.9× 等为对应文献特定算法和硬件平台结果，不能直接视为完整 Astrometry.net 的性能。