美术数据库图像智能处理系统阶段性工作报告与专业化升级方案
- 2026-10-07 21:58:02
美术数据库图像智能处理系统
阶段性工作报告与专业化升级方案
项目名称： 美术数据库图像智能处理系统当前设备： NVIDIA DGX Spark / NVIDIA GB10当前数据目录：/images当前工作目录：/workspace当前数据规模： 56,755 个图片文件当前阶段： 原始素材盘点 → 完整性检测 → SigLIP2 分类测试 → 软件架构升级
一、项目背景
本项目的目标不是简单地“把图片分类”，而是建立一个可以长期运行、不断扩充的美术数据库图像基础设施。
目前已有约 5.7 万张图片素材，未来数据规模可能继续扩大到：
- 10 万张
- 20 万张
- 50 万张
- 100 万张以上
因此，不能继续采用一次性脚本、临时修改代码、手工 sed 替换代码的方式。
项目需要从目前的实验脚本，逐步升级为：
模块化、插件化、可恢复、可追踪、可扩展的专业图像数据处理系统。
最终服务于中国美术数据库、全球艺术数据库以及后续 AI 艺术模型建设。
二、目前硬盘素材情况
目前已经完成第一轮硬盘扫描。
1. 图片总量
素材总量：56,755这是真实扫描 /images 得到的结果。
2. 文件格式统计
目前发现：
格式 | 数量 |
|---|---|
HEIC | 12,820 |
heic | 11,373 |
JPEG | 14 |
jpeg | 31,686 |
JPG | 507 |
PNG | 318 |
png | 37 |
总计 | 56,755 |
注意：
这里大小写不同并不代表不同格式。
例如：
HEICheic实际上都是 HEIC。
因此真正应该统计为：
HEIC / HEIF：24,193JPEG / JPG：32,207PNG：355合计：
24,193 + 32,207 + 355= 56,755这说明目前扫描出来的素材全部落在我们关注的图片格式范围内。
三、素材初步健康状况
目前检查发现：
0 字节文件：1也就是说，只有一个文件的文件大小为 0。
这是一个非常好的初步信号。
但是：
文件存在 ≠ 图片一定有效。
例如：
xxx.heic文件虽然存在，也可能：
- 文件头损坏
- HEIC 编码无法解码
- Photos Library 导出的文件不完整
- 图片内部数据损坏
- 扩展名与真实格式不一致
因此目前还不能直接宣布：
“56,755 张全部有效。”
必须继续进行真正的图像解码验证。
四、目前发现的一个重要问题：HEIC
前面的 SigLIP2 测试过程中出现了大量：
cannot identify image file其中相当一部分来自：
.heic以及 Apple Photos Library 中的文件。
这并不能直接说明这些照片损坏。
原因是：
Pillow 默认并不完整支持 HEIC。
因此我们已经安装：
pillow-heif并进行了：
from pillow_heif import register_heif_openerregister_heif_opener()这一步是正确方向。
五、目前 SigLIP2 测试的结果
目前已经成功让：
SigLIP2google/siglip2-so400m-patch14-384在：
NVIDIA GB10上完成 GPU 推理。
测试程序可以：
- 扫描图片
- 读取图片
- HEIC 解码
- RGB 转换
- 批量送入 GPU
- SigLIP2 推理
- 输出三个分类分数
- 保存 CSV
- 统计分类结果
这说明：
DGX Spark 的 GPU 环境、PyTorch、Transformers、SigLIP2 基本已经打通。
这是目前项目一个非常重要的阶段性成果。
六、1000张测试的意义
之前进行了 1000 张级别的测试。
测试过程中出现过：
成功：340失败：660后来通过：
- 排除 macOS
._文件 - 安装
pillow-heif - 修改读取逻辑
成功读取数量提高。
最终测试已经能够得到类似：
GPU完成：1000/1000并产生：
/output/test_siglip2_1000.csv这说明问题的主要来源之一确实是：
图片读取/格式兼容，而不是 GPU 推理本身。
七、目前分类结果的参考价值
后面的测试中得到了一批实际分类结果。
例如出现：
艺术品生活/摄影其他待复核这证明 SigLIP2 可以作为第一层图像筛选器。
但是必须特别强调：
目前结果只能作为工程测试结果，不能作为最终艺术数据库分类结果。
原因有三个。
1. SigLIP2 本身不是为数据库分类标签训练的
目前使用的是通用视觉语言模型。
我们人为定义：
艺术品生活/摄影其他实际上是在做：
Zero-shot classification
而不是一个专门训练过的“中国美术数据库分类器”。
八、目前代码中存在的核心问题
这是这次工作中最值得总结的地方。
之前代码出现过：
IndentationErrorSyntaxErrorsed 替换失败bash syntax error这些问题并不是 DGX Spark 的问题。
主要是因为：
代码修改方式不够专业。
例如通过：
sed -i不断修改 Python 文件的某几行。
这种方式在临时实验中可以，但对于现在这个项目已经不合适。
九、今后必须改变开发方式
以后不再采用：
看屏幕↓发现错误↓sed 修改一行↓重新运行↓出现另一个错误↓继续 sed而采用专业软件工程流程：
设计↓完整编写模块↓Python语法检查↓单元测试↓小样本测试↓1000张测试↓结果验证↓正式运行十、建议建立正式的软件架构
最终建议把现在的：
/workspace/test_siglip2.py升级为完整项目：
/workspace/art_database/│├── app/│ ├── scanner.py│ ├── validator.py│ ├── metadata.py│ ├── hashing.py│ ├── deduplicate.py│ ├── classifier.py│ ├── embedding.py│ ├── clustering.py│ ├── review.py│ └── exporter.py│├── plugins/│ ├── heic.py│ ├── jpeg.py│ ├── png.py│ ├── siglip2.py│ ├── clip.py│ ├── ocr.py│ └── metadata.py│├── config/│ └── config.yaml│├── database/│ └── artwork.db│├── logs/│├── reports/│├── results/│├── tests/│└── main.py十一、为什么采用插件架构
这是未来非常重要的一步。
例如现在：
SigLIP2以后可能增加：
Qwen-VLFlorenceCLIPOCR人脸识别艺术家识别印章识别题跋识别风格分析作品相似度图像质量检测如果全部写在一个 Python 文件里面，最终会变成几千甚至上万行的“巨型脚本”。
而插件结构可以变成：
图像 ↓基础读取插件 ↓完整性插件 ↓Hash插件 ↓SigLIP2插件 ↓OCR插件 ↓视觉Embedding插件 ↓相似度插件 ↓数据库以后增加一个模型，只需要增加一个插件。
十二、建议建立统一配置文件
以后不要把大量参数硬编码在 Python 里面。
例如：
data: input: /images output: /outputmodel: name: google/siglip2-so400m-patch14-384 device: cudaclassification: confidence_threshold: 0.55 margin_threshold: 0.10processing: batch_size: 128formats: - jpg - jpeg - png - heic - heif这样以后修改：
模型Batch Size阈值输入目录输出目录都不需要改 Python 主程序。
十三、必须建立“断点续跑”
对于 56,755 张图片，这一点非常重要。
如果运行到：
43,000 / 56,755突然：
- Spark 重启
- 电源中断
- GPU 出错
- 程序退出
不能从头开始。
应该自动记录：
已经处理：43,000未处理：13,755重新启动以后：
从 43,001 开始这叫：
Checkpoint / Resume
未来做到几十万甚至百万张时，这是必需功能。
十四、必须建立文件唯一身份
每张图片不能只依赖：
文件名因为素材中已经存在：
IMG_6897.PNGIMG_9115_1.HEIC以及大量 UUID 文件名。
建议给每个文件建立：
file_idsha256phash例如：
file_id:ARTIMG-000000001SHA256:xxxxxxxxxxxxxxxxpHash:xxxxxxxx这样可以判断：
完全相同
SHA256相同内容相同但尺寸不同
pHash高度相似同一作品不同照片
视觉Embedding高度相似这将成为以后数据库查重的基础。
十五、数据库最终应该保存什么
未来每张图片至少应该有：
ID文件路径原始文件名文件格式文件大小宽度高度色彩空间EXIF创建时间SHA256MD5pHashSigLIP艺术品分数SigLIP摄影分数SigLIP其他分数最终分类分类置信度分类Margin视觉Embedding相似作品组人工审核状态如果以后加入艺术数据库信息，还可以增加：
艺术家作品名称创作年代作品类型媒介尺寸来源收藏机构版权授权状态出版状态这样才真正成为：
美术数据库的底层数据结构。
十六、分类系统应该从“三分类”逐渐升级
目前：
艺术品生活/摄影其他只是第一层过滤。
以后建议：
第一层
艺术品非艺术品不确定第二层
艺术品：
中国画油画版画雕塑书法摄影艺术水彩综合材料数字艺术古代艺术现代艺术当代艺术第三层
例如中国画：
山水人物花鸟动物工笔写意第四层
继续做：
艺术家作品年代风格题材这样会越来越接近真正的AI美术数据库。
十七、人工复核不是失败，而是系统设计的一部分
目前我们设置：
confidence < 0.55或者：
margin < 0.10进入：
待复核这是正确方向。
未来不应该强迫 AI 对所有图片做决定。
应该形成：
AI高置信度 ↓自动入库AI低置信度 ↓人工复核人工结果 ↓反过来训练模型最终形成：
AI → 人工 → 数据 → 模型 → AI
的闭环。
十八、关于目前 SigLIP2 的 Softmax
这里还有一个技术问题需要记录。
SigLIP 原始模型更适合使用：
sigmoid(logits)而不是传统多分类：
softmax(logits)但是我们后来为了：
艺术品 / 生活摄影 / 其他三选一，把三个 logits 做了：
softmax得到相对概率。
这对于排序和三分类实验有参考价值。
但这些数值不能直接解释为：
“艺术品概率 97.4%”
因为这不是经过你的数据集校准后的概率。
未来应该做：
Calibration（概率校准）
甚至建立你自己的：
艺术数据库分类模型十九、当前测试结果应该如何理解
目前已经出现例如：
艺术品：33其他：12待复核：9生活/摄影：6这类结果。
它说明：
SigLIP2 已经能够对部分图片产生明显的语义区分。
但目前样本量太小，而且没有人工标注的 Ground Truth。
因此暂时不能计算：
准确率PrecisionRecallF1下一步应该人工标注一批，例如：
1000张形成：
人工真实标签+AI预测标签然后计算真正的模型表现。
二十、正式项目的测试体系
建议建立：
Level 1：文件测试
56,755检查：
- 文件存在
- 文件大小
- 图片头
- 解码
- HEIC
- JPEG
- PNG
Level 2：元数据测试
检查：
宽度高度EXIF方向颜色Level 3：Hash测试
检查：
完全重复Level 4：感知Hash
检查：
视觉近似Level 5：SigLIP2
检查：
艺术品生活摄影其他Level 6：Embedding
建立：
视觉向量Level 7：聚类
自动发现：
同一作品同一艺术家相似作品重复拍摄Level 8：人工审核
处理：
AI无法确定的图片二十一、第一阶段的正式目标
目前最合理的第一阶段目标不是立即跑完 56,755 张。
而是先建立：
“56,755 张素材健康档案”。
最终生成：
image_inventory.csvimage_validation.csvimage_metadata.csvduplicate_groups.csv例如：
总文件：56,755有效：56,xxx损坏：xxxHEIC有效：xx,xxxJPEG有效：xx,xxxPNG有效：xxx完全重复：xxx疑似重复：xxx唯一图片：xxx二十二、第二阶段
素材确认以后：
56,755↓去重↓可能剩余 40,000～50,000具体数量必须实际计算，不能提前假定。
然后：
SigLIP2↓艺术品生活/摄影其他待复核二十三、第三阶段
对“艺术品”继续分析：
艺术品↓中国画油画版画雕塑书法摄影其他再继续：
山水人物花鸟抽象肖像静物历史题材宗教题材二十四、第四阶段：建立视觉检索
这一步会真正产生很高的数据库价值。
例如以后输入一张画：
上传图片↓Embedding↓数据库搜索↓找到最相似的100件作品甚至可以：
找相似作品找同一作品不同照片找疑似重复图片找同一艺术家作品找相似风格这比单纯“图片分类”价值高得多。
二十五、第五阶段：建立 AI 美术数据库
最终架构可以发展成：
美术数据库 │ ┌────────────────┼────────────────┐ ↓ ↓ ↓ 图片资产 文献资料 艺术家资料 │ │ │ ↓ ↓ ↓ 图像AI OCR/RAG 知识图谱 │ │ │ └────────────────┼────────────────┘ ↓ 艺术知识系统 ↓ AI艺术检索/鉴定/研究这是现在这个项目真正值得建设的方向。
二十六、关于“插件”的最终规划
建议把插件系统设计成：
Input Plugin ↓Validation Plugin ↓Metadata Plugin ↓Hash Plugin ↓Dedup Plugin ↓Classification Plugin ↓Embedding Plugin ↓OCR Plugin ↓Artist Plugin ↓Similarity Plugin ↓Export Plugin每一个插件都可以独立开启或关闭。
例如：
python main.py --plugin validation或者：
python main.py --plugin siglip2或者：
python main.py --pipeline full以后就不需要再修改核心程序。
二十七、软件质量控制
从现在开始，每次修改程序必须自动执行：
① Python语法检查② import检查③ 配置检查④ GPU检查⑤ 模型检查⑥ 10张测试⑦ 100张测试⑧ 1000张测试⑨ 输出CSV检查⑩ 日志检查任何一级失败：
停止，不进入下一阶段。
这样可以大幅降低我们之前遇到的：
IndentationErrorSyntaxErrorsed替换错误逻辑覆盖二十八、当前项目的总体判断
经过目前这几轮测试，我的判断是：
硬件
没有问题。
NVIDIA GB10 已经成功完成 SigLIP2 GPU 推理。
硬盘
没有明显容量问题。
3.7 TB 总容量，目前仅约 158 GB 已使用。
素材
规模明确，结构相对干净。
56,755 个图片文件。
HEIC
需要正式验证。
不能再简单把 cannot identify image file 等同于损坏。
SigLIP2
已经跑通，可以作为第一层筛选模型。
但目前还不是最终分类模型。
软件
这是目前最需要升级的部分。
应该从实验脚本升级为正式的软件工程架构。
二十九、下一步工作顺序
我建议我们从现在开始严格按照这个顺序：
【阶段 1】56,755 张素材扫描 ↓【阶段 2】HEIC/JPEG/PNG 完整性验证 ↓【阶段 3】元数据提取 ↓【阶段 4】SHA256 + pHash ↓【阶段 5】重复图片分析 ↓【阶段 6】建立 SQLite 数据库 ↓【阶段 7】SigLIP2 第一层分类 ↓【阶段 8】人工抽样验证 ↓【阶段 9】优化分类阈值 ↓【阶段 10】Embedding ↓【阶段 11】相似作品搜索 ↓【阶段 12】艺术品细分类 ↓【阶段 13】AI + 人工审核 ↓【阶段 14】形成正式美术数据库三十、结论
这次工作最重要的成果，并不是某一次 SigLIP2 测试得到多少张“艺术品”。
真正重要的是，我们已经把问题看清楚了：
硬盘里确实存在一个规模达到 56,755 张的真实图片资产库，而且目前存储空间、GPU 和基础模型环境都已经具备。
现在最需要做的是把之前的“实验性代码”升级成：
专业、模块化、插件化、可恢复、可追踪的美术数据库图像处理系统。
以后不再追求“临时把一个错误修过去”，而是每一步都留下：
程序 + 配置 + 日志 + 数据库 + 报告 + 可重复运行的结果。
这样这个项目才真正有可能从现在的 5.7 万张素材，稳定发展到未来的几十万乃至百万级艺术图像数据库。
下一步就按这份报告执行：先完成 56,755 张图片的完整性验证，再开始正式的软件架构。不要再继续修改现在这个 test_siglip2.py。
