计算机视觉人工智能深度学习图像处理【免费下载链接】kornia Geometric Computer Vision Library for Spatial AI项目地址https://gitcode.com/gh_mirrors/ko/kornia点击查看免费下载Kornia 文档站中的 ONNX, torch.compile and torch.export support导出支持页面并非人工维护的表格而是由docs/export_support/目录下的一套可复现的全库图捕获调查流水线自动生成的。每个 Kornia 公开算子都会被以具体 CPU float32 输入跑过 PyTorch 的三条图捕获路径ONNX 导出、torch.export、torch.compile逐条记录成功/失败及根因最后合并成一份提交到仓库的 JSON 快照在文档构建时渲染为网页。本文将讲解测量了什么、case(...)注册协议、三条探测管线各自怎么工作、如何重新生成快照、合并阶段的校验策略以及如何新增一个 case 并让它在页面上呈现。读者读完即可复现这份调查或把同样的注册-探测-合并-渲染模式迁移到自己的 PyTorch 项目上。背景链接export_support 文档、导出支持页面源、页面入口第 74 行引用该页面。一、整体架构一份提交的快照一次构建期渲染docs/source/get-started/export-support.rst是最终支持页面的源文件但它由 docs/generate_export_support.py 在文档构建时从 docs/source/_data/export_support.json 渲染生成。该 JSON 是docs/export_support/目录测量结果的提交快照文档构建期间不会执行任何探测代码nothing here runs during a docs build。流水线概览docs/export_support/cases_*.py # case 注册每个公开算子 具体输入 │ run.py并行调度 可续跑 ├── harness.py ──► results/onnx_*.json ONNX 探测 └── probe_compile.py ──► results/compile_*.json export compile 探测 │ merge.py校验 合并 ▼ docs/source/_data/export_support.json # 提交的快照 │ docs/generate_export_support.py构建期渲染 ▼ docs/source/get-started/export-support.rstharness.py 的模块 docstring 明确说一个case是一个公开 kornia 可调用对象函数或nn.Module实例加上一组具体的张量输入每个张量输入都会成为 ONNX 图的一个输入Python 侧的关键字参数则烘焙为常量写入图中。二、测量什么6 个 case 注册文件每个case是一个公开可调用对象 具体 CPU float32 输入注册在 6 个cases_*.py文件之一文件覆盖范围cases_aug.pykornia.augmentation2D、3D、容器、自动策略cases_feature.pykornia.feature检测器、描述子、匹配器cases_geomA.pykornia.geometry变换、转换、相机、标定cases_geomB.pykornia.geometry其余部分对极几何、李群、Boxes 等cases_misc.pykornia.filters、color、enhance、morphology、contrib、losses、metrics、utils、sensors、io、nerf、tracking、xcases_models.pykornia.models权重未缓存时自动下载快照头部export_support.json末尾记录了精确的测量环境例如当前快照generated_at: 2026-09-02, kornia: 0.9.0rc1, torch: 2.9.1cu128, onnx: 1.21.0, onnxruntime: 1.23.2, onnxscript: 0.5.7, opset: 18, python: 3.11.14, device: cpu, revision: e0969438run.py 中GROUPS [aug, feature, geomA, geomB, misc, models]与上述文件一一对应。从 cases_geomB.py 可以看到实测案例的典型形态例如_cc(rad2deg, C.rad2deg, [torch.rand(2, 3) * 6.0]), # geometry.conversions _ce(find_fundamental, E.find_fundamental, [pts1, pts2], note8POINT), # geometry.epipolar _cam(PinholeCamera.project, lambda intr, extr, p: PinholeCamera(...).project(p), [...]) _clg(So3.exp.matrix, lambda v: So3.exp(v).matrix(), [so3_v])同一个算子有多个代码路径时用name[variant]约定命名如find_fundamental[7POINT]、unproject_points[normalize]、RANSAC[fundamental_7pt]使它们在页面同一行下分组[random]后缀表示采样在图中进行的随机模式详见第四节。三、case 注册协议case(...)的参数case(...)定义在 harness.py签名如下def case( name: str, # 唯一显示名通常用公开可调用名如 filters.filter3d group: str, # 报告分组filters、geometry.epipolar、feature.descriptors... target: Any, # nn.Module 实例或普通可调用 fn(*inputs, **kwargs) inputs: list[torch.Tensor], # 张量每个都会成为 ONNX 图的活输入 kwargs: dict | None None, # Python 侧关键字参数烘焙为常量 *, note: str , # 页面上展示的自由文本 check: bool True, # False图内有随机性只做导出运行输出不校验 atol: float 2e-4, # 数值比较容差 rtol: float 1e-3, skip: str | None None, # 给出理由时该 case 直接标记 skipped不运行 tags: tuple[str, ...] (), # 例如 (3d, model, pretrained) method: str | None None, # 在模块上调用该方法而非 forward如 detect ) - dict[str, Any]关键语义来自 docstring 与run_case实现inputs中的每个张量都是 ONNX 图的输入非张量位置参数必须放进kwargs前提是可调用对象支持按关键字接收否则用 lambda 包裹checkFalse用于图内带随机性的算子——RNG 流在图内不同无法逐值对比探测结果记为ok-unverified程序能跑、输出形状正确且值有限skip用于不适合作为张量图的条目例如cases_geomB.py中的save_pointcloud_ply文件 I/O、quaternion_to_angle_axis已废弃别名它们会以skipped/n/a呈现method用于调用模块的非 forward 方法如RANSAC.estimate_model_from_minsample见cases_geomB.py中methodestimate_model_from_minsample的用法。注册文件的主入口统一为如cases_aug.py末尾if __name__ __main__: run_cases(CASES, sys.argv[1], onlysys.argv[2:] or None)即python cases_aug.py out.json [names...]可选地只跑部分 case按名字、组或前缀过滤见run_cases的only逻辑。四、三条探测管线对每个 case 依次执行 eager 参考运行 三条捕获路径。4.1 ONNX 探测harness.py 的 run_caseharness.py 的流程eager 参考make_wrapper把任意可调用包装成固定元数的nn.Module动态生成forward(in0, ..., inN-1)并用_flatten_outputs把 kornia 的容器类输出Boxes、Keypoints、Se3、Quaternion、Image等通过.data属性暴露张量展平成张量元组然后torch.manual_seed(SEED)SEED1234下no_grad运行得到参考输出导出torch.onnx.export(m, inputs, dynamoTrue, opset_version18)输出重定向到os.devnull以避免 dynamo 打印整张 FX 图支持KORNIA_SURVEY_OPTIMIZE0环境变量关闭导出优化校验onnx.checker.check_model(model, full_checkTrue)运行对比onnxruntime.InferenceSession(blob, providers[CPUExecutionProvider])运行图与 eager 输出做np.allcloseclose函数还处理 NaN 模式、bool 输出、形状差异默认atol2e-4, rtol1e-3记录算子类型集合op_types含子图递归与自定义 domain 标记、模型大小size_kb、墙钟时间time_s失败时记录根因错误err_str沿__cause__/__context__链取最深错误以及涉事的 kornia 源码帧_kornia_frames最多 6 帧。状态全集docstring 中列出ok | ok-unverified | eager-fail | export-fail | checker-fail | ort-load-fail | ort-run-fail | mismatch | no-tensor-output | skipped。随机算子的处理if not c[check]时直接记ok-unverified只验证输出个数与形状不逐值比较——因为图内 RNG 流与 eager 不同。cases_aug.py中Rand包装器还重写了eval()返回 self确保 harness 调.eval()后增强模块仍保持 train 模式采样留在图内。4.2 torch.export 与 torch.compile 探测probe_compile.pyprobe_compile.py 复用同一批注册文件python probe_compile.py cases_module out.json [names...]每条记录exporttorch.export.export(wrap, inputs)非严格模式默认→ok | fail | eager-fail | skipped带 420 秒SIGALRM超时保护compile先用torch._dynamo.explain(wrap)(*inputs)统计graph break 数与 break 原因再torch.compile(wrap)默认 inductor 后端fullgraphFalse运行并与 eager 对比 →ok | ok-breaks:N | ok-unverified | mismatch | fail | eager-fail | skipped额外记录目标可调用对象的可导入限定名qualname供合并阶段生成文档交叉引用torch._dynamo.config.cache_size_limit 64、suppress_errors False。两类特殊的进程级故障处理值得一提TimeoutPOSIX 上用signal.alarm超时即Timeout异常Poisoned某个 case 把 dispatcher 搞坏PythonDispatcherTLS未设置后解释器不可再用进程以退出码POISON_EXIT 3退出由 run.py 负责重启续跑。4.3 失败根因的归因merge.py 把底层错误消息映射为页面上用户可读的原因几个典型类目_CAUSES表数据依赖Could not extract specialized integer from>pixi run -e default install-docs pixi run -e default build-docs # 先构建一次文档让算子获得交叉引用 python docs/export_support/run.py # ~2 小时8 CPU 核可续跑 pixi run -e default build-docsrun.py 的调度语义run.py 为每个 case 组启动两个并行子进程ThreadPoolExecutor共len(groups)*2个 workeronnx:group跑cases_group.pycompile:group跑probe_compile.py。支持的关键参数参数作用python docs/export_support/run.py全量探测全部 6 组约 2 小时run.py aug misc只跑指定 case 组run.py --merge-only不做探测仅用既有 results 重建 JSONrun.py --force即使结果不完整也强制合并可续跑每个探测进程在results/下写onnx_group.json、compile_group.json及对应inventory_*.json每条记录落盘后重启时跳过已有记录的 case因此崩溃segfault 会留下crashed标记的 worker 直接重启即可续跑run_cases中先写 crash 标记再跑run.py中MAX_RESTARTS50循环重启被毒化的解释器。版本印章provenanceinventory_*.json记录该探测用的 kornia revisiongit rev-parse --short HEAD-dirty后缀与torch.__version__harness.provenance。prepare_resume发现记录来自不同 revision/torch 时丢弃而非续跑。merge.py 的合并校验merge.py 在写出快照前做三重校验_validate防止部分运行静默低估覆盖率每个 results 文件必须存在对应inventory_*.jsoninventory 点名的每个 case 都须有非 crash 标记的记录所有组的 inventory 必须指向同一 kornia revision 与 torch 版本。任一不满足即中止合并并打印原因--force可强制合并并在头部盖章测量于什么版本。merge.py还从最近一次文档构建的 Sphinx inventorydocs/build/html/objects.inv解析交叉引用使页面上的算子名成为可点击的文档链接无 inventory 时算子以纯文本渲染。合并输出export_support.json每条 case 的字段包括package、section、operator、variant、ref最短文档化别名、note、三列的*_detail原因文本、graph_breaks、where首个 kornia 源码帧位置。六、案例实操以 augmentation 为例理解两种模式cases_aug.py 展示了最复杂的注册形态其 docstring 明确两部分PART 1确定性组augmentation*aug(img, paramsparams)把采样出的参数张量作为 ONNX 图输入喂入Det包装器容器AugmentationSequential等与自动策略RandAugment等先 eager 调用一次导出时把seq._params固定为常量PART 2随机组*.randomaug(img)且保持 train 模式随机性留在图内checkFalse。以build()辅助函数为例它为一个变换同时注册确定性与随机两个 casebuild(Normalize, G2, lambda: KA.Normalize(mean..., std...), [IMG], directTrue) # directTrue无随机参数 - 确定性 case 就是普通 aug(*data) 调用 build(RandomRotation90, G2, lambda: KA.RandomRotation90(times(1, 3), p1.0), [IMG]) # 默认注册两个 caseRandomRotation90params 喂入 RandomRotation90[random]图内采样值得注意的细节torch.manual_seed(7)在forward_parameters前固定种子保证参数可复现非张量参数batch_prob、forward_input_shape从params中剔除NONPARAM_KEYS保持为常量build(f{_n}[p0.5], ...)用p0.5的默认概率注册 5 个代表性子集P05使逐样本 batch_prob 门控分支真正进入图这是常见的导出阻塞点见P05注释容器用seq_build先 eager 调用填充seq._params导出时SeqDet.forward以paramsparams常量调用页面上的变体分组[variant]由merge._split_name解析RandomCrop[p0.5][random]会变成 operatorRandomCrop、variantp0.5, random。七、页面如何渲染状态语义与统计口径docs/generate_export_support.py 构建期渲染状态 → 单元格STATUS表 _cellok“yes”ok-breaks“yes, N breaks”可编译且匹配 eager但有 graph breakok-unverified“yes (random)”随机算子只验形状与有限性mismatchfail“no”Details 列说明原因n/a不适用的非张量图文件 I/O、枚举、Python 容器、stub统计口径每列计数为supported / probed排除n/a行distinct operators按(package, operator)去重且任一配置成功即计为 ONNX 支持_operator_counts注释明确[random]失败但确定性变体成功的增强算子算作支持因为想导出 ONNX 的用户会用确定性变体页面布局顶部三张统计卡片 图例Legend 按包汇总表 每包分节的算子表附带一个隐藏的 JS 搜索/筛选控件kornia-compat-controls可按任意失败、ONNX 失败、graph breaks 等筛选行页脚有一段失败是特定 torch/exporter/kornia 版本下的事实而非承诺的说明并链接到 onnx 与 gpu-acceleration 文档。八、如何新增一个 case按 README 的 Adding a case 一节在匹配的cases_*.py中用case(...)注册协议见第三节完整 docstring 在 harness.py唯一名称、用作页面分节的组名、可调用对象、张量输入、Python 侧 kwargs、页面上展示的 note同一算子的变体使用name[variant]约定如warp_perspective[fill]合并时自动归到同一行标签下_split_name会把组前缀剥离、把[a][b]折叠成 variant注册后重新跑python docs/export_support/run.py group只跑该组快且only过滤可进一步限制到单个 case再--merge-only合并最后重建文档页面。新增 case 时若目标算子含随机性记得checkFalse并给note说明若无法以张量图表达文件 I/O、枚举、stub用skip原因让页面以n/a呈现而不是误报为失败。九、小结这套机制的可迁移价值docs/export_support/的价值不止于一张支持矩阵更在于它是一套可复现、可续跑、防静默失真的兼容性回归流水线注册式覆盖新增算子只需一行case(...)自动进入三条捕获路径的探测防失真版本印章revision/torch inventory 校验 合并前完整性检查杜绝部分运行覆盖完整快照可诊断每个失败都带根因数据依赖、缺 lowering、torch 版本 bug与涉事 kornia 源码帧构建期渲染快照提交进仓库页面在文档构建时生成数据跟着库走而不是手工维护。对任何希望系统化回答我的 PyTorch 库在 ONNX / torch.export / torch.compile 下到底哪些能用的团队这套cases 注册 → 并行探测 → 校验合并 → 构建期渲染的模式都可以直接借鉴对本仓库而言它让用户在使用 ONNX 导出、部署或torch.compile加速前先对某个算子的兼容性有一个版本化的事实依据。赞分享计算机视觉人工智能深度学习图像处理【免费下载链接】kornia Geometric Computer Vision Library for Spatial AI项目地址https://gitcode.com/gh_mirrors/ko/kornia点击查看免费下载相关推荐Kornia ONNX / torch.export / torch.compile 支持页面从图捕获调研到自动生成的兼容性文档Kornia ONNX / torch.export / torch.compile 支持页面从图捕获调研到自动生成的兼容性文档 本指南围绕 Kornia 仓计算机视觉人工智能深度学习图像处理Kornia 全库算子 ONNX / torch.compile / torch.export 支持矩阵图捕获调查与支持页面生成全解析Kornia 全库算子 ONNX / torch.compile / torch.export 支持矩阵图捕获调查与支持页面生成全解析 Kornia 仓库自计算机视觉深度学习人工智能图像处理kornia 全面支持 Dynamo ONNX 导出约 140 个新增算子案例的图捕获兼容实践kornia 全面支持 Dynamo ONNX 导出约 140 个新增算子案例的图捕获兼容实践 本文基于 kornia 仓库 changelog.d/mig计算机视觉人工智能深度学习图像处理上一篇FATE联邦学习部署终极教程单机与集群完整方案指南 下一篇Apptainer 项目常见问题解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Kornia 图捕获兼容性调查：docs/export_support 背后的 ONNX、torch.compile 与 torch.export 支持页机制
计算机视觉人工智能深度学习图像处理【免费下载链接】kornia Geometric Computer Vision Library for Spatial AI项目地址https://gitcode.com/gh_mirrors/ko/kornia点击查看免费下载Kornia 文档站中的 ONNX, torch.compile and torch.export support导出支持页面并非人工维护的表格而是由docs/export_support/目录下的一套可复现的全库图捕获调查流水线自动生成的。每个 Kornia 公开算子都会被以具体 CPU float32 输入跑过 PyTorch 的三条图捕获路径ONNX 导出、torch.export、torch.compile逐条记录成功/失败及根因最后合并成一份提交到仓库的 JSON 快照在文档构建时渲染为网页。本文将讲解测量了什么、case(...)注册协议、三条探测管线各自怎么工作、如何重新生成快照、合并阶段的校验策略以及如何新增一个 case 并让它在页面上呈现。读者读完即可复现这份调查或把同样的注册-探测-合并-渲染模式迁移到自己的 PyTorch 项目上。背景链接export_support 文档、导出支持页面源、页面入口第 74 行引用该页面。一、整体架构一份提交的快照一次构建期渲染docs/source/get-started/export-support.rst是最终支持页面的源文件但它由 docs/generate_export_support.py 在文档构建时从 docs/source/_data/export_support.json 渲染生成。该 JSON 是docs/export_support/目录测量结果的提交快照文档构建期间不会执行任何探测代码nothing here runs during a docs build。流水线概览docs/export_support/cases_*.py # case 注册每个公开算子 具体输入 │ run.py并行调度 可续跑 ├── harness.py ──► results/onnx_*.json ONNX 探测 └── probe_compile.py ──► results/compile_*.json export compile 探测 │ merge.py校验 合并 ▼ docs/source/_data/export_support.json # 提交的快照 │ docs/generate_export_support.py构建期渲染 ▼ docs/source/get-started/export-support.rstharness.py 的模块 docstring 明确说一个case是一个公开 kornia 可调用对象函数或nn.Module实例加上一组具体的张量输入每个张量输入都会成为 ONNX 图的一个输入Python 侧的关键字参数则烘焙为常量写入图中。二、测量什么6 个 case 注册文件每个case是一个公开可调用对象 具体 CPU float32 输入注册在 6 个cases_*.py文件之一文件覆盖范围cases_aug.pykornia.augmentation2D、3D、容器、自动策略cases_feature.pykornia.feature检测器、描述子、匹配器cases_geomA.pykornia.geometry变换、转换、相机、标定cases_geomB.pykornia.geometry其余部分对极几何、李群、Boxes 等cases_misc.pykornia.filters、color、enhance、morphology、contrib、losses、metrics、utils、sensors、io、nerf、tracking、xcases_models.pykornia.models权重未缓存时自动下载快照头部export_support.json末尾记录了精确的测量环境例如当前快照generated_at: 2026-09-02, kornia: 0.9.0rc1, torch: 2.9.1cu128, onnx: 1.21.0, onnxruntime: 1.23.2, onnxscript: 0.5.7, opset: 18, python: 3.11.14, device: cpu, revision: e0969438run.py 中GROUPS [aug, feature, geomA, geomB, misc, models]与上述文件一一对应。从 cases_geomB.py 可以看到实测案例的典型形态例如_cc(rad2deg, C.rad2deg, [torch.rand(2, 3) * 6.0]), # geometry.conversions _ce(find_fundamental, E.find_fundamental, [pts1, pts2], note8POINT), # geometry.epipolar _cam(PinholeCamera.project, lambda intr, extr, p: PinholeCamera(...).project(p), [...]) _clg(So3.exp.matrix, lambda v: So3.exp(v).matrix(), [so3_v])同一个算子有多个代码路径时用name[variant]约定命名如find_fundamental[7POINT]、unproject_points[normalize]、RANSAC[fundamental_7pt]使它们在页面同一行下分组[random]后缀表示采样在图中进行的随机模式详见第四节。三、case 注册协议case(...)的参数case(...)定义在 harness.py签名如下def case( name: str, # 唯一显示名通常用公开可调用名如 filters.filter3d group: str, # 报告分组filters、geometry.epipolar、feature.descriptors... target: Any, # nn.Module 实例或普通可调用 fn(*inputs, **kwargs) inputs: list[torch.Tensor], # 张量每个都会成为 ONNX 图的活输入 kwargs: dict | None None, # Python 侧关键字参数烘焙为常量 *, note: str , # 页面上展示的自由文本 check: bool True, # False图内有随机性只做导出运行输出不校验 atol: float 2e-4, # 数值比较容差 rtol: float 1e-3, skip: str | None None, # 给出理由时该 case 直接标记 skipped不运行 tags: tuple[str, ...] (), # 例如 (3d, model, pretrained) method: str | None None, # 在模块上调用该方法而非 forward如 detect ) - dict[str, Any]关键语义来自 docstring 与run_case实现inputs中的每个张量都是 ONNX 图的输入非张量位置参数必须放进kwargs前提是可调用对象支持按关键字接收否则用 lambda 包裹checkFalse用于图内带随机性的算子——RNG 流在图内不同无法逐值对比探测结果记为ok-unverified程序能跑、输出形状正确且值有限skip用于不适合作为张量图的条目例如cases_geomB.py中的save_pointcloud_ply文件 I/O、quaternion_to_angle_axis已废弃别名它们会以skipped/n/a呈现method用于调用模块的非 forward 方法如RANSAC.estimate_model_from_minsample见cases_geomB.py中methodestimate_model_from_minsample的用法。注册文件的主入口统一为如cases_aug.py末尾if __name__ __main__: run_cases(CASES, sys.argv[1], onlysys.argv[2:] or None)即python cases_aug.py out.json [names...]可选地只跑部分 case按名字、组或前缀过滤见run_cases的only逻辑。四、三条探测管线对每个 case 依次执行 eager 参考运行 三条捕获路径。4.1 ONNX 探测harness.py 的 run_caseharness.py 的流程eager 参考make_wrapper把任意可调用包装成固定元数的nn.Module动态生成forward(in0, ..., inN-1)并用_flatten_outputs把 kornia 的容器类输出Boxes、Keypoints、Se3、Quaternion、Image等通过.data属性暴露张量展平成张量元组然后torch.manual_seed(SEED)SEED1234下no_grad运行得到参考输出导出torch.onnx.export(m, inputs, dynamoTrue, opset_version18)输出重定向到os.devnull以避免 dynamo 打印整张 FX 图支持KORNIA_SURVEY_OPTIMIZE0环境变量关闭导出优化校验onnx.checker.check_model(model, full_checkTrue)运行对比onnxruntime.InferenceSession(blob, providers[CPUExecutionProvider])运行图与 eager 输出做np.allcloseclose函数还处理 NaN 模式、bool 输出、形状差异默认atol2e-4, rtol1e-3记录算子类型集合op_types含子图递归与自定义 domain 标记、模型大小size_kb、墙钟时间time_s失败时记录根因错误err_str沿__cause__/__context__链取最深错误以及涉事的 kornia 源码帧_kornia_frames最多 6 帧。状态全集docstring 中列出ok | ok-unverified | eager-fail | export-fail | checker-fail | ort-load-fail | ort-run-fail | mismatch | no-tensor-output | skipped。随机算子的处理if not c[check]时直接记ok-unverified只验证输出个数与形状不逐值比较——因为图内 RNG 流与 eager 不同。cases_aug.py中Rand包装器还重写了eval()返回 self确保 harness 调.eval()后增强模块仍保持 train 模式采样留在图内。4.2 torch.export 与 torch.compile 探测probe_compile.pyprobe_compile.py 复用同一批注册文件python probe_compile.py cases_module out.json [names...]每条记录exporttorch.export.export(wrap, inputs)非严格模式默认→ok | fail | eager-fail | skipped带 420 秒SIGALRM超时保护compile先用torch._dynamo.explain(wrap)(*inputs)统计graph break 数与 break 原因再torch.compile(wrap)默认 inductor 后端fullgraphFalse运行并与 eager 对比 →ok | ok-breaks:N | ok-unverified | mismatch | fail | eager-fail | skipped额外记录目标可调用对象的可导入限定名qualname供合并阶段生成文档交叉引用torch._dynamo.config.cache_size_limit 64、suppress_errors False。两类特殊的进程级故障处理值得一提TimeoutPOSIX 上用signal.alarm超时即Timeout异常Poisoned某个 case 把 dispatcher 搞坏PythonDispatcherTLS未设置后解释器不可再用进程以退出码POISON_EXIT 3退出由 run.py 负责重启续跑。4.3 失败根因的归因merge.py 把底层错误消息映射为页面上用户可读的原因几个典型类目_CAUSES表数据依赖Could not extract specialized integer from>pixi run -e default install-docs pixi run -e default build-docs # 先构建一次文档让算子获得交叉引用 python docs/export_support/run.py # ~2 小时8 CPU 核可续跑 pixi run -e default build-docsrun.py 的调度语义run.py 为每个 case 组启动两个并行子进程ThreadPoolExecutor共len(groups)*2个 workeronnx:group跑cases_group.pycompile:group跑probe_compile.py。支持的关键参数参数作用python docs/export_support/run.py全量探测全部 6 组约 2 小时run.py aug misc只跑指定 case 组run.py --merge-only不做探测仅用既有 results 重建 JSONrun.py --force即使结果不完整也强制合并可续跑每个探测进程在results/下写onnx_group.json、compile_group.json及对应inventory_*.json每条记录落盘后重启时跳过已有记录的 case因此崩溃segfault 会留下crashed标记的 worker 直接重启即可续跑run_cases中先写 crash 标记再跑run.py中MAX_RESTARTS50循环重启被毒化的解释器。版本印章provenanceinventory_*.json记录该探测用的 kornia revisiongit rev-parse --short HEAD-dirty后缀与torch.__version__harness.provenance。prepare_resume发现记录来自不同 revision/torch 时丢弃而非续跑。merge.py 的合并校验merge.py 在写出快照前做三重校验_validate防止部分运行静默低估覆盖率每个 results 文件必须存在对应inventory_*.jsoninventory 点名的每个 case 都须有非 crash 标记的记录所有组的 inventory 必须指向同一 kornia revision 与 torch 版本。任一不满足即中止合并并打印原因--force可强制合并并在头部盖章测量于什么版本。merge.py还从最近一次文档构建的 Sphinx inventorydocs/build/html/objects.inv解析交叉引用使页面上的算子名成为可点击的文档链接无 inventory 时算子以纯文本渲染。合并输出export_support.json每条 case 的字段包括package、section、operator、variant、ref最短文档化别名、note、三列的*_detail原因文本、graph_breaks、where首个 kornia 源码帧位置。六、案例实操以 augmentation 为例理解两种模式cases_aug.py 展示了最复杂的注册形态其 docstring 明确两部分PART 1确定性组augmentation*aug(img, paramsparams)把采样出的参数张量作为 ONNX 图输入喂入Det包装器容器AugmentationSequential等与自动策略RandAugment等先 eager 调用一次导出时把seq._params固定为常量PART 2随机组*.randomaug(img)且保持 train 模式随机性留在图内checkFalse。以build()辅助函数为例它为一个变换同时注册确定性与随机两个 casebuild(Normalize, G2, lambda: KA.Normalize(mean..., std...), [IMG], directTrue) # directTrue无随机参数 - 确定性 case 就是普通 aug(*data) 调用 build(RandomRotation90, G2, lambda: KA.RandomRotation90(times(1, 3), p1.0), [IMG]) # 默认注册两个 caseRandomRotation90params 喂入 RandomRotation90[random]图内采样值得注意的细节torch.manual_seed(7)在forward_parameters前固定种子保证参数可复现非张量参数batch_prob、forward_input_shape从params中剔除NONPARAM_KEYS保持为常量build(f{_n}[p0.5], ...)用p0.5的默认概率注册 5 个代表性子集P05使逐样本 batch_prob 门控分支真正进入图这是常见的导出阻塞点见P05注释容器用seq_build先 eager 调用填充seq._params导出时SeqDet.forward以paramsparams常量调用页面上的变体分组[variant]由merge._split_name解析RandomCrop[p0.5][random]会变成 operatorRandomCrop、variantp0.5, random。七、页面如何渲染状态语义与统计口径docs/generate_export_support.py 构建期渲染状态 → 单元格STATUS表 _cellok“yes”ok-breaks“yes, N breaks”可编译且匹配 eager但有 graph breakok-unverified“yes (random)”随机算子只验形状与有限性mismatchfail“no”Details 列说明原因n/a不适用的非张量图文件 I/O、枚举、Python 容器、stub统计口径每列计数为supported / probed排除n/a行distinct operators按(package, operator)去重且任一配置成功即计为 ONNX 支持_operator_counts注释明确[random]失败但确定性变体成功的增强算子算作支持因为想导出 ONNX 的用户会用确定性变体页面布局顶部三张统计卡片 图例Legend 按包汇总表 每包分节的算子表附带一个隐藏的 JS 搜索/筛选控件kornia-compat-controls可按任意失败、ONNX 失败、graph breaks 等筛选行页脚有一段失败是特定 torch/exporter/kornia 版本下的事实而非承诺的说明并链接到 onnx 与 gpu-acceleration 文档。八、如何新增一个 case按 README 的 Adding a case 一节在匹配的cases_*.py中用case(...)注册协议见第三节完整 docstring 在 harness.py唯一名称、用作页面分节的组名、可调用对象、张量输入、Python 侧 kwargs、页面上展示的 note同一算子的变体使用name[variant]约定如warp_perspective[fill]合并时自动归到同一行标签下_split_name会把组前缀剥离、把[a][b]折叠成 variant注册后重新跑python docs/export_support/run.py group只跑该组快且only过滤可进一步限制到单个 case再--merge-only合并最后重建文档页面。新增 case 时若目标算子含随机性记得checkFalse并给note说明若无法以张量图表达文件 I/O、枚举、stub用skip原因让页面以n/a呈现而不是误报为失败。九、小结这套机制的可迁移价值docs/export_support/的价值不止于一张支持矩阵更在于它是一套可复现、可续跑、防静默失真的兼容性回归流水线注册式覆盖新增算子只需一行case(...)自动进入三条捕获路径的探测防失真版本印章revision/torch inventory 校验 合并前完整性检查杜绝部分运行覆盖完整快照可诊断每个失败都带根因数据依赖、缺 lowering、torch 版本 bug与涉事 kornia 源码帧构建期渲染快照提交进仓库页面在文档构建时生成数据跟着库走而不是手工维护。对任何希望系统化回答我的 PyTorch 库在 ONNX / torch.export / torch.compile 下到底哪些能用的团队这套cases 注册 → 并行探测 → 校验合并 → 构建期渲染的模式都可以直接借鉴对本仓库而言它让用户在使用 ONNX 导出、部署或torch.compile加速前先对某个算子的兼容性有一个版本化的事实依据。赞分享计算机视觉人工智能深度学习图像处理【免费下载链接】kornia Geometric Computer Vision Library for Spatial AI项目地址https://gitcode.com/gh_mirrors/ko/kornia点击查看免费下载相关推荐Kornia ONNX / torch.export / torch.compile 支持页面从图捕获调研到自动生成的兼容性文档Kornia ONNX / torch.export / torch.compile 支持页面从图捕获调研到自动生成的兼容性文档 本指南围绕 Kornia 仓计算机视觉人工智能深度学习图像处理Kornia 全库算子 ONNX / torch.compile / torch.export 支持矩阵图捕获调查与支持页面生成全解析Kornia 全库算子 ONNX / torch.compile / torch.export 支持矩阵图捕获调查与支持页面生成全解析 Kornia 仓库自计算机视觉深度学习人工智能图像处理kornia 全面支持 Dynamo ONNX 导出约 140 个新增算子案例的图捕获兼容实践kornia 全面支持 Dynamo ONNX 导出约 140 个新增算子案例的图捕获兼容实践 本文基于 kornia 仓库 changelog.d/mig计算机视觉人工智能深度学习图像处理上一篇FATE联邦学习部署终极教程单机与集群完整方案指南 下一篇Apptainer 项目常见问题解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考