3 ms·

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

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