57 lines
2.2 KiB
Markdown
57 lines
2.2 KiB
Markdown
# 需求分析-2026-05-20-02-32-47
|
||
|
||
## 开始时间
|
||
|
||
2026-05-20-02-32-47
|
||
|
||
## 原始需求摘要
|
||
|
||
用户要求优化“导出全部 NII.GZ”：
|
||
|
||
- 选择导出全部时，改为压缩包形式一次导出。
|
||
- 如果选择分割影像，需要同时导出不同类别 ID 与名称/类别名对应的 JSON 文件。
|
||
- 分割影像导出范围可选择“所有类别”或“可见类别”。
|
||
|
||
## 业务目标
|
||
|
||
- 避免多文件连续触发下载，形成一个可归档、可转移的导出包。
|
||
- 让分割影像与类别语义元数据成对导出，便于 ITK-SNAP 查看后再对照系统内 STL 构件层级。
|
||
- 保留“只导出当前可见构件”的轻量检查场景，同时支持“导出全部构件”的完整交付场景。
|
||
|
||
## 输入与输出
|
||
|
||
- 输入：
|
||
- 导出内容选择：DICOM 原始影像、分割影像、位姿数据。
|
||
- 分割类别范围：所有类别或可见类别。
|
||
- 当前模型位姿。
|
||
- 输出：
|
||
- 一个 `.tar.gz` 导出包。
|
||
- 包内按选择包含 DICOM NIfTI、分割 NIfTI、位姿 JSON。
|
||
- 若包含分割影像，同时包含类别映射 JSON。
|
||
|
||
## 影响范围
|
||
|
||
- `WebSite/server.ts`
|
||
- `WebSite/src/lib/api.ts`
|
||
- `WebSite/src/components/ReverseWorkspace.tsx`
|
||
- 本次工程分析文档和经验记录。
|
||
|
||
## 关键约束
|
||
|
||
- NIfTI 导出仍必须使用真实 DICOM 维度、spacing 和当前模型位姿。
|
||
- 分割类别范围不能影响 DICOM 原始影像和位姿数据导出。
|
||
- 类别 JSON 必须与实际导出的分割标签值一致。
|
||
- 前端仍使用后端直链下载，避免重新引入 blob URL。
|
||
|
||
## 风险点
|
||
|
||
- DICOM NIfTI 和分割 NIfTI 都可能较大，包生成会有一定耗时。
|
||
- 当前项目已有 tar.gz 归档工具，若强行实现 zip 可能引入额外复杂度；本轮默认使用 `.tar.gz` 压缩包。
|
||
- “可见类别”需要读取项目持久化的 `moduleStyles.visible`，不能只看前端临时状态。
|
||
|
||
## 默认假设
|
||
|
||
- “压缩包形式”按项目现有归档方式实现为 `.tar.gz`。
|
||
- 顶部“导出全部 NII.GZ”使用压缩包；右侧单独 NII/NII.GZ 导出按钮继续导出单个分割 NIfTI。
|
||
- 分割类别范围默认为“可见类别”，符合当前右侧映射视图的显示语义。
|