I would like to know how does a company (say Philips or Siemens) register private DICOM tags?
I mean:
How to ensure that the DICOM group is not taken by another manufacturer? Say Philips chooses the tags (1111, 00xx), so it needs to know that the group "1111" hasn't been taken.
After that, does NEMA need to be involved? Or any other organization that regulates these private tags?
There is no official "registry" of private DICOM tags, but publishing your private tags in the DICOM conformance statement is good practice.
To avoid collisions, each private tag belongs to a private creator name. The private creator usually contains the company name (or an abbreviation of it) and contains enough information to be able to relate it to a specific vendor, device and/or software. While there is no standard how it shall look, in practice this avoids collisions of private tags. So, while there is no guaranteed global uniqueness of private tags, in practice the combination of private group, private creator and tag offset ensures a reasonable distinction of different private tags.
Private creators are contained in tags with the element number from 0x10 to 0xff, so theoretically up to 240 private creators can co-exist for any private group. The private tag element number is always an offset (from 0x00 to 0xff), which is combined with the corresponding private creator tag, so for example the private tag (0041,0020) for a private creator located at (0041,0011) has the actual tag number (0041,1120). This is described in detail in PS3.5, section 7.8 in the DICOM standard.
So, to define your own private tags, you actually have to define a private creator name (prepend it with your company/organization name to ensure uniqueness), and than you can use all 256 possible tags in that private block. You don't have to check for the availability of the tags, just have to ensure a unique private creator that is used for these tags. A private tag is identified by the (odd) group number, the private creator and the tag element offset.
Reading and writing private tags using a DICOM toolkit usually demands that the private creator is given together with the group and the element offset to avoid any ambiguity. You can define your private tags in any allowed private group (e.g. odd groups >= 9), and your private creator will be written to the next free private creator tag, like this:
(0041,0010) SIEMENS XYZ
(0041,0011) ACME LTD XXX
(0041,0012) MY COMAPANY, MY PROD
(0041,1000) some SIEMENS private tag
(0041,1001) another SIEMENS private tag
...
(0041,1100) some ACME private tag
(0041,1101) another ACME private tag
...
(0041,1200) your own private tag
(0041,1201) another of your own private tags
If your DICOM framework does not handle this for you, you have to look for the first free private creator tag yourself, write your private creator in that tag, and use the corresponding tag range for your private tags. Of course, this is only relevant if you change existing DICOM files which already may contain some private tags.
Note that DICOM toolkits like DCMTK or pydicom usually contain a number of well-known private tags (together with their private creators), that have been collected from DICOM conformance statements and similar information.
Related
I learned that there is a public part and a private part in an Ada specification file (*.ads) and only the public part should be considered of the user of the compilation unit (usually a package).
It is actually not usual to separate the public and private part of the specification in different files?
So, finally, the user of such a package knows about the internals of the packages on specification layer but can not use it. Am I right here?
Thanks and cheers,
Wolfgang
No, Ada does not allow you to separate the public and private part of a package specification.
The original chief designer of Ada, Jean Ichbiah, did some work on a language, which actually separated the public, private (data structure) and implementation parts of a package, but this didn't become a part of Ada.
Also:
The private part and body of a child package can see the private part of its parent.
The specification of a private child package can see the private part of its parent.
... so you can't always just ignore the private part of a package specification completely.
A practical example:
When I write unit-tests, I like to put the test suite in a child package of the package I am testing. That way my test cases are not limited to inspect the public view of the types declared in the package.
We are running a project which contains some maps.
We have this under the node:
root.maps //object
It is a list of maps, in case some are private and some are public. Which is under the node:
root.maps.$mapId.config.isPrivate //boolean
root.maps.$mapId.config.uid //string
Now we have a problem. We listen on the maps node for changes, but we want only to return the public nodes, and the private nodes of the user.
So we added rules but it does not seem to work. The maps are either all displayed or none. When we try to set a restriction on a map itself it does not work.
Now after some searching on the internet we read that in order to manage the security rules well the private and public maps should be moved to private or public nodes.
So like this
root.maps.private.$mapId.uid
root.maps.public.$mapId.uid
Which I can't believe is true. In order to change this boolean value, we have to move the complete node from the public to the private node.
Is this really how this database should work? It does not sound logical at all to me.
Is there any other way on how to filter this data based on rules (maps should not be known to the client, client side filtering is not an option)
And if the really strange case of moving complete nodes based on changing boolean values is really true.
What is the idea behind it? This can't be true right?
I want to add few private tags to an existing DICOM image.
I would like to know which odd number tags I can use. Do I need to inform any organizations about my intentions ?
Private tags are typically just documented by a device manufacturer in the DICOM Conformance Statement for the product adding the private tags. The method for adding private tags was designed to prevent conflicts between manufacturers. When adding tags, you should develop in such away to prevent conflicts. Ie, to give an example, a typical DICOM tag is composed of a 2 byte group and a 2 byte element:
(gggg,eeee)
The group needs to be an odd number greater than 0008. Your private attributes are typically in a private block that have an associated private creator data element. The private creator is encoded as such:
(gggg,00bb)
where bb in the tag is an open private block in the DICOM object and has a value in the rage of 10-FF. This private block is where conflicts between vendors are dealt with. You must assign your private tags in the object to one of these blocks.
Finally, the private elements themselves are within the block:
(gggg,bbxx)
Where the block is encoded in the tag, and then the elements themselves are defined by xx. Your conformance statement should list your private identification code, the DICOM VR of the tag, the element number (xx) of the tag, along with a description of the tag so that other vendors can use the tag, if necessary.
If you want a more detailed explanation, it can be found in Part 5 of the DICOM Standard, starting in section 7.8.
if we can access the private members through setters and getters then what is the use of private?
You need the private to enforce Encapsulation. It is one of the fundamental paradigm of Object Oriented programming to keep the implementation of something separate from the interface. This reduces the coupling between your different program parts and in the long run make it more maintainable.
Take the following example :
class toto {
private String someThing;
public String getSomething();
public void setSomething(String Something);
}
If you change above to simply put someThing public, sure you have less code, but if one day that someThing needs to change to a more complex object for some new functionality while the old code could still work fine with a string then you need to change everything. By isolating the internal representation of someThing you can evolve your system much more easily
class toto {
private ComplexSomeThing someThing;
public String getSomething(){ someThing.toString();}
public void setSomething(String something){ something = new ComplexSomeThing(something);}
public ComplexSomeThing (getComplexSomething();
public void setComplexSomething(ComplexSomething someThing);
}
There are other reasons that makes encapsulation a Good Thing (tm), this is just a silly example to illustrate the point.
EDIT
There is somewhat of a debate right now as to using protected vs private or to use concepts akin to properties in some languages (Delphi, C#) rather than getters and setters (as in Java).
Protected rather than private will allow easier changes by the clients of the code but it does expose the innards of your system more so there is a balance to strive for between usability of the API and it's maintainability. However the basic principle of encapsulation remains.
Whatever the option chosen one still needs to expose functionality that is coherent and on the same level of abstraction and hide the gory details of how this is done.
To me the debate is not to declare a jihad against private but to find a way to provide extensibility and flexibility while not breaking the coherence of the API.
Here some interesting reading about private if you want to dig further. However I must stress that before forming an opinion about private you should really master the concepts of encapsulation and polymorphism, their apparent simplicity does hides some subtle complexities.
Because the getters and setters can act as a proxy. They make it so that you can hide the actual insides of the class, and only let the outside classes access the data through methods. Allowing you to treat the inners of the class however you want.
Just because your getter/setter is named getName() and your property is called name, doesn't mean it will always be that way.
What if you wanted to change the variable to be fullName. If you directly accessed public variables, the change would break a lot of code. Instead, you can simply remap where getName() retrieves its data from.
One of my best examples of this is my own URL class, where I allow for creating and manipulating a URL. If you want to set the scheme, you can get $obj->setScheme(). However, you don't know whether I am manually making the string every time you change the URL, whether I am storing them as separate parts. This gives me flexibility as I can store your data however I want to.
Furthermore, I can preform manipulations on the data before storing it. In my URL class, I assume that all schemes and host names are lowercase. I can standardize this by converting all strings saved via setHost() to lowercase, and then storing them. If I used a public variable, you would have to assume that the client that put the data in was correctly storing it.
They can also validate information that is being passed in to make sure that it is valid data, and cause an error if it isn't.
No one forces you to put in getters and setters for every variable. Indeed, blindly using private members + dummy getters & setters for every variable is pointless, even though many "object oriented encapsulation" tutorials do this all the time for some reason. For one thing, such encapsulation is no encapsulation from concurrency viewpoint.
I think what you really want to understand is why we use public properties with private backing fields, instead of just using public fields. There are several questions on SO like this; here's one:
What is the difference between a Field and a Property in C#?
I think you have good answers so far (information hiding and all that). Just want to add a suggestion about using setters.
As you mentioned using accessors makes private variables a bit pointless and in some environments performance consequence of using getters and setters just makes it worthless.
On the other hand if you don't have such concerns, I think using getters isn't so bad, but you should think twice before using setters. They make your object mutable which is especially hard to maintain in concurrent environments.
What's the best object layout in ASP.net or at least.. what are the advantages and disadvantages of either case:
Public Class Dog
Public Breed as String
Public Type as String
Etc....
OR the use of properties and keeping variables private
Somewhat of a debate among our team about it. Just wanted to hear thoughts.
Never expose fields directly.
Use properties with private backing fields. This allows you to change implementation and to encapsulate logic around getting/setting them.
See what the Visual Basic Team have to say on this.
Also, read about the differences between fields and properties.