Talk:DICOM

message: Looking at the log it seems the image is coming from:
  http://www.dicom-solutions.com/sample/
Is it ok not to referenced the orginal file. 
Also the jpg is extracted from the DICOM file, why not referenced directly the original file, which would make more sense.
I am changing "set of standards" to "standard" since the DICOM committee itself refers to it as the "DICOM standard" (see the DICOM Strategic Document.) MrSerif 15:33, 29 December 2006 (UTC)
thread_title: Looking

message: Is it strictly correct to say "DICOM files consist of a header with standardized and free-form fields, and a body of image data"?
That is, I thought that there isn't really a header -- just a collection of attributes, some of which contain data that would normally
appear in a header and typically one notable one (!) that contains the image data.
:Agreed and now done Medconn 13:20, 31 December 2006 (UTC)
thread_title:  DICOM Data Format 

message: I think this is totally wrong:
"DICOM is categorized into two different transmissions; DICOM Store and DICOM Print."
Why just two?  Aren't there lots of service classes:
* Verification Service Class
* Storage Service Class
* Query/Retrieve Service Class
* Study Content Notification Service Class
* Patient Management Service Class
* Study Management Service Class
* Results Management Service Class
* Print Management Service Class
* Media Storage Service Class
* Storage Commitment Service Class
* Basic Worklist Management Service Class
* Queue Management Service Class
:Yes, though many have never beed used - the major ones are now listed on the main page Medconn 13:20, 31 December 2006 (UTC)
replies: text:  Are they? I only find the very confusing section heading "DICOM Services". When I hear DICOM Services I only think of DIMSE Service (like C-STORE and N-GET). I think we should rename this section "DICOM Service Classes" and give each subsection it proper Service Class name. Alternively we should replace "services" in the heading with something else, like "features". Kr-val 13:30, 4 January 2007 (UTC)
thread_title:  Service Classes 

message: Is it true that: "This protocol is an application protocol, it uses TCP/IP to communicate between systems."
Doesn't DICOM specify all of the upper-layer protocols, including application layer, presentation layer, and session layer?
: In TCP/IP, there is only an application layer.  Application, presentation, & session are in the OSI model, not TCP/IP. Cburnett 02:14, 27 April 2006 (UTC)
replies: text:  And the OSI model has now been officialy retired (at last!) Medconn 14:21, 13 July 2006 (UTC)
thread_title:  Application protocol? 

message: The list of modalities takes up a very large proportion of the article, and adds very little ot the value - should it be removed? Medconn 12:21, 31 December 2006 (UTC)
replies: text: I gives some insight in what areas DICOM can be applied, but I definitely agree that it is way too long. And it definitely does not fit into the history section. Maybe we could pic only a few? Btw, I plan to add some more info into the history section. Kr-val 13:09, 4 January 2007 (UTC)
thread_title: List of modalities

message: I think there are several holes in the history, there were at least two other companies that produced and successfully marketed the 50 PIN interface (I used to work for one of them).  And if we are in the space of naming contributors one needs to mention the two CTN implementations for the 1993 RSNA demonstration. One built by Mallinckrodt institute (http://erl.wustl.edu/research/dicom/ctn.html)and the other by Oldenburg university (http://dicom.offis.de/dcmtk). If you want to be charitable you also should mention Steve More and Dr. Marco Eichelberg.  The rest is history.
The extensions developed by Philips and Siemens diverged very quickly, and SPI implementations between the companies were not compatible, I would not even bother mentioning them because they were just as inbreed as ODINA developed by GE.  BTW ODINA was a forerunner of DICOM, it was the CT to console protocol used internally by GE.
I would also like to point out that the DICOM SDO does not operate like most SDOs.  WG6 is sort of a technical oversight committee that manages the release and editing of the entire standard.  Usually a working group is created to cover a particular aspect of the standard, a new SOP class, or in case of Structured reporting a new set of templates.
Concerning the DICOM Data format….
I think it is partially misleading to characterize DICOM data sets as just data sets.  The DICOM data fall into one of two categories, composite objects and normalized objects.  Composite objects are invariant objects identifiable by embedded UIDs that locate the object in the DICOM real world model.   Normalized objects are more like HL7 messages used to communicate a particular state of the object repositories, or connect composite objects to other domains like HL7.  When we talk about composite objects we need to look at them as structured documents more like an HL7 CDA document, but with tighter controls on the content.  Each DICOM object (composite and normalized) is controlled by the IOD definitions detailed in Parts 3 and 4.  One could look part 3 and 4 as the DTD in XML except not in a computable format.  (In reality there is a current work item of transcoding DICOM SR into CDA which would effectively put the DICOM IOD definitions into a DTD, but that would be an entirely different discussion.) 
So in more accessible terms the DICOM data format is a database on a wire.  The encoding is pretty arcane and binary, and it also is dependent on the transfer syntax, but in general it follows the
	<tag><[Value Representation(VR)]><length>
pattern.  The VR is optional because it only appears in explicit VR   transfer syntaxes.
The DICOM header is also split into modules; each IOD may contain mandatory or optional modules, within the modules tags may be required, optional or conditionally required.  (And we refer to the header as the information preceding the pixel data, not the command group or the file metaheader.)  When a DICOM message is written to disk or media the entire header and the pixel data is written to the disk.  Depending of the level of a DICOM archive the original image may be preserved bit for bit and retrieved, or attributes may be coerced as needed, but in that case for a level 2 archive it is required that the source of the image is notified of this action.
I am confused as to what you mean that a DICOM object contains no header.  When transmitted over a DICOM association there is a command group (tags 0000xxxx) that precede the actual object.   BTW there might be more attributes that contain pixel data like the Icon Image Sequence.  There is nothing special about the pixel attribute other than it can be big, so is any other tag with a value representation of Unlimited Text (UT).
I also find your distinction of frame and image a bit hard to get.  So let me see if I can get it.  If I use a single frame CT object to encode a CT study I have say 50 IODs and in your nomenclature 50 images, if I use the new multiframe CT object to send the same CT study I somehow lost 49 of those images because they became frames of the object?   That is how I read it; in essence you did a semantic conversion between frames and images.  I am not following you.  In my vocabulary frames and images are the same concepts just encoded differently.
DICOM has specified compressed transfer syntaxes from its very early versions.  Nothing but the pixel data gets compressed and it can be lossy or lossless compression.  The encoding uses encapsulation.  Using LZW on DICOM images is a bad idea.  RLE can be used as the final encoding as opposed to Huffman encoding as part of standard JPEG where the data is first moved into the frequency domain using DCT.  Lossless compression reduces DICOM image sizes on average by a factor 2 to 3.  Some SOP classes compress better because of the large collimation regularly used in those images.  Compressing DICOM headers is not very important they are very small compared to most DICOM images.
On DICOM services:
You are missing the General Purpose Worklist and General Purpose Performed Procedure Step services.  They are becoming very important tools to manage scheduled workflow for specialty devices, such as 3D workstations, image guided surgery, or radiation therapy devices.
As far as offline storage:  it would be more important to concentrate on Part 11: Media Storage Application Profiles.  It not only uses part 10 as the underlying mechanism to specify file system creator and reader behavior but also defines what information is required for a specific application of the exchange media.  
And since you dragged IHE into this, there is very little or nothing about that in the Wikipedia. 
Applications:
I do not think that the list of enumerated value of the modality attribute is it.   I think it deserves a serious discussion of the field of medical imaging and how DICOM is used.
The sample would be a better if you had a DICOM header dump….
So much for now…I will think of other stuff, maybe get David Clunie to look at your page as well.  I do not think one can put DICOM in a nutshell, it is way too big :-)
dee
;-D
(ObjectForge 14:14, 25 April 2007 (UTC)
thread_title:  General Comments 

message: Over on [Medical Imaging], we found these four links that clearly fit your category better:
* Trial Wire - Free DICOM tool to transfer and anonymize DICOM files....
* MicroDicom - Free DICOM viewer for Windows 
* SureVistaVision - Multi-platform DICOM viewer.
* OsiriX - OsiriX Open Source DICOM Viewer
If you guys want to keep, alter, or dump... be our guests.  :)
FreedomWorks! (talk) 15:06, 17 August 2009 (UTC)
replies: text: Everything that's relevant is welcome (I think), but please talk about the relevance inline . Wikipedia is no external link collection, whatever the spammers might try (even here.) –Be..anyone (talk) 06:33, 2 March 2014 (UTC)
thread_title:  External Links 

message: Paragraph "Off-line Media (DICOM Files)" states both that "DICOM restricts the filenames on DICOM media to 8 characters (some systems wrongly use 8.3, but this is not legal)." and "DICOM files typically have a .dcm file extension." This seems be a contradiction? Supermagle (talk) 07:50, 28 May 2010 (UTC)
thread_title:  DICOM file extension 

message: This article covered most aspects of DICOM, however, it did not mentioned the market and users to demonstrate the trend of usage.
users
* American Academy of Ophthalmology
* American Academy of Oral and
* Maxillofacial Radiology
* American Association of Orthodontists
* American Association of Physicists in
* Medicine (AAPM)
* American College of Cardiology
* American College of Radiology
* American College of Veterinary Radiology
* American Dental Association
* Brazilian College of Radiology (CBR)
* College of American Pathologists
* Deutsche Roentgengesellschaft
* European Federation of Organizations for Medical Physics (EFOMP)
* European Society of Cardiology
* European Society of Radiology
* Medical Image Standards Association of Taiwan
* RadiologicalSociety of North America
* Société Française de Radiologie
* Society for Imaging Informatics in Medicine
* Spanish Health Informatics Society
* Institute of Materials Malaysia  — Preceding unsigned comment added by 121.121.9.29 (talk) 08:40, 30 September 2014 (UTC)
thread_title:  The users of the DICOM 

message: This article is the subject of an educational assignment at La Trobe University supported by  the Wikipedia Ambassador Program during the 2013 Q1 term. Further details are available on the course page.Category:Wikipedia Ambassador Program student projects, 2013 Q1
Hi Enzo,
I think you touch on some really nice ideas in your part. The idea of comparing DICOM and HL7 is brilliant. The title summarises the key points of this section. The structure is clear, but maybe you can try to put some of your ideas in dot points. For example, the third paragraph of DICOM and HL7, try to put your points into dot points rather than listing with numbers would be better. Plenty of footnotes and the references are from reliable sources. One more suggestion, maybe you can try to put   for the terms that wiki has an article on, so that people can click it and easily go to that article. For example, HL7. Also, try to make your article title consistent with the whole wiki page: DICOM and HL7.  — Preceding unsigned comment added by ChaoDOU (talk • contribs) 10:48, 19 May 2013 (UTC)
thread_title:  Feedback on DICOM AND HL7 

message: This article is the subject of an educational assignment at La Trobe University supported by  the Wikipedia Ambassador Program during the 2013 Q1 term. Further details are available on the course page.Category:Wikipedia Ambassador Program student projects, 2013 Q1
Hi Enzo, Thanks for your contribution to DICOM. You added a great part, and provide readers really valuable information from another angle. Personally, you use very clear and simple language to explain a complex theory to a variety of different readers. However, as for me, it is better to add more information to explain their differences and relations. I am also interested in interfaces between them. This would be one of relations between them. If you explain the comparison or relationships between them by using a application instance in health services, that would be perfect! Above all, this part integrates my knowledge of DICOM. Thanks for you contribution. 
Fan Zhang-IHC (talk) 12:43, 19 May 2013 (UTC)
thread_title:  Suggestions of DICOM AND HL7 

message: "Parts of the standard" is its own section? Could it go into the external links section? Hza a 9 (talk) 20:04, 10 February 2015 (UTC)
thread_title:  Is there any reason why 

message: "It is not a framework or architecture for achieving a useful clinical workflow. RSNA's Integrating the Healthcare Enterprise (IHE) initiative layered on top of DICOM (and HL-7) provides this final piece of the medical imaging interoperability puzzle."
This is not the only available library or application providing a clinical workflow layer on top of DICOM. Should it say one option, or better yet, not mention IHE at all? 204.187.11.131 (talk) 10:49, 7 April 2015 (UTC)
thread_title:  Advert for IHE? 

message: I like Irfanview, so I tried to look at Dicom images with Irfanview. I couldn’t get it to work. The standard Irfanview needs extra extensions to see Dicom, and do not mix 32 and 64 bit versions. Even with installed extensions, apparently including Dicom, Irfanview won’t recognize a Dicom file or directory, as no file extension (like .jpg) is used. A Sam Zen https://irfanview-forum.de/showthread.php?t=2960 repeates: “DICOM.DLL - This PlugIn allows IrfanView to read Dicom medical files. … Note: DICOM/ACR/IMA format hasn't a specific header and IrfanView can't recognize all such images. If you want to read Dicom/ACR/IMA images with IrfanView, the file extension MUST BE ".dcm", ".acr" or ".ima"!” – Fritz Jörn (talk) 04:44, 15 September 2018 (UTC)
thread_title:  Irfanview 

message: The article currently says " for VRs that are not OB, OW, OF, SQ, UT, or UN,", but none of the latter should be assumed to be known by all readers, and none are explained in the article. 
—DIV (137.111.13.4 (talk) 02:14, 7 May 2020 (UTC)
thread_title:  Undefined terms