PID_Symbol_Detection: Why P&ID Symbol Extraction Works Better as Detect, Then Compare
A two-stage pipeline uses sliced inference to find tiny symbols on huge drawings, then few-shot learning to label them without needing massive class-specific datasets.
- The repo’s real insight is that symbol recognition becomes much more tractable when geometry detection and identity matching are separated.
- Class-agnostic detection helps the system survive class imbalance and drawing-style drift, which are common in industrial documents.
- Sliced inference is not a performance detail here, it is what keeps tiny symbols from disappearing on oversized P&ID sheets.
- Few-shot label transfer makes the pipeline usable when every plant or vendor legend introduces new symbols with limited annotation data.
P&IDs are a brutal vision problem. The drawings are enormous, the symbols are tiny, and the same symbol can look different across vendors, plants, and decades of drafting habits. That is why PID_Symbol_Detection is interesting: it does not try to solve everything with one model.
Instead, it turns the task into a practical judgment call. First, detect anything that looks like a symbol. Then compare that crop against a small set of known examples and assign the closest label. That split is the whole story.
The real problem: tiny symbols on giant drawings
P&ID sheets do not behave like ordinary photos. They are dense technical artifacts with long line segments, overlapping annotations, and symbols that may be only a few dozen pixels wide once a full page is resized. A standard detector that looks fine on benchmark images can fail immediately when the page is large and the objects are small.
The repo’s architecture starts from that constraint, not from a generic object detection benchmark. It assumes the hardest part is preserving small visual evidence long enough to make a decision.
Why the repo refuses the one-model approach
The project uses a class-agnostic first stage, then a few-shot second stage. That choice matters because industrial drawings rarely give you balanced training data. Some symbols are common, some appear only a handful of times, and new symbol sets often arrive before you have time to relabel everything.
Class-Agnostic Object Detection & One-shot Label Transfer is found to be more: 1. Generalizable to different underlying P&ID drawing styles 2. Robust to class-imbalance compared to equivalent class-aware counterparts.
| Approach | Data need | Strength | Weakness |
|---|---|---|---|
| Single-stage class-aware detector | Many labeled examples per class | Simple inference | Breaks on rare symbols and style drift |
| Per-site retraining | Fresh labels for every symbol set | Can fit one drawing standard well | Hard to maintain across vendors and plants |
| Detect then compare | Few examples plus prototype labels | More flexible and more robust to imbalance | Adds a second stage and more compute |
How the pipeline actually works
The repository is organized around a clean pipeline. Stage 1 finds candidate symbol regions with a class-agnostic detector. Stage 2 embeds those crops and compares them to prototype examples, often using a Siamese or triplet-style representation learned to keep similar symbols close together in vector space.
python src/run_pipeline.py stage1 --config configs/pid.yaml
python src/run_pipeline.py stage2 --config configs/pid.yaml
python src/run_pipeline.py inference --input data/raw/sample.pdf --config configs/pid.yamlThat CLI shape mirrors the architecture. The codebase keeps configuration, folder creation, patch handling, and inference orchestration separate, which makes the pipeline easier to reproduce and easier to swap stage-specific models into.
The small-object trick that keeps symbols from vanishing
This is where the repo leans on patch generation and sliced inference. Large drawings are broken into overlapping tiles, then detections are merged back together. Without overlap, a symbol that crosses a tile edge can get clipped into two weak predictions or missed altogether.
That matters more than it sounds. On P&IDs, the object of interest is often smaller than the spacing of the text and linework around it. If you shrink the whole page and hope the detector notices, the page wins.
Why few-shot label transfer is the quiet superpower
The second stage is what makes the system feel industrial instead of academic. Rather than requiring a giant curated class list, it learns embeddings that can be compared against a prototype bank. A new symbol class can be represented with only a few examples, which is much closer to how real engineering teams work.
That is the quiet advantage of the repo. It is not just detecting objects. It is building a path from a detected shape to a usable label, even when the label set is thin, messy, or incomplete.
| Question | Answer in a class-aware detector | Answer in PID_Symbol_Detection |
|---|---|---|
| How many examples do I need? | A lot per class | A few per class |
| What if the drawing style changes? | Often requires retraining | Prototype matching can adapt more easily |
| What if one class is rare? | Accuracy usually suffers | Geometry detection stays class-agnostic |
| What if I need a new symbol type? | Expand the classifier and retrain | Add prototypes and support examples |
What the architecture buys you, and what it costs
The upside is flexibility. Class imbalance hurts less. Drawing styles can vary more. New symbols can be introduced without rebuilding the whole system from scratch. For a domain where each plant or contractor may have its own visual dialect, that is a real advantage.
The cost is complexity. You now depend on the first stage to catch candidates reliably, and you pay for a second pass that compares embeddings to prototypes. If Stage 1 misses the symbol, Stage 2 never gets a chance. That is the tradeoff the repo makes on purpose.
How it compares to simpler P&ID detection repos
| Project | Core idea | Best at | Main limitation |
|---|---|---|---|
| PID_Symbol_Detection | Detect first, compare second | Generalizing across styles and small data | More moving parts |
| p-id-symbols | YOLO-based symbol extraction | Straightforward object detection | Relies on class-specific training |
| P_ID-Symbol-Objectdetection | Fine-tuned SSD MobileNet v2 | Targeted symbol detection for known classes | Less flexible for new symbol sets |
That comparison is the real takeaway. Some repos are better at one fixed legend. This one is trying to survive the messiness of real drawings, where the legend is the problem, not just the labels.
Why this matters beyond one repo
This project sits in a larger shift from document storage to document understanding. The goal is not just to find symbols. It is to turn legacy engineering sheets into structured, machine-readable assets that can support search, QA, and eventually digital twin workflows.
That makes PID_Symbol_Detection more than a detector. It is a practical pattern for industrial digitization: use geometry to find the thing, then use a small learned memory to name it.
