5 ms·

> Manufacturers will dump in all sorts of tags, and check for them, when you read in, but the won't tell you what they are True. As far as I know it could be a

> Manufacturers will dump in all sorts of tags, and check for them, when you read in, but the won't tell you what they are True. As far as I know it could be also used for a vendor lock-in. If you export DICOM files from X, you have to use software Y. Since they are dumping all sorts of private tags which you don't know anything about.

danielheath 4y ago
In practice, the files can be viewed just fine in any standard-compliant viewer without any awareness of custom tags. Source: I wrote the DICOM viewer & anonymizer for Radiopaedia (okay, most of the heavy lifting is done by cornerstone.js).
- thfuran 4y ago
  For certain definitions of "just fine". Some manufacturers will use a private tag to hold the same information that's meant to be in a standard tag—and even sometimes put different values in the two, with the private tag being correct.
  - vladsiv 4y ago
    > Some manufacturers will use a private tag to hold the same information that's meant to be in a standard tag... Agree! Also some applications have "special" features that rely on data stored in private tags which, of course, you don't have any idea how to use.
- brnt 4y ago
  Viewer of what? Dicom can contain other things than just nD imagery. Also, the difficulty in my experience is the getting data back in part; getting data out is usually a lot easier (you don't need to care about those tags).
fluidcruft 4y ago
In many cases it's because the standards don't (yet) support storing important information or weren't performant. For example, in DTI imaging recording of the diffusion vectors was not something that DICOM supported until DTI use became more widespread clinically. In other cases it was network performance hacks. Another example with DTI is that initially DICOM for MRI only supported 2D images. Which for DTI is a problem because you easily end up with thousands of images and transferring them as individual 2D with all the network handshaking and storage confirmations is slow as molasses and grinds on PACS that aren't setup for this. Some vendors "solved" this by creating large 2D images of 3D images by laying out multiple 2D slices in a mosaic. Because the 3D volume became one 2D image, transfers were much faster and doesn't consume as many resources on PACS. Eventually the DICOM standard came up with an even better solution, but it's only recently starting to roll out on the scanners and the old ways still persist.

danielheath 4y ago

In practice, the files can be viewed just fine in any standard-compliant viewer without any awareness of custom tags. Source: I wrote the DICOM viewer & anonymizer for Radiopaedia (okay, most of the heavy lifting is done by cornerstone.js).

thfuran 4y ago
For certain definitions of "just fine". Some manufacturers will use a private tag to hold the same information that's meant to be in a standard tag—and even sometimes put different values in the two, with the private tag being correct.
- vladsiv 4y ago
  > Some manufacturers will use a private tag to hold the same information that's meant to be in a standard tag... Agree! Also some applications have "special" features that rely on data stored in private tags which, of course, you don't have any idea how to use.
brnt 4y ago
Viewer of what? Dicom can contain other things than just nD imagery. Also, the difficulty in my experience is the getting data back in part; getting data out is usually a lot easier (you don't need to care about those tags).

fluidcruft 4y ago

In many cases it's because the standards don't (yet) support storing important information or weren't performant. For example, in DTI imaging recording of the diffusion vectors was not something that DICOM supported until DTI use became more widespread clinically. In other cases it was network performance hacks. Another example with DTI is that initially DICOM for MRI only supported 2D images. Which for DTI is a problem because you easily end up with thousands of images and transferring them as individual 2D with all the network handshaking and storage confirmations is slow as molasses and grinds on PACS that aren't setup for this. Some vendors "solved" this by creating large 2D images of 3D images by laying out multiple 2D slices in a mosaic. Because the 3D volume became one 2D image, transfers were much faster and doesn't consume as many resources on PACS. Eventually the DICOM standard came up with an even better solution, but it's only recently starting to roll out on the scanners and the old ways still persist.