Notes from the buildThree posts · 28 August 2026
Notes from the build
Short posts about how Nitsor works. Each one is built on a number we measured on real scans, not a claim we would like to make. Where a value is an example rather than a measurement, the post says so on the line.
- 01
Why the scan never leaves your bucket
Most labelling tools ask you to upload the scans first. Nitsor reads them where they already are, a few hundred kilobytes at a time. The arithmetic, what we keep instead of a copy, and what the arrangement costs you.
Me 163 · z 160 - 02
What a label diff in millimetres looks like
A folder called final_v3 does not tell you what changed. On one real CT slice, moving every boundary out by a single pixel changes the labelled area by 14 per cent. That is the size of the thing people argue about.
Me 163 · z 192 - 03
How we picked a mark that survives 32 pixels
We drew six logos and shrank them to the size of a browser tab. Two lost their shape, two only worked in more than one colour, and the one we started with kept the job. All six are on the page at both sizes.
M04 · the mark
What goes in here
One post per thing we had to work out, written the week we worked it out. If a post gives you a number, the number was measured on files you can download, and the note at the bottom says which file and when.
The scans in these posts are two published datasets: a computed-tomography scan of a Me 163 airframe from Fraunhofer EZRT (doi:10.5281/zenodo.10651746) and a prostate MRI series from The Cancer Imaging Archive (doi:10.7937/K9/TCIA.2018.MR1CKGND). Both are CC BY 4.0. We have no customer logos to show you yet, so we show the data instead.
Who writes it
The people building it. The team is small enough that the person who wrote the code is the person writing the post. There is no marketing team to route it through.
If a post is wrong, tell us and we will fix it and say what we changed. Contact reaches a person.