截至 2026 年 9 月 5 日，QuPath 官网仍将 v0.7.0 列为当前稳定版本，同时提供 macOS Intel 与 Apple Silicon 安装包，并把 Apple Silicon 包标为 beta。(QuPath 官网)

本周建议动作：如果你使用 Apple Silicon，先下载 arm64 版做代表性切片测试；一旦课题依赖 JPEG-XR 压缩 CZI、部分 NDPI，或某条 Bio-Formats 读取链路失败，就保留通过 Rosetta 运行的 Intel 版。格式来源复杂、多人协作或需要长期复现的课题组，直接采用 arm64 与 Intel 双版本隔离，通常比反复迁移项目更稳。

病理学与生物医学研究生，可以用这篇指南判断低成本 macOS 环境该下载哪个版本。
课题组图像分析人员，可据此检查多种显微文件格式、扩展和脚本是否能迁移。
实验室技术支持人员，则可以把下面的指标清单用于远程 Mac 环境交付和验收。

最后更新于 2026 年 9 月 5 日，版本状态核实自 QuPath 官网、v0.7.0 稳定版文档、安装文档与官方发布资料。

01

先给结论：芯片只决定起点，切片格式决定最终版本

Apple Silicon Mac 应优先从 arm64 版开始，但不能把“原生运行”直接等同于“最适合科研工作流”。QuPath 官方安装文档明确说明，Apple Silicon 版运行速度更快，但 Bio-Formats 在 Apple Silicon 上仍存在文件格式支持边界；Intel 版可以在 Apple Silicon Mac 上通过 Rosetta 运行。(QuPath 稳定版安装文档)

你可以先按下面的路线判断：

  • ✅ 全部代表性切片、插件和脚本都通过：使用 arm64 版。
  • ⚠️ 只有 Intel 版能打开关键格式：保留 Intel 版，不要强行转换全部数据。
  • ✅ 格式复杂、项目多人协作或需要复现实验：arm64 与 Intel 双版本隔离安装。
  • ❌ 只用普通 TIFF 测试后就下结论：不合格。TIFF 的金字塔结构、压缩方式和元数据差异，可能导致真实项目表现完全不同。

对于 Apple Silicon 设备，最稳妥的下载顺序是“先 arm64、再按失败项补 Intel”。如果你的数据主要是标准 OME-TIFF、普通 TIFF，且不依赖 Intel 专属扩展，arm64 是合理的首选。如果课题使用 Zeiss CZI、Hamamatsu NDPI、荧光多通道数据，或者已有项目通过 Bio-Formats 读取，则应同时测试 Intel 版。

下载后不要只看安装包名称。打开 Finder，选中 QuPath 应用并查看“显示简介”，确认应用类型；也可以在应用文件名中区分 aarch64 与 x64。否则你可能把 Intel 版的测试结果误认为 arm64 版，导致错误的性能和兼容性判断。QuPath 官方文档明确说明，两种版本可以并存，应用名称会包含对应架构标识。(QuPath 架构安装说明)

02

第一项指标：切片格式是否通过完整读取链路

全切片图像的兼容性不能只回答“能不能打开”。你至少要验证 4 个动作：

  1. 首次打开是否成功。
  2. 金字塔层级缩放是否连续。
  3. 通道、颜色和位深显示是否正确。
  4. 扫描仪、像素尺寸、层级和通道元数据是否完整。

QuPath 0.7 使用 OpenSlide 与 Bio-Formats 处理不同类型的图像。OpenSlide 通常更轻量，适合部分二维、8-bit、RGB 图像；Bio-Formats 能覆盖更多多维、时间序列和多通道数据，但不同格式变体仍可能存在差异。(QuPath 图像格式说明)

遇到部分 CZI 文件无法打开时，先检查压缩方式，而不是立即重装软件。
关键不在文件扩展名本身，而在 CZI 内部使用的压缩链路。QuPath 官方文档指出，采用 JPEG-XR 压缩的 CZI，Bio-Formats 在 Apple Silicon 上暂不支持；这类文件可能需要改用 Intel 版，或先在其他环境转换。

NDPI 也要分情况处理。Apple Silicon 版的 Bio-Formats 可能无法读取大部分 .ndpi 或 .ndpis 文件，但 OpenSlide 对部分二维明场 NDPI 提供替代读取路径。因此，“NDPI 支持”不能被简化成“全部能读”或“全部不能读”。

建议你建立一份代表性切片清单，至少包含：

  • 课题组最常见的扫描仪来源。
  • 每种真实扩展名，而不是人工改名后的副本。
  • 不同压缩方式的 CZI 或 TIFF。
  • 明场、荧光、多通道和需要读取元数据的样本。
  • 过去项目中曾经出现过读取异常的文件。

⚠️ 注意：格式出现在 Bio-Formats 或 OpenSlide 的支持列表中，并不保证每一个实际文件都能正常打开。科研验收应以你的原始文件副本为准，而不是以格式名称为准。

03

第二项指标：不要把启动速度当成科研性能

arm64 版在 Apple Silicon 上是原生架构，官方安装文档将其描述为比 Intel 版运行更快；但科研用户真正关心的通常不是双击后几秒出现窗口，而是连续缩放、区域标注、检测预览、项目切换和长时间运行是否稳定。

在 Apple Silicon Mac 上启动 Intel 版时，macOS 需要借助 Rosetta 转换运行。通常首次打开 Intel 应用时，系统会提示安装 Rosetta；安装过程需要联网，并可能要求输入 macOS 用户密码。(Apple Rosetta 官方说明)

你不应使用不同设备、不同文件或不同网络条件来比较两种架构。远程环境尤其容易把画面延迟误判成 QuPath 计算变慢。更可靠的做法是固定测试条件：

  • 同一台远程 Mac。
  • 同一份脱敏切片副本。
  • 同一显示分辨率和远程协议。
  • 同一操作顺序。
  • 同一项目目录与缓存策略。

建议记录以下指标，但不要预先设定一个没有来源的“性能倍数”：

  • 首次打开是否出现错误。
  • 从低倍到高倍连续缩放是否出现空白或长时间卡顿。
  • 连续拖动画布时，画面是否能保持可操作。
  • 运行一次检测预览后，界面是否仍能响应。
  • 在两个项目之间切换后，图层和显示设置是否正常。

QuPath 是面向金字塔图像设计的，金字塔允许程序按所需分辨率读取数据，而不是一次性加载整张全切片图像。磁盘吞吐、远程画面传输、项目目录权限和图像读取后端，都会影响你的实际体验。单独比较应用启动时间，参考价值有限。

04

第三项指标：扩展、模型和脚本能否真正迁移

QuPath 的版本选择不能只看主程序。科研项目经常依赖扩展、Groovy 脚本、模型文件、项目模板和外部命令。只要其中一项在 arm64 版中失效，单版本方案就可能无法交付。

QuPath 0.7 提供命令行脚本入口，可以对图像或项目运行 Groovy 脚本，并通过参数传入输入文件、项目路径和其他变量。(QuPath 命令行文档) 这对批处理很有帮助，但也让架构验证不能停留在“扩展列表里看得到”。

你应为每个课题建立一个最小迁移样本：

  1. 复制一个旧项目，不直接在原项目上测试。
  2. 保存一份只读的代表性切片。
  3. 安装课题组实际使用的 QuPath 扩展。
  4. 打开项目并检查图像服务器、图层和对象。
  5. 运行一段最小 Groovy 脚本。
  6. 导出对象、测量列或分类结果。
  7. 对比 arm64 与 Intel 版的输出结构。

扩展在两个架构中都能加载，并不代表分析结果一定一致。
加载成功只说明程序找到了扩展，不代表模型引擎、外部库、脚本路径和输出字段完全一致。尤其是深度学习扩展，要单独检查模型格式和后端支持。

QuPath 文档说明，DJL 默认包含 PyTorch 引擎，但 TensorFlow 引擎在 Apple Silicon 上存在限制；即使使用 Intel 版，近期 Mac 上的 TensorFlow 也不一定可用。(QuPath DJL 与深度学习文档) 如果你的项目涉及模型推理，应把“模型加载、单张图像推理、批量推理、结果导出”列为独立验收项，而不是把它归入普通插件测试。

对于使用 PyTorch 的任务，QuPath 文档还提到部分场景可以使用 MPS，但不同模型和扩展的表现仍需以实际任务验证。(QuPath GPU 支持说明) 因此，不能因为设备是 Apple Silicon，就默认所有分析都能自动获得相同的硬件加速。

05

远程 Mac 场景：把网络问题和 QuPath 问题分开

没有本地 Mac 的研究生，常见做法是通过远程桌面访问托管在数据中心的 macOS 主机。此时你要把问题拆成两层：

  • 主机端：切片读取、QuPath 运算、脚本、项目保存和导出。
  • 操作端：VNC 或网页画面、鼠标拖动、键盘输入和断线重连。

如果画面拖动不流畅，先不要认定 Intel 版或 arm64 版性能较差。你应在主机端检查 CPU、内存、磁盘读写和 QuPath 日志，再单独记录远程画面的延迟。

远程环境的全切片验收，应按“传入、读取、分析、导出、恢复”这条链路执行。
使用一组已经脱敏的样例文件，按“上传或挂载—打开—缩放—标注—检测—保存—导出—取回”的顺序执行。每一步都记录是否成功、是否需要重复操作、输出文件是否完整，以及断线后能否恢复到可控状态。

远程验收至少包含以下步骤：

  1. 在本地准备脱敏切片、QuPath 项目副本和脚本文件。
  2. 通过安全方式传入远程 Mac，确认项目目录拥有读写权限。
  3. 分别启动 arm64 与 Intel 版，记录应用架构和版本。
  4. 打开相同切片，完成低倍浏览、连续缩放和局部标注。
  5. 运行最小检测或脚本任务，保存项目副本。
  6. 导出测量表、对象文件或分析结果，检查文件是否可取回。
  7. 主动断开远程连接，再重连并确认项目状态没有损坏。

受限病理数据不能因为“科研用途”就自动获得合规放行。你仍需核对学校或课题组审批、数据脱敏、账号权限、访问日志、保存周期和本地取回策略。本文只提供技术验收框架，不替代学校的数据管理制度，也不把 QuPath 用途等同于临床诊断许可。

如果你还没有 Mac，可先阅读这份远程 Mac 处理全切片图像的配置估算，再决定是短期验证还是建立长期环境。对于学生项目，先用小规模脱敏样本验证架构，通常比直接购买设备更容易控制预算和返工风险。

06

一张表判断：arm64、Intel，还是双版本

验收结果 推荐方案 适合的科研场景 主要代价
所有核心格式、扩展、脚本和导出均通过 arm64 以标准 TIFF、OME-TIFF 或已验证格式为主 仍需记录 QuPath 版本与项目环境
关键 CZI 或 NDPI 只能在 Intel 版读取 Intel 依赖 Bio-Formats 特定链路的课题 需要 Rosetta，并承担后续兼容性维护
不同项目依赖不同格式或插件 双版本隔离 多扫描仪、多课题组、多人协作 需要明确项目与版本对应关系
还没有代表性样本，只有普通 TIFF 暂不定案 新课题、远程试用阶段 先准备验收样本，再做长期决策

两个架构版本可以在同一台 Apple Silicon Mac 上并存。
官方安装文档说明，Apple Silicon Mac 可以同时安装 Intel 与 Apple Silicon 版本，并通过应用名称中的 x64 与 aarch64 标识区分。

双版本安装时，不要让两个版本共享同一个正在修改的项目目录。建议采用以下隔离方式：

  • 项目名称-arm64：只由 arm64 版打开。
  • 项目名称-intel：只由 Intel 版打开。
  • 原始切片目录保持只读。
  • 每次迁移前复制项目。
  • 在结果文件名中记录版本和架构。

这样做的重点不是让两个版本永久并行，而是避免一次打开、保存或升级后，另一个版本无法准确复现结果。

07

本周执行的 QuPath 双版本验收清单

下面的清单适合个人研究生、课题组分析人员和实验室技术支持人员共同使用。不要勾选“看起来应该可以”，只勾选已经完成并留有记录的项目。

  • [ ] 从官网确认 QuPath v0.7.0 仍是稳定版本，并确认 Apple Silicon 包的 beta 状态。
  • [ ] 下载 macOS arm64 与 Intel 两个安装包。
  • [ ] 在 Apple Silicon Mac 上安装 Rosetta，并确认 Intel 版可以启动。
  • [ ] 记录两个应用的实际架构、版本号和应用路径。
  • [ ] 列出课题组真实使用的 CZI、NDPI、NDPI-S、TIFF、OME-TIFF 或其他格式。
  • [ ] 为每种格式准备至少一份脱敏代表性文件。
  • [ ] 在 arm64 版中完成打开、缩放、通道显示和元数据读取。
  • [ ] 在 Intel 版中重复完全相同的读取测试。
  • [ ] 特别检查 JPEG-XR 压缩 CZI 和需要 Bio-Formats 的文件。
  • [ ] 复制旧项目，分别用两个版本打开，不覆盖原项目。
  • [ ] 在两个版本中加载常用扩展和模型文件。
  • [ ] 运行最小 Groovy 脚本，并比较对象数量、测量列和导出文件。
  • [ ] 在远程 Mac 上完成一次断线、重连和结果取回测试。
  • [ ] 将通过标准、失败文件和停止条件写入课题组记录。
  • [ ] 只有在核心格式与工具链全部通过后，才把 arm64 设为长期默认版本。

QuPath v0.7.0 的版本状态还可以通过官方发布页复核。发布页用于确认稳定版本，安装文档用于确认架构与 Rosetta，格式文档用于确认读取边界，命令行和深度学习文档则用于确认批处理及模型后端限制。

08

你现在该怎么选

如果你只有标准化的 OME-TIFF 或已经验证过的明场切片，arm64 可以作为默认版本。
如果关键 CZI、NDPI 或多通道文件依赖 Intel 版才能稳定读取，就保留 Intel 版，不要为了“原生架构”牺牲数据链路。
如果你面对多种扫描仪、多套脚本和多人协作，双版本隔离更适合长期复现。

实验室现有的 Windows 或 Linux 方案，常见缺点是没有原生 macOS 环境、无法直接验证 Apple Silicon 行为，或者需要额外处理远程桌面、文件传输和权限配置。云端通用主机则可能缺少真实 Mac 的图形交互与系统组件。对 QuPath 这类既要看全切片、又要运行脚本和检查项目状态的任务，短周期租用真实 Mac 往往比盲目迁移数据或直接购买设备更容易先验证结论。

如果你需要的是临时课题环境、论文复现节点或架构兼容性测试，可以先了解 VpsMesh 的 Mac 远程租赁方案，用同一组脱敏切片同时测试 QuPath 0.7 arm64 与 Intel 版。等真实工作流通过后，再决定长期租用、部署实验室设备，还是继续保留双版本。