DSCNet: a convolution kernel that learns to follow a vessel

The problem is that a square kernel cannot see a curve

The paper's title states the problem: dynamic snake convolution based on topological geometric constraints for tubular structure segmentation. The README's background section describes why tubular structures are hard, pointing to their thin and fragile local structural features and their complex and variable global morphological characteristics. The method itself has two parts. A multi-view feature fusion strategy handles feature extraction and feature fusion, and a continuity topology-constrained loss constrains the output. The inspiration is Deformable Convolution, and the authors are explicit about why they went that way, namely so the model can dynamically adapt the shape of its convolution kernel while learning features, allowing it to concentrate on the structural attributes of tubular formations. The audience is medical imaging and remote sensing researchers who need precise vessel or road masks, and who care about continuity as much as per-pixel accuracy.

The learning problem the authors had to fix first

There is a detail in the motivation section that explains why the constraint is not optional. The authors say that during their initial experiments they observed that, because tubular structures make up a relatively small proportion of the image, the model tends to lose its perception of those specific structures, and as a result the convolution kernel deviates significantly from its intended focus. So the failure mode of a plain deformable convolution here is not that it cannot bend, it is that nothing holds it in place, and the optimisation drifts away from the structures the kernel was supposed to be tracking. The snake formulation is the answer to that, because the kernel is tied to a coordinate frame that follows the structure. The README also includes a visualisation of the whole process during training, recorded after every two epochs, showing the kernel gradually adapting to the vessel, which is the clearest available evidence of what the constraint does in practice.

Four code directories, and they are not interchangeable

The repository layout is the quickest way to understand what you can actually run. There are four top level directories. DSCNet_2D_opensource/ is the original 2D implementation, and DSCNet_3D_opensource/ is the 3D version, which the news section says was refactored from the ground up and optimised with the help of fellow researchers, with the current version tested and showing what the authors call excellent stability. NPU_DSCNet/ holds the open-sourced NPU versions of the operators, described as optimised implementations for NPU acceleration aimed at improving performance and deployment efficiency on NPU-enabled hardware, with the note that this is separate from the reference implementations and intended for deployment on that kind of hardware. There is also a Fig/ directory holding the figures used in the README, including the training visualisation. The main branch is the default, the licence is MIT, and the last push was on 2026-05-29.

The optimized 2D path, and what the README claims about speed

One of the news items is worth pulling out because it changes how you would use the 2D code. The authors say they have already released an optimised version of the dynamic snake convolution, which reuses established algorithm libraries and refines parts of the logic further, and they point at a specific location in the repository for it, the DRIVE code directory. The performance claim attached to it is specific: training on the entire DRIVE dataset on a machine with similar specifications to the 4090 takes less than 4 minutes for 400 epochs, attributed to a combination of algorithmic acceleration strategies. That is a training-time figure on one dataset and one hardware class, so it should be read as evidence that the implementation is no longer the bottleneck, not as a general performance promise. The authors also uploaded two Tensorboard files to help observe the training process results, which is a small thing that saves a lot of time when you are trying to reproduce a run.

The paper's own argument for why specialised models still matter

The Thinking section of the README is the most unusual part of it, because it is the authors making a case rather than describing a method. They ask whether the next research direction should involve creating even larger models, or whether it should build on what came before and explore fine-tuning large models for specific domains. They acknowledge that models like SAM and the Universal Model, along with numerous other segmentation foundation models, now give satisfactory results on many tasks through direct testing or straightforward fine-tuning. Their answer is that there are still complex domains where foundation models have not provided comprehensive coverage, and that this may only be a matter of time, with examples given as camouflaged targets, non-prominent targets, and the distinctive tubular structures the paper focuses on, which they characterise as low prevalence with faint and widely dispersed features. They also argue that extending segmentation to 3D or even 4D data makes structures like blood vessels and airways significantly harder for large models, and that in clinical contexts where even a 1 percent error can be critically dangerous for diagnosis, specialised models remain indispensable.

A dataset is coming, and a project page exists

Two more items from the news section bear on whether this repository is a place to build. The first is the dataset. The authors say they are dedicated to collecting, annotating and open-sourcing the largest dataset of pan-tubular structures, including over 10,000 images, with both instance-level and binary-level annotations, and that they aim to release it by the end of the year. That is a promise rather than a released artefact, so anyone planning experiments on this method should treat the data as pending. The second is the project page, which the authors say they updated to visualise results, and the Chinese translation of the paper, which they have updated as well. The paper itself is on arXiv at 2308.14383 and was accepted by ICCV 2023, and the authors ask that users cite it.

Where DSCNet is the wrong choice

There are two clear cases. The first is general segmentation. The snake constraint is a cost paid for a specific geometry, and if your targets are blobs, text or ordinary objects, a standard convolution is both simpler and likely to be at least as accurate, so importing the deformation machinery buys you nothing. The second is production use. This is a paper implementation with four directories that partly overlap, a dataset that has not been released, an optimisation claim attached to one specific directory, and a note in the README that the code will be gradually and continuously opened, which tells you the release was incremental. There is no pip package, no versioned API and no maintenance guarantee. The alternative worth naming is a general segmentation model such as the one from Segment Anything, fine-tuned on your data, which the authors themselves argue is the right comparison for many tasks, and for tubular structures the realistic alternative is a purpose-built approach such as a topology-aware loss applied on top of a standard network, which gets you much of the benefit of the snake constraint without rewriting the operator. The honest summary is that DSCNet is a paper you can run, not a dependency you can adopt.

Editorial conclusion

Adopt DSCNet if you are segmenting thin tubular structures such as retinal vessels, roads or airways, where a square kernel loses the shape of the target, and if you are comfortable working with a research code release. Do not adopt it as a general segmentation backbone, since the deformation constraints are specific to elongated targets, and the repository is a paper implementation rather than a packaged library. Verify first which of the four code directories matches your case, the 2D, the 3D, the NPU operator set or the optimized DRIVE version, and expect to read the paper alongside the code.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. YaoleiQi/DSCNet on GitHub