Technical walkthrough 03 · Medical-imaging software
PulseImaging desktop viewer
An Electron application that validates DICOM hierarchy, loads a CT series into a cached volume, and renders linked axial, sagittal, and coronal views for segmentation work.
The real viewer, rendered without patient data
A medical-imaging screenshot is useful evidence only if it does not expose protected data. I ran the current frontend against a generated 96-slice DICOM phantom containing no patient source, then opened the application’s actual MPR mode.
bed6b1d, rendered with a generated,
non-clinical 96-slice CT fixture. The image verifies the product
surface and three-plane volume path. It is not an employer
screenshot, clinical example, segmentation result, or latency
benchmark.
The screenshot exposes the actual interaction model: series navigation at left, viewport tools and MPR selection above the canvas, linked orthographic views in the center, and artery labels and calcium-scoring state at right.
One series crosses five explicit boundaries
| Boundary | Validation or transformation |
|---|---|
| DICOM import | Validate study → series → instance hierarchy and retain ordering metadata. |
| API contract | Return series metadata, image count, ordered image URLs, and patient data separately. |
| Client cache | Load and cache every DICOM image in bounded batches before volume construction. |
| Volume viewports | Attach one cached volume to axial, sagittal, and coronal orthographic viewports. |
| Segmentation | Attach the same labelmap to each active viewport and persist edited slices. |
A stack viewer can request slices lazily. MPR needs a coherent three-dimensional volume, so the client loads the complete ordered series before creating the volume and exposing orthogonal planes.
The publishable test fixture encodes volume geometry explicitly
The employer repository is not publicly accessible, so this page does not republish its implementation. The product behavior can still be tested safely: the fixture writes the position, orientation, spacing, pixel representation, and windowing fields needed to build a real DICOM volume, while marking every patient field as synthetic.
dataset.PatientName = "SYNTHETIC^QA"
dataset.PatientID = "NON-CLINICAL"
dataset.SeriesDescription = "Synthetic cardiac CT - portfolio QA fixture"
dataset.ImagePositionPatient = [0, 0, float(z * 1.25)]
dataset.ImageOrientationPatient = [1, 0, 0, 0, 1, 0]
dataset.SliceThickness = 1.25
dataset.PixelSpacing = [0.7, 0.7]
dataset.BitsAllocated = 16
dataset.PixelRepresentation = 1
dataset.WindowCenter = 40
dataset.WindowWidth = 400The phantom varies along z so MPR reveals orientation errors
A stack of identical circles would make the axial view look plausible while producing uninformative slabs in the other planes. The fixture tapers the body and organs across 96 positions, so the sagittal and coronal views must reconstruct a different, continuous shape.
| Fixture decision | Failure it can reveal |
|---|---|
| 96 ordered slices with 1.25-mm z positions | Missing, duplicated, or incorrectly sorted instances |
| Explicit orientation and 0.7-mm in-plane spacing | Swapped axes or geometry built from array index alone |
| Torso and organs taper across z | Orthogonal planes that render but do not reconstruct the volume |
| High-HU deposits only in central slices | Threshold features appearing on the wrong slice range |
The synthetic capture can be reproduced with the checked-in
scripts/pulse-synthetic-fixture.py and
scripts/pulse-vite-fixture.config.mjs in this portfolio
repository. Those scripts generate the pixels and proxy only the local
fixture endpoints.
Product verification and employer-scoped performance
| Evidence | Observed | Scope |
|---|---|---|
| Current product render | 96 generated slices load; axial, sagittal, and coronal viewports render | Local visual QA of the frontend; no clinical data |
| Client loading width | 8 images per Promise.all batch | Resume claim confirmed in the local repository snapshot; private source is not republished |
| Batch inference latency | <100 ms | Measured internship result; hardware and percentile not claimed |
| Full-scan completion | Under 2 minutes | Measured internship result; scan size and production throughput not generalized |
The first two rows are reproducible from the public source and synthetic fixture. The final two are resume-scoped employer measurements and are not re-benchmarked by this page.
What remains outside the public evidence
- The synthetic phantom verifies rendering and data flow, not clinical correctness or diagnostic usefulness.
- No patient images, employer datasets, private deployment details, credentials, protected screenshots, or private source excerpts were published.
- Sub-100-ms latency is not labeled with a percentile, GPU model, concurrency level, or dynamic-batching configuration because those details are not supported by the public evidence.
- The local capture shows an unannotated labelmap and zero calcium score. It should not be read as a segmentation-quality result.
Add a deterministic synthetic series with known voxel spacing and landmarks, then test that the three viewports report the expected orientation, slice index, and shared physical point after crosshair movement.