Most efficient way to change the value of a specific tag in a DICOM file using GDCM - gdcm

I have a need to go through a set of DICOM files and modify certain tags to be current with the data maintained in the database of an external system. I am looking to use GDCM. I am new to GDCM. A search through stack overflow posts demonstrates that the anonymizer class can be used to change tag values.
Generating a simple CT DICOM image using GDCM
My question is if this is the best use of the GDCM API or if there is a better approach for changing the values of individual tags such as patient name or accession number. I am unfamiliar with all of the API options but have a link to the API documentation. It looks like the DataElement SetValue member could be used, but it doesn't appear that there is a valid constructor for doing this in the Value class. Any assistance would appreciated. This is my current approach:
Anonymizer anon = new Anonymizer();
anon.SetFile(myFile);
anon.Replace(new Tag(0x0010, 0x0010), "BUGS^BUNNY");

Quite late, but maybe it would be still useful. You have not mention if you write in C++ or C#, but I assume the latter, as you do not use pointers. Generally, your approach is correct (unless you use System.IO.File instead of gdcm.File). The value (second parameter of Replace function) has to be a plain string so no special constructor is needed. You should probably start with doxygen documentation of gdcm, and there is especially one complete example. It is in C++, but there should be no problems with translation.

There are two different ways to pad dicom tags:
Anonymizer
gdcm::Anonymizer anon;
anon.SetFile(file);
anon.Replace(gdcm::Tag(0x0002, 0x0013), "Implementation Version Name");
//Implementation Version Name
DatsElement
gdcm::Attribute<0x0018, 0x0088> ss;
ss.SetValue(10.0);
ds.Insert(ss.GetAsDataElement());

Related

Automatic documentation of an OO MATLAB project with mtoc++/Doxygen

I have an OO project in MATLAB and would like to automatically produce some documentation.
After some research I have found a convenient tool called mtoc++ which apparently produces a documentation using Doxygen (I have no experience with).
My only question is whether in order to use the tool I need to write comments in MATLAB using a specific format (language?) so that mtoc++/Doxygen could understand and document my comments?
If so, then what this format/ language is and where I can find its description?
After correctly installing and configuring mtoc++/Doxygen, the documentation is created automatically.
If you want to define personalized comments for specific custom parameters, you can follow the instructions on this page:
http://www.ians.uni-stuttgart.de/MoRePaS/software/mtocpp/docs/tools.html
Look under the heading Configuration options for the mtoc++ filter.
What you have to do is to edit the mtocpp.conf file, located in tools/config folder, and the format you'll be using is this:
add(params) = <parameter1_name> => """Your parameter1 description text in triple quotes""";
An example would be:
add(params) = myVariable => """This variable is defined by me""";
So you can define personalized comments for your Parameters, Fields, Extra Documentation and Global Settings.
I am sure there must be other workarounds to add comments and documentation.
I hope this helps. Happy coding.

i18n in Symfony Forms

Is there any way I can use the format_number_choice function inside of a actions file. In fact I need to use it for a Form error message.
'max_size' => 'File is too large (maximum is %max_size% bytes).',
In English it's simply "bytes", but in other languages the syntax changes after a certain value (for example if the number is greater than 20 it's: "20 of bytes").
I can use parenthesis, of course, but if the framework offers support for doing this specific thing, why not to use it?!
The way it's currently implemented in the 1.4 branch, you can define only one translation per message using il18n XML files.
What you could do is create a custom validator which inherits the current validator (sfValidatorFile in your example) and does the size checking in the doClean method before calling its parent's method.
I suggest you take a look at the source to see how it works : sfValidatorFile
The correct way to handle number ranges for translation is explained here in the Definitive Guide. I won't reproduce it here as the documentation itself is clear and concise. Note however that the string is not extracted automatically by the i18n-extract task, so you need to add it manually - again, the documentation explains this.
So yes, you can use the format_number_choice() function inside an action - you just need to load the helper inside the action like this:
sfContext::getInstance()->getConfiguration()->loadHelpers('I18N');

Extracting function call list from DOxygen XML Output

I posted a question on the DOxygen forums and also am posting it here for a better response.
I have a moderately sized C project of about 2,900 functions. I am using DOxygen 1.5.9 and it is successfully generating a call graph for the functions. Is there a way to extract this out for further analysis? A simple paired list would be sufficient, e.g.
Caller,Callee
FunctionX, FunctionY
...
I am comfortable with XSLT but I must say that the DOxygen XML output is complex. Has anyone done this before and can provide some guidance on how to parse the XML files?
Thanks in advance!
Based on what I see in the contrived example that I created,
Parse files with a name similar to ^_(.+)\d+(c|cpp|h|hpp)\.xml$, if my regex-foo is right.
Find all <memberdef kind="function">. It has a unique id attribute. I believe the XPath for this is //memberdef[#kind='function'].
Within that element, find all <references>.
For each of those tags, the refid attribute uniquely refers to the id attribute of the corresponding <memberdef> that is being called.
The text node within each <references> corresponds to the <name> of the corresponding <memberdef> that is being called.
This seems like a nice, straightforward way to express call graphs. You should have no trouble using XSLT or any other sane XML-parsing suite to get the desired results.

How do I dynamically create a read-only contract in Perl?

My attorney gave me a 10 page contract that we need to fill in the blanks with the client name, pricing etc and then provide the client with a PDF or equivalent of the contract.
I have looked at PDF::Create but it looks like I would have to create the entire document through code, not just the the placeholders.
CAM::PDF, PDF::API2 can modify existing documents. Your question is not very specific, so no code example.
I would look into using a templating system and LaTeX rather than making the pdf by hand.

Using YAML tags to denote types

I don't quite understand how to use application specific YAML tags, and maybe its because my desired use of them is purely wrong. I am using YAML for a configuration file and was hoping to use tags to provide my configuration loader with a hint as to what datatype it should parse the data into - application specific datatypes.
I'm also using libyaml with C.
So I'm trying to do something like...
shapes:
square: "0,4,8,16"
circle: "5,10"
In my app I'd like to use tags as hints so I can load the values of square into my square data structure, and the values of circle into my circle data structure (these values mean nothing in this example).
So I'm currently doing:
shapes:
square: !square "0,4,8,16"
circle: !circle "5,10"
Libyaml will provide a tag of "!square" when I'm passed the scalar "0,4,8,16". Is it valid to use this tag to provide my loader with a hint of how to process the scalar?
Since it does work for me, I'm more curious to know if its proper. And if not, how would I go about making this more proper.
Thanks.
I know that this is an ancient question, but anyway I've seen !int, etc being used in yaml files before so I went to look up the specs at Yaml 1.2 Spec # Tags
application specific tag: !something |
The semantics of the tag
above may be different for
different documents.
As per the document, it does look like your intended usage of tags is correct for application specific tag.