Proyecto DICOMJose

Desarrollo de aplicacin DICOM mediante librer o as JDT (Java Dicom Toolkit)
Jos Ma Onrubia e 14 de julio de 2003
Indice general
1. Introduccin y objetivos o 2. Estado de la tcnica. e 2.1. DICOM (Digital Imaging and Communication in Medicine). . 2.1.1. Proceso distribuido. . . . . . . . . . . . . . . . . . . . 2.1.2. Conceptos generales de DICOM. . . . . . . . . . . . . 2.1.3. Conceptos de red DICOM. . . . . . . . . . . . . . . . 2.1.4. Conectividad (Connectivity) . . . . . . . . . . . . . . . 2.1.5. Estndar DICOM . . . . . . . . . . . . . . . . . . . . a 2.2. Instancias SOP de imgenes DICOM (DICOM Image SOP a Instances) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1. Modelo de informacin de las imgenes . . . . . . . . o a 2.2.2. Instancias imagen SOP (Image SOP Instances) . . . . 2.2.3. Relaciones e indenticacin . . . . . . . . . . . . . . . o 2.2.4. Clasicacin de los datos de imagen . . . . . . . . . . o 2.2.5. Extensin de la informacin . . . . . . . . . . . . . . . o o 2.2.6. Tipos de imgenes . . . . . . . . . . . . . . . . . . . . a 2.2.7. Aplicacin de los datos de imgenes . . . . . . . . . . o a 3. Estudio de librerias DCMTK. 3.1. Visin general. . . . . . . . . . . . . . . . . . . o 3.1.1. Introduccin. . . . . . . . . . . . . . . . o 3.1.2. Descripcin. . . . . . . . . . . . . . . . . o 3.1.3. Estructura de datos DICOM. . . . . . . 3.1.4. Servicios de red DICOM. . . . . . . . . 3.1.5. Intercambio de medios de comunicacin. o 3.1.6. Estatuto de conformidad. . . . . . . . . 3.1.7. Conclusin. . . . . . . . . . . . . . . . . o 3.2. Instalacin dcmtk351. . . . . . . . . . . . . . . o 3.2.1. Dcmnet. . . . . . . . . . . . . . . . . . . 3.2.2. Dcmjpeg. . . . . . . . . . . . . . . . . . 3.3. DicomScope. . . . . . . . . . . . . . . . . . . . 3.3.1. Instalacin. . . . . . . . . . . . . . . . . o 3 1 3 3 3 5 15 22 25 27 28 32 32 36 42 43 47 51 51 51 52 52 53 53 54 54 55 57 58 58 59
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
4 3.3.2. 3.3.3. 3.3.4. 3.3.5. Browser. . . . Viewer. . . . Print. . . . . Process Log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
INDICE GENERAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 60 61 62 65 65 66 66 66 73 75 80 80 81 83 85 85 87 87 92 93 94 96 97 99 99 103 105 106 106 107 107 107 108
4. JDT (Java DICOM Toolkit) 4.1. Introduccin. . . . . . . . . . . . . . . . . . o 4.2. Guia de usuario de JDT. . . . . . . . . . . . 4.2.1. Terminolog . . . . . . . . . . . . . a. 4.2.2. Conjunto de datos (Datasets). . . . 4.2.3. Depsitos. . . . . . . . . . . . . . . . o 4.2.4. Imgenes en JDT. . . . . . . . . . . a 4.3. Estructura de JDT(Java DICOM Toolkit). . 4.3.1. Arbol de clases. . . . . . . . . . . . . 4.3.2. Paquetes. . . . . . . . . . . . . . . . 4.3.3. Conclusiones. . . . . . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
5. Estudio de JAVA. 5.1. Introduccin . . . . . . . . . . . . . . . . . . . o 5.2. Estudio a travs de un ejemplo. . . . . . . . . e 5.2.1. Clase Ejemplo1 . . . . . . . . . . . . . 5.2.2. Clase Geometr . . . . . . . . . . . . a. 5.2.3. Clase Rectngulo. . . . . . . . . . . . a 5.2.4. Clase Circulo. . . . . . . . . . . . . . . 5.2.5. Interface Dibujable . . . . . . . . . . . 5.2.6. Clase RectanguloGraco. . . . . . . . 5.2.7. Clase CirculoGraco. . . . . . . . . . . 5.2.8. Clase PanelDibujo. . . . . . . . . . . . 5.2.9. Clase VentanaCerrable. . . . . . . . . 5.3. Nomenclatura habitual en la programacin en o 5.4. Estructura general de un programa java. . . . 5.4.1. Concepto de Clase. . . . . . . . . . . . 5.4.2. Herencia. . . . . . . . . . . . . . . . . 5.4.3. Concepto de Interface. . . . . . . . . . 5.4.4. Concepto de Package. . . . . . . . . . 5.4.5. La jerarqu de clases de Java (API). . a
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . java. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
6. Desarrollo de nuestra aplicacin mediante JDT, JDK o y JBuilder7. 6.1. Introduccin. . . . . . . . . . . . . . . . . . . . . . . . . o 6.2. Uso de JBuilder 7.0 . . . . . . . . . . . . . . . . . . . . 6.2.1. Introduccin. . . . . . . . . . . . . . . . . . . . . o 6.2.2. Instalacin de JBuilder. . . . . . . . . . . . . . . o 6.2.3. Creacin de una aplicacin JBuilder. . . . . . . . o o
1.4.1 109 . . . 109 . . . 110 . . . 110 . . . 110 . . . 110
6.3. Uso de librer JDK 1.4.1 . . . . . . . . . . . as 6.3.1. Introduccin e instalacin. . . . . . . . o o 6.3.2. Estructura de JDK 1.4.1. . . . . . . . 6.3.3. Conguracin de JDK en JBuilder. . . o 6.4. Instalacin de JDT en JBuilder. . . . . . . . o 6.5. Implementacin de nuestra aplicacin. . . . . o o 6.5.1. Introduccin. . . . . . . . . . . . . . . o 6.5.2. Estructura de la GUI. . . . . . . . . . 6.5.3. Panel VisorDicom. . . . . . . . . . . . 6.5.4. Panel Crear DICOM. . . . . . . . . . 6.5.5. Panel Procesamiento. . . . . . . . . . . 6.5.6. Panel Cliente/Servidor. . . . . . . . . 6.6. Distribucin de la aplicacin. . . . . . . . . . o o 6.6.1. Generacin del archivo ejecutable java. o 6.6.2. Ejecucin del archivo ejecutable java. o
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
132 132 133 138 139 142 142 143 144 158 168 172 173 173 175
A. ESTANDAR DICOM PARTE 1 177 A.1. Introduccin. . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 o A.2. Alcance y campo de aplicacin. . . . . . . . . . . . . . . . . . 180 o A.3. Deniciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 A.4. S mbolos y abreviaturas. . . . . . . . . . . . . . . . . . . . . . 182 A.5. Objetivos del estndar DICOM. . . . . . . . . . . . . . . . . . 183 a A.6. Contenido del estndar DICOM. . . . . . . . . . . . . . . . . 184 a A.6.1. Estructura del documento. . . . . . . . . . . . . . . . 184 A.6.2. PS 3.2: Conformidad . . . . . . . . . . . . . . . . . . . 184 A.6.3. PS 3.3: Deniciones de objetos de la informacin o (IODs) . . . . . . . . . . . . . . . . . . . . . . . . . . 186 A.6.4. PS 3.4: Especicaciones de las clases de servicio. . . . 188 A.6.5. PS 3.5: Estructura de datos y semntica . . . . . . . . 188 a A.6.6. PS 3.6: Diccionario de datos . . . . . . . . . . . . . . . 189 A.6.7. PS 3.7: Intercambio de mensajes. . . . . . . . . . . . . 189 A.6.8. PS 3.8: Apoyo de comunicacin de red para el intero cambio de mensaje . . . . . . . . . . . . . . . . . . . . 190 A.6.9. PS 3.9: Soporte de comunicacin para el intercambio o de mensajes punto por punto. . . . . . . . . . . . . . . 191 A.7. Relaciones entre las partes del estndar. . . . . . . . . . . . . 193 a
INDICE GENERAL
Cap tulo 1
Introduccin y objetivos o
Dicom (Digital Imaging and Communications in Medicine) es el estndar a industrial para transferencia de imgenes digitales e informacin mdica a o e entre computadoras. Dicom permite la comunicacin digital entre equipos o de diagnstico, teraputicos y entre sistemas de diferentes fabricantes. o e Se ve entonces, la gran importancia de este estndar, ya que da la a posibilidad de interconectar sistemas informticos de diferentes fabricantes a y hace posible que se comuniquen entre s lo que en un hospital, donde los , aparatos mdicos son de muchas marcas diferentes, debido a la especiale izacin, es tremendamente interesante y necesario. o La estandarizacin de archivos mdicos hace posible que, mediante una o e transmisin segura, los datos de los pacientes puedan viajar de deparo tamento en departamento, de hospital en hospital, lo que hace que esa informacin pueda ser vista remotamente de la zona de adquisicin de o o las imgenes. Esto permite que los mdicos puedan diagnosticar desde su a e casa, buscar diferentes opiniones de otros mdicos expertos de una forma e sencilla y rpida, un orden y estructura de los datos ms efectivo y seguro, a a y muchos otros tipos de ventajas. Objetivos Los objetivos de este estndar son: a lograr una interfaz comn para todos los dispositivos de imgenes (tou a mograf resonancia magntica, ultrasonido, rayos x, etc). a, e intentar desligar Dicom de las instituciones que lo desarrollan para que realmente pueda ser un estndar independiente. a debe ser aplicable a toda la esfera de las imgenes mdicas, desde su a e 1
CAP ITULO 1. INTRODUCCION Y OBJETIVOS transmisin hasta el tratamiento e impresin. o o
Jos Ma Onrubia e
De momento Dicom facilita, pero no garantiza, por si mismo que se cumplan todos los objetivos que se intentan lograr en los sistemas de gestin o de imgenes. a Debido a todas estas ventajas y posibilidades para que los hospitales y la medicina en general funcione mejor, es de gran inters avanzar por estas e l neas de trabajo. Por esto lo interesante de avanzar por este camino. La creciente utilizacin de sistemas de adquisicin y tratamiento digital o o de imgenes mdicas ha hecho necesaria la adopcin de estndares que a e o a posibiliten el intercambio de stas tanto dentro de las propias instituciones e como fuera de ellas. El estndar DICOM 3.0 nace en el ao 1993, a partir de un rediseo a n n completo de la publicacin normalizada No 300-1988 de ACR-NEMA y o pertenece al campo de la Informtica Mdica por lo que, en principio, esta a e norma se solapa con otras de este campo. El avance de la estandarizacin poco a poco va adquiriendo todo su o signicado: Se homogeneizan los estndares de codicacin de la informacin y a o o del conjunto de datos resultantes de utilizar los Objetos de informacin (imgenes) con las Clases de Servicio (impresin, almacenamiento, o a o etc), as como se especican varias tcnicas de compresin normal e o izadas (JPEG con y sin perdidas). Se muestran las reglas de codicacin que se deben cumplir para cono struir un secuencia de datos para ser transmitida como un mensaje. Se especica los servicios de comunicaciones y los protocolos necesarios para, en un entorno de red, intercambiar mensajes. Se dene la utilizacin de un conjunto de protocolos OSI (Intero conexin de Sistemas Abiertos) para asegurar una comunicacin eo o ciente y que soporte una amplia variedad de tecnolog de red basadas as en normas internacionales como la ISO 8802-3 CSMA/CD (la famosa red Ethernet), ATM (muy en boga actualmente), X.25, etc. Y como protocolo de transporte se puede utilizar el famoso TCP/IP que hay que recordar que es un protocolo de propsito general, por lo que el o sistema, en este apartado, es realmente abierto y compatible con la mayor de las redes que se estn instalando actualmente en los cena a tros sanitarios. 2 GVA-ELAI-UPM r PFC0074-03
Cap tulo 2
Estado de la tcnica. e
2.1. DICOM (Digital Imaging and Communication in Medicine).
En esta seccin se van a explicar un nmero de conceptos denidos por el o u estndar de DICOM. Primero se describe como punto de partida el modelo a de un proceso distribuido, a partir del cual vamos a introducirnos en los conceptos DICOM. Se explican las partes que tratan con la informacin o (Clases de Servicio) y otras cuestiones. En las dos siguientes subsecciones se describen el intercambio a travs de e la red de la informacin. o Finalmente, se dan las caracter sticas que aseguran la conectividad y una descripcin de las partes del estndar. o a
2.1.1.
Proceso distribuido.
Un simple modelo de un proceso distribuido (gura 2.1) servir para a explicar el mecanismo y terminolog usada en el estndar DICOM. a a Un proceso distribuido est formado al menos por dos procesos que coma parten informacin y conf el uno en el otro. Varios procesos distribuidos o an actuando juntos proporcionan servicios para sistemas en entornos como departamentos de radiolog a.
CAP ITULO 2. ESTADO DE LA TECNICA.
Jos Ma Onrubia e
Figura 2.1: Proceso distribuido Antes de que los procesos puedan actuar juntos, una serie de temas tienen que ser tratados. Tienen que estar de acuerdo en la informacin que se va o ha intercambiar y seleccionar las operaciones que cada parte realizar: a
El papel de cada parte debe ser denido como cliente o como servidor. La parte que utiliza la operatividad de la otra, tienen el papel de cliente. La parte contraria actuando sobre un modelo tiene el papel de servidor. El funcionamiento de ambas partes viene denida por la relacin que comparten. La relacin dene que parte y bajo que o o condicin toma la iniciativa en el proceso. En muchos casos los clientes o provocan el proceso, pero a veces lo hace el servidor. Adems de los papeles que desempean, ambas partes tienen que estar a n de acuerdo en la informacin que van a intercambian. La informacin o o est denida por el contexto del servicio que el proceso distribuido a est realizando. a La operacin dene como debe ser procesada la informacin intercamo o biada en la otra parte, tal como almacenar informacin, devolver un o resultado, etc. La combinacin del contexto, relacin, operaciones e informacin es la o o o piedra fundamental del procesamiento distribuido y tiene que denirse antes de que una aplicacin se realice (un intercambio). Todos estas cuestiones o son parte del dominio de la aplicacin (application domain) de los procesos o distribuidos. Estos no se ocupan de la forma en que la informacin se o intercambia, pero cuentan con los servicios de menor nivel (p.e. TCP/IP) suministrados por el dominio del intercambio (exchange domain) para 4 GVA-ELAI-UPM r PFC0074-03
2.1. DICOM (DIGITAL IMAGING AND COMMUNICATION IN Jos Ma Onrubia e MEDICINE). poder hacer frente al proceso de comunicacin. o Ambas partes, cliente y servidor, tienen que ser capaces de emitir peticiones a los servicios de menor nivel. Los servicios de menor nivel llevarn el a intercambio y estarn ocultos para el dominio de la aplicacin del cliente o a o servidor. La parte que solicita los servicios es el usuario del servicio (service user ). El equivalente es el proveedor del servicio (service provider ). Ambas partes pueden tener distintas implementaciones, pero comparten el mismo conocimiento sobre como se intercambian los datos (protocolo) y tienen el mismo interface lgico (formato de peticin) entre s o o . Ambas partes deben determinar cmo viene representada la informacin o o en el formato de bit/byte. El proveedor del servicio debe determinar en qu formato la informacin fue transferida y convertida a la representacin e o o esperada por el dominio de la aplicacin. La representacin es conocida o o entre el usuario y el proveedor del servicio en cada parte. Despus del intere cambio, la informacin presentada a los procesos utilizando la informacin o o es igual en ambas partes, independientemente de como fuera intercambiada. El intercambio f sico entre los proveedores del servicio puede ser v a network o media. Cada mecanismo tiene su propia forma de manejar el conocimiento de la representacin. o
2.1.2.
Conceptos generales de DICOM.
DICOM es un estndar que cubre en parte las cuestiones planteadas en la a seccin anterior. Esta seccin abordar los conceptos generales con respecto o o a al mecanismo de intercambio actualmente usado. DICOM utiliza su propia terminolog para describir el contexto, relaciones, etc. El primer paso es el a mismo modelo que para el procesamiento distribuido con la transformacin o de la gura anterior en la misma gura aplicando los trminos equivalentes e de DICOM.
Clases de Servicio (Service Classes) y Clases SOP (SOP Classes). La relacin entre ambas partes se dene por la descripcin de la Clase de o o Servicio. La Clase de Servicio describe expl citamente los papeles que ambas partes desempean. Con DICOM ambos papeles son llamados: Usuario de n la Clase de Servicio o SCU (Service Class User ) (cliente) y Proveedor de la Clase de Servicio o SCP (Service Class Provider ) (servidor). No hay que confundir SCU y SCP con el usuario del servicio y el proveedor del servicio del dominio del intercambio. GVA-ELAI-UPM r PFC0074-03 5
Jos Ma Onrubia e
Figura 2.2: Modelo de un proceso distribuido Parte de la Clase de Servicio es la descripcin de la informacin y o o operaciones. En DICOM estas estn combinadas con la denicin de la a o clase, llamada Clase de Servicio de Par Objeto (Service Object Pair Class) o Clase SOP (SOP Class). En cada denicin de Clase SOP una unica o denicin de Objeto de informacin (Information Object Denition) o IOD o o es combinado con uno o ms servicios. Para cada uno de estos servicios a los detalles de los papeles de ambas partes que tienen que desempear son n invariables. Ms de una Clase SOP puede existir en una Clase de Servicio a cuando ms de un IOD est implicado. a a Una Clase de Servicio entiende la relacin de informacin denida en difero o entes IODs. Una Clase SOP identica las capacidades del proceso distribuido espec co de una Clase de Servicio. Cuando las partes estn de acuerdo en a utilizar una Clase SOP, ambas partes deben asegurar que desempearn sus n a papeles como se describen, utilizando el contexto de la Clase de Servicio incluida. Antes de que la informacin se intercambie puede tener lugar la o identicacin de la Clase SOP, que es una parte importante que tiene que o 6 GVA-ELAI-UPM r PFC0074-03
2.1. DICOM (DIGITAL IMAGING AND COMMUNICATION IN Jos Ma Onrubia e MEDICINE). realizarse al principio. El mecanismo usado depende del tipo de intercambio: network o media. Utilizando la Clase de Servicio y otras deniciones derivadas, las partes en el entorno de un proceso distribuido funcionan juntas mediante los servicios proporcionados por el dominio del intercambio.
Figura 2.3: Clases de servicio DICOM Deniciones de Objeto de Informacin (Information Objects Defo initions). La parte de informacin de una Clase SOP es denida en los IODs. Un o IOD es una coleccin de partes de informacin relacionada, agrupadas en o o Entidades de informacin (Information Entities). Cada entidad contiene o informacin sobre un unico objeto (mundo real) como un paciente, una o imagen, etc. Dependiendo del contexto denido por la Clase de Servicio, un IOD consiste en una entidad de informacin unica llamada IOD normalizado o (normalized IOD) o una combinacin de entidades de informacin llamada o o IOD compuesto (composite IOD). Las Clases de Servicio que llevan a cabo GVA-ELAI-UPM r PFC0074-03 7
Jos Ma Onrubia e
funciones de administracin (en su mayor parte cuestiones simples) utilizan o IODs normalizados, aquellas que manejan el ujo de imgenes (estructura a compleja de informacin) utilizan IODs compuestos. La relacin entre o o diferentes entidades de informacin (estructuracin) y los IODs compuestos o o se describe en el modelo de informacin (informacin model ) perteneciente o o a la Clase de Servicio. Con IODs normalizados (solo una entidad de informacin) no hay ninguna necesidad de estructuracin. Las relaciones en o o otras piezas de informacin estn hechas aludiendo a esa informacin. o a o Las entidades de informacin consisten en atributos, describiendo una o unica parte de informacin, por ejemplo, el nombre de un paciente. Los o atributos que tienen una relacin estn agrupados en mdulos de informao a o cin de objetos o IOMs (Information Object Modules). Los IOMs estn o a denidos de tal manera que pueden ser usados en ms de un IOD. Estos a IOMs tambin tienen la ventaja de que las descripciones semnticas de los e a atributos descritos pueden ser agrupados juntos. La gura que se ve a continuacin representa una visin general de estas o o relaciones.
Figura 2.4: Relaciones entre IODs y atributos Un ejemplo de una IOD compuesto, imagen IOD est representada a siguiente: 8 GVA-ELAI-UPM r PFC0074-03
2.1. DICOM (DIGITAL IMAGING AND COMMUNICATION IN Jos Ma Onrubia e MEDICINE).
Figura 2.5: Ejemplo de una imagen IOD compuesta. Atributos. Los atributos son la entidad de informacin bsica y tienen que ser o a descritos en detalle. De un atributo, se denen las siguientes caracter sticas en el estndar DICOM: a
un unico Nombre de Atributo (Attribute Name) (legible por el ser humano). una unica Etiqueta de Atributo (Attribute Tag) (legible por los sis temas de informacin). o una descripcin de Atributo (Attribute Description) (semntica). o a GVA-ELAI-UPM r PFC0074-03 9
Jos Ma Onrubia e
un Valor Representativo (Value Representation) (sintaxis). un Valor de Multiplicidad (Value Multiplicity). tipo de clasicacin: 1, 1C, 2, 2C o 3 (usadas dependiendo del contexto o de las Clases SOP, Clases de Servicio, papel que desempea, etc.). n El tipo de clase especica el uso de los atributos especicados en las Clases SOP y SCU o el papel del SCP. Dependiendo de la situacin, a cada o atributo se le fuerza a tener un valor (tipo 1 ) o a que exista con o sin valor (tipo 2 ) o que sea opcional que aparezca ese atributo (tipo 3 ). Dentro de un IOD, los atributos agrupados o individuales pueden ser condicionados por la situacin en la que el IOD est siendo usado. Por o a ejemplo, un anlisis utilizando contraste puede almacenar informacin a o en un modulo de Contrast/Bolus. Los atributos de este mdulo estn o a por consiguiente disponibles o no disponibles, dependiendo del uso del contraste. Si se usa, el tipo de clase especicada para los atributos debe ser obedecida (denida como tipo 1C y tipo 2C).
Elementos de Servicio (Service Elements). Los Elementos de Servicio son las operaciones permitidas en los Objetos de informacin para una Clase SOP denida. El grupo de elementos de o servicio pertenece a la Clase SOP y es llamada Grupo de Servicio (Service Group). El Grupo de Servicio de una Clase SOP se selecciona de una lista ja de Elementos de Servicio de DICOM. Algunos Elementos de Servicio estn a proyectados para usarse con IODs compuestos, otros para uso con IODs normalizados. Una tercera categor medios de almacenamiento (storage a, media) relacionados con Elementos de Servicio, manejando instancias de Clases SOP normalizadas o compuestas como archivos. El contexto descrito por la Clase de Servicio est limitado cuando a se utilizan IODs compuestos (p.e., transferir imagen). Elementos de Servicio semejantes tienen un signicado complejo, p.e., STORE, FIND, MOVE. No hay ninguna relacin asumida entre los Elementos de Servicio o individuales en una secuencia cuando se utilizan Clases de Servicio compuestos. Si existe una relacin, es fuera del alcance de la Clase de Servicio y o deber estar denida en el proceso uyente utilizando las Clases de Servicio. a En contraste, las Clases de Servicio utilizando IODs normalizados tienen un contexto ms amplio, como funciones directivas. Estas utilizan los a 10 GVA-ELAI-UPM r PFC0074-03
2.1. DICOM (DIGITAL IMAGING AND COMMUNICATION IN Jos Ma Onrubia e MEDICINE). Elementos de Servicio primitivos para operaciones con piezas sencillas de informacin: GET, SET, ACTION, etc. La Clase de Servicio dene la o relacin de la secuencia de la peticiones primitivas. Con Clases de Servicio o normalizadas ambas partes estn al tanto del procedimiento de ambas a partes, utilizando los Elementos de Servicio para controlarlos. Cada Clase SOP utiliza uno o ms Elementos de Servicio de cada uno de a los grupos compuestos (C-XXXX) o de los grupos normalizados (N-XXXX). Los siguientes Elementos de Servicio estn disponibles: C-STORE, C-FIND, a C-MOVE, C-GET, CCANCEL, C-ECHO, N-GET, N-SET, N-ACTION, N-CREATE, N-DELETE y NEVENT- REPORT. Las semnticas de los a Elementos de Servicio dependen de la Clase de Servicio y de la Clase SOP en la cual estn utilizados. a Los Elementos de Servicio relacionados con Media, M-WRITE, M-READ, MDELETE, M-INQUIRE-FILE-SET y M-INQUIRE-FILE denen funciones primitivas para el tratamiento con archivos.
Instancias SOP (SOP Instances). El esqueleto de las deniciones citadas anteriormente toma forma cuando se utilizan en un proceso distribuido. Despus del acuerdo que mantienen e las Clases SOP (impl citamente la Clase de Servicio), y como los papeles de la SCU y la SCP estn divididos, las instancias de la clase SOP a pueden ser distribuidas entre las dos partes. Los atributos tienen que ser proporcionados con los valores correctos y almacenado en la Instancia SOP como se especica en la denicin de los atributos. o Despus de recopilar la informacin, esta ser codicada a los formatos e o a denidos por DICOM, utilizando la representacin del la Etiqueta (Tag) o y del Valor (Value) para crear un DICOM data set, en el cual cada atributo es codicado en un data element. Este data set es manejado por el proveedor del servicio de intercambio, el cual garantiza que la parte contraria recibe idntico data set. Las diferencias en la representacin del e o sistema especicado son tomadas en una cuenta durante el intercambio, asegurando que los signicados semnticos permanecen intactos. a El receptor del data set decodicar este para extraer la informacin que a o necesita y actuar como acuerdo de la semntica de la Clase SOP. a
GVA-ELAI-UPM r PFC0074-03
11
CAP ITULO 2. ESTADO DE LA TECNICA. Identicacin. o
Jos Ma Onrubia e
Como parte del proceso de creacin de una Instancia SOP, una identio cacin es generada como atributo de la SOP Instance. La identicacin se o o pretende para la utilizacin por los sistemas de informacin antes que por o o los humanos y tiene dos caracter sticas: la identicacin de la clase (class o identication) y la identicacin de la instancia (instance identication). o Esta identicacin tiene que ser usada en un entorno de muchos vendeo dores en distintas partes del mundo. Para asegurar la unicidad de cada identicacin en todo el mundo, se utiliza un mecanismo para generar o una cadena de caracteres, llamada Identicador Unico o UID (Unique Identier), tal y como sigue:
<
root >.<sux
>
La parte de root es proporcionada por una autoridad que garantice que nadie ms utilizar este root. Este nmero ser asignado por estndares de a a u a a organizaciones y compa tales como Philips u hospitales, que debern nas a asegurar que permanece unico a lo largo de sus propios sistemas. Utilizando un sistema de identicacin unico, cada sistema tendr un unico root a lo o a largo de todo el mundo. El sux tiene que ser creado dinmicamente por a el sistema en la creacin de la instancia. o Un vez que una instance es identicada por un UID, esta debe ser utilizada consistentemente. Si se crean copias o la instancia se reproduce sin ninguna modicacin, o deber tener el mismo UID, de lo contrario dos piezas de idntica informaa e cin coexistir con diferentes identicaciones, lo que podr conducir a o an a confusin. o
Relaciones. Adems de la identicacin de la Clase SOP y la Instancia SOP, los UIDs a o tambin se utilizan para identicar una relacin entre instancias. En una e o instancia compuesta (composite instance) que contiene una unica imagen perteneciente a una secuencia de imgenes, la Entidad de informacin (Ina o formation Entity) que contiene la informacin de las secuencias ser comn o a u para todas aquellas instancias. En este caso solo se requiere un UID, el atributo por s mismo identica qu tipo de entidad de informacin es e o identicada.
12
2.1. DICOM (DIGITAL IMAGING AND COMMUNICATION IN Jos Ma Onrubia e MEDICINE). En el caso de instancias normalizadas (normalized instances), slo son o posibles referencias a instancias fuera de s mismas; aqu se requiere la combinacin de una identicacin de una clase y una instancia. o o Con el mtodo de la unicidad de identicacin de informacin utilizando e o o UIDs, es tan slo posible comparar si las instancias son iguales. El valor del o UID no tiene ningn signicado, y no puede ser utilizado para clasicar, u etc. Utilizando otro mtodo como los atributos ms signicativos tales e a como la fecha y la hora y los nmeros de la secuencia, se puede establecer u la relacin entre la informacin. o o
Valor representativo (Value Representation). Para cada atributo se dene un Representacin del Valor (VR). Una o valor representativo describe como un atributo se codica en un elemento de datos. El conocimiento de la valor representativo se comparte por las partes en el intercambio de informacin , el proceso de codicacin y o o decodicacin tiene que tener cuidado en la seleccin del VR correcto para o o un atributo (identicado por su etiqueta). Son posibles dos formas de compartir esta informacin: compartir un o diccionario de datos que contiene todos los posibles atributos de intercambio, o incluyendo el valor representativo como una parte del data element. El ultimo mtodo incrementa los gastos de intercambio de informacin, e o pero es mucho ms exible comparado con el uso de un diccionario de a datos compartido. Especialmente en un entorno de muchos proveedores, sincronizar el diccionario de datos es dif cil. Cuando el valor representativo se incluye, el mensaje se codica con un VR expl cito (explicit VR). En el otro caso, la codicacin tiene lugar con o un VR impl cito implicit VR).
Sintaxis de transferencia (Transfer Syntax ). Antes de que el conjunto de datos (data set) de una Instancia SOP pueda ser transferida, la forma en la que el conjunto de datos est codicada en a una secuencia de bytes debe ser ja, mediante un acuerdo cuando se usa el intercambio por red, o almacenados junto con los datos en un medio de almacenamiento f sico (disquete, CDs ...). La forma de codicar se especica por la Transfer Syntax. Tres caracter sticas se tienen que denir en la sintaxis de transferencia: GVA-ELAI-UPM r PFC0074-03 13
Jos Ma Onrubia e
Se especica un valor representativo (VR).
El orden de bytes de un nmero mltiple de bytes (palabras, palabras u u largas): little endian o big endian.
En caso de compresin: el formato. o
El manejo de la transfer syntax es parte del proveedor del servicio. As y todo, ambos procesos tienen que iniciar el escenario para un correcta transfer syntax, aceptable para ambas partes. Anlogamente a una identicacin de Clase SOP, una transfer syntax es a o identicada por un UID.
Descripcin o Mirando la gura 2.6 se puede obtener una visin general del ujo o de codicacin y decodicacin. Los servicios proporcionados dentro del o o Dominio del Intercambio tienen que garantizar que en ambas partes las Instancias SOP contienen la misma informacin, independientemente de la o representacin y mtodo de transferencia. o e El proceso de codicacin y decodicacin tiene dos etapas: Primero se o o transere la representacin interna en el formato denido por DICOM (Data o Set) donde cada atributo es almacenado conforme al valor representativo denido para ese atributo. La segunda etapa transere el data set en una corriente de bytes que pueden ser manejados por las capas ms bajas. Para a la segunda etapa la ordenacin de bytes tiene que ser utilizada de acuerdo o con la Transfer Syntax. La aplicacin que est utilizando la informacin debe saber el signicado o a o (semntica) de la informacin dentro del data object. a o
14
2.1. DICOM (DIGITAL IMAGING AND COMMUNICATION IN Jos Ma Onrubia e MEDICINE).
Figura 2.6: Descripcin de la codicacin y decodicacin de las instancias o o o SOP.
2.1.3.
Conceptos de red DICOM.
En la anterior seccin se han discutido los conceptos de DICOM del o dominio de la aplicacin. Cuando se utiliza un mecanismo de red para o el intercambio de informacin, el dominio del intercambio debe contener o GVA-ELAI-UPM r PFC0074-03 15
Jos Ma Onrubia e
funciones requeridas para la comunicacin: el dominio de la comunicacin. o o
Figura 2.7: DICOM con intercambio en red.
Entidad de la aplicacin (Application Entity ). o Una cuestin importante en las aplicaciones distribuidas en red es cmo o o las aplicaciones pueden contactar entre ellas. En DICOM Network, las partes se reconocen mutuamente mediante las entidades de la aplicacin. o Una entidad de la aplicacin es aquella parte de un proceso que negocia o con la comunicacin. Ella contiene el usuario de servicio del proceso, cono teniendo funciones para organizar conexiones y transferencia de informacin. o Una Entidad de la aplicacin tiene un nombre, t o tulo de la aplicacin o (Application Title), que tiene que se utilizado cuando se establece la comunicacin. o
16
2.1. DICOM (DIGITAL IMAGING AND COMMUNICATION IN Jos Ma Onrubia e MEDICINE). Presentacin de la direccin (Presentation Address). o o Los t tulos de la aplicacin son nombres simblicos para los procesos o o involucrados en la comunicacin. En un sistema de red real, la direccin o o de red tiene que ser suministrada. A esto se le llama la Presentation Address. Se le llama as porque el usuario del servicio es la capa de aplicacin (OSI), el proveedor del servicio, la capa de Presentacin (OSI) o o (y niveles ms bajos). La frontera entre ambos niveles es el punto de a acceso de red donde los datos son transferidos desde la capa de aplicacin a o las capas de red. Cada punto de acceso en una red tiene una unica direccin. o El mapeo del t tulo de la aplicacin a la Presentation Address no tiene o que ser unico, porque la Presentation Address se utiliza para la iniciacin o de la conexin, etc. De cualquier manera, en el nivel de aplicacin, el t o o tulo de la aplicacin se usa normalmente para identicar una aplicacin como o o fuente o destino de informacin en un directorio o catlogo. Si esto no o a puede ser registrado sin ambigedades la operacin de los sistemas puede u o llegar a ser un problema. El formato de la Presentation Address depende del protocolo de red utilizado. Los DICOM Networks se realizan en muchos casos utilizando el protocolo TCP/IP. En este caso la valor representativo se mapea a un TCP/IP socket. En el caso de un protocolo OSI, debe utilizarse un OSI Presentation Service Address Point (PSAP) vlido. a
Negociacin de la asociacin (Negotiation Association). o o La conexin para el intercambio de informacin entre dos entidades de la o o aplicacin se llama una asociacin (Association). Para una asociacin, se o o o jan un nmero de asuntos de comunicacin como el contexto en el cual la u o informacin puede tener cambios. o Este contexto, llamado contexto de la aplicacin (Application Context), o se dene en el estndar DICOM y ambas partes deben estar de acuerdo con a la actuacin conforme a la denicin del contexto. o o Un contexto de la aplicacin se dene con un UID y durante la iniciacin o o de una asociacin este UID es transferido a las partes. Por comparacin del o o UID de un contexto de la aplicacin, la parte puede decidir si es capaz de o manejar la peticin de una asociacin. El aceptar el establecimiento de la o o a asociacin o lo rechazar. o a GVA-ELAI-UPM r PFC0074-03 17
Jos Ma Onrubia e
El contexto de la aplicacin cubre la operatividad global para el intero cambio de informacin. Qu tipo de informacin intercambia tendr lugar a o e o a travs de la asociacin que est denida por las Clases SOP y las Clases de e o a Servicio de estas Clases SOP. La parte iniciadora de la asociacin propone o a la Clase SOP que ser utilizada, el SCU / SCP para cada Clase SOP y la a forma de representacin de la informacin. Dependiendo de las capacidades o o de la otra parte, aceptar o rechazar cada Clase SOP individual. a a Despus de este proceso de negociacin, ambas partes conocen mutuae o mente las capacidades y limitaciones. La autntica informacin distribuida e o puede tener lugar conforme a las reglas de una Clase de Servicio y una Clase SOP denidas para estas clases. Cuando una asociacin no se requiere o por ms tiempo, la asociacin se termina. a o
Contexto de la presentacin (Presentation Context) o Para cada Clase SOP negociada durante la iniciacin de la asociacin o o tiene que alcanzarse un acuerdo entre los procesos involucrados acerca de la transfer syntax usada entre los procesos. La parte iniciadora propone todas las transfer syntaxes, jando el contexto de la presentacin para esta Clase o SOP. Despus de la negociacin se establece un Presentation Context para e o cada Clase SOP aceptada. Un Presentation Context se identica por un nmero acordado entre las u dos partes. En el contexto de una aplicacin puede existir un nmero de o u una Presentation Context. El nmero de la Presentation Context identica u la SOP Class para la cual el intercambio de informacin tiene lugar. o
TCP/IP Protocol Stack La combinacin de TCP/IP y una extensin para los servicios de aplio o cacin de OSI es ampliamente usada para implementar DICOM a travs de o e las redes. Como no hay niveles ms altos denidos por TCP/IP, DICOM a dene la operatividad de la aplicacin, la presentacin y sesin de la capa o o o en el estndar. Esta operatividad se combina en una capa: la DICOM a Upper Layer o DUL. La DUL utiliza el mismo interface que el protocolo TCP/IP con respecto del protocolo OSI. En el nivel ms bajo de la capa DUL, hay un interface a para el nivel TCP. La asociacin DICOM entre las entidades de aplicacin o o se mapea a una conexin TCP. La presentacin de la direccin se mapea a o o o 18 GVA-ELAI-UPM r PFC0074-03
2.1. DICOM (DIGITAL IMAGING AND COMMUNICATION IN Jos Ma Onrubia e MEDICINE). un nmero de puerto TCP (TCP port number ), combinado con el nmero u u de IP (IP number ) o nombre del servidor (Host name). Esta combinacin del nmero de puerto TCP y el nmero de IP se llama direccin o u u o de conexin (Socket Address). En una red esta combinacin es siempre unica. o o Una conexin TCP se dene por la combinacin de una direccin de o o o conexin local y una remota. Manteniendo los nmeros de IP unicos de la o u red y el nmero unico de puerto en el sistema, cada conexin TCP se idenu o tica unicamente por la combinacin. La administracin de las conexiones o o se hace por un recurso llamado interface de conexin (Socket Interface) que o proporciona funciones para congurar las conexiones, transferir cadenas de bits, etc.
19
Jos Ma Onrubia e
Figura 2.8: Capas OSI
20
2.1. DICOM (DIGITAL IMAGING AND COMMUNICATION IN Jos Ma Onrubia e MEDICINE). El puerto TCP de la parte llamada durante la inicializacin de la o conexin se debe conocido. Esto puede ser por un acuerdo en el nmero o u de puerto entre las dos aplicaciones, o por un nmero de puerto, llamado u nmero de puerto conocido (well known port number ), reservado para las u implementaciones de DICOM (nmero de puerto 104). u
21
Jos Ma Onrubia e
Figura 2.9: Conexin TCP o
2.1.4.
Conectividad (Connectivity )
Antes de que las dos implementaciones de DICOM se puedan conectar entre s se necesita algo de investigacin para ver si la conexin es posible. , o o 22 GVA-ELAI-UPM r PFC0074-03
2.1. DICOM (DIGITAL IMAGING AND COMMUNICATION IN Jos Ma Onrubia e MEDICINE). Esto alcanza desde el bajo nivel de conexin f o sica hasta la implementacin o de la misma Clase de Servicio en el nivel de aplicacin. o El acercamiento a una conexin red es diferente comparado con un o intercambio a travs de medios de comunicacin f e o sicos como CDs o disquetes. Durante la negociacin de la asociacin en un entorno de red, o o un nmero de detalles se pueden establecer todav En el caso de utilizar u a. medios f sicos no es posible y deber ser dirigido de distinto modo. a DICOM solventa esta cuestin utilizando perles de sistema (system proo les) para implementaciones y perles de aplicacin (application Proles) o en un entorno de intercambio mediante medios f sicos.
Estatuto de conformidad (Conformance Statement). Un perl de sistema (System Prole) contiene una lista de las funciones soportadas y limitaciones o extensiones de estas funciones. Juntos forman un perl que se debe ajustar al perl de la parte que tendr que cooperar. Estos a perles de sistema se describen en un documento que debe ser suministrado con cada implementacin de DICOM: el Conformance Statement(ver gura o 2.10).
Figura 2.10: Estatuto de conformidad con perl del sistema. En el nivel de aplicacin se describen una descripcin funcional de la o o GVA-ELAI-UPM r PFC0074-03 23
Jos Ma Onrubia e
entidad de la aplicacin, las Clases SOP soportadas y el papel que ambos o sistemas desempean. Para la implementacin de los protocolos de red n o puede ser referido a documentacin estndar apropiada, con constancia de o a las excepciones que restringen el uso en un entorno de red. Las posibilidades de una conexin f o sica es tambin un tema que debe ser dirigido. e Los objetos congurables de una implementacin, tales como el t o tulo de la aplicacin (Application Title), la presentacin de la direccin (Presentao o o tion Address) de ambas implementaciones y partes, que son mencionadas juntas con informacin de como puede ser congurado. Otros objetos o congurables como el tamao del protocol data unit (PDU) debe ser listado. n Finalmente el soporte para caracteres ja otros, adems del estndar a a ASCII (tales como extensiones para idiomas Europeos, Japons, etc) e descrito. Comparando los Conformance Statements se puede vericar si la conectividad a todos los niveles es posible. Si la implementacin de la o informacin por todas las partes involucradas es igual no se puede asegurar o por vericacin con la Conformance Statement. o Dependiendo de cmo de estricta pueda ser interpretada la semntica o a de todos los atributos individuales, el nivel de interoperabilidad es ms a predecible. Actualmente no hay ningn mtodo para asegurar la interoperu e abilidad. Al Conformance Statements pueden aadir ms informacin describin a o endo en ms detalle la informacin que manejan. Cuando est indicado a o a qu relaciones estn disponibles y que selecciones estn hechas por la e a a implementacin comparada con el estndar, ste ayudar a incrementar la o a e a conectividad y la interoperatividad.
Perles de aplicacin (Application Proles) o Para median perl de sistema detallado tiene poco sentido porque la u correspondencia no tendr lugar antes de que se conecten los sistemas, pero a por el momento el mdium se lleva a otro sistema. En este caso ambos e sistemas deben garantizar que se ajustan a un formato genrico que habilita e la aplicacin que ambos implementan. Este formato genrico se llamo perl o e de la aplicacin. Por ejemplo, un sistema que genera datos de imagen en o un medio debe hacerlo conforme a un perl de aplicacin conrmado. Un o sistema utilizando esta imagen puede conar en este perl de aplicacin o para resultar exitoso. Dos aspectos son importantes: el formato del medium y la extensin de la o 24 GVA-ELAI-UPM r PFC0074-03
2.1. DICOM (DIGITAL IMAGING AND COMMUNICATION IN Jos Ma Onrubia e MEDICINE). informacin capturada en el medium. Un perl de aplicacin asegura estos o o dos aspectos y proporciona un tipo de etiqueta que puede ser adjuntada al sistema involucrado y al medium que contiene los datos. El aspecto f sico del medium alude al formato denido en el estndar a DICOM. La parte de informacin descrita por la Clase SOP es el segundo o aspecto incluido en el Perl de la aplicacin. o
Figura 2.11: Estatuto de conformidad con perl de aplicacin o
2.1.5.
Estndar DICOM a
El estndar DICOM est dividido en varias partes, cada una de ellas a a describiendo una cuestin importante tal como las Clases de Servicio, los o IODs, temas relacionados con Network y Media, etc. En la gura 8 se ve una visin general de la relacin entre las diferentes partes. o o En este apartado las partes de DICOM son abordadas en el mismo orden que los temas planteados en los apartados anteriores. Puede ser usada como l nea directiva para empezar a leer las varias partes del estndar DICOM. a
25
Jos Ma Onrubia e
La parte 1 da una introduccin y una visin general del estndar DICOM o o a y su relacin con otros sistemas de informacin hallados en el entorno o o cl nico. (ver Apndice A) e Las Clases de Servicio y las Clases SOP incluidas en las Clases de Servicio estn denidas en la parte 4. Para cada Clase de Servicio la operatividad a est delineada siguiendo la descripcin de las Clases SOP individuales. Para a o cada papel un proceso puede desempear los requisitos dados por los dos n con detalles del uso de los atributos si es aplicable. Dependiendo del tipo de Clase de Servicio (compuesta o normalizada) la descripcin es dando un o pequeo contexto o uno detallado. As mismo los temas que tienen que ser n descritos por cada parte de la Clase SOP en la Conformance Statement son listados. La parte 4 utiliza los IODs y los Servicios denidos en las Partes 3, 7 y 10.
Figura 2.12: Diferentes partes del estndar DICOM a Los IODs utilizados por las Clases SOP son descritos en la Parte 3. 26 GVA-ELAI-UPM r PFC0074-03
2.2. INSTANCIAS SOP DE IMAGENES DICOM (DICOM IMAGE SOP a Onrubia Jos M e INSTANCES) Empieza con la descripcin del IOD completo, dividindolo en los grupos o e de IODs compuestos y normalizados. De cada IOD se da una lista de Information Object Modules. La ultima parte dene los atributos individuales agrupados en detalle en los IOMs. Para los IODs compuestos todos los detalles son listados en esta parte, para los IODs normalizados el actual uso de los atributos depende del servicio aplicado y descrito en la parte 4. En la Parte 5 se describe la codicacin de las Instancias SOP en o un conjunto de datos. Se defeinen las reglas para los numerosos valores representativos (Value Representation) y para las sintaxis de transferencia (Transfer Syntaxes). Los Elementos de Servicio utilizados por las Clases SOP se dividen en dos partes: Parte 7 para los Servicios Network y Parte 10 para los Servicios Media. En estas partes se denen tanto la codicacin del network message o headeromo media le header. El resultado es un mensaje o archivo que c puede ser manejado por el correspondiente mecanismo de intercambio. Los dos grupos de menor nivel tratan con el intercambio f sico de datos. En la Parte 8 se describen las cuestiones de Protocolo de Red (Network protocolo), la Parte 9 dene la conexin punto-a-punto (point-to-point o conexion) (raramente utilizada) y la Parte 12 dene las cuestiones del formato de Physical Media. Todos los atributos y UIDs denidos por las varias partes del estndar a DICOM son listadas en el Diccionario de Datos (Data Dictionary) (Parte 6). El Estatuto de Conformidad se describen en la Parte 2 incluyendo la manera en que un Conformance Statement se tiene que congurar. Los Perles de aplicacin utilizados para el intercambio Media se discuten en la o Parte 12 junto con la .Application Prole layout.
2.2.
Instancias SOP de imgenes DICOM (DIa COM Image SOP Instances)
En el cap tulo precedente, se han explicado los conceptos DICOM sin describir en detalle cmo se capturan las imgenes dentro de una instancia o a SOP. En este cap tulo se ve con ms profundidad cmo se estructura la a o informacin. Se explicar la diferencia entre los distintos tipos de imgenes, o a a junto a la forma en que el proceso de creacin crea los datos de la imagen. o GVA-ELAI-UPM r PFC0074-03 27
Jos Ma Onrubia e
Final mente, se ve qu manera es la adecuada de usar la informacin creada e o por un sistema. Las clases SOP DICOM contienen una denicin de objeto (IOD) y o servicios para ser aplicados a ese objeto. En la mayor de las secciones que a se ven, slo se discute la denicin del objeto. En el manejo de los datos de o o las imgenes, como lo descrito en DICOM, est slo limitado por la transa a o ferencia (clase de almacenamiento SOP) y por el medio de almacenamiento. En este cap tulo, adems de usar los trminos almacenamiento de clase e a e instancia SOP, el trmino no DICOM, Image SOP Class/Instance, se usa e para referirse al proceso de los datos de la imagen. DICOM no tiene forma de describir el tipo de manejo de datos de las imgenes; el nombre de almacenamiento de clase SOP es poco claro y es a confuso si se usa en otros contextos.
2.2.1.
Modelo de informacin de las imgenes o a
El manejo electrnico de la informacin requiere un modelo para represeno o tar la forma en que la informacin estar estructurada. Esta estructura es o a necesaria para tener instancias uniformes y para hacer posible la descripcin o de las relaciones entre instancias de forma clara. Un modelo de informacin o de imagen deriva de la forma en que las imgenes se manejan en un a departamento de radiolog Las imgenes recogidas de uno u otro aparato, a. a son recopiladas en una carpeta perteneciente al paciente correspondiente. Las imgenes son ordenadas en la carpeta conforme al tipo de examen a realizado (series de imgenes que estn relacionadas). a a Los usuarios de cada tipo de aparato tienen su propia terminolog a para esta ordenacin, como escner, rodaja, etc. Cuando los datos de las o a imgenes de diferentes fuentes tienen que ser recogidas en un ambiente a unico, debe ser posible ordenar los datos de las imgenes de diferentes a fuentes. Esto es slo posible cuando los datos estn estructurados de o a acuerdo al mismo modelo de informacin. o
Mapping Real World Examinations El modelo de informacin de imagen DICOM est basado en suposiciones o a sobre la forma en que la informacin de diferentes aparatos estn relacionao a dos. Ver gura 2.13. Los cuatro niveles de este modelo de informacin son o paciente, estudio, serie e imagen.
28
2.2. INSTANCIAS SOP DE IMAGENES DICOM (DICOM IMAGE SOP a Onrubia Jos M e INSTANCES) Nivel de paciente El nivel del paciente contiene la identicacin y la informacin demogro o a ca de ste al cual el estudio le pertenece. Debido a que puede existir ms e a de un estudio, el nivel del paciente es el nivel ms alto (cuando toda la a informacin es recogida para un solo paciente se lleva a una cuenta). o Sin embargo, es de prctica normal usar el nivel del estudio para recoger a la informacin manejada por varios sistemas para un unica respuesta a este o estudio.
Figura 2.13: Del mundo real al modelo de informacin o
Nivel de estudio El nivel de estudio es el nivel ms importante en el modelo de ina formacin. Un estudio es el resultado de una contestacin a un cierto o o tipo de examen mdico. Todas las actividades en un departamento de e radiolog se centran en el manejo correcto del estudio. En un estudio, a la informacin de identicacin se guarda y puede contener referencias o o a informacin relacionada al mismo estudio en un sistema de administracin. o o En general, una respuesta puede envolver procedimientos de diferentes mquinas. Esto da a lugar a una serie de una o ms imgenes, dependiendo a a a del protocolo denido por el examen realizado. Todos los datos son recogidos juntos en el mismo estudio principal. Un paciente puede tener muchos estudios como resultado de otros realizados anteriormente.
29
CAP ITULO 2. ESTADO DE LA TECNICA. Nivel de serie
Jos Ma Onrubia e
Despus del nivel de estudio todas las imgenes se recogen. El nivel de e a serie identica el tipo de aparato que crea las imgenes, la fecha y el tiempo a de creacin de la serie y los detalles del tipo de examen realizado y del o equipo usado. Realizar una lista de los trminos usados en los diferentes aparatos tiene e que ser cuidadosamente considerado. Puede haber palabras que aparentemente signiquen lo mismo, pero se usan con diferencias en distintos contextos. Las series siempre son una coleccin de imgenes que provienen o a de una unico aparato. La forma en que las imgenes estn agrupadas en a a series depende del uso mdico que se les va a dar. Cmo las imgenes son e o a adquiridas por una mquina es menos importante para sta agrupacin. a e o Sin embargo, varios atributos denirn el tipo de adquisicin y se pueden a o mostrar en la visualizacin. En algunos casos la relacin entre las imgenes o o a se dene mediante la forma en que la adquisicin ha tenido lugar. o Cuando las adquisiciones en una secuencia tienen relacin espacial o o temporal, las imgenes resultantes de esta adquisicin pueden ser agrupadas a o en series. Una serie nueva debe comenzar cuando la relacin existente entre o imgenes ya no existe. a Otro criterio para agrupar imgenes puede ser coger los datos de una a unica parte del cuerpo hecho durante un estudio completo. Por ejemplo, cuando un aparato produce un nmero de imgenes del estmago de un u a o paciente desde diferentes posiciones y momentos, las imgenes pueden ser a agrupadas en una serie. Algunos sistemas producen ms de una imagen al a hacer una adquisicin de datos. Por ejemplo, algunos escneres se hacen con o a un sistema CT, las imgenes reconstruidas desde cada escaneamiento son a recogidas en series y tienen relacin espacial. El siguiente escaneamiento o estar en una nueva serie, porque en muchos casos el proceso de escanear a se hace desde diferentes posiciones. Tambin, en una serie, una imagen de referencia puede ser incluida como e una descripcin de la posicin espacial de las rodajas individuales. Ver o o gura. Diferentes reconstrucciones puede ser guardada en diferentes series.
30
2.2. INSTANCIAS SOP DE IMAGENES DICOM (DICOM IMAGE SOP a Onrubia Jos M e INSTANCES)
Figura 2.14: Ejemplo de mappingde un CT Para cada tipo de aparato mdico hay reglas deniendo los contenidos e que una serie debe describir. Las reglas usadas por un sistema dado son parte de un perl de sistema en el estatuto de conformidad DICOM.
Nivel de imagen El nivel ms bajo del modelo de informacin es el nivel de imagen. Cada a o imagen contiene la informacin de adquisicin y posicionamiento al igual o o que los datos propios de la imagen. Dependiendo del tipo de aparato, el nivel de imagen contiene datos para una slo imagen, dos imgenes (sistema o a de dos planos) o una coleccin de imgenes cogidas en un corto espacio de o a tiempo (multiframe images). El uso de multiframes images guarda la informacin duplicada en niveles o ms altos, pero es slo posible cuando la relacin entre los marcos (frames) a o o pueden ser descritos de una sola manera. Por ejemplo, los incrementos en los movimientos del sistema y del tiempo son iguales para todas los marcos. Creando un multiframe images es ms complejo y gasta ms recursos que a a GVA-ELAI-UPM r PFC0074-03 31
Jos Ma Onrubia e
creando una imagen unica. La relacin entre marcos, la capacidad del o aparato y la carga de datos producidos deber ser usada para determinar si a se debe aplicar una serie de imgenes simples o un multi marco de imgenes. a a
2.2.2.
Instancias imagen SOP (Image SOP Instances)
El modelo de informacin mostrado en la gura 2.13 es una simplicacin o o del modelo de informacin completo de imagen DICOM de la gura 2.14. o Cada bloque en este diagrama representa una entidad de informacin (ver o IODs) del IOD compuesto. Las relaciones indican los puntos cardinales para cada relacin de la entidad de informacin usada en una instancia SOP. o o Cada instancia de imagen SOP tiene que contener la informacin eso tructurada de acuerdo al modelo de informacin DICOM. Cada instancia o de imagen SOP (simple o multimarco) es una instancia compuesta SOP que contiene el rbol completo de informacin del modelo de informacin. a o o Todas las imgenes en una serie son de un mismo paciente, estudio y serie; a todas las series son del mismo paciente y estudio, etc. En cada composicin, o toda la informacin relacionada con la imgenes est disponible. o a a Este formato hace ms fcil el intercambio y el manejo (especialmente a a el almacenamiento) de la informacin pero incremente la carga de datos o cuando se transere un estudio completo. En este caso las entidades de informacin del paciente y del estudio tienen o mltiples instancias en la coleccin de las instancias SOP. En contraste, las u o instancias normalizadas SOP (con entidades de informacin simples) usan o referencias a otras entidades de informacin , perteneciendo un protocolo o ms eciente, pero requiriendo un manejo ms complejo. a a
2.2.3.
Relaciones e indenticacin o
Cuando se recoge un grupo de Image SOP Instances las cuales tienen relacin entre ellas, pero estn creadas desde diferentes aparatos, es o a importante ser capaz de marcar las entidades de informacin en diferentes o niveles. Son importantes dos aspectos:
1. Todas las modalidades deben tener un mapa (cdigo) consistente de o cmo pasar de unos datos de imagen a una instancia SOP. o 2. Las entidades de informacin individuales deben contener la identio cacin suciente de hacer un correcto marcado de las entidades de o 32 GVA-ELAI-UPM r PFC0074-03
2.2. INSTANCIAS SOP DE IMAGENES DICOM (DICOM IMAGE SOP a Onrubia Jos M e INSTANCES) informacin equivalente en otras instancias SOP. o
Figura 2.15: Modelo de informacin de una imagen compuesta DICOM o
Estructura de los datos de las imgenes a El primer aspecto requiere que los datos producidos por los aparatos sea ordenado en series que tengan una relacin como la descrita en la seccin o o nivel de serie (pgina 30). En los niveles de serie e imagen, la secuena cia de imgenes dentro de una secuencia debe ser identicado en un aparato. a Las entidades de informacin sobre el nivel de serie deber contener o a informacin perteneciente al estudio y al paciente que debe ser comparable o con la informacin de otros aparatos. La mayor de esta informacin o a o viene de fuentes externas como un sistema de planicacin. Puede ser o suministrado al aparato por la interfaz de usuario (del papel) o mediante una conexin a un sistema de informacin. o o
33
CAP ITULO 2. ESTADO DE LA TECNICA. Identicacin o
Jos Ma Onrubia e
Si los datos de imagen tienen que ser almacenados en sistemas los cuales ordenan los datos examinando el contenido de la informacin de la entidad, o debe haber un consentimiento y un acuerdo para indenticar la informacin o de la entidad por todos los sistemas (aparatos, sistemas de almacenamiento, estaciones de trabajo, etc.) los cuales manejan la informacin. o Visualizar la informacin es ms amplio que slo ordenar imgenes. o a o a La identicacin es tambin usada para acceder a los datos desde otros o e sistemas de informacin. Los sistemas de informacin normalmente usan o o claves que no necesitan ser interpretadas por los seres humanos, pero tienen que ser unicos en el ambiente en el que son usados. El mecanismo DICOM que se ha denido para estas identicaciones son los UIDs como se discuti en la seccin de Identicacin (pgina 12). Cada o o o a una de las entidades de informacin en el modelo de informacin tiene su o o propia UID, excepto para la entidad de informacin del paciente. La forma o en que la informacin debe ser identicada se dene por otros sistemas o de informacin (fuera del visor DICOM) que tratan con la administracin o o paciente. En este caso se usa un identicador ID para el paciente.
Identicacin del estudio o Como el estudio de un examen mdico realizado por un doctor es el e centro de todas las actividades en un departamento de radiolog debe ser a, reejada en todas las piezas de informacin las cuales estn relacionadas o a con el examen realizado. Para DICOM esta informacin se identica al nivel de estudio. En la o mayor de los casos el atributo UID de la instancia del estudio (Study a Instance UID) identica la entidad del estudio de informacin del estudio o perteneciente al resultado del examen del mundo real. Cuando este UID se usa de una forma consistente por todos los sistemas involucrados, no es dif relacionar todas las piezas de informacin con los cil o datos de la imagen en la instancia DICOM SOP. Sin embargo, esto requiere una unin entre todos los sistemas involucrados para transferir la clave del o sistema. UID transfer by human beings is not an acceptable practice due to length and meaningless content of the UID string, it would be error-prone. A parte de esta unin (link ), UIDs se tienen que soportar por todos los o otros sistemas, no slo los sistemas involucrados en el manejo de datos de o 34 GVA-ELAI-UPM r PFC0074-03
2.2. INSTANCIAS SOP DE IMAGENES DICOM (DICOM IMAGE SOP a Onrubia Jos M e INSTANCES) imgenes. Un sistema que genera los UIDs del estudio juega un mayor rol a para distribuir el UID a otros sistemas involucrados. Normalmente, esto deber hacerse por un Sistema de Informacin Radiolgico (RIS) o por a o o un Sistema de Informacin de Hospital (HIS), que normalmente puede no o siempre soportar el concepto UID. Cuando el soporte para el UID de la instancia del estudio no est disponible, no es posible usar este UID como unin a toda la a o otra informacin. Tiene que ser reemplazada en esos casos por otras claves. o RIS usan actualmente una o ms claves para acceder a su informacin a o almacenada, nmero de registro del estudio, etc. Esas claves se imprimen u en papel que pertenece al estudio. Esta informacin tiene que ser incluida o en la entidad de informacin del estudio y usada como reemplazo al UID o del estudio. Usar el UID del estudio como unin con las partes relacionadas de la o informacin es un aspecto importante para proporcionar un modelo de o informacin DICOM consistente, el cual puede ser expandido en otras o partes de la informacin en un departamento de radiolog o a. Esta consistencia es muy dif de mantener cuando el UID del estudio cil se reemplaza por un RIS o un mtodo espec e co de identicacin. o
Otras identicaciones A parte de las claves del sistema, los usuarios necesitan acceder a la informacin y quieren usar identicadores que tengan sentido como el o nombre del paciente, su d de nacimiento, fecha del estudio mdico, etc. a e Los aparatos mdicos tienen que proporcionar una informacin lo ms e o a consistente posible para permitir una identicacin por parte de los o humanos. La informacin de identicacin puede ser proporcionada por o o una unica fuente cuando una unin entre sistemas es posible. o Por ejemplo, el RIS da el nombre del paciente, su fecha de nacimiento, etc, como parte de la informacin para realizar un examen mdico. Este o e mtodo previene el error de mquina y permite una forma ms eciente de e a a funcionamiento.
35
Jos Ma Onrubia e
2.2.4.
Clasicacin de los datos de imagen o
El modelo de informacin dene el modelo jerrquico de las entidades o a de informacin para dejar claro cmo la informacin dentro de diferentes o o o instancias SOP pueden ser agrupadas en diferentes niveles. En este seccin o la informacin de la instancia SOP est clasicada de acuerdo a las o a funciones que tiene, pero independientemente de su lugar dentro del modelo de la informacin. Desde luego, hay una fuerte relacin entre el proceso de o o modelado y el proceso de creacin. La siguiente seccin describe la forma o o de producir los datos de la imagen. En la gura 2.16 se muestra una descripcin de la clasicacin y la o o relacin con la arquitectura del sistema de un aparato mdico. Las difero e entes clases son creadas en diferentes momentos en el tiempo cuando se realiza un examen mdico. Cada subsistema aade atributos al resultado e n nal: la instancia de imagen SOP. La siguiente seccin discute las clases de o informacin con ms detalle. o a
Informacin del paciente o Esta clase contiene informacin sobre el paciente al que se le realiza un o estudio. En un departamento de radiolog la informacin del paciente a o se sabe por otras fuentes, como sistemas de informacin o formularios en o papel. Slo tiene que ser registrado de una manera formal por un nmero de o u atributos como nombre del paciente, ID del paciente, fecha de nacimiento, etc. La informacin en esta clase es estable, excepto por la correccin de o o errores de escritura y cambios de nombre en caso de enlaces matrimoniales, etc. El mantenimiento de esta informacin se hace por sistemas que actan o u como fuentes para aparatos mdicos. e Uno o ms atributos son clave para la informacin en otros sistemas de a o informacin. Otros atributos identican al paciente como una persona o o dan ms detalles sobre su condicin. Un nmero de esos atributos son muy a o u importantes para el proceso completo de identicacin y conexin a otra o o informacin en un departamento de radiolog o a. Para permitir la identicacin del paciente y la revisin de un estudio, o o el aparato mdico tiene que incluir esos atributos en las instancias SOP e creadas. Procesos en el hospital tambin tienen que enfrentarse con el manejo de e 36 GVA-ELAI-UPM r PFC0074-03
2.2. INSTANCIAS SOP DE IMAGENES DICOM (DICOM IMAGE SOP a Onrubia Jos M e INSTANCES) la informacin en casos excepcionales. Por ejemplo, cuando un paciente o desconocido es examinado por emergencia, se deben realizar unos pasos para permitir que la informacin sea correctamente identicada cuando se o conoce el nombre del paciente.
37
Jos Ma Onrubia e
Figura 2.16: Clasicacin de la informacin de la imagen o o
38
2.2. INSTANCIAS SOP DE IMAGENES DICOM (DICOM IMAGE SOP a Onrubia Jos M e INSTANCES) Informacin del estudio o La informacin del estudio es una clase con una mezcla de informacin o o fuente. Por un lado, la informacin ser suministrada desde un sistema o a como un RIS (Sistema de Informacin Radiolgico) que identica el o o estudio a travs de ms de un sistema. Por otro lado, el aparato mdico e a e aadir informacin sobre el paciente en el momento en que el estudio n a o se realiza. Informacin de otros sistemas incluyen una identicacin del o o estudio. Un UID de una instancia de un estudio es la forma ms eciente a de identicacin, pero tiene desventajas (ver pgina 34). Un atributo o a alternativo, llamado nmero de acceso, puede ser usado en un sistema RIS. u En el caso de que no est disponible un UID de la instancia del estudio e desde fuera de un aparato mdico, ste tiene que generar el UID de forma e e que garantice que es el unico en el sistema. Cuando las imgenes de un estudio se copian desde un almacenamiento a local para un destino remoto, es muy importante que se use el mismo UID de la instancia del estudio. Esto previene la existencia de imgenes con a diferentes identicaciones provinientes un mismo estudio. Tales imgenes a nunca pueden ser recogidas juntas sin la intervencin de un operador. o Otra informacin suministrada al aparato mdico son los nombres de o e los mdicos solicitantes o la lectura de las imgenes y la informacin del e a o paciente dinmica como la edad, el peso, la ocupacin, etc. a o La informacin incluida localmente por el aparato mdico identica el o e estudio proporcionando un valor para el atributo ID del estudio y la fecha y hora actual del estudio. El ID del estudio es slo relevante por el aparato o usado para realizar el examen mdico. e
Informacin de la serie o La clase de informacin de serie es la primera que es completamente o generada por el aparato mdico. En esta clase el tipo de sistema, la e localizacin y la identicacin del sistema se da. La identicacin de las o o o series consiste de un UID de la instancia de la serie, que unicamente identica la serie en los datos de la imagen y una serie en la zona usada ID que puede ser usado para hacer una secuencia con series en un estudio. Los ID de las series tienen slo un signicado para el aparato mdico en o e s mismo, no hay una regla dada para este uso. Con la informacin de las series, se suministran ms detalles sobre la foro a ma en que las series son realizadas, la gente involucrada, la parte del cuerpo GVA-ELAI-UPM r PFC0074-03 39
Jos Ma Onrubia e
examinada, etc. La parte de la informacin del equipo contiene informacin o o general sobre el sistema usado por esta serie. Incluye informacin sobre la o localizacin, la identicacin del tipo y la serie, cuestiones de calibracin, o o o etc. Estos datos pueden ser compartidos por series pertenecientes al mismo estudio y realizados mediante el mismo aparato mdico. e Se usa un marco de referencia para agrupar imgenes que tienen relacin a o espacial o temporal. Esto puede ser usado para dividir series en partes o a travs de ms de una serie si se aplica la misma relacin. Tal relacin se e a o o identica por un UID de marco de referencia compartido entre las imgenes a involucradas.
Informacin de la aplicacin o o Los atributos en esta clase dan informacin sobre la imagen contenida en o la instancia SOP requerida para el diagnstico y otras aplicaciones. Varios o ejemplos, desde un simple texto aadido como comentario, hasta detalles n como el contraste, terapia y dispositivos usados durante el reconocimiento mdico. e Otro grupo describe la parte del cuerpo examinada usando valores codicados. Los ajustes del valor de inters (VOI), en la mayor de los e a casos llamado anchura de ventana y centro de ventana (window width y window center), son miembros muy importantes de esta clase. El VOI es la seleccin fuera de la gama completa de los valores de pixel que son o cl nicamente signicativos cuando se muestra o se imprime la imagen. Slo o el rango especicado tiene que ser convertido a nivel de grises disponibles. La informacin que dibuja l o neas o agrega el texto a la imagen mostrada puede ser en forma del velo matrices que tiene que ser agregado a la demostracin por una estacin de inspeccin, o ya aplicados(aplicado) al o o o matriz de pixel (quemado en). Sumnistrando la superposicin como una o informacin separada de los datos de imagen, la imagen puede ser mostrada o con o sin la superposicin, permitiendo que los datos de imagen puedan ser o usados como entradas para el tratamiento remoto.
Informacin adquirida o En esta clase de informacin se guardan los ajustes del equipo de o adquisicin. El grado de informacin depende del tipo de aparato y puede o o tener un rango desde unos pocos atributos para un sistema sencillo, a una estructura compleja. Contiene detalles del sistema de adquisicin como los o 40 GVA-ELAI-UPM r PFC0074-03
2.2. INSTANCIAS SOP DE IMAGENES DICOM (DICOM IMAGE SOP a Onrubia Jos M e INSTANCES) valores usados de los rayos X por ejemplo. Las imgenes resultantes de la misma adquisicin pueden ser identicadas a o con un nmero de adquisicin. Este agrupamiento depende del sistema u o y puede ser parte de series sencillas, pero una adquisicin sencilla puede o tambin resultar en mltiples series de imgenes, cada una con diferentes e u a caracter sticas. La adquisicin no tiene relacin con el modelo de informao o cin DICOM y no tiene un identicador UID equivalente. o
Informacin de la posicin o o Una clase importante es la informacin dada sobre el posicionamiento de o la imagen dentro del paciente. Depende del tipo de aparato mdico, de la forma en que se describe la e matriz de la imagen posicionada usando trminos sencillos como anterior, e posterior, derecha, en frente, etc. Se debe tener cuidado para asegurar que hay proporcionada informacin suciente con la imagen para que no haya o visualizaciones ambiguas (sobre todo en cuestiones de derecha e izquierda). En una serie que tiene relacin espacial, como puede ser imgenes CT o a o MR, muchos ms detalles se tienen que suministrar sobre la posicin a o de las imgenes en el espacio tridimensional del cuerpo del paciente. Esta a informacin permite a sistemas como planicadores de tratamiento de o radioterapia usar el posicionamiento tridimensional para el procesamiento de los datos de las imgenes. a Otro uso de la informacin del posicionamiento es para sistemas de o vasculacin para describir los movimientos dinmicos. o a
Informacin de los datos de las imgenes o a Finalmente, los datos de las imgenes provenientes del sistema de a adquisicin y procesadas para producir imgenes visibles en formato o a digital. Esta clase describe detalles sobre cmo los datos de los p o xeles deben ser interpretados, como el tamao de la matriz de p n xeles, la valor representativo de p y cmo estos estn codicados. xel o a Cuando los aparatos mdicos son capaces de generar imgenes en e a color, tiene que ser suministrada la informacin sobre cmo los datos son o o ordenados en diferentes planos. A parte del formato de la informacin, esta o clase contiene los datos de los p xeles en un marco sencillo, en dos marcos GVA-ELAI-UPM r PFC0074-03 41
Jos Ma Onrubia e
para sistemas de dos planos o en multimarco. Cuando un multimarco se genera por un sistema de dos planos es posible almacenar los marcos de los dos planos juntos. En este caso los marcos de los dos planos se almacenan alternados (A-B-A-B-...). Para un multimarco las relaciones de tiempo entre los marcos individuales se describen mediante otros atributos. La imagen se identica unicamente por el UID de la imagen. Como una instancia SOP de una clase de imagen SOP siempre incluye una porcin de la imagen, el UID de la imagen se usa tambin como UID de o e la instancia SOP. Este UID se use para identicar la instancia cuando se transere o se recupera desde un almacen de imgenes o para identia car la entidad de la imagen usndola en un rbol jerrquico de informacin. a a a o
2.2.5.
Extensin de la informacin o o
Para el almacenamiento de toda la informacin descritas en las clases o de arriba se denen atributos que se agrupan en IODs (Information Object Denitions) los cuales dan una descripcin genrica de las instancias o e SOP para cada tipo de aparato mdico. Los atributos que se usan actuale mente deben ser descritos en el Estatuto de Conformidad (perl del sistema). No siempre es posible guardar toda la informacin generada por un o aparato en un IOD estndar. En casos el equipo tiene nuevos campos los a cuales necesitan informacin adicional para alamacenarlos en un nuevo o IOD. Se debe tener cuidado en que las partes que usan esta informacin o sern capaces de entender esta nueva informacin. Estos detalles se tienen a o que publicar en el Estatuto de Conformidad. Si el uso se acepta, la nueva informacin llega a formar parte del estndar. o a La extensin puede no inuenciar la semntica de la informacin guardao a o da en los atributos estndares. Tiene que ser un subconjunto apropiado, a compatible con el IOD del que deriva. En otros casos, el equipo de un vendedor unico, puede aadir informacin para ser usada slo en la n o o combinacin de sistemas o slo por el mismo sistema que ha generado los o o datos. En esta situacin, no existen detalles sobre la informacin que tiene o o que ser publicada en el Estatuto de Conformidad. No hay intencin por o otras partes de usar esta informacin adicional. o Para permitir la extensin de informacin, DICOM ha denido dos tipos o o de atributos: atributos estndar y privados. a Los primeros se usan para codicar los atributos descritos en el estndar a IOD (ver seccin .Atributospgina 9). Si no hay extensiones o cambios en o a 42 GVA-ELAI-UPM r PFC0074-03
2.2. INSTANCIAS SOP DE IMAGENES DICOM (DICOM IMAGE SOP a Onrubia Jos M e INSTANCES) los IODs, la clase SOP es una clase SOP estndar. a Los segundos denen atributos o usan atributos estandarizados no pertenecientes al IOD de una clase SOP espec ca, no se pude seguir llamando clase estndar SOP y depende del efecto que cambia a uno de los a siguientes tipos: Clase SOP extendida: cuando los atributos adicionales no cambian el uso de la clase SOP. En este caso es un super-conjunto, cuando se usa por sistemas los cuales no son conscientes de las aadidos, se pueden ignorar n y la imagen puede ser manejada como se dice en la clase SOP estndar. a Una clase SOP extendida usa el mismo UID que la clase SOP estndar. Las a diferencias entre las dos clases se muestra en el Estatuto de Conformidad. Clase SOP especializada: cuando las adiciones cumplen con el modelo de informacin, pero la clase ya no es un super-conjunto. Como consecuencia, o el UID de la clase SOP estndar puede no ser usado; se debe usar un UID a privado para esta clase SOP. Los socios que manejan las instancias SOP conocen el UID privado y pueden manejar la informacin. Otros no pueden o aceptar la clase SOP durante la negociacin de la asociacin o, cuando se o o abre un archivo DICOM desde un medio DICOM. Las Clases SOP privadas no siguen el modelo de informacin DICOM y o se usan en un contexto completamente privado. Usan mecanismos proporcionados por DICOM para transferir la informacin. Las clases SOP privadas o usan UIDs privados para prevenir usos incorrectos de la informacin. o Si una de las tres clases SOP arriba mencionadas se denen con la intencin de llegar a ser parte del estndar DICOM, los detalles se publican en o a el Estatuto de Conformidad. De otra forma, slo se usan en un ambiente o cerrado.
2.2.6.
Tipos de imgenes a
DICOM dene un nmero de tipos de clases de imgenes SOP, dependiu a endo del aparato mdico que crea la los datos de las imgenes. Cada tipo e a tiene su propio IOD para aadir informacin espec n o ca del aparato a la instancia de la imagen SOP. Todas las instancias de las imgenes SOP comparten un m a nimo juego de informacin que permite a una aplicacin visualizadora manejar las o o imgenes independientemente de su tipo. a Una clase de imagen SOP est disponible para encapsular las imgenes a a que no estn disponibles en el formato digital y s capturadas en formato a de pel cula o de v deo.
43
CAP ITULO 2. ESTADO DE LA TECNICA. Tipos genricos de imgenes e a
Jos Ma Onrubia e
Las instancias de las clases de las imgenes SOP tienen un conjunto a bsico de atributos; ver gura(2.17). El conjunto m a nimo de atributos requeridos para una instancia de imagen SOP consiste en el siguiente grupo de atributos:
Atributos identicadores: UID de clase SOP, UID de la instancia del estudio, UID de la instancia de la serie y UID de la instancia de la imagen (= UID de la instancia SOP).
Tipo de aparato.
Descripcin de la matriz de p o xeles: muestra por p xel, las, columnas.
Interpretacin del valor del p o xel: interpretacin fotomtrica. o e
Codicacin de los p o xeles: bits asignados, bits almacenados, bit alto, representacin de pixel, conguracin plana. o o
Matriz de p xeles: datos de p xel. 44 GVA-ELAI-UPM r PFC0074-03
2.2. INSTANCIAS SOP DE IMAGENES DICOM (DICOM IMAGE SOP a Onrubia Jos M e INSTANCES)
Figura 2.17: Juego bsico de atributos de las instancias de imagen SOP a Este m nimo conjunto permite mostrar los datos de p xel y proporciona la identicacin en el nivel de sistema, para el caso de la instancia SOP o para adherirla modelo de la informacin. Aadiendo ms informacin al o n a o menos para los tres primeros niveles del modelo de informacin, hace ms o a entendible a la instancia SOP. Los atributos que identican la instancia SOP para seres humanos y permiten que la imagen sea mostrada. Aadiendo ms informacin para al menos los tres primeros niveles del n a o modelo de la informacin, hace la instancia SOP ms comprensible. Los o a atributos que identican la instancia SOP para los seres humanos y permiten que la imagen sea visualizada con los correctos ajustes de ventana son:
Nivel de paciente: nombre, ID, d de nacimiento, sexo. a Nivel de estudio: fecha del estudio, hora, nombre del mdico, ID del e estudio, nmero de acceso. u GVA-ELAI-UPM r PFC0074-03 45
Jos Ma Onrubia e
Nivel de serie: nmero de serie, fabricante, nombre de la institucin. u o Nivel de imagen: nmero de imagen, tipo de imagen. u Ajustes de presentacin: ancho de ventana, centro de ventana. o Los atributos listados arriba son en la mayor de los casos atributos del a tipo 2 (deben ser suministrados, pero pueden faltar) o del tipo 3 (opcionales).
Tipos de imgenes especiales a El formato genrico descrito arriba se usa en la denicin de cada clase e o SOP, pero depende del tipo de aparato, esto se extiende con la informacin o entregada sobre la adquisicin, etc. El nmero de imgenes especializadas o u a est creciendo por la aparicin de nuevas mquinas mdicas. a o a e Normalmente, los siguientes aparatos tienen una denicin de la clase de o almacenamiento SOP en el estndar DICOM: a
Radiograf computada IOD, usada por los sistemas radiogrcos a a tradicionales que trabajan con fsforo que brilla al leerse con sistemas o como PCR. Tomograf computada IOD para escneres CT. Para este tipo a a de aparatos el posicionamiento es importante, para montones de imgenes, para crear vistas tridimensionales. a Resonancia magntica IOD para sistemas IOD. A parte de la misma e informacin que para escneres CT tambin se da informacin adio a e o cional sobre el protocolo de adquisicin. o Medicina nuclear IOD para cmaras usan istopos radiactivos. Cona o tienen imgenes de especial formato para este tipo de aparatos. Las a imgenes son en multimarco formato. a Ultrasonidos IOD para este tipo de equipos. Estos contienen detalles sobre la posicin y la adquisicin de la imagen. Las imgenes pueden o o a ser en color y se puede usar el multimarco. Angiograf con rayos-X IOD para sistemas digitales cardiolgico y a o basculares. Este formato puede capturar una cadena en multimarco o imgenes simples. Inside a run a description of which images are a a mask for image subtraction can be added. Extensive information about the equipment positioning and acquisition is given to allow the image data to be processed. 46 GVA-ELAI-UPM r PFC0074-03
2.2. INSTANCIAS SOP DE IMAGENES DICOM (DICOM IMAGE SOP a Onrubia Jos M e INSTANCES) Radiouoroscop de rayos-X IOD para sistemas como sistemas ana giogrcos, pero hacer una mesa con columnas en vez de brazos C. a La mayor diferencia es la forma en que se describe la posicin de las o piezas del equipo.
Por cada uno de los IODs, se describe una lista de mdulos en el o estndar DICOM. El uso de unos ciertos mdulos a veces dependen de a o capacidades o condiciones de ciertos sistemas. Los mdulos se seleccionan o o desde un grupo de mdulos comunes usados para todos los IODs de o almacenamiento SOP, o mdulos espec o cos para slo un tipo de IOD. o Estos mdulos contienen atributos especiales para ese tipo de IOD. Esos o mdulos, y a veces atributos individuales, los redenen y extienden para el o IOD genrico. En la parte PS3.3 del estndar DICOM los IOD, IOM y los e a atributos se listan. El anexo A contiene la lista de IOM para cada IOD. En el anexo C.7 se describen los mdulos comunes de los IODs, en el anexo o C.8 los mdulos espec o cos de los aparatos mdicos. El anexo C.9 mediante e C.12 dene un nmero de mdulos que pueden ser aadidos al objeto u o n imagen, como un mdulo ms, un valor de inters (VOI), informacin, etc. o a e o
2.2.7.
Aplicacin de los datos de imgenes o a
Las clases de imagen SOP, en general, se generan en aparatos mdicos o e en estaciones de trabajo dedicadas a procesamiento. Las clases de imagen SOP se visualizan en estaciones de revisin o son imprimidas sobre pel o cula. Los sistemas de almacenamiento guardan en el bfer las imgenes en un u a fase intermedia o archivan estas imgenes por referencia en un estado a posterior. Los requerimientos para la informacin contenida en la instancia o de imagen SOP (Image SOP Instance) dieren para cada tipo de sistema el cual est envuelto en el ciclo de vida de una imagen. a Intercambiando datos entre sistemas, cada sistema puede tener una diferente visin de la informacin, pero se debe tener mucho cuidado con que o o toda la informacin en la instancia de imagen SOP sea transferida entre cao da sistema involucrado. Incluso cuando un sistema en una cadena no usa la informacin, otro sistema, que s que la usa en una fase posterior, est cono a ando en el paso completo de la informacin en la cadena entera, ver gura o (2.18). GVA-ELAI-UPM r PFC0074-03 47
Jos Ma Onrubia e
Figura 2.18: Ciclo de vida de Image SOP Instance Information
Sistemas de almacenamiento de imgenes a Los sistemas de almacenamiento de imgenes usan un nmero de a u atributos identicatorios para almacenar las instancias de imagen SOP. En primer lugar, estos atributos se usan para recoger todos los datos de las imgenes pertenecientes al mismo estudio. La instancia UID del a estudio (Study Instance UID) es el atributo clave. Pero cuando ste no se e usa consistentemente, se tienen que usar otros atributos como el ID del paciente, nmero de acceso, etc. u En segundo lugar, unos atributos pueden ser usados por sistemas que quieren encontrar instancias de imagen SOP en el sistema de almacenamiento. La clave principal en este caso es la instancia UID del estudio y la instancia UID de la serie. Son posibles tambin bsquedas basadas en el e u nombre del paciente, fecha del estudio, etc. Para el uso de sistemas de almacenamiento un valor muy signicativo para estos tipos de atributos se tiene que suministrar por los creadores de la instancia de la imagen SOP. Los atributos que contiene los parmetros de a adquisicin y los datos de la imagen se almacenan pero no tienen signicado o para un sistema de almacenamiento.
48
2.2. INSTANCIAS SOP DE IMAGENES DICOM (DICOM IMAGE SOP a Onrubia Jos M e INSTANCES) Estaciones de revisin o Una estacin de revisin es bsicamente usada para visualizar las o o a imgenes hechas en una o varios aparatos. Recoge o busca las instancias de a imagen SOP, en un sistema de almacenamiento, perteneciente a un cierto estudio. Mostrar la imgen junto a la informacin del paciente, ajustes de a a o adquisicin, informacin del diagnstico, etc. o o o Los ajustes paraa el proceso de presentacin, como los seleccionados en el o aparato de captura, son muy importantes. Cuando los pasos de presentacin o se procesan de forma correcta, los resultados mostrados deber ser iguales an a los originales mostrados por el aparato mdico de captura de la imagen. e Para informacin adicional de otros sistemas, se usan atributos identio cadores como la instancia UID del estudio.
Estaciones de procesamiento de imgenes a Las estaciones de trabajo capaces de procesar los datos de las imgenes a tienen requerimientos adicionales. Se necesitan los parmetros de adquisicin a o y posicionamiento para la realizacin de pasos adicionales de procesamiento. o Dependiendo en el tipo de procesamiento la entrada es un conjunto de imgenes procesadas o no procesadas. En este caso la relacin entre las a o imgenes es importante ordenar los datos de las imgenes de forma correcta a a para el procesamiento. Los resultados de este procesamiento son nuevos datos de p xeles que son almacenados en una nueva instancia de imagen SOP que tiene su propio ciclo de vida con, en la mayor de los casos, relaciones con los datos originales a usados por esta imagen.
Reutilizacin de datos o Una categor nal de las aplicaciones es el sistema que ha creado la a instancia de imagen SOP. En este caso los datos antiguos de la imagen pueden ser usados cuando hay una nueva visita del mismo paciente con el mismo tipo de examinacin. Los datos de adquisicin y el posicionamiento o o pueden ser reutilizados, o la imagen puede ser visualizada como una referencia para el nuevo examen.
49
CAP ITULO 2. ESTADO DE LA TECNICA. Categor de aplicacin as o
Jos Ma Onrubia e
Como lo mostrado arriba, las exigencias de los sistemas individuales en el ciclo de vida de una una instancia de imagen SOP son diferentes. Cuando un sistema produce los datos de la imagen, debe estar alerta de que todos los sistemas que estn intentando ser parte del ciclo de vida deben recibir a suciente informacin. El estatuto de conformidad (conformance statement) o debe describir, para cada tipo de sistema, la informacin adecuada y que o procesamiento no pueden ser aplicados. Para ayudar a la seleccin de estos tipos de sistemas, los requerimientos o pueden ser divididos en categor de aplicacin. Una categor alta as o a numerada incluye la categor baja numerada. Se denen las siguientes a categor as:
1. Categor de almacenamiento: slo identica los atributos requeridos. a o 2. Categor de visualizacin: slo se requieren los atributos para una a o o correcta presentacin. o 3. Procesamiento simple - medidas de volumen y distancia: requiere algunos atributos ms que describan qu informacin est en la imagen. a e o a 4. Procesamiento complejo - sustraccin de imagen y MRP: requiere o informacin espec o ca sobre el posicionamiento y relaciones.
El comit de estandarizacin DICOM est considerando una clasicacin e o a o como la lista vista arriba para ser incluida en el estatuto de conformidad.
50
Cap tulo 3
Estudio de librerias DCMTK.

3.1. Visin general. o
La tecnolog de la informacin y la comunicacin poco a poco est llea o o a gando a ser omnipresente en el cuidado de la salud. Los requerimientos para un rpido acceso a los datos mdicos en el a e momento necesario slo se puede conseguir mediante los estndares. El o a estndar de DICOM facilita el intercambio y el procesamiento de imgenes a a biomdicas de forma digital. Los aparatos de adquisicin de imgenes, e o a archivos de imgenes y las estaciones de trabajo de diferentes vendedores, a pueden estar conectadas en una infraestructura comn e integradas con u otros sistemas de informacin. Nuevas oportunidades se alzan, no slo o o dentro del hospital, tambin para el intercambio de informacin entre e o diferentes cl nicas y entre hospitales y prcticas mdicas. a e
3.1.1.
Introduccin. o
La importancia del procesamiento de imgenes mdicas a crecido permaa e nentemente desde la introduccin de la tomograf computada como primer o a aparato digital en 1970. La idea de unas imgenes digitales y una distribucin electrnica de a o o stas en el hospital cre la necesidad de intercambiar las imgenes digitales e o a entre recursos de diferentes vendedores. En 1983 se formaron los grupos de American College of Radiology (ACR) y el National Electrical Manufacturers Association (NEMA) con el objetivo de descubrir un estndar para a el intercambio. Los trabajos resultaron en el estndar ACR-NEMA, el cul a a 51
CAP ITULO 3. ESTUDIO DE LIBRERIAS DCMTK.
Jos Ma Onrubia e
fue publicado en 1985. Sin embargo este estndar no tuvo xito devido a a e una cierta debilidad conceptual. El estndar de DICOM (Digital Imaging and Communications in a Medicine) fue creado desde las bases del ACR-NEMA para crear y abrir una plataforma para la comunicacin de imgenes y datos relacionados. o a Adems de este soprte, la garant de interoperatividad entre aparatos a a DICOM y programas fue la parte central de su xito. DICOM fue publicado e en 1993 y se est extendiendo continuamente desde entonces. DICOM fue a aceptado como estndar formal en Europa en 1995. a
3.1.2.
Descripcin. o
Los contenidos del standard de DICOM van ms all de una denicin a a o del formato de los datos de las imgenes mdicas. a e DICOM dene:
Estructuras de datos (formatos) para imgenes mdicas y datos a e relacio-nados, Servicios orientados a la red. Formatos para el almacenaje de medios de intercambio. Requerimientos para el acuerdo de recursos y programas.
3.1.3.
Estructura de datos DICOM.
Una imagen DICOM consiste en lista de elementos de datos (llamados atributos) que contiene una multitud de imagen la informacin relacionada: o
paciente (nombre, sexo, identicacin, nmero) o u aparatos y procedimiento de imagen(parmetros de dispositivo, calia bracin, dosis de radiacin, medios de comunicacin de contraste), o o o imagen (resolucin, windowing) o DICOM con precisin dene para cada aparato, los elementos de o datos son requeridos, los q son opcionales y que es requerido en ciertas circunstancias. Esta exibilidad sin embargo, tan poderoso como es, es tambin una debilidad del estndar porque la experiencia prctica muestra e a a que las imgenes son con frecuencia incompletas: los campos requeridos a 52 GVA-ELAI-UPM r PFC0074-03
Jos Ma Onrubia e
3.1. VISION GENERAL.
omiteno contienen valores incorrectos. Esto puede conducir a problemas en el intercambio de datos.
3.1.4.
Servicios de red DICOM.
Los servicios de red de DICOM estn basados en los concepto de cliente a / servidor. Antes de que dos aplicaciones DICOM puedan intercambiar la informacin, ellas deben establecer una conexin y estar de acuerdo sobre o o los parmetros siguientes: a
Quien es el cliente y quien es el servidor, que servicios DICOM deben ser usados, y en que formato los datos son transmitidos (Comprimido o incomprimido). Slo si ambas aplicaciones estn de acuerdo en un unos parmetros o a a comunes, la conexin se establece. o
3.1.5.
Intercambio de medios de comunicacin. o
Adems de la comunicacin de imgenes mdicas sobre la red, el intera o a e cambio de medios de comunicacin se ha hecho otro foco en DICOM que o ha sido integrado en el estndar slo en la edicin 1996. Los campos de a o o aplicacin son por ejemplo el almacenaje o la pel o culas de angiograf en as la cardiolog o el almacenaje de imgenes de ultrasonido. Para asegurarse a a de que los medios de comunicacin de almacenaje DICOM son realmente o intercambiables, el estndar dene los llamados perles de aplicacin que a o explica detalladamente.
que aparatos pueden estar presentes en el medio que formatos de codicacin y compresin pueden ser usados o o que medio de almacenaje debe ser usado Cada medio DICOM contiene un llamado DICOM directorio .adems a de los archivos de imagen. Este directorio contiene la informacin ms o a importante (el nombre paciente, la modalidad, identicadores unicos etc.) para todas las imgenes en el medio. Esto permite hojear o buscar a rpidamente sin haber de necesidad de leer el medio completo. a
53
Jos Ma Onrubia e
3.1.6.
Estatuto de conformidad.
DICOM requiere que una Declaracin de Conformidad sea escrita para o cada dispositivo o la reclamacin de programa para ser DICOM conforo mant. El formato y el contenido de esta declaracin son denidos en el o estndar. Esto explica que servicios DICOM y opciones son soportados, que a extensiones y particularidades han sido puestas en prctica por el vendedor, a y como el dispositivo se comunica con otros sistemas DICOM. En la teor a, comparando dos declaraciones de conformidad permite determinar si dos dispositivos DICOM son capaces de comunicarse el uno con otro. En la prctica, sin embargo, las declaraciones de conformidad son slo a o comprensibles para expertos y son con frecuencia inadecuados.
3.1.7.
Conclusin. o
DICOM se ha hecho un componente indispensable para la integracin o de sistemas de imagenes digitales en la medicina. DICOM ofrece soluciones para una multitud de comunicacin aplicaciones relacionadas. La o palabra clave DICOMsolo, sin embargo, no es ninguna garant para una a integracin de enchufar y listode todos los sistemas de informacin en o o hospital. Esto requiere una combinacin cuidadosa de todas las soluciones o parciales ofrecidas por DICOM. DCMTK es el software DICOM proporcionado gratuitamente por OFFIS-DICOM, el cual se puede descargar de la pgina web. a DCMTK es una coleccin de librer y aplicaciones que implementan o as las partes del estndar DICOM para la comunicacin de imagen mdica. a o e Esto incluye el software para el examen, la construccin y la conversin o o archivos de imagen DICOM, el manejo medios de comunicacin autnomos, o o el env e imgenes de encubrimiento sobre una conexin de red, as como o a o la demostracin del almacenaje de imagenes y servidores worklist. DCMTK o incluye el cdigo fuente completo y est escrito en una mezcla de C ANSI o a y la C ++. DCMTK ha sido usado en numerosas demostraciones DICOM para proporcionar central, el vendedor independiente, el almacenaje de imagen y servidores worklist (CTNs - Nodos Centrales De prueba). Es usado por hospitales y empresas en todo el mundo para una amplia variedad de propsitos desde ser una herramienta para pruebas de productos, a ser un o componente bsico para proyectos de investigacin, prototipos y productos a o comerciales 54 GVA-ELAI-UPM r PFC0074-03
Jos Ma Onrubia e
3.2. INSTALACION DCMTK351.
El software DCMTK puede ser compilado bajo el Windows NT o una amplia gama de sistemas operativos Unix que incluyen Linux, Solaris, OSF/1, IRIX, FreeBSD y MacOS X. Todos los guiones de conguracin o necesarios y makelesde los proyecto son suministrados. Trabajar con esta herramienta es muy arduo y dicultoso debido a la poca documentacin, a la dicultad que entraa el trabajar con todos o n los trminos DICOM y a la amplitud del cdigo. Por estas razones y e o por alguna ms es ms aconsejable trabajar con una nueva herramienta a a que cuenta con la desventaja de que no es gratuita pero con las ventajas de una gran documentacin plenamente estructurada y el trabajar con Java. o
3.2.
Instalacin dcmtk351. o
OceDicom ofrece la posibilidad de conseguir gratuitamente de su pgina web, http://www.os.de, el Toolkit dcmtk351, donde se encuentra a el estndar DICOM implementado en cdigo C++. Para la instalacin del a o o toolkit de OceDicom en un sistema operativo basado en Windows, hay que descomprimir el archivo dcmtk531.zip. Entonces abriremos el proyecto dcmtk.dsp y lo compilaremos y construiremos con el Visual C++, este proyecto se encuentra en X:/.../Toolkit/source/dcmtk. Esto crear todos a los ejecutables y archivos .obj y .lib en una carpeta llamada OpenSSL de cada una de las funciones existentes en este toolkit las cuales podrn ser a utilizadas en otros proyectos, bastando incluirlas en stos. e Este Toolkit tiene diferentes funciones basadas en el estndar Dicom. a Hay varias carpetas con los archivos fuente de las funciones. Las funciones son agrupadas en carpetas dependiendo de la funcin que desempeen. o n
Cong: Incluye los cheros .h necesarios para la conguracin del o toolkit. Dcmdata: Contiene funciones para el tratamiento de los datos de los archivos Dicom y Data Sets. Dcmimage: Fuciones para el tratamiento de los datos de los pixel de una imagen. Slo para imgenes Dicom sin comprimir. o a Dcmimgle: Sirven para el tratamiento de la luminosidad de las imgenes. a GVA-ELAI-UPM r PFC0074-03 55
Jos Ma Onrubia e
Dcmjpeg: Son funciones para la compresin/descompresin de o o imgenes DICOM a JPEG. a Dcmnet: Funciones para el transporte de los archivos Dicom a travs e de la Red. Dcmpstat: Funciones para el tratamiento de escalas de grises y estados de presentacin. o Dcmsing: Para la creacin o supresin de una rma digital para un o o archivo Dicom y su vericacin. o Dcmsr: Para la conversin de documentos Dicom SR (Structured Reo porting) a HTML, XML . Dcmtls: Para la transmisin segura de archivos Dicom por la Red. o Imagectn: Para el registro de archivos en una base de datos. Wlistctn: Para implementar un SCP como una Base de Datos. Nos centraremos en las funciones para el transporte de archivos y la compresin a Jpeg. o
Figura 3.1: Visual C++ con DCMTK 56 GVA-ELAI-UPM r PFC0074-03
Jos Ma Onrubia e
3.2. INSTALACION DCMTK351.
3.2.1.
Dcmnet.
Echoscu: Esta aplicacin implementa un Service Class User (SCU) o para la vericacin SOP Class.Env un mensage Dicom C-ECHO a o a un Service Class Provider (SCP) y espera una respuesta. Findscu: Esta aplicacin implementa un Service Class Query/Rerieve o (peticin/recuperacin) y un Service Class Basic Worklist Manageo o ment. Slo soporta el mensage Dicom C-FIND, que env una peticin o a o al SCP y espera respuesta. Movescu: Esta aplicacin implementa un SCP para el Service Class o Query/Retrieve y un SCU para el Storage Service Class. Para usar la funcionalidad Retrieve (Recuperacin) usa el mensage Dicom Co MOVE que env una peticin al SCP y espera respuesta. El SCP a o aceptar la asociacin para recibir imgenes enviadas como resultado a o a de la peticin C-MOVE. El trmino MOVE es poco apropiado, ya que o e lo que hace es una copia de la imagen, la imagen nunca se borra del SCP. Storescp: Implementa un Service Class Provider (SCP) para el Storage Service Class. Se pone a la escucha sobre un espec co puerto TCP/IP, para las peticiones de asociacin que puedan llegar de un Storage SCU o y puede recibir imgenes segn el Storage Service Class. a u Storescu: Implementa un Service Class User (SCU) para el Storage Service Class.Se usa para transmitir imgenes Dicom. Env un mena a sage C-STORE a un Storage SCP y espera respuesta. Aplicacin para ver la conectividad entre dos mquinas. o a Esta aplicacin la realizaremos sobre dos mquinas, una ser Galileo que o a a actuar de SCP y otra ser Gauss que ser el SCU. Pondremos la opcin -v a a a o la cual nos dir en todo momento que asociacin se est realizando, dando a o a detalles sobre ella. Paso 1o : Realizamos una aplicacin Dicom Storage/Verication Service o Class Provider. Ponemos un puerto a la escucha (el puerto 104 es el ms a utilizado en Dicom) para la llegada de asociaciones. Galileostorescp -v 104 Paso 2o : Comenzamos una aplicacin Dicom Verication Service Class o User. Esto intentar construir una asociacin Dicom con una aplicacin que a o o corra sobre Galileo, conectndolos por el puerto 104. Gauss enviar una a a peticin C-ECHO y estar a la espera de una respuesta C-ECHO de Galileo. o a GVA-ELAI-UPM r PFC0074-03 57
Jos Ma Onrubia e
Esto es slo para vericar que hay conexin entre las dos mquinas. o o a Gauss>echoscu -v Galileo 104 Paso3o : Enviamos una imagen Dicom a Galileo (SCP). Volveremos a intentar realizar una asociacin Dicom con una aplicacin que corra sobre o o Galileo. Enviamos una peticin C-STORE que contiene una imagen Dicom o c raneo.dcm esperamos una respuesta C-STORE de Galileo. Gauss>storescu -v Galileo 104 craneo.dcm La imagen se guardar en el lugar de trabajo donde est realizandose a e la escucha del puerto 104. Por ejemplo si lo hemos hecho en un chero C:/Dicom, la imagen ser guardada en ese chero. El nombre que tendr la a a nueva imagen copiada en Gauss, ser a priori su UID, que ser unico entre a a todas las imges DICOM que tengamos. a
2
3.2.2.
Dcmjpeg.
Dcmcjpeg: Realiza la compresin de una imagen DICOM a una imagen o JPEG. Dcmdjpeg: Descomprime la imagen DICOM comprimida como JPEG. Dcmj2pnm: Lee una imagen DICOM y convierte los datos de los pixel segn las opciones del procesamiento de imgenes seleccionadas, u a PPM/PGM, BMP, TIFF o JPEG. Dcmmkdir: Crea un archivo DICOMDIR de los archivos DICOM especicados segn la aplicacin Media de almacena. u o
3.3.
DicomScope.
El DicomScope es un programa desarrollado en C++ y su entorno de ventanas en Java. Permite visualizar, imprimir, almacenar, transmitir y recibir estudios, imgenes, estados de presentacin e informes estructurados a o . Los informes estructurados (SR) consisten en informes completos de diagnstico y resultados de un examen en particular. o La aplicacin tiene cuatro partes principales: o
Browser (Navegador de estudios): El cual es la base de datos local de la aplicacin donde se encuentran los estudios (imgenes, structured o a 58 GVA-ELAI-UPM r PFC0074-03
Jos Ma Onrubia e reports,...) de la aplicacin. o
3.3. DICOMSCOPE.
Viewer: Para tratar y mostrar imgenes Dicom, imgenes de escalas a a de grises, estados de presentacin e informes estructurados. o Print: Administra e incluye los estudios para su impresin. o Process log: Muestra los procesos que se han llevado a cabo en la transmisin de archivos Dicom. o
3.3.1.
Instalacin. o
Es necesario para la instalacin un sistema compatible con Java o v1.3 y Windows 32 bits. Antes de la instalacin del DicomScope o es necesaria la instalacin de Java 2 SDK o JRE(Java 2 Runtime o Environment), para conseguir esto, se puede bajar de la pgina a http://java.sun.com/j2se/1.4.1/download.html. Tan slo hay que ejeo cutar el Setup y seguir las instrucciones dadas.
3.3.2.
Browser.
Es la base de datos del DicomScope donde se almacenan los estudios Dicom. Tiene una estructura de rbol en la que cada estudio es una rama, a y puede tener varias ramas a su vez, puede tener imgenes, informes a estructurados, imgenes de escalas de grises y estados de presentacin. a o Los nuevos estudios recibidos por Red o almacenados en la aplicacin, o a su se di-ferenciarn de los otros por que aparece un s a mbolo de New. izquierda, una vez visualizados stos, perdern el s e a mbolo. Para enviar estudios a otra mquina, hay elegir el estudio que queramos en-viar y a presionar la tecla send, entonces se abrir una ventana en la que hay que a elegir la forma de enviar los estudios, hay tres formas:
Transmisin insegura, sin proteccin de los datos en trnsito. o o a Transmisin TLS , en la que se utilizan certicados para la transmisin o o de datos. Transmisin TLS y encriptacin. o o Para poder congurar a que mquinas van a ir los estudios enviados a y que puerto utilizan para la asociacin, se hace mediante el archivo o DICOMscope.cfg que se encuentra en .../DICOMscope351, escribiendo a que hostname quiere ser en-viado y el port.
59
Jos Ma Onrubia e
Figura 3.2: Browser
3.3.3.
Viewer.
Todas las instancias Dicom que se carguen, pasarn a verse en el a Viewer. Es una herramienta para tratar las imgenes Dicom y cambiar y eda itar informes estructu-rados, incluso para vericarlos y crear rmas digitales.
60
Jos Ma Onrubia e
3.3. DICOMSCOPE.
Figura 3.3: Viewer
3.3.4.
Print.
Se pueden enviar imgenes Dicom a imprimir desde el Browser o la a imagen que se est visualizando en el Viewer. Esto lleva la imagen al Print a en el que se vi-sualiza la imagen que se va a imprimir.
61
Jos Ma Onrubia e
Figura 3.4: Print
3.3.5.
Process Log.
Se puede ver que procesos se producen para la transmisin de archivos o Di-com. Al iniciar el DicomScope se ve que hay dos procesos que estn a realizndose. a
Uno es para que el DicomScope sirva como receptor de instancias Dicom con transmisin insegura, sin utilizar TLS. Este proceso utiliza la o orden C-STORESCP, con esto recibe y guarda en la base de datos los archivos Dicom mandados a este equipo, utilizando el puerto 10004.
El otro proceso recibe las instancias Dicom utilizando TLS, siendo de esta forma segura la transmisin de datos. Tambin utiliza la orden o e C-STORESCP y el puerto elegido es el 10007. 62 GVA-ELAI-UPM r PFC0074-03
Jos Ma Onrubia e
3.3. DICOMSCOPE.
Figura 3.5: Process log
63
Jos Ma Onrubia e
64
Cap tulo 4
JDT (Java DICOM Toolkit)

4.1. Introduccin. o
Java DICOM Toolkit es la ayuda para un programador en JAVA para construir una aplicacin que siga lo marcado por el estndar DICOM 3.0. o a Combina las ventajas y la fuerza de DICOM y JAVA en una .APImuy fcil de usar. Proporciona numerosas clases y mtodos que simplican la a e programacin de DICOM. o JDT es el primer equipo de desarrollo de software DICOM que est implea mentado totalmente en JAVA. Con esto, los desarrolladores DICOM pueden beneciarse de las numerosas ventajas del lenguaje de programacin JAVA o applets, aplicaciones independientes JAVA y en y desplegarlo en DICOM . software de servidor. JDT viene con una .APIbien documentada que ha sido diseada para hacer que la estructura compleja del estndar DICOM n a sea ms accesible para los desarrolladores. JDT funciona sobre JDK 1.1.X a y la JAVA 2. Caractersticas: Soporte de la parte 10 del estndar DICOM. a Soporte de red DICOM. Soporte para todas las transfer syntaxno comprimidas y conversiones. Soporte para formatos RLE y JPEG. Leer y escribir datos DICOM desde InputStreams/OutputSreams. Esquema de tipos JAVA a tipo tipos DICOM. Tolerancias en implementaciones DICOM. 65
CAP ITULO 4. JDT (JAVA DICOM TOOLKIT)
Jos Ma Onrubia e
4.2.
4.2.1.
Guia de usuario de JDT.

Terminolog a.
En esta seccin se usa palabras como conjunto de datos (dataset) y atribo uto. Conjunto de datos se usa para identicar una coleccin de atributos o DICOM. Un atributo se identica por su par (nmero de grupo, nmero de u u elemento), tiene un cierto tipo DICOM (value representation - VR)
4.2.2.
Conjunto de datos (Datasets).
Introduccin. o En JDT, todos los conjuntos de datos estn representados por a com.archimed.dicom.DicomObject. Esta clase es una subclase de com.archimed.dicom.GroupList. Bsicamente es donde residen los atributos a DICOM (com.archimed.dicom.TagValue).
Manipulacin de atributos. o Un conjunto de datos DICOM es representado por un DicomObject. Los diferentes atributos de estos conjuntos de datos estn internamente almaa cenados en el DicomObject como objetos com.archimed.dicom.Tagvalue. El objeto TagValue contiene un par (grupo,elemento) y los valores del atributo estn almacenados en un Vector. El tamao del Vector corresponde a la a n multiplicidad del atributo. El tipo JAVA que representa el valor de un atributo depende del tipo DICOM (Value Representation - VR) denido para ese atributo espec co. La siguiente tabla muestra la equivalencia entre los tipos DICOM y sus correspondientes tipos JAVA. Las conversiones soportadas a y desde tipos que no son los tipos por defecto estn en cursiva. a Manipulacin de atributos simples. Hay un nmero de mtodos o u e set/get en DicomObject con los que se puede meter, sacar o modicar los atributos guardados en un DicomObject. La forma de hacer esto es con la clase com.archimed.dicom.DDict. La clase DDict tiene una constante denida para cada atributo denido en el estndar DICOM. Por ejemplo: a DDict.dPatientName DDict.dAccessionNumber Esas constantes pueden ser usadas en los mtodos set/get del DicomObject: e Person p = (Person)dcm.get(DDict.dPatientName); 66 GVA-ELAI-UPM r PFC0074-03
Jos Ma Onrubia e tipo Java Short Integer Long Float Double byte[] int[] String Person DDate DDateRange
4.2. GUIA DE USUARIO DE JDT. tipo DICOM SS US, USSS, IS, AT, SS, SL, UL SL, UL FL, DS FD OB, OW, OWOB AT (int[2]) AS, AE, CS, LO, LT, SH, ST, UI, TM, PN, DA, DS, IS, SS, US, SL, UL, FL, FD, OB, OW, OWOB PN DA DA Cuadro 4.1: tipo Java / tipo DICOM
Integer acnumber = (Integer)dcm.get(DDict.dAccessionNumber); dcm.set(DDict.dPatientName, new Person(Jose)); dcm.set(DDict.dAccessionNumber, new Integer(12345)); El mtodo set impl e citamente convierte el valor del argumento dado al tipo DICOM correcto. Tambin se puede acceder a los atributos de un DicomObject a travs del e e par (grupo.elemento). Person p = (Person)dcm.get ge(0x0010, 0x0010); Integer acnumber = (Integer)dcm.get ge(0x0008,0x0050,DDict.dAccessionNumber); dcm.set ge(0x0010, 0x0010, new Person(Jose)); dcm.set ge(0x0008, 0x0050, new Integer(12345)); Hay tambin dos mtodos get que convierten directamente a String o int: e e String s = dcm.getS(DDict.dPatientName); int i = dcm.getI(DDict.dAccessionNumber); GVA-ELAI-UPM r PFC0074-03 67
CAP ITULO 4. JDT (JAVA DICOM TOOLKIT) tipo DICOM AE AT AT CS DA DS FL FD IS LO LT OB OW OBOW PN SH SL SS ST TM UI UL US USSS tipo Java String String Integer (0xggggeeee) String DDate or DDateRange Float Float Double Integer String String byte[] byte[] byte[] Person String Long Short String String String Long Integer Integer
Jos Ma Onrubia e
Cuadro 4.2: tipo DICOM / tipo Java
Para manipular atributos con una multiplicidad mayor de uno, se usan los mtodos get/set con un argumento adicional. La multiplicidad de e un atributo se obtiene con getSize(). Por ejemplo, suponiendo que un DicomObject dcm contiene un atributo ImageType con multiplicidad 2 y valores DERIVED/SECONJDARY, entonces se puede coger esos valores de la siguiente forma: int multiplicity = dcm.getSize(DDict.dImageType); //devolver el valor 2 a String str1 = (String)dcm.get(DDict.dImageType,0); valor DERIVED String str2 = (String)dcm.get(DDict.dImageType,1); 68 //devolver el a
//devolver el a
Jos Ma Onrubia e valor SECONDARY
4.2. GUIA DE USUARIO DE JDT.
Insertando el valor de un atributo ocurre lo mismo: dcm.set(DDict.dImageType,0,DERIVED); dcm.set(DDict.dImageType,1,SECONDARY); Secuencias. Las secuencias se tratan de una forma parecida que los valores de multiplicidad mayor de uno. Cuando un atributo en un DicomObject representa una secuencia (tipo SQ DICOM), entonces los art culos de la secuencia pueden ser insertados y cogidos con los mismos mtodos e get/set del DicomObject que ahora aceptan y devuelven los DicomObejcts completos. Por ejemplo, suponiendo que el DicomObject dcm contiene un atributo DirectoryRecordSequence con un cierto nmero de art u culos: int numberotems = dcm.getSize(DDict.dDirectoryRecordSequence); DicomObject item0 = (DicomObject)dcm.get(DDict.dDirectoryRecordSequence,0); DicomObject item1 = (DicomObject)dcm.get(DDict.dDirectoryRecordSequence,1); Para aadir un valor a una secuencia (Sequence), simplemente usando el n mtodo set que tiene el DicomObject que representa el art e culo y el ndice del art culo. Para un rpido acceso, hay una utilidad de la clase a com.archimed.dicom.tools.Sequences que contiene varios mtodos para e acceder a las secuencias. Tambin cuida de todas las diferentes excepciones e encontradas. El nombre elegido para los mtodos son muy similares que los e encontrados en el DicomObject. Comentarios:
las longitudes de los grupos no se almacenan en un DicomObject, se calculan cuando se necesitan, as que no hay acceso a ellos. cuando usamos set para insertar valores de atributos, los valores se alamacenan por referencia y no se copian. cuando usamos get para sacar valores de atributos, se devuelve una referencia al valor. GVA-ELAI-UPM r PFC0074-03 69
Jos Ma Onrubia e
Manipular grupos de atributos. Para usuarios que quieran manipular los grupos enteros del conjunto de datos, hay el acceso al grupo proporcionado por com.archimed.dicom.GroupList, el cual es la superclase de com.archimed.DicomObject. Un grupo es un conjunto de atributos que tienen el mismo nmero de grupo en su par (grupo,elemento). u DicomObject copyGroup(int groupnr) copia el grupo con el nmero de u grupo y lo devuelve como un DicomObject nuevo. Notar que slo se hace o una copia no profunda, slo se copian referencias a los atributos. o Void addGroups(DicomObject o) aade todos los grupos encontrados al n conjunto de datos. Slo se aaden los grupos que no estuvisen presentes en o n este conjunto de datos. Otra vez, se hace slo una copia superua. o DicomObject removeGroup(int groupnr) borra el grupo entero con el nmero de grupo del conjunto de datos y lo devuelve como un DicomObject. u
I/O de conjuntos de datos DICOM. Nosotros tenemos varias formas para leer o escribir datasets DICOM desde y por InputStreams/OutputStreams. En ambos casos hay un mtodo e bsico y varios mtodos que lo hacen posible para especicar todo tipo de a e parmetros. a Leer conjunto de datos(dataset). void read(java.io.InputStream in) Este mtodo lee todos los atributos DICOM desde un inputStream a un e DicomObject. El inputStream puede contener tanto un archivo DICOM como un conjunto de datos DICOM. Cuando el inputStream contiene un archivo de la parte 10 DICOM, se lee y se almacena la Meta File Information en un DicomObject separado que se puede coger mediante getFileMetaInformation(). La transfer syntax se asume que es Implicit VR Little Endian cuando el inputStream contiene un conjunto de datos DICOM. Cuando el inputStream contiene un archivo de la parte 10 de DICOM, el transfer syntax se detecta desde la File Meta Information. void read(java.io.InputStream in, boolean process) Este mtodo hace lo mismo que el anterior pero adems permite especie a car si se procesa o no se procesa los datos de pixel. Salva el tiempo de proceso cuando no se necesita el pixel data. 70 GVA-ELAI-UPM r PFC0074-03
Jos Ma Onrubia e
void read(java.io.InputStream in, int ts, boolean process) El parmetro ts especica que transfer syntax se usa. Este parmetro a a puede venir dado , cuando se conoce por adelantado con qu transfer syntax e se codic el conjunto de datos. o Escribir conjunto de datos(dataset). void write(java.io.OutputStream out, boolean f ) Este es el ms bsico mtodo para exportar. Si la bandera f es true, el a a e conjunto de datos se codica como la parte 10 de DICOM. En este caso, la File Meta Information se usa si est presente, o se crea cuando se necesita. a Nota que la creacin de la File Meta Information puede lanzar una execcin o o cuando faltan atributos requeridos (SOP Class UID, SOP Instance UID). void write(java.io.OutputStream out, boolean f, int ts, boolean seqUndef ) Los parmetros adicionales ts y seqUndef puede ser usado para escribir tu a conjunto de datos casi en todos los posibles tipos DICOM. Los parmetros a ts y seqUndef pueden ser usados para insertar la Transfer Syntax. Toda posible combinacin de parmetros ts y seqUndef se permiten, pero no o a todas las combinaciones siguen los dictados del estndar de DICOM. Si a escribes un conjunto de datos con f true ts otra cosa que no sea Implicit VR Little Endian, es imposible para otras aplicaciones para decodicar ya que ellas no pueden detectar la sintaxis de transferencia usada. El parmetro seqUndef indica al escribir secuencias si se usa indenido (true) a o denida (false) la longitud. Visualizar conjunto de datos. DicomObject contiene dos mtodos para imprimir todos lor atributos e que contiene hacia un OutputStream de forma ordenada para que el ser humano sea capaz de interpretarla. void dumpVRs(java.io.OutputStream os) void dumpVRs(java.io.OutputStream os, boolean metainfo) Poner metainfo a truesi se quiere ver File Meta Information. Ejemplos.
2
71
Jos Ma Onrubia e
Estos trozos de cdigo demuestran el fcil uso de JDT. Con slo unas o a o l neas de cdigo, es posible construir soluciones poderosas DICOM. o El cdigo siguiente lee un archivo DICOM desde un archivo y muestra o los atributos (incluidos los contenidos en la meta information si existe) por la pantalla. DicomObject dcm = new DicomObject; dcm.read(new FileInputStream(foo.dcm)); dcm.dumpVRs(System.out, true); El siguiente ejemplo lee los datos de un archivo y lo escribe en otro archivo usando una transfer syntax y una secuencia de codicacin espec o cas. DicomObject dcm = new DicomObject; dcm.read(new FileInputStream(in.dcm)); dcm.write(new FileOutputStream(.out.dcm), tax.ExplicitVRBigEndian, true); true, TransferSyn-
Mtodos utiles. e Enumerar los atributos de un conjunto de datos(dataset). Con el mtodo enumerateVRs es posible conseguir una enumeracin e o (clase de java) de todos los atributos sontenidos en un DicomObject. Enumeration e = dcm.enumerateVRs(false); enumerateVRs() devuelve una enumeracin de todos los atributos de o dcm como objetos TagValue. TagValue tiene mtodos para coger el valor y e el par (grupo,elemento) de un atributo. File Meta Information. DicomObject fmi = dcm.getFileMetaInformation(); Devuelve la File Meta Information del DicomObject dcm si existe. Se puede usar ahora fmi para aadir o alterar atributos espec n cos de esta informacin como se quiera. o
72
Jos Ma Onrubia e Informacin general. o
Unosm mtodos de com.archimed.dicom.GroupList proporcionan infore macin general sobre un conjunto de datos: o int numberOfElements() : devuelve el nmero total de atributos. u int numberOfGroups() : devuelve el nmero total de grupos. u boolean isEmpty() : devuelve si el GroupList contiene algn atributo. u boolean containsGroup(int g) : devuleve si el GroupList contiene el grupo especicado.
4.2.3.
Depsitos. o
Hay unas clases en el paquete com.archimed.dicom que hacen ms fcil a a para los programadores para usar los conjuntos de datos y las UIDs registradas (se ha tratado de cubrir todo lo especicado en el estndar 3.6). a
Clase DDict: depsito de atributos. o La clase com.archimed.dicom.DDict es un almacen de los VRs (value representations) y los elementos de datos. Contiene un nmero de constantes u que representan los diferentes VRs y un gran conjunto de constantes para los elementos de datos: DDict.tPN // representa el tipo DICOM PERSON. DDict.tUS // representa el tipo DICOM UNSIGNED SHORT. DDict.dAccesionNumber // representa el atributo AccessionNumber. DDict.dPatientName // representa el atributo PatientName.
Los mtodos de DDict. e La clase DDict tiene mtodos para obtener el par (grupo,elemento) de un e atributo, un tipo de atributo, una descripcin del atributo y para consultar o una constante DDict del atributo basada en su par (grupo,elemento).
73
Jos Ma Onrubia e
static int getGroup(int dct) Devuelve el nmero de grupo para una u constante DDict que representa un atributo. static int getElement(int dct) Devuelve el nmero de elemento para una u constante DDict que representa un atributo. static int getTypeCode(int dct) Devuelve el tipo para una constante DDict que representa un atributo. Los elementos de datos que no estn en a la lista de arriba tendrn un DDict.tUNKNOWN. a static java.lang.String getDescription(int dct) Da una descripcin elaboo rada para una constante DDict que representa un atributo. static int lookupDDict(int g, int e) Devuelve la constante DDict que representa el atributo con nmero de grupo g y nmero de elemento e. Si u u no se encuentran constantes, el mtodo devolver DDict.dUNDEFINED. e a
Clase UID: depsitos UID. o La clase com.archimed.dicom.UID contiene un depsito de los UIDs o DICOM registrados (Parte 6 DICOM).Las constantes que representan los UIDs y que tienen que ser usadas a travs de JDT se denen en subclases e de UID: com.archimed.dicom.TransferSyntax : constantes que representan las transfer syntax. com.archimed.dicom.SOPClass: constantes que representan las clases SOP. com.archimed.dicom.MetaSOPClass: constantes que representan las clases Meta SOP. com.archimed.dicom.SOPInstance: constantes que representan las bien conocidas instancias SOP. El objeto com.archimed.dicom.UIDEntry representa un unico identi cador y se obtiene con la clase UID de dos formas. Usando una constante de una de las subclases UID: UIDEntry entry = UID.getUIDEntry(TransferSyntax.JPEGBaseline); o usando una cadena UID: 74 GVA-ELAI-UPM r PFC0074-03
Jos Ma Onrubia e
UIDEntry entry = UID.getUIDEntry(1.2.840.10008.1.2.4.50); Cada uno de esos mtodos de consulta devulve un objeto UIDEntry el e cual es contiene varias propiedades de el identicador unico espec co. Esos atributos pueden ser obtenidos usando los mtodos get. e
4.2.4.
Imgenes en JDT. a
Esta parte habla de las capacidades de imagen de JDT. Todas las clases relacionadas con las imgenes pueden ser encontradas en el paquete a com.archimed.dicom.image.
La clase DicomImage. La clase base para las imgenes a es com.archimed.dicom.image.DicomImage. A parte de los mtodos set/get e bsicos para manipular los datos, inherentes a la DicomObject, contiene a otras formas de coger e insertar los atributos requeridos (tipo 1 y tipo 2) que son comunes a todos los DICOM Image Modality IODs (ver parte 3 de DICOM). Cuando se escribe una DicomImage a un outputstream, no hay un reconocimiento de si todos los atributos requeridos estn presentes. a Insertar datos que no son de imagen. DicomImage contiene un nmero de mtodos para insertar los atributos u e requeridos que no estn relacionados con los datos de imgen.Una corta a a descripcin son estos mtodos: o e void patientData(String patientName, String patientID, String birthDate, String sex) inserta los datos del paciente. void generalStudyData(String instanceUID, String date, String time, String physName, String studyID, String orderNumber) inserta los atributos del estudio general. generalSeriesData(String modality, String instanceUID, String seriesNumber) aade los datos generales de serie. n generalEquipmentData(String manufacturer) generalImageData(String imageNumber)
75
Jos Ma Onrubia e
sopCommonData(String sopClassUID, String sopInstanceUID) inserta los datos comunes SOP. SOP Class UID es t picamente uno de las diferentes image storage SOP Classes, que pueden ser encontrados en com.archimed.dicom.SOPClass. Insertar datos de imagen con los mtodos de DicomImage. e Hay tambin mtodos en com.archimed.dicom.image.DicomImage que e e pueden ser usados para insertar los datos de los p xeles de la imagen. La clase contiene mtodos para imgenes en escala de grises, en paleta e a de colores y en RGB. Una denicin de todos los parmetros pueden ser o a encontrados en la API. DicomImage dcmi = new DicomImage(); byte[] pixels = new byte[640*480]; // rellena este array con p xeles. byte[] red = new byte[256]; // rellena este array con un LUT rojo. byte[] green = new byte[256]; // rellena este array con un LUT verde. byte[] blue = new byte[256]; // rellena este array con un LUT azul. dcmi.imagePixelData(480, 640, pixels, red, green, blue); Esto da una DicomImage con una interpretacin fotomtrica PALETTE o e COLOR, tamao 640x480 y con una profundidad de pixel de 8. n Insertando los datos de imagen con ImageProducer. Hay otra forma de insertar los datos de la imagen. Dado una ImageProducer ip, construyebdo un objeto ImageIO y usando el mtodo e setImageProducer() para copiar los datos de imagen desde la ImageProducer a la DicomImage: DicomImage dcmi = new DicomImage(); ImageIO imgio = new ImageIO(dcmi); imgio.setImageProducer(ip); Cuando se llama al mtodo setImageProducer(), todo los datos se copian e dentro de la DicomImage.
76
Jos Ma Onrubia e
Esto es en teor despus de muchas prcticas no ha sido posible a; e a demostrar la validez de ste mtodo, por lo que se recomiendo usar los e e otros. (Tambin se puede tratar de haver funcionar ste). e e Obtenier una ImageProducer desde una DicomImage es tambin posible. e Todo marco simple de una imagen DICOM se puede coger como una ImageProducer usando uno de los mtodos siguientes: e java.awt.image.ImageProducer getImageProducer() java.awt.image.ImageProducer getImageProducer(int i) java.util.Vector getImageProducers() Para imgenes de escalas de grises con profundidad de pixa el mayor que 8 bits, hay un color model (clase de java) especial com.archimed.dicom.image.GrayColorModel. Este color model se usa en combinacin con un array int de p o xeles, para producir imgenes de 256 a grises sin prdida de datos. Con este GrayColorModel, tambin es posible e e meter el Window/Level usado en la produccin de la imagen. o
Insertar imagen con DicomObject. Insertar y sacar los datos de imagen puede ser hecho directamente con los set/get de la clase DicomObject. Los atributos de imagen como bits por p xel, las y coumnas se meten o sacan como cualquier otro atributo en un DicomObject mediante las constantes de DDict. Los datos de p de una xel imagen se almacenan en un DicomObject como un array o un nmero de u arrays dependiendo del formato de compresin: o no-comprimido transfer syntax, una imagen: un array de bytes que mantiene el formato original de los datos de p xel denido en el estndar DICOM, ejemplos: a imagen MONOCHROME2, 8 bits asignados, 8 bits alamcenados: 1 elemento del array de bytes por pixel. imagen MONOCHROME2, 16 bits asignados, 12 bits alamcenados: 2 elementos consecutivos del array de bytes por pixel. imagen MONOCHROME2, 12 bits asignados, 12 bits alamcenados: 1 elemento y medio del array de bytes por pixel. imagen RGB, conguracin plana color por pixel: 3 bytes conseco utivos representando 1 pixel. GVA-ELAI-UPM r PFC0074-03 77
Jos Ma Onrubia e
imagen RGB, conguracin plana color por plano: el array o de bytes est dividivo en 3 partes de igual longitud cada una a representando un color de plano (Red-Green-Blue). Los array de bytes se cogen e insertan con los mtodos e get(DDict.dPixelData) y set(DDict.dPixelData,byte array) respectivamente. no-comprimido transfer syntax, varias imgenes: un array de bytes que a contienen marcos consecutivos. comprimido transfer syntax, una imagen: un array de bytes en el formato original de compresion (ver compression). Compression. Los datos de p xel de una imagen DICOM se almacena en el atributo DDict.dPixelData. Cuando una imagen DICO comprimida se lee desde un inputstream, los pixeldata no se decodican pero se almacenan internamente en arrays de bytes en su formato de compresin por razones de rendimineto. o El tipo de codicacin puede ser sacado de la sintaxis de transferencia en o el File Meta Information. DcmObject dcm = new DicomObject(); dcm.read(new FileInputStream(://encodedimage.dcm)); c DicomObject fmi = dcm.getFileMetaInformation(); UIDEntry tsentry = UID.getUIDEntry(fmi.get(DDict.dTransferSyntaxUID)); System.out.println(encoding: + tsentry.getName()); Una utilidad de la clase com.archimed.dicom.codec.Compression es que proporciona un nmero de decodicadores: u JPEG baseline JPEG lossless RLE Lossless Todos los decodicadores estn limitados a 8 bits por p a xel. El decodicador JPEG puede manejar 1 o 3 muestras por p xel. RLE es slo capaz de o 78 GVA-ELAI-UPM r PFC0074-03
Jos Ma Onrubia e
descomprimir 1 muestra por p xel. El camino ms fcil para descomprimir a a imagen entera DICOM es construir un objeto Compression desde un DicomObject y despus llamar al mtodo decompress. Este descodica los e e datos del array de p xeles del DicomObject y los reemplaza por los datos descomprimidos. En el caso de una imagen DICOM multimarco, se puede decodicar el array de bytes correspondioente a un marco individual. Primero obteniendo un array de bytes de un marco con get(DDict.dPixelData, index of frame) y luego usando el mtodo esttico decompressframe() del objeto e a Compression para obtener un array de bytes decodicado desde el array de bytes comprimido. static byte[] decompressframe(int encoding, byte[] frame, int width, int heigth); Los argumentos de codicacin, ancho y alto que tienen que ser sumino istrados para usar decompressframe() se encuentran en la imagen DICOM original.
79
Jos Ma Onrubia e
4.3.
4.3.1.
Estructura de JDT(Java DICOM Toolkit).

Arbol de clases.
class java.lang.Object class com.archimed.dicom.network.Association class java.awt.image.ColorModel (implements java.awt.Transparency) class com.archimed.dicom.image.GrayColorModel class com.archimed.dicom.codec.Compression class com.archimed.dicom.DDate class com.archimed.dicom.DDateRange class com.archimed.dicom.DDict class com.archimed.dicom.DDictEntry class com.archimed.dicom.Debug class com.archimed.dicom.network.DimseUtil class com.archimed.dicom.network.ExtendedNegotiation class com.archimed.dicom.GroupList class com.archimed.dicom.DicomObject class com.archimed.dicom.image.DicomImage class com.archimed.dicom.image.SCImage class com.archimed.dicom.image.ImageIO class com.archimed.dicom.Jdt class com.archimed.dicom.Osets class com.archimed.dicom.Person class com.archimed.dicom.network.Request class com.archimed.dicom.network.Response class com.archimed.dicom.network.Abort class com.archimed.dicom.network.Acknowledge class com.archimed.dicom.network.Reject class com.archimed.dicom.network.ResponsePolicy class com.archimed.dicom.tools.Sequences class com.archimed.dicom.TagValue class java.lang.Throwable (implements java.io.Serializable) class java.lang.Exception class com.archimed.dicom.DicomException class com.archimed.dicom.IllegalValueException class com.archimed.dicom.UnknownUIDException class com.archimed.dicom.UID class com.archimed.dicom.MetaSOPClass class com.archimed.dicom.SOPClass class com.archimed.dicom.SOPInstance class com.archimed.dicom.TransferSyntax class com.archimed.dicom.UIDEntry class com.archimed.dicom.image.WL 80 GVA-ELAI-UPM r PFC0074-03
Jos Ma Onrubia4.3. ESTRUCTURA DE JDT(JAVA DICOM TOOLKIT). e
4.3.2.
Paquetes.
Com.archimed.dicom.network. Abort : Representa el aborto de una asociacin. Los dos parmetros o a son, la fuente y la razn del aborto. o Acknowledge : Estos objetos tienen los parmetros de la asociacin Aca o knowledge, contiene todos los contextos de presentacin del Acknowlo edge y son numerados desde 0 hasta el no de contextos de presentacin o menos uno. Puede actuar como receptor de asociacin o como iniciador o de la asociacin. o Association : Contiene mtodos para construir y destruir una asoe ciacin entre dos entidades de aplicacin DICOM y mandar/ recibir o o comandos y datos (data sets) una vez que la asociacin est establecio a da. DimseUtil : Las funciones DICOM que pueden hacerse. ExtendedNegotiation: Representa los datos de negociacin para un sino taxis abstracto. Reject: Representa el rechazo de una asociacin. Sus parmetros son o a fuenta, resultado y razn. o Request : Representa todos los parmetros relevantes de una asociacin a o Request. Contiene todos los contextos de presentacin y son numerao dos desde 0 hasta el no de contextos de presentacin menos uno. Puede o actuar como receptor de asociacin o como iniciador de la asociacin. o o Response: Representa una respuesta de un par de entidades DICOM. Las clases implementadas son: Reject, Acknowledge y Abort. ResponsePolicy: contiene dos tipos de mtodos. Mtodos para creacin e e o de objetos Response, basados en una peticn dada y una pol o tica de aceptacin de la asociacin. Mtodos para el anlisis de respuestas o o e a Acknowledge, en el contexto de una peticin dada. o Com.archimed.dicom.codec Compression : Es una clase que proporciona mtodos para la descome presin de datos de Pixel. DICOM soporta muchos tipos de tcnicas o e de compresin. o GVA-ELAI-UPM r PFC0074-03 81
CAP ITULO 4. JDT (JAVA DICOM TOOLKIT) Com.archimed.dicom.image
Jos Ma Onrubia e
DicomImage: Esta clase provee de mtodos para construir una imagen e Dicom. GrayColorModel : Esta clase representa un ColorModel para el empleo con imgenes de Escala de gris. a ImageIO: Es una clase que proporciona mtodos de convertir datos e de imagen almacenados a un ImageProducer (Productor de imagen) y viceversa. SCImage: Esta clase proporciona mtodos para construir una imagen e SC. WL: Es un contenedor bsico para un par Ventana/Nivel. a Com.archimed.dicom.tools Sequences: Estos objetos proveen los .atajospara coger/poner valores dentro de secuencias. La conversin de valores est hecha usando el o a esquema de conversin DicomType-JavaType dada en la clase Dicoo mObject. Com.archimed.dicom DDate: Esta clase representa la fecha de un objeto, conteniendo el d a, mes y ao. Se ha desarollado en correspondencia al tipo Dicom DA Es n util, cuando se quiere buscar en una gama de fechas. DDateRange: Esta clase representa la gama de fechas. DDict: Esta clase provee de un diccionario (Diccionario de datos Dicom) para los VRs y todos los elementos de datos.Cada par (grupo,elemento) es accesible por una variable static int. Por ejemplo, (0010,0010) es representado por Ddic.dPatientName. DDictEntry: Un objeto para una etiqueta que puede ser almacenado en el diccionario de datos. Debug: Proporciona una variable static int por si hay que imprimir informacin de reparacin de los errores a System.err. o o DicomObject: Esta es la clase base de todos los datasets. Los mtodos e de acceso proporcionados aqu son el modo de obtener/poner elementos de dato (data elements) dentro de un objeto Dicom (DicomObject). GroupList: Provee de mtodos para el acceso de datos por grupo. e 82 GVA-ELAI-UPM r PFC0074-03
Jos Ma Onrubia4.3. ESTRUCTURA DE JDT(JAVA DICOM TOOLKIT). e Jdt: Para obtener informacin sobre este Jdt o MetaSOPClass: Extensin de la clase UID. o Osets : Esta clase proporciona utilidades para calcular compensaciones en un DicomObject que va a ser escrito. Person: Esta clase representa el PN (Person Name) en Dicom. SOPClass: Extensin de la clase UID. o SOPInstance: Extensin de la clase UID. o TagValue: Representa un par (grupo, elemento) y su valor. TransferSintax : Extensin de la clase UID. o UID: Esta clase contiene un depsito de todos los UIDs Dicom cero ticados. Cada UID est en funcin del Transfer Syntax, SOPClass, a o Meta- SOPClass y SOPInstance. UIDEntry: Representa la entrada de un UID en el depsito, almao cenndose. a DicomExcepcion: Indica que la aplicacin ha violado la estructura y o codicacin del Dicom Data. o IllegalValueExcepcion: Indica que un valor ilegal es le durante una do asociacin o cuando un valor ilegal es argumento de un mtodo. o e UnknownUIDExcepcion: Indica que el UID incluido no est denido a en la clase UID.
4.3.3.
Conclusiones.
Una vez trabajado y experimentado con los dos toolkit de DICOM, dcmtk y JDT, se llegan a las siguientes conclusiones: El toolkit dcmtk351 cuenta con la gran ventaja de ser un producto gratuito, pero si no se es un gran experto tanto en materia DICOM como en programacin en C++, el estudio y la creacin de una aplicacin, nuestro o o o objetivo, se antoja demasiado complicado debido a la poca documentacin o proporcionada con dicha herramienta y a la gran dicultad y amplitud del cdigo. o Por el contrario, JDT es un producto no gratuito, pero cuenta con las grandes ventajas que el toolkit dcmtk351 no tiene. Lo primero a sealar n es que el lenguaje de programacin es JAVA, con las ventajas que conlleva o GVA-ELAI-UPM r PFC0074-03 83
Jos Ma Onrubia e
con respecto a C++. Por otro lado, contiene una documentacin amplia o y muy bien estructurada, lo que facilita enormemente el trabajo y su comprensin. Contiene un rbol de clases, informacin de los diferentes o a o packages, ejemplos, las diferentes clases se estudian con detalle, es decir, de que clases derivan, que mtodos usan, que interfaces implementan, etc, lo e que todo junto hace mucho ms fcil la implememtacin. a a o Por todo lo visto anteriormente, a partir de este punto se empieza a trabajar con JDT, lo que nos conduce al estudio profundo de JAVA, por lo que la siguiente seccin trata de esto mismo: El lenguaje de programacin JAVA. o o
84
Cap tulo 5
Estudio de JAVA.
5.1. Introduccin o
Java es la plataforma ideal para las soluciones de computacin en red. o Ejecutable sobre las ms diversas plataformas, desde servidores a telfonos a e mviles y tarjetas inteligentes, Java ofrece una infraestructura unica para o crear soluciones en red para su negocio. Java est soportado por una gran comunidad de desarrolladores que a activamente trabajan en productos y servicios alrededor de Java, que al mismo tiempo contribuyen a la evolucin de la plataforma mediante el o Java Community Process, una organizacin estndar, abierta y basada en o a comunidades. Java est en telfonos mviles, ordenadores portatiles, PDAs, en la a e o web, e incluso en los sistemas de las carreras de Formula 1. De hecho, encontrar Java en cualquier lugar. a Benecios de JAVA:
Java es simple: cuando usa un telfono Java, juega o accede a su red e corporativa, Java ofrece la base de la verdadera movilidad. El excelente compromiso entre movilidad y seguridad de la plataforma Java hace posible el desarrollo y despliege de soluciones mviles e inalambricas. o Java es el entorno ideal para Web services: Java y XML son los dos lenguajes ms ampliamente aceptados en el mundo, ofreciendo una a plataforma real para cualquiera, en cualquier lugar, en cualquier momento, desde cualquier dispositivo. Java est en todos los niveles de su negocio: Java ofrece un simple y a 85
CAP ITULO 5. ESTUDIO DE JAVA.
Jos Ma Onrubia e
unicado modelo de programacin que puede conectar todos los eleo mentos de una infraestructura de negocio. Java surgi en 1991 cuando un grupo de ingenieros de Sun Microsyso tems trataron de disear un nuevo lenguaje de programacin destinado n o a electrodomsticos. La reducida potencia de clculo y memoria de los e a electrodomsticos llev a desarrollar un lenguaje sencillo capaz de generar e o cdigo de tamao muy reducido. o n Debido a la existencia de distintos tipos de CPUs y a los continuos cambios, era importante conseguir una herramienta independiente del tipo de CPU utilizada. Desarrollan un cdigo neutroque no depende del tipo o de electrodomstico, el cual se ejecuta sobre una mquina hipottica e a e o virtualdenominada Java Virtual Machine (JVM). Es la JVM quien interpreta el cdigo neutro convirtindolo a cdigo particular de la CPU o e o utilizada. Esto permit lo que luego se ha convertido en el principal lema a del lenguaje: Write Once, Run Everywhere. Al programar en Java no se parte de cero. Cualquier aplicacin que o se desarrolle uelga(o se apoya, segn como se quiera ver) en un gran c u nmero de clases preexistentes. Algunas de ellas las ha podido hacer el u propio usuario, otras pueden ser comerciales, pero siempre hay un nmero u muy importante de clases que forman parte del propio lenguaje (el API o Application Programming Interface de Java). Java incorpora muchos aspectos que en cualquier otro lenguaje son extensiones propiedad de empresas de software o fabricantes de ordenadores (threads, ejecucin o remota, componentes, seguridad, acceso a bases de datos, etc). Por eso es un lenguaje ideal para aprender la informtica moderna, porque incorpora a todos estos conceptos de un modo estndar, mucho ms sencillo y claro a a que con las citadas extensiones de otros lenguajes. Esto es consecuencia de haber sido diseado ms recientemente y por un unico equipo. n a El principal objetivo del lenguaje Java es llegar a ser el nexo universalque conecte a los usuarios con la informacin, est sta situada en o e e el ordenador local, en un servidor de Web, en una base de datos o en cualquier otro lugar. La compa Sun describe el lenguaje Java como na simple, orientado a objetos, distribuido,interpretado, robusto, seguro, de arquitectura neutra, portable, de altas prestaciones, multitarea y dinmico. a Los programas desarrollados en Java presentan diversas ventajas frente a los desarrollados en otros lenguajes como C/C++. La ejecucin de o programas en Java tiene muchas posibilidades: ejecucin como aplicacin o o independiente (Stand-alone Application), ejecucin como applet, ejecucin o o como servlet, etc.. Un applet es una aplicacin especial que se ejecuta dentro o 86 GVA-ELAI-UPM r PFC0074-03
Jos Ma Onrubia e
5.2. ESTUDIO A TRAVES DE UN EJEMPLO.
de un navegador o browser (por ejemplo Netscape Navigator o Internet Explorer) al cargar una pgina HTML desde un servidor Web. El applet se a descarga desde el servidor y no requiere instalacin en el ordenador donde o se encuentra el browser. Un servlet es una aplicacin sin interface grca o a que se ejecuta en un servidor de Internet. La ejecucin como aplicacin o o independiente es anloga a los programas desarrollados con otros lenguajes. a Adems de incorporar la ejecucin como Applet, Java permite fcilmente a o a el desarrollo tanto de arquitecturas clienteservidor como de aplicaciones distribuidas, consistentes en crear aplicaciones capaces de conectarse a otros ordenadores y ejecutar tareas en varios ordenadores simultneamente, a repartiendo por lo tanto el trabajo. Aunque tambin otros lenguajes de e programacin permiten crear aplicaciones de este tipo, Java incorpora en o su propio API estas funcionalidades.
5.2.
Estudio a travs de un ejemplo. e
Este ejemplo contiene algunas de las caracter sticas ms importantes de a Java: clases, herencia, interfaces, grcos, polimorsmo, etc. a
5.2.1.
Clase Ejemplo1
En realidad, este programa principal lo unico que hace es utilizar la clase Geometr y sus clases derivadas. Es pues un programa puramente a usuario, a pesar de lo cual hay que denirlo dentro de una clase, como todos los programas en Java. 1. // chero Ejemplo1.java 2. import java.util.Vector; 3. import java.awt.*; 4. class Ejemplo1 { 5. public static void main(String arg[]) throws InterruptedException 6. { 7. System.out.println(Empieza main()...); 8. Circulo c = new Circulo(2.0, 2.0, 4.0); 9. System.out.println(Dimetro/2 = + c.r ); a 10. System.out.println(Punto medio = (+ c.x + ,+ c.y + ) GVA-ELAI-UPM r PFC0074-03 87
Jos Ma Onrubia e
unidades.); 11. Circulo c1 = new Circulo(1.0, 1.0, 2.0); 12. Circulo c2 = new Circulo(0.0, 0.0, 3.0); 13. c = c1.elMayor(c2); 14. System.out.println(El mayor radio es + c.r + .); 15. c = new Circulo(); // c.r = 0.0; 16. c = Circulo.elMayor(c1, c2); 17. System.out.println(El mayor radio es + c.r + .); 18. VentanaCerrable ventana = 19. new VentanaCerrable(Ventana abierta al mundo...); 20. Vector v = new Vector(); 21. CirculoGraco cg1 = new CirculoGraco(200, 200, 100, Color.red); 22. CirculoGraco cg2 = new CirculoGraco(300, 200, 100, Color.blue); 23. RectanguloGraco rg = new 24. RectanguloGraco(50, 50, 450, 350, Color.green); 25. v.addElement(cg1); 26. v.addElement(cg2); 27. v.addElement(rg); 28. PanelDibujo mipanel = new PanelDibujo(v); 29. ventana.add(mipanel); 30. ventana.setSize(500, 400); 31. ventana.setVisible(true); 32. System.out.println(Termina main()...); 33. } // n de main() 34. } // n de class Ejemplo1 Las sentencias 2 y 3 importanlases de los packages de Java, esto c es, hacen posible acceder a dichas clases utilizando nombres cortos. Por ejemplo, se puede acceder a la clase Vector simplemente con el nombre Vector en lugar de con el nombre completo java.util.Vector, por haber introducido la sentencia import de la l nea 2. Un package es una agrupacin de clases que tienen una nalidad relacionao da. Existe una jerarqu de packages que se reeja en nombres compuestos, a separados por un punto (.). Es habitual nombrar los packages con letras minsculas (como java.util o java.awt), mientras que los nombres de las u clases suelen empezar siempre por una letra mayscula (como Vector). u El asterisco (*) de la sentencia 3 indica que se importan todas las clases del package. Hay un package, llamado java.lang, que se importa siempre automticamente. Las clases de java.lang se pueden utilizar directamente, a sin importar el package. En Java todo son clases: no se puede denir una variable o una funcin o
88
Jos Ma Onrubia e
que no pertenezca a una clase. En este caso, la clase Ejemplo1 tiene como unica nalidad acoger al mtodo main(), que es el programa principal del e ejemplo. Las clases que utiliza main() son mucho ms importantes que la a propia clase Ejemplo1. Las l neas 5-33 contienen la denicin del programa principal de la o aplicacin, que en Java siempre se llama main(). La ejecucin siempre o o comienza por el programa o mtodo main(). La sentencia 8 (Circulo c = e new Circulo(2.0, 2.0, 4.0);) es muy propia de Java. En ella se crea un objeto de la clase Circulo, que se dene en el apartado 1.3.4. Esta sentencia es equivalente a las dos sentencias siguientes: Circulo c; c = new Circulo(2.0, 2.0, 4.0); que quizs son ms fciles de explicar. a a a En primer lugar se crea una referencia llamada c a un objeto de la clase Circulo. Crear una referencia es como crear un nombrevlido para a referirse a un objeto de la clase Circulo. A continuacin, con el operador o new se crea el objeto propiamente dicho. Puede verse que el nombre de la clase va seguido por tres argumentos entre parntesis. Estos argumentos se e le pasan al constructor de la clase como datos concretos para crear el objeto (en este caso los argumentos son las dos coordenadas del centro y el radio). Interesa ahora insistir un poco ms en la diferencia entre clase y objeto. a La clase Circulo es lo genrico: es el patrn o modelo para crear c e o rculos concretos. El objeto c es un c rculo concreto, con su centro y su radio. De la clase Circulo se pueden crear tantos objetos como se desee; la clase dice que cada objeto necesita tres datos (las dos coordenadas del centro y el radio) que son las variables miembro de la clase. Cada objeto tiene sus propias copias de las variables miembro, con sus propios valores, distintos de los dems objetos de la clase. La sentencia 9 (System.out.println(Radio = + a c.r + unidades.);) imprime por la salida estndar una cadena de texto a que contiene el valor del radio. Esta cadena de texto se compone de tres subcadenas, unidas mediante el operador de concatenacin (+). Obsrvese o e cmo se accede al radio del objeto c: el nombre del objeto seguido del o nombre de la variable miembro r, unidos por el operador punto (c.r). El valor numrico del radio se convierte automticamente en cadena de caracteres. e a La sentencia 10 es similar a la 9, imprimiendo las coordenadas del centro del c rculo. La sentencia 13 (c = c1.elMayor(c2);) utiliza el mtodo e
89
Jos Ma Onrubia e
elMayor() de la clase Circulo. Este mtodo compara los radios de dos e c rculos y devuelve como valor de retorno una referencia al c rculo que tenga mayor radio. Esa referencia se almacena en la referencia previamente creada c. Un punto importante es que todos los mtodos de Java (excepto e los mtodos de clase o static) se aplican a un objeto de la clase por medio del e operador punto (c1.elMayor()). El otro objeto (c2) se pasa como argumento entre parntesis. Obsrvese la forma .asimtricaen la que se pasan los e e e dos argumentos al mtodo elMayor(). De ordinario se llama argumento e impl cito a c1, mientras que c2 ser el argumento expl a cito del mtodo. e La sentencia 14 imprime el resultado de la comparacin anterior y la o sentencia 15 crea un nuevo objeto de la clase Circulo guardndolo en la a referencia c. En este caso no se pasan argumentos al constructor de la clase. Eso quiere decir que deber utilizar algunos valores por defectopara el a centro y el radio. Esta sentencia anula o borra el resultado de la primera comparacin de radios, de modo que se pueda comprobar el resultado de la o segunda comparacin. o La sentencia 16 (c = Circulo.elMayor(c1, c2);) vuelve a utilizar un mtodo e llamado elMayor() para comparar dos c rculos: Se trata del mismo mtodo e de la sentencia 13, utilizado de otra forma? No. Se llama de un mtodo e diferente, aunque tenga el mismo nombre. A las funciones o mtodos e que son diferentes aunque tienen el mismo nombre se les llama funciones sobrecargadas (overloaded). Las funciones sobrecargadas se diferencian por el numero y tipo de sus argumentos. El mtodo de la sentencia 13 e tiene un unico argumento, mientras que el de la sentencia 16 tiene dos (en todos los casos objetos de la clase C rculo). En realidad, el mtodo de la e sentencia 16 es un mtodo static (o mtodo de clase), esto es, un mtodo e e e que no necesita ningn objeto como argumento impl u cito. Los mtodos e static suelen ir precedidos por el nombre de la clase y el operador punto (Java tambin permite que vayan precedidos por el nombre de cualquier e objeto, pero es considerada una nomenclatura ms confusa.). La sentencia a 16 es absolutamente equivalente a la sentencia 13, pero el mtodo static de e la sentencia 16 es ms simtrico. Las sentencias 17 y 18 no requieren ya a e comentarios especiales. Las sentencias 18-31 tienen que ver con la parte grca del ejemplo. En las a l neas 18-19 (VentanaCerrable ventana = new VentanaCerrable(Ventana abierta al mundo...);) se crea una ventana para dibujar sobre ella. Una ventana es un objeto de la clase Frame, del package java.awt. La clase VentanaCerrable aade a la clase Frame la capacidad de responder a los n eventos que provocan el cierre de una ventana. La cadena que se le pasa como argumento es el t tulo que aparecer en la ventana. En la sentencia a
90
Jos Ma Onrubia e
20 (Vector v = new Vector();) se crea un objeto de la clase Vector (en el package java.util). La clase Vector permite almacenar referencias a objetos de distintas clases. En este caso se utilizar para almacenar referencias a a varias guras geomtricas diferentes. e Las siguientes sentencias 21-27 crean elementos grcos y los incluyen a en el vector v para ser dibujados ms tarde en el objeto de la clase a DrawWindow. Los objetos de la clase Circulo creados anteriormente no eran objetos aptos para ser dibujados, pues slo ten informacin del o an o centro y el radio, y no del color de l nea. Las clases RectanguloGraco y CirculoGraco, denidas en los Apartados 1.3.4 y 1.3.7, derivan respectivamente de las clases Rectangulo (Apartado 1.3.3) y Circulo (Apartado 1.3.4), heredando de dichas clases sus variables miembro y mtodos, aadiendo la e n informacin y los mtodos necesarios para poder dibujarlos en la pantalla. o e En las sentencias 21-22 se denen dos objetos de la clase CirculoGraco; a las coordenadas del centro y al radio se une el color de la l nea. En la sentencia 23-24 se dene un objeto de la clase RectanguloGraco, especicando asimismo un color, adems de las coordenadas del vrtice a e superior izquierdo, y del vrtice inferior derecho. En las sentencias 25-27 e los objetos grcos creados se aaden al vector v, utilizando el mtodo a n e addElement() de la clase Vector. En la sentencia 28 (PanelDibujo mipanel = new PanelDibujo(v);) se crea un objeto de la clase PanelDibujo. Por decirlo de alguna manera, los objetos de dicha clase son paneles, esto es supercies en las que se puede dibujar. Al constructor de PanelDibujo se le pasa como argumento el vector v con las referencias a los objetos a dibujar. La sentencia 29 (ventana.add(mipanel);) aade o incluye el panel (la supercie de dibujo) en la n ventana; la sentencia 30 (ventana.setSize(500, 400);) establece el tamao de n la ventana en pixels; nalmente, la sentencia 31 (ventana.setVisible(true);) hace visible la ventana creada. Cmo se consigue que se dibuje todo o esto? La clave est en la serie de rdenes que se han ido dando al a o computador. La clase PanelDibujo deriva de la clase Container a travs e de Panel, y redene el mtodo paint() de Container. En este mtodo, e e se realiza el dibujo de los objetos grcos creados. El usuario no tiene a que preocuparse de llamar al mtodo paint(), pues se llama de modo e automtico cada vez que el sistema operativo tiene alguna razn para a o ello (por ejemplo cuando se crea la ventana, cuando se mueve, cuando se minimiza o maximiza, cuando aparece despus de haber estado oculta, etc.). e
91
Jos Ma Onrubia e
5.2.2.
Clase Geometr a.
En este apartado se describe la clase ms importante de esta aplicacin. a o Es la ms importante no en el sentido de lo que hace, sino en el de que a las dems clases derivande ella, o por decirlo de otra forma, se apoyan o a cuelgan de ella. La Figura 1.2 muestra la jerarqu de clases utilizada en este a ejemplo. La clase Geometr es la base de la jerarqu En realidad no es la a a. base, pues en Java la clase base es siempre la clase Object. Siempre que no se diga expl citamente que una clase deriva de otra, deriva impl citamente de la clase Object (denida en el package java.lang). De las clases: Dibujable RectanguloGraco Rectangulo Dibujable CirculoGraco Circulo Geometr a Rectangulo y Circulo derivan respectivamente las clases RectanguloGraco y CirculoGraco. En ambos casos est por en medio un elemento un a poco especial donde aparece la palabra Dibujable. En trminos de Java, e Dibujable es una interface. Se suele utilizar la nomenclatura de superclase y subclase para referirse a la clase padre o hija de una clase determinada. Un aspecto importante a considerar es que no va a haber nunca objetos de la clase Geometria, es decir geometr a secas. Una clase de la que no va as a haber objetos es una clase abstracta, y como tal puede ser declarada. A continuacin se muestra el chero Geometr o a.java en el que se dene dicha clase:
1. 2. 3. 4. 5. 6.
// chero Geometria.java public abstract class Geometria { // clase abstracta que no puede tener objetos public abstract double perimetro(); public abstract double area(); }
La clase Geometr se declara como public para permitir que sea utilizada a por cualquier otra clase, y como abstract para indicar que no se permite crear objetos de esta clase. Es caracter stico de las clases tener variables y funciones miembro. La clase Geometr no dene ninguna variable miema 92 GVA-ELAI-UPM r PFC0074-03
Jos Ma Onrubia e
bro, pero s declara dos mtodos: per e metro() y area(). Ambos mtodos se e declaran como public para que puedan ser llamados por otras clases y como abstract para indicar que no se da ninguna denicin, es decir ningn cdigo o u o para ellos. Interesa entender la diferencia entre declaracin (la primera l o nea o header del mtodo) y denicin (todo el cdigo del mtodo, incluyendo la e o o e primera l nea). Se indica tambin que su valor de retorno -el resultado- va e a ser un double y que no tienen argumentos (obtendrn sus datos a partir a del objeto que se les pase como argumento impl cito). Es completamente lgico que no se denan en esta clase los mtodos per o e metro() y area(): la forma de calcular un per metro o un rea es completamente distinta a en un rectngulo y en un c a rculo, y por tanto estos mtodos habr que e a denirlos en las clases Rectngulo y Circulo. En la clase Geometria a lo unico que se puede decir es cmo sern dichos mtodos, es decir su o a e nombre, el nmero y tipo de sus argumentos y el tipo de su valor de retorno. u
5.2.3.
Clase Rectngulo. a
Segn el diagrama de clases de la Figura 1.2 la clase Rectangulo deriva u de Geometria. Esto se indica en la sentencia 2 con la palabra extends (en negrita en el listado de la clase).
1. // chero Rectangulo.java 2. public class Rectangulo extends Geometria { 3. // denicin de variables miembro de la claes o 4. private static int numRectangulos = 0; 5. protected double x1, y1, x2, y2; 6. // constructores de la clase 7. public Rectangulo(double p1x, double p1y, double p2x, double p2y) { 8. x1 = p1x; 9. x2 = p2x; 10. y1 = p1y; 11. y2 = p2y; 12. numRectangulos++; 13. } 14. public Rectangulo(){ this(0, 0, 1.0, 1.0); } 15. // denicin de mtodos o e 16. public double perimetro() { return 2.0 * ((x1-x2)+(y1-y2)); } 17. public double area() { return (x1-x2)*(y1-y2); } 18. } // n de la clase Rectngulo a
En la sentencia 4 (private static int numRectangulos = 0;) se dene una GVA-ELAI-UPM r PFC0074-03 93
Jos Ma Onrubia e
variable miembro static. Las variables miembro static se caracterizan por ser propias de la clase y no de cada objeto. De la variable numRectangulos, que en la sentencia 4 se inicializa a cero, se mantiene una unica copia para toda la clase. Adems esta variable es privada (private), lo cual quiere decir que a slo las funciones miembro de esta clase tienen permiso para utilizarla. El o declararlas como protected indica que slo esta clase, las clases que deriven o de ella y las clases del propio package tienen permiso para utilizarlas.
5.2.4.
Clase Circulo.
A continuacin se presenta la denicin de la clase Circulo, tambin o o e derivada de Geometria.
1. // chero Circulo.java 2. public class Circulo extends Geometria { 3. static int numCirculos = 0; 4. public static nal double PI=3.14159265358979323846; 5. public double x, y, r; 6. public Circulo(double x, double y, double r) { 7. this.x=x; this.y=y; this.r=r; 8. numCirculos++; 9. } 10. public Circulo(double r) { this(0.0, 0.0, r); } 11. public Circulo(Circulo c) { this(c.x, c.y, c.r); } 12. public Circulo() { this(0.0, 0.0, 1.0); } 13. public double perimetro() return 2.0 * PI * r; } 14. public double area() { return PI * r * r; } 15. // mtodo de objeto para comparar c e rculos 16. public Circulo elMayor(Circulo c) { 17. if (this.r>=c.r) return this; else return c; 18. } 19. // mtodo de clase para comparar c e rculos 20. public static Circulo elMayor(Circulo c, Circulo d) { 21. if (c.r>=d.r) return c; else return d; 22. } 23. } // n de la clase Circulo
La sentencia 3 (static int numCirculos = 0;) dene una variable static o de clase anloga a la de la clase Rectangulo. En este caso no se ha denido a como private. Cuando no se especican permisos de acceso (public, private o protected) se supone la opcin por defecto, que es package. Con esta o opcin la variable o mtodo correspondiente puede ser utilizada por todas o e 94 GVA-ELAI-UPM r PFC0074-03
Jos Ma Onrubia e
las clases del package y slo por ellas. Como en este ejemplo no se ha o denido ningn package, se utiliza el package por defecto que es el directorio u donde estn denidas las clases. As pues, la variable numCirculos podr ser a a utilizada slo por las clases que estn en el mismo directorio que Circulo. o e La sentencia 4 (public static nal double PI=3.14159265358979323846;) dene tambin una variable static, pero contiene una palabra nueva: nal. e Una variable nal tiene como caracter stica el que su valor no puede ser modicado, o lo que es lo mismo, es una constante. Es muy lgico denir el o nmero PI como constante, y tambin es razonable que sea una constante u e static de la clase Circulo, de forma que sea compartida por todos los mtodos y objetos que se creen. e La sentencia 6-9 dene el constructor general de la clase Circulo. En este caso tiene una peculiaridad y es que el nombre de los argumentos (x, y, r) coincide con el nombre de las variables miembro. Esto es un problema, porque como se ver ms adelante los argumentos de un mtodo son a a e variables locales que slo son visibles dentro del bloque ... del mtodo, que o e se destruyen al salir del bloque y que ocultan otras variables de mbito ms a a general que tengan esos mismos nombres. En otras palabras, si en el cdigo o del constructor se utilizan las variables (x, y, r) se est haciendo referencia a a los argumentos del mtodo y no a las variables miembro. La sentencia e 7 indica como se resuelve este problema. Para cualquier mtodo no static e de una clase, la palabra this es una referencia al objeto -el argumento impl cito- sobre el que se est aplicando el mtodo. De esta forma, this.x se a e reere a la variable miembro, mientras que x es el argumento del constructor. Las sentencias 10-12 representan otros tres constructores de la clase (mtoe dos sobrecargados), que se diferencian en el nmero y tipo de argumentos. u Los tres tienen en comn el realizar su papel llamando al constructor general u previamente denido, al que se hace referencia con la palabra this (en este caso el signicado de this no es exactamente el del argumento impl cito). Las sentencias 13 y 14 denen los mtodos perimetro() y area(), declarae dos como abstract en la clase Geometria, de modo adecuado para los c rculos. Las sentencias 16-18 denen elMayor(), que es un mtodo de objeto para e comparar c rculos. Uno de los c rculos le llega como argumento impl cito y el otro como argumento expl cito. En la sentencia 17 se ve cmo al radio del o argumento impl cito se accede en la forma this.r (se podr acceder tambin a e simplemente con r, pues no hay ninguna variable local que la oculte), y al del argumento expl cito como c.r, donde c es el nombre del objeto pasado como argumento. La sentencia return devuelve una referencia al objeto
95
Jos Ma Onrubia e
cuyo radio sea mayor. Cuando ste es el argumento impl e cito se devuelve this. Las sentencias 20-22 presentan la denicin de otro mtodo elMayor(), o e que en este caso es un mtodo de clase (denido como static), y por tanto e no tiene argumento impl cito. Los dos objetos a comparar se deben pasar como argumentos expl citos, lo que hace el cdigo muy fcil de entender. Es o a importante considerar que en ambos casos lo que se devuelve como valor de retorno no es el objeto que constituye el mayor c rculo, sino una referencia (un nombre, por decirlo de otra forma).
5.2.5.
Interface Dibujable
. El diagrama de clases de la Figura 1.2 indica que las clases RectanguloGraco y CirculoGraco son el resultado tanto de las clases Rectangulo y Circulo, de las que derivan, como de la interface Dibujable, que de alguna manera interviene en el proceso. El concepto de interface es muy importante en Java. A diferencia de C++, Java no permite herencia mltiple, esto u es, no permite que una clase derive de dos clases distintas heredando de ambas mtodos y variables miembro. La herencia mltiple es fuente de e u problemas, pero en muchas ocasiones es una caracter stica muy conveniente. Las interfaces de Java constituyen una alternativa a la herencia mltiple u con importantes ventajas prcticas y de estilo de programacin. a o Una interface es un conjunto de declaraciones de mtodos (sin implee mentacin, es decir, sin denir el cdigo de dichos mtodos). La declaracin o o e o consta del tipo del valor de retorno y del nombre del mtodo, seguido por e el tipo de los argumentos entre parntesis. Cuando una clase implementa e una determinada interface, se compromete a dar una denicin a todos los o mtodos de la interface. En cierta forma una interface se parece a una clase e abstract cuyos mtodos son todos abstract. La ventaja de las interfaces e es que no estn sometidas a las ms r a a gidas normas de las clases; por ejemplo, una clase no puede heredar de dos clases abstract, pero s puede implementar varias interfaces. Una de las ventajas de las interfaces de Java es el establecer pautas o modos de funcionamiento similares para clases que pueden estar o no relacionadas mediante herencia. En efecto, todas las clases que implementan una determinada interface soportan los mtodos declarados en la interface e y en este sentido se comportan de modo similar. Las interfaces pueden tambin relacionarse mediante mecanismos de herencia, con ms exibile a idad que las clases. El chero Dibujable.java dene la interface Dibujable, 96 GVA-ELAI-UPM r PFC0074-03
Jos Ma Onrubia e mostrada a continuacin. o
1. 2. 3. 4. 5. 6.
// chero Dibujable.java import java.awt.Graphics; public interface Dibujable { public void setPosicion(double x, double y); public void dibujar(Graphics dw); }
La interface Dibujable est dirigida a incorporar, en las clases que la a implementen, lacapacidad de dibujar sus objetos. El listado muestra la declaracin de los mtodos setPosicion() y dibujar(). La declaracin de o e o estos mtodos no tiene nada de particular. Como el mtodo dibujar() utiliza e e como argumento un objeto de la clase Graphics, es necesario importar dicha clase. Lo importante es que si las clases RectanguloGraco y CirculoGraco implementan la interface Dibujable sus objetos podrn ser representados a grcamente en pantalla. a
5.2.6.
Clase RectanguloGraco.
La clase RectanguloGraco deriva de Rectangulo (lo cual quiere decir que hereda sus mtodos y variables miembro) e implementa la interface e Dibujable (lo cual quiere decir que implementa los mtodos declarados en e dicha interface). A continuacin se incluye la denicin de dicha clase. o o
1. // Fichero RectanguloGraco.java GVA-ELAI-UPM r PFC0074-03 97
Jos Ma Onrubia e
2. import java.awt.Graphics; 3. import java.awt.Color; 4. class RectanguloGraco extends Rectangulo implements Dibujable { 5. // nueva variable miembro 6. Color color; 7. // constructor 8. public RectanguloGraco(double x1, double y1, double x2, double y2, 9. Color unColor) { 10. // llamada al constructor de Rectangulo 11. super(x1, y1, x2, y2); 12. this.color = unColor; // en este caso this es opcional 13. } 14. // mtodos de la interface Dibujable e 15. public void dibujar(Graphics dw) { 16. dw.setColor(color); 17. dw.drawRect((int)x1, (int)y1, (int)(x2-x1), (int)(y2-y1)); 18. } 19. public void setPosicion(double x, double y) { 20. ; // mtodo vac pero necesario de denir e o, 21. } 22. } // n de la clase RectanguloGraco
La sentencia 4 indica que RectanguloGraco deriva de la clase Rectangulo e implementa la interface Dibujable. Recurdese que mientras que slo se e o puede derivar de una clase, se pueden implementar varias interfaces, en cuyo caso se ponen en el encabezamiento de la clase separadas por comas. La sentencia 6 (Color color;) dene una nueva variable miembro que se suma a las que ya se tienen por herencia. Esta nueva variable es un objeto de la clase Color. Las sentencias 14-18 y 19-21 denen los dos mtodos declarados por e la interface Dibujable. El mtodo dibujar() recibe como argumento un e objeto dw de la clase Graphics. Esta clase dene un contexto para realizar operaciones grcas en un panel, tales como el color de las l a neas, el color de fondo, el tipo de letra a utilizar en los rtulos, etc. Ms adelante se ver con o a a ms detenimiento este concepto. La sentencia 16 (dw.setColor(color);) hace a uso un mtodo de la clase Graphics para determinar el color con el que se e dibujarn las l a neas a partir de ese momento. Java obliga a implementar o denir siempre todos los mtodos declarados e por la interface, aunque no se vayan a utilizar. Esa es la razn de que las o sentencias 19-21 denan un mtodo vac que slo contiene un carcter e o, o a
98
Jos Ma Onrubia e
punto y coma. Como no se va a utilizar no importa que est vac pero e o, Java obliga a dar una denicin o implementacin. o o
5.2.7.
Clase CirculoGraco.
A continuacin se dene la clase CirculoGraco, que deriva de la clase o Circulo e implementa la interface Dibujable.
// chero CirculoGraco.java import java.awt.Graphics; import java.awt.Color; public class CirculoGraco extends Circulo implements Dibujable { // se heredan las variables y mtodos de la clase Circulo e Color color; // constructor public CirculoGraco(double x, double y, double r, Color unColor) { // llamada al constructor de Circulo super(x, y, r); this.color = unColor; } // mtodos de la interface Dibujable e public void dibujar(Graphics dw) { dw.setColor(color); dw.drawOval((int)(x-r),(int)(y-r),(int)(2*r),(int)(2*r)); } public void setPosicion(double x, double y) { ; } } // n de la clase CirculoGraco
5.2.8.
Clase PanelDibujo.
La clase que se describe en este apartado es muy importante y quizs a una de las ms dif a ciles de entender en este cap tulo introductorio. La clase PanelDibujo es muy importante porque es la responsable nal de que los rectngulos y c a rculos aparezcan dibujados en la pantalla. Esta clase deriva de la clase Panel, que deriva de Container, que deriva de Component, que deriva de Object. Ya se ha comentado que Object es la clase ms general de Java. La clase a GVA-ELAI-UPM r PFC0074-03 99
Jos Ma Onrubia e
Component comprende todos los objetos de Java que tienen representacin o grca, tales como botones, barras de desplazamiento, etc. Los objetos a de la clase Container son objetos grcos del AWT (Abstract Windows a Toolkit; la librer de clases de Java que permite crear interfaces grcas de a a usuario) capaces de contener otros objetos del AWT. La clase Panel dene los Container ms sencillos, capaces de contener otros elementos grcos a a (como otros paneles) y sobre la que se puede dibujar. La clase PanelDibujo contiene el cdigo que se muestra a continuacin. o o
1. // chero PanelDibujo.java 2. import java.awt.*; 3. import java.util.Vector; 4. import java.util.Enumeration; 5. public class PanelDibujo extends Panel { 6. // variable miembro 7. private Vector v; 8. // constructor 9. public PanelDibujo(Vector vect) { 10. super(new FlowLayout()); 11. this.v = vect; 12. } 13. // redenicin del mtodo paint() o e 14. public void paint(Graphics g) { 15. Dibujable dib; 16. Enumeration e; 17. e = v.elements(); 18. while(e.hasMoreElements()) { 19. dib = (Dibujable)e.nextElement(); 20. dib.dibujar(g); 21. } 22. } 23. } // Fin de la clase PanelDibujo
La clase Vector y la interface Enumeration pertenecen al package java.util, y sirven para tratar colecciones o conjuntos, en este caso conjuntos de guras dibujables. La sentencia 5 indica que la clase PanelDibujo deriva de la clase Panel, heredando de sta y de sus superclases Container y Component todas sus e capacidades grcas. a
100
Jos Ma Onrubia e
La sentencia 7 (private Vector v;) crea una variable miembro v que es una referencia a un objeto de la clase Vector (ntese que no es un objeto, o sino una referencia o un nombre de objeto). Las sentencias 9-12 denen el constructor de la clase, que recibe como argumento una referencia vect a un objeto de la clase Vector. En este vector estarn almacenadas las referencias a los objetos -rectngulos y c a a rculosque van a ser dibujados. En la sentencia 10 (super(new FlowLayout());) se llama al constructor de la superclase panel, pasndole como argumento un objeto recin creado de a e la clase FlowLayout. Al hablar de construccin de interfaces grcas con o a el AWT, la clase FlowLayout se ocupa de distribuir de una determinada forma (de izquierda a derecha y de arriba abajo) los componentes grcos a que se aaden a un ontainertal como la clase Panel. n c Hay que introducir ahora un aspecto muy importante de Java y, en general, de la programacin orientada a objetos. Tiene que ver con algo o que es conocido con el nombre de Polimorsmo. La idea bsica es que a una referencia a un objeto de una determinada clase es capaz de servir de referencia o de nombre a objetos de cualquiera de sus clases derivadas. Por ejemplo, es posible en Java hacer lo siguiente:
Geometria geom1, geom2; geom1 = new RectanguloGraco(0, 0, 200, 100, Color.red); geom2 = new CirculoGraco(200, 200, 100, Color.blue);
Obsrvese que se han creado dos referencias de la clase Geometria que e posteriormente apuntan a objetos de las clases derivadas RectanguloGraco y Circulo-Graco. Sin embargo, hay una cierta limitacin en lo que se o puede hacer con las referencias geom1 y geom2. Por ser referencias a la clase Geometria slo se pueden utilizar las capacidades denidas en dicha o clase, que se reducen a la utilizacin de los mtodos perimetro() y area(). o e De la misma forma que se ha visto con la clase base Geometria, en Java es posible utilizar una referencia del tipo correspondiente a una interface para manejar objetos de clases que implementan dicha interface. Por ejemplo, es posible escribir:
101
Jos Ma Onrubia e
Dibujable dib1, dib2; dib1 = new RectanguloGraco(0, 0, 200, 100, Color.red); dib2 = new CirculoGraco(200, 200, 100, Color.blue);
donde los objetos referidos por dib1 y dib2 pertenecen a las clases RectanguloGraco y CirculoGraco, que implementan la interface Dibujable. Tambin los objetos dib1 y dib2 tienen una limitacin: slo pueden ser e o o utilizados con los mtodos denidos por la interface Dibujable. El poder e utilizar nombres de una superclase o de una interface permite tratar de un modounicado objetos distintos, aunque pertenecientes a distintas subclases o bien a clases que implementan dicha interface. Esta es la idea en la que se basa el polimorsmo. Ahora ya se est en condiciones de volver al cdigo del mtodo paint(), a o e denido en las sentencias 14-22 de la clase PanelDibujo. El mtodo paint() e es un mtodo heredado de Container, que a su vez redene el mtodo e e heredado de Component. En la clase PanelDibujo se da una nueva denicin o de este mtodo. Una peculiaridad del mtodo paint() es que, por lo general, e e el programador no tiene que preocuparse de llamarlo: se encargan de ello Java y el sistema operativo. El programador prepara por una parte la ventana y el panel en el que va a dibujar, y por otra programa en el mtodo paint() las operaciones e grcas que quiere realizar. El sistema operativo y Java llaman a paint() a cada vez que entienden que la ventana debe ser dibujada o redibujada. El unico argumento de paint() es un objeto g de la clase Graphics que, como se ha dicho antes, constituye el contexto grco (color de las l a neas, tipo de letra, etc.) con el que se realizarn las operaciones de dibujo. a La sentencia 15 (Dibujable dib;) crea una referencia de la clase Dibujable, que como se ha dicho anteriormente, podr apuntar o contener objetos a de cualquier clase que implemente dicha interface. La sentencia 16 (Enumeration e;) crea una referencia a un objeto de la interface Enumeration denida en el package java.util. La interface Enumeration proporciona los mtodos hasMoreElements(), que chequea si la coleccin de elementos que e o se est recorriendo tiene ms elementos y nextElement(), que devuelve el a a siguiente elemento de la coleccin. Cualquier coleccin de elementos (tal o o como la clase Vector de Java, o como cualquier tipo de lista vinculada programada por el usuario) puede implementar esta interface, y ser por
102
Jos Ma Onrubia e
tanto utilizada de un modo uniforme. La sentencia 19 (dib = (Dibujable)e.nextElement();) contiene bastantes elementos nuevos e importantes. El mtodo e.nextElement() devuelve el e siguiente objeto de la enumeracin. En principio este objeto podr ser de o a cualquier clase. Los elementos de la clase Vector son referencias de la clase Object, que es la clase ms general de Java, la clase de la que derivan todas a las dems. Esto quiere decir que esas referencias pueden apuntar a objetos a de cualquier clase. El nombre de la interface (Dibujable) entre parntesis e representa un cast o conversin entre tipos diferentes. En Java como en o C++, la conversin entre variables u objetos de distintas clases es muy o importante. Por ejemplo, (int)3.14 convierte el nmero double 3.14 en el u entero 3. Evidentemente no todas las conversiones son posibles, pero s lo son y tienen mucho inters las conversiones entre clases que estn en la e a misma l nea jerrquica (entre sub-clases y super-clases), y entre clases que a implementan la misma interface. Lo que se est diciendo a la referencia a dib con el cast a la interface Dibujable en la sentencia 19, es que el objeto de la enumeracin va a ser tratado exclusivamente con los mtodos de o e dicha interface. En la sentencia 20 (dib.dibujar(g);) se aplica el mtodo e dibujar() al objeto referenciado por dib, que forma parte de la enumeracin o e, obtenida a partir del vector v. Lo que se acaba de explicar puede parecer un poco complicado, pero es t pico de Java y de la programacin orientada a objetos. La ventaja del o mtodo paint() as programado es que es absolutamente general: en ningn e u momento se hace referencia a las clases RectanguloGraco y CirculoGraco, cuyos objetos son realmente los que se van a dibujar. Esto permite aadir n nuevas clases tales como TrianguloGraco, PoligonoGraco, LineaGraca, etc., sin tener que modicar para nada el cdigo anterior: tan slo es o o necesario que dichas clases implementen la interface Dibujable. Esta es una ventaja no pequea cuando se trata de crear programas extensibles (que n puedan crecer), exibles (que se puedan modicar) y reutilizables (que se puedan incorporar a otras aplicaciones).
5.2.9.
Clase VentanaCerrable.
Es una clase de utilidadque mejora algo las caracter sticas de la clase Frame de Java, de la que deriva. La clase Frame estndar tiene una a limitacin y es que no responde a las acciones normales en Windows para o cerrar una ventana o una aplicacin (por ejemplo, clicar en la cruz de o la esquina superior derecha). En ese caso, para cerrar la aplicacin es o necesario recurrir por ejemplo al comando End Task del Task Manager de Windows NT (que aparece con Ctrl+Alt+Supr). Para evitar esta molestia GVA-ELAI-UPM r PFC0074-03 103
Jos Ma Onrubia e
se ha creado la clase VentanaCerrable, que deriva de Frame e implementa la interface WindowListener.
1. // Fichero VentanaCerrable.java 2. import java.awt.*; 3. import java.awt.event.*; 4. class VentanaCerrable extends Frame implements WindowListener { 5. // constructores 6. public VentanaCerrable() { 7. super(); 8. } 9. public VentanaCerrable(String title) { 10. super(title); 11. setSize(500,500); 12. addWindowListener(this); 13. } 14. // mtodos de la interface WindowsListener e 15. public void windowActivated(WindowEvent e) {;} 16. public void windowClosed(WindowEvent e) {;} 17. public void windowClosing(WindowEvent e) {System.exit(0);} 18. public void windowDeactivated(WindowEvent e) {;} 19. public void windowDeiconied(WindowEvent e) {;} 20. public void windowIconied(WindowEvent e) {;} 21. public void windowOpened(WindowEvent e) {;} 22. } // n de la clase VentanaCerrable
La sentencia 12 (addWindowListener(this);) es muy importante y signicativa sobre la forma en que el AWT de Java gestiona los eventos sobre las ventanas y en general sobre lo que es la interface grca de a usuario. Cuando un elemento grco -en este caso la ventana- puede recibir a eventos del usuario es necesario indicar quin se va a encargar de procesar e esos eventos. De ordinario al producirse un evento se debe activar un mtodo determinado que se encarga de procesarlo y realizar las acciones e pertinentes (en este caso cerrar la ventana y la aplicacin). La sentencia o 12 ejecuta el mtodo addWindowListener() de la clase Frame (que a su e vez lo ha heredado de la clase Window). El argumento que se le pasa a este mtodo indica qu objeto se va a responsabilizar de gestionar los e e eventos que reciba la ventana implementando la interface WindowListener. En este caso, como el argumento que se le pasa es this, la propia clase VentanaCerrable debe ocuparse de gestionar los eventos que reciba. As es, puesto que dicha clase implementa la interface WindowListener segn se ve u
104
5.3. NOMENCLATURA HABITUAL EN LA PROGRAMACION EN a Onrubia Jos M e JAVA. en la sentencia 4. Puede notarse que como el constructor por defecto de las sentencias 6-8 no utiliza el mtodo addWindowListener(), si se construye e una VentanaCerrable sin t tulo no podr ser cerrada del modo habitual. a As se ha hecho deliberadamente en este ejemplo para que el lector lo pueda comprobar con facilidad. La interface WindowListener dene los siete mtodos necesarios para gese tionar los siete eventos con los que se puede actuar sobre una ventana. Para cerrar la ventana slo es necesario denir el mtodo windowClosing(). Sin o e embargo, el implementar una interface obliga siempre a denir todos sus mtodos. Por ello en las sentencias 15-21 todos los mtodos estn vac e e a os (solamente el punto y coma entre llaves), excepto el que realmente interesa, que llama al mtodo exit() de la clase System. El argumento 0indica e terminacin normal del programa. o
5.3.
Nomenclatura habitual en la programacin en o java.
Los nombres de Java son sensibles a las letras maysculas y minsculas. u u As las variables masa, Masa y MASA son consideradas variables com, pletamente diferentes. Las reglas del lenguaje respecto a los nombres de variables son muy amplias y permiten mucha libertad al programador, pero es habitual seguir ciertas normas que facilitan la lectura y el mantenimiento de los programas de ordenador. Se recomienda seguir las siguientes instrucciones:
1. En Java es habitual utilizar nombres con minsculas, con las excepu ciones que se indican en los puntos siguientes. 2. Cuando un nombre consta de varias palabras es habitual poner una a continuacin de otra, poniendo con mayscula la primera letra de o u la palabra que sigue a otra (Ejemplos: elMayor(), VentanaCerrable, RectanguloGraco, addWindowListener()). 3. Los nombres de clases e interfaces comienzan siempre por mayscula u (Ejemplos: Geometria, Rectangulo, Dibujable, Graphics, Vector, Enumeration). 4. Los nombres de objetos, los nombres de mtodos y variables miembro, e y los nombres de las variables locales de los mtodos, comienzan sieme pre por minscula (Ejemplos: main(), dibujar(), numRectangulos, x, u y, r). GVA-ELAI-UPM r PFC0074-03 105
Jos Ma Onrubia e
5. Los nombres de las variables nales, es decir de las constantes, se denen siempre con maysculas (Ejemplo: PI) u
5.4.
Estructura general de un programa java.
El anterior ejemplo presenta la estructura habitual de un programa realizado en cualquier lenguaje orientado a objetos u OOP (Object Oriented Programming), y en particular en el lenguaje Java. Aparece una clase que contiene el programa principal (aquel que contiene la funcin o main()) y algunas clases de usuario (las espec cas de la aplicacin que se o est desarrollando) que son utilizadas por el programa principal. a Los cheros fuente tienen la extensin *.java, mientras que los cheros o compilados tienen la extensin *.class. Un chero fuente (*.java) puede o contener ms de una clase, pero slo una puede ser public. El nombre del a o chero fuente debe coincidir con el de la clase public (con la extensin *.java. o Si la clase no es public, no es necesario que su nombre coincida con el del chero. Una clase puede ser public o package (default), pero no private o protected. De ordinario una aplicacin est constituida por varios cheros *.class. o a Cada clase realiza unas funciones particulares, permitiendo construir las aplicaciones con gran modularidad e independencia entre clases. La aplicacin se ejecuta por medio del nombre de la clase que contiene la o funcin main() (sin la extensin *.class). Las clases de Java se agrupan o o en packages, que son librer de clases. Si las clases no se denen como as pertenecientes a un package, se utiliza un package por defecto (default) que es el directorio activo. Los packages se estudian con ms detenimiento en a siguientes apartados.
5.4.1.
Concepto de Clase.
Una clase es una agrupacin de datos (variables o campos) y de funo ciones (mtodos) que operan sobre esos datos. A estos datos y funciones e pertenecientes a una clase se les denomina variables y mtodos o funciones e miembro. La programacin orientada a objetos se basa en la programacin o o de clases. Un programa se construye a partir de un conjunto de clases. Una vez denida e implementada una clase, es posible declarar elementos de esta clase de modo similar a como se declaran las variables del lenguaje (int, double, String, . . . ). Los elementos declarados de una clase se denom106 GVA-ELAI-UPM r PFC0074-03
Jos Ma Onrubia ESTRUCTURA GENERAL DE UN PROGRAMA JAVA. e 5.4. inan objetos de la clase. De una unica clase se pueden declarar o crear numerosos objetos. La clase es lo genrico: es el patrn o modelo para crear e o objetos. Cada objeto tiene sus propias copias de las variables miembro, con sus propios valores, en general distintos de los dems objetos de la clase. a Las clases pueden tener variables static, que son propias de la clase y no de cada objeto.
5.4.2.
Herencia.
La herencia permite que se pueden denir nuevas clases basadas en clases existentes, lo cual facilita reutilizar cdigo previamente desarrollado. Si una o clase deriva de otra (extends) hereda todas sus variables y mtodos. La e clase derivada puede aadir nuevas variables y mtodos y/o redenir las n e variables y mtodos heredados. e En Java, a diferencia de otros lenguajes orientados a objetos, una clase slo puede derivar de una unica clase, con lo cual no es posible realizar o herencia mltiple en base a clases. Sin embargo es posible simularla u herencia mltiple en base a las interfaces. u
5.4.3.
Concepto de Interface.
Una interface es un conjunto de declaraciones de funciones. Si una clase implementa (implements) una interface, debe denir todas las funciones especicadas por la interface. Una clase puede implementar ms de una a interface, representando una forma alternativa de la herencia mltiple. u Una interface puede derivar de otra o incluso de varias interfaces, en cuyo caso incorpora todos los mtodos de las interfaces de las que deriva. e
5.4.4.
Concepto de Package.
Un package es una agrupacin de clases. Existen una serie de packo ages incluidos en el lenguaje (ver jerarqu de clases que aparece en el a API de Java). Adems el usuario puede crear sus propios packages. Lo a habitual es juntar en packages las clases que estn relacionadas. Todas e las clases que formen parte de un package deben estar en el mismo directorio.
107
Jos Ma Onrubia e
5.4.5.
La jerarqu de clases de Java (API). a
Durante la generacin de cdigo en Java, es recomendable y casi necesario o o tener siempre a la vista la documentacin on-line del API de Java . En o dicha documentacin es posible ver tanto la jerarqu de clases, es decir o a la relacin de herencia entre clases, como la informacin de los distintos o o packages que componen las librer base de Java. as Hay que resaltar el hecho de que todas las clases en Java son derivadas de la clase java.lang.Object, por lo que heredan todos los mtodos y variables e de sta. e
108
Cap tulo 6
Desarrollo de nuestra aplicacin mediante JDT, o JDK 1.4.1 y JBuilder7.

6.1. Introduccin. o
Una vez elegidas las librer JDT y hecho un estudio de Java, se est listo as a para comenzar a crear nuestra aplicacin DICOM. o El primer paso que se tiene que dar es la eleccin del entorno de desarrollo o a utilizar. La disyuntiva que aparece es el uso de JBuilder o de Visual J++; pero la eleccin est casi tomada desde un principio a favor de JBuilder o a de Borland debido a lo mucho ms completo, espec a co y con muchas ms a prestaciones que VJ++. Por lo tanto nos encontramos con un entorno de desarrollo llamado JBuilder (en nuestro caso la versin 7.0 Enterprise), con unas librer o as de DICOM llamadas JDT y con las propias librer Java, JDK (1.4.1), as mediante las cuales se va a implementar nuestra aplicacin DICOM. o Paso a paso se va a ver la progresin seguida para este proceso de creacin o o de la aplicacin, cuyo orden podr ser el siguiente: o a
Uso de JBuilder 7.0 Uso de librer JDK 1.4.1 as Uso de librer JDK y JDT en JBuilder as Implementacin conjunta. o 109
CAP ITULO 6. DESARROLLO DE NUESTRA APLICACION MEDIANTE JDT, JDK 1.4.1 Y JBUILDER7. Jos Ma Onrubia e
6.2.
6.2.1.
Uso de JBuilder 7.0

Introduccin. o
En esta seccin se van a ver los aspectos ms importantes a la hora o a de crear una aplicacin (interfaz de usuario) mediante este programa de o desarrollo.
6.2.2.
Instalacin de JBuilder. o
Es un proceso muy sencillo en el cual hemos tenido algunas peculiaridades. Pasos para la instalacin: o
1. Ir a la pgina web de sun (http://www.borland.com/products/ downa loads/download builder.html) y descagar la versin de JBuilder deseao da; en nuestro caso JBuilder 7.0 Enterprise. 2. Pedir via email un archivo de activacin necesario para poder trabajar o con el programa. 3. Ejecutar JBuilder y cuando pide el archivo de activacin indicarle la o ruta de ste. e 4. Cambiar el archivo localizado en .../JBuilder7/bin jbuilder.jar y sustituirlo por el proporcionado para que la licencia dure en vez de un mes, unos cuantos d ms. En este momento es posible trabajar con el as a programa sin preocuparnos de problemas de tiempo con la licencia.
6.2.3.
Creacin de una aplicacin JBuilder. o o
Se va a crear un simple editor de texto para ver cmo realizar una o aplicacin. El estudio de este ejemplo proporciona una base esplndida o e para, a partir de ste, tener las nociones bsicas en JBuilder y poder e a avanzar rpida y fcilmente en la creacin de una interfaz de usuario. a a o Pasos:
Paso 1: Creacin de un proyecto. o Para crear un proyecto se usa el asistente para proyectos y el asistente para aplicaciones, lo que acelera este proceso de creacin, de esta forma: o
110
Jos Ma Onrubia e
6.2. USO DE JBUILDER 7.0
1. Elija ArchivoNuevo proyecto para iniciar el Asistente para proyectos. 2. Realice los siguientes cambios en el Paso 1: Nombre: Editor de texto Tipo (tipo de archivo): .jpx Seleccione la opcin Crear archivo de notas del proyecto. Al seo leccionar esta opcin, el Asistente para proyectos crea un archivo o HTML para las notas del proyecto y lo aade al mismo. n 3. Acepte todas las dems opciones por defecto en el Paso 1, 2 y 3. a
Figura 6.1: Asistente para proyectos: paso 1 Una vez creado nuestro proyecto podemos pasar a crear nuestra aplicacin o dentro de l mediante el asistente para aplicaciones: e
1. Abra la galer de objetos seleccionando ArchivoNuevo. a 2. Haga doble clic en el en el icono Aplicacin para abrir el Asistente o para aplicaciones. GVA-ELAI-UPM r PFC0074-03 111
CAP ITULO 6. DESARROLLO DE NUESTRA APLICACION MEDIANTE JDT, JDK 1.4.1 Y JBUILDER7. Jos Ma Onrubia e 3. Cambie el nombre de clase de la aplicacin en el Paso 1. o
4. Pulse Siguiente para ir al Paso 2 del Asistente para proyectos.
5. Cambie el nombre y el t tulo de la clase de marco en el Paso 2
6. Seleccione todas las opciones del Paso 2. El asistente genera automticamente el cdigo correspondiente a las opciones seleccionadas. a o (F jese en el signicado de cada opcin segn las va marcando). o u
7. Haga clic en el botn Finalizar. El Asistente para aplicaciones aade o n al proyecto un .java y archivos de imagen.
8. Guarde el proyecto utilizando ArchivoGuardar proyecto.
9. Pulse la pestaa Diseo del archivo abierto, TextEditFrame.java. La n n pestaa Diseo, ubicada en la parte inferior de la ventana del Visun n alizador de aplicaciones, abre el diseador de interfaces de usuario. n Observe estos cambios en el IDE de JBuilder:
En el panel de contenido aparece el diseador de interfaces. n El rbol de componentes aparece en el panel de estructura. a El Inspector aparece a la derecha del diseador. n 112 GVA-ELAI-UPM r PFC0074-03
Jos Ma Onrubia e
Figura 6.2: Partes de aplicacin. o
Paso 2: A adir un rea de texto. n a En este paso se crea un rea de texto que rellena por completo el marco a de la interfaz de usuario entre la barra de mens por encima y la barra u de estado por debajo. Para lograrlo, el gestor de diseos del contenedor n principal de la interfaz de usuario debe utilizar BorderLayout. Como consecuencia de la utilizacin del Asistente para aplicaciones, el principal o contenedor de esta interfaz de usuario, que aparece como this en el rbol a de componentes, contiene un JPanel denominado contentPane que ya se ha cambiado a BorderLayout. Lo unico que hay que hacer ahora es aadir los n componentes del rea de texto a contentPane. a Para ello, se aadir un panel de desplazamiento en el contentPane n a y despus se colocar un componente de rea de texto dentro del panel e a a de desplazamiento. El panel de desplazamiento proporciona barras de desplazamiento al rea de texto. a
113
CAP ITULO 6. DESARROLLO DE NUESTRA APLICACION MEDIANTE JDT, JDK 1.4.1 Y JBUILDER7. Jos Ma Onrubia e 1. Haga clic en la pestaa TextEditFrame del editor, y a continuacin n o seleccione la pestaa Diseo. n n 2. Haga clic en el componente contentPane del rbol de componentes a para seleccionarlo, como se muestra a continuacin. o
Figura 6.3: contentPane 3. Pulse la pestaa Contenedores Swing en la paleta de componentes y n seleccione el componente JScrollPane.
Figura 6.4: JScrollPane 4. Haga clic en el centro de contentPane del diseador de interfaces. Esto n coloca el componente JScrollPane en el panel de contenido y deber a darle una restriccin de centro BorderLayout, haciendo que ocupe como pletamente el rea situada entre la barra de herramientas y la barra a de desplazamiento. Si no lo consigue, seleccione EdicinDeshacer e o intntelo de nuevo. e 5. Seleccione el nuevo componente jScrollPane1 en el rbol de compoa nentes. 114 GVA-ELAI-UPM r PFC0074-03
Jos Ma Onrubia e
6. F jese en el valor de la propiedad constraints del Inspector y compruebe que se le est asignando el valor Center. Si no es as seleccione Center a , en la lista desplegable.
Figura 6.5: constraints
7. Pulse la pestaa Swing en la paleta y seleccione el componente n JTextArea.
Figura 6.6: JTextArea
8. Haga clic sobre el componente jScrollPane1 en el rbol de componentes a o arrstrelo al diseador de interfaces para colocar JTextArea en el a n panel de desplazamiento.
9. En el Inspector, haga clic con el botn derecho sobre la propiedad text o y seleccione Borrar el valor de la propiedad para eliminar jTextArea1 del rea de texto. a GVA-ELAI-UPM r PFC0074-03 115
Figura 6.7: text
10. Por ultimo, debe denir algunas propiedades en jTextArea1 para que ajuste automticamente las l a neas de texto y lo haga en los espacios entre palabras. En el Inspector, asigne los siguientes valores:
lineWrap = true wrapStyleWord = true background = white
A continuacin, compile el programa y ejectelo para ver qu aspecto o u e ofrece.
1. Seleccione ProyectoEjecutar Make del proyecto en el men. Esto u compila todos los archivos del proyecto y crea un archivo TextEditClass.class y un TextEditFrame.class en una carpeta de clases dentro de la carpeta de proyectos. Deber compilarse sin errores. a
2. Haga clic en el botn Ejecutar en la barra de herramientas de JBuilder o o seleccione EjecutarEjecutar proyecto en el men. Ahora la interfaz u de usuario ofrecer un aspecto similar al siguiente: a 116 GVA-ELAI-UPM r PFC0074-03
Jos Ma Onrubia e
Figura 6.8: Ejecutado 3. En la aplicacin Editor de texto, seleccione ArchivoSalir para cero rar la ventana de ejecucin. o Paso 3: Crear men s. u En este paso se van a crear estos mens: u
Figura 6.9: Mens u 1. Haga clic en la pestaa Diseo de TextEditFrame.java si an no est sen n u a leccionada. 2. Haga doble clic sobre jMenuBar1 en la carpeta Menu del rbol de coma ponentes para abrir el diseador de mens. (Tambin puede seleccionar n u e un elemento de men del rbol de componentes y pulsar Intro.) u a 3. Seleccione el elemento de men ArchivoSalir en el diseador de u n mens o jMenuFileExit en el rbol de componentes. El diseador de u a n mens resaltar el elemento seleccionado. u a 4. Haga clic en el botn Insertar elemento de men de la barra de hero u ramientas del diseador de mens, o pulse la tecla Insert del teclado. n u Encima de Salir se introduce un nuevo elemento de men resaltado y u vac o. GVA-ELAI-UPM r PFC0074-03 117
CAP ITULO 6. DESARROLLO DE NUESTRA APLICACION MEDIANTE JDT, JDK 1.4.1 Y JBUILDER7. Jos Ma Onrubia e 5. Escriba Nuevo en el rea resaltada. a 6. Pulse Flecha abajo para aceptar la nueva entrada y baje al siguiente elemento (en este caso, el elemento de men Salir). u 7. Haga clic con el botn derecho en Salir y seleccione Insertar elemeno to de men en el men contextual. Escriba Abrir. Nota: Tambin se u u e puede acceder a todas las acciones de la barra de herramientas desde el men emergente que aparece al hacer clic con el botn derecho. u o 8. De la misma forma, aada los elementos de men Guardar y Guardar n u como. 9. Seleccione Salir y haga clic en el botn Separador de la barra de hero ramientas para insertar una barra. El men Archivo ya est terminado. u a 10. Haga clic con el botn derecho en la barra principal de mens y seleco u cione Insertar men. As se crea un men entre los mens Archivo y u u u Ayuda. Escriba Edicin como nombre de este men. o u 11. Pulse Intro para descender hacia la siguiente entrada vac No es necea. sario pulsar Insert aqu porque este men no contiene ningn elemento u u despus de la entrada actual. Sugerencia: Para borrar una entrada, see leccinela y haga clic en el botn Borrar de la barra de herramientas, o o o pulse la tecla Supr dos veces. La primera vez que se pulsa la tecla Supr se borra el texto de la entrada. La segunda vez elimina la entrada del men. u 12. Prosiga con la construccin del men Edicin tal y como se indica en o u o la siguiente imagen, aadiendo tres elementos: Fuente (JBuilder SE y n Enterprise), Color de texto y Color de fondo. Si alguna entrada tiene una longitud superior al rea de edicin, el texto se desplazar aua o a tomticamente a medida que escriba. Cuando pulse Intro, el diseador a n de mens ajustar el ancho del men para mostrar el elemento ms u a u a largo de la lista. 13. Cierre el diseador de mens con un doble clic en cualquier compon u nente de la seccin de la interfaz de usuario del rbol de componentes. o a Esto har que el panel de contenido cambie al diseador de interfaces. a n 14. Guarde el archivo y ejecute la aplicacin. Ahora la interfaz de usuario o ofrecer un aspecto similar al siguiente: a 118 GVA-ELAI-UPM r PFC0074-03
Jos Ma Onrubia e
Figura 6.10: Editor Debe poder experimentar con la interfaz de usuario y escribir texto en el rea de texto, pero los botones no funcionarn todav aunque s lo a a a harn los mens ArchivoSalir y AyudaAcerca de. a u Paso 4: A adir un cuadro de dilogo Selector de fuentes. n a Comencemos a enlazar los sucesos de men, empezando con el elemento u de men EdicinFuente que es el que va a mostrar el cuadro de dilogo u o a Selector de fuentes. En primer lugar, para poder utilizar esta opcin de men, debe aadir un o u n componente cuadro de dilogo Selector de fuentes a la clase TextEditFrame: a
1. Abra TextEditFrame.java en el diseador de interfaces. n 2. Seleccione la pestaa Ms dbSwing de la paleta de componentes y haga n a clic en el componente FontChooser . 3. Haga clic en cualquier lugar del rbol de componentes o en el diseador a n de interfaces, para aadir el FontChooser al diseo. Esto situar el n n a componente dentro de la clase como fontChooser1 y lo mostrar en la a carpeta Otros del rbol de componentes. a Slo ver el componente cuadro de dilogo en el rbol de componentes, o a a a no en el diseador de interfaces. n Creacin de un suceso para lanzar el Selector de fuentes o Creacin de un suceso para el elemento de men EdicinFuente, que o u o lanzar el Selector de fuentes: a
119
CAP ITULO 6. DESARROLLO DE NUESTRA APLICACION MEDIANTE JDT, JDK 1.4.1 Y JBUILDER7. Jos Ma Onrubia e 1. Seleccione el elemento de men EdicinFuente en el rbol de comu o a ponentes. Deber ser jMenuItem5 (en el segundo nodo de men, llaa u mado jMenu1.) Obsrve que la propiedad text para este elemento e de men del Inspector dice Fuente. No importa si su elemento de u men Fuente tiene un nmero diferente a ste. Pero asegrese de seu u e u leccionar el correspondiente al men Fuente. u 2. Haga clic en la pestaa sucesos en el Inspector, y haga doble clic en n el campo de valor (la segunda columna) del suceso actionPerformed. En los mens, botones y otros muchos componentes de la interfaz de u usuario de Java, actionPerformed es el suceso principal de usuario, que deber capturar para responder al usuario cuando utiliza el men o el a u botn. El nombre del mtodo de tratamiento de sucesos aparece en el o e campo de valor. Si el mtodo no existe todav esta operacin muestra e a, o el nombre propuesto por defecto para el nuevo mtodo de gestin del e o suceso. Para este nuevo manejador de sucesos, el nombre propuesto es jMenuItem5 actionPerformed.
Figura 6.11: actionPerformed 3. Haga doble clic en el valor de este suceso, o pulse Intro para crear el suceso. Si el mtodo de tratamiento del suceso es nuevo, esta operacin genere o ar un stub vac para el mtodo en el cdigo fuente. Independiena o e o temente de si el mtodo es nuevo o ya existe, el foco de ventana e cambiar a cdigo fuente en el editor y colocar el cursor dentro del a o a mtodo de tratamiento de sucesos. En el caso de un mtodo nuevo de e e tratamiento de sucesos, como es el caso, ver que la seccin principal a o del mtodo no contiene todav cdigo alguno. e a o 4. Escriba esta l nea de cdigo en el cuerpo de este nuevo mtodo vac o e o (entre las llaves de apertura y cierre): fontChooser1.showDialog(); 120 GVA-ELAI-UPM r PFC0074-03
Jos Ma Onrubia e
Ahora el mtodo deber parecerse a ste: e a e
void jMenuItem5 actionPerformed(ActionEvent e) { fontChooser1.showDialog(); }
5. Guarde y ejecute la aplicacin. El elemento de men EdicinFuente o u o deber abrir el cuadro de dilogo Selector de fuentes. Si no, compruebe a a que la propiedad frame tiene el valor this. Aunque intente cambiar la fuente, no suceder nada. Esto se debe a que no se utiliza el resultado a del FontChooser para cambiar el texto del rea de edicin. Esto ser lo a o a siguiente que hagamos.
6. Cierre la aplicacin EditorDeTexto. o
Paso 5: Vinculacin de sucesos de elemento de men al cuadro de o u dilogo Selector de fuentes. a Vamos a utilizar el cuadro de dilogo Selector de fuentes para modicar a la propiedad font de textArea1.
1. Haga clic en la pestaa Fuente y seleccione el mtodo de n e tratamiento del suceso del elemento de men Fuente ( jMenuu Item5 actionPerformed(ActionEvent e))) recin creado. e GVA-ELAI-UPM r PFC0074-03 121
Figura 6.12: jMenu 2. Introduzca este cdigo en el mtodo de tratamiento de sucesos o e para el elemento de men Fuente (jMenuItem5), entre las llaves u de apertura y cierre, asegurndose de reemplazar el cdigo antiguo a o fontChooser1.showDialog();: // Gestiona el elemento de men Edicin Fuente u o // Obtiene la fuente existente en el rea de texto a // y la lleva al Selector de fuente antes de mostrarlo // para que se modique la fuente // que ya existe fontChooser1.setSelectedFont(jTextArea1.getFont()); // Obtiene la nueva fuente del Selector de fuentes // Comprueba primero el valor devuelto por showDialog() para // ver si el usuario puls Aceptar. o if (fontChooser1.showDialog()) { // Asigna a la fuente de jTextArea1 el valor // seleccionado por el usuario antes de pulsar Aceptar jTextArea1.setFont(fontChooser1.getSelectedFont()); } //pinta el men de nuevo una vez que el elemento se ha seleccionado u this.repaint(); //Vuelve a dibujar el texto correctamente si hay texto selecionado al 122 GVA-ELAI-UPM r PFC0074-03
Jos Ma Onrubia e cambiar la fuente. jTextArea1.repaint();
3. Guarde y ejecute la aplicacin y escriba algo en el rea de texto. o a 4. Seleccione el texto y utilice el elemento de men EdicinFuente para u o cambiar la fuente. En esta aplicacin, se cambia la fuente de la totalio dad del rea de texto (no solamente del texto seleccionado). No espere a que la conguracin de fuentes se mantenga. No introduciremos cdigo o o para activar esa caracter stica. 5. Cierre la aplicacin EditorDeTexto. o
Paso 6: Vinculacin de sucesos de elementos de men a JColoro u Chooser. A continuacin se crean los sucesos de men EdicinColor de texto o u o y EdicinColor de fondo y se los vincula con el cuadro de dilogo o a JColorChooser de Swing. Al no necesitar asignar valores a ninguna de las propiedades de JColorChooseren el diseador, no es preciso aadirlo a la interfaz de usuario n n del diseador. Puede llamarlo directamente desde el manejador del suceso n actionPerformed() de un elemento de men del siguiente modo: u
1. Vuelva al diseador de TextEditFrame.java. n 2. Seleccione el segundo elemento de men del rbol de componentes en u a Edicin (jMenuItem6) que tiene escrito Color de textoen la propiedad o actionCommand. 3. Seleccione la pestaa Sucesos en el Inspector y haga clic tres veces en n el suceso actionPerformed() para crear el manejador del suceso: void jMenuItem6 actionPerformed(ActionEvent e) { }
4. Aada el cdigo siguiente en el stub del manejador del suceso n o GVA-ELAI-UPM r PFC0074-03 123
CAP ITULO 6. DESARROLLO DE NUESTRA APLICACION MEDIANTE JDT, JDK 1.4.1 Y JBUILDER7. Jos Ma Onrubia e (incluyendo los comentarios si lo desea): //Gestiona el elemento de men Color de texto u Color color = JColorChooser.showDialog(this,Color de texto, jTextArea1.getForeground()); if (color != null) { jTextArea1.setForeground(color); } //pinta el men de nuevo una vez que el elemento se ha seleccionado u this.repaint();
5. Vuelva al diseador. n
6. Seleccione el tercer elemento de men en el rbol de componentes, en u a Edicin (menuItem7), que debe tener la etiqueta Color de fondoen la o propiedad actionCommand. Cree un suceso actionPerformed () para l, tal como hizo con jMenuItem6. e
7. Inserte el siguiente cdigo en el suceso actionPerformed() de jMenuo Item7: // Gestiona el elemento de men Color de fondo u Color color = JColorChooser.showDialog(this,Color de fondo, jTextArea1.getBackground()); if (color != null) { jTextArea1.setBackground(color); } //pinta el men de nuevo una vez que el elemento se ha seleccionado u this.repaint();
8. Guarde el archivo, compile y ejecute la aplicacin. Escriba texto y o haga pruebas con los colores de primer plano y de fondo. La aplicacin o ofrecer el siguiente aspecto, si elige texto blanco con fondo negro: a 124 GVA-ELAI-UPM r PFC0074-03
Jos Ma Onrubia e
Figura 6.13: editor en negro 9. Cierre la aplicacin EditorDeTexto. o Paso 7: Adicin de un manejador a un suceso de men para borrar o u el rea de texto. a Vamos a capturar el elemento de men ArchivoNuevo con un manejador u que borra el contenido del rea de texto. a
1. Vuelva al diseador. n 2. Seleccione el elemento de men ArchivoNuevo del rbol de compou a nentes (jMenuItem1). 3. Cree un suceso actionPerformed() e introduzca en l este cdigo: e o // Gestiona el elemento de men ArchivoNuevo. u // Borra el texto del rea del texto. a jTextArea1.setText();
4. Guarde y ejecute la aplicacin, escriba algo en el rea de texto y vea o a qu sucede al seleccionar ArchivoNuevo. Deber borrar el contenido. e a Observe que no pregunta si desea guardar el archivo antes. Para poder tratar este aspecto, tendr que congurar la infraestructura para la a lectura y escritura de archivos de texto, para controlar si el archivo ha cambiado y necesita guardarse, etctera. Comenzaremos la utilizacin e o de archivos en el paso siguiente. 5. Cierre la aplicacin EditorDeTexto. o GVA-ELAI-UPM r PFC0074-03 125
CAP ITULO 6. DESARROLLO DE NUESTRA APLICACION MEDIANTE JDT, JDK 1.4.1 Y JBUILDER7. Jos Ma Onrubia e Paso 8: A adir un cuadro de dilogo selector de archivos. n a Vamos a enlazar el elemento de men ArchivoAbrir con un manejador u de un suceso que presenta al usuario un JFileChooser (cuadro de dilogo a para abrir archivos) para archivos de texto. Cuando el usuario selecciona un archivo y hace clic en Aceptar el manejador del suceso abre el archivo de texto y coloca su contenido dentro de JTextArea.
1. Vuelva al diseador y seleccione el componente JFileChooser de la n cha Swing Containers de la paleta de componentes. 2. Haga clic en la carpeta IU del rbol de componentes para colocar el a componente. (Si hace clic en el diseador de interfaces, el componente n se colocar en una seccin equivocada del rbol.) a o a 3. Seleccione el elemento de men ArchivoAbrir en el rbol de compou a nentes (jMenuItem2). 4. Cree un suceso actionPerformed() e introduzca este cdigo: o
// Gestionar el elemento de men ArchivoAbrir. u //Utilizar la versin OPEN del cuadro de dilogo, comprobar el valor o a devuelto de Aceptar/Cancelar if (JFileChooser.APPROVE OPTION == jFileChooser1.showOpenDialog(this)) { // Muestra el nombre del directorio y archivos abiertos en la barra de estado. statusBar.setText(.Abierto +jFileChooser1.getSelectedFile().getPath()); // El cdigo debe ir aqu para cargar realmente el texto o // en el TextArea. } 5. Salvar y ejecutar la aplicacin. En el men ArchivoAbrir, seleccione o u un archivo y pulse aceptar. Debe aparecer el nombre del archivo y el directorio completo en la l nea de estado en la parte inferior de la ventana. Sin embargo, el rea de texto seguir vac Nos ocuparemos a a a. de ello en el siguiente paso. 6. Cierre la aplicacin EditorDeTexto.antes de continuar. o 126 GVA-ELAI-UPM r PFC0074-03
Jos Ma Onrubia e
Paso 9: A adir cdigo para leer texto de un archivo. n o Posteriormente, vamos a aadir cdigo para leer el texto del archivo n o seleccionado por el usuario y ponerlo en el JTextArea. En primer lugar, habr que aadir un nuevo mtodo a la clase para a n e realizar la operacin de apertura del archivo. Este mtodo se llamar openo e a File():
1. Cambie el editor a TextEditFrame.java e introduzca el siguiente mtodo openFile(). Puede ponerlo en cualquier lugar de la clase e (fuera de otros mtodos). Un buen lugar para ubicarlo es justo e despus del cdigo del mtodo jbInit() y justo antes del suceso e o e jMenuFileExit actionPerformed(). // Abrir el archivo con nombre; lee el texto del archivo al jTextArea1; informar a la barra de estado. void openFile(String leName) { try { // Abrir un archivo con nombre. File le = new File(leName); // Obtener el tamao del archivo abierto. n int size = (int)le.length(); // Asignar cero a un contador para realizar un recuento de // los caracteres que se han le del archivo. do int chars read = 0; // Crear un lector de entrada basado en el archivo, para leer los datos. // FileReader gestiona las conversiones de cdigo de caracteres o internacionales. FileReader in = new FileReader(le); // Crea una matriz de caracteres del tamao del archivo, n // para utilizarla como bfer de datos, en el que leer u // los datos del texto. char[] data = new char[size];
127
CAP ITULO 6. DESARROLLO DE NUESTRA APLICACION MEDIANTE JDT, JDK 1.4.1 Y JBUILDER7. Jos Ma Onrubia e // Leer todos los caracteres disponibles en el bfer. u while(in.ready()) // Incrementar el recuento de cada carcter le a do, // y acumularlos en el bfer de datos. u chars read += in.read(data, chars read, size - chars read); } in.close(); // Crear una cadena temporal que contenga los datos, // y asignar la cadena a JTextArea. jTextArea1.setText(new String(data, 0, chars read)); // Muestra el nombre del directorio y archivos abiertos en la barra de estado. statusBar.setText(.Abierto +leName); } catch (IOException e) { statusBar.setText(Error al abrir +leName); }
2. Aada la importacin siguiente a la lista de importaciones de la parte n o superior del archivo: import java.io.*; 3. Haga clic en el manejador del suceso de ArchivoAbrir (jMenuItem2 actionPerformed(ActionEvent)) del panel de estructura para buscarlo rpidamente en el cdigo fuente. a o 4. Reemplace el cdigo fuente en el manejador del suceso de Archio voAbrir if() que conten previamente: a
// Muestra el nombre del directorio y archivos abiertos en la barra de estado. statusBar.setText(.Abierto +jFileChooser1.getSelectedFile().getPath()); // El cdigo debe ir aqu para cargar realmente el texto o // desde el archivo al JTextArea. con este nuevo mtodo openFile(), empleando el nombre de directorio e y archivo concatenados. // Llamar a openFile para intentar cargar el texto desde el archivo al 128 GVA-ELAI-UPM r PFC0074-03
Jos Ma Onrubia e
JTextArea openFile(jFileChooser1.getSelectedFile().getPath()); //pinta el men de nuevo una vez que el elemento se ha seleccionado u this.repaint();
5. Pruebe el programa ahora y vea si funciona. Guarde y ejecute el programa, y abra un archivo de texto en el editor. El editor de textos debe tener algn contenido. u 6. Cierre la aplicacin EditorDeTexto. o Paso 10: Adicin de cdigo a los elementos de men para guardar o o u un archivo Ahora se precisa un cdigo que vuelva a grabar el archivo a disco cuando o se seleccione ArchivoGuardar y ArchivoGuardar como. Para ello, es necesario aadir una variable de instancia String para n almacenar el nombre del archivo abierto, adems de aadir mtodos para a n e escribir de nuevo el texto en este y en otros archivos.
1. Haga clic en jFileChooser1 en el panel de estructura. Esto le llevar a a la ultima entrada de la lista de declaraciones de variables de instancia (dado que jFileChooser1 fue la ultima declaracin realizada). o 2. Aada las siguientes declaraciones al nal de la lista despus de jFilen e Chooser1: String currFileName = null; //V completa con nombre de archivo. a null signica nuevo / sin t tulo. boolean dirty = false; // True signica texto modicado. 3. Haga clic en el mtodo openFile(String leName) del panel de estruce tura para buscarlo rpidamente en el cdigo fuente. Site el cursor en a o u el mtodo, a continuacin de la l e o nea siguiente que lee el archivo en JTextArea: jTextArea1.setText(new String(data, 0, chars read)); 4. Inserte el siguiente cdigo en esta posicin: o o // Almacenar en cach el nombre de archivo abierto actualmente para e GVA-ELAI-UPM r PFC0074-03 129
CAP ITULO 6. DESARROLLO DE NUESTRA APLICACION MEDIANTE JDT, JDK 1.4.1 Y JBUILDER7. Jos Ma Onrubia e utilizarlo al guardar... this.currFileName = leName; // ...y marcar la sesin de modicacin como borrada o o this.dirty = false; 5. Cree un mtodo saveFile() al que pueda llamar desde el manejador e del suceso de ArchivoGuardar. Puede colocarlo justo despus del e mtodo openFile(). Este mtodo escribe el nombre de archivo en la e e barra de estado al guardar. // Guardar archivo actual; gestionar los que no tienen nombre de archivo; informar a la barra de estado. boolean saveFile() { //Gestionar donde an no exista nombre de archivo. u if (currFileName == null) { return saveAsFile(); } try { // Abrir el archivo del nombre actual. File le = new File (currFileName); // Crear un escritor de salida que escribir ese archivo. a // FileWriter gestiona las conversiones de cdigos de caracteres o internacionales. FileWriter out = new FileWriter(le); String text = jTextArea1.getText(); out.write(text); out.close(); this.dirty = false; // Muestra el nombre del directorio y archivos abiertos en la barra de estado. statusBar.setText(Error al guardar +currFileName); return true; } catch(IOException e) { statusBar.setText(Error al guardar +currFileName); } return false; }
130
Jos Ma Onrubia e
6. Cree el mtodo saveAsFile() al que se llama desde saveFile() si e no existe nombre de archivo actual. Lo utilizar tambin desde el a e men ArchivoGuardar como. Aada el cdigo siguiente justo a u n o continuacin del mtodo saveFile(): o e
// Guardar el archivo actual, preguntando al usuario el nuevo nombre de destino. // Informar a la barra de estado. boolean saveAsFile() { //Utilizar la versin SAVE del cuadro de dilogo, comprobar el valor o a devuelto de Aceptar/Cancelar if (JFileChooser.APPROVE OPTION == jFileChooser1.showSaveDialog(this)) { // Asignar al nombre de archivo actual la seleccin del usuario o // a continuacin realizar un saveFile normal o currFileName = jFileChooser1.getSelectedFile().getPath(); //pinta el men de nuevo una vez que el elemento se ha seleccionado u this.repaint(); return saveFile(); } else { this.repaint(); return false; } }
7. Vuelva al diseador y cree un manejador del suceso actionPerformed() n para el elemento de men ArchivoGuardar (jMenuItem3). Inserte u el siguiente cdigo: o
//Gestionar el elemento de men ArchivoGuardar. u saveFile();
8. Cree un manejador de sucesos actionPerformed() para el elemento de men ArchivoGuardar como (jMenuItem4) e introduzca este cdigo: u o //Gestionar el elemento de men ArchivoGuardar como. u saveAsFile(); 9. Guarde y compile el archivo. Ejectelo e intente guardar texto en un u GVA-ELAI-UPM r PFC0074-03 131
CAP ITULO 6. DESARROLLO DE NUESTRA APLICACION MEDIANTE JDT, JDK 1.4.1 Y JBUILDER7. Jos Ma Onrubia e archivo.
10. Cierre la aplicacin EditorDeTexto. o
Con estos pasos se tiene un conocimiento bsico de cmo crear un GUI a o (graphical user interface) que es nuestro punto de base para construir nuestra aplicacin DICOM. o
6.3.
6.3.1.
Uso de librer JDK 1.4.1 as

Introduccin e instalacin. o o
Para poder realizar aplicaciones Java, se necesitan las librer propias de as Java, las cuales se pueden descargar directamente de la pgina web de sun. a En nuestro caso se ha trabajado con la ultima versin actual JDK 1.4.1 que o se ha podido descargar de http://java.sun.com/j2se/1.4.1/download.html. Una vez descargado se procede a la instalacin, la cual es muy sencilla. o Con esta descarga se consigue el archivo j2re-1 4 0 03-windows-i586-i.exe el cual con slo ejecutarlo nos instala la coleccin de librer de Java JDK o o as 1.4.1 las cuales estn listas para ser usadas. a En nuestro proyecto de JBuilder bastar realizar un import del paquete a o clase querida para poder trabajar con sus clases o mtodos, como ya se e entiende que se sabe. Para poder trabajar con JDK es muy importante poder continuamente ver el conjunto de paquetes y de clases (API )para poder buscar y encontrar lo necesitado en cada momento. Esto se ha conseguido con tener constantemente contacto con la pgina web de sun que muestra esta API. a La gura 6.14 muestra la organizacin de esta API de Java: o
132
Jos Ma Onrubia e
6.3. USO DE LIBRER IAS JDK 1.4.1
Figura 6.14: API de JDK 1.4.1. Tambin debido a la gran amplitud de paquetes, clases y mtodos es e e muy importante contar con la posibilidad de un grupo de noticias en el cual poder mostrar nuestras dudas, sugerencias, ver preguntas frecuentes e intentar consultar nuestros problemas. Se ha contado con el grupo news.upm.es para dichas consultas. Esta API es altamente extensa por lo que para usar lo que uno necesita el mayor problema es encontrarlo, por lo que, como hemos dicho es muy importante tener un buen servicio de consulta.
6.3.2.
Estructura de JDK 1.4.1.
Los paquetes usados de esta API para nuestra aplicacin son unos pocos, o por lo que nos vamos a centrar en comentar someramente slo stos debido o e a lo expuesto anteriormente referente a la amplitud. Se sealan tambin n e clases e interfaces importantes de cada paquete:
133
CAP ITULO 6. DESARROLLO DE NUESTRA APLICACION MEDIANTE JDT, JDK 1.4.1 Y JBUILDER7. Jos Ma Onrubia e java.awt Contiene todas las clases para la creacin de interfaces de usuario y para o la representacin grca de imgenes. Hay objetos de interfaz de usuario o a a como un botn o un scrollbar, en la terminolog awt, un componente. o a La clase Component es la ra de todos los componentes awt. Ver la clase z Component para una descripcin detallada de las propiedades las que todos o los componentes awt comparten. Algunos componentes lanzan eventos cuando un usuario interacta u sobre los componentes. La clase AWTEvent y sus subclases se usan para representar los acontecimientos los que awt componentes pueden lanzar. Ver AWTEvent para una descripcin del modelo de eventos de awt. o Un container es un componente que puede contener componentes y otros contenedores. Una container tambin puede tener a un gerente de disposie cin que controla la colocacin visual de componentes en el contenedor. o o El paquete de programas de awt contiene a varios gerentes de disposicin o clases y un interfaz para construir su propio gerente de disposicin. Ver las o clases Container y LayoutManager para ms informacin. a o Clases importantes:
AWTEvent: La clase de eventos ra para todos los eventos AWT. z BorderLayout: Un BorderLayout pone de un contenedor, arreglando y redimensionando su componente para tener cinco regiones: norte, sur, este, oeste, y centro. Component: Un componente es un objeto que tiene una representacin o grca que puede ser mostrada sobre la pantalla y que puede interaca tuar con el usuario. Container : Un Abstract Window Toolkit(AWT) el objeto de contenedor es un componente que puede contener otros componentes AWT. Graphics: La clase Graphics es la clase abstracta base para todos los contextos de grcos que permiten a una aplicacin dibujar sobre los a o componentes que estn comprendidos sobre varios dispositivos, as coa mo sobre imgenes fuera de pantalla. a GridBagLayout:La clase GridBagLayout es un gerente de disposicin o exible que alinea componentes verticalmente y horizontalmente, sin requerir que que los componentes fueran del mismo tamao. n 134 GVA-ELAI-UPM r PFC0074-03
Jos Ma Onrubia e
Image: La clase abstracta la Imagen es la superclase de todas las clases que representan imgenes grcas. a a MediaTracker : La clase MediaTracker es una clase de utilidad para rastrear el estado de un nmero de objetos media. u ... java.awt.event Proporciona interfaces y clases para ocuparse de los diferentes tipos de eventos lanzados por los componentes awt. Ver la clase java.awt.event para ms detalles sobre el modelo de acontecimiento awt. Los acontecimientos a se lanzan por fuentes de eventos. Un oyente de eventos (event listener) se registra con una fuente de evento para recibir noticaciones sobre los eventos de un tipo particular. Este paquete de programas dene eventos y oyentes de eventos, as como adaptadores de oyente de acontecimiento, que son clases que convienen para hacer ms fcil el proceso de escribir a a a oyentes de acontecimiento.
ActionEvent: Un evento que indica que ocurri una accin denida de o o un componente. ComponentAdapter : Una clase de adaptador abstracta para recibir eventos de componentes. ComponentEvent: Un acontecimiento de bajo nivel que indica que un componente se ha movido, el tamao cambiado o la visibilidad camn biada (tambin es la clase de ra para otros acontecimientos de nivel e z componente). MouseEvent: Un evento que indica que una accin de ratn ocuro o ri en un componente. Ver tambin MouseMotionAdapter y Mouseo e WheelEvent. Interfaz ActionListener : El interfaz de oyente (listener interface) para recibir eventos de accin. o ... java.awt.image Proporciona clases para la creacin y la modicacin de imgenes. Las o o a imgenes son procesadas usando un marco que corre que implica a una a image producer, ltros de imagen opcionales y una image consumer. Este marco hace posible para progresivamente dar una imagen mientras este se GVA-ELAI-UPM r PFC0074-03 135
CAP ITULO 6. DESARROLLO DE NUESTRA APLICACION MEDIANTE JDT, JDK 1.4.1 Y JBUILDER7. Jos Ma Onrubia e trae y se genera. Adems, el marco permite un uso desechar el almacenaje a usado por una imagen y regenerarlo en cualquier momento. Este paquete proporciona a un nmero de image producers, consumers, y ltros que se u pueden congurar para nuestras necesidades de procesamiento de imgenes. a Clases importantes de este paquete son:
BueredImage: La subclase BueredImage describe una Imagen con un bufer accesible de datos de imagen. ColorModel : La clase abstracta de ColorModel encapsula los mtodos e para traducir un valor de pixel a un componente de color (por ejemplo, rojo, verde, y azul) y un componente alfa. PixelGrabber : La clase PixelGrabber implementa un ImageConsumer que puede ser atado a una Imagen o a un objeto ImageProducer para coger los datos de los p xeles de esa imagen. ... java.io Proporciona la entrada y salida del sistema a travs de corrientes de e datos, serializacin y el archivo de sistema. Si se pasa un argumento nulo o a un constructor o a algn mtodo de cualquier clase o interfaz en este u e paquete har que un NullPointerException se lance. a Clases importantes:
BueredInputStream: Un BueredInputStream agrega la funcionalidad a otra entrada corriente conocida, la capacidad de bufer la entrada y apoyar la seal y poner resetear mtodos. n e BueredOutputStream: La clase implementa un bueredOutputStream. FileInputStream: coge bytes de entrada desde un archivo y lo pasa a un archivo de sistema. FileOutputStream: es una corriente de salida para la escritura de datos a un File o a un FileDescriptor. ... 136 GVA-ELAI-UPM r PFC0074-03
Jos Ma Onrubia e java.lang.Object
Proporciona las clases que son fundamentales para el diseo del lenguaje n de programacin Java. Las clases ms importantes son el Object, que es la o a ra de la jerarqu de clase, y la Class. z a Con frecuencia es necesario representar un valor de tipo primitivo como si esto fuera un objeto. Las clases Boolean, Character, Integer, Long, Float, y Double sirven para este objetivo. Un objeto tipo Doble, por ejemplo, contiene un campo cuyo tipo es doble, representando aquel valor de tal modo que una referencia a ello puede ser almacenada en una variable de tipo de referencia. Estas clases tambin proporcionan unos mtodos para la e e conversin entre valores primitivos, as como mtodos tan estndar como o e a equals y hashCode. La clase Void es una clase no instanciable que sostiene una referencia a un objeto Clase que representa el tipo primitivo void. La clase Math proporciona comnmente funciones matemticas como u a el seno, el coseno, y la ra cuadrada. Las clases String y StringBuer z proporcionan de modo similar operaciones comnmente usadas sobre u cadenas de caracteres. Las clases ClassLoader, Process, Runtime, SecurityManager, y System provorcionan .operaciones de sistemaque manejan la carga dinmica de a clases, crean procesos externos, reciben preguntas como la hora del d y a, la ejecutan una pol tica de seguridad. La clase Throwable abarca los objetos que pueden ser lanzados por la declaracin de lanzamiento. Las subclases de Throwable representan errores o y excepciones. Clases importantes: Boolean, Byte, Character, Class, Integer, Long, Math, Double, Float, Process, Runtime, String ...
javax.swing Proporciona un juego fcil de usar de componentes (para GUIs) que, al a mximo grado posible, trabajan sobre todo tipo de plataformas. a Clases importantes: JButton, JComboBox, JFileChooser, JFrame, JLabel, JPanel, JScrollPane, ... GVA-ELAI-UPM r PFC0074-03 137
6.3.3.
Conguracin de JDK en JBuilder. o
Por defecto al estar en un proyecto de JBuilder se usa (en esta versin o 7) la API 1.3 de JDK. En el caso de que queramos usar otra versin por la o causa que sea (en nuestro caso queremos cambiar a JDK 1.4.1 para poder usar unas determinadas funciones)se debe proceder de la siguiente manera:
1. Herramientas
2. Congurar JDK...
Figura 6.15: Congurar JDK.
3. En la pantalla siguiente se debe mostrar el camino de la nueva API mediante el botn Cambiar. o 138 GVA-ELAI-UPM r PFC0074-03
Jos Ma Onrubia e
6.4. INSTALACION DE JDT EN JBUILDER.
Figura 6.16: Nuevo camino de JDK.
De esta forma cambiar amos la API para poder trabajar con las nuevas actualizaciones de sta. De todas formas a nuestro nivel es casi intil e u trabajar con la versin ultima y nos podr o amos conformar con versiones anteriores sin mermar nuestras posibilidades.
6.4.
Instalacin de JDT en JBuilder. o
Debido a que se necesita trabajar con estas librer de DICOM, es as necesario indicarle al programa cmo usarlas, es decir, instalarlas. o Este proceso, que ser equivalente para cualquier tipo de librer consta a as, de las siguientes partes:
1. En la barra de herramientas seleccionar Proyecto. 2. Propiedades de proyecto. GVA-ELAI-UPM r PFC0074-03 139
Figura 6.17: Propiedades de proyecto.
3. En la pantalla siguiente en la pestaa Vias de acceso y dentro de sta n e en la pestaa Bibliotecas necesarias y pulsando el botn Aadir y n o n en Nuevo y mediante el asistente de bibliotecas se aade las nuevas n bibliotecas: 140 GVA-ELAI-UPM r PFC0074-03
Jos Ma Onrubia e
6.4. INSTALACION DE JDT EN JBUILDER.
Figura 6.18: Propiedades de proyecto.
Aadir. n
Seleccionar camino: en nuestro caso D:/classpath/jdt.jar y D:/classpath/jdt.key como podemos ver en la gura. GVA-ELAI-UPM r PFC0074-03 141
Figura 6.19: Propiedades de proyecto. 4. Hecho sto en nuestro cdigo podremos ya incluir nuestros nuevos e o paquetes como por ejemplo: import com.archimed.dicom.*; y una vez hecho sto podremos denir nuevos objectos de estas nuevas e clases de DICOM como por ejemplo: private SOPClass sopClass = new SOPClass(); Por lo que ya tenemos instaladas nuestras librer JDT y podemos as empezar a trabajar con ellas.
6.5.
6.5.1.
Implementacin de nuestra aplicacin. o o

Introduccin. o
Una vez instalados y comprendidos todos nuestros recursos para desarrollar la aplicacin DICOM, se comienza a implementarla. o 142 GVA-ELAI-UPM r PFC0074-03
Jos Ma Onrubia6.5. IMPLEMENTACION DE NUESTRA APLICACION. e
6.5.2.
Estructura de la GUI.
Lo primero, y a travs de los componentes de javax.swing es construir un e marco que concuerde con las expectativas. En nuestro caso se ha dispuesto varias pestaas que albergan paneles mediante las clases JTabbedPane y n JPanel para que quede una estructura de interfaz como la representada en la gura 6.20.
Figura 6.20: Estructura bsica de la aplicacin. a o Y de esta forma poder poner en cada panel lo deseado. En nuestro caso se ha dispuesto de los paneles que aparecen en la gura: panelProcesamiento, panelVisorDicom, panelCrearDicom y panelCliente-Servidor (tambin se e han incluido dos paneles para posibles funciones posteriores). Vamos a ver para que sirven cada uno de estos paneles y una pequea n muestra de cmo han sido implementados. o
143
6.5.3.
Panel VisorDicom.
Este panel sirve para poder visualizar todo tipo de archivos DICOM: archivos comprimidos, no comprimidos, en color, en escala de grises y de una o varias imgenes, tambin es capaz de insertar datos de texto en los a e campos ya existentes de un archivo DICOM y tambin de crear nuevos e campos e insertar datos en ellos. Se ha conseguido a travs de la implementacin de una clase llamada e o Imagedos en el proyecto de JBuilder, la cual nos va a permitir en ultima instancia ser capaces de visualizar la imagen de los archivos DICOM. Se recomienda ver el cdigo fuente de esta clase. o
Figura 6.21: Panel Visor DICOM. Visualizar datos: texto e imgenes. a Esta clase tiene un constructor de la forma public Imagedos(DicomObject dcm) al cual vamos a llamar y a pasarle un objeto de la clase DicomObject. Este parmetro que se pasa es un archivo DICOM sacado de archivos a .dcm (formato DICOM) los cuales se han conseguido de pginas web que a 144 GVA-ELAI-UPM r PFC0074-03
Jos Ma Onrubia6.5. IMPLEMENTACION DE NUESTRA APLICACION. e dejan bajar ejemplos de archivos DICOM. La forma de pasar de un archivo .dcm a una instancia de la clase DicomImage (subclase de DicomObject, ver API de JDT) se consigue mediante este cdigo, implementado en nuestra clase principal MarcoCuao tro.java en el mtodo open(): e
....... if (JFileChooser.APPROVE OPTION == jFileChooser1.showOpenDialog(this)) openFileName = jFileChooser1.getSelectedFile().getAbsolutePath(); f = new File(openFileName); n = new FileInputStream(f ); bis = new BueredInputStream(n); dcm.read(bis, true); ....... en donde con la primera l nea de cdigo conseguimos que se abra un o selector de archivos, donde elegimos el archivo DICOM deseado (ver clase JFileChooser en la API de JAVA). Con la l nea openFileName = jFileChooser1.getSelectedFile().getAbsolutePath(); conseguimos guardar el camino completo del archivo, el cual necesitamos para crear un objeto de la clase File, depus uno de la clase FileInputStream y nalmente uno de e la clase BueredInputStream para poder usar el mtodo read de la clase e DicomObject, el cual lee desde el BueredInputStream el archivo DICOM. De esta forma tenemos en dcm (DicomImage dcm = new DicomImage();) nuestro archivo DICOM .dcm. Para sacar los datos de texto de este archivo DICOM usamos:
ReSystemOut systemArea = new ReSystemOut(areaTextoDatosDicom); dcm.dumpVRs(systemArea,true); donde la clase ReSystemOut es una implementacin realizada para poder o mostrar estos datos en un objeto de la clase JTextArea, que es lo que nos interesa para poder visualizar estos datos en nuestro GUI (en este caso en la instancia areaTextoDatosDicom de JTextArea: ver cdigo de la clase o ReSystemOut). El paso siguiente es coger los datos reunidos en este objecto. Para
145
CAP ITULO 6. DESARROLLO DE NUESTRA APLICACION MEDIANTE JDT, JDK 1.4.1 Y JBUILDER7. Jos Ma Onrubia e ello necesitamos la clase Imagedos. Llamamos a su constructor public Imagedos(DicomObject dcm) con lo que tenemos un objeto de esta clase:
imagedcm = new Imagedos(dcm); Mediante el mtodo getBueredImage(int numeroDeImagen) podemos e sacar las imgenes y poderlas visualizar de esta forma: a
imagen = imagedcm.getBueredImage(numeroImagen); etiquetaMostrarImagen.setIcon(new ImageIcon(imagen)); donde etiquetaMostrarImagen es un objeto de la clase JLabel la cual mediante el mtodo setIcon(ImageIcon a) puede mostrar nuestras imgenes. e a La instancia de la clase ImageIcon se crea como se ve arriba mediante su constructor (ver clase en API).
Hacer zoom in o zoom out. Una vez visualizada la imagen, se ha dotado de la posibilidad de hacer zoom de dos formas diferentes: 1. Botones Zoom In y Zoom Out:
Figura 6.22: Zoom mediante botones Zoom In y Zoom Out. La implementacin bsica es (para el caso de Zoom In): o a int altura = zoomImagen.getHeight(null); int anchura = zoomImagen.getWidth(null); zoomImagen = imagen.getScaledInstance(anchura*2,altura*2,imagen.SCALE DEFAULT); etiquetaMostrarImagen.setIcon(new ImageIcon(zoomImagen)); donde con getHeight y getWidth (mtodos de la clase Image) sacamos e la altura y anchura de la imagen zoomImagen. Y mediante el mtodo e 146 GVA-ELAI-UPM r PFC0074-03
Jos Ma Onrubia6.5. IMPLEMENTACION DE NUESTRA APLICACION. e getScaledInstance hacemos una imagen a escala de la anterior, para lo que necesitamos nuevos datos de alto/ancho, que despus con el mtodo e e antes visto setIcon podemos visualizamos en el mismo objeto JLabel, etiquetaMostrarImagen.
2. Mediante eventos de ratn: o
Figura 6.23: Zoom mediante cliqueos de ratn. o
En este caso se ha conseguido que mediante dos cliqueos con el ratn o sobre la imagen se haga zoom IN de la zona selecionada. Se hace, creando para la JLabel deseada (etiquetaMostrarImagen), un cdigo que sea capaz o de recoger un evento, en este caso el chasquido del ratn. La implementacin o o es:
etiquetaMostrarImagen.addMouseListener(new MouseAdapter() GVA-ELAI-UPM r PFC0074-03 147
CAP ITULO 6. DESARROLLO DE NUESTRA APLICACION MEDIANTE JDT, JDK 1.4.1 Y JBUILDER7. Jos Ma Onrubia e { public void mousePressed(MouseEvent e) { try if(x1==-1&y1==-1) { x1 = e.getX(); y1 = e.getY(); } else if(x2==-1&y2==-1) { x2 = e.getX(); int ancho = Math.abs(x2) - Math.abs(x1); int alto = y2 - y1; ancho = Math.abs(ancho); alto = Math.abs(alto); zoomBueredImagen = ImageToBueredImage.toBueredImage(zoomImagen); if((x1>x2)&(y1>y2)) { zonaBImagen= zoomBueredImagen.getSubimage(x2,y2,ancho,alto); } if((x1<x2)&(y1>y2)) { zonaBImagen= zoomBueredImagen.getSubimage(x1,y2,ancho,alto); } if((x1<x2)&(y1>y2)) { zonaBImagen= zoomBueredImagen.getSubimage(x1,y1,ancho,alto); } if((x1>x2)&(y1<y2)) { zonaBImagen= zoomBueredImagen.getSubimage(x2,y1,ancho,alto); } Image zonaZoomImage = zonaBImagen.getScaledInstance(4*ancho,4*alto,Image.SCALE DEFAULT); Marco PantallaCompleta marcoZonaZoom = new Marco PantallaCompleta(zonaZoomImage); Dimension dlgSize = marcoZonaZoom.getPreferredSize(); Dimension frmSize = getSize(); Point loc = getLocation(); marcoZonaZoom.setLocation((frmSize.width - dlgSize.width) / 2 +
148
Jos Ma Onrubia6.5. IMPLEMENTACION DE NUESTRA APLICACION. e loc.x, (frmSize.height - dlgSize.height) / 2 + loc.y); marcoZonaZoom.setModal(true); marcoZonaZoom.pack(); } } }); donde se crea un listener de evento MouseEvent el cual nos permite saber la posicin del ratn en el momento que ste es pulsado, por lo que o o e podemos sacar la zona de inters (mediante los mtodos getX() y getY() e e ) y donde Marco PantallaCompleta es una clase que permite visualizar imgenes en un panel aparte. Se sugiere ver cdigo de esta ultima clase. a o Tambin, si se quisiese detectar, por ejemplo el movimiento del ratn sobre e o un componente o el rotar de la rueda central del ratn se pueden usar clases o del mismo paquete MouseAdapter, MouseEvent, MouseMotionAdapter o/y MouseWheelEvent para tener efectos homlogos a lo anteriormente visto. o
Visualizar todas las imgenes. a Ya se ha comentado la forma de conseguir visualizar los datos de la imagen de los archivos DICOM, pero tambin sabemos que un archivo e DICOM puede contener ms de una imagen, por lo que debemos ser capaces a de visualizarlas todas y cada una de ellas. Al abrir un archivo DICOM se muestra en pantalla (en una instancia de la clase JLabel) la primera imagen y en el caso de que haya ms de a una imagen en dicho archivo, los botones Siguiente, Anterior y Seguidas realizarn las funciones siguientes. a
1.- Botones Siguiente y Anterior :
Figura 6.24: Botones Anterior y Siguiente GVA-ELAI-UPM r PFC0074-03 149
CAP ITULO 6. DESARROLLO DE NUESTRA APLICACION MEDIANTE JDT, JDK 1.4.1 Y JBUILDER7. Jos Ma Onrubia e Estos dos botones permiten ver, si existe, la imagen siguiente o la anterior como indica su nombre. La implementacin es muy sencilla. Primero, se ve o si hay ms de una imagen mediante la captura del dato del objeto DICOM a dcm.getI(DDict.dNumberOfFrames) (ver pgina 66) y si existe, se muestra a en pantalla. La parte importante de esta implementacin es: o
void botonImagenSiguiente actionPerformed(ActionEvent e) { ..... ..... numeroImagen++; imagen=imagedcm.getBueredImage(numeroImagen); etiquetaMostrarImagen.setIcon(new ImageIcon(imagen)); ..... ..... }
Donde imagedcm es un objeto de la clase Imagedos que puede coger la imagen de nmero seleccionada mediante el int numeroImagen (Ver u implementacin de Imagedos.java). Se visualiza como antes. o 2.- Botn Seguidas: o
Figura 6.25: Botn Seguidas o Se basa en lo anterior, pero se consigue que las imgenes pasen una detrs a a de otra (formando una especie de pel cula por supuesto en el caso de que haya ms de una). La pel a cula se para si se pulsa con el ratn sobre el panel o donde aparece esta secuencia. Se va a ver una parte importante de la implementacin: o 150 GVA-ELAI-UPM r PFC0074-03
void botonImagenesSeguidas actionPerformed(ActionEvent e) { ..... ..... Image [] secuencia = new Image[dcm.getI(DDict.dNumberOfFrames)]; for(int n=0;ndcm.getI(DDict.dNumberOfFrames);n++) {); secuencia[n]=imagedcm.getBueredImage(n); System.out.println(n); } cargado = true; ImageSequenceTimer controller = new ImageSequenceTimer(); controller.secuencia(secuencia,dcm.getI(DDict.dNumberOfFrames)); ..... ..... } donde, como se puede ver, se cargan todas las imgenes en un array de a Images y ms tarde se crea una instancia de la clase ImageSequenceTimer a con la cual se crea el panel donde se va a visualizar la secuencia. Ver implementacin de la clase ImageSequenceTimer. o
Guardar imgenes como JPEG. a
Figura 6.26: Botn Guardar JPEG o Se puede guardar la imagen visualizada en formato JPG mediante las posibilidades de JDK 1.4.1. Esta funcin slo se encuentra en esta vero o sin de la API JAVA, por lo que aqu vemos el porqu del uso de esta versin. o e o Para implementar esto necesitamos importar el paquete:
151
import javax.imageio.*; debido a que en ste se encuentra lo buscado, que es el mtodo de la clase e e javax.imageio.ImageIO que nos permite guardar los datos de una instancia de la clase Image en un archivo de formato JPEG. La implementacin o esencial es:
void botonGuardarIamgenComoJpg actionPerformed(ActionEvent e) { ..... ..... if (JFileChooser.APPROVE OPTION == jFileChooser1.showSaveDialog(this)) { String salvarJPG = jFileChooser1.getSelectedFile().getAbsolutePath(); FileOutputStream salvar = new FileOutputStream(salvarJPG); File save = new File(salvarJPG); BueredOutputStream salida = new BueredOutputStream(salvar); javax.imageio.ImageIO.write(imagen,JPEG,save); } ..... ..... } donde la l nea importante es javax.imageio.ImageIO.write(imagen,JPEG,save); que realiza la funcin deseada. o
Meter y modicar datos de texto en el archivo DICOM. En un archivo DICOM, como sabemos tenemos datos de imagen y tambin de texto, es decir el nombre del paciente, que aparato ha realizado e la captura de la imagen ... La funcin, que se ha hecho para esta GUI y o para este panel, es la capacidad de poder aadir datos de texto al archivo n visualizado. Esto se puede hacer de dos formas diferentes. Se puede insertar datos en campos ya existentes, como el nombre del paciente, o se puede crear nuestro propio campo como por ejemplo nmero de molculas infectadas. u e Del primer tipo se han dispuesto una serie de campos, los cuales pueden 152 GVA-ELAI-UPM r PFC0074-03
Jos Ma Onrubia6.5. IMPLEMENTACION DE NUESTRA APLICACION. e ser vlidos o no. En este aspecto deben ser los profesionales de la medicina a los que deben suministar informacin para saber los datos que quieren o insertar para poder adaptarnos a ellos. Ya se vi de que manera se puede visualizar todos los datos del archivo o DICOM (ver pginas 71 y 145 en seciones 4.2.2 y 6.5.3 respectivamente); a aqu vamos a cambiar o entrar nuevos datos en determinados campos y podremos visualizar si estas modicaciones se llegan a producir. Para sto se han dispuesto dos instancias de la clases JComboBox, dos e botones de la clase JButton para insertar y para ver lo insertado y de dos objetos JTextArea siendo stas las zonas de visualizacin. Todo esto se e o puede ver en la gura 6.27
Figura 6.27: Zona de insertar datos. La forma de implementar esto es creando dos instancias de la clase JComboBox con los campos que tengan que aparecer segn lo comentado u ms arriba: a private JComboBox jComboBox1 = new JComboBox(opcionesCombobox); siendo en este caso opcionesCombobox : String[] opcionesCombobox = {dAdditionalPatientHistory ,dBeamName,dBitsAllocated,dBodyPartExamined,dContrastAllergies ,dHistogramData,dImageComments,dInterventionDrugName,dModality ,dPatientName,dPixelData,dROIArea,dSeriesNumber,dSmokingStatus ,dNumberOfFrames};
153
CAP ITULO 6. DESARROLLO DE NUESTRA APLICACION MEDIANTE JDT, JDK 1.4.1 Y JBUILDER7. Jos Ma Onrubia e por lo que al pinchar sobre la echa del combobox, aparecen todos estos campos. Ahora hay que interconectarlos para que al seleccionar uno y escribir sobre las JTextArea se inserte y visualicen los datos. Esto se consigue, a grandes rasgos, mediante esta codicacin: o
Para insertar: void botonInsertarDato actionPerformed(ActionEvent e) { try { String opcion = (String)jComboBox1.getSelectedItem(); String dato = areaTextoInsertarDato.getText(); if(opcion==dPatientName) dcm.set(DDict.dPatientName, new Person(dato)); ..... donde new Person(dato) es el dato del nombre del paciente que se inserta en el campo del archivo DICOM DDict.dPatientName. Hecho esto, el dato estar en el objeto DicomImage pero no todav en a a el archivo .dcm, para lo que se implementa estas otras l neas de cdigo: o FileOutputStream save = new FileOutputStream(openFileName); dcm.write(save,true); siendo write un mtodo de la clase DicomObject que lo que hace es e escribir a travs de un FileOutputStream todos los datos de la instancia e DicomImage en un archivo .dcm que, si no existe, crea uno. Para ver lo insertado: void botonVerDato actionPerformed(ActionEvent e) { String opcion2 = (String)jComboBox2.getSelectedItem(); if(opcion2==dPatientName) { String cadena = dcm.getS(DDict.dPatientName); areaTextoVerDato.setText(dcm.getS(DDict.dPatientName)); ..... Para ver que el funcionamiento de lo anterior es correcto se puede volver
154
Jos Ma Onrubia6.5. IMPLEMENTACION DE NUESTRA APLICACION. e a abrir el archivo DICOM y se podr observar que el nombre del paciente a ha cambiado o aparece cosa que antes no har La gura siguiente pretende a. servir de ejemplo de lo descrito.
Figura 6.28: Ver funcionamiento.
Cmo a adir campos nuevos al archivo DICOM o n La otra posibilidad, como se ha comentado, es la de insertar nuestros propios campos. Se ha visto cmo insertar datos en los campos del archivo DICOM o existentes ya, como el sexo del paciente, nombre del fabricante, ID del paciente, etc, pero es muy importante ser capaces de crear nuestros propios campos, como por ejemplo el nmero de virus, diagnstico del mdico, y en u o e denitiva, los que se crean convenientes. Para ello se han dispuesto en la GUI ciertos botones (gura 6.29) que son capaces hacer este servicio.
155
CAP ITULO 6. DESARROLLO DE NUESTRA APLICACION MEDIANTE JDT, JDK 1.4.1 Y JBUILDER7. Jos Ma Onrubia e Se tiene la posibilidad de crear campos donde se albergan datos de tipo Integer o datos de tipo String, es decir, campos para datos numricos y e campos para datos de texto.
Figura 6.29: Botones para campos nuevos. El cdigo bsicamente es: o a void jButton6 actionPerformed(ActionEvent e) { ....... DDictEntry entrarDDict1 = new DDictEntry(new Integer(campoGrupoNumero.getText()) .intValue(), new Integer (campoElementoNumero.getText()).intValue(), DDict.tUS,campoNuevoNumero.getText(), 1); diccionario.addEntry(entrarDDict1); dcm.set ge(new Integer(campoGrupoNumero.getText()).intValue(), new Integer(campoElementoNumero.getText()).intValue(),new Integer(numero.getText())); ....... } Como se ve es la implementacin que se ejecuta en el momento en que el o 156 GVA-ELAI-UPM r PFC0074-03
Jos Ma Onrubia6.5. IMPLEMENTACION DE NUESTRA APLICACION. e botn en cuestin es pulsado. o o Lo primero que se hace es crear una instancia de la clase DDictEntry. Al pasar los parmetros vistos jamos el nmero de grupo, el nmero de a u u elemento, la descripcin del campo y el tipo de dato DICOM que se puede o meter en ste campo. Ver clases DDictEntry y DDict en la API de JDT la e clase DDictEntry para ms detalles. a Una vez hecho esto, creamos un objeto de la clase DDict, en la cual vamos a insertar nuestro nuevo campo por medio del mtodo addEntry(DDictEntry e a). En este momento tenemos la posibilidad de poder meter en el objeto de la clase DicomObject (dcm) el nuevo dato mediante el mtodo e set ge(grupo,elemento,dato), que en este caso debe ser un Integer ya que el tipo US DICOM es tipo Integer en Java (ver conversiones DICOM/JAVA, JAVA/DICOM tablas en pginas 67 y 68). a Se puede comprobar que el nuevo campo se inserta bien:
Figura 6.30: Comprobar insercin de nuevo campo. o GVA-ELAI-UPM r PFC0074-03 157
CAP ITULO 6. DESARROLLO DE NUESTRA APLICACION MEDIANTE JDT, JDK 1.4.1 Y JBUILDER7. Jos Ma Onrubia e Para el caso de insertar un campo que alberge un dato de tipo String se ha procedido de la misma forma: void jButton5 actionPerformed(ActionEvent e) { ....... DDictEntry entrarDDict2 = new DDictEntry(new Integer(campoGrupoTexto.getText()) .intValue(), new Integer (campoElementoTexto.getText()).intValue(), DDict.tST,campoNuevoTexto.getText(), 1); diccionario.addEntry(entrarDDict2); dcm.set ge(new Integer(campoGrupoTexto.getText()).intValue(), new Integer(campoElementoTexto.getText()).intValue(),new Integer(numero.getText())); ....... } donde lo unico que cambia es el tipo de dato que vamos a insertar, por lo que el tercer parmetro que se pasa al constructor de la clase DDictEntry a es DDict.tST, que es lo que indica esto.
6.5.4.
Panel Crear DICOM.
La funcin de este panel es la de poder crear un archivo DICOM a partir o de imgenes de formato jpeg y por supuesto datos de texto. a Los datos de texto como el nombre del paciente, el aparato que hace la imagen, la parte del cuerpo examinada, etc, se insertan de la misma forma que la vista en la seccin 6.5.3 y (pgina 154). Consultar tambin la seccin 4.2.2. o a e o La parte nueva con respecto al panel de visualizacin de archivos DICOM o (pginas 144 hasta 155) es la zona de meter los datos de imgenes nuestras a a en formato jpeg dentro del nuevo archivo DICOM. Los campos de texto a aadir en el archivo DICOM a crear pueden ser n cambiados, como ya se ha visto.
Estructura del panel Crear DICOM. Esta estructura la podemos ver en la gura siguiente:
158
Figura 6.31: Panel Crear archivo DICOM.
Este panel consta de varias partes:
1. Zona de visualizacin de imgenes a insertar (gura 6.32). o a GVA-ELAI-UPM r PFC0074-03 159
Figura 6.32: Imagen a insertar.
2. Zona de insercin de datos de texto (gura 6.33). o 160 GVA-ELAI-UPM r PFC0074-03
Figura 6.33: Datos de texto a insertar.
Insercin de una sla imagen. o o En esta parte vamos a ver la forma de cmo insertar los datos de una o sla imagen. o Lo primero que se hace es visualizar la imagen a insertar en el rea a destinada mediante el botn Abrir imagen y despus mediante los botones o e Monochrome y RGB metemos la imagen segn sea en escala de grises o en u color respectivamente. Al abrir la imagen se graba la imagen en una instancia de la clase Image GVA-ELAI-UPM r PFC0074-03 161
CAP ITULO 6. DESARROLLO DE NUESTRA APLICACION MEDIANTE JDT, JDK 1.4.1 Y JBUILDER7. Jos Ma Onrubia e (Image imagenJPG;) con la que se trabaja de esta manera: 1. Botn Monochrome: o La implementacin de la funcin de este botn es de la forma: o o o void botonCrearDicomGris actionPerformed(ActionEvent e) { ....... String rutaArchivoDicomGuardar = jFileChooser1.getSelectedFile().getAbsolutePath(); int[] pix = image2IntArray(imagenJPG); dcmNueva.set(DDict.dSOPClassUID,1.2.840.10008.5.1.4.1.1.7); dcmNueva.set(DDict.dSOPInstanceUID,1.2.840.10008.5.1.4.1.1.7); dcmNueva.imagePixelData(imagenJPG.getHeight(null),imagenJPG.getWidth(null), 8,8,7,pix); dcmNueva.write(salvar,true); ....... } donde image2IntArray es un mtodo que mediante la clase PixelGrabe ber (ver API JDK) es capaz de coger los datos de la imagen pixel a pixel, por lo que el resultado es un array de int donde se encuentran estos datos. Las dos l neas siguientes se colocan debido a que son datos que se deben encontrar obligatoriamente en un archivo DICOM, ya que sin ellos no es posible crear el archivo. Ms tarde, en nuestra instancia de la clase DicomImage (DicomImage a dcmNueva = new DicomImage();) se insertan estos datos de imagen mediante el mtodo de esta clase imagePixelData(int las, int columnas, int e planarConf, int[] pixelData) (ver API JDT). Tambin se han probado los e mtodos vistos en la seccin 4.2.4 donde, por lo comprobado, slo funcionan e o o los mtodos de DicomObject y DicomImage y no as los mtodos mediante e e ImageProducer. Una vez hecho sto se puede comprobar que los resultados son satisface torios al ir al panel VisorDicom y tratar de abrir el archivo creado, donde podemos ver los resultados siguientes:
162
Figura 6.34: Comprobar la creacin del archivo DICOM en escala de grises. o Vemos que la imagen se ha grabado junto con los datos metidos, en este caso el nombre del paciente, los datos de la imagen y los datos SOP (Service Object Pair).
1. Botn RGB : o Para el caso de la imagen en color se realiza de la misma forma; la diferencia es que se usa otra implemtentacin del mtodo imagePixelData ya o e que es un mtodo sobrecargado y se utiliza debido al cambio de parmetros e a que se pasan a ste: e imagePixelData(int rows, int cols, int planarConf, int[] pixelData); por lo que queda de la siguiente manera: dcmNueva.imagePixelData(imagenJPG.getHeight(null),imagenJPG.getWidth(null), 0,pix); Los resultados se pueden comprobar igualmente visualizando el archivo GVA-ELAI-UPM r PFC0074-03 163
CAP ITULO 6. DESARROLLO DE NUESTRA APLICACION MEDIANTE JDT, JDK 1.4.1 Y JBUILDER7. Jos Ma Onrubia e creado:
Figura 6.35: Comprobar la creacin del archivo DICOM en color. o
Compresin de archivos DICOM (Monochrome). o Se ha visto cmo crear un archivo DICOM de escala de grises, pero al o hacer sto se tiene un problema: el tamao de los archivos es muy grande e n debido a que no se ha realizado ningn tipo de compresin a los datos de u o los p xeles, por lo que el espacio que ocupan es bastante grande. Para ello se ha recurrido a la clase de la API de JDT llamada Compression, la cual proporcina mtodos para realizar compresiones de estos datos. e Para realizar la compresin, como vimos en la seccin 4.2.4, pgina 78, se o o a acta de la siguiente forma: u void botonComprir actionPerformed(ActionEvent e) 164 GVA-ELAI-UPM r PFC0074-03
Jos Ma Onrubia6.5. IMPLEMENTACION DE NUESTRA APLICACION. e { ....... Compression c = new Compression(dcmNueva); c.compress(TransferSyntax.JPEGLossless); ....... } se crea una instancia de la clase Compression (c) que despus usa su e mtodo compress, el cual necesita saber el tipo de compresin a usar. En e o este momento se tiene que decir que el unico tipo de compresin que realiza o este servicio es el sealado arriba, TransferSyntax.JPEGLossless, mientras n que con los otros tipos no consiguen lo buscado con la limitacin de que o funciona slo con imgenes monochrome. o a La diferencia de tamao de un archivo comprimido a uno sin comprimir n es: No comprimido: tamao = X n Comprimido: tamao = X / 2 n Tamao archivo sin comprimir x 2 = Tamao archivo comprimido n n (aproximadamente.) Insercin de varias imgenes. o a Para este caso se ha introducido en un array de Image todas las imgenes a que se quieren insertar en el archivo DICOM. Una vez insertadas, se procede a sacar los datos de p xeles de estas instancias Image. En este caso se van a guardar estos datos en una matriz de bytes en vez de array de int. Teniendo la matriz de bytes (byte[][]), se contina uniendo todos estos u bytes en un slo array de bytes (byte[]) donde van uno detrs de otro. o a Una vez hecho sto se proceder a insertar estos datos en el archivo e a DICOM a crear. Para todo esto se usan diferentes botones que realizan las diferentes funciones vistas antes:
1. Botn No de imgenes: donde se seala el nmero de imgenes que o a n u a vamos a insertar. En el cdigo se da valor a una variable que es o GVA-ELAI-UPM r PFC0074-03 165
CAP ITULO 6. DESARROLLO DE NUESTRA APLICACION MEDIANTE JDT, JDK 1.4.1 Y JBUILDER7. Jos Ma Onrubia e utilizada para saber el nmero de instancias Image que se deben u guardar en el array Image[].
La implementacin es: o
void iniciarArrayImages actionPerformed(ActionEvent e) { imagenSecuencia = new Image [new ger(datoPantalla.getText()).intValue()]; }
Inte-
2. Botn Abrir imgenes a insertar : mediante este botn se van almao a o cenando el array las imgenes, hasta que se almacena la ultima, y es a en este momento cuando aparece un nuevo cuadro que te pregunta por el lugar y el nombre en donde insertar este arhivo DICOM. La implementacin bsica es: o a void botonAbrirImagen actionPerformed(ActionEvent e) { ........ imagenSecuencia[numeroDeImagen] = imagenJPG; numeroDeImagen++; int imagenesTotales = new Integer(datoPantalla.getText()).intValue(); if(numeroDeImagen == imagenesTotales) { byte[][] secuenciaBytes = new byte[imagenesTotales][]; int n,nBytes=0; for(n=0;n<imagenesTotales;n++) { byte[] ver = image2ByteArray(imagenSecuencia[n]); secuenciaBytes[n]=image2ByteArray(imagenSecuencia[n]); } arrayDeArrayDeBytes=secuenciaBytes; byte[] todoJunto = unirBytesArray(secuenciaBytes,imagenesTotales); todosBytesJuntos = todoJunto; if (JFileChooser.APPROVE OPTION == jFileChooser1.showSaveDialog(this)) { try { String rutaArchivoDicomGuardar = jFileChoos166 GVA-ELAI-UPM r PFC0074-03
Jos Ma Onrubia6.5. IMPLEMENTACION DE NUESTRA APLICACION. e er1.getSelectedFile().getAbsolutePath(); ........ dcmNueva.imagePixelData (imagenJPG.getHeight(null), JPG.getWidth(null), 8,8,7,todosBytesJuntos); ........ dcmNueva.write(salvar,true); ........ } } }
imagen-
como se ve en este cdigo, una vez recogidas todas las instancias Image o en el array, se pasa a sacar de cada objeto Image sus datos de p xeles y se reunen en una matriz de bytes llamada arrayDeArrayDeBytes. Una vez hecho esto, se unen esos array de bytes en uno slo mediante o el mtodo unirBytesArray(byte[][] secuencia, int numeroDeImagenes), e el cual es el dato a insertar en nuestro archivo DICOM, donde se recogen todas nuestras imgenes. a
Una vez hecho lo anterior, podemos ver los resultados:
Figura 6.36: Resultados de nuestra secuencia. Comprimir archivo DICOM de varias imgenes monochrome. a Este archivo est sin compresin. Se puede realizar una compresin como a o o la indicada antes (164) y la reduccin de tamao es de la relacin 2 a 1 o n o aproximadamente, es decir el tamao del archivo comprimido es la segunda n parte del archivo sin comprimir.
167
CAP ITULO 6. DESARROLLO DE NUESTRA APLICACION MEDIANTE JDT, JDK 1.4.1 Y JBUILDER7. Jos Ma Onrubia e Igual que lo anteriormente comentado, el unico sistema de compresin so o portado sigue siendo JPEGLossless de estas librer y ms particularmente as a de la clase Compression.
6.5.5.
Panel Procesamiento.
Este panel (gura 6.37) sirve para poder procesar una imagen mediante un algoritmo desarrollado por el GVA. Este panel visualiza la imagen de origen a procesar y ejecuta el procesamiento y cuando acaba ste se e visualiza en el panel de al lado imagen procesada. Para realizar este panel se ha contado con la ayuda de los creadores del algoritmo para poder instalar las librer necesarias. Se a procedido de la as siguiente manera:
Figura 6.37: Panel procesamiento. Introduccin de algoritmo en la aplicacin. o o Pasos a seguir:
168
Jos Ma Onrubia6.5. IMPLEMENTACION DE NUESTRA APLICACION. e 1. Lo primero que se debe hacer es poner en las variables de entorno los caminos para encontrar las librer necesarias: as D:/jmonrubia/AWouter/bin/win32; D:/jmonrubia/AWouter; c:/matlab6p5/bin/win32; Esto signica que antes se ha debido copiar en estas carpetas los archivos solicitados. En la carpeta D:/jmonrubia/AWouter se deben copiar los archivos applylut.dll y dataread.dll. 2. Despus se debe ejecutar el setup mglinstaller.exe que instala las libre er necesarias de Matlab. as 3. Por supuesto se debe D:/jmonrubia/AWouter. copiar el ejecutable en la carpeta
4. Despus se tiene que crear una carpeta donde se ponen las librer e as para slo este algoritmo: o C:/matlab6p5/toolbox/images/images/private y se incluyen en sta e bwlabel1.dll y bwlabel2.dll. Esto es a nivel de sistema. Una vez hecho sto se debe realizar una e implementacin para que este algoritmo se pueda ejecutar desde nuestro o GUI (graphical user interface). Para hacer esto se dan estos pasos: En el panel de procesamiento se han creado dos JLabel donde poner las imgenes de origen y la de salida o procesada. Se ha incluido adems a a una JTextArea para decir el camino y el nombre de la imagen procesada y dos botones, uno para abrir la imagen a procesar y otro para empezar el procesamiento. Esto se puede ver en la gura 6.37. Pasos en JBuider7.0: 1.- Incluir en el proyecto los archivos CntVirRel.exe y les.txt mediante el botn que se muestra en la gura 6.38: o
169
Figura 6.38: Botn para aadir archivos. o n
2.- Se ha implementado de esta forma. En el botn Imagen a tratar (gura 6.39): o void botonSeleccionImagen actionPerformed(ActionEvent e) { ..... fotoEntradaCamino = jFileChooser1.getSelectedFile().getAbsolutePath(); ImageIcon iconoEntrada = new ImageIcon(fotoEntradaCamino); imagenEntrada = iconoEntrada.getImage(); etiquetaImagenEntrada.setIcon(iconoEntrada); String caminoFicheroTxt = les.txt; File lesTxt= new File(caminoFicheroTxt); FileOutputStream chorro = new FileOutputStream(lesTxt); PrintStream escribirEnArchivo = new PrintStream(chorro); escribirEnArchivo.println(fotoEntradaCamino); imagenProcesada = textoImagenSalida.getText(); escribirEnArchivo.println(imagenProcesada); etiquetaSeleccionImagen.setText(fotoEntradaCamino); ......
170
Jos Ma Onrubia6.5. IMPLEMENTACION DE NUESTRA APLICACION. e donde se muestra la imagen de entrada (setIcon) y se escribe el camino de entrada y de salida en el chero les.txt de donde despus con el botn e o que se ve acontinuacin se saca esta informacin. o o
Figura 6.39: Botn para abrir imagen a procesar. o
En el botn Procesar imagen (gura 6.40) bsicamente se codica de la o a siguiente manera: void botonProcesamiento actionPerformed(ActionEvent e) { Process p = Runtime.getRuntime().exec(d:/jmonrubia/AWouter/CntVirRel.exe); int valorRetorno = p.waitFor(); ImageIcon iconoSalida = new ImageIcon(textoImagenSalida.getText()); etiquetaImagenSalida.setIcon(iconoSalida); ..... donde las clases importantes son Process con su mtodo getRune time().exec() para ejecutar en este caso un .exe y tambin el mtodo e e waitFor() que hace que la ejecucin del cdigo se pare hasta que el proceso o o p no naliza. Una vez hecho esto slo falta mostrar la imagen de salida en o pantalla, cosa que ya se estudi en su debido momento (ver seccin 6.5.3 en o o pgina 146). a
Figura 6.40: Botn para procesar imagen. o GVA-ELAI-UPM r PFC0074-03 171
6.5.6.
Panel Cliente/Servidor.
Uno de los mayores objetivos de esta aplicacin es la posibilidad de o poder mandar y recibir los archivos DICOM a travs de la red. Para esta e funcionalidad se ha creado este panel (gura 6.41), el cual permite enviar un archivo en formato DICOM por la red.
Figura 6.41: Panel Cliente/Servidor.
Para la implementacin de este panel se ha insertado en l varias etiqueo e tas y cuatro instancias de la clase JTextArea que se usarn para este servicio. a La implementacin consta de bsicamente: o a
void enviar actionPerformed(ActionEvent e) 172 GVA-ELAI-UPM r PFC0074-03
Jos Ma Onrubia e
6.6. DISTRIBUCION DE LA APLICACION.
{ open(); .......... Storagescu enviar = new Storagescu(servidor,puerto,Tservidor,Tcliente,openFileName); .......... int ok=enviar.store(); if(ok==enviar.STORE OK) etiquetaEnvio.setText(Enviado con xito); e else etiquetaEnvio.setText(Enviado sin xito); e .......... donde los parmetros servidor,puerto,Tservidor,Tcliente,openFileName a corresponden a los datos necesarios para enviar ms tarde el archivo a mediante el mtodo store() de la clase Storagescu, que emplazamos a que e sea estudiada.
6.6.
Distribucin de la aplicacin. o o
6.6.1.
Generacin del archivo ejecutable java. o
Una vez hecha esta versin Beta de nuestra aplicacin DICOM es o o importante poder distribuirla para que sea ejecutada donde sea necesario, que es uno de los objetivos ms importantes. a Contamos con las ventajas de Java, que en este caso concreto es que independientemente del sistema operativo se puede ejecutar la aplicacin. o Para hacer sto se cuenta con un asistente de JBuilder que se llama asise tente Creador de recopilatorios, el cual se puede seleccionar de la forma en que muestra la gura 6.42: GVA-ELAI-UPM r PFC0074-03 173
Figura 6.42: Asistente creador de recopilatorios. Pasos a seguir:
1. Paso 1: seleccionar Aplicacin. o 2. Paso 2: escribir el nombre del ejecutable java.
Figura 6.43: Asistente creador de recopilatorios. Paso2. 174 GVA-ELAI-UPM r PFC0074-03
Jos Ma Onrubia e
6.6. DISTRIBUCION DE LA APLICACION.
3. Paso 3: En este paso se selecciona la opcin de Incluir siempre todas o las clases y recursos necesarios. 4. Paso 4: Lo mostrado en la gura siguiente son las opciones que se eligen.
Figura 6.44: Asistente creador de recopilatorios. Paso3. 5. En los pasos 5,6 y 7 se aceptan las opciones por defecto. Una vez hecho esto se debe compilar el proyecto otra vez, con lo que conseguimos el archivo recopilado en este caso Cuatro.jar.
6.6.2.
Ejecucin del archivo ejecutable java. o
Generado este archivo es posible ejecutar esta aplicacin con la sla o o teniencia de la herramienta de JDK instalada (en este caso 1.4.1). La forma de proceder para poder ejecutar este archivo es muy sencilla. En la l nea de comandos donde se encuentre el archivo se debe escribir: java -jar cuatro.jar con lo que la aplicacin aparece en pantalla. o
175
176
Apndice A e
ESTANDAR DICOM PARTE 1

A.1. Introduccin. o
Descripcin. o ACR (Colegio Americano de Radiolog y NEMA (la Asociacin de a) o Fabricantes Nacional Elctrica) formaron un comit conjunto para desare e rollar un estndar para la imagen digital y las comunicaciones en medicina. a Este estndar (DICOM) ha sido desarrollado segn los procedimientos a u NEMA. Ha sido desarrollado conjuntamente con otras organizaciones de estandarizacin entre las que se incluyen el centro TC251 en Europa o y el JIRA en Japn, contando tambin con la supervisin de otras o e o organizaciones en las que se incluyen IEEE, HL7 Y ANSI en EE.UU. El estndar DICOM est estructurado como un documento dividido en a a varias partes que usan las directrices establecidas en el documento siguiente: - ISO/IEC Directrices, 1989 Parte 3: Esquema y presentacin de Normas o Internacionales. Este documento es una parte del estndar DICOM, que consiste en las a siguientes partes: PS 3.1: Introduccin y descripcin. o o PS 3.2: Estatuto de conformidad. PS 3.3: Deniciones de objeto de informacin (IODs). o PS 3.4: Datos espec cos de clase de servicio. PS 3.5: Estructura de datos y codicacin. o 177
APENDICE A. ESTANDAR DICOM PARTE 1 PS 3.6: Diccionario de datos. PS 3.7: Intercambio de mensajes.
Jos Ma Onrubia e
PS 3.8: Soporte de comunicacin en red para el intercambio de meno sajes. PS 3.9: Soporte para la comunicacin punto a punto para el intercamo bio de mensajes. PS 3.10: Almacenamiento y formato de archivos para el intercambio de datos. PS 3.11: Almacenamiento media de perles de aplicacin. o PS 3.12: Funciones de almacenamiento y formatos media para intercambio de datos. PS 3.13: Soporte para la impresin en una comunicacin punto a punto. o o PS 3.14: Funcin de visualizacin estndar en escala de grises. o o a PS 3.15: Perles de seguridad. PS 3.16: Content mapping resource. Estas partes estn relacionadas, pero son documentos independientes. Su a nivel de desarrollo y el su nivel aprobacin pueden diferenciarse. Se va a ver o el primer documento.
Historia Con la introduccin de la tomograf calculada (CT) seguido por otros o a tipos de imgenes digitales para diagnsticos en los aos 1970, y el empleo a o n creciente de ordenadores en aplicaciones cl nicas, el Colegio Americano de Radiolog (ACR) y la Asociacin de Fabricantes Nacional Elctrica a o e (NEMA) reconoci la necesidad emergente de un mtodo estndar para la o e a transferencia de imgenes y la asociacin de informacin entre dispositivos a o o fabricados por diferentes vendedores. Estos dispositivos producen una variedad de formatos de imagen digitales. El Colegio Americano de Radiolog a (ACR) y la Asociacin de Fabricantes Nacional Elctrica (NEMA) form un o e o comit conjunto en 1983 para desarrollar un estndar que: e a
Promueve la comunicacin de informacin de imgenes digitales, indeo o a pendientemente del fabricante del dispositivo de captura. 178 GVA-ELAI-UPM r PFC0074-03
Jos Ma Onrubia e
A.1. INTRODUCCION.
Facilita el desarrollo y la expansin para archivar las imgenes y para o a sistemas de comunicacin (PACS) que tambin puede servir como ino e terfaz con otros sistemas de informacin de otros hospitales o Permite la creacin de las bases de datos de informacin de diagnstio o o cos que pueden ser solicitados desde una amplia variedad de dispositivos distribuidos geogrcamente. a Las normas no 300-1985 de ACR-NEMA publicada en 1985 era la versin o 1.0. Al estndar le ha seguido seguido dos revisiones: no 1, octubre de 1986 a y no 2, enero de 1988. Las normas no 300-1988 de ACR-NEMA publicada en 1988 era la versin o 2.0. Esta incluy la versin 1.0, las revisiones publicadas, y revisiones o o adicionales. Tambin proporciona el soporte de comandos para dispositivos e de visualizacin, presenta un esquema de jerarqu nuevo de identicacin o a o de una imagen, y aade datos para incrementar la especicidad a la hora n de describir una imagen. Estas publicaciones de normas denieron una interfaz de soporte f sico, un juego m nimo de instrucciones de software, y un juego constante de formatos de datos. El estndar DICOM a El estndar incorpora unas mejoras principales respecto a las versiones a anteriores del estndar: a
1. Se aplica a un ambiente de red. Las versiones anteriores eran aplicables slo a ambientes de punto a punto; para la operacin en un ambiente o o de red una unidad de interfaz de Red (NIU) era requerida. La Versin o 3.0 de DICOM puede soportar los estndares de comunicacin en red a o que se usan en industria, como los protocolos OSI Y TCP/IP. 2. Especica cmo los dispositivos deben cumplir con el estndar para o a que los datos y las instrucciones sean intercambiadas. Las versiones anteriores han sido limitadas a la transferencia de datos, pero la Versin 3.0 DICOM especica, por el concepto de clases de servicio, la o semntica de rdenes y datos asociados. a o 3. Especica los niveles de conformidad. Las versiones anteriores especicaron un nivel m nimo de conformidad. DICOM la Versin 3.0, exo pl citamente, describe como una implementacin debe estructurar una o declaracin de conformidad para seleccionar opciones espec o cas. GVA-ELAI-UPM r PFC0074-03 179
APENDICE A. ESTANDAR DICOM PARTE 1
Jos Ma Onrubia e
4. Est estructurado como un documento dividivo en varias partes. Esto, a facilita la rpida evolucin del estndar simplicando la adicin de rasa o a o gos nuevos. Las directrices ISO que denen como estructurar documentos de multi-partes han sido seguidas en la construccin del estndar o a DICOM. 5. Introduce objetos de informacin expl o citos no slo para imgenes y o a los grcos, tambin para estudios, informes, etc. a e 6. Especica una tcnica establecida para la identicacin unica de e o cualquier objeto de informacin lo que facilita las deniciones inequ o vocas de las relaciones entre objetos de informacin como ellos son ino terpretados a travs de la red. e
A.2.
Alcance y campo de aplicacin. o
El Estndar DICOM facilita la interoperabilidad de un equipo mdico a e visualizador y creador de imgenes especicando: a
un juego de protocolos para que sean cumplidos por los dispositivos. la sintaxis y la semntica de rdenes y de la informacin asociada que a o o puede ser intercambiada usando estos protocolos. la informacin que debe ser suministrada para una realizacin para o o cumpla con el estado de conformidad. El Estndar DICOM no especica: a
los detalles de cualquiera de los rasgos del estndar para que un disa positivo reclamando conformidad para una implementacin. o el juego total de rasgos y funciones de un sistema integrado por un grupo de dispositivos cada uno siguiendo la norma del estndar. a un procedimiento de pruebas y validacin para evaluar de que forma o se cumple con el estndar. a El estndar DICOM pertenece al campo de la informtica mdica. Dentro a a e de este campo, dirige el intercambio de informacin digital entre equipos o mdicos. Como el equipo mdico puede funcionar con otros dispositivos e e mdicos, el alcance de estas necesidades estndar para trasladar a otras e a a reas de informtica mdica, como mostrado en la gura. Sin embargo, el a e estndar DICOM no dirige la anchura de este campo. a
180
Jos Ma Onrubia e
A.3. DEFINICIONES.
A.3.
Deniciones.
Atributo: una caracter stica de un objeto de informacin. Un atributo o tiene un nombre y un valor que es independiente de cualquier esquema de codicacin. Por ejemplo el nombre del paciente. o Comando: un medio genrico de transportar una peticin para funcionar e o sobre objetos de informacin a travs de una interfaz o una red. o e
181
Jos Ma Onrubia e
Elemento de comando: una codicacin de un parmetro de un comando o a que transporta el valor de este parmetro. a Chorro de comandos: el resultado de codicar un conjunto de elementos de comando DICOM que usan el esquema de codicacin DICOM. o Estatuto de conformidad : una declaracin formal asociada con una o realizacin espec o ca del estndar DICOM. Especica las clases de servicio, a los objetos de informacin, y los protocolos de comunicacin que soportan o o por las implementaciones. Diccionario de datos: un registro de los elementos de datos DICOM que tienen una etiqueta unica, un nombre, un valor, y la semntica de cada a elemento de datos. Elemento de datos: una unidad de informacin como denido por una o partida simple en el diccionario de datos. Conjunto de datos: informacin intercambiada que consiste en un o conjunto estructurado de valores de atributos directa o indirectamente relacionados con los objetos de informacin. El valor de cada atributo en o un conjunto de datos es expresado como un elemento de datos. Corriente de Datos: el resultado de codicar un conjunto de datos que usa el esquema de codicacin DICOM. o Objeto de Informacin: una abstraccin de una entidad verdadera de la o o informacin (p.ej., CT la Imagen, el Estudio, etc.) que es interpretado por o uno o ms comandos DICOM. a Clase de objeto de informacin: una descripcin formal de un objeto de o o informacin que incluye una descripcin de su propsito y los atributos que o o o posee. No incluye los valores de estos atributos.
A.4.
S mbolos y abreviaturas.
ACSE Association Control Service Element CT Computed Tomography DICOM Digital Imaging and Communications in Medicine
182
Jos Ma Onrubia e
A.5. OBJETIVOS DEL ESTANDAR DICOM.
HIS Hospital Information System NIU Network Interface Unit OSI Open Systems Interconnection PACS Picture Archiving and Communication Systems RIS Radiology Information System TCP/IP Transmission Control Protocol/Internet Protocol
A.5.
Objetivos del estndar DICOM. a
El estndar DICOM facilita la interoperabilidad de dispositivos que a cumplen con ste. En particular: e
Dirige la semntica de comandos y datos asociados. En dispositivos a que actan rec u procamente, debe haber normas sobre cmo se espera o que estos dispositivos reaccionen a esas rdenes y esos datos asociao dos, no slamente a cmo la informacin debe ser intercambiada entre o o o dispositivos. Explicita en la denicin de las exigencias de conformidad de las pueso tas en prctica del estndar. En particular, una declaracin de cona a o formidad debe especicar bastante informacin para determinar las o funciones para las que pueden esperar la interoperabilidad con otro dispositivo reclamando la conformidad. Facilita la operacin en un ambiente conectado a una red, sin la exio gencia de unidades de interfaz de red. Est estructurado para acomodar la introduccin de servicios nuevos, a o facilitando as el soporte para usos futuros de aplicaciones con imgenes mdicas. a e Hace uso de normas existentes internacionales, y ellas mismas siguen las directrices de documentacin establecidas para normas internao cionales. Si bien el estndar DICOM tiene el potencial para facilitar las puestas en a prctica de soluciones PACS, el empleo del estndar slo, no garantiza que a a o GVA-ELAI-UPM r PFC0074-03 183
APENDICE A. ESTANDAR DICOM PARTE 1 todos los objetivos de un PACS sean cumplidos.
Jos Ma Onrubia e
El estndar facilita la interoperabilidad de sistemas siguiendo la conformia dad en un ambiente de multivendedor, pero por s mismo no garantiza la interoperabilidad. Ha sido desarrollado con nfasis en el diagnstico mdico e o e como el practicado en radiolog y en disciplinas relacionadas; sin embargo, a se piensa que tambin es aplicable a una amplia gama de informacin de e o imgenes relacionadas en los ambiente cl a nicos.
A.6.
A.6.1.
Contenido del estndar DICOM. a

Estructura del documento.
DICOM la versin 3.0 consiste en el siguiente nueve partes: o PS 3.1: Introduccin y descripcin o o PS 3.2: Conformidad PS 3.3: Deniciones de objeto de informacin o PS 3.4: Datos espec cos de clase de Servicio PS 3.5: Estructura de datos y Codicacin o PS 3.6: Diccionario de datos PS 3.7: Intercambio de mensajes PS 3.8: Soporte de comunicacin en red para el intercambio de mensajes o PS 3.9: Soporte de comunicacin puntop por punto para el intercambio o de mensajes Estas partes del estndar estn relacionadas, pero son documentos indea a pendientes. Una corta descripcin de las Partes 2 a 9 se proporcionan en o esta seccin. o
A.6.2.
PS 3.2: Conformidad
PS 3.2 del Estndar DICOM dene principios que las implementaciones a deben seguir:
184
Jos Ma Onrubia e
A.6. CONTENIDO DEL ESTANDAR DICOM.
Exigencias de conformidad. PS 3.2 especica las exigencias generales que deben ser encontradas por cualquier realizacin. Hace referencia a o secciones de conformidad de otras partes del estndar. a
Declaracin de conformidad. PS 3.2 dene la estructura de un estado o de conformidad. Especica la informacin que debe estar presente en o una declaracin de conformidad. Hace referencia a las secciones del o estado de conformidad de otras partes del estndar. a
PS 3.2 no especica procedimientos de pruebas y validacin para evaluar o la conformidad de una implementacin del estndar. La gura represeno a ta el proceso de construccin para una declaracin de conformidad. Una o o declaracin de conformidad consiste en tres partes principales: o
el conjunto de los objetos de informacin que son reconocidos por esta o implementacin o
el conjunto de las clases de servicio que es reconocido en sta implee mentacin. o
el conjunto de los protocolos de comunicaciones que esta implementacin soporta. o GVA-ELAI-UPM r PFC0074-03 185
Jos Ma Onrubia e
A.6.3.
PS 3.3: Deniciones de objetos de la informacin o (IODs)
PS 3.3 del estndar DICOM especica unas clases de objeto de infora macin que proporcionan una denicin abstracta de entidades del mundo o o real, aplicables a la comunicacin de imgenes digitales mdicas. Cada IOD o a e consiste en la descripcin de su objetivo y los atributos que lo denen. Un o IOD no incluye los valores para los atributos que comprenden su denicin. o Para facilitar el crecimiento futuro del estndar y mantener la compatia bilidad con las versiones anteriores del estndar, dos tipos de IODs estn a a denidos: normalizado y compuesto. Los IODs normalizados incluyen slo aquellos atributos inherentes a la o entidad de mundo real representada. Por ejemplo, la clase de objeto de 186 GVA-ELAI-UPM r PFC0074-03
Jos Ma Onrubia e
informacin de estudio, que est denida como normalizado, contiene los o a atributos de los estudios de fecha y tiempo porque son inherentes al estudio actual. El nombre del paciente, sin embargo, no es un atributo de la clase de objeto de informacin de estudio porque sto, es inherente al paciente o e sobre el que el estudio ha sido realizado y no sobre el estudio en s mismo. Las clases de objeto de informacin compuestas pueden adems incluir o a los atributos que tienen relacin, pero que no son inherentes a la entidad o del mundo real. Por ejemplo, la clase de objeto de informacin de imagen o de tomogrca calculada, que est denida como compuesta, contiene los a a atributos que son inherentes a la imagen (p.ej. la fecha de imagen) y los atributos que estn relacionados, pero que no son inherentes a la imagen a (p.ej. el nombre paciente). Las clases de objeto de informacin compuestas o proporcionan un marco estructurado para expresar las exigencias de comunicacin de las imgenes que han sido denidos en las versiones anteriores o a del estndar. a Para simplicar las deniciones de clase de objeto de informacin, o los atributos de cada clase de objeto de informacin estn divididos en o a atributos similares, agrupados juntos. Estas agrupaciones de atributos son especicadas como mdulos independientes y pueden ser reutilizadas por o una o ms clases de objeto de informacin compuestas. a o Para representar un acontecimiento de una entidad del mundo real, se crea una instancia de objeto de informacin, en la cual se incluyen valores o para los atributos de la clase de objeto de informacin. Los valores de o atributo de esta instancia de objeto de informacin pueden cambiar con o tiempo para reejar con exactitud el estado que se cambia de la entidad a la que esto representa. Esto se logra realizando operaciones bsicas diferentes a sobre la instancia de objeto de informacin para dar un juego espec o co de servicios denidos como una clase de servicio. Estas clases de servicio son denidas en PS 3.4 del Estndar. a PS 3.3 tambin est relacionado con otras partes del estndar DICOM: e a a
PS 3.5, Estructura de datos y semntica, dene la estructura del cona junto de datos y la codicacin para convey DICOM Information Obo ject Attributes
PS 3.6, Dicconario de datos, dene la semntica de los elementos de a datos DICOM la cual tranporta los atributos de objetos de informacin o denidos en PS 3.3. GVA-ELAI-UPM r PFC0074-03 187
Jos Ma Onrubia e
A.6.4.
PS 3.4: Especicaciones de las clases de servicio.
PS 3.4 del estndar DICOM dene un nmero de clases de servicio. Una a u clase de servicio asocia uno o ms objetos de informacin con una o ms a o a o rdenes para ser realizadas sobre estos objetos. PS 3.4 del estndar DICOM dene las caracter a sticas compartidas por todas las clases de servicio, y como una declaracin de conformidad a o una clase de servicio individual est estructurada. Contiene unos anexos a normativos que describen clases de servicio individuales detalladamente. Los ejemplos de Clases de Servicio incluyen lo siguiente:
Clase de servicio de almacenamiento. Clase de servicio de pregunta. Clase de servicio de recuperacin. o Clase de servicio de gestin de estudio. o PS 3.4 dene las operaciones realizadas sobre los objetos de informacin o denidos en PS 3.3. PS 3.7 dene las rdenes y protocolos para usar los o comandos para lograr las operaciones descritas en PS 3.4.
A.6.5.
PS 3.5: Estructura de datos y semntica a
PS 3.5 del estndar DICOM especica como las entidades de aplicacin a o DICOM construyen y codican la informacin de conjunto de datos el o siendo resultado del empleo de los objetos de informacin y clases de o servicios denidas en las partes 3 y 4 del estndar DICOM. a PS 3.5 del estndar DICOM, especica como entidades de aplicacin a o DICOM construyen y codican la informacin del conjunto de datos, siendo o conjunto el resultado del empleo de los objetos de informacin y clases de o servicios denidas en las partes 3 y 4 del estndar DICOM. a PS 3.5 direcciona las reglas de codicacin necesarias para construir un o ujo de datos para ser transportada en un mensaje como se especica en PS 3.7 del estndar DICOM. Estos datos son producidos de la coleccin de a o elementos de datos que forman el conjunto de datos. Varios conjuntos de datos pueden ser referidos o doblados en un conjunto de datos compuesto. Un conjunto de datos compuesto es usado para transferir en un paqueteel 188 GVA-ELAI-UPM r PFC0074-03
Jos Ma Onrubia e
contenido de objetos de informacin, ofreciendo una capacidad de carpeta. o PS 3.5 tambin dene la semntica de un nmero de unas funciones e a u genricas que son comunes a muchos objetos de informacin. e o
A.6.6.
PS 3.6: Diccionario de datos
PS 3.6 del estndar DICOM es el registro centralizado que dene la coleca cin de todos los elementos de datos DICOM disponibles para representar o la informacin. Para cada elemento de datos, PS 3.6: o
asigna una etiqueta unica, que consiste en grupo y el nmero de ele u mento le da un nombre especica sus caracter sticas de valor (la cadena de caracteres, el nmero entero, etc.) u dene su semntica (como debe ser interpretado). a PS 3.6, en la conjuncin con PS 3.5, es usado para construir conjunto de o datos, y representar objetos de informacin como conjuntos de datos en la o conjuncin con PS 3.3 Y PS 3.5. o
A.6.7.
PS 3.7: Intercambio de mensajes.
PS 3.7 del estndar DICOM especica tanto el servicio como el protocolo a usado por una entidad de aplicacin en un ambiente de imgenes mdicas o a e para intercambiar mensajes sobre los servicios de apoyo de comunicaciones denidos en PS 3.8 O PS 3.9. Un mensaje est compuesto por un ujo de a o rdenes denidos en PS 3.7 seguido por un ujo de datos opcional como lo denido en PS 3.5. Esta parte especica lo siguiente: reglas para establecer y nalizar las asociaciones proporcionadas por el apoyo de comunicaciones especicado en PS 3.8 O PS 3.9, y las repercusiones sobre transacciones excepcionales. reglas que gobiernan el intercambio de peticiones y respuestas de o rdenes. GVA-ELAI-UPM r PFC0074-03 189
Jos Ma Onrubia e
reglas codicadas necesarias para construir ujo de rdenes y meno sajes. Adems, PS 3.7 est relacionado con otras partes del estndar: a a a
PS 3.3, las deniciones de objeto de informacin, especican el juego o de clases de objeto de informacin a las que las Ordenes denidas en o PS 3.7 pueden ser aplicadas. PS 3.5, la estructura de datos y la semntica, dirigen las reglas de a codicacin necesarias para construir un ujo de datos para ser transo portada en un mensaje especicado en PS 3.7 del estndar DICOM. a PS 3.7, el intercambio de mensajes, dene las rdenes y protocolos o para usar las rdenes para lograr las operaciones descritas en PS 3.4. o
A.6.8.
PS 3.8: Apoyo de comunicacin de red para el intero cambio de mensaje
PS 3.8 del estndar DICOM especica los servicios de comunicacin y a o los protocolos de capas superiores necesarios para soportar, en una red, la comunicacin entre entidades de aplicacin DICOM segn lo especicado o o u en PS 3.3, PS 3.4, PS 3.5, PS 3.6, Y PS 3.7. Estos servicios de comunicacin o y protocolos aseguran que la comunicacin entre entidades de aplicacin o o DICOM sea realizada de una manera eciente y coordinada a travs de la e red. Los servicios de comunicacin especicados en PS 3.8 son un subconjunto o apropiado de los servicios ofrecidos por el servicio de presentacin OSI (LA o ISO 8822) y del elemento de servicio de control de asociacin OSI (ACSE) o (LA ISO 8649). Se reeren al servicio de capa superior, que permite a un par entidades de aplicacin el establecimiento de asociaciones, mensajes de o transferencia y el n de las asociaciones. Esta denicin del servicio de capa superior permite el empleo de los o protocolos OSI (Capas 1 a 6 ms ACSE) para alcanzar una comunicacin a o robusta y eciente. Esto, soporta una gran variedad de estndares internaa cionales basados en tecnolog de red que usan una amplia opcin de redes as o f sicas como la ISO 8802-3 CSMA/CD (Ethernet a menudo llamada), FDDI, ISDN, X.25, dedicated digital circuits y muchas otras LAN y tecnolog de as red WAN. Adems, este mismo servicio de capa superior tambin puede ser propora e cionado por el protocolo de capa DICOM superior usado conjuntamente 190 GVA-ELAI-UPM r PFC0074-03
Jos Ma Onrubia e
con protocolos de transporte de TCP/IP. Por lo tanto, una amplia gama de ambientes de red se pueden usar. La denicin de un servicio de capa o superior comn a OSI y a ambientes TCP/IP, permite la migracin de un u o TCP/IP a un ambiente OSI sin chocar entidades de aplicacin DICOM. o Estos protocolos de comunicacin especicados por PS 3.8 son protocolos o de comunicacin de objetivos generales (OSI, TCP/IP) y no versiones o espec cas para el estndar DICOM. La gura muestra estos dos protocolos. a
A.6.9.
PS 3.9: Soporte de comunicacin para el intercambio o de mensajes punto por punto.
El PS 3.9 del estndar DICOM especica los servicios y los protocolos usaa dos para las comunicaciones punto por punto de una manera compatible con ACR-NEMA 2.0. Especica un interfaz f sico y protocolos sealados. Dene n GVA-ELAI-UPM r PFC0074-03 191
Jos Ma Onrubia e
el OSI enlace para transmisin de datos y protocolos sesin/transporte/red y o o los servicios del montn de protocolo para ser usado sobre este interfaz f o sico. Los servicios de capa de sesin/transporte/red especicados y protocolos o soportan la comunicacin entre entidades de aplicacin DICOM como lo o o especicado en las partes 3, 4, 5, 6, y 7. Estos servicios son un subconjunto de los servicios de capa superiores especicados en PS 3.8 del estndar a DICOM. Esta caracter stica del subconjunto permite la interconexin de o un dispositivo con un interfaz de punto-punto a un ambiente de comunicacin totalmente conectado a una red con soporte OSI Y TCP/IP. Tal o interconexin requiere una unidad de interfaz de red interventor (NIU). La o gura presenta como un interfaz de punto-punto y un ambiente conectado a una red coexisten.
192
Jos Ma Onrubia RELACIONES ENTRE LAS PARTES DEL ESTANDAR. e A.7.
A.7.
Relaciones entre las partes del estndar. a
Las relaciones siguientes existen entre las partes del estndar: a PS 3.1: la introduccin y la descripcin describen la estructura total del o o estndar. a PS 3.2: la conformidad especica las exigencias generales que deben ser encontradas por puestas en prctica reclamando la conformidad y el a contenido de una Declaracin de conformidad. o PS 3.3: las deniciones de objeto de informacin especican la estructura o y los atributos de los objetos que son manejados por clases de servicio (PS 3.4). Estos objetos incluyen imgenes, estudios, y pacientes. a PS 3.4: los datos espec cos de clase de servicio denen las operaciones que pueden ser realizadas sobre los casos de objetos de informacin (PS o 3.3) para proporcionar un servicio espec co. Estos servicios incluyen el almacenaje de imagen, la recuperacin, y la impresin. o o PS 3.5: la estructura de datos y la Semntica especican la codicacin a o del contenido de datos de los mensajes que son cambiados para lograr las operaciones usadas por las clases de servicio (PS 3.4). PS 3.6: el diccionario de datos dene los atributos individuales de la informacin que representan el contenido de datos (PS 3.5) de los casos de o objetos de informacin. o PS 3.7: el cambio de mensaje especica las operaciones y el protocolo usado para cambiar mensajes. Estas operaciones son usadas para lograr los servicios denidos por las clases de servicio (PS 3.4). PS 3.8: el apoyo de comunicacin de red para el cambio de mensaje o dene los servicios y protocolos usados para cambiar mensajes (PS 3.7) directamente sobre REDES de TCP/IP y OSI. PS 3.9: el apoyo de comunicacin punto a punto para el intercambio de o mensajes dene los servicios y los protocolos usados para el intercambio de mensajes (PS 3.7) en la interfaz de 50 pines.
Para ms imformacin dirigirse a la parte del estndar deseada. Todas a o a las partes del estndar se pueden encontrar en la red. a
193
Jos Ma Onrubia e
194
Indice de guras
2.1. 2.2. 2.3. 2.4. 2.5. 2.6. Proceso distribuido . . . . . . . . . . . . . . . . . . . . . . . . Modelo de un proceso distribuido . . . . . . . . . . . . . . . . Clases de servicio DICOM . . . . . . . . . . . . . . . . . . . . Relaciones entre IODs y atributos . . . . . . . . . . . . . . . Ejemplo de una imagen IOD compuesta. . . . . . . . . . . . . Descripcin de la codicacin y decodicacin de las instano o o cias SOP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.7. DICOM con intercambio en red. . . . . . . . . . . . . . . . . 2.8. Capas OSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.9. Conexin TCP . . . . . . . . . . . . . . . . . . . . . . . . . . o 2.10. Estatuto de conformidad con perl del sistema. . . . . . . . . 2.11. Estatuto de conformidad con perl de aplicacin . . . . . . . o 2.12. Diferentes partes del estndar DICOM . . . . . . . . . . . . . a 2.13. Del mundo real al modelo de informacin . . . . . . . . . . . o 2.14. Ejemplo de mappingde un CT . . . . . . . . . . . . . . . . 2.15. Modelo de informacin de una imagen compuesta DICOM . . o 2.16. Clasicacin de la informacin de la imagen . . . . . . . . . . o o 2.17. Juego bsico de atributos de las instancias de imagen SOP . . a 2.18. Ciclo de vida de Image SOP Instance Information . . . . . . 3.1. 3.2. 3.3. 3.4. 3.5. 6.1. 6.2. 6.3. 6.4. 6.5. 6.6. 6.7. Visual C++ Browser . . Viewer . . . Print . . . . Process log con DCMTK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 6 7 8 9 15 16 20 22 23 25 26 29 31 33 38 45 48 56 60 61 62 63 111 113 114 114 115 115 116
Asistente para proyectos: paso 1 Partes de aplicacin. . . . . . . . o contentPane . . . . . . . . . . . . JScrollPane . . . . . . . . . . . . constraints . . . . . . . . . . . . JTextArea . . . . . . . . . . . . . text . . . . . . . . . . . . . . . . 195
INDICE DE FIGURAS
Jos Ma Onrubia e . . . . . 117 . . . . . 117 . . . . . 119 . . . . . 120 . . . . . 122 . . . . . 125 . . . . . 133 . . . . . 138 . . . . . 139 . . . . . 140 . . . . . 141 . . . . . 142 . . . . . 143 . . . . . 144 . . . . . 146 . . . . . 147 . . . . . 149 . . . . . 150 . . . . . 151 . . . . . 153 . . . . . 155 . . . . . 156 . . . . . 157 . . . . . 159 . . . . . 160 . . . . . 161 de grises.163 . . . . . 164 . . . . . 167 . . . . . 168 . . . . . 170 . . . . . 171 . . . . . 171 . . . . . 172 . . . . . 174 . . . . . 174 . . . . . 175
6.8. Ejecutado . . . . . . . . . . . . . . . . . . . . . . . . 6.9. Mens . . . . . . . . . . . . . . . . . . . . . . . . . . u 6.10. Editor . . . . . . . . . . . . . . . . . . . . . . . . . . 6.11. actionPerformed . . . . . . . . . . . . . . . . . . . . 6.12. jMenu . . . . . . . . . . . . . . . . . . . . . . . . . . 6.13. editor en negro . . . . . . . . . . . . . . . . . . . . . 6.14. API de JDK 1.4.1. . . . . . . . . . . . . . . . . . . . 6.15. Congurar JDK. . . . . . . . . . . . . . . . . . . . . 6.16. Nuevo camino de JDK. . . . . . . . . . . . . . . . . . 6.17. Propiedades de proyecto. . . . . . . . . . . . . . . . . 6.18. Propiedades de proyecto. . . . . . . . . . . . . . . . . 6.19. Propiedades de proyecto. . . . . . . . . . . . . . . . . 6.20. Estructura bsica de la aplicacin. . . . . . . . . . . a o 6.21. Panel Visor DICOM. . . . . . . . . . . . . . . . . . . 6.22. Zoom mediante botones Zoom In y Zoom Out. . . . 6.23. Zoom mediante cliqueos de ratn. . . . . . . . . . . . o 6.24. Botones Anterior y Siguiente . . . . . . . . . . . . . 6.25. Botn Seguidas . . . . . . . . . . . . . . . . . . . . . o 6.26. Botn Guardar JPEG . . . . . . . . . . . . . . . . . o 6.27. Zona de insertar datos. . . . . . . . . . . . . . . . . . 6.28. Ver funcionamiento. . . . . . . . . . . . . . . . . . . 6.29. Botones para campos nuevos. . . . . . . . . . . . . . 6.30. Comprobar insercin de nuevo campo. . . . . . . . . o 6.31. Panel Crear archivo DICOM. . . . . . . . . . . . . . 6.32. Imagen a insertar. . . . . . . . . . . . . . . . . . . . 6.33. Datos de texto a insertar. . . . . . . . . . . . . . . . 6.34. Comprobar la creacin del archivo DICOM en escala o 6.35. Comprobar la creacin del archivo DICOM en color. o 6.36. Resultados de nuestra secuencia. . . . . . . . . . . . 6.37. Panel procesamiento. . . . . . . . . . . . . . . . . . . 6.38. Botn para aadir archivos. . . . . . . . . . . . . . . o n 6.39. Botn para abrir imagen a procesar. . . . . . . . . . o 6.40. Botn para procesar imagen. . . . . . . . . . . . . . o 6.41. Panel Cliente/Servidor. . . . . . . . . . . . . . . . . 6.42. Asistente creador de recopilatorios. . . . . . . . . . . 6.43. Asistente creador de recopilatorios. Paso2. . . . . . . 6.44. Asistente creador de recopilatorios. Paso3. . . . . . .
196

Proyecto DICOMJose

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Proyecto DICOMJose

Încărcat de

Drepturi de autor:

Formate disponibile

Desarrollo de aplicacin DICOM mediante librer o as JDT (Java Dicom Toolkit)

Jos Ma Onrubia e 14 de julio de 2003

4 3.3.2. 3.3.3. 3.3.4. 3.3.5. Browser. . . . Viewer. . . . Print. . . . . Process Log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4.1 109 . . . 109 . . . 110 . . . 110 . . . 110 . . . 110

CAP ITULO 1. INTRODUCCION Y OBJETIVOS transmisin hasta el tratamiento e impresin. o o

CAP ITULO 2. ESTADO DE LA TECNICA.

Conceptos generales de DICOM.

CAP ITULO 2. ESTADO DE LA TECNICA.

CAP ITULO 2. ESTADO DE LA TECNICA.

2.1. DICOM (DIGITAL IMAGING AND COMMUNICATION IN Jos Ma Onrubia e MEDICINE).

CAP ITULO 2. ESTADO DE LA TECNICA.

CAP ITULO 2. ESTADO DE LA TECNICA. Identicacin. o

CAP ITULO 2. ESTADO DE LA TECNICA.

Se especica un valor representativo (VR).

En caso de compresin: el formato. o

2.1. DICOM (DIGITAL IMAGING AND COMMUNICATION IN Jos Ma Onrubia e MEDICINE).

Figura 2.6: Descripcin de la codicacin y decodicacin de las instancias o o o SOP.

Conceptos de red DICOM.

CAP ITULO 2. ESTADO DE LA TECNICA.

funciones requeridas para la comunicacin: el dominio de la comunicacin. o o

Figura 2.7: DICOM con intercambio en red.

CAP ITULO 2. ESTADO DE LA TECNICA.

CAP ITULO 2. ESTADO DE LA TECNICA.

Figura 2.8: Capas OSI

CAP ITULO 2. ESTADO DE LA TECNICA.

Figura 2.9: Conexin TCP o

CAP ITULO 2. ESTADO DE LA TECNICA.

Figura 2.11: Estatuto de conformidad con perl de aplicacin o

CAP ITULO 2. ESTADO DE LA TECNICA.

Instancias SOP de imgenes DICOM (DIa COM Image SOP Instances)

CAP ITULO 2. ESTADO DE LA TECNICA.

Modelo de informacin de las imgenes o a

Figura 2.13: Del mundo real al modelo de informacin o

CAP ITULO 2. ESTADO DE LA TECNICA. Nivel de serie

CAP ITULO 2. ESTADO DE LA TECNICA.

Instancias imagen SOP (Image SOP Instances)

Figura 2.15: Modelo de informacin de una imagen compuesta DICOM o

CAP ITULO 2. ESTADO DE LA TECNICA. Identicacin o

CAP ITULO 2. ESTADO DE LA TECNICA.

Clasicacin de los datos de imagen o

CAP ITULO 2. ESTADO DE LA TECNICA.

Figura 2.16: Clasicacin de la informacin de la imagen o o

CAP ITULO 2. ESTADO DE LA TECNICA.

CAP ITULO 2. ESTADO DE LA TECNICA.

CAP ITULO 2. ESTADO DE LA TECNICA. Tipos genricos de imgenes e a

Descripcin de la matriz de p o xeles: muestra por p xel, las, columnas.

Interpretacin del valor del p o xel: interpretacin fotomtrica. o e

Matriz de p xeles: datos de p xel. 44 GVA-ELAI-UPM r PFC0074-03

CAP ITULO 2. ESTADO DE LA TECNICA.

Aplicacin de los datos de imgenes o a

CAP ITULO 2. ESTADO DE LA TECNICA.

Figura 2.18: Ciclo de vida de Image SOP Instance Information

CAP ITULO 2. ESTADO DE LA TECNICA. Categor de aplicacin as o

Estudio de librerias DCMTK.

CAP ITULO 3. ESTUDIO DE LIBRERIAS DCMTK.

Estructura de datos DICOM.

3.1. VISION GENERAL.

Servicios de red DICOM.

Intercambio de medios de comunicacin. o

CAP ITULO 3. ESTUDIO DE LIBRERIAS DCMTK.

3.2. INSTALACION DCMTK351.

CAP ITULO 3. ESTUDIO DE LIBRERIAS DCMTK.