ECA-LDNet: Training and Evaluation Artifacts

This repository provides the code snapshots, model checkpoints, evaluation records, and supporting outputs for an engineering characterization of ECA-LDNet, a single-image dehazing network. It is organized so readers can move from aggregate results to per-image records, run metadata, and the relevant source code.

ECA-LDNet is a depthwise-separable U-Net with Efficient Channel Attention (ECA), pixel-attention blocks, and a low-weight atmospheric-scattering-inspired correction branch. The reported model has 1,481,871 parameters and 2.171 GMAC / 4.343 GFLOPs at 256 × 256. Its atmospheric-light-like and transmission-like predictions are not physically calibrated estimates.

The experiments characterize outputs from fixed checkpoints under selected evaluation settings. They do not establish a new attention operator, state-of-the-art performance, deployment readiness, or a causal contribution for each network component.

Result overview

• Using the observed hazy image in the ASM correction branch on the reused grouped validation split of 2,066 pairs, blend 0.08 with ε = 0.1 gave the highest tested mean PSNR; at fixed blend 0.08, ε = 0.2 gave the highest tested mean SSIM.
• In five-fold selection over all 45 O-HAZE pairs, every fold selected blend 0.20 and ε = 0.01. The pooled out-of-fold change against 0.08 / 0.1 was +0.686 dB PSNR and +0.0171 SSIM.

These are inference-time recombinations of fixed checkpoint outputs. The validation sweep reused the checkpoint-selection split, O-HAZE had been evaluated previously, and nested selections reached tested grid boundaries. Interpret them as sensitivity results for the evaluated checkpoints and settings, not evidence of a transferable optimum or an isolated synthetic-to-real domain effect.

Start here

If you want to…	Open…
See aggregate evaluation results	Results/Requested Evaluation via Reviewer Feedback/Overall Summary/
Inspect per-image scores and their run records	Results/Requested Evaluation via Reviewer Feedback/Paired Evaluations/
Review training histories and checkpoint metadata	Results/Full Model Training/
Review ablation training histories and settings	Results/Ablations/
Inspect blend/epsilon sweeps, nested O-HAZE analyses, or method comparisons	Results/Interference/
Run the standalone reviewer evaluation	reviewer_test_package/REVIEWER_TEST_PACKAGE_README.md
Find source-specific setup and run instructions	The README.md files under code/

Repository map

Evaluation results

• Results/Requested Evaluation via Reviewer Feedback/ — Main evaluation bundle. Start with Overall Summary/Overall Summary.csv for the combined summary or Overall Summary/Per_Model_Dataset_Summary.csv for model-by-dataset values. Dataset-specific I-HAZE and NH-HAZE summaries are under Overall Summary/Model Summary/. The Paired Evaluations/256 X 256/ and Paired Evaluations/512 X 512/ trees contain records by model, dataset, and seed. Each evaluation directory typically includes paired_per_image.csv, paired_summary.csv, and paired_run_manifest.json. The same bundle contains the blend sweep, training-history plots, and selected qualitative figures.
• Results/Full Model Training/ — Training artifacts for seeds 17, 43, and 73. Each seed contains stage 1–4 histories, stage manifests, checkpoints, and split metadata. training_history_report/stage_history_summary.csv and its plots provide a compact view across stages. Read the folder's README.md for checkpoint curation and stage completion details.
• Results/Ablations/ — Training histories and run_config.json files for eca_only, no_attention, no_eca, and no_physics, under seeds 17, 43, and 73. These are training records; model weights and split manifests are not included in this folder. The folder's README.md describes the contents.
• Results/Interference/ — Additional inference analyses and comparisons. Important subfolders are:
  • asm_epsilon_sweep_results/ — Per-image and aggregate sweep results with run manifests for each seed.
  • nested_ohaze_blend_epsilon_cv/ and nested_ohaze_epsilon_selection/ — Fold assignments, fold-level settings and scores, out-of-fold records, bootstrap summaries, and run manifests for nested O-HAZE selection analyses.
  • full_release_real_haze_perceptual_eval/ — Full-release I-HAZE and NH-HAZE evaluation records across the available train, validation, and test partitions, including pair inventories, per-image records, summaries, and selected prediction examples. These are evaluation outputs; the source benchmark images are not bundled.
  • paired_dcp_identity_baseline/, frozen_edformer_comparison/, and three_seed_uniform_ensemble/ — Per-image scores, paired comparisons, dataset summaries, and bootstrap summaries for the named analyses. Comparison conditions and limitations are recorded in each run_manifest.json.
  • ohaze_inference_cost_profile/ — Raw timings, summaries, and the run manifest for the inference-cost profile.

Results/Interference/ is the exact directory name used in this release. Run-level manifests are the most direct source for the checkpoint, dataset, settings, and code context behind a result. Use this README and the manifests beside each run to navigate and inspect the current release.

Code and reviewer package

• code/full_training_source/ — Full-model implementation, training and evaluation scripts, notebooks, and environment/run guides. Start with its README.md, then choose the laptop or Kaggle guide for the intended environment.
• code/ablation_revision_source/ — Revised ablation implementation, scripts, tests, run guides, and revision evidence. Start with its README.md and the applicable laptop or Kaggle guide.
• code/reviewer_evaluator_snapshot/ — Snapshot of the evaluator implementation used for review-oriented evaluation.
• reviewer_test_package/ — Standalone evaluation package with 15 Stage 4 best checkpoints, code, split and configuration metadata, requirements, and a Kaggle notebook. package_manifest.json records package files and checkpoint hashes. Begin with REVIEWER_TEST_PACKAGE_README.md; REVIEWER_TEST_COVERAGE.md describes what the test package covers.

Reading the result files

For the main paired evaluation records, the directory structure is:

Results/Requested Evaluation via Reviewer Feedback/Paired Evaluations/
├── 256 X 256/<model-and-seed>/<dataset>/
└── 512 X 512/<model-and-seed>/<dataset>/

Within a run directory, use:

• paired_per_image.csv for the image-level metrics and paired values used in aggregate calculations.
• paired_summary.csv for the run's compact metric summary.
• paired_run_manifest.json for run configuration and provenance.

For training, histories are stored with their seed and stage under Results/Full Model Training/; checkpoints are under each stage's models/ directory. Ablation histories and settings are under Results/Ablations/<seed>/<variant>/. Sensitivity analyses and method comparisons follow the same general pattern: per-image rows, summaries, and a nearby run manifest. Read the corresponding manifest before comparing results across directories, because datasets, resolutions, checkpoints, or comparison procedures can differ.

The published score tables are convenient entry points, while the per-image files are the appropriate place to inspect sample-level values or independently recalculate means and paired differences. Preserve image identifiers and pairing when doing so.

Bootstrap interval endpoints and reproducibility

Bootstrap point estimates and interval endpoints have different reproducibility requirements. A mean computed from a fixed set of per-image values is determined by those values. A bootstrap interval also depends on the resampling procedure, row order, random-number generator, seed, and quantile calculation. Consequently, matching means do not by themselves verify exact interval endpoints.

For the current supplementary result references:

• S3: The reported mean contrasts match the saved per-image records. The supplement specifies 10,000 paired-image resamples and percentile 95% intervals, but the original RNG seed is not preserved, so the exact original endpoints cannot be verified.
• S8: The reported mean contrasts match. The supplement specifies 10,000 pair-level resamples, percentile 95% intervals, and NumPy default_rng seeds 20261038, 20261064, and 20261094 for model seeds 17, 43, and 73. A replay using the saved rows and sorted image identifiers comes close but does not reproduce every endpoint exactly; the original row order or implementation detail is not fully captured.
• S6: The paired 256 × 256 versus 512 × 512 intervals match a regeneration from the paired per-image records using 5,000 resamples and the documented RNG seed 42.

For a reproducible regeneration, publish a small provenance record alongside the regenerated interval table. It should state:

1. The exact input file paths and SHA-256 hashes.
2. The deterministic row order, using a stable image or pair identifier; for paired comparisons, keep both observations for a sampled unit together.
3. The bootstrap unit (for example, image, pair, or image cluster) and the statistic resampled.
4. The random seed, RNG algorithm, and software/package versions.
5. The number of resamples, confidence level, and quantile method used for interval endpoints.
6. The script or notebook version used to produce the outputs.
7. The resampling indices or bootstrap replicate statistics, if practical, so the published endpoints can be checked without relying on RNG implementation details.

For S3, a newly selected seed can produce a reproducible regenerated interval, but it cannot recover or verify the original endpoints. Label it as a regenerated result and retain the currently reported values for traceability. For S8, retain the reported seeds, sort rows by a stable image identifier before resampling, and record the exact implementation; label any changed endpoints as regenerated until they reproduce the published values. For S6, replay the documented seed and compare regenerated endpoints with the archived values. In every case, publish regenerated tables and provenance as a clearly named, versioned output; do not silently overwrite existing endpoints. If regenerated values are adopted in a later release, identify the change and its provenance in the release notes and associated reporting.

Reproducing and running the code

Raw benchmark images are not included. Obtain each dataset from its provider and follow the dataset layout, preprocessing, dependency, and command instructions in the relevant source README or reviewer package guide. The source folders include laptop and/or Kaggle run guides where available. The reviewer package includes its own requirements.txt and reviewer_kaggle_test.ipynb for the packaged evaluation workflow.

The training artifacts and evaluation outputs are supplied for inspection and analysis; their presence does not imply that a fresh run will be bit-for-bit identical across hardware, framework, or library versions. Check each run manifest and source guide before launching a run. Respect the licenses and access terms of the datasets, pretrained weights, and code; the code snapshots include their own license files where applicable.

Scope and interpretation

• The primary evaluation includes SOTS-Indoor and SOTS-Outdoor (500 pairs each at 256 × 256), O-HAZE (45 pairs at native resolution), and five-pair test subsets from I-HAZE and NH-HAZE (256 × 256). Additional analyses include the 1,000-pair RESIDE-6K-Test partition, all 55 Dense-Haze release pairs, and full-release I-HAZE/NH-HAZE partitions. Dense-Haze results pool development/training, validation, and challenge-test images; they are not an official challenge-test score. I-HAZE and NH-HAZE test partitions each contain five pairs.
• The validation blend sweep reuses the grouped checkpoint-selection split. O-HAZE had also been evaluated previously, and nested selections reached tested grid boundaries. These analyses describe sensitivity for the evaluated checkpoints and grids; they do not establish a transferable global optimum.
• Ablation variants used a 40-epoch screening schedule, while the full model used a planned 140-epoch schedule. The screens do not estimate full-budget component effects and should not be interpreted as controlled causal evidence that a component improves performance.
• Cross-method comparisons involve different training data or pipelines and do not establish a controlled ranking.
• The batch-one timing profile used sequential calls on a Kaggle runtime with two Tesla T4 GPUs visible: 2.94 images/s at 256 × 256 and 2.90 images/s at 512 × 512. These measurements describe that runtime and exclude checkpoint loading, output serialization, metric computation, concurrent requests, and controlled cold-storage reads; they do not establish deployment performance.