[HN Gopher] Dicom File Format Basics
___________________________________________________________________
Dicom File Format Basics
Author : vladsiv
Score : 106 points
Date : 2022-07-26 09:22 UTC (13 hours ago)
(HTM) web link (www.vladsiv.com)
(TXT) w3m dump (www.vladsiv.com)
| queuebert wrote:
| I have a funny (or sad, really) DICOM story. I wrote my own DICOM
| parser in Rust, and I kept encountering a bug where the parsing
| would fail on a small subset of files in my database.
|
| What you need to know is that DICOM tags have 16-bit group and
| element values that uniquely identify what the tag contains, and
| tags that begin with the group 0xfffe are very special,
| comprising a small set of field delimiters.
|
| Well, the brilliant minds at Codonics decided to use the special
| group 0xfffe for their private, vendor-specific fields at the end
| of the file. When parsing a file those private fields would look
| like delimiters and ruin the logic.
|
| So because of that one particular vendor, I have to check _both_
| the group and element of every special tag in every file I parse
| to make sure it isn 't one of their special ones. Whereas, if
| they had followed the standard, I would only need to check the
| groups for the value 0xfffe. Thanks, guys!
| quasarj wrote:
| Would love to see your Rust parser
| randlet wrote:
| Things are improving, but non-conformity to the DICOM spec by
| some vendors is quite common. I regularly encounter DICOM files
| that don't even have the 128byte preamble or 4byte `DICM`
| prefix.
| golf_mike wrote:
| For those who like to experiment a little, I can recommend firing
| up a jupyter notebook and explore the image data using pydicom
| and plotting it via matplotlib (or whatever plotting lib you
| fancy). For most CT and MRI data you will have a volume/voxels
| available and its pretty fun to slice'n dice your way through it
| by using list slices. Also all other data is available to
| inspect.
| kaibee wrote:
| > The standard includes a file format definition and a network
| communications protocol that uses TCP/IP to communicate between
| systems.
|
| Is this as cursed as it sounds?
| danielheath wrote:
| The file format is reasonably cursed (header fields to indicate
| endian-ness, multiple internal metadata tables, and it's a
| container format so you can encode the image data using any one
| of 6-8 codecs - or just include a link to the TCP stream).
|
| I haven't used the network protocol, but having some way to
| only bring the required pixel data across the network is pretty
| important - uncompressed CT scans are often hundreds of
| megabytes and the standard was developed before ethernet was
| widespread.
| haolez wrote:
| It's fully binary and is document as a Lisp, as far as I
| remember. It's very nightmarish, but it's from the 80s, so it
| has its merits for staying for so long.
| quasarj wrote:
| Yes.
| mcluck wrote:
| DICOM is a fun format to tinker with. The absolute basics of it
| are simple enough that I wrote a DICOM viewer in college for a
| class. All of the extensions mean you can get some really
| interesting data as well. The various number of attributes and
| unusual combinations make it a real pain if you're trying to
| implement it all from the ground up but I'd highly recommend
| anyone play with it.
| thfuran wrote:
| The DICOM standard document is like 6,000 pages and I've never
| heard anyone call it "fun".
| rurban wrote:
| Thanks for the pedicom hack tip, I was not aware of it. Will add
| a check against the DOS-Header (4d 5a 90 00) magic immediately.
|
| https://github.com/d00rt/pedicom
| ml_giant wrote:
| There is also a file format called DICOS which is based off of
| DICOM which is used by the TSA and various inspection systems:
|
| https://www.nema.org/directory/nema-councils/imaging-and-com...
|
| If you've gone through security at a U.S. airport, the scanners
| use DICOS format to save scans of your baggage. Someone correct
| me if I am wrong though - it's possible only a subset of these
| machines use DICOS, I am not 100% sure.
| vladsiv wrote:
| Yes, I remember stumbling upon DICOS when I researched DICOM.
| Quite interesting application of the standard!
| petercooper wrote:
| Coincidentally, for me, I had an MRI yesterday and they always
| give me access to the DICOM files so it's interesting to know
| more about them. "Horos" is a really good viewer if you want
| something for managing and viewing entire sets of such images,
| especially as it can create 3D visualizations of all the 2D
| slices which results in fun/creepy pictures of my brain to show
| off.
| stronglikedan wrote:
| I recently had some imaging done as well, and they gave me a
| DVD with the images. Now I just have to find a DVD player.
| BuildTheRobots wrote:
| Only supported on OSX. I'd be interested if anyone can
| recommend something similar for Windows and/or Linux.
| antegamisou wrote:
| InVesalius
|
| https://invesalius.github.io/
| fluidcruft wrote:
| Oh, nice! Somehow I had missed this one and was wondering
| why nobody had created a cross-platform python viewer
| that's simpler than slicer. I'll check it out!
|
| https://github.com/invesalius/invesalius3
| figomore wrote:
| Developer here. If you are going to use in Linux, I
| recommend you to install it using flatpak.
| rjzzleep wrote:
| I use Ginkgo CAD on linux. Unfortunately a lot of good free
| DICOM viewers have become abandonware in Linux and shareware
| on OSX. Don't know about Windows.
| tecleandor wrote:
| Ginkgo CADx was a project by a Spanish company giving
| services to public and private health services, but they
| dissolved some years ago, and seems like nobody took the
| maintenance.
| fluidcruft wrote:
| It's similar on Windows. Part of the problem is that access
| to DICOM images is a major barrier. OsiriX happened because
| OS X didn't have a viewer. The "eFilm Workstation" crowd
| moved to OsiriX. It's complex but eFilm used to be pretty
| good but they couldn't add features and fix bugs fast
| enough. And then they couldn't make high DPI work. In the
| mean time, OsiriX was very nice looking and adaptable for
| radiologists who like to tinker. Radiologists can be
| extremely picky and demanding about UI and efficiency and
| OsiriX served that well. Not to mention that OSX brought
| all the linux research packages. So, they all just bought
| Macs and left eFilm behind for OsiriX particularly after it
| obtained FDA/EC clearance.
| tecleandor wrote:
| OsiriX is a great and bad viewer that made life easier
| and cheaper for lots of radiologists and doctor (although
| not cheap enough for some countries)
|
| The bad part: OsiriX was LGPL for a while, but they began
| to mix it with closed binaries. I reported some
| inconsistencies on the license in their mailing list,
| they moderated me, and some time later stopped publishing
| source. That's were Horos started growing.
| fluidcruft wrote:
| I have always avoided OsiriX, but at my new job it's used
| a lot in the image processing lab (that I help support).
| I want to build/provide some simple QA utilities for the
| people who do use OsiriX, but I'm a physicist and I can't
| justify buying that MD license to tinker with and that
| damn timeout nag bullshit is not something I will waste
| my time on. I can't even tell how compatible Horos is
| with OsiriX or if it's maintained anymore. If I knew that
| plugins developed for Horos would work on OsiriX I might
| consider that "ecosystem" but as is it's not worth the
| effort to me. I barely tolerate OS X.
| sbf501 wrote:
| Every CDROM I've received after an MRI comes with a windows
| viewer on it. IN 2010 it was E Film Light, then DCSView, then
| DrayViewer, and today it is Radiant.
| fluidcruft wrote:
| On Windows I use RadiAnt. It's not free software, but it is
| extremely good and not terribly expensive. It will even load
| and display DICOM out of zip files which is a killer feature.
|
| It used to be that everyone used eFilm Workstation for like
| legal consulting etc. But eFilm decided to end that (probably
| because they couldn't figure out how to get it to migrate to
| high DPI screens and it wasn't a priority).
|
| RadiAnt switched their sales model in a way that's very
| convenient for law firms to pay consultants. They can
| basically buy however many months are needed for the
| consultant.
| nick__m wrote:
| I find https://www.slicer.org/ awesome once you get past the
| initial learning curve.
| pilotneko wrote:
| I would suggest ImageJ, which is a Java-based image
| processing program developed at the National Institutes of
| Health (NIH). It has a very low memory footprint, built-in
| support for most DICOM file formats, a ton of extensions, and
| (of course) cross-platform support.
|
| As an added bonus, you can run it as a portable app.
| jphoward wrote:
| RadiAnt is OK - it's got a trial license model but when the
| license expires you can request an extension for free (big
| WinRAR energy). There's nothing as good as Horos that is
| similarly free and open source, sadly.
|
| What you may prefer to do is use the excellent pydicom
| library for Python, which loads dicom files as numpy arrays,
| allowing you to convert to any other file format you fancy,
| whether that be image or video.
| fluidcruft wrote:
| A complex/overkill but open source approach on Windows is
| to install Orthanc and use the new webassembly viewer. But
| it's not as fast/good as RadiAnt and it's certainly nothing
| next to OsiriX.
|
| https://www.orthanc-server.com/static.php?page=stone-web-
| vie...
| pehtis wrote:
| I'm using this one on macOS
| https://github.com/rordenlab/MRIcroGL It is available for
| linux too.
| bick_nyers wrote:
| Weasis is good on Linux
| notorandit wrote:
| I still wonder how can DICOM be any better than PNG... But that
| is supposedly due to my ignorance.
| bick_nyers wrote:
| 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 wrote:
| 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.
| superjan wrote:
| 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.
| bick_nyers wrote:
| You are correct, DICOM does not support PNG:
|
| https://dicomlibrary.com/dicom/transfer-syntax/
| mhalle wrote:
| 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).
| bick_nyers wrote:
| 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.
| randomh3r0 wrote:
| *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 wrote:
| 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.
| an1sotropy wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| randomh3r0 wrote:
| 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 wrote:
| 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.
| thfuran wrote:
| >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.
| zegerius wrote:
| Very interesting! I have been working with medical information
| standards for a while now. Recently, I took an interest in DICOM
| and ways to modernize it. For example by introducing streaming,
| caching, moving metadata to a FHIR ImagingStudy resource.
|
| To me, specifically streaming and caching strategies to move the
| load of (often hopelessly legacy) hospital infrastructure are an
| interesting challenge.
| lostlogin wrote:
| Whatever issues exist within DICOM are dwarfed by HL7 hell, and
| the point where the two specs meet can by awful.
|
| Between HL7 and vendors doing custom things with HL7 and DICOM,
| IT support in healthcare is always going to be desperately
| needed.
| etaioinshrdlu wrote:
| The amount of redundant scientific/medical/industrial image file
| formats is amazing. Just off the top of my head there is DICOM,
| FITS, NIFTI, NRRD, plus TIFF.
|
| They all have the basic property of having raster data of
| arbitrary channels/depth plus a whole bunch of metadata.
|
| It feels like every new industry I work with I discover they have
| their own redundant image format.
| quasarj wrote:
| Yep. Quit making new ones!
| greatgib wrote:
| Very nicely written article. I guess that it is pleasant to read
| even if we don't have to work with the Dicom format.
|
| The explanation of TLV could be interesting also in itself.
| vladsiv wrote:
| Thank you, I really appreciate it!
| juliansark wrote:
| My amazing experience with DICOM, an open standard with viewer
| software on SourceForge, is that I once took pictures in the
| format to a locally renowned neurologist.
|
| She plugged my USB stick into her Windows XP workstation, ca.
| 2019, without the slightest hesitation, then proceeded to claim
| not to know what DICOM is, and to ask me why I didn't bring her
| either the proprietary viewer program, or JPEGs.
|
| Had I brought the viewer, she would have probably launched the
| .exe with equally no hesitation.
|
| At least in these parts of the woods, this once again confirmed
| to me that medicine and IT usually exist at opposite ends of a
| spectrum.
| solardev wrote:
| IMHO, I don't think it's ever safe to assume that someone, even
| if they're in tech, would readily know what file format X is or
| have the right software for it. If in doubt, you should provide
| them the way to easily see whatever it is you want to show
| them, whether it's a x-ray or a hiking map or a giant party
| banner.
|
| When I got my scans from the radiologist, they came on a CD-ROM
| (remember those?). I had to dig up my old disc drive from
| storage, then loaded the files onto my phone. At the
| orthopedist, I just showed it to them right on the phone with a
| Android DICOM viewer. I also brought the original CD, along
| with the same files plus 2-3 different viewers on my laptop,
| juuuuust in case. There's no way I was going to risk another
| clinic visit, at what, $300/visit?, just because they couldn't
| read the images. I'd do the same anytime I was visiting another
| professional. I don't assume to know their tech setup or level
| of file format expertise... that isn't what I'm paying them
| for, after all.
|
| As an aside, in my brief investigation into DICOM (a format
| previously unknown to me before my injury), I discovered that
| it's actually a pretty complex format, with different viewers
| having pretty different UIs in terms of how they handle layers
| within a file (in both time and space), overlays and contrast
| adjustments (to emphasize/deemphasize certain artifacts,
| apparently), different collections and naming schemes for the
| same body parts, etc. Some of them were barely more usable than
| a JPEG viewer, while others could interpolate/extrapolate the
| data into a 3D point cloud and create rough anatomical models
| by combining collections of images from different angles. It's
| quite a complex system of raster imaging plus metadata, and no
| two viewers worked quite the same, even between the several
| free and/or open-source options. It reminds of the nonstandard
| mess that is file packaging for GIS (geographic information
| systems) -- a lot of power, but no simple system for organizing
| that power. In that sense DICOM is more like a database of
| radiological data that happens to be plottable in 2D (and
| sometimes 3D) space, rather than a simple image. If you export
| it to JPEG, you get a static output in time & space and lose a
| lot of the power of DICOM.
|
| There are a loooooooot of ways to store imaging data out in the
| wild, and many different versions & viewers for each format...
| rather than looking down on someone for not keeping up with the
| tech stacks du jour, why not just help them get what they need
| to do their job more effectively? Especially when they're
| working to heal you.
| xvilka wrote:
| There is also a problem that many DICOM viewers are outdated
| and abandoned, e.g. written in GTK+ 2.x which is not availabe
| on modern systems, and weren't updated for many years. Take,
| for example, AMIDE[1] - no changes in the development
| repository for 5 years already. Same story with many other
| projects.
|
| [1] https://sourceforge.net/projects/amide/
| balls187 wrote:
| > that medicine and IT usually exist at opposite ends of a
| spectrum.
|
| Working in Medicine you learn that specialists, and in
| particular renowned ones have their worlds optimized around
| having them do what they do best, and not wasting time not
| doing what they do best.
| classichasclass wrote:
| My clinical work is in TB control and we read a lot of chest
| X-rays and CT scans. I'm very used to DICOM and I have my
| personal preferences for DICOM viewers, but outside of an
| actual radiology suite most docs will just use whatever viewer
| came on the disc, if there's one at all. And that's largely
| true for the ones I've worked with in this field, too.
|
| That said, I was in IT before I got my MD.
| nick__m wrote:
| What your preference, and do you like https://www.slicer.org/
| ?
| badsectoracula wrote:
| > Had I brought the viewer, she would have probably launched
| the .exe with equally no hesitation. At least in these parts of
| the woods, this once again confirmed to me that medicine and IT
| usually exist at opposite ends of a spectrum.
|
| Well, on the other hand she'd be able to do what she needed
| without any other distractions - and in case you happened to
| break the machine, you'd be around to slap or pay up for the
| fixes :-P.
|
| At the end of the day for most people computers are there to
| help their jobs.
| riedel wrote:
| My father practice moved digital in the late nineties, they had
| a cd robot that would burn the dicom images together with a
| quite decent windows viewer from Siemens (actually it had nice
| contrast and zooming features) on the disk with autorun config
| (nobody cared at this time about security). The future was
| here...
|
| Fun side aspect of the story is that they bought the wrong type
| of CD-Rs for the robot and I am still having empty CD-Rs from a
| batch of 500 or so I am using (once every other year).
| pc86 wrote:
| Until I took a senior developer role at a radiology practice I
| had no idea what DICOM was. The idea that a physician should
| know is kind of fanciful, isn't it? In 99.99% of cases, they
| load images by clicking a button that says "Display images" in
| a PACS, or RIS, or the images are loaded automatically by
| workflow. It's like expecting someone who has only ever viewed
| webpages, and never even viewed the source let alone made a
| webpage, to know the difference between JPEG, GIF, and PNG.
| 1MachineElf wrote:
| Physicians know that a DICOM file is what you get when you
| export from their viewer software. I asked a chiropractor for
| my x-rays and they just gave me a CD with two DICOM files on
| it. That chiropractor was an idiot, but at least they knew
| what a DICOM was.
| VikingCoder wrote:
| This is like a restaurant that has a QR code on the table
| instead of a menu.
|
| Yes, it's absolutely possible for someone to use the QR code to
| fetch the menu from a website using their phone. But unless you
| do it often, you just don't even know how to do it.
|
| Doctors are insulated from DICOM the same way that most humans
| don't normally type "h t t p : / /" They just click on links
| and things show up for them.
| tecleandor wrote:
| Oh yeah, really. Doctors, standards and computers not always
| mix well.
|
| Thankfully nowadays there are lots of local-only web DICOM
| viewers, based on Cornerstone or other JS libraries...
|
| https://github.com/ivmartel/dwv
|
| https://github.com/webnamics/u-dicom-viewer
| samuel wrote:
| Dicom files are usually in a structure that includes a viewer
| (there is a IHE profile which standardizes it). Barring
| radiologists physicians rarely know about file formats, and the
| portable media "just works" (mostly).
| lostlogin wrote:
| In my experience the specialists just offload this problem
| (and any other imaging tech problems) to their radiology
| provider, and while that might be a local phenomenon, I'd
| hazard a guess that it's universal.
| tainto wrote:
| phkahler wrote:
| You needed to bring a free DICOM viewer and have her install it
| ;-)
| brnt wrote:
| The problem with extensibility is that everyone does!
| 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 and how
| you might calculate their supersecret checksums (for safety!).
|
| Dicom Compliance is a well paying job.
| vladsiv wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| queuebert wrote:
| I have some DICOM experience. How does one go about getting
| these compliance jobs?
| brnt wrote:
| Manufacturers of devices and associated software (eg
| treatment planning systems) tend to have somebody like that.
| Not sure you actually want to though.
| vladsiv wrote:
| I would also like to know :D
| SubiculumCode wrote:
| I always convert dicoms to nifti format. Is there any advantage
| not to??
| skywal_l wrote:
| You might be interested in a series of articles dealing with the
| multi planar rendering algorithm (starts at part 2):
| http://site.novidee.com/blog/blog-entry.html?article=2020091...
|
| How to render an MPR image (an arbitrary slice of 3D data volume)
| from scratch starting from the bare DICOM files.
| vladsiv wrote:
| Thanks! This is great, I'll definitely check it out in-depth.
___________________________________________________________________
(page generated 2022-07-26 23:01 UTC)