If an X-ray machine has a detector:
Apparently some dicom tags are not always available eg. (0018, 700a) Detector ID. At what point in time it is decided which dicom tags are stored in the dicom files. At the installation time of the maschine or is it subsequently expandable?
EDIT
Is there any settings to switch on/off to push dicom tags into the file?
DICOM standard gives each tag a type, which indicates, whether it's mandatory or not. The tag You mention (0018, 700a) Detector ID is type 3 or optional. That means, that including or not including it is up to the vendor of the machine or software.
Whether it's configurable or not also depends on the implementation. The best way to find out, would be to look at the DICOM conformance statement of the equipment in question. They might list all the tags they include in their output with explanations where the values come from or whether they are configurable.
Related
All, Forgive me I am a newbie in the DICOM world. I tried to learn the DCMTk tools to talk with PACS server. But didn't found much tutorial or sample in the internet to know enough about it .Currently I just have the offical document to read.
I just tried the findscu.exe to test c-find command .
I remembered C-Find would return what specified in the request message. for example. If I only specifed the condition Patient Name ='abc' then the reponse would return only attribute Patient Name. Nothing else.( If it is not right . Please correct me.)
So I want to know how to return all the attribute of response DICOM.
Thanks.
How to specified multiple attributes in the findscu command.
Just specify multiple --key (-k) options on the command line. Alternatively, you could also use a "query file" as described in the man page.
So I want to know how to return all the attribute of response DICOM.
Then, you have to specify all attributes (keys) you are interested in. That's how C-FIND works.
By the way, if you are querying a PACS (Query/Retrieve SCP), then you also have to specify the Query/Retrieve Level (0008,0052), e.g. "PATIENT".
Currently I just have the offical document to read.
If you think that the examples in the man page of the findscu tool are not sufficient (and you are actually querying a PACS), this HOWTO might be useful too.
It is totally legal to send a request with Patient Name information only and the PACS will return all matching datasets.
Each dataset should at least contain all mandatory fields like Date of Birth, Patient ID, and so on, depending on the Query Level.
What information is returned by the PACS system on each Query Level should be specified in the DICOM Conformance Statement of the vendor. I would recommend to take a look at this to know, how to set up a valid query to get the information you need and/or if the information is provided by the PACS system.
It is best to include the Unique key and Required Key Attributes in the request attribute list. Also, include the optional attributes (if supported by SCP) when you wish server to return values for them. Please refer to DICOM Standard PS 3.4 section C.2 and C.3 detail information on Query/Retrieve service. List of attribute and type (Unique, Required, Optional) is listed section C.6.1.1.2 (Patient Level), C.6.1.1.3 (Study Level) and so on.
For an assignment I have to suggest an algorithm to calculate the degree of relatedness between two terms given a document. I don't know where to start creating an algorithm like that;. This is all in the area of Information Retrieval and we are currently study the binary and vector space model etc.
If anyone could put me in the right direction at least, that would be great! Or any links that would help.
A key problem in text mining is the extraction of relations between terms. Hand-crafted lexical resources such as Wordnet have limitations when it comes to special text corpora. Distributional approaches to the problem of automatic construction of thesauri from large corpora have been proposed, making use of sophisticated Natural Language Processing techniques, which makes them language specific, and computationally intensive. It is conjectured that in a number of applications, it is not necessary to determine the exact nature of term relations, but it is sufficient to capture and exploit the frequent co-occurrence of terms. Such an application is tag recommendation.
Collaborative tagging systems are social data repositories, in which users manage web resources by assigning to them descriptive keywords (tags). An important element of collaborative tagging systems is the tag recommender, which proposes a set of tags to a user who is posting a resource. In this talk we explore the potential of three tag sources: resource content (including metadata fields, such as the title), resource profile (the set of tags assigned to the resource by all users that tagged it) and user profile (the set of tags the user assigned to all the resources she tagged). The content-based tag set is enriched with related tags in the tag-to-tag and title-word-to-tag graphs, which capture co-occurrences of words as tags and/or title words. The resulting tag set is further enriched with tags previously used to describe the same resource (resource profile). The resource-based tag set is checked against user profile tags - a rich, but imprecise source of information about user interests. The result is a set of tags related both to the resource and user.
(And if you copy that word-for word into your report the prof is bound to discover that you got it from a simple Google search, like I did.)
I wonder if it is possible to have two different images with the same header. If so, can we display this two images in the PACS or otherwise which tags should be changed to display them?
No you can't. The issue is that Dicom requires every image to have it's own Unique UID stored in the header.
PACS systems commonly ignore newly received images if their UID is identical to one they already have in the database, so if you don't follow this part of the standard you probably don't get very far.
If you want to generate DICOM images, and you are unfamiliar with the standard, my advice is to use OFFIS img2dcm or a similar tool to convert them from normal images.
Jan de Vaan is correct, you SHOULDNT have duplicate headers with different image bitmaps and that is 'guaranteed' by the unique SOP instance UID. I've never seen a duplicate UID come from any modality. Saying that, there are sloppy applications with terrible UID implementations to generate the unique UID. There are teleradiology apps, secondary capture devices and other open source DICOM packages (for instance) that, typically on reset, could and do create a repeatable UID sequence. Many research labs get along fine with these. I expect you have one of these applications up the pipeline back to the source modality. If its messing up something as fundamental to DICOM as the UID, I would wonder what other wonderful things are happening.
If you must get these into the PACS, you would have to change the SOP Instance UID, which is not a recommended practice.
I was doing a project on dicom, and I found the DICOM Standard document(http://medical.nema.org/standard.html) is really a mess for programmers.For example when I come across a Tag(0008, 0060), I look into 11_03pu.pdf(http://medical.nema.org/Dicom/2011/11_03pu.pdf). It is said to be a modality with some value(GM, SM). Where could I find a more specific meaning about the tag and the value (GM, SM...) ?
The index of Part 3 contains a mapping from Tag to page. There you can find any reference to your tag in question. Looking at the referenced pages will show you how the tag is used, what it means in what situation and so on.
Well, dicom standard is your friend. But normally, any dicom parser contains what is called a dictionary that maps tag keys (two short numbers) to tag name and type. Without such a dictionary it is not possible to parse dicom data encoded implicitly.
Another thing you can look at is dicom modules (also defined in standard). Modules are groups of tags assembled by some global meaning (e.g. patient data, study data, equipment, image). Then you know for instance that for CR image one must put together patient, study, series, exposure, image plane, etc. modules in order to obtain a valid data set.
I would recommend you Digital Imaging and Communications in Medicine book, before reading dicom standard, this will ease your suffering.
you can also find more information with Dicom PS 3 as well in Tag Info
List of DICOM Tags are located under chapter 6 of DICOM Standard PS 3.6 or part 6. This list includes DICOM element Name, Tag number, Value Representation (VR) and Value Multiplicity (VM) of the tag value. Also, tag value encoding rules are located under sections 6 of PS 3.5 or part 5. See table 6.2-1.
You can download the DICOM standard from http://medical.nema.org/standard.html
I've created a topology for a video file which contains just one stream (no audio).
It contains three nodes which are connected in order:
a source stream node
an Mpeg4Part2VideoDecoder as transform node
an activate object for the EVR as output node
Calling SetTopology(), allowing for a partial topology results in working playback. However, I am trying to resolve the full topology myself.
Therefore, I first need to bind my output node to a media sink. I followed the guidelines specified in the manual, and all the required calls seem to succeed. When setting the full topology, I receive the MESessionTopologySet event.
Unfortunately, playback doesn't work, but I don't get any errors.
Is there anything else required when creating a full topology?
I recall reading somewhere in the msdn docs that the topology loader which is used when setting a partial topology also sets media types. Is this required, and if so where can I find more information on this?
Matt Andrews answered this one for me on the msdn forums.
You definitely need to negotiate your own media types if you are
bypassing the topology loader. This means obtaining the source's
media type from IMFMediaTypeHandler, setting it on the downstream
transform, and then for each node down the chain, querying the
available input and output types to find a compatible media type. It
is much easier to use the topoloader unless you have a specific need
to avoid it.