Does anyone have ANY information on creating a valid DICOM file with DCMTK?
1.2.840.10008.1.2.4.100 MPEG2 Main Profile Main Level
1.2.840.10008.1.2.4.102 MPEG-4 AVC/H.264 High Profile / Level 4.1
1.2.840.10008.1.2.4.103 MPEG-4 AVC/H.264 BD-compatible High Profile / Level 4.1
I understand that MPEG-4 is not currently released, but it in their development branch. I would assume that the process of creating an MPEG2 would be similar to MPEG-4?
Just to clarify, are the transfer syntaxs mentioned above multi-frame videos, where each frame (mpeg, h.264, etc) is wrapped as a DICOM image to create mutli-frame DICOM image? Or, do you simply take the mp4 file, and put some DICOM headers into the beginning of the file?
Anyways, does anyone have some sample code for creating a valid DCM file from either MPEG2 or MPEG4?
The current snapshot of the DCMTK contains all Transfer Syntax UIDs, i.e. the definition of what is listed in part 6 of the DICOM standard, which include various flavors of MPEG-2 and MPEG-4. Part 5 of the DICOM standard clearly describes how these transfer syntaxes are to be used, e.g. what the requirements for an MPEG data stream are and how the stream is to be encapsulated into the DICOM Pixel Data element.
By the way, DCMTK-related questions are probably better posted to the public discussion forum at http://forum.dcmtk.org/.
With regard to MPEG-4 AVC/H.264 High Profile / Level 4.1, you should read (at least) the relevant section in Part 5 of the DICOM standard: http://medical.nema.org/medical/dicom/current/output/chtml/part05/sect_8.2.7.html
NOTE: This answer has been fully edited on 20150407
I have done some tests to create mpeg4 DICOM video with the dcm4che2 toolkit. I assume that the same could be done in a similar manner with the DCMTK tools.
Answering to your second question, a DICOM video is just a video file (which must be compliant with some given constraints according to the video type) with some necessary DICOM data elements (attributes).
One way to obtain a DICOM video file is to create first an XML file containing the necessary DICOM data elements, and then to combine the XML file with the original video file. You will end up having a supposedly compliant DICOM instance containig the original video encapsulated in the (7FE0,0010) data element.
Your XML file will be something more or less like this:
<?xml version="1.0" encoding="UTF-8"?>
<dicom>
<attr tag="00020002" vr="UI" name="MediaStorageSOPClassUID">1.2.840.10008.5.1.4.1.1.77.1.4.1</attr>
<attr tag="00020003" vr="UI" name="MediaStorageSOPInstanceUID">1.3.51.5146.1682.20140505.1225531.197</attr>
<attr tag="00020010" vr="UI" name="TransferSyntaxUID">1.2.840.10008.1.2.4.102</attr>
<attr tag="00020012" vr="UI" name="ImplementationClassUID">1.2.40.0.13.1.1</attr>
<attr tag="00020013" vr="SH" name="ImplementationVersionName">dcm4che-1.4.18</attr>
<attr tag="00080005" vr="CS" name="SpecificCharacterSet">ISO_IR 100</attr>
<attr tag="00080008" vr="CS" name="ImageType">DERIVED\PRIMARY</attr>
<attr tag="00080012" vr="DA" name="InstanceCreationDate">20140505</attr>
<attr tag="00080013" vr="TM" name="InstanceCreationTime">135531</attr>
<attr tag="00080016" vr="UI" name="SOPClassUID">1.2.840.10008.5.1.4.1.1.77.1.4.1</attr>
<attr tag="00080018" vr="UI" name="SOPInstanceUID">1.3.51.5146.1682.20140505.1225531.197</attr>
<attr tag="00080020" vr="DA" name="StudyDate">20140505</attr>
<attr tag="00080022" vr="DA" name="AcquisitionDate">20140505</attr>
<attr tag="00080030" vr="TM" name="StudyTime">135531</attr>
<attr tag="00080032" vr="TM" name="AcquisitionTime">135531</attr>
<attr tag="00080050" vr="SH" name="AccessionNumber">2014505093198485</attr>
<attr tag="00080060" vr="CS" name="Modality">XC</attr>
<attr tag="00080070" vr="LO" name="Manufacturer">Test MFR</attr>
<attr tag="00080090" vr="PN" name="ReferringPhysicianName">Test^^^Dr^</attr>
<attr tag="00081030" vr="LO" name="StudyDescription">Test video HD</attr>
<attr tag="0008103e" vr="LO" name="SeriesDescription">Test video 720p</attr>
<attr tag="00082218" vr="SQ" vm="1" name="AnatomicRegionSequence">
<item>
<attr tag="00080100" vr="SH" name="CodeValue">T-32000</attr>
<attr tag="00080102" vr="SH" name="CodingSchemeDesignator">SRT</attr>
<attr tag="00080104" vr="LO" name="CodeMeaning">Heart</attr>
</item>
</attr>
<attr tag="00100010" vr="PN" name="PatientName">Smith^John^^Test^</attr>
<attr tag="00100020" vr="LO" name="PatientID">100539</attr>
<attr tag="00100030" vr="DA" name="PatientBirthDate">19700101</attr>
<attr tag="00100040" vr="CS" name="PatientSex">M</attr>
<attr tag="00180040" vr="IS" name="CineRate">30</attr>
<attr tag="00181063" vr="DS" name="FrameTime">33.33</attr>
<attr tag="0020000d" vr="UI" name="StudyInstanceUID">1.3.51.0.7.633920140505.6339234439.633987.633918098</attr>
<attr tag="0020000e" vr="UI" name="SeriesInstanceUID">1.3.51.5146.11682.20140505.122553197</attr>
<attr tag="00200010" vr="SH" name="StudyID">00000001</attr>
<attr tag="00200011" vr="IS" name="SeriesNumber">1</attr>
<attr tag="00200013" vr="IS" name="InstanceNumber">1</attr>
<attr tag="00200020" vr="CS" name="PatientOrientation"></attr>
<attr tag="00280002" vr="US" name="SamplesPerPixel">3</attr>
<attr tag="00280004" vr="CS" name="PhotometricInterpretation">YBR_PARTIAL_420</attr>
<attr tag="00280006" vr="US" name="PlanarConfiguration">0</attr>
<attr tag="00280008" vr="IS" name="NumberOfFrames">1080</attr>
<attr tag="00280009" vr="AT" name="FrameIncrementPointer">00181063</attr>
<attr tag="00280010" vr="US" name="Rows">720</attr>
<attr tag="00280011" vr="US" name="Columns">1280</attr>
<attr tag="00280100" vr="US" name="BitsAllocated">8</attr>
<attr tag="00280101" vr="US" name="BitsStored">8</attr>
<attr tag="00280102" vr="US" name="HighBit">7</attr>
<attr tag="00280103" vr="US" name="PixelRepresentation">0</attr>
<attr tag="00282110" vr="CS" name="LossyImageCompression">01</attr>
<attr tag="00400555" vr="SQ" name="AcquisitionContextSequence"></attr>
<attr tag="7FE00010" vr="OB">
<item />
<item src="test_720p.mp4"/>
</attr>
</dicom>
Once you have the XML file, combine it with the video file in order to obtain the DICOM file:
$ xml2dcm -d -t 1.2.840.10008.1.2.4.102 -x test_720.xml -o test_720.dcm
The resulting file has been tested with the dciodvfy tool and it seems to be a valid part 10 DICOM file.
Now, you can try to store this DICOM file into your PACS:
$ dcmsnd -L TEST YOUR.AET#yourpacs.com:11112 test_720.dcm
I have tested it, being able to recover and to reproduce the video with the Weasis DICOM viewer.
Some additional information just to clarify
SOP Class UID: 1.2.840.10008.5.1.4.1.1.77.1.4.1 (Video Photographic Image Storage)
Transfer Syntax UID: 1.2.840.10008.1.2.4.102 (MPEG-4 AVC/H.264 High Profile / Level 4.1)
So, the XML includes data elements from the Video Photographic Image IOD, in particular from the Cine Module. It must include also information from the Multiframe Module.
You can find additional information in this thread on the comp.protocols.dicom newsgroups.
Related
Given a DataMapper node that would map between the following two structures:
Strcuture A:
<item>
<id>123</id>
<price>1</price>
<quantity>1</quantity>
</item>
<item>
<id>124</id>
<price>2</price>
<quantity>1</quantity>
</item>
<item>
<id>125</id>
<price>3</price>
<quantity>1</quantity>
</item>
Structure B:
<total>
<totalPrice>6</totalPrice>
</total>
The Mule ESB DataMapper will generate a CTL2 (Clover) Transformation.
Can the Mule ESB DataMapper also generate XSLT
Do you mean to perform a XML transformation? Because if this is the case then yes.
If what you mean is to generate XSLT, technically I can, but makes no sense as XSLT is not meant to contain information but rather to transform it.
I guess XSLT (Extensible Stylesheet Language Transformations) is a language for transforming XML documents into other XML documents and I am afraid Data mapper cannot generate a XSLT ...
you can always use Mule XSLT transformer separately to transform data into your expected format of XML:- http://www.mulesoft.org/documentation/display/current/XSLT+Transformer
You can use XSLT component and provide an xsl file. This xsl file would be convert between 2 different sml formats.
Below is the example of mule flow for the same.
<file:connector name="File" autoDelete="true" streaming="true" validateConnections="true" doc:name="File"/>
<flow name="xsltexampleFlow">
<file:inbound-endpoint path="D:\Mule_Work\Input" connector-ref="File" responseTimeout="10000" doc:name="File"/>
<logger message="------------------File Read------------" level="INFO" doc:name="Logger"/>
<mulexml:xslt-transformer xsl-file="D:\Mule_Work\Output\transform.xsl" maxIdleTransformers="2" maxActiveTransformers="5" doc:name="XSLT"/>
<logger level="INFO" doc:name="Logger" message="--------------XSL Transformation---------------------"/>
<file:outbound-endpoint path="D:\Mule_Work\Output" outputPattern="Output_transform.xml" connector-ref="File" responseTimeout="10000" doc:name="File"/>
</flow>
I'm working with dexterity xml models and am looking for a way to extract i18n strings from my models. It doesn't look like i18ndude or infrae.i18nextract do this. As a result all the translations strings in my xml models don't show in the generated .pot files.
Some of the models have more than 30 fields, so manual extraction is becoming tedious.
i18ndude do extract i18n messages from model files without any issues; check you're including your domain and marking the strings to be extracted.
see our i18n script and check compare, as an example, collective.cover's model with yours:
<?xml version="1.0" ?>
<model xmlns="http://namespaces.plone.org/supermodel/schema"
xmlns:form="http://namespaces.plone.org/supermodel/form"
xmlns:i18n="http://xml.zope.org/namespaces/i18n"
i18n:domain="collective.cover">
<schema>
<field name="template_layout" type="zope.schema.Choice" form:widget="collective.cover.widgets.selectpreview.SelectFieldWidget"
form:omitted="z3c.form.interfaces.IEditForm:true">
<description i18n:translate=""
>Choose one of the predefined layouts</description>
<title i18n:translate="">Layout</title>
<vocabulary>collective.cover.AvailableLayouts</vocabulary>
<default>Empty layout</default>
</field>
<field name="cover_layout" type="zope.schema.Text"
form:omitted="z3c.form.interfaces.IForm:true
z3c.form.interfaces.IAddForm:true
z3c.form.interfaces.IEditForm:true">
<description i18n:translate=""
>The layout to be used to render groups and tiles</description>
<title i18n:translate="">Cover Layout</title>
</field>
</schema>
</model>
The data dictionary pretty much forces every node in Alfresco to have a sys:locale value:
<type name="sys:base">
<title>Base</title>
<mandatory-aspects>
<aspect>sys:referenceable</aspect>
<aspect>sys:localized</aspect>
</mandatory-aspects>
</type>
<!--
Localization:
If you add this aspect to a node, then the server will assume that all non-multilingual
properties apply to this locale.
-->
<aspect name="sys:localized">
<title>Translation</title>
<properties>
<property name="sys:locale">
<title>Locale</title>
<type>d:locale</type>
<mandatory>true</mandatory>
</property>
</properties>
</aspect>
I can imagine a whole lot of content where a locale does not make sense to me at all. Images, video, sound, code are a few examples. I would guess this locale is used for indexing tokenized string type properties. Still, I cannot see how that makes sense in the context of the content mentioned.
What exactly are the semantics of sys:locale and how is it used by Alfresco ?
The sys:locale serves as a fallback for the locale from the ContentData during indexing (if not set), so both #cm:content.locale and the tokenisation of d:content / d:text properties may / will be affected. In addition, sys:locale is used to differentiate the translations within the context of MultilingualContentService. On a site node, it affects the generated workflow descriptions for invitations.
sys:locale is not a real property in the sense that it is maintained in alf_node_properties - it is a virtual property much like sys:uuid derived from alf_node directly, which is why it affects even the content where it might not make much sense (apart from d:text property tokenization).
I have a question about creation of an RSS feed.
I have read a few different bits of information on creation of an RSS feed and this, on the whole doesn't appear too difficult.
What I'm struggling to understand though is how to automatically populate the RSS feed xml file?
Here is our basic .xml file...
<?xml version='1.0' encoding='utf-8'?>
<rss version='2.0'>
<channel>
<title>Channel Title</title>
<description>Description of Channel</description>
<link>http://www.test.com</link>
<item>
<title>Item Title</title>
<description>Updated on: 5/20/2012</description>
<link>http://www.test.com/itempage.asp?itemID=1</link>
</item>
</channel>
</rss>
We can, obviously, manually enter each item but I want this to automatically select the latest items from our database. In this case, news items.
you can use the Msxml2.DOMDocument.6.0 object. have a look here for MSXML DOM Reference.
with that object you can create xml nodes and then save the xml document...
example:
set xml = server.createobject("Msxml2.DOMDocument.6.0")
set rssNode = xml.createElement("rss")
rssNode.appendChild(xml.createTextNode(""))
rssNode.setAttribute "version", "2.0"
I am trying send a DICOM instance (an image in my case) from an application to a server.
But somehow it is not Happening.
The logs reveals that some tags were missing.
So what is the list of mandatory tags which are required during a DICOM association (a C-STORE in my case) ?
Which tags are mandatory is a function of what SOP class is used to represent the image. It varies. There are tables in part 3 of the DICOM standard (available at ftp://medical.nema.org/medical/dicom/2009/) which tell you which modules are required. Other documentation for individual tags will tell you if they are Type 1, 1C, 2, 2C, or 3. The Type 3 attributes are optional. The types with a C are mandatory under certain conditions and not mandatory under other conditions. Type 1 is always mandatory and must have a valid value. Type 2 is required to exist but can have a null value.
If you use dcm4chee, there is a dcm4chee/server/default/conf/dcm4chee-attribute-filter.xml with DTD stating following:
Minimal descriptor for DICOM Standard Conformance of Query/Retrieve Service:
<dcm4chee-attribute-filter>
<patient>
<attr tag="00080005"/>
<attr tag="00100010"/>
<attr tag="00100020"/>
</patient>
<study>
<attr tag="00080005"/>
<attr tag="00080020"/>
<attr tag="00080030"/>
<attr tag="00080050"/>
<attr tag="0020000D"/>
<attr tag="00200010"/>
</study>
<series>
<attr tag="00080060"/>
<attr tag="0020000E"/>
<attr tag="00200011"/>
</series>
<instance>
<attr tag="00080018"/>
<attr tag="00200013"/>
</instance>
</dcm4chee-attribute-filter>
While Matt's answer is absolutely correct, this should get you started faster.
If you are sending an DICOM image to server means it is C-STORE, so the server(PACS) which you are using checks for the Transfer syntax UID and also Some Header SOP Instance UID and Class UID, check your dicom tags whether the above stated tags are filled.