ISAT ships a plugin system proven by two hundred line examples and a citation stuck at 1.33

Two plugin examples, given as line counts

A plugin system arrived in one version, and the way it was introduced is better evidence than a documentation page.

The news entry says the tool can be extended with a small amount of code, and then names two official examples with their sizes. One is an auto-annotation plugin built on a detection model, described as implemented in two hundred and forty lines. The other is a mask export plugin, in one hundred and sixty.

So the whole extension surface is demonstrated in four hundred lines of working code, split across two very different jobs: calling a model to pre-label, and exporting the result.

Publishing the line count is a genuinely useful thing to do. Most plugin systems are announced with an architecture diagram; a reader who needs to know whether they can write the plugin they want cannot use a diagram, but they can use a number.

The export plugin being that small is also the more interesting of the two, because export is where the real interop lives. A four hundred label workflow that emits the expected exchange format is what turns a viewer into a dataset tool.

The citation block names version 1.33 and has not moved since February 2025

There is a citation block at the bottom of the README, and it is out of date in a way that matters.

It gives two named authors, a year, a note recording when it was last updated, and a version. The version is one point three three, not one point three something. The note date is early 2025.

The releases listed on the same page go to one point five point two, and three of them shipped after that note date, the last of them at the end of 2025.

So the citation a reader copies points at a build two minor versions behind the current one, and its update note predates three releases. Anyone who pastes it is citing code they are not running.

The authorship is worth noting too. The citation names two people by name, while the repository is under a different handle and the packaging file credits that handle instead. Those may well be the same people, and nothing visible settles it.

None of that is unusual for a research tool. It is simply the one place in the repository where a stale copy gets propagated rather than regenerated.

Dependencies are written down twice, and three carry a floor

The packaging file and the requirements file declare the same two dozen packages, in a different order, and both have to be maintained.

That is two sources of truth for the same list. Nothing in the build reconciles them, so a package added to one is invisible to the other until someone installs and hits a missing import.

The pinning style is worth separating out. Three packages carry a lower bound: the deep learning framework, the configuration library, and the progress bar. Everything else has no constraint at all, including the GUI toolkit, the imaging library, the geometry library and the dataset toolkit.

So the tool requires a specific-enough framework to run but says nothing about the twenty others. In practice that means an install resolves to whatever is current for most of the stack, which for an application with a graphical interface is a real source of breakage: a major release of a GUI or imaging library will not be caught at install time.

The packaging file does contain one telling comment. It explains that the dependency list must be named directly, because otherwise the package will not install them. That is a hard-won note about installer behaviour, and it explains why the duplication exists at all.

A medical imaging reader is required and never mentioned

One entry in the dependency list has no counterpart anywhere in the visible documentation.

The tool requires a library for reading DICOM, which is the standard format for medical images. That means it can open medical image series, not just photographs.

Nothing on the README mentions it. The feature list talks about image segmentation annotation in general, the news entries are all about prompting and plugins, and the documentation index linked from the page does not surface it either.

There are two plausible explanations. Either it is an undocumented capability that nobody has written down, which would be a shame because DICOM input is exactly the kind of thing a clinical or imaging researcher would want to know about. Or it is a transitive requirement of something else in the stack that was hoisted into the direct list, which happens when a dependency is added to satisfy an import rather than a feature.

Either way the manifest is the only place the answer exists, and the fact that it is there at all suggests the capability is real rather than vestigial.

The newest features are announced but not shown

The two most recent version announcements describe prompting, and in the text of the page neither one is demonstrated.

The later release added visual prompting on top of the third generation of the segmentation model. The release before it added that model plus text prompting.

Both entries wrap their examples in expandable blocks, and what those blocks contained was images. In the plain text of the page the visual prompting example is empty. The text prompting example has headings for single category and for multiple categories, and nothing under either of them.

So a reader gets told that text prompting exists, gets told it works differently for one category and several, and gets no example of either.

The surrounding structure suggests the content was there as screenshots, which is a reasonable choice for a visual tool and a poor one for a feature whose distinction is a matter of interface states. The details block under the page's table of contents has the same problem, and so do the dark and light theme screenshots in the project description.

For a tool whose main argument is that it is fast to annotate with, the documentation is the part that most needs the pictures, and the pictures are exactly what a text reader loses.

Three releases in two weeks, then nine months without one

The release history is short and the gap after it is long.

Three releases are visible, clustered inside two weeks at the end of 2025: a minor version and two patches, one a week apart. That is the cadence of a feature push, and it fits the changelog, since the minor release is the one that added a model generation and text prompting.

The most recent push to the default branch is at the end of September 2026. So roughly nine months of commits have produced no tagged release, and the feature that would most obviously justify a version, visual prompting on the newest model, shipped at the end of 2025 and has not been cut as a release.

The news section does say to look at the releases page for other versions, which suggests the visible three are a sample rather than the whole list. If so, the page is not lying, only stale.

For an installer this matters less than for a library, because the packaged version comes from a package index rather than a tag. For anyone tracking the source, it means there is no way to ask what shipped when.

The repository builds Windows executables as well as a package

The distribution shape explains why the repository name and the package name differ.

The project directory is named after the model it wraps, with a long descriptive name. What you install is two short words. The command it installs is the same two words.

The root contains a build script and a specification file for producing a self-contained Windows executable, plus a directory of icons and a directory for a container image. So there are at least three delivery routes: the package index, a Windows binary, and a container.

That is a lot of surface for a desktop tool whose core is a graphical interface, and it explains the build script sitting at the root rather than in a scripts directory.

It also means the thing you install on Windows may not be the thing on the package index, and neither is versioned by a tag in this repository.

The documented install is one command after the optional environment step:

pip install isat-sam

The package manifest derives its version by reading it out of the package's own init file, and raises an error naming that file if it is missing, so the version travels with the source rather than with a tag.

Editorial conclusion

Use this if you are labelling segmentation data and want a promptable model doing the tedious part under human review, because the semi-automatic framing is the right one for datasets where every mask gets checked anyway. Two things to fix on your side. Declare the dependencies once rather than trusting the packaged install, since the manifest and the requirements file duplicate each other and only three packages carry a floor. And if you cite the tool, cite the version you actually used rather than copying the block in the README, which names a build two minor versions behind the one you would download.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. yatengLG/ISAT_with_segment_anything on GitHub