Labelme JSON转VOC XML：生产级转换器设计与工程落地

1. 项目概述：为什么非得把Labelme的json转成VOC XML？

做图像目标检测的朋友，十有八九都踩过这个坑：在标注阶段图省事用了Labelme——界面清爽、支持多边形、拖拽顺滑，导出个json文件咔咔快；可一到模型训练环节，打开YOLOv5、Faster R-CNN或者老派但稳如泰山的SSD代码库，发现人家只认Annotations/目录下那一堆.xml文件，还必须是PASCAL VOC 2007那种带<folder>、<filename>、<size>、<object>嵌套结构的格式。这时候再回头重标一遍？时间成本翻倍，标注员心态崩塌。更现实的问题是：团队里有人用Labelme，有人用CVAT，还有人手写XML，数据格式不统一，协作链路直接卡死。

我最早在某高校实验室带一个视觉识别小项目时就遇到这问题。当时三个人分工标注，A同学习惯Labelme画多边形框（比如标注叶片病斑边缘），B同学用在线平台导出的是COCO JSON，C同学为了兼容旧模型硬生生手敲XML——结果合并数据集时，路径拼错、宽高颠倒、类别名大小写不一致，训练前的数据校验脚本跑了七遍才过。后来我们干脆停掉所有标注，花两天搭了个轻量转换流水线，核心就是把Labelme生成的JSON“翻译”成VOC标准XML。这不是炫技，而是工程落地的刚需：Labelme负责“怎么标得准”，VOC XML负责“怎么喂得进模型”。它解决的不是技术深度问题，而是数据管道里的毛细血管堵塞——看不见，但卡得你寸步难行。

这个转换过程表面看只是文件格式变化，背后其实牵扯三个关键层：第一层是语义对齐——Labelme的shapes数组里每个points是顶点坐标，而VOC要求<bndbox>里的xmin/ymin/xmax/ymax是包围矩形，多边形怎么包？要不要做凸包简化？第二层是路径与元信息映射——Labelme JSON里没有<folder>字段，但VOC规定必须有，否则很多数据加载器会报错；图片尺寸是存imageHeight/imageWidth还是靠PIL重新读取？第三层是工程鲁棒性——真实场景中，一张图可能标了10个目标，其中2个没填label字段，或者points只有两个点（根本构不成多边形），这些脏数据怎么兜底？不处理，转换脚本直接崩溃；全删，标注成果大量浪费。所以这篇内容不讲“怎么写一行命令搞定”，而是带你从零手撸一个生产级转换器，每一步都解释清楚“为什么这么设计”，尤其那些官方文档绝不会写的坑。

2. 核心思路拆解：为什么不用现成工具，而要自己写转换逻辑？

网上搜“labelme to voc”，头几条全是GitHub上star过千的开源脚本，比如labelme2voc或labelme2coco改个参数。我试过三个主流方案，结论很明确：能跑通demo，扛不住真实项目。原因不在代码质量，而在设计哲学的根本差异——开源工具默认你用的是“教科书式标准数据”，而真实世界的数据永远在挑战边界。

先说最典型的labelme2voc（Python版）。它核心逻辑是：读JSON → 提取shapes→ 对每个shape调用cv2.boundingRect()算包围框 → 拼XML字符串。听起来没问题？但实际运行时你会发现三类致命缺陷：第一，多边形退化处理缺失。Labelme允许用户双击闭合多边形，但新手常误操作——画完四个点后多点一下，导致points数组里出现重复顶点或三点共线。cv2.boundingRect()对这种输入会返回[0,0,0,0]，XML里就冒出<xmin>0</xmin><ymin>0</ymin><xmax>0</xmax><ymax>0</ymax>，模型训练时loss直接nan。第二，图像尺寸来源混乱。该脚本优先读JSON里的imageHeight/imageWidth，但Labelme在导出时如果勾选了“保存缩略图”，这两个值就变成缩略图尺寸（比如640x480），而非原图真实尺寸（3840x2160）。用错尺寸，包围框坐标全部偏移。第三，类别映射硬编码。脚本里写死label_map = {"cat": 1, "dog": 2}，可你的项目新增了“kitten”类别，就得改代码、重装包——协作时版本一升级，整个数据集就废了。

所以我最终采用的方案是：不依赖任何第三方转换库，用纯Python+内置xml.etree.ElementTree实现，所有关键逻辑显式可控。具体分三层设计：

• 第一层：安全解析层。用try/except包裹JSON读取，对缺失字段（如imagePath、shapes）提供默认值；对points做有效性校验——长度<3则跳过，存在NaN值则剔除，共线点自动简化。
• 第二层：智能包围层。不用cv2.boundingRect()，改用Numpy向量化计算：xmin = min(p[0] for p in points)，这样即使points里混入异常值，也能通过np.nanmin()兜底；同时增加开关--use-minimal-bbox，当用户需要严格最小包围框时启用，否则默认用四舍五入后的整数坐标（避免浮点误差导致XML解析失败）。
• 第三层：元信息治理层。强制要求用户提供--images-dir参数指定原图根目录，脚本自动根据JSON里的imagePath拼出绝对路径并用PIL读取真实尺寸；<folder>字段直接取原图所在文件夹名（如/data/train/→train），杜绝手动填写错误；类别名不做任何转换，原样写入XML，后续由模型训练脚本统一管理映射表。

这个设计看似麻烦，实则省去后期90%的调试时间。去年帮某工业质检公司部署缺陷检测系统，他们标注了2万张PCB板图，用旧脚本转换后发现17%的XML文件包围框坐标为负数——根源就是Labelme导出时启用了“压缩图像”选项。而我们的新脚本在解析层就捕获到imageHeight异常（小于100像素），自动触发PIL重读，问题当场解决。工程思维的本质，不是找最快的路，而是找最不容易翻车的路。

3. 核心细节解析：JSON到XML的字段映射与边界处理

Labelme JSON和VOC XML的字段并非一一对应，中间存在语义鸿沟。比如Labelme的imageData字段存的是base64编码的图片数据，而VOC XML里压根不存图片内容，只存路径引用。这种差异决定了转换不能简单做字符串替换，必须理解每个字段的业务含义。下面逐字段拆解映射逻辑，并说明真实场景中的处理技巧。

3.1 图像元信息：<folder>、<filename>、<path>、<source>的生成策略

Labelme JSON里最关键的图像标识字段是imagePath，例如"imagePath": "train/001.jpg"。很多人直接把它当<filename>用，这是大忌。VOC规范要求<filename>只能是纯文件名（不含路径），而<folder>必须是上级目录名。所以正确做法是：

from pathlib import Path json_path = Path("annotations/001.json") img_rel_path = json_data["imagePath"] # "train/001.jpg" img_path = json_path.parent / img_rel_path # 拼出相对路径 folder_name = img_path.parent.name # "train" filename = img_path.name # "001.jpg"

这里有个隐藏陷阱：imagePath可能是绝对路径（如"/home/user/data/train/001.jpg"）。Labelme新版默认导出相对路径，但老版本或自定义导出脚本可能输出绝对路径。我们的转换器必须兼容两种情况——用Path(img_rel_path).is_absolute()判断，若是绝对路径，则取Path(img_rel_path).parent.name作为<folder>，否则按相对路径处理。实测某汽车零部件标注项目中，30%的JSON文件imagePath为绝对路径，因为标注员在不同电脑上切换使用Labelme，路径配置未同步。

<path>字段在VOC中用于记录图片绝对路径，但多数训练框架（如TensorFlow Object Detection API）已弃用，仅作存档用途。我们选择写入os.path.abspath(img_path)，确保路径可追溯。<source>字段在VOC中是可选的，但建议填充：<database>The Labelme Annotation Tool</database>，既符合规范，又为后续审计留痕。

3.2 尺寸信息：<size>块的尺寸来源与精度控制

VOC XML的<size>块包含<width>、<height>、<depth>三个子项。<depth>固定为3（RGB），无争议。但<width>和<height>的来源必须谨慎：

• 方案A：读JSON里的imageHeight/imageWidth
  优点：快，无需IO。缺点：如前所述，Labelme导出时若勾选“保存缩略图”，这两个值就是错的。且某些版本Labelme在导出JSON时不写这两个字段，导致KeyError。
• 方案B：用PIL读取原图获取真实尺寸
  优点：100%准确。缺点：IO开销大，2万张图要多花3分钟。

我们的折中方案是：优先读JSON字段，若缺失或值异常（<10或>10000），则fallback到PIL读取。异常值判断逻辑如下：

height = json_data.get("imageHeight", 0) width = json_data.get("imageWidth", 0) if height < 10 or width < 10 or height > 10000 or width > 10000: # PIL fallback with Image.open(img_path) as img: width, height = img.size

为什么阈值设为10和10000？因为真实工业相机图像最小常见尺寸是1280x720（监控），手机拍摄图最小约400x300，而10000是当前民用相机最高分辨率（如佳能EOS R5的8192x5464）。这个范围覆盖99.9%场景，且避免因个别损坏图片（如0字节文件）导致脚本中断。

精度方面，VOC规范要求<width>和<height>为整数。Labelme JSON里这两个值本就是int，但PIL读取时img.size返回tuple of int，无需转换。重点在坐标计算——后面讲包围框时会涉及浮点转整数的取舍问题。

3.3 目标对象：<object>块的生成与多边形包围策略

这是转换的核心难点。Labelme的shapes是一个列表，每个元素含label、points、shape_type等字段。shape_type可能是"polygon"、"rectangle"、"circle"等。VOC只支持矩形框，所以必须将所有类型统一转为<bndbox>。策略如下：

• rectangle类型：Labelme存储为两个点[[x1,y1],[x2,y2]]，需转换为xmin=min(x1,x2), ymin=min(y1,y2), xmax=max(x1,x2), ymax=max(y1,y2)。注意：Labelme不保证两点顺序，必须显式取极值。
• polygon类型：取所有顶点的x、y坐标极值。但存在退化情况：
  • 三点共线：[[100,100],[200,100],[300,100]]→ymin=ymax=100，此时<ymin>和<ymax>相等，VOC规范允许，但某些老版训练器会报错。我们的解决方案是：若ymin==ymax，则ymax += 1（同理xmin==xmax时xmax += 1），确保包围框面积>0。
  • 顶点数<3：Labelme允许用户画线段（2点）或点（1点），points数组长度可能为1或2。此时视为无效标注，跳过该shape，并在日志中记录警告：“Shape 'xxx' has only 1 point, skipped”。
• circle类型：Labelme存储为[[center_x,center_y],[radius_x,radius_y]]，实际是椭圆。我们按VOC惯例转为正方形包围框：xmin=center_x-radius_x, ymin=center_y-radius_y, xmax=center_x+radius_x, ymax=center_y+radius_y，再用前述极值逻辑修正。

所有坐标计算完成后，必须做边界裁剪：xmin = max(0, xmin),ymin = max(0, ymin),xmax = min(width, xmax),ymax = min(height, ymax)。否则可能出现xmin=-5，导致XML非法。某医疗影像项目曾因此导致Mask R-CNN训练时ROI Pooling层报错，排查三天才发现是标注时多边形画出了图像边界。

3.4 类别与属性：<name>、<pose>、<truncated>、<difficult>的务实填充

VOC的<object>块还包含<pose>、<truncated>、<difficult>等字段。很多教程建议填默认值（如<pose>Unspecified</pose>），但这会丢失信息。我们的实践是：

• <name>：严格使用Labelme中填写的label字段，不做任何清洗（如转小写、去空格）。因为类别映射应在训练阶段由label_map.txt统一管理，转换阶段保持原始性。
• <pose>：Labelme JSON无对应字段，填Unspecified。但若项目有特殊需求（如标注时区分“正面/侧面”），可在Labelme的flags字段里加{"pose": "front"}，转换器解析flags并填入。
• <truncated>：表示目标是否被截断。Labelme不提供此信息，但可通过包围框位置推断：若xmin<=1或xmax>=width-1或ymin<=1或ymax>=height-1，则设为1（截断），否则0。阈值设为1而非0，避免因坐标取整误差误判。
• <difficult>：同理，Labelme无此字段。我们设为0，但增加命令行参数--mark-difficult "car,pedestrian"，当<name>匹配列表时自动设为1。某自动驾驶项目用此功能标记“远处小目标”，提升困难样本召回率。

提示：所有布尔型字段（truncated/difficult）必须输出为0或1，不能是true/false或True/False，否则VOC解析器会报类型错误。这是XML Schema的硬性要求，不是风格问题。

4. 实操过程：从零编写可复用的转换脚本

现在把前面所有设计落地为可执行代码。我们不追求“一键安装”，而是提供一个单文件Python脚本，所有依赖均为Python标准库（json,xml.etree.ElementTree,pathlib,PIL），确保在任何Linux/macOS/Windows环境都能运行。脚本命名为labelme2voc.py，完整代码超过300行，这里聚焦核心函数与关键配置。

4.1 脚本结构与命令行接口设计

脚本采用模块化设计，主函数main()只负责解析参数和调度，核心逻辑封装在convert_json_to_xml()函数中。命令行接口遵循Unix哲学——一个程序只做一件事，但做到极致。参数设计如下：

python labelme2voc.py \ --json-dir ./labelme_annotations/ \ --images-dir ./images/ \ --output-dir ./voc_annotations/ \ --labels-file ./labels.txt \ --use-minimal-bbox \ --skip-empty

• --json-dir：Labelme导出的JSON文件目录（必填）
• --images-dir：原图根目录（必填），用于读取真实尺寸和生成<path>
• --output-dir：输出VOC XML的目录（必填）
• --labels-file：可选，指定类别名映射文件（每行一个类别，用于生成label_map.txt）
• --use-minimal-bbox：可选，启用严格最小包围框（对多边形顶点直接取极值，不简化）
• --skip-empty：可选，跳过无目标的JSON文件（Labelme允许空标注）

参数解析使用argparse，对必填参数做存在性校验，对路径参数做可读性校验（os.access(path, os.R_OK)）。特别地，--images-dir必须存在且可读，因为后续所有尺寸读取都依赖它——这是防止“路径配错导致批量生成错误XML”的第一道防线。

4.2 核心转换函数：convert_json_to_xml()详解

该函数接收单个JSON文件路径和配置参数，返回生成的XML字符串。代码骨架如下：

def convert_json_to_xml(json_file: Path, config: dict) -> str: # 1. 安全读取JSON try: with open(json_file, "r", encoding="utf-8") as f: data = json.load(f) except (json.JSONDecodeError, FileNotFoundError) as e: raise ValueError(f"Invalid JSON file {json_file}: {e}") # 2. 解析图像路径与尺寸 img_rel_path = Path(data.get("imagePath", "")) if not img_rel_path.is_absolute(): img_path = config["images_dir"] / img_rel_path else: img_path = img_rel_path # ... 尺寸读取逻辑（含fallback）... # 3. 构建XML根元素 root = ET.Element("annotation") # 添加folder/filename/path/size等... # 4. 处理每个shape for shape in data.get("shapes", []): label = shape.get("label", "").strip() if not label and config["skip_empty_label"]: continue # 跳过未填label的shape points = shape.get("points", []) if len(points) < 3 and shape.get("shape_type") == "polygon": logger.warning(f"Polygon {label} in {json_file} has <3 points, skipped") continue # 计算包围框坐标（含边界裁剪） xmin, ymin, xmax, ymax = calculate_bbox(points, shape["shape_type"], width, height) # 创建object元素 obj = ET.SubElement(root, "object") ET.SubElement(obj, "name").text = label ET.SubElement(obj, "pose").text = "Unspecified" ET.SubElement(obj, "truncated").text = "1" if is_truncated(xmin, ymin, xmax, ymax, width, height) else "0" ET.SubElement(obj, "difficult").text = "1" if label in config["difficult_labels"] else "0" bndbox = ET.SubElement(obj, "bndbox") ET.SubElement(bndbox, "xmin").text = str(int(xmin)) ET.SubElement(bndbox, "ymin").text = str(int(ymin)) ET.SubElement(bndbox, "xmax").text = str(int(xmax)) ET.SubElement(bndbox, "ymax").text = str(int(ymax)) # 5. 格式化XML（缩进） rough_string = ET.tostring(root, encoding="unicode") reparsed = minidom.parseString(rough_string) return reparsed.toprettyxml(indent=" ")

关键点在于calculate_bbox()函数。它根据shape_type分发处理：

• rectangle: 直接取两点极值
• polygon: 遍历所有点计算min/max，并应用前述退化处理（共线时+=1）
• circle: 按中心+半径计算，再裁剪

所有坐标计算使用float类型，最后转int前做round()而非int()，避免负数截断错误（如int(-1.7) = -1，但round(-1.7) = -2更符合坐标取整直觉）。

4.3 批量处理与日志系统：如何避免“静默失败”

单文件转换容易验证，但真实项目动辄上千文件。批量处理必须解决两个问题：进度可见性和错误隔离性。我们的方案是：

• 进度条：用tqdm库（需pip install tqdm）包装json_files迭代器，显示“已处理/总数/耗时/预计剩余”。不加进度条时，2万文件转换要5分钟，用户会以为脚本卡死。
• 错误隔离：对每个JSON文件的转换用try/except包裹，捕获ValueError、OSError等，记录详细错误到error.log，但不停止整个流程。“失败1个，不影响9999个”是工程底线。
• 统计报告：转换完成后生成summary.txt，内容包括：

  Total JSON files processed: 12478 Successful conversions: 12456 (99.82%) Failed conversions: 22 Skipped empty annotations: 156 Average time per file: 0.12s

这个报告比任何GUI弹窗都管用。某工厂部署时，运维人员靠summary.txt快速定位到22个失败文件全是同一台标注机导出的损坏JSON，立刻重标，避免了全量返工。

4.4 实操演示：一个真实转换案例全流程

假设我们有一个小型数据集，结构如下：

project/ ├── images/ │ ├── train/ │ │ ├── 001.jpg │ │ └── 002.jpg ├── labelme_annotations/ │ ├── 001.json │ └── 002.json

001.json内容精简如下：

{ "version": "4.5.6", "imagePath": "train/001.jpg", "imageHeight": 1080, "imageWidth": 1920, "shapes": [ { "label": "defect", "points": [[100, 200], [150, 200], [150, 250], [100, 250]], "shape_type": "polygon" } ] }

执行命令：

python labelme2voc.py \ --json-dir ./labelme_annotations/ \ --images-dir ./images/ \ --output-dir ./voc_annotations/ \ --skip-empty

脚本输出./voc_annotations/001.xml，内容为：

<?xml version="1.0" ?> <annotation> <folder>train</folder> <filename>001.jpg</filename> <path>/absolute/path/to/project/images/train/001.jpg</path> <source> <database>The Labelme Annotation Tool</database> </source> <size> <width>1920</width> <height>1080</height> <depth>3</depth> </size> <segmented>0</segmented> <object> <name>defect</name> <pose>Unspecified</pose> <truncated>0</truncated> <difficult>0</difficult> <bndbox> <xmin>100</xmin> <ymin>200</ymin> <xmax>150</xmax> <ymax>250</ymax> </bndbox> </object> </annotation>

注意：<segmented>字段在VOC中表示是否分割标注，Labelme无对应概念，故固定为0。所有字段均按前述规则生成，无任何硬编码值。

5. 常见问题与排查技巧实录：那些让人心梗的“小问题”

即使脚本写得再严谨，真实场景总有些意料之外的状况。以下是我在过去三年中收集的22个高频问题，按发生频率排序，并附上现场排查命令和根治方案。这些问题90%以上不会出现在教程里，但每个都足以让新人调试半天。

5.1 问题速查表：症状、原因、命令行诊断、修复方案

5.2 独家避坑技巧：来自血泪经验的三条铁律

铁律一：永远不要信任Labelme导出的imageHeight/imageWidth
哪怕你亲眼看到Labelme界面上显示“1920x1080”，导出的JSON里这两个值也可能被篡改。某次客户交付，我们发现5000张图中有37张imageHeight为1，原因是标注员在导出前误点了“导出为PNG”按钮，Labelme后台临时生成了1x1像素的占位图并写入JSON。根治方案：在脚本中加入“尺寸可信度校验”——若imageHeight * imageWidth < 1000，则强制PIL读取。这条规则让我们后续所有项目零尺寸错误。

铁律二：<filename>必须与原图文件名100%一致，包括大小写和扩展名
Linux系统区分大小写，001.JPG和001.jpg是两个文件。Labelme导出JSON时，imagePath里的文件名大小写与原图完全一致。但有些Windows标注员习惯全大写扩展名，上传到Linux服务器后，os.path.exists()返回False。我们的应对是：在拼img_path后，用glob模糊匹配——list(img_path.parent.glob(f"{img_path.stem}.*"))，取第一个存在的文件。虽然慢一点，但避免了“文件存在却找不到”的玄学问题。

铁律三：批量转换前，务必用--dry-run模式预演
我们在脚本中加入--dry-run参数，启用后只打印将要生成的XML路径和关键字段（如<folder>、<filename>、第一个<object>的<name>和<bndbox>），不实际写入文件。运行一次python labelme2voc.py --dry-run --json-dir ./test/，5秒内就能确认路径映射、尺寸读取、类别名是否正确。某次上线前，--dry-run发现200个JSON的<folder>全成了unknown，追查发现是imagePath字段被批量替换成了绝对路径，立刻回滚配置，避免了全量数据污染。

5.3 进阶场景：如何支持增量标注与版本管理？

真实项目不是一次性标注完就结束，而是持续迭代：第1版标了1000张，第2版新增500张并修改了200张的标签。这时转换脚本必须支持增量更新，否则每次都要全量重转，浪费算力。

我们的方案是：

• 步骤1：转换时记录每个JSON文件的mtime（修改时间）到conversion_log.json
• 步骤2：下次运行时，只处理mtime大于上次记录的JSON文件
• 步骤3：对已存在的XML文件，若对应JSON被修改，则覆盖；若JSON被删除，则保留XML（供历史对比）

命令行增加--log-file conversion_log.json参数。conversion_log.json格式为：

{ "001.json": 1678886400.0, "002.json": 1678886405.0 }

这样，每天凌晨的定时任务只需转换新增文件，耗时从30分钟降到20秒。某电商平台用此方案管理千万级商品图标注，三年来从未因转换问题延误模型迭代。

6. 工程化落地：如何将转换器集成到CI/CD流水线

当项目规模扩大，手动运行脚本不再可行。我们需将其变成自动化流水线的一环。以下是在GitLab CI中集成的实战配置，同样适用于Jenkins或GitHub Actions。

6.1 CI配置文件：.gitlab-ci.yml关键片段

stages: - validate - convert - test validate-labelme: stage: validate image: python:3.9 script: - pip install -r requirements.txt - python scripts/validate_json.py --json-dir $CI_PROJECT_DIR/labelme_annotations/ artifacts: paths: [validation_report.txt] convert-to-voc: stage: convert image: python:3.9 script: - pip install -r requirements.txt - python scripts/labelme2voc.py \ --json-dir $CI_PROJECT_DIR/labelme_annotations/ \ --images-dir $CI_PROJECT_DIR/images/ \ --output-dir $CI_PROJECT_DIR/voc_annotations/ \ --skip-empty artifacts: paths: [voc_annotations/] expire_in: 1 week test-voc-xml: stage: test image: python:3.9 script: - pip install -r requirements.txt - python scripts/test_voc.py --xml-dir $CI_PROJECT_DIR/voc_annotations/ --max-files 100

关键设计点：

• 分阶段解耦：validate阶段检查JSON语法和基本字段，失败则阻断后续；convert阶段只做转换；test阶段抽样验证XML合法性。
• 制品（artifacts）管理：convert阶段输出voc_annotations/目录，供下游训练任务下载，避免重复转换。
• 抽样测试：test-voc-xml只验证100个XML（--max-files 100），因为全量验证太慢。验证逻辑包括：XML格式有效性、<xmin>≤<xmax>、<folder>非空、<name>在预设列表中等。

6.2 本地开发协同：VS Code插件与快捷键配置

为提升单人开发效率，我们为VS Code配置了自定义任务。在.vscode/tasks.json中添加：

{ "version": "2.0.0", "tasks": [ { "label": "Convert Labelme to VOC", "type": "shell", "command": "python scripts/labelme2voc.py --json-dir ${fileDirname} --images-dir ../images/ --output-dir ../voc_annotations/", "group": "build", "presentation": { "echo": true, "reveal": "always", "focus": false, "panel": "shared", "showReuseMessage": true, "clear": true } } ] }

然后按Ctrl+Shift+P→ “Tasks: Run Task” → 选择“Convert Labelme to VOC”，即可一键转换当前打开的JSON文件所在目录。配合文件监视器（chokidar），还能实现“保存JSON即自动转换”，真正解放双手。

6.3 性能优化实测：从12秒到0.8秒的单文件转换

初始版本转换一个JSON平均耗时12秒，瓶颈在PIL读取图像尺寸。优化后降至0.8秒，提速15倍。关键优化点：

• 缓存尺寸读取：用functools.lru_cache(maxsize=1000)装饰PIL读取函数，相同路径的