MONTEVIDEO - FING2009 - DICOM Dicom (Digital Imaging and COmmunication in Medicine/imagen médica digital) Introducción Importancia Más de 20 años de existencia Universal En libre acceso: http://www.dclunie.com/dicom-status/status.html Visualizadores DICOM opensource: http://www.idoimaging.com Newsgroups: http://groups.google.com/group/comp.protocols.dicom Evento anual de nivel mundial: RSNA a fines de noviembre cada año en Chicago No confundir con un formato de imagen Dicom contiene imágenes de formatos estándares (TIF, JPG, RLE, JP2, MPG, MP2). Próximamente MP4 y probablemente H264 también. Además DICOM soporta muchos codecs para estos formatos. Pero la caracteristica esencial que diferencia DICOM de cualquier formato de imagen es el vínculo: imagen - circumstancias identificadas mediante referencias precisas del evento de captura y de las evenctuales transformaciones de la misma En Dicom, las imágenes son instancias de clases Objeto de Información Definidos (IOD) en la norma con atributos obligatorios, opcionales y condicionales. Las instancias están identificadas por medio de (UID=Unique IDentifier) Durante los primeros años de desarrollo de DICOM, muchos atributos eran opcionales. Desde 5 años aparecen nuevas classes DICOM (nuevos objetos de información), llamados enhanced, (mejorados) con mucho más atributos obligatorios, con el fin de evitar riesgos de interpretación equivocada cuando se estudia un archivo DICOM desde una estaciónes de trabajo de varios fabricantes. Creo que el ingeniero biomédico es quién entre el informático y el médico tiene que prestar particular atención a que este vínculo esencial en DICOM entre imagen y circunstancias de adquisición no se pierda en el mecanismo de la transmisión y de la representación. Ejemplos: - print : todo lo necesario tiene que estar adentro de la imagen - izquierda - derecha: preocuparse que el workflow desde la adquisición hasta la pantalla garantice la orientación correcta de la imagen.
- teleradiología : jpg Otros capitulos dónde el ingeniero biomédico tiene que especializarse: Calidad de imagen y monitores (curso 2) RIS e interoperabilidad IHE (curso 4) Conformidad de equipos a la norma (curso 4 y 17) Transmisión, tipo de imágenes y volumen de las mismas para cada modalidad (curso 16) Debug de red DICOM (curso 17) Política de implementación, evaluación de tecnología, simplificación de workflows (curso 17) Objetivo de este curso sobre la norma DICOM: ser capaz de usar la norma para poder leer un archivo binario DICOM En muchos casos de problemas de comunicación, es un ejercicio a realizar para evaluar el problema y encontrar solución. Las introducción que explican la estructura del archivo DICOM en general copian unas páginas de la parte 5 de la norma, sin entrar en los detalles que esta parte expone. Cuando uno intenta leer el archivo, necesita estos detalles, pues recomiendo trabajar directamente desde la norma. La norma esta subdividida en 18 partes, de las cuales el contenido se incrementa año tras año con correcciones y suplementos. Para leer un archivo DICOM necesitamos referirnos a: 5 Data Structures and Encoding capitulo 6.1 charset (hoy solo usaremos ISO-100, ASCII, para simplificar) capitulo 6.2 value representation (tipo de data) capitulo 7 dataset (conjunto de tags con su(s) valores) capitulo 7.5 nesting of dataset (encapsulación) capitulo 8 pixel y compresión anexo A transfer syntax 6 Data Dictionary 3 Information Object Definitions Se bajan de internet en formato word o pdf, tienen índice muy detallado Encontrar la la información que uno busca La forma electrónica tiene la virtud de poder buscar por palabra adentro del texto. Esta posibilidad es potenciada cuando el objeto buscado tiene una síntaxis particular. Es el caso de los UID y tags. UID - IOD Information Object Definition (grupo de atributos que definen una clase de objeto) - UID Unique IDentifier (identificador de una instancia única de una clase de objeto)
UIDs, en particular cuando se habla de ellos en relación con HL7, están llamados también OID (Object IDentifier). Para hacerlo sencillo, cuando termina en ID, se trata de un IDentificador. UIDs son constituidos de números decimales (que no empiezan con la cifra 0) unidos por puntos para formar una secuencia. Por ejemplos : 1.2.840.10008.5.1.4.1.1.12.1 1.3.6.1.4.1.23650.1.1.33.9 El UID conlleva algo de semántica. En particular, el principio del UID, llamado raíz es un número único que hace referencia a tal o cual organización. Este tipo de notación esta promocionado por el ISO (International Standard Organization). En nuestros ejemplos: 1.2.840.10008 = DICOM 1.3.6.1.4.1.23650 = OPENDICOM El resto del UID esta definido como lo entiendo cada institución raíz. Casi siempre los números sucesivos permiten definir categorias, subcategorías y refinar los conceptos hasta obtener la identificación de un objeto único. El OID es útil para realizar búsquedas dentro de la norma, por ser referencia de sintaxis determinada e independiente de cualquier idioma. Occurre que el OID es útil para realizar búsquedas también dentro de un archivo DICOM, porque en el archivo esta transcrito con caracteres ASCII, de izquierda a derecha, un carácter por cifra o punto. TAG El tag es un identificador de atributo. En la literatura, siempre aparece en la forma de 2 grupos de cifras hexadecimales separadas por coma y envueltos entre parentesis. Ejemplo: (7FE0,0010) Este tag anuncia el principio del atributo que contiene los pixeles de la imagen. Dentro del archivo, los tags están dispuestos por orden creciente. Los tag pares están definidos adentro de la norma DICOM Se autoriza a fabricantes definir tags afuera de la norma. En este caso, tienen que ser impares y documentados dentro del certificado de conformidad a la norma dicom que se requiere de un equipo presentado como equipo DICOM. Los numeros de tag no son tan sistemáticos como los OID. Igual algo de clasificación hay en función del primero número, considerado como grupo. Por ejemplo (0010, se refiere a atributos de identificación del paciente. IOD módulo tag
Cada uno de los módulos, que puede ser parte de varios objetos, esta definido en el Anexo C. Ahí vemos la lista de los tags que constituyen cada uno de los módulos que constituyen el archivo de angiografía. Por cierto, que los modulos mismos usan tags especificos y tags generales, usados en otros módules también.
Little y Big Endian Eso es fácil cuando buscamos dentro de la documentación. Es más complejo cuando buscamos por el tag dentro de un archivo. Porqué ahí la codificación, al contrario de la codificación del OID, no es mediante caracteres ASCII. Ambas partes del tag están codificadas como unsigned short (2 bytes). 2 bytes para el grupo, seguidos de 2 bytes para el elemento. No parentesis ni coma. Por si no fuese suficiente complicación, el orden de los 2 bytes no es siempre el mismo. Si el archivo esta codificado Little Endian, el primer byte representa las unidades y el segundo las "hexadecenas". Si el archivo esta codificado Big Endian, el orden es a revés. Al mirar 7FE00010 (big endian) y E07E1000 (little endian), no es obvio adivinar que se trata del mismo tag. En la representación hexadecimal un byte permite indicar valores entre 0 y 255 (00 a FF) pues en esta notación el byte esta representado por 2 caracteres... (2 bytes para el grupo son 4 caracteres, y 2 bytes para el elemento, son 4 más, que dan un total de 8 characteres... ojo no es ASCII es una representación de binario.
Explicit implicit Pero existe también otra forma de codificar, dónde luego del tag, se precisa explicitamente el tipo de datos que siguen. Podría haber sido deducido del tag mediante una tabla de tags y tipos de datos correspondientes, pero en este caso de codificación explicita, luego del tag se le añade 2 caracteres ASCII que precisan el tipo de datos. Esos 2 caracteres, por ser ASCII, son fáciles de reconocer. En resumen la diferencia entre implicit y explicit es que explicit copia a continuación de cada tag dentro del archivo DICOM la correspondencia con un tipo de datos que esta definido en el diccionario sintáctico de los tags DICOM (estándar, parte 6) Ven el tag, su significado, el tipo de datos (VR=value representation) implicado por el tag y la cardinalidad (VM=value multiplicity) de valores autorizados para este tag. Las letras PN, LO, CS,... son tipos de datos DICOM. Una lista completa de los mismos se encuentra en la parte 5 de la norma.
Transfer syntax ILE, ELE, EBE Combinando Big y Little Endian de un lado y explicit implicit del otro, tenemos 3 "transfer syntax" (=codificaciones) definidas para transportar informacieon DICOM (IBE no esta definido). Explicit Big Endian : útil para plataformas PowerPC porque tiene la todas las variables multibyte representadas en el mismo orden en el cual las necesita el procesador. Se ahora en este caso la necesidad de realizar un "byte swap" (permutación de los bytes representando una variable multibytes) antes poder usarla. Pues se ahora mucho tiempo de procesamiento y de complicaciones. Implicit Little Endian: codificación que cualquier estación DICOM tiene que saber manejar. Es un requisito de la norma misma. Explicit Little Endian: base para todos los tipos de archivos DICOM que tienen la data de los pixeles
comprimida. Explicit Big Endian se usa cada vez menos, ahora que la arquitectura INTEL (que es little endian) se encuentra en casi todas las computadoras. Implicit Little Endian ahora muy poco espacio sin estos 2 characteres ascii sin permitir datos de pixeles comprimidos. Hasta el intel Pentium 4 y ibm powerpc G4, comprimir en formatos sin perdida (lossless) tal por ejemplo jpeg 2000 lossless mejoraba la velocidad de transmisión pero provocaba un cuello de botella al momento de descomprimir las imágenes para presentarlas en pantalla. Las computadoras desde intel core 2 duo arriba cambiaron el panorama y hacen interesante ahora workflows comprimidos, más aún cuando los estudios superan las 1000 imágenes como puede ser el caso con el tomografo 64 cortes que viene al hospital de Clínicas, por ejemplo. Pues, Explicit Little Endian, la única codificación de archivo DICOM estándar para acompañar datos de pixel comprimidos, es y será cada vez la más usada. public.data org.nema.dicom +-----------------+-----------------+ ELE EBE ILE
+---------+... +---------+... +---------+... ELEIMG... EBEIMG... ILEIMG... +---------+---------+--------+-----------+---------+----------+ RLE ELEZIP JPEG-LS J2K1 JPIP MPEG2 +---------+---------+---------+ JP1 JP2 JP4 JP14 J2K2 JPIPZIP JP141 Las opciones de síntaxis de transferencia están identificadas mediante UID (Unique IDentificadores): 1.2.840.10008.1.2.2 EBE Explicit VR Big Endian 1.2.840.10008.1.2 ILE Implicit VR Little Endian 1.2.840.10008.1.2.1 ELE Explicit VR Little Endian 1.2.840.10008.1.2.1.99 ELEZIP Deflated Explicit VR Little Endian... todas las sintaxis de transferencia siguiente son ELE para todos los tags salvo el tag que contiene los pixeles 1.2.840.10008.1.2.4.50 JP1 JPEG Baseline (Process 1): Default Transfer Syntax for Lossy JPEG 8 Bit Image Compression... (lista completa en la parte 6 anexo A de la norma) En suma, es preciso conocer primero la síntaxis de transferencia, antes analizar el contenido del dataset DICOM (conjunto de datos), porque eso nos indica el orden de los bytes en las variables multibyte y si esta escrita la información sobre los tipos de datos utilizados. Disponemos de UIDs para anunciar cual es la sintaxis de transferencia. Solo nos falta espacio antes el dataset para almacenar esta información.
Preámbulo y estructura del archivo DICOM Proveer esta y otras informaciones generales es el propósito del preámbulo al dataset DICOM. Con la excepción de archivos viejos, todos los archivos DICOM actuales empiezan con tal preámbulo. El preámbulo esta siempre escrito en ELE y contiene la información de sintaxis de transferencia para el resto del archivo. Estructura archivo DICOM: Archivo Preámbulo bytes 0-127 libres bytes 128-131 "DICM" (firma DICOM) metadata (codificado en ELE) Dataset (0002,0000) File Meta Information Group Length UL 1 (0002,0001) File Meta Information Version OB 1 (0002,0002) Media Storage SOP Class UID UI 1 (0002,0003) Media Storage SOP Instance UID UI 1 (0002,0010) Transfer Syntax UID UI 1 (0002,0012) Implementation Class UID UI 1 (0002,0013) Implementation Version Name SH 1 (0002,0016) Source Application Entity Title AE 1 (0002,0100) Private Information Creator UID UI 1 (0002,0102) Private Information OB 1 atributos clasificados por orden creciente y codificados EBE, ILE o ELE en función de (0002,0010) atributo (7FE0,0010) conteniendo los pixeles codificados, comprimidos en función de (0002,0010) "trailing atribute" (es posible crear atributos privados con numero más elevado que el atributo pixel, para encapsular algo)
Estructura de un atributo El atributo empieza por el tag, sigue el tipo de data, luego el tamaño y la data. La parte 5 anexo A es muy importante de estudiar antes poder entender cada byte en la codificación. Eso sería el tema de otro curso más especializado. Atributos secuencias Un tipo de dato particular SQ (secuencia) viene viene complicar un poquito más toda esta estructura hasta ahora perfectamente linear. Se trata de tener atributos que contienen elementos compuestos de atributos. Pueden contener cero, uno o muchos elementos, cada uno de los cuales tienen la misma estructura, o por lo menos contienen los mismos atributos obligatorios (más eventuales atributos opcionales). Esta posible encapsulación es a su ves recursiva. O sea es posible enfrentarse con un atributo que contiene varios elementos que contienen varios atributos, de los cuales uno o muchos son secuencias de elementos de atributos, y así sucesivamente. Para agregar un poco de fun... existen 2 maneras de indicar las fronteras de cada elemento y la cantidad de los mismos. La parte 5 de la norma, capitulo 7.5 "Nesting of Datasets" explica todo eso, con ejemplos que son muy útiles. Una de las consecuencias de estas posibles encapsulación es que el orden de los tags adentro del archivo DICOM no es estrictamente del tag más chico al más grande. Sigue correcto cuando nos quedamos en un mismo nivel de encapsulación y no analizamos el contenido de las secuencias. Porque sino, los tags contenidos dentro de las secuencias están todos agrupados adentro de las mismas,
respetan su propio orden, no el orden general del archivo. Estrategía de descubrimiento: pasar por una representación xml Por ser un primer curso sobre el tema, no vamos a elegir el camino de descubrimiento pasando por el estudio de la norma antes analizar ejemplos. Vamos a inmergirnos directamente dentro de un ejemplo, pero ayudándonos con una representación del archivo ya "pre-masticado". En efecto, todo lo que vimos hasta ahora de elementos (un atributo DICOM es un elemento) que están agrupados en estructuras más grandes, cabe perfectamente en un modelado xml, dónde todo se escribe en texto, con estructuras fáciles de reconocer, y representados con mucha claridad gracias a editores de xml especializados. Nuestra estrategía entonces será de comparar el contenido binario del archivo DICOM con el mismo contenido "pre-masticado" en xml para encontrar las correspondencias y analizarlas de a una. Dos aclaraciones de vocabulario: Atributo En la terminología DICOM, un atributo es un elemento de la definición de un objeto de información En la terminología XML, un atributo es un nodo terminal identificado y valorado con un solo valor, al contrario del nodo elemento que puede contener otros nodos (sean elementos, atributos, texto, etc). En notación XML, el atributo siempre aparece como nombre="valor" adentro del tag inicial de un elemento. Ejemplo: <elementox atributoy="valorz"> contenido del elementox </elementox> Tag En la terminología DICOM, el tag es el identificador ubicado al principio de un elemento compuesto de unsignedshort1 unsignedshort2. En la documentación, para facilitar la lectura se representan los unsignedshort1 unsignedshort2 como (1111,2222). En XML, el tag esta compuesto de 2 mardadores espejados indicando el principio y el final del elemento. Se reconocen como marcador por su encapsulación entre <> y se diferencia el principio del final por un / como primer caracter del final. Ejemplo <elemento> contenido </elemento> Esta representación es la misma en el archivo y en la documentación, porque xml es un formato textual y no binario.
DICOM > XML Existen varias herramientas que lo hacen, disponibles para todas las plataformas informáticas. Las 3 más conocidas son herramientas que pertecen a los conjuntos de herramientas siguientes: dcmtk C, C++ nombre herramienta dcm2xml bajar http://dicom.offis.de/dcmtk.php.en documentación http://support.dcmtk.org/docs/ dcm4che1 java nombre herramienta dcm2xml.jar bajar http://sourceforge.net/project/showfiles.php? group_id=37982&package_id=50497 documentación opciones descritas desde el comando ejecutado en el terminal sin parámetros o con --help dcm4che2 java nombre herramienta dcm2xml bajar http://sourceforge.net/project/showfiles.php? group_id=37982&package_id=192320 documentación hhttp://www.dcm4che.org/confluence/display/d2/dcm4che2+dicom+toolkit Ejemplo: Después de haber bajado e instalado dcm4che1, desde el terminal: 125 15:bin jacquesfauquex$ cd /dcm4che 1.4.22/bin 125 15:bin jacquesfauquex$ java jar dcm2xml.jar dcm2xml.jar: Missing argument Usage: java jar dcm2xml.jar <dcm_file> [ o <xml_file>] [ bx] [ x <tag> [,...]] [ L <maxvallen>] [ d <basedir>] [[ TXT XSL <xsl_file>] [ I][ D<param>=<value> [,...]]] Transform the specified DICOM file <dcm_file> into XML and optionally apply XSLT with the specified XSL stylesheet <xsl_file> to the XML presentation. Options: o <xml_file> Place output in <xml_file> instead in standard output. b Brief format: exclude attribute names from XML output. X Exclude pixel data from XML output. Same as xpixeldata x <tag> Exclude value of specified tag from XML output. Format: ggggeeee or attribute name L <maxvallen> Exclude values which length exceeds the specified limit from XML output. d <basedir> file excluded values into directory <basedir>. T, TXT Apply default XSLT to produce text output: Dmaxlen=<maximal line length> [79] Dvallen=<displayed value length> [64] Dvaltail=<truncation position from value tail>. [8] Dellipsis=<truncation mark>. ['...'] S, XSL <file> Apply XSLT with specified XSL stylesheet <file>. I Enable incremental XSLT (only usable with XALAN) D<param>=<value> Set XSL parameter to specified value. Ya tenemos la descripción del comando. Los datos de pixel son esencialmente numéricos y muy grandes pues poco interesantes a representar
en XML. Pues usaremos la opción -X También limitaremos la representación de atributos demasiado grandes con la opción -L 65. Ponemos un límite superrio al tamaño máximo de un UID para no tenerlos escondidos. Tengo un archivo DICOM llamado xa.dcm a la raíz de mi disco de arranque, pues desde el terminal, ejecutando el comando java -jar dcm2xml.jar -X -L 65 /xa.dcm obtengo el listado siguiente: 125 15:bin jacquesfauquex$ java jar dcm2xml.jar X L 65 /xa.dcm <?xml version="1.0" encoding="utf 8"?> <dicomfile> <filemetainfo> <preamble>73\73\42\0\252\18\66\1\70\1\50\0\176\155\116\26\0\8\0\0\58\6\0\0\252\18\66\1\ 4\0\0\0\243\81\20\0\101\70\88\65\0\0\0\0\0\0\0\0\52\3\0\0\10\0\0\0\30\3\0\0\14\0\0\0\70 \3\0\0\8\0\0\0\200\4\0\0\50\0\0\0\2\5\0\0\50\0\0\0\82\5\0\0\2\0\0\0\8\0\0\0\0\0\0\0\198 \1\0\0\56\0\0\0\92\5\0\0\2\0\0\0\102\5\0\0\2\0\0\0</preamble> <attr tag="00020000" vr="ul" pos="132" name="group Length" vm="1" len="4">202</attr> <attr tag="00020001" vr="ob" pos="144" name="file Meta Information Version" vm="1" len="2">0\1</attr> <attr tag="00020002" vr="ui" pos="158" name="media Storage SOP Class UID" vm="1" len="28">1.2.840.10008.5.1.4.1.1.12.1</attr> <attr tag="00020003" vr="ui" pos="194" name="media Storage SOP Instance UID" vm="1" len="56">1.3.46.670589.7.5.10.80008191025.20070731.155457.12.1.1</attr> <attr tag="00020010" vr="ui" pos="258" name="transfer Syntax UID" vm="1" len="20">1.2.840.10008.1.2.1</attr> <attr tag="00020012" vr="ui" pos="286" name="implementation Class UID" vm="1" len="28">1.2.276.0.7230010.3.0.3.5.4</attr> <attr tag="00020013" vr="sh" pos="322" name="implementation Version Name" vm="1" len="16">offis_dcmtk_354 </attr> </filemetainfo> <dataset> <attr tag="00080005" vr="cs" pos="346" name="specific Character Set" vm="1" len="10">iso_ir 100</attr> <attr tag="00080008" vr="cs" pos="364" name="image Type" vm="4" len="38">original\primary\single PLANE\SINGLE A</attr> <attr tag="00080016" vr="ui" pos="410" name="sop Class UID" vm="1" len="28">1.2.840.10008.5.1.4.1.1.12.1</attr> <attr tag="00080018" vr="ui" pos="446" name="sop Instance UID" vm="1" len="56">1.3.46.670589.7.5.10.80008191025.20070731.155457.12.1.1</attr> <attr tag="00080020" vr="da" pos="510" name="study Date" vm="1" len="8">20070731</attr> <attr tag="00080021" vr="da" pos="526" name="series Date" vm="1" len="8">20070731</attr> <attr tag="00080022" vr="da" pos="542" name="acquisition Date" vm="1" len="8">20070731</attr> <attr tag="00080030" vr="tm" pos="558" name="study Time" vm="1" len="12">143119.0000 </ attr> <attr tag="00080031" vr="tm" pos="578" name="series Time" vm="1" len="12">143119.0000 </attr> <attr tag="00080032" vr="tm" pos="598" name="acquisition Time" vm="1" len="12">145932.0000 </attr> <attr tag="00080050" vr="sh" pos="618" name="accession Number" vm="0" len="0"/> <attr tag="00080060" vr="cs" pos="626" name="modality" vm="1" len="2">xa</attr> <attr tag="00080070" vr="lo" pos="636" name="manufacturer" vm="1" len="38">philips Medical Systems (Netherlands) </attr> <attr tag="00080080" vr="lo" pos="682" name="institution Name" vm="1" len="14">hhhhh HOSPITAL</attr> <attr tag="00080081" vr="st" pos="704" name="institution Address" vm="0" len="0"/> <attr tag="00080090" vr="pn" pos="712" name="referring Physician's Name" vm="0" len="0"/> <attr tag="00081010" vr="sh" pos="720" name="station Name" vm="1" len="6">visub </attr> <attr tag="00081050" vr="pn" pos="734" name="performing Physician's Name" vm="1" len="2">vp</attr> <attr tag="00081070" vr="pn" pos="744" name="operator's Name" vm="1" len="2">vp</attr>
<attr tag="00081090" vr="lo" pos="754" name="manufacturer's Model Name" vm="1" len="28">p H I L I P S INTEGRIS V</attr> <attr tag="00100010" vr="pn" pos="790" name="patient's Name" vm="1" len="14">de XXXX^YYYYY </attr> <attr tag="00100020" vr="lo" pos="812" name="patient ID" vm="1" len="10">7777777 1 </attr> <attr tag="00100030" vr="da" pos="830" name="patient's Birth Date" vm="1" len="8">19360520</attr> <attr tag="00100040" vr="cs" pos="846" name="patient's Sex" vm="1" len="2">f </attr> <attr tag="00180060" vr="ds" pos="856" name="kvp" vm="1" len="2">83</attr> <attr tag="00181020" vr="lo" pos="866" name="software Version(s)" vm="3" len="18">7.7.2\5.3.1\3.3.1 </attr> <attr tag="00181030" vr="lo" pos="892" name="protocol Name" vm="1" len="14">cerebral (fr) </attr> <attr tag="00181065" vr="ds" pos="914" name="frame Time Vector" vm="10" len="40">0.0\320\320\320\320\320\320\320\320\240 </attr> <attr tag="00181066" vr="ds" pos="962" name="frame Delay" vm="1" len="4">320 </attr> <attr tag="00181110" vr="ds" pos="974" name="distance Source to Detector" vm="1" len="4">1094</attr> <attr tag="00181150" vr="is" pos="986" name="exposure Time" vm="1" len="4">150 </attr> <attr tag="00181151" vr="is" pos="998" name="x ray Tube Current" vm="1" len="4">182 </attr> <attr tag="00181155" vr="cs" pos="1010" name="radiation Setting" vm="1" len="2">gr</attr> <attr tag="00181162" vr="ds" pos="1020" name="intensifier Size" vm="1" len="10">169.99998 </attr> <attr tag="00181500" vr="cs" pos="1038" name="positioner Motion" vm="1" len="6">static</attr> <attr tag="00181510" vr="ds" pos="1052" name="positioner Primary Angle" vm="1" len="12"> 0.40000001 </attr> <attr tag="00181511" vr="ds" pos="1072" name="positioner Secondary Angle" vm="1" len="12"> 0.40000001 </attr> <attr tag="00190010" vr="lo" pos="1092" vm="1" len="16">cardio D.R. 1.0 </attr> <attr tag="00191000" vr="cs" pos="1116" vm="2" len="20">rectangular\circular</attr> <attr tag="00191002" vr="is" pos="1144" vm="1" len="2">1 </attr> <attr tag="00191004" vr="is" pos="1154" vm="1" len="4">1024</attr> <attr tag="00191006" vr="is" pos="1166" vm="1" len="2">1 </attr> <attr tag="00191008" vr="is" pos="1176" vm="1" len="4">1024</attr> <attr tag="00191010" vr="is" pos="1188" vm="2" len="8">512\512 </attr> <attr tag="00191012" vr="is" pos="1204" vm="1" len="4">570 </attr> <attr tag="0020000d" vr="ui" pos="1216" name="study Instance UID" vm="1" len="50">1.3.46.670589.7.5.8.80008191025.20070731.143119.1</attr> <attr tag="0020000e" vr="ui" pos="1274" name="series Instance UID" vm="1" len="50">1.3.46.670589.7.5.7.80008191025.20070731.143119.1</attr> <attr tag="00200010" vr="sh" pos="1332" name="study ID" vm="1" len="14">31072007143119</attr> <attr tag="00200011" vr="is" pos="1354" name="series Number" vm="1" len="2">1 </attr> <attr tag="00200012" vr="is" pos="1364" name="acquisition Number" vm="1" len="2">12</attr> <attr tag="00200013" vr="is" pos="1374" name="instance Number" vm="1" len="2">12</attr> <attr tag="00200020" vr="cs" pos="1384" name="patient Orientation" vm="0" len="0"/> <attr tag="00201002" vr="is" pos="1392" name="images in Acquisition" vm="1" len="2">1 </attr> <attr tag="00280002" vr="us" pos="1402" name="samples per Pixel" vm="1" len="2">1</attr> <attr tag="00280004" vr="cs" pos="1412" name="photometric Interpretation" vm="1" len="12">monochrome2 </attr> <attr tag="00280008" vr="is" pos="1432" name="number of Frames" vm="1" len="2">10</attr> <attr tag="00280009" vr="at" pos="1442" name="frame Increment Pointer" vm="1" len="4">00181065</attr> <attr tag="00280010" vr="us" pos="1454" name="rows" vm="1" len="2">1024</attr> <attr tag="00280011" vr="us" pos="1464" name="columns" vm="1" len="2">1024</attr> <attr tag="00280100" vr="us" pos="1474" name="bits Allocated" vm="1" len="2">16</attr> <attr tag="00280101" vr="us" pos="1484" name="bits Stored" vm="1" len="2">10</attr> <attr tag="00280102" vr="us" pos="1494" name="high Bit" vm="1" len="2">9</attr> <attr tag="00280103" vr="us" pos="1504" name="pixel Representation" vm="1"
len="2">0</attr> <attr tag="00281040" vr="cs" pos="1514" name="pixel Intensity Relationship" vm="1" len="4">log </attr> <attr tag="00281050" vr="ds" pos="1526" name="window Center" vm="1" len="4">512 </attr> <attr tag="00281051" vr="ds" pos="1538" name="window Width" vm="1" len="4">1024</attr> <attr tag="00283000" vr="sq" pos="1550" name="modality LUT Sequence" len="2088"> <item id="1" pos="1562" len="2080"> <attr tag="00283002" vr="us" pos="1570" name="lut Descriptor" vm="3" len="6">1024\0\16</attr> <attr tag="00283004" vr="lo" pos="1584" name="modality LUT Type" vm="1" len="2">us</attr> <attr tag="00283006" vr="us" pos="1594" name="lut Data" vm="1024" len="2048" hide="true"/> </item> </attr> <attr tag="00290010" vr="lo" pos="3650" vm="1" len="12">integris 1.0</attr> <attr tag="00291000" vr="sq" pos="3670" len="222"> <item id="1" pos="3682" len="214"> <attr tag="00290010" vr="lo" pos="3690" vm="1" len="12">integris 1.0</attr> <attr tag="00291001" vr="us" pos="3710" vm="2" len="4">9\9</attr> <attr tag="00291002" vr="us" pos="3722" vm="81" len="162" hide="true"/> <attr tag="00291003" vr="fl" pos="3892" vm="1" len="4">0.9</attr> </item> </attr> <attr tag="00400244" vr="da" pos="3904" name="performed Procedure Step Start Date" vm="1" len="8">20070731</attr> <attr tag="00400245" vr="tm" pos="3920" name="performed Procedure Step Start Time" vm="1" len="12">143119.0000 </attr> <attr tag="00400253" vr="sh" pos="3940" name="performed Procedure Step ID" vm="1" len="8">unknown </attr> <attr tag="00400254" vr="lo" pos="3956" name="performed Procedure Step Description" vm="1" len="8">unknown </attr> <attr tag="00400275" vr="sq" pos="3972" name="request Attributes Sequence" len="52"> <item id="1" pos="3984" len="44"> <attr tag="00400009" vr="sh" pos="3992" name="scheduled Procedure Step ID" vm="1" len="14">31072007143119</attr> <attr tag="00401001" vr="sh" pos="4014" name="requested Procedure ID" vm="1" len="14">31072007143119</attr> </item> </attr> <attr tag="00500004" vr="cs" pos="4036" name="calibration Image" vm="0" len="0"/> <attr tag="7fe00010" vr="ow" pos="4044" name="pixel Data" vm="1" len="20971520" hide="true"/> <attr tag="fffcfffc" vr="ob" pos="20975576" name="data Set Trailing Padding" vm="1" len="134324" hide="true"/> </dataset> </dicomfile> Ahora pueden comparar este listado del archivo dicom transformado a xml con el original DICOM binario (escrito en hexadecimal) 4449434D02000000554C0400CA000000 020001004F4200000200000000010200 020055491C00312E322E3834302E3130 3030382E352E312E342E312E312E3132 2E310200030055493800312E332E3436 2E3637303538392E372E352E31302E38 303030383139313032352E3230303730 3733312E3135353435372E31322E312E 31000200100055491400312E322E3834 302E31303030382E312E322E31000200
120055491C00312E322E3237362E302E 373233303031302E332E302E332E352E 340002001300534810004F464649535F 44434D544B5F33353420080005004353 0A0049534F5F49522031303008000800 435326004F524947494E414C5C505249 4D4152595C53494E474C4520504C414E 455C53494E474C452041080016005549 1C00312E322E3834302E31303030382E 352E312E342E312E312E31322E310800 180055493800312E332E34362E363730 3538392E372E352E31302E3830303038 3139313032352E32303037303733312E 3135353435372E31322E312E31000800 20004441080032303037303733310800 21004441080032303037303733310800 2200444108003230303730373331... o con el binario con reconocimiento de los caracteres ASCII Ejercicio 1 Con la ayuda de la representación xml y de la representación ASCII del archivo DICOM, subdividir la representación binaria hexadecimal en unidades significativa, y comentarlas. Va a continuación el principio de la solución: 4449434D DICM firma en caracteres ASCII que indica que se trata de un archivo DICOM 02000000 tag (0002,0000) escrito en ELE
554C UL en caracteres ASCII. Datatype unsigned long del tag (0002,0000) 0400 4 bytes, tamaño del tag de tipo unsigned long CA000000 202, valor del tag 02000100 tag (0002,0000) 4F42 OB Byte String "Other Byte String " "OB is a VR which is insensitive to Little/Big Endian byte ordering The string of bytes shall be padded with a single trailing NULL byte value (00H) when necessary to achieve even length." 00000200 2 bytes 00000001 0000\0001... Ejercicio 2 400054024C4F0800554E4B4E 4F574E204000750253510000 34000000FEFF00E02C000000 4000090053480E0033313037 323030373134333131394000 011053480E00333130373230 303731343331313950000400 43530000 Este fragmento contiene una secuencia. Cuales tags pertenecen a un elemento de la secuencia? Antes intentar contestar vale leer DICOM parte 5 capitulo 7.5 Beneficios adicionales de la intermediación por xml Al instalar dcmtk o dcm4che, vieron que existen también las herramientas inversas xml2dcm. cuando se trata de realizar una pequeña modificación a un archivo DICOM resulta muy cómodo transformar DICOM a XML, editar el XML y volver a transformar el resultado a DICOM. si sobre algo de tiempo, realizar algunos experimentos al respecto Control de calidad Estudiar los tags de un specimen de archivo DICOM de las modalidades de adquisición en uso en un hospital es importante para realizar controles de calidad. Un ejemplo común es la representación inadecuada de imagen de CR.
Los datos de pixel del archivo DICOM tienen que pasar por unas cuantas operaciones antes estar representados en el monitor. El VOI LUT, que es la operación que realiza el usuario con el ratón para achicar el rango útil de valores a representar permite ver una imagen en casi cualquier caso, pero eso no significa que esta imagen sea conforme a las condiciones de de captura. En particular, con CR, frecuentemente se incorpora un Modality LUT en el archivo, que sirve de correctivo a los datos medidos en función de la calibración del escáner que lee las placas de fósforo. Sin este correctivo, por medio del VOI LUT se obtiene igual una imagen dónde se reconocen las estructuras de los huesos. Pero en el resultado nunca se logrará una escala de contraste tal la definida durante la calibración del equipo. Resultarán imágenes de calidad inferior e inaptadas. Si se fijan en el ejemplo de transcripción xml del archivo presentado arriba, verán el tag (0028,3004) que indica que también en esta angiografía hay un modality LUT a tomar en cuenta. Para saber si la estación de visualización toma en cuenta o no la calibración, la tarea podría consistir en : (1) recuperar un archivo DICOM producido por el CR (2) analizarlo para comprobar la presencia del modality LUT (3) modificar el specimen, suprimiendo el modality LUT, o alterándolo (4) visualizar la nueva imagen desde el visualizador y comprobar si hay diferencias. (5) en caso negativo, el visualizador o esta mal configurado, o inadecuado. Conclusiones DICOM es mucho más que un formato de imagen
DICOM siendo universal para imagen médica, es importante estudiar este lenguaje hasta ser capaz de entenderlo, fuese con herramientas de más alto o bajo nivel. Por lo menos, creo que se puede exigir de un ingeniero biomédico : - la capacidad de entender un conformance statement, - la capacidad de analizar un archivo DICOM, - la capacidad de estudiar IODs, relacionarlos a la realidad de las condiciones de captura de la información en el hospital, evaluar la calidad de la implementación y proponer mejoras a la misma. Siendo muy compleja la información que transmite el archivo DICOM, una situación de incomunicación, o sea la imposibilidad de una consola de visualización de mostrar correctamente imágenes de tal o cual modalidad es el resultado drástico de tal vez un detallecito que podría solucionarse con un filtro de transformación de archivo apropiado entre el equipo de adquisición y la consola de visualización. Por ejemplo a veces solo se trata de poder cambiar la síntaxis de transferencia. Existen herramientas, en particular dcm2xml que facilitan mucho el trabajo del ingeniero biomédico. Talleres prácticos Requisitos: haber repasado el contenido de este curso y leído los capitulos de la norma mencionados. Tener una computadora a disposición con dcm4che1 y dcm4che2 instalados Instalar Clearcanvas si tiene Windows, o imagej si tiene Linux, o OsiriX si tiene macintosh 10.5 para poder visualizar los archivos DICOM creados Para ejercicios avanzados tener un programa que permite editar fácilmente datos hexadecimales, como por ejemplo Resorcerer para macintosh Area de las prácticas Creación de archivo DICOM jpg, mpg o pdf desde imágenes jpg Transformación de archivos DICOM