The information in a DICOM file is a huge huge superset of the information you'd typically find in a PNG, because the amount of metadata you want to tie to a medical image is enormous (e.g. what day, what scanner, which scan, which part of which scan, which radiology tech, which doctor, which patient, with which contrast agent, in what orientation). Even if you did contrive a way to pack that metadata into a PNG file (which is possible), you'd still need a way to unambiguously interpret all that metadata, and know that everything else in the healthcare world is going to interpret it the same way. That's one of the things that the DICOM standard covers.

As you said, it is nothing you cannot put into a PNG metadata. Unambiguously? It is all about standard definition. XML, JSON, CSV, excel sheet...

DICOM is a lot older than PNG, you can embed multiple images in a DICOM file using different formats - losless and lossy, formats like jpg, tiff and so on. It also includes a bunch of tags that describe the image, patient information, scanner it came from and so on.

It also goes well beyond just talking about the imagery itself or the metadata surrounding it, and the standard contains its own network protocol effectively for transmitting data between PACS systems and other endpoints. (I recently worked in medical imaging for over 6 years and know DICOM fairly well, warts and all).

That said, there are absolutely better ways of handling almost any of the cases DICOM supports, the issue is that there is almost no standard that is fully backwards compatible which supports everything DICOM does, so we're sorta shackled to it for better or worse. Otherwise you have to deal with trying to explain to underfunded clinics (not the Mayo or Cleveland type) around the world why their expensive machine that they bought second or third hand is no longer acceptable.

In your professional opinion:

Is there any need or demand for a decent Java language DICOM parsing library?

Mid-aughts, I wrote a DICOM image viewing applet. (Before tile-servers a la Google Maps, which would have been a better strategy.) My library could read DICOM filestores. But not do network interchange.

DICOM applet was intended to be part of our EMR web client, our frontend to showcase our portable electronic medical records backend stuff. At the time, it was an amazing demo, greatly helping our Sales team.

My code (IP) got lost, abandoned. (Acquisition, abandonment, high mgmt turnover, etc. Typical M&A story.) So sad. Anyone who'd know or remember what my code did is long gone.

--

Ditto my HL7 2.x and 3.x libraries, FWIW. I wrote my stuff in response to the available tools at the time. SeeBeyond ICAN/JCAPS, Mirth, BizTalk, a bunch of others I now forget. Turrible. I'm out of the field, so I imagine the world's moved on. FHIR and whatnot.

We lived predominantly in the .NET world and leveraged Fellow Oak Dicom pretty heavily, but when I did have to use anything in Java-land we pretty much always leveraged dcm4che, as it did what we needed and we didn't need to monkey with it much. Ultimately given my ignorance of that ecosystem I'd be hard pressed to advise about the need or demand in Java one way or the other unfortunately. Sorry about that!

You made me shudder by mentioning BizTalk just now, though. I had long since shut that way in the corners of my mind.

Thanks for the feedback.

Ya, with all the ETL work I've done, I've been cured of any interest in visual programming, "no-code", and the latest iteration of CASE tools in general.

Aside from all the BizTalk specific heartache...

With patch-cord programming, you always have to drop down to actual code for that last 5% of work, the fit & finish. Then you're fighting the framework (tool).

Better to have an API that's easy and bulletproof. My solution for HL7 "interface" implementations was to ingest the specifications (authored by our customer facing business analysts) and output Java source code. Then use any IDE (tool stack) to proceed as normal for that last 5%.

We'd onboard new teammates (to do "HL7 interfaces"), most who had never seen Java before, in about 2 weeks. At the time, the assumption was onboarding to ICAN (or equiv) would take about 3 months. (Yikes.)

I was always interested in playing with C# and LINQ for our work. But none those sales leads panned out.

>Is there any need or demand for a decent Java language DICOM parsing library?

Dcm4che is that, though perhaps there could be some debate as to whether it's decent. I don't know; I'm stuck using quite an old version.

PNG coupled with a JSON can do almost anything that DICOM can do. DICOM can also do video and is starting to dabble in waveform data, but MP4 and SVG exist.

DICOM is a standard for medical imaging, and the patient data related to it, supported by every medical imaging device manufacturer.

JSON is a data format, it isn't in itself a standard for any content in particular, particularly medical imaging content. Think schema, not encoding (and in fact there is a JSON encoding for DICOM).

Yup, the way you interpret the JSON or DICOM matters.

In DICOM, the interpretation of the data is coupled with a specific file format, when it doesn't need to be.

We want window leveling to work the same way across the board, but whether you transmit the width, center, and algorithm (linear, sigmoid, etc.) in a DCM file or in JSON or in carrier pigeon doesn't particularly matter so long as the receiver can interpret it.

Would it be better if all modality manufacturers started sending JSON? Probably not, however manufacturers produce non-compliant DICOM ALL THE TIME so there's still an issue there with complexity and lack of strong testing tools for the standard.

*supported by every medical imaging device manufacturer going back something like 3+ decades.

This is much less of a problem of shiny-object-syndrome not providing a "better" way of solving the problem(s) and much more one of market inertia, IMO. Many people overlook this.

Especially considering that medical information can often need review decades later. Can't just support the new stuff, you need to support the priors that were rendered in the pre-2000s as well.

DICOM supports MP4 (and HVEC/H.265, various flavors of JPG, and various other encoders, etc). I don't think PNG is supported, though and I'm not entire certain why but possibly it's a licensing issue. DICOM objects are basically just generic containers.

There’s probably multiple reasons why DICOM does not support PNG. Most compression formats in DICOM are those published as official standards in the JPEG family from ISO. The original JPEG from ‘92 already included a Lossless mode which supports 16/12/8 bit color and monochrome and is very fast to encode and decode. All of those were important features. Adding PNG later would not benefit anyone: it can not handle all of these usecases, it is usually slower and it came later.

You are correct, DICOM does not support PNG:

https://dicomlibrary.com/dicom/transfer-syntax/