简介：面向目标检测入门与工业质检场景的YOLO格式瓷砖缺陷数据集，包含约1700张标注图片，共裂缝、正常两个类别，适合用于瓷砖表面裂缝识别模型的训练与验证。图片与标签文本分别保存在不同目录，标注由LabelImg完成，标签为txt格式，并已对部分数据做翻转、添加噪声等增强处理，可直接投入YOLO系列模型训练。压缩包内共2000个文件，其中1765个txt标注文件、234个jpg图像及1个数据可视化py脚本，整体约91.75MB；目录结构清晰，classes.txt明确类别对应关系。附带可视化脚本无需改动即可运行，随机传入一张图片即可输出带边界框的标注结果，便于快速核查标签质量。目前已有193人学习下载，适合需要现成数据集进行裂缝检测实验、YOLOv5改进或目标检测入门练习的读者，也可用于学习数据增强与标注格式转换。
1. 这块瓷砖数据集是什么：一个能直接进训练流程的“2类裂缝检测包”
做瓷砖表面缺陷检测的人，拿到手的第一份资源往往不是模型，而是一份划分好的 YOLO 数据集。标题里这个包解决的就是“从数据到可训练”这一步：2 个类别，通常是长条形的裂纹（crack）和边缘崩角或表面破口（chip），图片按 train / val / test 分好，附带类别 class 文件和一套数据可视化脚本。也就是说，解压之后不用再花一晚上整理目录、写转换脚本，直接用 YOLO 训练命令就能跑起来。
这套东西适合谁？一类是刚入手 YOLO 的工程师，想在建自己的数据集之前先看一份规范样本长什么样；另一类是已经标了一批瓷砖图片但不会划分、不会检查标注的团队，拿这份目录和脚本当模板改一改就能复用。关键不在于图片数量多大，而在于流程完整：数据划分干净、class 文件和标签一一对应、可视化脚本能把标注质量摊开给人看。训练深度学习模型之前，至少要有一次“肉眼审查标注”的机会，这个包里的脚本就是干这个的。
2. 翻开划分好的数据集：目录结构、class 文件与标签格式
2.1 先看清 train / val / test 三件套的落位
解压后第一件事不是急着训模型，而是先把目录结构完整看一遍。常见做法是 YOLO 系列统一的数据布局：images下按train / val / test分子目录，labels下同名子目录，标签和图片通过“同名不同后缀”对应。比如一张IMG_001.jpg的标注，必然在同级 labels 目录下能找到IMG_001.txt。
用一条命令就能把骨架看明白：
tree -L 2 --dirsfirst # 期望看到类似输出： # . # ├── classes.txt # ├── images # │ ├── test # │ ├── train # │ └── val # ├── labels # │ ├── test # │ ├── train # │ └── val # ├── visualize.py # └── data.yaml这里classes.txt就是标题里说的类别 class 文件，visualize.py是可视化脚本，data.yaml是训练时给 YOLO 吃的配置。很多新手下意识以为train / val / test比例越接近越好，其实对瓷砖裂缝这种缺陷检测，三类场景分布差异很大，尤其是光照不均、表面纹理干扰多的批次，必须保证 val 和 test 里也有这些困难样本，而不是只放在 train 里。
划分比例的常见做法是 7 : 2 : 1 或 8 : 1 : 1。比例本身不是难点，难在划分时要把同一块瓷砖的不同视角图片放进同一个集合里。否则一张瓷砖的粗裂纹出现在 train，它的另一个视角切片却出现在 test，val 阶段指标虚高，训出来的模型到了产线一测就原形毕露。
2.2 class 文件命名与实际图片标注顺序不一致的后果
class 文件看起来只有两行文本，但它的顺序直接决定了模型学到的类别是什么。YOLO 的标签文件里每条记录的第一个数字是类别索引，这个索引按classes.txt的“行号”来算：第一行是 0，第二行是 1。不是按类别名字的拼音或首字母排序，也不是按你在标注软件里看列表时的视觉顺序。
常见翻车现场是：一个数据集在 Roboflow 上标注时类别叫crack和chip，导出时顺序是crack在前、chip在后；另一个人拿到手以后，为了让名字“更好看”把classes.txt改成了chip在前、crack在后，但 labels 目录里几千个 txt 文件的索引没跟着改。于是原本标注为 chip 的框，训练时被当成了 crack，整个模型类别语义颠倒，val 曲线再好也是假的。
先检查再动手，两步到位：
# 1. 看 class 文件内容 cat classes.txt # crack # chip # 2. 抽查 labels/train 里任意一个 txt 的类别索引分布 awk '{print $1}' labels/train/*.txt | sort | uniq -c # 期望看到 0 和 1 都有出现，确认图片里两种缺陷都标了如果第二步统计出来只有 0 或者只有 1，先别怀疑数据有问题，要回到图片上确认是不是确实只包含单类缺陷。瓷砖数据集里这种情况挺常见，一批次只裂不崩，另一批次只崩不裂，单一批次抽查不到另一类是正常的。
2.3 label 文件一条记录一个框
YOLO 标签的格式是每行一个目标，规范是五列：
class_id x_center y_center width height后四列全部是归一化坐标，范围在 0 到 1 之间，相对于图片的宽和高计算，不是像素值。举例来说，一张 1920 x 1080 的图片里，某个裂缝框的左上角在像素 (600, 300)，右下角在 (1200, 700)，换算后中心点是 ((600+1200)/2 / 1920, (300+700)/2 / 1080)，宽是 (1200-600)/1920，高是 (700-300)/1080。这个换算逻辑是可视化脚本的基础，几乎所有排查都要基于它展开。
用一段短命令快速扫描异常标签是省时间的做法：
# 找出坐标越界的标签行 awk '{ if ($2 < 0 || $2 > 1 || $3 < 0 || $3 > 1 || $4 < 0 || $4 > 1 || $5 < 0 || $5 > 1) print FILENAME": "$0 }' labels/train/*.txt没有输出就是正常。这里特别提醒，YOLO 标签允许目标紧贴图片边缘，所以中心点坐标可以非常接近 0 或 1，宽度也可能接近 1，这本身不是错误；但只要出现负值，基本是标注软件导出 bug 或手工改坏了，训练时轻则报 warning，重则 loss 直接飞掉。见到这类文件，最快的解决办法是删除对应图片和标签，而不是试图去修坐标，一张两张的丢弃对模型影响可以忽略。
3. 可视化脚本：在训练前把标注质量摊开来看
3.1 用 OpenCV 叠加边界框
标题里特意点出的“数据可视化脚本”，本质上解决的是信任问题。标签文件是纯数字，没人能靠读 txt 判断标注准不准；可视化脚本把这些数字还原成图片上的彩色框，一眼就能看出裂缝位置对不对、框体是否把纹理误当成了裂纹。
这段脚本是一个最小实现，也是绝大多数数据集自带脚本的底层逻辑：
import cv2 import os image_dir = "images/train" label_dir = "labels/train" output_dir = "visual_check" os.makedirs(output_dir, exist_ok=True) for img_name in os.listdir(image_dir): if not img_name.endswith(".jpg"): continue img_path = os.path.join(image_dir, img_name) label_path = os.path.join(label_dir, img_name.replace(".jpg", ".txt")) img = cv2.imread(img_path) img_h, img_w = img.shape[:2] with open(label_path, "r", encoding="utf-8") as f: lines = f.readlines() for line in lines: parts = line.strip().split() if len(parts) < 5: continue cls_id, xc, yc, w, h = map(float, parts[:5]) # 从归一化坐标换算回像素坐标 x1 = int((xc - w / 2) * img_w) y1 = int((yc - h / 2) * img_h) x2 = int((xc + w / 2) * img_w) y2 = int((yc + h / 2) * img_h) # 边缘像素保护，防止画出图外 x1, y1 = max(0, x1), max(0, y1) x2, y2 = min(img_w - 1, x2), min(img_h - 1, y2) color = (0, 0, 255) if int(cls_id) == 0 else (0, 255, 255) cv2.rectangle(img, (x1, y1), (x2, y2), color, 2) cv2.putText(img, str(int(cls_id)), (x1, y1 - 5), cv2.FONT_HERSHEY_SIMPLEX, 0.6, color, 2) out_path = os.path.join(output_dir, img_name) cv2.imwrite(out_path, img) if os.path.getsize(out_path) < 1024: print(f"可疑文件，输出图片过小: {img_name}")这段脚本逻辑分成三步：读图、读标签、画框。类别索引 0 用红色，1 用黄色，实际使用中颜色自己定义即可，重点看两个参数：color用于区分类别，thickness=2是边框粗细。瓷砖裂纹通常细长，如果线宽太大，会盖住裂缝本体，肉眼检查时反而不容易判断框和裂纹边缘是否贴合，所以瓷砖这类小目标场景我一般把 thickness 设为 1 或 2。
3.2 用类别分布柱状图发现类别失衡
画框只能看到单张图的质量，看不到整个数据集的分布。两份数据集在“视觉上都能看到裂缝”和“可训练程度”之间差别很大，一个典型变量是：每个类别到底有多少个目标框。只画框不统计，容易漏掉类别失衡的问题。
import os import matplotlib.pyplot as plt label_dir = "labels/train" class_names = ["crack", "chip"] counts = {0: 0, 1: 0} for txt_name in os.listdir(label_dir): if not txt_name.endswith(".txt"): continue with open(os.path.join(label_dir, txt_name), "r", encoding="utf-8") as f: for line in f: parts = line.strip().split() if len(parts) >= 1: cls_id = int(parts[0]) counts[cls_id] = counts.get(cls_id, 0) + 1 plt.bar(class_names, [counts[0], counts[1]]) plt.title("Training Set Class Distribution") plt.ylabel("Object Count") plt.tight_layout() plt.savefig("class_distribution.png", dpi=150)跑完看一眼柱状图，如果 crack 有 3000 个框而 chip 只有 180 个，相差接近 17 倍，这就是典型的长尾分布。应对方法通常有两个：一是用--cls损失权重让模型更关注少样本类别，二是对 chip 类别做离线复制增强。两种方法的细节在第 5 章展开，这里先得出“是否失衡”的结论。
3.3 可视化脚本的入参与可调项
一个工程上能反复用的可视化脚本，应当支持命令行参数，而不是改代码换目录。常见做法是给脚本加四个参数：--image_dir、--label_dir、--output_dir、--class_file。这样做的好处是 train / val / test 三个集合都能复用同一个脚本，不用复制三份代码。
--class_file是一个关键参数，脚本从 class 文件读取类别名，而不是写死在代码里。这样即使 class 文件被更新，脚本无需改动。
python visualize.py \ --image_dir images/train \ --label_dir labels/train \ --output_dir visual_check/train \ --class_file classes.txt另一个容易被忽视的是图片后缀匹配。瓷砖数据集可能混着.jpg和.png，脚本里如果只匹配一个后缀，另一个格式的图片会被静默跳过，你看到全部可视化结果，但实际只覆盖了部分数据。更稳妥的做法是直接匹配 label 文件名，再反查图片是否存在：
for label_name in os.listdir(label_dir): base = os.path.splitext(label_name)[0] img_path = os.path.join(image_dir, base + ".jpg") if not os.path.exists(img_path): img_path = os.path.join(image_dir, base + ".png") if not os.path.exists(img_path): print(f"标签存在但图片缺失: {label_name}") continue这样能顺手查出“孤儿标签”——有 txt 无图片的脏数据。这类文件在训练时不会直接报错，但会让 val 阶段的目标数量统计失真，等到发现指标对不上时已经浪费了一轮训练。
4. 实战避坑：跑 YOLO 训练时最容易卡住的 4 个细节
4.1 图片是 BGR、标签是归一化——别指望肉眼直读
现象：可视化脚本画出来的框位置整体偏移，或者色彩明显不对，裂纹明明是灰白色的，却偏蓝偏绿。
原因：OpenCV 的cv2.imread读进来的是 BGR 通道顺序，可视化脚本如果直接用plt.imshow显示，红蓝通道互换，颜色全乱；边界框偏移则是因为标签坐标是归一化值，脚本忘了乘图片宽高。
解决：显示前做一次通道转换cv2.cvtColor(img, cv2.COLOR_BGR2RGB)，换算坐标时严格按xc * img_w和yc * img_h计算，宽度和高度分别乘对应轴的尺寸，不要图省事统一乘一个值。这不是玄学，是每个跑过目标检测的人都踩过的同一块石头。
4.2 class 文件顺序变动导致模型学到的类别张冠李戴
现象：训练跑完，val 精度看着不错，打开推理结果发现红色框全标在崩角上，黄色框全标在裂纹上，整个类别语义对调。
原因：某个环节改过classes.txt的行顺序，但没有同步修改 labels 目录里成千上万个 txt 文件第一列的索引。YOLO 训练时类别名只从classes.txt里读，它不关心图片里原来叫 crack 还是 chip，完全按索引号对齐。
解决：训练前做一次全量抽查，用第 2.2 节里的awk命令统计每个类别的框数量，然后和 class 文件逐行对应确认。最保险的是在数据准备阶段就固定 class 文件顺序，之后任何环节都不允许改动，除非重新生成标签。
4.3 数据划分后文件数量对不上
现象：images/train 里有 800 张图，labels/train 里只有 760 个 txt；或者反过来 labels 里多出几十个没有对应图片的标签。
原因：很多人划分数据是直接在图片文件夹里按比例随机挑文件，复制到 train 目录后忘记把对应的 txt 一起带过去。图片是 jpg、标签是 txt，后缀不同，文件管理器里排序规律不同，批量操作时很容易遗漏。
解决：划分数据集要基于“主文件名”而不是文件类型。用脚本遍历 labels 目录文件名，去 images 里反查同名文件是否存在，缺失的列一张清单，统一补齐；如果图片本身已经无法找回，就把孤儿标签清掉，保证两边都是 766 张。
4.4 碰到缺失或损坏图片
现象：训练在某个 epoch 突然中断，报错信息指向cv2.imread返回 None，后面跟着一个奇怪的图片文件名。
原因：图片文件后缀是.jpg，但实际内容损坏，或者文件大小为 0。OpenCV 读不进来返回 None，数据加载器没做防御，程序直接崩溃。
解决：训练前用一条命令全量体检，损坏图片尽量直接删除或重拷：
find images -name "*.jpg" -size 0 -delete python -c " import cv2, glob bad = [] for p in glob.glob('images/**/*.jpg', recursive=True): if cv2.imread(p) is None: bad.append(p) print('\n'.join(bad)) "这段脚本把imread失败的图片列出来，执行前提是已经确认这些图片不重要，只做体检不做恢复。更稳妥的做法是在训练数据加载器里加try/except跳过坏图，但这属于“后悔药”，不推荐作为首要防线。数据进入训练流程之前，必须先让每条样本可读、坐标合法、类别索引对应。
5. 进阶：用可视化结果反向微调训练集，两处改动就能压住裂缝漏检
5.1 先给少样本类别加权重
可视化脚本跑完，最容易得到的结论就是类别失衡。瓷砖场景里裂缝条数通常远多于崩角，模型训练时倾向把模糊的崩角也预测成裂缝。YOLOv8 / YOLO11 风格的新版训练入口，可以在 data yaml 里直接指定权重矩阵。例如 chip 只有 crack 的 1/10，把loss_weights设为[1.0, 3.0]，让模型对少样本类别的误判付出更高代价。
这个参数不是越大越好。之前见过有人把少样本类别权重提到 10，结果模型把所有高置信度预测都推向 chip，泛化能力反而下降。从 2 到 3 起步，观察 val 类别精度，如果 chip 的 recall 明显上升而 precision 没有崩，再继续加。
5.2 把可视化结果里的难例筛出来单独验证
可视化脚本真正值钱的地方是让你看见“模型即将看到什么”。我在实际项目中会把框压着裂缝边缘、框体跨过砖缝纹理、光照极暗导致裂缝几乎看不清的图片，单独拷到一个hard_examples目录，用这些图片而不是 val 全集做推理测试。效果很直接：模型在全量 val 上 mAP 挺高，但拿 hard examples 一测就现原形，这个模型到了现场大概率翻车。
具体节奏是：先跑一次可视化，挑 20 到 30 张难例；训完一个版本后立刻推理这些难例，看裂缝的中段是否断开、相邻两条裂纹是否被合并成一个大框。哪里断框就用第 3.1 节标记缺陷位置，拿到第 5.1 节的权重里侧重复试。“数据可视化 + hard example 回归”这套组合，比只看训练曲线可靠得多，因为训练曲线只告诉你 loss 在降，不告诉你实际场景里有哪些裂缝没被找出来。
5.3 最后顺手做的一件事：保存 val 可视化对比图
训练到一个阶段后，让可视化脚本跑在labels/val上，再把模型推理 val 图片的结果也用同一套画框函数导出，打到一个目录里按文件名对比。一边是标注框，一边是预测框，框重叠得齐不齐、预测框是不是把背景杂点也框了，都一眼可见。
这也是我长期比较认可的验证方式：数值指标负责总结整体趋势，可视化对比负责挑刺。做数据集的工程师很少纯粹“给别人提供数据”，这份数据集最终是用来训练模型的，模型能用可视化脚本自查质量，数据集的复用价值才真正落地。按照这套流程把数据从解压、检查到训练首尾走通之后，再遇到新的瓷砖纹理、新的缺陷形态，你只需要改 class 文件、重跑可视化脚本、换掉一批困难样本，整个闭环就能再次转起来。少踩几轮晕头转向的坑，是我做这个方向最直接的收获，希望帮到你。
本文还有配套的精品资源，点击获取
