6 ms·

I still wonder how can DICOM be any better than PNG... But that is supposedly due to my ignorance.

an1sotropy 4y ago
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.
- notorandit 4y ago
  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...
chadcmulligan 4y ago
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.
- randomh3r0 4y ago
  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.
  - specialist 4y ago
    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.
    - thfuran 4y ago
      >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.
    - randomh3r0 4y ago
      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.
      - specialist 4y ago
        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.
bick_nyers 4y ago
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.
- fluidcruft 4y ago
  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.
  - bick_nyers 4y ago
    You are correct, DICOM does not support PNG: https://dicomlibrary.com/dicom/transfer-syntax/ https://dicomlibrary.com/dicom/transfer-syntax/
  - superjan 4y ago
    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.
- mhalle 4y ago
  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).
  - randomh3r0 4y ago
    *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.

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.

notorandit 4y ago
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...

chadcmulligan 4y ago

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.

randomh3r0 4y ago
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.
- specialist 4y ago
  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.
  - thfuran 4y ago
    >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.
  - randomh3r0 4y ago
    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.
    - specialist 4y ago
      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.

bick_nyers 4y ago

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.

fluidcruft 4y ago
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.
- bick_nyers 4y ago
  You are correct, DICOM does not support PNG: https://dicomlibrary.com/dicom/transfer-syntax/ https://dicomlibrary.com/dicom/transfer-syntax/
- superjan 4y ago
  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.
mhalle 4y ago
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).
- randomh3r0 4y ago
  *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.