土木标准图的合规审查在设计院和审图机构里至今仍是一条高度依赖人工的工序。审查人员拿到一套 PDF 图纸需要逐页翻图、定位构件、对照规范条文再把结论整理成审图意见。这个过程不仅慢而且消耗大量有经验的工程师时间。PlanSightRAG 的出发点是把这套流程中的“看图”和“查规范”拆成可自动化的检索与生成任务对平面图、立面图、节点详图这类以图像为载体的土木标准图采用视觉优先Visual-First的多模态 RAG 方案同时覆盖两个目标场景——面向图纸内容的事实问答Question Answering以及面向规范条文的合规检查Compliance Checking。这篇文章是一篇工程落地笔记不是论文复现。文中给出的代码用于说明最小可运行链路读者可以按自己的图纸类型、模型版本和规范文本库替换其中的关键模块。如果你所在团队正在做图纸智能审查、施工图问答、设计规范辅助检查或者只是想在 RAG 基础上增加对图片文档的处理能力这篇文章的架构思路和排错路线都有参考价值。1. 土木标准图为什么需要“视觉优先”的多模态 RAG1.1 标准图里到底有什么信息要理解 PlanSightRAG 为什么采用视觉优先先要看一套标准图里实际存在哪些信息。土木标准图通常不是单一模态的文档而是“图为主、文为辅、尺寸标注连接两者”的复合文档。一套典型图纸中会出现以下内容平面图表达墙体、门窗、楼梯、房间的空间关系立面图和剖面图表达竖向尺寸和构造层次节点详图表达构件连接方式标题栏记录工程名称、图号、版本尺寸线和标高符号给出精确数值设计说明和表格承载材料、做法、规范引用等文字信息。用表格拆开看每种信息依赖的载体完全不同信息类型典型载体文本层视觉层说明空间关系墙、门、窗、楼梯的图形弱强需要看图才能理解布局尺寸数值尺寸线、延伸线、数字标记弱强OCR 能读数字但容易与图元脱节构件编号C-1、M-2、M1521 等引线标注弱中需要结合图例和编号规则设计说明文字段落、材料表强中纯文本也能处理规范引用条文、表格、附注强中文本检索更合适结论很清楚如果把图纸当成普通 PDF只抽文字实际上丢弃了最重要的空间和几何信息。这正是传统 RAG 处理标准图时最大的问题。1.2 纯文本 RAG 为什么在图纸场景失效很多团队第一次接入图纸问答时会直接复用文本 RAG 流水线解析 PDF、分段、向量化、检索、交给大模型生成。落到标准图场景这个流程在多个环节失效。第一图纸 PDF 经常没有文本层。大量旧图纸是扫描件或者由 CAD 打印成 PDF程序用常规文本抽取工具拿不到任何字符。即使有文本层文字顺序也未必与视觉阅读顺序一致。第二OCR 结果无序。CAD 导出的图纸经过 OCR 后输出的是“坐标 文字”的散点没有段落、句子、标题结构。如果按照字符顺序强行拼接尺寸数字会和说明文字混在一起语义被彻底打散。第三语义单元是图形而不是段落。门的净宽是不是 900mm在图纸上表现为一条尺寸线、两根延伸线和数字“900”。文本 RAG 只看到一堆零散数字无法知道这条标注属于哪个门、对应哪个构件。第四检索表示不匹配。通用文本嵌入模型按自然语言训练查询“疏散门净宽要求”和图纸上的“M1521”“900”之间没有直接的语义桥接。文本向量检索很难把一句自然语言问题映射到图纸上的具体区域。因此检索单元必须回到“图”本身以图纸上的视觉区域为最小检索单位文字作为附属元数据。这就是视觉优先的基本动机。1.3 Visual-First 到底是什么用一句通俗的话说先看图再查字。不是先把图转成文字而是把图本身当作可以检索的对象。技术定义是在文档处理链路中将页面图像切分为视觉区域visual region每个区域同时保存图像特征、坐标和 OCR 文本检索时以图像特征作为主召回通道文本特征用于过滤和重排。放到 PlanSightRAG 里它的作用是让用户问“M1521 的防火等级是什么”时系统先定位到门节点详图所在的图像区域再读取该区域内附带的 OCR 文本“防火门 甲级”而不是在整个页面范围里盲目匹配。最小示例可以这样理解一个门节点详图区域被视觉编码模型转换成 512 维向量元数据中记录“节点详图、门、M1521、净宽、防火等级”。用户提问后文本召回先锁定包含关键词的区域图像召回再确认该区域确实是门节点而不是楼梯节点两者互为校验。这里有一个容易误解的点Visual-First 不是不要文本。文本从主索引降级为辅助信号但仍然是定位、量化和复核的关键。真正的设计原则是图像决定检索边界文本决定数值精度规则决定最终结论。2. PlanSightRAG 的整体架构从图纸入库到合规报告2.1 五层架构总览PlanSightRAG 不是一个单独模型而是一条处理链路。整套系统按职责拆成五层每一层只做一件事问题可以逐层定位。层级职责关键组件输入输出接入层统一图纸格式登记版本PDF 解析、CAD 导出、图片归一化原始图纸文件标准页面图像和元数据解析层版面分析、OCR、视觉区域切块版面检测、OCR、区域裁剪页面图像visual chunk 列表索引层构建多路索引图像向量索引、文本向量索引、关键词索引visual chunk可查询的索引文件检索层多路召回与重排向量检索、关键词检索、重排器用户问题排序后的候选片段生成与判定层生成回答和候选值规则复核LLM、规则引擎候选片段问答结果、合规报告这个分层的关键在于接入层不判断内容解析层不生成结论检索层只负责候选排序生成层不直接输出合规结论而是输出候选值最终合规结论交给规则引擎。这样即使某一步出错也能单独验证不会出现“模型一句话掩盖了整条链路问题”的情况。2.2 解析层如何把图纸切成“视觉片段”解析层把一页图纸按照“视觉区域”切块原则是让每个检索单元对应一个语义完整的图元区域而不是简单按页面或按固定字数切。处理过程是PDF 页面转成 200 到 300 DPI 图像版面分析识别图框、标题栏、说明区、节点详图区域对每个区域裁剪出子图再对子图做 OCR得到区域内文字最终形成一个 visual chunk。visual chunk 的数据结构可以用 JSON 描述{ chunk_id: A-102_p01_r07, source: A-102.pdf, page: 1, bbox: [120, 340, 480, 620], crop_image: chunks/A-102_p01_r07.png, ocr_text: 防火门 M1521 净宽1500 耐火等级甲级, region_type: node_detail, plan_id: A-102, revision: R2 }其中bbox是页面像素坐标crop_image是裁剪下来的子图路径ocr_text来自 OCRregion_type由版面分析给出。后面图像检索返回这个 chunk 时生成层既可以直接读取子图也可以读取 OCR 文本还可以拿到图号、版本信息作为证据。2.3 检索层为什么采用多路召回图纸问答最难的部分是检索因为同一个问题要同时匹配图形和文字。PlanSightRAG 采用三路召回而不是单一索引。图像向量召回把用户问题用视觉语言模型的文本编码器编码与所有 visual chunk 的图像向量计算余弦相似度。优势是能捕捉“这是门节点”“这是疏散通道”这类视觉语义。文本向量召回把问题与 OCR 文本、设计说明做向量检索。优势是能精确匹配“防火门”“净宽”“甲级防火门”等术语。关键词召回对构件编号和规范编号做精确索引。M1521、GB 50016-2014 这类编号向量模型经常分词错误精确匹配更可靠。单一路由都不够用。纯图像召回对文字密集的说明区效果不好纯文本召回看不懂图元纯关键词召回无法处理口语化问题。三路召回后做加权融合再由重排器过滤才能兼顾覆盖率和精度。2.4 合规判定层生成不是终点规则复核才是合规检查不能接受“看起来合理”的结论。LLM 生成的内容存在幻觉风险而合规结论直接影响工程决策因此主流程分成两步。第一步LLM 从检索到的视觉片段中提取候选字段值比如“疏散门净宽 1.5m”“楼梯踏步高 0.18m”并给出对应证据片段 ID。这一步只负责提取不负责判断。第二步规则引擎用规范配置表对候选值做数值比较输出 PASS、FAIL 或 UNKNOWN。规范阈值不放在 prompt 里避免模型凭记忆写错。规则引擎判定结果可追踪每条结论都有数值来源和证据 ID。这套设计的核心价值是把“模型能力”和“规范确定性”分开。模型负责理解图纸规则负责执行规范两边各司其职出错时不互相掩盖。3. 环境准备与依赖清单3.1 运行环境与硬件要求图像向量化比纯文本 RAG 更吃资源。PlanSightRAG 的小规模实验环境可以参考下面的配置环境项推荐配置说明操作系统Ubuntu 20.04/22.04Windows 10/11 也可生产环境优先 LinuxPython3.10 或 3.11依赖库对 3.12 的支持仍不稳定GPU至少 8GB 显存跑 CLIP/SigLIP 编码如果还要跑 VLM 图文理解建议 16GB 以上内存16GB多个模型同时加载时预留更多存储单套图纸 200 DPI 切图后每页约 1 到 3MB按项目规模预留纯文本 RAG 可以用 CPU 跑但图像向量化在 GPU 上快很多。没有 GPU 时可以走服务化接口但要评估单页处理延迟和请求并发是否满足业务要求。3.2 Python 依赖下面是一份经过验证的最小依赖组合。写这篇博客时它可以跑通但 PyMuPDF、PaddleOCR、Transformers 升级较快落地前要重新锁版测试。pymupdf1.24.10 paddleocr2.7.3 paddlepaddle2.6.2 transformers4.44.2 torch2.3.1 sentence-transformers3.2.1 faiss-cpu1.8.0 Pillow10.4.0 numpy1.26.4 pydantic2.8.2 PyYAML6.0.2依赖用途说明pymupdfPDF 页面渲染成高清 PNG。paddleocr、paddlepaddleOCR 文字提取可替换成其他 OCR 引擎。transformers、torch加载 CLIP 等视觉语言模型。sentence-transformers中文文本向量编码。faiss-cpu向量索引和相似度检索。Pillow图像裁剪和格式处理。视觉语言模型权重需要从模型仓库下载建议团队内部准备统一缓存目录或镜像避免每台机器重复拉取也方便版本固定。3.3 模型选型建议不同任务对模型的要求不同不必为所有环节选择最大的模型。PlanSightRAG 常见选型如下任务类型可选模型参数规模说明图像向量编码CLIP ViT-B/32、SigLIP、EVA-CLIP150M 到 300M把图变成向量用于相似度召回文本向量编码BAAI/bge-large-zh-v1.5约 400M中文检索效果好用于 OCR 文本召回图文理解与候选值提取Qwen2-VL、MiniCPM-V 等 VLM7B 到 8B从图纸区域提取数值读取裁剪图OCRPaddleOCR、PP-StructureV2不固定文字识别和版面分析具体版本以实际可用情况为准。领域精度要求高时可以对视觉模型做少量图纸微调但成本较高建议先跑通链路再评估是否值得。4. 最小可运行实现从图纸入库到问答与合规检查4.1 项目目录结构演示项目按下面结构组织实际项目可以根据团队习惯调整plansightrag/ ├── config.yaml ├── requirements.txt ├── data/ │ ├── raw/ │ │ └── A-102.pdf │ ├── chunks/ │ └── index/ ├── src/ │ ├── ingest/ │ │ ├── pdf_loader.py │ │ ├── chunker.py │ │ └── embedder.py │ ├── retrieval/ │ │ ├── indexer.py │ │ ├── multi_recall.py │ │ └── reranker.py │ ├── engine/ │ │ ├── qa_engine.py │ │ └── compliance_engine.py │ └── cli.py └── tests/ingest负责入库retrieval负责检索engine负责问答和合规判定。路径在演示代码里使用相对路径生产环境建议统一放到配置中心。4.2 图纸解析PDF 转页面高清图像第一步是把 PDF 每一页渲染成 PNG。这里用 PyMuPDF 实现# src/ingest/pdf_loader.py from pathlib import Path import fitz def pdf_to_page_images(pdf_path: Path, output_dir: Path, dpi: int 200) - list[Path]: 把 PDF 每一页渲染成 PNG返回图片路径列表。 output_dir.mkdir(parentsTrue, exist_okTrue) doc fitz.open(str(pdf_path)) image_paths [] for page_no in range(len(doc)): page doc.load_page(page_no) pix page.get_pixmap(dpidpi) out_file output_dir / f{pdf_path.stem}_p{page_no 1:03d}.png pix.save(str(out_file)) image_paths.append(out_file) print(f[ 视觉优先的多模态RAG：土木标准图智能审查与合规检查实践
土木标准图的合规审查在设计院和审图机构里至今仍是一条高度依赖人工的工序。审查人员拿到一套 PDF 图纸需要逐页翻图、定位构件、对照规范条文再把结论整理成审图意见。这个过程不仅慢而且消耗大量有经验的工程师时间。PlanSightRAG 的出发点是把这套流程中的“看图”和“查规范”拆成可自动化的检索与生成任务对平面图、立面图、节点详图这类以图像为载体的土木标准图采用视觉优先Visual-First的多模态 RAG 方案同时覆盖两个目标场景——面向图纸内容的事实问答Question Answering以及面向规范条文的合规检查Compliance Checking。这篇文章是一篇工程落地笔记不是论文复现。文中给出的代码用于说明最小可运行链路读者可以按自己的图纸类型、模型版本和规范文本库替换其中的关键模块。如果你所在团队正在做图纸智能审查、施工图问答、设计规范辅助检查或者只是想在 RAG 基础上增加对图片文档的处理能力这篇文章的架构思路和排错路线都有参考价值。1. 土木标准图为什么需要“视觉优先”的多模态 RAG1.1 标准图里到底有什么信息要理解 PlanSightRAG 为什么采用视觉优先先要看一套标准图里实际存在哪些信息。土木标准图通常不是单一模态的文档而是“图为主、文为辅、尺寸标注连接两者”的复合文档。一套典型图纸中会出现以下内容平面图表达墙体、门窗、楼梯、房间的空间关系立面图和剖面图表达竖向尺寸和构造层次节点详图表达构件连接方式标题栏记录工程名称、图号、版本尺寸线和标高符号给出精确数值设计说明和表格承载材料、做法、规范引用等文字信息。用表格拆开看每种信息依赖的载体完全不同信息类型典型载体文本层视觉层说明空间关系墙、门、窗、楼梯的图形弱强需要看图才能理解布局尺寸数值尺寸线、延伸线、数字标记弱强OCR 能读数字但容易与图元脱节构件编号C-1、M-2、M1521 等引线标注弱中需要结合图例和编号规则设计说明文字段落、材料表强中纯文本也能处理规范引用条文、表格、附注强中文本检索更合适结论很清楚如果把图纸当成普通 PDF只抽文字实际上丢弃了最重要的空间和几何信息。这正是传统 RAG 处理标准图时最大的问题。1.2 纯文本 RAG 为什么在图纸场景失效很多团队第一次接入图纸问答时会直接复用文本 RAG 流水线解析 PDF、分段、向量化、检索、交给大模型生成。落到标准图场景这个流程在多个环节失效。第一图纸 PDF 经常没有文本层。大量旧图纸是扫描件或者由 CAD 打印成 PDF程序用常规文本抽取工具拿不到任何字符。即使有文本层文字顺序也未必与视觉阅读顺序一致。第二OCR 结果无序。CAD 导出的图纸经过 OCR 后输出的是“坐标 文字”的散点没有段落、句子、标题结构。如果按照字符顺序强行拼接尺寸数字会和说明文字混在一起语义被彻底打散。第三语义单元是图形而不是段落。门的净宽是不是 900mm在图纸上表现为一条尺寸线、两根延伸线和数字“900”。文本 RAG 只看到一堆零散数字无法知道这条标注属于哪个门、对应哪个构件。第四检索表示不匹配。通用文本嵌入模型按自然语言训练查询“疏散门净宽要求”和图纸上的“M1521”“900”之间没有直接的语义桥接。文本向量检索很难把一句自然语言问题映射到图纸上的具体区域。因此检索单元必须回到“图”本身以图纸上的视觉区域为最小检索单位文字作为附属元数据。这就是视觉优先的基本动机。1.3 Visual-First 到底是什么用一句通俗的话说先看图再查字。不是先把图转成文字而是把图本身当作可以检索的对象。技术定义是在文档处理链路中将页面图像切分为视觉区域visual region每个区域同时保存图像特征、坐标和 OCR 文本检索时以图像特征作为主召回通道文本特征用于过滤和重排。放到 PlanSightRAG 里它的作用是让用户问“M1521 的防火等级是什么”时系统先定位到门节点详图所在的图像区域再读取该区域内附带的 OCR 文本“防火门 甲级”而不是在整个页面范围里盲目匹配。最小示例可以这样理解一个门节点详图区域被视觉编码模型转换成 512 维向量元数据中记录“节点详图、门、M1521、净宽、防火等级”。用户提问后文本召回先锁定包含关键词的区域图像召回再确认该区域确实是门节点而不是楼梯节点两者互为校验。这里有一个容易误解的点Visual-First 不是不要文本。文本从主索引降级为辅助信号但仍然是定位、量化和复核的关键。真正的设计原则是图像决定检索边界文本决定数值精度规则决定最终结论。2. PlanSightRAG 的整体架构从图纸入库到合规报告2.1 五层架构总览PlanSightRAG 不是一个单独模型而是一条处理链路。整套系统按职责拆成五层每一层只做一件事问题可以逐层定位。层级职责关键组件输入输出接入层统一图纸格式登记版本PDF 解析、CAD 导出、图片归一化原始图纸文件标准页面图像和元数据解析层版面分析、OCR、视觉区域切块版面检测、OCR、区域裁剪页面图像visual chunk 列表索引层构建多路索引图像向量索引、文本向量索引、关键词索引visual chunk可查询的索引文件检索层多路召回与重排向量检索、关键词检索、重排器用户问题排序后的候选片段生成与判定层生成回答和候选值规则复核LLM、规则引擎候选片段问答结果、合规报告这个分层的关键在于接入层不判断内容解析层不生成结论检索层只负责候选排序生成层不直接输出合规结论而是输出候选值最终合规结论交给规则引擎。这样即使某一步出错也能单独验证不会出现“模型一句话掩盖了整条链路问题”的情况。2.2 解析层如何把图纸切成“视觉片段”解析层把一页图纸按照“视觉区域”切块原则是让每个检索单元对应一个语义完整的图元区域而不是简单按页面或按固定字数切。处理过程是PDF 页面转成 200 到 300 DPI 图像版面分析识别图框、标题栏、说明区、节点详图区域对每个区域裁剪出子图再对子图做 OCR得到区域内文字最终形成一个 visual chunk。visual chunk 的数据结构可以用 JSON 描述{ chunk_id: A-102_p01_r07, source: A-102.pdf, page: 1, bbox: [120, 340, 480, 620], crop_image: chunks/A-102_p01_r07.png, ocr_text: 防火门 M1521 净宽1500 耐火等级甲级, region_type: node_detail, plan_id: A-102, revision: R2 }其中bbox是页面像素坐标crop_image是裁剪下来的子图路径ocr_text来自 OCRregion_type由版面分析给出。后面图像检索返回这个 chunk 时生成层既可以直接读取子图也可以读取 OCR 文本还可以拿到图号、版本信息作为证据。2.3 检索层为什么采用多路召回图纸问答最难的部分是检索因为同一个问题要同时匹配图形和文字。PlanSightRAG 采用三路召回而不是单一索引。图像向量召回把用户问题用视觉语言模型的文本编码器编码与所有 visual chunk 的图像向量计算余弦相似度。优势是能捕捉“这是门节点”“这是疏散通道”这类视觉语义。文本向量召回把问题与 OCR 文本、设计说明做向量检索。优势是能精确匹配“防火门”“净宽”“甲级防火门”等术语。关键词召回对构件编号和规范编号做精确索引。M1521、GB 50016-2014 这类编号向量模型经常分词错误精确匹配更可靠。单一路由都不够用。纯图像召回对文字密集的说明区效果不好纯文本召回看不懂图元纯关键词召回无法处理口语化问题。三路召回后做加权融合再由重排器过滤才能兼顾覆盖率和精度。2.4 合规判定层生成不是终点规则复核才是合规检查不能接受“看起来合理”的结论。LLM 生成的内容存在幻觉风险而合规结论直接影响工程决策因此主流程分成两步。第一步LLM 从检索到的视觉片段中提取候选字段值比如“疏散门净宽 1.5m”“楼梯踏步高 0.18m”并给出对应证据片段 ID。这一步只负责提取不负责判断。第二步规则引擎用规范配置表对候选值做数值比较输出 PASS、FAIL 或 UNKNOWN。规范阈值不放在 prompt 里避免模型凭记忆写错。规则引擎判定结果可追踪每条结论都有数值来源和证据 ID。这套设计的核心价值是把“模型能力”和“规范确定性”分开。模型负责理解图纸规则负责执行规范两边各司其职出错时不互相掩盖。3. 环境准备与依赖清单3.1 运行环境与硬件要求图像向量化比纯文本 RAG 更吃资源。PlanSightRAG 的小规模实验环境可以参考下面的配置环境项推荐配置说明操作系统Ubuntu 20.04/22.04Windows 10/11 也可生产环境优先 LinuxPython3.10 或 3.11依赖库对 3.12 的支持仍不稳定GPU至少 8GB 显存跑 CLIP/SigLIP 编码如果还要跑 VLM 图文理解建议 16GB 以上内存16GB多个模型同时加载时预留更多存储单套图纸 200 DPI 切图后每页约 1 到 3MB按项目规模预留纯文本 RAG 可以用 CPU 跑但图像向量化在 GPU 上快很多。没有 GPU 时可以走服务化接口但要评估单页处理延迟和请求并发是否满足业务要求。3.2 Python 依赖下面是一份经过验证的最小依赖组合。写这篇博客时它可以跑通但 PyMuPDF、PaddleOCR、Transformers 升级较快落地前要重新锁版测试。pymupdf1.24.10 paddleocr2.7.3 paddlepaddle2.6.2 transformers4.44.2 torch2.3.1 sentence-transformers3.2.1 faiss-cpu1.8.0 Pillow10.4.0 numpy1.26.4 pydantic2.8.2 PyYAML6.0.2依赖用途说明pymupdfPDF 页面渲染成高清 PNG。paddleocr、paddlepaddleOCR 文字提取可替换成其他 OCR 引擎。transformers、torch加载 CLIP 等视觉语言模型。sentence-transformers中文文本向量编码。faiss-cpu向量索引和相似度检索。Pillow图像裁剪和格式处理。视觉语言模型权重需要从模型仓库下载建议团队内部准备统一缓存目录或镜像避免每台机器重复拉取也方便版本固定。3.3 模型选型建议不同任务对模型的要求不同不必为所有环节选择最大的模型。PlanSightRAG 常见选型如下任务类型可选模型参数规模说明图像向量编码CLIP ViT-B/32、SigLIP、EVA-CLIP150M 到 300M把图变成向量用于相似度召回文本向量编码BAAI/bge-large-zh-v1.5约 400M中文检索效果好用于 OCR 文本召回图文理解与候选值提取Qwen2-VL、MiniCPM-V 等 VLM7B 到 8B从图纸区域提取数值读取裁剪图OCRPaddleOCR、PP-StructureV2不固定文字识别和版面分析具体版本以实际可用情况为准。领域精度要求高时可以对视觉模型做少量图纸微调但成本较高建议先跑通链路再评估是否值得。4. 最小可运行实现从图纸入库到问答与合规检查4.1 项目目录结构演示项目按下面结构组织实际项目可以根据团队习惯调整plansightrag/ ├── config.yaml ├── requirements.txt ├── data/ │ ├── raw/ │ │ └── A-102.pdf │ ├── chunks/ │ └── index/ ├── src/ │ ├── ingest/ │ │ ├── pdf_loader.py │ │ ├── chunker.py │ │ └── embedder.py │ ├── retrieval/ │ │ ├── indexer.py │ │ ├── multi_recall.py │ │ └── reranker.py │ ├── engine/ │ │ ├── qa_engine.py │ │ └── compliance_engine.py │ └── cli.py └── tests/ingest负责入库retrieval负责检索engine负责问答和合规判定。路径在演示代码里使用相对路径生产环境建议统一放到配置中心。4.2 图纸解析PDF 转页面高清图像第一步是把 PDF 每一页渲染成 PNG。这里用 PyMuPDF 实现# src/ingest/pdf_loader.py from pathlib import Path import fitz def pdf_to_page_images(pdf_path: Path, output_dir: Path, dpi: int 200) - list[Path]: 把 PDF 每一页渲染成 PNG返回图片路径列表。 output_dir.mkdir(parentsTrue, exist_okTrue) doc fitz.open(str(pdf_path)) image_paths [] for page_no in range(len(doc)): page doc.load_page(page_no) pix page.get_pixmap(dpidpi) out_file output_dir / f{pdf_path.stem}_p{page_no 1:03d}.png pix.save(str(out_file)) image_paths.append(out_file) print(f[