duxingchen/WQ_GUI
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
249 Commits 4 Branches 0 Tags
a572b52239525e558faba249bea767f4164a1cf0
Commit Graph

54 Commits

Author SHA1 Message Date
duxin
a572b52239 fix: formula report reads distribution maps from 12_visualization/distribution_maps/ instead of 11_Thematic_Map 2026-07-09 14:49:36 +08:00
duxin
5fe71917a6 fix: hyperspectral images section - skip missing instead of showing placeholder text, fix flight path rglob scope 2026-07-09 14:47:44 +08:00
duxin
f99fa63f0e fix: remove duplicate hyperspectral images and conflicting generic sections from formula report 2026-07-09 14:45:53 +08:00
duxin
8a7273dd57 fix: 公式报告进度步数用实际脉冲数而非原始数据量 (87→30) 
旧: total_steps = 4 + 63 + 20 = 87 (但大部分步骤不发脉冲)
新: total_steps = 4 + 63//10 + 20 = 30 (与 _next 调用次数一致)
 2026-07-09 13:27:47 +08:00
duxin
dd04ee323c fix: ML 报告进度增加 on_progress 回调 + 两条报告逻辑审查确认 
ML 报告: 参数循环中加入 on_progress 回调,
  终端显示 ML报告 参数 3/13: Chlorophyll

审查结论:
  公式报告 (_generate_formula_report):
    数据源: 10_WaterIndex_CSV + 11_Thematic_Map + 1_water_mask
    不含 ML 内容 (无 scatter/boxplot/heatmap/R²/RMSE)
    进度: 数据驱动 (N_csv + N_maps + 4 固定)

  ML 报告 (_generate_ml_report):
    数据源: 12_visualization + 5_Data_Cleaning + 9_Concentration
    完整 ML 流程 (统计表→热力图→浓度→逐参数图表→总结)
    进度: 图片数 + 参数数 + 2
 2026-07-09 13:26:09 +08:00
duxin
836c322b10 fix: 公式报告进度数据驱动 — 按实际 CSV/专题图数量计算总步数 
旧: total_steps=7 硬编码, 看不到实际数据处理进度
新: 启动时扫描 10_WaterIndex_CSV 和 11_Thematic_Map,
  总步数 = 4(固定章节) + N_csv + N_maps,
  每处理 10% CSV 和每张专题图均更新进度,
  终端显示 统计 7/63 / 专题图 3/20 等实时信息
 2026-07-09 13:21:32 +08:00
duxin
b88bab57ee fix: 公式报告 4 项修复 — 通用章节+AI接口+图片路径+标题数字 
修复一: _generate_formula_report 封面后恢复
  _add_company_description_page/doc
  _add_data_acquisition_section/doc
  _add_data_processing_section/doc

修复二: _call_minimax_text / _call_minimax_vision
  URL 自动补齐 /chat/completions 后缀

修复三: _call_minimax_vision
  MIME 类型动态检测 (.png→image/png, 其他→image/jpeg)

修复四: _add_hyperspectral_images_section
  航线图搜索: 多路径 + rglob 递归查找
  去掉所有硬编码编号 (3.1/图3-2/3-3/3-4/3-5/3-6)
 2026-07-09 13:12:14 +08:00
duxin
fc6036efb7 fix: _add_hyperspectral_images_section 去掉多余的 start_figure_num 参数 2026-07-09 11:53:23 +08:00
duxin
43d56e74d9 fix: _add_cover_page 参数对齐 + 确认 _generate_formula_report 无 ML 混入 2026-07-09 11:42:32 +08:00
duxin
650e505ac4 feat: 报告生成模块双轨制重构 — 公式模式 + ML 模式独立分流 
**UI (step13_report_panel.py):**
  - 新增 QComboBox 报告模式选择:
    机器学习(ml) / 水色指数公式(formula)
  - WorkerThread 传递 report_mode 到 generate_report

**后端 (report_word.py):**
  - generate_report(report_mode='ml'/'formula') 参数路由
  - _generate_formula_report(): 水色指数专属结构
    1.项目背景 → 2.影像预处理 → 3.公式列表 →
    4.指数统计(10_WaterIndex_CSV) → 5.分布专题图(11_Thematic_Map)
    绝不包含模型训练/R²/RMSE 等 ML 内容
  - _generate_ml_report(): 原有 ML 逻辑完整保留
  - _analyze_statistics(): 全部改用 .get() 防御式读取
    兼容 参数/Parameter/name, 点位数/数量/count,
    最小值/min, 最大值/max, 平均值/mean, 标准差/std
 2026-07-09 11:33:50 +08:00
duxin
692a88c7bb fix: heatmap_path 提前声明避免水色指数模式下 UnboundLocalError 2026-07-09 11:22:50 +08:00
duxin
1740425152 fix: 报告水色指数模式 stats_data 补全缺失的统计字段 
水色指数模式 stats_data 只复制了 参数/点位数,
  缺少 最小值/最大值/平均值/标准差 →
  _analyze_statistics 访问时 KeyError: '最小值'
 2026-07-09 11:17:54 +08:00
duxin
303f202547 fix: read_csv_data 含量列动态识别 — 排除所有坐标列名 
问题: CSV 格式 [proj_x, proj_y, longitude, latitude, BGA_Am09KBBI],
  旧逻辑 coord_cols={proj_x,proj_y} 只排除识别的坐标列,
  longitude 被错误提取为含量列 → Kriging 用坐标值插值

修复: 扩展排除集合包含全部已知坐标列名:
  proj_x/proj_y, longitude/latitude, x/y, lon/lat,
  x_coord/y_coord, pixel_x/pixel_y, geometry, uncertainty
  兜底取最后一列
 2026-07-09 09:56:03 +08:00
duxin
1d051c9fec feat: 报告生成器自动检测水色指数模式 — 支持非 ML 管线 
问题: 报告模板仅适配 ML 管线 (steps 5-9+13),
  用户跑 1,2,3,4,10,11,12 (水色指数公式管线) 时大量显示
  [图片未找到]。

修复: 自动模式检测 + 分支逻辑

  1. _detect_pipeline_mode(): 检测 scatter_with_confidence 文件
     不存在 → 水色指数模式

  2. _get_available_image_types(): 扫描实际存在的图片类型,
     只报告确实生成的内容

  3. 统计表格: ML→5_Data_Cleaning, 水色指数→10_WaterIndex_CSV
     水色指数模式遍历所有公式 CSV 生成统计汇总表

  4. 相关性热力图: 水色指数模式跳过并注明原因

  5. 分布图: 利用已有 fallback 从 11_Thematic_Map 读取
 2026-07-09 09:31:58 +08:00
duxin
830589c108 fix: 智能坐标列检测 — proj_x/proj_y 优先 + 双列名输出 
问题: CSV 中 UTM 米坐标被命名为 longitude/latitude,
  列名与实际内容不符, 容易引发 CRS 配置错误。

修复:

1. map.py read_csv_data: 优先级智能列检测
   proj_x/proj_y → longitude/latitude → lon/lat → x_coord/y_coord
   → 终极回退按位置[0][1]。新旧文件全部兼容。

2. csv_processor.py: 输出双列名
   proj_x + proj_y (新标准, 优先)
   longitude + latitude (旧标准, 兼容)
   值完全相同, 新旧代码都能正确读取
 2026-07-08 16:50:20 +08:00
duxin
f996353b37 fix: 克里金矩阵鲁棒性 — 去重重叠点 + nugget 防奇异化 
问题: 4326 点仍崩溃回退 IDW，原因两个:
  1. 采样点中存在空间完全重叠点 → 协方差矩阵行列式为 0
  2. 坐标范围出现负数 (X=-793275) → 经/纬度传反，空间距离扭曲

修复:
  1. read_csv_data: drop_duplicates(subset=['proj_x','proj_y'])
     坐标 <0.01m 的重叠点只保留首个，防止矩阵奇异化
  2. OrdinaryKriging (2处): nugget=1e-6
     微小固有方差强制打破矩阵奇异性，病态矩阵仍可求逆
 2026-07-08 16:29:33 +08:00
duxin
757741c6a9 fix: 掩膜改用 rasterio.features.rasterize 全分辨率 C 级光栅化 
问题: 降采样+np.kron 暴力放大的旧逻辑导致出图边缘出现
  14×14 像素马赛克锯齿。

修复: 彻底删除 _MASK_TARGET_POINTS/_mask_step/shapely.prepared/
  np.kron 升采样链，替换为 rasterio C 底层光栅化:
  - from_bounds 精确计算仿射矩阵
  - rasterize(shapes, out_shape, transform) C 级瞬间盖章
  - flipud 处理 Y 轴对齐
  - 输出 uint8 bool 掩膜, 无降采样无锯齿
 2026-07-08 15:02:30 +08:00
duxin
e0c6b63446 perf: shapely.prepared.prep 加速掩膜空间查询 — 22亿次测试秒级完成 
问题: mask_gdf.within(boundary_gdf.unary_union) 对 5.3万点 × 4.1万
  复杂多边形的暴力相交测试，计算量高达 22 亿次，单核假死。

修复: 使用 shapely.prepared.prep 预编译几何体:
  - union_poly = boundary_gdf.unary_union (执行一次)
  - prepared_poly = prep(union_poly) (预编译为 C 级空间索引)
  - [prepared_poly.contains(Point(x,y)) for ...] (加速 100×+)

  同时省去 GeoDataFrame 构造开销，直接用 numpy mask_pts
  迭代生成 Point 对象并查询。
 2026-07-08 14:35:11 +08:00
duxin
b8f0625bd9 fix: 掩膜降采样计算 — 杜绝 1m 分辨率下 10.5M Point 对象 OOM/假死 
真凶定位: prepare_shared_context 第 2982-2988 行
  grid_xx.ravel() → 10.5M 坐标点
  [Point(x,y) for ...] → 创建 10.5M 个 shapely Point (~2 GB)
  within(boundary.unary_union) → 10.5M 次几何测试 O(N×M)
  → 此处假死/卡死/内存爆炸，Kriging 从未开始执行

修复: 掩膜降采样到 ~50K 点 (约 100m 等效分辨率) 计算,
  结果通过 np.kron 升采样回原始分辨率。
  掩膜是布尔值，精度损失可忽略；
  np.kron 的 C 向量化升采样 <1 秒。
 2026-07-08 14:22:34 +08:00
duxin
9512cab807 fix: 移除 _local_kriging 内部 multiprocessing.Pool 避免 Windows 嵌套 spawn 死锁 
根因: step11 用 ProcessPoolExecutor 派发 CSV 到子进程，
  子进程内 ContentMapper.process_data → _local_kriging 又创建
  multiprocessing.Pool。Windows spawn 模式下嵌套 Pool 死锁。

修复: _local_kriging 内部改为顺序执行 16 个块。
  每块 ~12s (650K 网格点 × 50 近邻), 总计 ~3 分钟, 完全可接受。
  step11 层的 ProcessPoolExecutor 仍提供 CSV 级并行。
 2026-07-08 14:09:54 +08:00
duxin
4469d6462d fix: 修复 _local_krige_block 单块调用时参数未 unpack 的 bug 2026-07-08 14:01:29 +08:00
duxin
237fcba647 perf: 自适应分块 + 40% 重叠缓冲 + n_closest=50 优化局部克里金 
用户需求: 500m 固定分块(50块)容易碎片化, 稀疏区域易受异常值污染

修复 (3项):

1. 自适应块大小: 根据 extent 自动切分为 ~4×4 块(16块),
   纵横比极端时自动在长边增加 1 块。
   每块面积足够大, 囊括更多采样点特征。

2. 40% 重叠缓冲区: 采样点搜索范围为块长宽的 1.4×,
   相邻块交界处使用极度重叠的采样点 → 消除拼缝断层。
   网格点(grid_x/y)仍使用严格不重叠块范围 → 无冗余计算。

3. n_closest_points=50: 50 个近邻稀释极端异常值影响,
   比之前 15 个更稳健, 且协方差矩阵 50×50 仍远小于全局 8242×8242。
 2026-07-08 14:00:59 +08:00
duxin
7fbc613ded fix: 局部 Kriging 网格范围使用缓冲区导致 10x 冗余计算卡死 
问题: sub_grid_x/y 使用了缓冲区范围 (block+500m) 而非块范围,
  导致每个 500m 块的网格点从 ~457x460 膨胀到 ~1500x1500 (9x),
  50 个块合计需计算 1.12 亿次 kriging, 任务构建阶段就卡死。

修复: sub_grid_x/y 改为仅使用块自身范围,
  缓冲区仅用于筛选局部采样点。
  每个网格点只计算一次, 总计算量 = 实际网格点数 (10.5M)。
 2026-07-08 13:14:40 +08:00
duxin
bdac7873f4 fix: 修复 ContentMapper 类体被模块级函数截断的严重 bug 
问题: 批量生成专题图时报 'ContentMapper' object has no attribute 'process_data'

根因: _local_krige_block_worker (0空格缩进,模块级) 被错误地插入在
  ContentMapper 类体中间 (line 819), 导致类定义在此处终止。
  之后 19 个方法 (_idw_interpolation, read_csv_data, create_content_map,
  visualize_raster, prepare_shared_context, process_data, process_batch...)
  全部脱离类变成模块级函数。
  AST 验证: ContentMapper 仅剩 9 个方法。

修复: 将 _local_krige_block_worker 移至文件末尾 (模块级正确位置),
  ContentMapper 恢复为 28 个方法的完整类。
 2026-07-08 13:02:03 +08:00
duxin
8f03dcb10b perf: Local Kriging 500m spatial window + multiprocessing 
Local Kriging: grid split into 500m blocks, each block uses only
sample points within block+buffer zone. Covariance matrix shrinks
from 8242x8242 to local nxn. 10M+ grid cells now finish in minutes.

Complexity:
  Global: O(G * P * logP * K^3) = hours for large grids
  Local:  O(sum(block*grid * block*points * 15^3)) = minutes
 2026-07-08 12:03:46 +08:00
duxin
e0b9257b56 perf: Kriging 多进程分块 + C 后端自动检测 — 1m 分辨率千层级网格加速 
问题: 用户需要 1m 分辨率 (2285×4600 = 1051万网格点)，
  单进程 loop 后端需要数小时。

修复 (三层加速):

1. C 后端自动检测 (_detect_kriging_backend):
   - 检测 pykrige 是否有编译的 C 扩展 (conda-forge 默认有)
   - 可用时 C 后端比 loop 快 50-100×
   - 不可用时回退 loop + 多进程补偿

2. 多进程分块 (_krige_chunked):
   - 网格 >100 万点时自动启用
   - 沿 Y 轴将网格拆分为 N 个 stripe (N=CPU核数,上限8)
   - 每个 worker 独立运行 OrdinaryKriging.execute()
   - 结果沿 Y 轴 vstack 拼接

3. 进度可见:
   - 每个 worker 启动时打印 '[Krige Worker] 分块 X/N'
   - 完成后立即打印完成消息
   - 主进程打印拼接结果维度

预期性能 (8核, C后端, 1051万网格点):
  单进程 loop: ~3-5 小时
  8进程 + C: ~1-3 分钟 (loop后端 ~15-30 分钟)
 2026-07-08 11:34:14 +08:00
duxin
212772caf4 fix: Kriging 大网格自动拦截 — 防止百万级网格点导致无限卡死 
问题: 用户将 step11 分辨率设为 1m，生成 2285×4600 = 1051万
  网格点。pykrige OrdinaryKriging.execute() 在此规模上需要数小时，
  且期间无任何进度输出，看起来像程序卡死。

根因: 原代码对网格规模无上限约束。

修复 (create_interpolation_grid):
  - 推荐上限: 500K 网格点 (~30-120s)
  - 绝对上限: 2000K 网格点 (超出直接抛错，建议提升分辨率)
  - 超推荐上限时自动按比例提升分辨率: 2285×4600 → ~505×1016
  - 打印明确的网格点数统计和 ETA 提示
  - 网格自动缩减后日志: '调整后网格: N×M = X 个网格点'
 2026-07-08 11:28:25 +08:00
duxin
796d36c093 fix: 修复 TIF 缺失 CRS 时 fallback 到 WGS84 导致掩膜擦除全部像元的 bug 
问题: step11 日志反复出现:
  '栅格 TIF 缺失坐标系，默认按 WGS84 渲染'
  '擦除后有效像元: 0/15300'

根因: step10 生成的 GeoTIFF 缺少 CRS (可能是 PROJ 异常时生成的)。
  visualize_raster 中当 crs_obj 为 None 时无条件回退到 EPSG:4326 (WGS84),
  但 transform 实际是 UTM 米坐标 (e.g. x≈470000, y≈2200000)。
  UTM 度坐标的掩膜被 reproject 到 WGS84 后,
  与仍在 UTM 米坐标的 transform 彻底错位 → geometry_mask 全部为 False
  → 0 个有效像元。

修复: 当 crs_obj 为 None 且 boundary 有投影 CRS 时,
  检查 transform 的 X 坐标量级: 若 >180 则必定是投影坐标 (UTM 等),
  直接使用 boundary 的 CRS 而非 WGS84 回退。
  仅当坐标量级 <180 时才回退到 WGS84 (真经纬度)。
 2026-07-07 16:51:33 +08:00
duxin
c46f78e69d fix: 补齐缺失的 handler 文件 + IDW 插值退化检测 + V1 代码归档 2026-07-06 15:57:29 +08:00
duxin
385e5915af 格式统一 2026-07-01 17:33:52 +08:00
duxin
8de73db80e 格式统一 2026-07-01 11:32:32 +08:00
duxin
a3c20d3e49 格式统一 2026-07-01 09:57:27 +08:00
DXC
429ed3c1c1 测试修改 2026-06-25 18:11:50 +08:00
DXC
d327c6c267 fix(report_word): Minimax v2 接口兼容 + 缓存防毒化自愈 2026-06-25 16:45:50 +08:00
DXC
43f50ec07b 测试修改 2026-06-25 15:50:02 +08:00
DXC
e907e73810 测试修改 2026-06-23 15:26:55 +08:00
DXC
b8d263e494 测试修改 2026-06-23 14:39:54 +08:00
DXC
c4aa246c95 fix(viz_reports): plot_scatter_true_vs_pred 指标文本框移到图例下方 2026-06-23 08:41:40 +08:00
DXC
5a5109b1a6 fix(viz_reports): plot_scatter_true_vs_pred NaN 容错 + subplots_adjust 替换 tight_layout 2026-06-22 17:48:03 +08:00
DXC
e8820a73c1 fix(viz_reports): plot_spectrum_by_parameter legend 移出画布防止遮挡 2026-06-22 17:16:10 +08:00
DXC
561c59fbd4 fix(scatter_legend): 基础版散点图 legend 移出画布防止遮挡 
src/postprocessing/visualization_reports.py plot_scatter_true_vs_pred:

ax.legend 加 bbox_to_anchor=(1.02, 1) + borderaxespad=0，将图例移到画布右侧外部。

已有 plt.tight_layout() 与 plt.savefig(..., bbox_inches='tight') 自动处理裁剪。

Why: loc='upper left' 时图例位于散点区左上角，训练/测试点集中时易被遮挡。

仅改基础版（plot_scatter_true_vs_pred），增强版 sctter_batch.py 是 gridspec 4x4

子图布局，硬套 bbox_to_anchor 会破坏右侧 ax_hist_y 子图，保留原样。
 2026-06-22 16:37:11 +08:00
DXC
027981e9a6 ContentMapper 边界读取支持栅格水掩膜（.dat/.bsq/.tif/.tiff/.img） 2026-06-16 15:15:10 +08:00
DXC
82e0b92af6 Mega-1.1 全链路路径归一化收尾（18 文件） 2026-06-15 15:20:50 +08:00
DXC
184f5fe9f4 fix(step14): 批量渲染文件名唯一性 + Colorbar 样式 + 2σ拉伸 2026-06-11 10:29:32 +08:00
DXC
0493ba7916 fix(map): GeoTIFF 可视化全链路修复 2026-06-10 17:13:51 +08:00
DXC
fa9c940074 feat(visualization+report): 接入 Step9 浓度反演数据至可视化面板与报告生成器 2026-06-10 09:41:39 +08:00
DXC
e57fdb4f75 feat(report): 支持 Minimax AI 后端 + 统一 AI 配置对话框，修复 figure_counter 返回值断链 Bug 2026-06-08 14:58:16 +08:00
DXC
2a4a7ec7be refactor(packaging): PyInstaller资源路径统一适配get_resource_path 2026-05-10 18:02:59 +08:00
DXC
95d30d8d81 修复训练摘要报告无法识别 .joblib 模型的 Bug 2026-05-10 15:45:56 +08:00
DXC
375fea77b9 修复后处理模块导包路径断层 2026-05-10 15:24:50 +08:00