PAL puts more than a dozen infrared small target networks on one training switch

The design goal is one switch between supervision regimes

The project describes its own purpose as building an efficient and stable bridge between fully supervised training and point supervised training for infrared small target detection. The mechanism for that is deliberately narrow, and the README states it plainly: the project fully supports both conventional fully supervised training and PAL point supervised training, and switching between multiple networks and multiple datasets takes a change of one parameter. That is the whole thesis of the codebase, and it is a different thesis from proposing a new detection architecture. The paper behind it, From Easy to Hard, is a progressive active learning framework, accepted at ICCV 2025, with an arXiv identifier of 2412.11154. The authors are from the Shenyang Institute of Automation at the Chinese Academy of Sciences, the University of Chinese Academy of Sciences, Tsinghua, Nankai and MMLab at the Chinese University of Hong Kong, and the primary language of the repository is Python with a badge indicating Python 3.8 and newer.

Three label forms define the supervision axis

The label forms are the variable that makes this a study of supervision cost rather than of architecture. Three are supported: Full supervision, Coarse single-point supervision and Centroid single-point supervision. The distinction between the two point forms is the interesting one, because they encode the same budget differently. A coarse point marks the target region rather than a single pixel, while a centroid point marks the centre of the target, which means the difference between them is how much shape information the label carries. The evaluation script names mirror the same split, with CNN Full, CNN Coarse and CNN Centroid denoting CNN based methods under the three regimes, and the comparison presented in the repository is on the SIRST3 dataset. The third-party scripts at the top level reflect the same care about measurement, with cal_PD_and_Fa.py for probability of detection and false alarm rate and cal_mIoU_and_nIoU.py for the two intersection over union variants.

More than ten detection networks are integrated behind one interface

The integration list is long and it is the main practical reason to use this repository rather than a single paper implementation. The networks named in the README are ACM, ALCNet, MLCL-Net, ALCL-Net, AGPCNet, DNANet, GGL-Net, UIUNet, HDNet, ISNet, SCTransNet, SFDTNet, GSFANet, MMLNet, MSHNet, SDSNet, LR-Net and MSDA-Net, which is more than the ten the description claims, with new ones still being added. The news section records that four methods were adapted in August 2026, GSFANet, MMLNet, MSHNet and SDSNet, and that LR-Net was adapted in the same month with credit to Jinmiao Zhao, and that five more were added in July 2026, AGPCNet, HDNet, ISNet, SCTransNet and SFDTNet. The project explicitly invites contributions and states that more networks and functions can be integrated later, and the July 2026 entry says the project continues to support more networks and welcomes pull requests for integrating yours. The repository layout follows that structure, with a model/ directory for the network definitions and a components/ directory for shared building blocks.

Four datasets cover the usual infrared small target benchmarks

The datasets are the four that the field uses most, which is what makes cross network comparison meaningful. They are SIRST, NUDT-SIRST, IRSTD-1k and SIRST3, and the SIRST3 dataset is the one used for the main comparison shown in the repository. Having all four under one harness matters more than it might appear, because a detection network's reported accuracy moves with the partition and the metric, and comparing two papers means trusting that they used the same one. The main results figure is captioned as a comparison of different methods on SIRST3, with the three supervision regimes shown side by side for CNN based methods, which is exactly the figure that makes the supervision comparison legible. The evaluation scripts at the top level, cal_mIoU_and_nIoU.py in particular, suggest the project treats the choice of IoU variant as something the user must make, since nIoU and mIoU give different numbers for small targets and a small target is a few pixels across.

Training and evaluation are separate scripts with shared utilities

The top level of the repository is a small set of Python entry points rather than a package with a CLI. There is train_model.py and test_model.py, the two metric calculation scripts, and utilts.py, whose name is misspelled in the repository, which holds shared helpers. The loss/ directory holds the loss functions, the mm/ directory the metric module, tools/ the helper scripts, and model/ and components/ the networks and their shared parts. A researcher picking this up should note what is not in the tree, because there is no requirements.txt, no environment file and no install command, so the environment has to be assembled by matching the paper's setup, and the README does not document a rollback or a version pinning scheme. The releases are minimal, with v2.0 on 2026-08-23 and v1.0 on 2026-07-18, and the default branch is main. The last push was on 2026-09-04, so the tree is being worked on, and the repository is not archived.

The licence is the first thing to settle before you build on it

The licence field in the repository metadata is recorded as unknown, and the README carries an Apache 2.0 licence badge whose link points nowhere rather than at a file, while other licence badges in the same block are commented out. That is ambiguous rather than permissive, and the difference matters for a research codebase that other groups intend to extend. The README asks people to contribute their own networks by pull request, which is an invitation to build a shared codebase, and a shared codebase with an unstated licence is a poor foundation for that. The paper itself is on arXiv under an open preprint, and the project page is hosted at the author's GitHub pages site, so the intellectual content is readable either way. Before integrating a method here into anything you publish or ship, read the LICENSE file directly and, if it is ambiguous, ask. The alternative to resolving the question is to use the method's own upstream repository, which every one of the integrated networks has, and to treat PAL as a comparison harness rather than as a source you depend on.

Where PAL is the wrong choice

Three situations argue against it. The first is a project that needs a maintained dependency, because this is a paper artefact with no environment specification, no requirements file and a Python 3.8 era target, and the CUDA generation implied by the spconv style dependencies in this area does not match a current machine. A research codebase that you pin will age badly, and the point of PAL is that it absorbs new networks over time rather than that it stays stable. The second is a domain outside infrared small target detection, because the active learning schedule and the label forms are tied to the characteristics of that specific task, where the targets are a few pixels across in a large background, and the point supervision assumption is doing real work that would not transfer. The third is a team that needs a training pipeline with reproducible splits and metrics computed the way their field computes them, because the metric scripts here are the authors' choices and the two IoU variants exist precisely because there is no single agreed measure for small targets. The realistic alternative is to take the specific method you are interested in from its own repository, implement the supervision regime you need, and use PAL as a reference for how the comparison should be set up rather than as the code you run.

Editorial conclusion

Adopt PAL when you are working on infrared small target detection and want to compare architectures under full, coarse point and centroid point supervision on SIRST, NUDT-SIRST, IRSTD-1k or SIRST3, and pick a single detection model to build on. Skip it if you need maintained production code, since the licence is not stated in the repository metadata and the environment is pinned to an older Python and CUDA generation. Verify first which network and label form the released configuration selects, and check the loss and metric scripts, since the evaluation numbers depend on the choice between the two IoU variants.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. YuChuang1205/PAL on GitHub