简介这份资源面向使用PyTorch做深度学习、需要处理高光谱图像HSI的开发者与研究者聚焦于用DataLoader高效加载与预处理这类多波段数据。包内共7个文件以3个Python脚本为主辅以2个编译缓存文件与2个mat数据文件压缩包约5.69MB体量轻便便于直接运行与二次修改。代码围绕自定义Dataset类展开涵盖数据读取、归一化预处理、批处理、多线程加载、随机打乱与自定义collate_fn等关键环节并配有训练入口脚本与示例数据集可帮助读者理解高光谱数据从磁盘到网络输入的完整链路。已有613人学习适合希望快速搭建高光谱训练流水线、对照实践数据加载优化策略的读者参考。1. 高光谱数据加载这件事卡住过太多人第一次跑高光谱分类实验时我把数据整理成一个个.mat文件训练脚本里直接scipy.io.loadmat循环读一个 epoch 跑完花了四十多分钟GPU 利用率常年个位数。后来才想明白瓶颈根本不在模型而在数据管道——高光谱立方体动辄几百个波段、单样本几十 MB如果还用最朴素的方式喂给 PyTorch再好的显卡也得干等着。这个项目要解决的就是这件事用 PyTorch 的Dataset和DataLoader把高光谱数据组织成可批量、可打乱、可多进程预取的训练流让pytorch 高光谱 python这套组合真正跑出应有的吞吐。它适合刚接触高光谱分类、手里有一堆.mat或.tif立方体却不知道怎么接进训练循环的开发者也适合想把实验室里那套脚本重构成规范工程结构的人。下面按「数据长什么样 → 管道怎么搭 → 怎么跑 → 怎么改」的顺序拆。2. 数据管道设计从高光谱立方体到可迭代的 batch2.1 先搞清楚高光谱数据的形状约定高光谱数据最常见的两种存法一种是.mat里存一个(H, W, B)的三维数组外加一个(H, W)的标签图另一种是逐像素存成(N, B)的二维矩阵加(N,)标签。前者保留空间结构适合做 patch 采样后者适合像素级分类。项目里我一般统一成「先读成(H, W, B)的 numpy 数组再按需切 patch 或展平」这样下游Dataset只面对一种形状少一层心智负担。波段数B是内存杀手。一个145×145×200的立方体float64 就是 33 MB 左右转成 float32 减半。如果整个数据集有几十个这样的立方体全量加载进内存会直接爆掉。常见做法是训练时只保留当前 batch 需要的 patch或者用np.memmap做内存映射让操作系统按页调度。我在项目里默认走「启动时加载标签图 按索引懒加载立方体」的路子牺牲一点首次读取延迟换内存可控。import numpy as np import scipy.io as sio def load_cube(mat_path, cube_keydata, gt_keygt): 读取一个高光谱立方体与标签图统一成 (H, W, B) 与 (H, W) raw sio.loadmat(mat_path) cube raw[cube_key].astype(np.float32) # 波段维度放最后 gt raw[gt_key].astype(np.int64) # 有些数据集存成 (B, H, W)这里统一转置 if cube.shape[0] cube.shape[-1]: cube np.transpose(cube, (1, 2, 0)) return cube, gt这段的关键在最后那个if不同来源的.mat波段维位置不一致靠「波段数通常远小于空间边长」这个经验判断做一次自动转置省得每换一个数据集就手改代码。cube_key和gt_key做成参数是因为不同数据集的变量名五花八门硬编码进去后面必然要改。2.2 Dataset 该返回什么patch 还是像素这是设计上第一个要拍板的地方。像素级Dataset的__getitem__返回(B,)的向量和标量标签实现简单但丢掉了空间邻域信息分类精度通常打折扣。patch 级返回(C, P, P)的小立方体能喂给 3D 卷积或光谱-空间联合网络代价是采样逻辑复杂、边界要 padding。我倾向默认做 patch 版本因为高光谱分类里空间上下文太重要了。采样时以目标像素为中心取P×P邻域超出边界的部分用边缘复制或零填充。下面是一个可用的骨架import torch from torch.utils.data import Dataset class HyperSpectralPatchDataset(Dataset): def __init__(self, cube, gt, patch_size11, ignore_label0): self.cube cube self.gt gt self.p patch_size self.half patch_size // 2 # 只保留有标注的像素作为样本 self.coords np.argwhere(gt ! ignore_label) def __len__(self): return len(self.coords) def __getitem__(self, idx): r, c self.coords[idx] # 边界 padding保证任何位置都能取到完整 patch padded np.pad( self.cube, ((self.half, self.half), (self.half, self.half), (0, 0)), modereflect, ) patch padded[r:r self.p, c:c self.p, :] # (P, P, B) patch np.transpose(patch, (2, 0, 1)) # (B, P, P) label int(self.gt[r, c]) - 1 # 标签从 0 开始 return torch.from_numpy(patch).float(), labelcoords在__init__里一次性算好避免每次__getitem__都扫一遍标签图。modereflect比零填充更平滑边缘样本不会引入突兀的暗带。标签减 1 是因为很多数据集的背景是 0、类别从 1 开始而 PyTorch 的CrossEntropyLoss要求类别索引从 0 起。这几行看着琐碎但每一处都是踩过坑之后加上的。2.3 DataLoader 的参数怎么调才不浪费 GPUDataset写好只是第一步真正决定吞吐的是DataLoader的num_workers、batch_size、pin_memory、persistent_workers这几个参数。我的经验是num_workers从 4 起步按 CPU 核数的 1/2 到 2/3 调pin_memoryTrue配合.to(device, non_blockingTrue)能把 H2D 拷贝和计算重叠persistent_workersTrue避免每个 epoch 重建进程池对样本数多的数据集提升明显。from torch.utils.data import DataLoader loader DataLoader( dataset, batch_size64, shuffleTrue, num_workers8, pin_memoryTrue, persistent_workersTrue, prefetch_factor4, # 每个 worker 预取的 batch 数 drop_lastTrue, )prefetch_factor只在num_workers 0时生效调大能让 worker 提前准备更多 batch但太大会吃内存。drop_lastTrue是为了避免最后一个不满的 batch 干扰 BatchNorm 的统计样本量不大时也可以关掉。这套参数在单卡 24 GB 显存、patch 11×11、200 波段的场景下基本能把 GPU 利用率拉到 70% 以上剩下的瓶颈通常在磁盘 IO 或 Python 侧的预处理。3. 跑起来环境、数据组织与训练循环3.1 环境依赖与最小可运行清单项目依赖不复杂核心就四样torch、numpy、scipy读.mat、scikit-learn划分训练/测试集和算指标。如果数据是.tif再加rasterio或tifffile。Python 版本建议 3.9 以上PyTorch 用官方对应 CUDA 版本的安装命令即可不需要额外编译。pip install torch torchvision numpy scipy scikit-learn # 若数据为 GeoTIFF再补一个 pip install tifffile rasterio装完之后先跑一个最小验证读一个立方体、构造Dataset、取一个样本确认形状和标签都对再进训练。这一步能挡掉八成「跑不起来」的问题比直接开训然后看报错高效得多。cube, gt load_cube(data/sample.mat) ds HyperSpectralPatchDataset(cube, gt, patch_size11) x, y ds[0] print(x.shape, x.dtype, y) # 期望 (B, 11, 11) float32 与 int3.2 数据目录怎么摆划分怎么做高光谱项目最容易乱的地方是数据组织。我一般按「一个数据集一个目录目录下放立方体文件、标签文件、划分索引」来摆data/ indian/ cube.mat gt.mat split.json # 训练/验证/测试像素坐标划分索引单独存成 JSON 而不是每次随机生成是为了保证多次实验可比。高光谱数据样本量小随机种子一变结果就飘固定划分是复现的前提。划分时按类别分层采样每类取固定比例做训练剩下的做测试避免小类别在训练集里一个样本都没有。import json from sklearn.model_selection import train_test_split coords np.argwhere(gt ! 0) labels gt[coords[:, 0], coords[:, 1]] tr, te train_test_split( np.arange(len(coords)), test_size0.8, stratifylabels, random_state42, ) split {train: coords[tr].tolist(), test: coords[te].tolist()} json.dump(split, open(data/indian/split.json, w))stratifylabels是关键保证每个类别在训练和测试里的比例一致。random_state固定下来后面换模型、调超参时才有对照意义。3.3 训练循环里和 DataLoader 相关的几个细节训练循环本身是标准写法但有几处和DataLoader配合的细节值得单独说。一是non_blockingTrue必须和pin_memoryTrue成对出现才有效二是每个 epoch 结束后如果发现 GPU 利用率周期性掉到 0多半是 worker 在等磁盘考虑把立方体预加载成np.memmap或换 SSD三是验证集不要用shuffleTrue否则指标会有轻微抖动。device torch.device(cuda if torch.cuda.is_available() else cpu) model YourNet(num_bandscube.shape[-1], num_classesint(gt.max())).to(device) opt torch.optim.Adam(model.parameters(), lr1e-3) crit torch.nn.CrossEntropyLoss() for epoch in range(100): model.train() for x, y in loader: x x.to(device, non_blockingTrue) y y.to(device, non_blockingTrue) opt.zero_grad() loss crit(model(x), y) loss.backward() opt.step()num_bands从数据里动态取别写死换数据集时少改一处。num_classes用gt.max()推前提是标签连续且从 1 开始如果标签有跳号得先做一次重映射否则CrossEntropyLoss会因为索引越界报错。4. 避坑与排查那些让训练卡住或结果发飘的问题4.1 现象GPU 利用率个位数训练极慢原因通常是数据预处理全压在主进程或者num_workers0。高光谱 patch 采样涉及 padding 和转置单进程做这些时 GPU 全程空转。解决办法是把num_workers调到 4 以上并确认__getitem__里没有不可序列化的对象比如打开的文件句柄否则多进程会静默退化成单进程。排查时在__getitem__里打印进程 ID看是否真的分到了多个 worker。4.2 现象报RuntimeError: DataLoader worker exited unexpectedly这是 worker 进程崩了最常见的原因是内存不够被系统杀掉或者__getitem__里抛了异常但被吞掉。高光谱 patch 如果patch_size设得大、num_workers又多每个 worker 都持有一份立方体副本内存会成倍增长。解决方式是让 worker 共享只读数据用np.memmap或在__init__里只存路径、在__getitem__里读并适当降低num_workers。定位时先把num_workers设成 0 跑一遍异常会直接抛在主进程堆栈看得清楚。4.3 现象loss 不降或者准确率在训练集上很高、测试集一塌糊涂先查标签对齐。patch 采样时坐标是(r, c)但 numpy 数组索引是[行, 列]如果读入时做过转置而标签图没同步转样本和标签就错位了。再查归一化高光谱不同波段量纲差异大训练前按波段做标准化减均值除标准差几乎是必须的而且统计量只能从训练集算不能把测试集混进去。这两处任一出错都会表现为「模型在学但学的是错的东西」。4.4 现象换一台机器结果对不上除了随机种子还要固定num_workers和persistent_workers因为多进程下的数据增强如果用了全局随机状态不同 worker 数的采样顺序会不同。更稳妥的做法是把所有随机性收敛到torch.Generator或numpy.random.Generator实例上按 worker ID 设种子。另外cudnn.benchmarkTrue会让不同输入尺寸下的卷积算法选择不同追求严格复现时把它关掉。5. 二次开发把管道改造成你自己的数据形态拿到这套骨架后真正要动的通常只有三处数据读取、采样策略、增强。数据读取层如果你的数据是.tif把load_cube换成tifffile.imread即可返回形状同样是(H, W, B)下游不用改如果是逐像素的(N, B)矩阵就跳过 patch 逻辑直接写一个返回(B,)的DatasetDataLoader部分原样复用。采样策略上类别极不平衡是高光谱的常态小类别往往只有几十个像素。我一般会在__init__里算每个类别的样本数给WeightedRandomSampler传权重让稀有类别被采到的概率提高。注意这时shuffle要设成False两者不能同时用。from torch.utils.data import WeightedRandomSampler labels np.array([int(gt[r, c]) - 1 for r, c in ds.coords]) counts np.bincount(labels) weights 1.0 / counts[labels] sampler WeightedRandomSampler(weights, num_sampleslen(weights), replacementTrue) loader DataLoader(ds, batch_size64, samplersampler, num_workers8)增强方面高光谱不能照搬图像那套水平翻转加旋转因为波段维是有物理顺序的翻转空间维可以打乱波段顺序就毁了光谱曲线。安全的增强包括空间随机裁剪、小角度旋转、加高斯噪声、随机波段丢弃模拟传感器缺失。我习惯把增强写成可组合的 transform 列表在__getitem__末尾统一应用这样换增强不用改采样逻辑。验证改造是否成功别只看最终准确率。我会在训练前先跑一个「过拟合小批量」测试取 32 个样本关掉增强训练到 loss 接近 0如果能做到说明管道和标签没问题剩下的才是模型和超参的事。这个习惯帮我省下过大量排查时间——有次准确率死活上不去就是靠这一步发现标签整体偏移了一位。从那以后我每次接新数据集都强制先走一遍小批量过拟合再开正式训练。希望帮到你。本文还有配套的精品资源点击获取
简介这份资源面向使用PyTorch做深度学习、需要处理高光谱图像HSI的开发者与研究者聚焦于用DataLoader高效加载与预处理这类多波段数据。包内共7个文件以3个Python脚本为主辅以2个编译缓存文件与2个mat数据文件压缩包约5.69MB体量轻便便于直接运行与二次修改。代码围绕自定义Dataset类展开涵盖数据读取、归一化预处理、批处理、多线程加载、随机打乱与自定义collate_fn等关键环节并配有训练入口脚本与示例数据集可帮助读者理解高光谱数据从磁盘到网络输入的完整链路。已有613人学习适合希望快速搭建高光谱训练流水线、对照实践数据加载优化策略的读者参考。1. 高光谱数据加载这件事卡住过太多人第一次跑高光谱分类实验时我把数据整理成一个个.mat文件训练脚本里直接scipy.io.loadmat循环读一个 epoch 跑完花了四十多分钟GPU 利用率常年个位数。后来才想明白瓶颈根本不在模型而在数据管道——高光谱立方体动辄几百个波段、单样本几十 MB如果还用最朴素的方式喂给 PyTorch再好的显卡也得干等着。这个项目要解决的就是这件事用 PyTorch 的Dataset和DataLoader把高光谱数据组织成可批量、可打乱、可多进程预取的训练流让pytorch 高光谱 python这套组合真正跑出应有的吞吐。它适合刚接触高光谱分类、手里有一堆.mat或.tif立方体却不知道怎么接进训练循环的开发者也适合想把实验室里那套脚本重构成规范工程结构的人。下面按「数据长什么样 → 管道怎么搭 → 怎么跑 → 怎么改」的顺序拆。2. 数据管道设计从高光谱立方体到可迭代的 batch2.1 先搞清楚高光谱数据的形状约定高光谱数据最常见的两种存法一种是.mat里存一个(H, W, B)的三维数组外加一个(H, W)的标签图另一种是逐像素存成(N, B)的二维矩阵加(N,)标签。前者保留空间结构适合做 patch 采样后者适合像素级分类。项目里我一般统一成「先读成(H, W, B)的 numpy 数组再按需切 patch 或展平」这样下游Dataset只面对一种形状少一层心智负担。波段数B是内存杀手。一个145×145×200的立方体float64 就是 33 MB 左右转成 float32 减半。如果整个数据集有几十个这样的立方体全量加载进内存会直接爆掉。常见做法是训练时只保留当前 batch 需要的 patch或者用np.memmap做内存映射让操作系统按页调度。我在项目里默认走「启动时加载标签图 按索引懒加载立方体」的路子牺牲一点首次读取延迟换内存可控。import numpy as np import scipy.io as sio def load_cube(mat_path, cube_keydata, gt_keygt): 读取一个高光谱立方体与标签图统一成 (H, W, B) 与 (H, W) raw sio.loadmat(mat_path) cube raw[cube_key].astype(np.float32) # 波段维度放最后 gt raw[gt_key].astype(np.int64) # 有些数据集存成 (B, H, W)这里统一转置 if cube.shape[0] cube.shape[-1]: cube np.transpose(cube, (1, 2, 0)) return cube, gt这段的关键在最后那个if不同来源的.mat波段维位置不一致靠「波段数通常远小于空间边长」这个经验判断做一次自动转置省得每换一个数据集就手改代码。cube_key和gt_key做成参数是因为不同数据集的变量名五花八门硬编码进去后面必然要改。2.2 Dataset 该返回什么patch 还是像素这是设计上第一个要拍板的地方。像素级Dataset的__getitem__返回(B,)的向量和标量标签实现简单但丢掉了空间邻域信息分类精度通常打折扣。patch 级返回(C, P, P)的小立方体能喂给 3D 卷积或光谱-空间联合网络代价是采样逻辑复杂、边界要 padding。我倾向默认做 patch 版本因为高光谱分类里空间上下文太重要了。采样时以目标像素为中心取P×P邻域超出边界的部分用边缘复制或零填充。下面是一个可用的骨架import torch from torch.utils.data import Dataset class HyperSpectralPatchDataset(Dataset): def __init__(self, cube, gt, patch_size11, ignore_label0): self.cube cube self.gt gt self.p patch_size self.half patch_size // 2 # 只保留有标注的像素作为样本 self.coords np.argwhere(gt ! ignore_label) def __len__(self): return len(self.coords) def __getitem__(self, idx): r, c self.coords[idx] # 边界 padding保证任何位置都能取到完整 patch padded np.pad( self.cube, ((self.half, self.half), (self.half, self.half), (0, 0)), modereflect, ) patch padded[r:r self.p, c:c self.p, :] # (P, P, B) patch np.transpose(patch, (2, 0, 1)) # (B, P, P) label int(self.gt[r, c]) - 1 # 标签从 0 开始 return torch.from_numpy(patch).float(), labelcoords在__init__里一次性算好避免每次__getitem__都扫一遍标签图。modereflect比零填充更平滑边缘样本不会引入突兀的暗带。标签减 1 是因为很多数据集的背景是 0、类别从 1 开始而 PyTorch 的CrossEntropyLoss要求类别索引从 0 起。这几行看着琐碎但每一处都是踩过坑之后加上的。2.3 DataLoader 的参数怎么调才不浪费 GPUDataset写好只是第一步真正决定吞吐的是DataLoader的num_workers、batch_size、pin_memory、persistent_workers这几个参数。我的经验是num_workers从 4 起步按 CPU 核数的 1/2 到 2/3 调pin_memoryTrue配合.to(device, non_blockingTrue)能把 H2D 拷贝和计算重叠persistent_workersTrue避免每个 epoch 重建进程池对样本数多的数据集提升明显。from torch.utils.data import DataLoader loader DataLoader( dataset, batch_size64, shuffleTrue, num_workers8, pin_memoryTrue, persistent_workersTrue, prefetch_factor4, # 每个 worker 预取的 batch 数 drop_lastTrue, )prefetch_factor只在num_workers 0时生效调大能让 worker 提前准备更多 batch但太大会吃内存。drop_lastTrue是为了避免最后一个不满的 batch 干扰 BatchNorm 的统计样本量不大时也可以关掉。这套参数在单卡 24 GB 显存、patch 11×11、200 波段的场景下基本能把 GPU 利用率拉到 70% 以上剩下的瓶颈通常在磁盘 IO 或 Python 侧的预处理。3. 跑起来环境、数据组织与训练循环3.1 环境依赖与最小可运行清单项目依赖不复杂核心就四样torch、numpy、scipy读.mat、scikit-learn划分训练/测试集和算指标。如果数据是.tif再加rasterio或tifffile。Python 版本建议 3.9 以上PyTorch 用官方对应 CUDA 版本的安装命令即可不需要额外编译。pip install torch torchvision numpy scipy scikit-learn # 若数据为 GeoTIFF再补一个 pip install tifffile rasterio装完之后先跑一个最小验证读一个立方体、构造Dataset、取一个样本确认形状和标签都对再进训练。这一步能挡掉八成「跑不起来」的问题比直接开训然后看报错高效得多。cube, gt load_cube(data/sample.mat) ds HyperSpectralPatchDataset(cube, gt, patch_size11) x, y ds[0] print(x.shape, x.dtype, y) # 期望 (B, 11, 11) float32 与 int3.2 数据目录怎么摆划分怎么做高光谱项目最容易乱的地方是数据组织。我一般按「一个数据集一个目录目录下放立方体文件、标签文件、划分索引」来摆data/ indian/ cube.mat gt.mat split.json # 训练/验证/测试像素坐标划分索引单独存成 JSON 而不是每次随机生成是为了保证多次实验可比。高光谱数据样本量小随机种子一变结果就飘固定划分是复现的前提。划分时按类别分层采样每类取固定比例做训练剩下的做测试避免小类别在训练集里一个样本都没有。import json from sklearn.model_selection import train_test_split coords np.argwhere(gt ! 0) labels gt[coords[:, 0], coords[:, 1]] tr, te train_test_split( np.arange(len(coords)), test_size0.8, stratifylabels, random_state42, ) split {train: coords[tr].tolist(), test: coords[te].tolist()} json.dump(split, open(data/indian/split.json, w))stratifylabels是关键保证每个类别在训练和测试里的比例一致。random_state固定下来后面换模型、调超参时才有对照意义。3.3 训练循环里和 DataLoader 相关的几个细节训练循环本身是标准写法但有几处和DataLoader配合的细节值得单独说。一是non_blockingTrue必须和pin_memoryTrue成对出现才有效二是每个 epoch 结束后如果发现 GPU 利用率周期性掉到 0多半是 worker 在等磁盘考虑把立方体预加载成np.memmap或换 SSD三是验证集不要用shuffleTrue否则指标会有轻微抖动。device torch.device(cuda if torch.cuda.is_available() else cpu) model YourNet(num_bandscube.shape[-1], num_classesint(gt.max())).to(device) opt torch.optim.Adam(model.parameters(), lr1e-3) crit torch.nn.CrossEntropyLoss() for epoch in range(100): model.train() for x, y in loader: x x.to(device, non_blockingTrue) y y.to(device, non_blockingTrue) opt.zero_grad() loss crit(model(x), y) loss.backward() opt.step()num_bands从数据里动态取别写死换数据集时少改一处。num_classes用gt.max()推前提是标签连续且从 1 开始如果标签有跳号得先做一次重映射否则CrossEntropyLoss会因为索引越界报错。4. 避坑与排查那些让训练卡住或结果发飘的问题4.1 现象GPU 利用率个位数训练极慢原因通常是数据预处理全压在主进程或者num_workers0。高光谱 patch 采样涉及 padding 和转置单进程做这些时 GPU 全程空转。解决办法是把num_workers调到 4 以上并确认__getitem__里没有不可序列化的对象比如打开的文件句柄否则多进程会静默退化成单进程。排查时在__getitem__里打印进程 ID看是否真的分到了多个 worker。4.2 现象报RuntimeError: DataLoader worker exited unexpectedly这是 worker 进程崩了最常见的原因是内存不够被系统杀掉或者__getitem__里抛了异常但被吞掉。高光谱 patch 如果patch_size设得大、num_workers又多每个 worker 都持有一份立方体副本内存会成倍增长。解决方式是让 worker 共享只读数据用np.memmap或在__init__里只存路径、在__getitem__里读并适当降低num_workers。定位时先把num_workers设成 0 跑一遍异常会直接抛在主进程堆栈看得清楚。4.3 现象loss 不降或者准确率在训练集上很高、测试集一塌糊涂先查标签对齐。patch 采样时坐标是(r, c)但 numpy 数组索引是[行, 列]如果读入时做过转置而标签图没同步转样本和标签就错位了。再查归一化高光谱不同波段量纲差异大训练前按波段做标准化减均值除标准差几乎是必须的而且统计量只能从训练集算不能把测试集混进去。这两处任一出错都会表现为「模型在学但学的是错的东西」。4.4 现象换一台机器结果对不上除了随机种子还要固定num_workers和persistent_workers因为多进程下的数据增强如果用了全局随机状态不同 worker 数的采样顺序会不同。更稳妥的做法是把所有随机性收敛到torch.Generator或numpy.random.Generator实例上按 worker ID 设种子。另外cudnn.benchmarkTrue会让不同输入尺寸下的卷积算法选择不同追求严格复现时把它关掉。5. 二次开发把管道改造成你自己的数据形态拿到这套骨架后真正要动的通常只有三处数据读取、采样策略、增强。数据读取层如果你的数据是.tif把load_cube换成tifffile.imread即可返回形状同样是(H, W, B)下游不用改如果是逐像素的(N, B)矩阵就跳过 patch 逻辑直接写一个返回(B,)的DatasetDataLoader部分原样复用。采样策略上类别极不平衡是高光谱的常态小类别往往只有几十个像素。我一般会在__init__里算每个类别的样本数给WeightedRandomSampler传权重让稀有类别被采到的概率提高。注意这时shuffle要设成False两者不能同时用。from torch.utils.data import WeightedRandomSampler labels np.array([int(gt[r, c]) - 1 for r, c in ds.coords]) counts np.bincount(labels) weights 1.0 / counts[labels] sampler WeightedRandomSampler(weights, num_sampleslen(weights), replacementTrue) loader DataLoader(ds, batch_size64, samplersampler, num_workers8)增强方面高光谱不能照搬图像那套水平翻转加旋转因为波段维是有物理顺序的翻转空间维可以打乱波段顺序就毁了光谱曲线。安全的增强包括空间随机裁剪、小角度旋转、加高斯噪声、随机波段丢弃模拟传感器缺失。我习惯把增强写成可组合的 transform 列表在__getitem__末尾统一应用这样换增强不用改采样逻辑。验证改造是否成功别只看最终准确率。我会在训练前先跑一个「过拟合小批量」测试取 32 个样本关掉增强训练到 loss 接近 0如果能做到说明管道和标签没问题剩下的才是模型和超参的事。这个习惯帮我省下过大量排查时间——有次准确率死活上不去就是靠这一步发现标签整体偏移了一位。从那以后我每次接新数据集都强制先走一遍小批量过拟合再开正式训练。希望帮到你。本文还有配套的精品资源点击获取
