How yangyang12318/lgcn works
1. What this repository is
- This is a PyTorch-based research codebase for self-supervised real SAR despeckling using a Local–Global Collaborative Network (LGCN).
- The repo is organized around a classic deep-learning pipeline: dataset loading → model/network construction → training/validation/inference.
2. Primary execution entry points
- train/train_all.py is the main training driver.
- validate/validate.py is the evaluation/validation entry point.
- submit_test/test.py is a separate inference/testing path, likely for generating final outputs or submission-style results.
- train_all.sh is the shell wrapper for launching training with the expected environment and config.
3. Configuration boundary
- option/all.json centralizes run-time settings such as dataset paths, model choices, and training hyperparameters.
- utils/option.py likely parses and exposes those settings to the rest of the codebase.
- This indicates the repo is config-driven, with the JSON file acting as the main control plane for experiments.
4. Dataset subsystem
- dataset/base.py is the shared dataset abstraction.
- dataset/SAR_sRGB.py is a concrete dataset/preprocessing module for SAR-related data, likely handling the conversion or pairing between SAR and displayable formats.
- dataset/__init__.py exposes dataset classes so the training code can instantiate them without depending on file-level details.
- The data boundary is external: the README points to GF-3, TerraSAR-X, Sentinel-1, and a PolSAR land-cover classification dataset as input sources.
5. Network subsystem
- network/all.py and network/__init__.py suggest the actual LGCN architecture is implemented here and exported as a package.
- This layer is where the paper-specific building blocks live: the local branch, global branch, and their collaborative fusion.
- In architectural terms, this package is the pure forward-pass / layer-definition layer, separate from training logic.
6. Model subsystem
- model/base.py and model/all.py likely wrap the network with training-oriented behavior: loss computation, optimization hooks, checkpoint handling, and experiment-level orchestration.
- This separation implies a clean split between:
- network = architecture definition
- model = how that architecture is trained/evaluated
- model/__init__.py exposes the chosen model implementation to the training scripts.
7. Utility layer
- utils/build.py likely constructs datasets, models, and other components from the config.
- utils/io.py probably handles filesystem concerns such as saving logs, checkpoints, and results.
- utils/option.py manages option parsing/loading.
- These utilities form the glue between configuration, data, and runtime execution.
8. Training data flow
- Training begins in train/train_all.py, which reads configuration, builds the dataset and model, then launches optimization.
- Data flows from the dataset package into the model/network stack through PyTorch dataloading and batching.
- Checkpoints and logs are likely emitted through utils/io.py, while experiment parameters come from option/all.json.
9. Validation and test flow
- validate/validate.py uses the trained model to run evaluation on held-out data, likely computing despeckling quality metrics and/or saving predicted outputs.
- submit_test/test.py appears to be a lightweight inference path, separated from validation so test-time generation can be run independently.
- This suggests the repo distinguishes model assessment from final inference/export.
10. Project boundaries and runtime
- The repo is a standalone research training/inference project, not a service or web application.
- Its main external dependency is PyTorch on Python 3.9.5 with CUDA-enabled execution.
- The architectural boundary is clear: raw SAR datasets in, trained despeckling model, then denoised outputs / validation metrics out.
11. What to show in an architecture diagram
- A useful diagram should show:
- external SAR datasets feeding into dataset/*
- config from option/all.json into utils/option.py
- train/validate/submit_test as separate entry points
- utils/build.py assembling components
- model/* wrapping network/*
- outputs to checkpoints, logs, and inference results
- The key internal distinction is between data handling, network definition, and experiment orchestration.
Main entry points: train_all.py Train · dataset/__init__.py Dataset API · model/__init__.py Model API · build.py Builder
Components 19
Entry points
Run commands for training, validation, and test-time inference
Config
Experiment settings and option loading
- Run config · Central experiment configuration
option/all.json - Option load · Loads and exposes runtime options
utils/option.py
Data subsystem
Dataset abstractions and SAR preprocessing
- Dataset base · Shared dataset interface
dataset/base.py - SAR data · SAR-specific loading and preprocessing
dataset/SAR_sRGB.py - Dataset API · Dataset package entry
dataset/__init__.py - SAR sources · Input datasets such as GF-3, TerraSAR-X, Sentinel-1
Core model
Network definition and training-oriented wrapping
- LGCN net · Local-global collaborative despeckling network
network/all.py - Network API · Network package entry
network/__init__.py - Model base · Model-level training and evaluation hooks
model/base.py - Model impl · Concrete model orchestration
model/all.py - Model API · Model package entry
model/__init__.py
Runtime utils
Build, option, and IO helpers
Outputs
Artifacts produced by training and inference
- Checkpoints · Saved training state and logs
- Results · Validation metrics and inference outputs
Connections 29
- Launcher → Train: launches · Shell wrapper starts the main trainer
- Run config → Option load: loaded by · Configuration file is parsed into runtime options
- Option load → Builder: drives · Parsed options control component construction
- Train → Option load: reads · Training entry point loads experiment options
- Validate → Option load: reads · Validation entry point loads experiment options
- Test → Option load: reads · Test entry point loads experiment options
- Train → Builder: builds · Training assembles data and model through builder
- Validate → Builder: builds · Validation reuses builder for loaded model and data
- Test → Builder: builds · Inference path constructs needed runtime components
- Builder → Dataset API: creates · Builder instantiates datasets through the package API
- Builder → Model API: creates · Builder instantiates the selected model implementation
- Dataset API → Dataset base: extends · Package exports shared dataset abstraction
- Dataset API → SAR data: exports · Package exposes SAR dataset implementation
- SAR data → SAR sources: consumes · Dataset implementation reads external SAR inputs
- Train → Dataset API: trains on · Training consumes batched dataset samples
- Validate → Dataset API: evaluates on · Validation consumes held-out dataset samples
- Test → Dataset API: infers on · Test path consumes dataset samples for output generation
- Model API → Model base: wraps · Model package exposes training-oriented base behavior
- Model API → Model impl: exports · Package exposes the concrete model implementation
- Model impl → Network API: uses · Model implementation depends on network definitions
- Network API → LGCN net: exports · Network package exposes LGCN architecture
- Train → Model API: optimizes · Training runs optimization over the model
- Validate → Model API: scores · Validation uses the model for evaluation
- Test → Model API: runs · Inference uses the model to generate outputs
- Train → IO utils: writes · Training emits logs and checkpoints through IO utilities
- Validate → IO utils: writes · Validation stores metrics and predictions through IO utilities
- Test → IO utils: writes · Inference stores generated results through IO utilities
- IO utils → Checkpoints: saves · IO utilities persist training artifacts
- IO utils → Results: saves · IO utilities persist outputs and metrics