Here's a similar case of a scanner using a traditional compression algorithm. It has a bug in the compression algorithm, which made it replace a number in the scanned image with a different number.
That is completely outside all my expectations prior to reading it. The consequences are potentially life and death, or incarceration, etc, and yet they did nothing until called out and basically forced to act.
A good reminder that the bug can be anywhere, and when things stop working we often need to get very dumb, and just methodically troubleshoot.
We programmers tend to think our abstractions match reality somehow. Or that they don't leak. Or even if they do leak, that leakage won't spill down several layers of abstraction.
I used to install T1 lines a long time ago. One day we had a customer that complained that their T1 was dropping every afternoon. We ran tests on the line for extended periods of time trying to troubleshoot the problem. Every test passed. Not a single bit error no matter what test pattern we used.
We monitored it while they used it and saw not a single error, except for when the line completely dropped. We replaced the NIU card, no change.
Customer then hit us with, "it looks like it only happens when Jim VNCs to our remote server".
Obviously a userland program (VNC) could not possibly cause our NIU to reboot, right?? It's several layers "up the stack" from the physical equipment sending the DS1 signal over the copper.
But that's what it was. We reliably triggered the issue by running VNC on their network. We ended up changing the NIU and corresponding CO card to a different manufacturer (from Adtran to Soneplex I think?) to fix the issue. I wish I had had time to really dig into that one, because obviously other customers used VNC with no issues. Adtran was our typical setup. Nothing else was weird about this standard T1 install. But somehow the combination of our equipment, their networking gear, and that program on that workstation caused the local loop equipment to lose its mind.
This number-swapping story hit me the same way. We would all expect a compression bug to manifest as blurry text, or weird artifacts. We would never suspect a clean substitution of a meaningful symbol in what is "just a raster image".
I assume something like jpeg (used in the DICOM standard today) has more eyes on the code than proprietary Xerox stuff? hopefully at least...
I have seen weird artifacts on MRI scans, specifically the FLAIR image enhancement algorithm used on T2 images, i.e. white spots, which could in theory be interpreted by a radiology as small strokes or MS...so I always take what I see with a grain of salt..
The DICOM standard stuff did have a lot of eyes on it, and was tuned toward fidelity which helps. It's not perfect, but what is.
MRI artifacts though are a whole can of worms, but fundamentally most of them come from a combination of the EM physics involved, and the reconstruction algorithm needed to produce an image from the frequency data.
I'm not sure what you mean by "image enhancement algorithm"; FLAIR is a pulse sequence used to suppress certain fluid signals, typically used in spine and brain.
Many of the bright spots you see in FLAIR are due to B1 inhomogeneity, iirc (it's been a while though)
Probably worth mentioning also that "used in DICOM standard" is true but possibly misleading to someone unfamiliar with it.
DICOM is a vast standard. In it's many crevasses, it contains wire and file encoding schemas, some of which include (many different) image data types, some of which allow (multiple) compression schemes, both lossy and lossless, as well as metadata schemes. These include JPEG, JPEG-LS, JPEG-2000, MPEG2/4, HVEC.
I think you have to encode the compression ratio as well, if you do lossy compression. You definitely have to note that you did lossy compression.
Iirc, this was an issue or conspiracy fuel or whatever with the birth certificate that Obama released. That some of the unique elements in the scan repeated over and over.
A good reminder that the bug can be anywhere, and when things stop working we often need to get very dumb, and just methodically troubleshoot.