Entry 02 · the imaging lab
Notebook: The Imaging Lab
Walked through 22 September 2026every figure re-taken live, times in UTC~1,200 words
Say the important thing first, because the whole entry depends on it. The Rx.Luxury imaging lab is a viewer. It displays a scan. It does not read one.
There is no classifier in it, no segmentation, no finding detection, no report generation and nothing that offers an opinion about what is in the picture. It windows pixels, pages through slices, prints the header and lets you save what is on the board. Everything below is written on that understanding, and any sentence that sounded like the software was looking at your scan on your behalf has been taken out of this entry.
- 1The limit is the standfirst, not a footnote:
Uncompressed DICOM renders here. Compressed JPEG/JPEG2000 is metadata only.
- 2The keyboard map, printed on the empty drop zone where a beginner will read it.
- 3Four presets. I read their numbers out of the source rather than guessing them.
- 4Free window centre and window width, plus a slice slider that only has a range once a stack is in.
- 5Five ways out, all local: PNG, JPEG, PDF, every slice as a ZIP, and the printer.
The controls, and whether they are what they say
The four presets are the standard radiology windows and the source carries the numbers: brain is centre 40 / width 80, bone 400 / 1800, lung −600 / 1500, soft tissue 40 / 400. Those are the right values, which is worth saying, because a preset row is the easiest place in a viewer to put plausible nonsense.
The keyboard map printed on the drop zone reads: W / L nudge window · arrows change slice · 0 reset · I invert
and, on the second line, scroll to zoom, shift-scroll for slices, drag to pan, alt-drag or right-drag for window/level. I did not take that on trust either. The handler in js/dicom.js binds exactly those keys, and the reset really is the digit zero rather than the letter O — an easy thing to mistype into a help line and a genuinely annoying thing to get wrong.
It is also incomplete. Holding shift reverses both W and L, so shift-W narrows the window and shift-L drops the level. The printed map does not mention it. A user who only reads the drop zone has half the window control the software actually gives them, and the half they are missing is the half you need constantly.
The phantom is the right answer to an obvious problem
Most people who open a DICOM viewer out of curiosity do not have a DICOM file. The lab solves this by synthesising one: a button marked Load MRI phantom builds a Shepp–Logan head — the standard ten-ellipse tomography test object — in the browser, with no download and no sample study to host.
I clicked it and the heads-up display read MR 256×256 slice 9/16 W/L 824/412. Sixteen slices, a real stack, with the slice slider live and the series panel listing T1-weighted phantom. Every control on the page has something to act on within one click of arriving. The card underneath then tells you how to look at what you are looking at: bright ovals are higher signal, dark ovals are lower.
- 1The HUD states modality, matrix, slice position and the window you are reading at.
- 2The phantom itself — ten ellipses, generated in the page, not downloaded.
- 3A real sixteen-slice series, so the slice slider and the arrow keys have something to do.
- 4A reading card that explains the display, and stops there. It describes signal, not findings.
The guard nobody asks for
When a loaded file still carries a patient name or ID in its header, a warning bar appears above the controls: This file is identified. Patient name or ID is present in the header. Prefer a de-identified teaching study.
The check is a short function that inspects the two tags and deliberately stays quiet for the phantom, so the demonstration does not cry wolf.
Think about what that means in the situation it is built for: someone drops their own MRI on a laptop, gets a picture, and screenshots it to send to a family member. The software warns them that their name is in the file before they do it. Nothing obliges a hobby viewer to think that far ahead.
What will not open
Compressed transfer syntaxes render as metadata only. The check matches every transfer syntax UID beginning 1.2.840.10008.1.2.4 — the whole JPEG, JPEG-LS and JPEG 2000 family — plus 1.2.840.10008.1.2.5 for RLE, and returns the header with no pixels.
Be blunt about the size of that. A large share of what a real hospital burns to a disc or exports from a PACS is compressed, so a reader who brings their own study stands a fair chance of getting a table of tags and a blank canvas. The mitigation is genuine — the lab accepts PNG, JPEG and WebP as well, and the standfirst tells you to export a PNG from your PACS before you try — but it is a mitigation, not a fix, and a PNG from a PACS has already had its window baked in, which is the one thing this tool exists to let you change.
What I could not test: a real, identified, multi-frame clinical study. I have no patient data and would not put it through a browser to write a review. So this entry describes the phantom path, the code path, and the printed limits — not the behaviour of the lab against a full CT series, which remains unverified here.
Verdict, such as a notebook gives one
This is the most serious piece of software in the health room and the one most likely to be described wrongly, including by its own owner’s shorthand. It is a competent window/level workstation that runs with no upload, no account and no server, where the file is read through FileReader and never leaves the machine, and where the two things a naive build would get wrong — the preset numbers and the compressed-syntax trap — are both handled and both disclosed.
It also does exactly nothing to help you understand what is in your scan, and it says so. That is not a gap in the product. That is the product refusing to be something it has no business being, which in this particular corner of software is the rarest feature on offer.