CIENCIAS EXACTAS Y NATURALES - COMUNICACIÓN

Experiencias en la gestión de imágenes por contenido en bases de datos objeto-relacionales *

Experiences in Image Management by Content in Object-Relational Databases *

Alvez, Carlos E. **; Vecchietti Aldo R. ***

*) Articulo derivado del PID-UNER Nº7024, Facultad de Ciencias de la Administración, Universidad Nacional de Entre Ríos (UNER), 2006-2007; versiones preliminares fueron presentadas en “SQL:1999 y SQL/MM para el Modelado y Diseño de Bases de Datos Multimedia” y “Representación y Recuperación de Imágenes Médicas en Bases de Datos Objeto-Relacionales”; recibido en diciembre 2008; admitido en noviembre 2009.
**) Facultad de Ciencias de la Administración, UNER, Concordia (Argentina) caralv@ai.fcad.uner.edu.ar
***) Sistemas de Información, Universidad Tecnológica Nacional (UTN) Facultad Regional Santa Fe; CONICET. aldovec@frsf.utn.edu.ar

Resumen: En este artículo se analizan diversos mecanismos que brinda la tecnología Objeto-Relacional (OR) para el almacenamiento de imágenes en una Base de Datos. El objetivo fue estudiar, mediante la implementación de dos ejemplos en Oracle 10g, el comportamiento de la tecnología OR en el almacenamiento, la formulación de consultas, la recuperación de la información y de las imágenes asociadas. La primera implementación se corresponde con el almacenamiento de imágenes médicas concordantes con el estándar DICOM, utilizando objetos ORDImage propios de ORACLE. En el segundo ejemplo se almacenaron imágenes de un diario digital empleando instancias del UDT SI_StillImage del estándar SQL/MM. Las capacidades provistas por la Base de Datos Objeto-Relacional empleada facilitan la implementación de un servidor de imágenes. Se analizaron también las ventajas y desventajas de emplear objetos del estándar SQL/MM o datos nativos correspondientes a Oracle 10g.

Palabras clave: Informática; Objeto relacional; Bases de datos; Recuperación por contenido

Abstract: In this paper, several alternatives for the storage of still images in databases given by the Object-Relational technology are analyzed. The aim was to study, by means of two examples, implementation in Oracle 10g database, the technology behaviour in the storage, query formulation and image recovery. The first application corresponds to the storage of medical images complying with DICOM (Digital Imaging and Communications in Medicine) standard, Oracle 10g ORDImage objects have been used for this case. The second example deals with the storage of images for a digital newspaper for which SI_StillImage of the SQL/MM standard have been employed. The capabilities provided by the Object Relational technology facilitate the implementation of an images server. The advantages and drawbacks of using SQL/MM standard or native objects corresponding to Oracle 10g are also compared.

Keywords: Informatics; Object-Relational; Databases; Content-based retrieval

I. Introducción

En la actualidad, es cada vez más común la incorporación de datos multimediales (imágenes, sonidos, videos) en los sistemas de información. El empleo de datos multimediales es un componente más en el manejo cotidiano de las organizaciones. Para el manejo de imágenes, en muchos casos no sólo es importante obtener la información textual asociada a la misma, sino también las propiedades (descriptores) que la caracterizan como color, textura y forma. Desde hace algunos años, muchas bases de datos comerciales tienen la capacidad de almacenar datos mediales y recuperar la información de los mismos por medio de consultas a la información textual almacenada en conjunto, pero sólo algunas de ellas proveen la capacidad de recuperación por medio de los descriptores de las imágenes. Las bases de datos que presentan esta capacidad son las Bases de Datos Objeto-Relacionales (BDOR) en las que se pueden definir tipos definidos por el usuario (UDT: User Defined Type) específicos para una aplicación. En este trabajo, se analiza la infraestructura, en términos de UDT, operadores y métodos, de representación de imágenes en una BDOR que responde al estándar SQL2003 (Melton, 2003). Específicamente, se emplea para este análisis Oracle 10g, que es un Sistema de Gestión de Bases de Datos Objeto-Relacionales (SGBDOR) y su extensión InterMedia (Oracle, 2005a) para el soporte de datos multimediales. La selección de Oracle 10g para este estudio obedece a que en la actualidad es uno de los SGBDOR más avanzados y que mayor concordancia tiene con el estándar SQL2003. El análisis se centra en las alternativas de representación de las imágenes que Oracle10g provee por medio de interMedia, que son dos:

- ORDImage que es un UDT definido para imágenes quietas, en conjunto con ORDImageSignature que es UDT para la administración de los descriptores de las imágenes, que son desarrollos propios de Oracle.
-  SIStillImage que es un UDT para administrar imágenes quietas pero que responde a la especificación del estándar SQL/MM (SQL Multimedia).

Cada uno de los UDTs tiene definidos sus métodos que sirven para extraer los metadatos y sus atributos de las imágenes, almacenar y manipular los datos de la Base de Datos.
Para el almacenamiento de imágenes en una BD multimedia es muy importante definir qué información almacenar. Esta información debe permitir encontrar imágenes tanto por su contenido físico, como también, por la información descriptiva de estos datos multimediales (Kosch, 2002). Para ello se emplean metadatos (datos sobre los datos). Los metadatos deben proveer diferentes niveles de abstracción; por ejemplo, de una imagen se puede guardar información sobre sus propiedades (color, textura, forma) que permita recuperar información mediante la utilización de medidas de similaridad, que se puede catalogar como de bajo nivel de abstracción, como también sobre la misma imagen se puede guardar información semántica, por ejemplo: "resonancia magnética de cerebro de Juan Pérez de fecha 25/06/09", que brinda conocimiento específico sobre la imagen y permite recuperarla con precisión. Estos metadatos que describen el contenido multimedia se pueden indexar para contar con un eficiente acceso a la información multimedia por contenido físico y/o semántico.
El objetivo de este artículo es mostrar los mecanismos más adecuados y el comportamiento de ambas implementaciones (ORDImage y Stillimage) para el almacenamiento de imágenes, formulación de consultas y la recuperación de la información. En primer lugar introduciremos las BDOR y las características de esta tecnología; luego se presentarán las propiedades y características de los UDT ORDImage y StillImage que provee Oracle InterMedia para el almacenamiento de imágenes quietas; en el apartado IV se describirán los ejemplos que se utilizaron para hacer la experiencias de almacenamiento y recuperación de las imágenes, y por último, se analizarán los resultados obtenidos y se presentarán las conclusiones.

II. Bases de datos Objeto-Relacionales

Los Sistemas de Gestión de Bases de Datos Relacionales (SGBDR) son muy efectivos para la gestión de datos alfanuméricos, pero no ofrecen soluciones adecuadas para la gestión de datos multimediales. Una BD multimedia debe proveer mecanismos tanto para el almacenamiento de objetos mediales, como también para la recuperación de los mismos por medio de sus descriptores. En esto último se encuentra la principal desventaja de los SGBDR, dado que no proveen herramientas para la comparación (matching) de objetos mediales. Los SGBDOR son los que más han evolucionado en este sentido, alcanzando un grado de estabilidad y madurez que permite abordar aplicaciones multimediales no accesibles hace algunos años (Alvez y Vecchietti: 2006). La tecnología Objeto-Relacional nos permite:

-  Conservar ciertas características de las BD relacionales, como realizar consultas declarativas (SQL).
- Aprovechar las características de OO de los SGBDOR, que dan la posibilidad de establecer nuevos tipos de datos (UDT) para adaptar los servicios provistos por el servidor de BD a un dominio específico.

El uso del SGBDOR Oracle 10g en este trabajo se debe a que su extensión interMedia permite la gestión de contenido multimedia de manera integrada con otra información de la aplicación. Para esto, interMedia provee de tres modos diferentes de representar datos multimediales:

-  Como objetos BLOB (Binary Large Objects) que se almacenan localmente en la BD y contienen los datos multimediales (imágenes en nuestro caso).
-  Como objetos BFILE que son objetos grandes almacenados en archivos específicos del sistema operativo.
- Por medio de URLs que almacenan datos mediales en servidores http. La primera opción presenta algunas ventajas, ya que las otras formas, al estar soportadas en archivos del sistema operativo o en servidores http, no cuentan con un control transaccional y de seguridad pleno como el que puede proveer la BD cuando las imágenes se almacenan como objeto BLOB.

La utilización de BLOB en Oracle 10g permite la selección de tres formas diferentes de almacenar una imagen:

1.  Como tipo BLOB plano que puede estar incluido en una tabla o en un UDT.
2.  Como un tipo ORDImage.
3.  Como un tipo SIStillImage (ISO/IEC, 2001).

Como ya fue expresado en la Introducción, las instancias de los UDT SIStillImage y ORDImage consisten en atributos y métodos; los primeros permiten almacenar no sólo la imagen, sino también los metadatos que contienen información extra sobre el contenido de la imagen. Los métodos son funciones, operadores y procedimientos que permiten, entre otras cosas, la inserción de imágenes, la extracción automática de los metadatos cuando la imagen se almacena y la recuperación de la misma por medio de sus descriptores. En este trabajo se presentan las experiencias realizadas para analizar las virtudes y defectos de esta tecnología.

III. Objetos de Oracle interMedia para tratamiento de imágenes

En esta sección se hará un análisis sintético de los objetos de Oracle interMedia para el almacenamiento de imágenes y sus metadatos.

III. 1 Objetos ORDImage

Las instancias de ORDImage están compuestas por atributos que permiten el almacenamiento tanto de la imagen binaria, como de distintos metadatos. La imagen se almacena en un atributo "source", que es instancia de otro UDT denominado ORDSource compuesto, a su vez, por otros atributos, entre ellos, "localData", que es de tipo BLOB y es el que contiene la imagen; los demás atributos brindan información sobre propiedades de almacenamiento del archivo donde se encuentra la imagen, como por ejemplo: localización, fecha de última actualización, etc. Además, existen otros atributos para almacenar metadatos de la imagen tales como: alto y ancho, tamaño en bytes, formato de archivo. Sin embargo, las instancias de ORDImage no almacenan metadatos físicos para la recuperación por contenido. Para esto se debe utilizar el UDT ORDImageSignature que tiene declarado atributo "signature", del tipo BLOB, para almacenar los metadatos que describen a la imagen por sus propiedades de color, textura y forma. Los valores almacenados en "signature" son los que se emplean realmente para la recuperación de imágenes por contenido. Por lo tanto, cada instancia de ORDImage que se almacena en una tabla debe guardar su respectiva signatura. En la Figura 1 se muestra la definición de la tabla que se emplea para la implementación de los ejemplos de este trabajo. Allí puede verse cómo pueden combinarse los objetos ORDImage y ORDImageSignature, en una tabla, y además, cómo esta información se puede vincular con otras tablas, ya sea utilizando claves foráneas (Foreign key) o referencias a objetos (instancias del tipo Ref del estándar SQL:2003). En la sección IV.1, se presentará un ejemplo de implementación de aplicación utilizando ORDImage para la gestión de imágenes médicas.

Figura 1: Tabla que contiene instancias de los UDT ORDImage y ORDImageSignature

III. 2 Objetos SI_StillImage

Si bien tanto los objetos del estándar Still Image como ORDImage permiten almacenar imágenes y realizar consultas por contenido, sólo el UDT SI_StillImage se adecua al estándar ISO/IEC 13249-5:2001 SQL/MM Part 5: Still Image Standard (Melton y Eisenberg: 2001). El estándar especifica el contenido de los UDT para imágenes y características de las imágenes. Cada uno de ellos incluye atributos y métodos SQL asociados. Si bien esta interfase ofrece solo una parte de las capacidades de interMedia, su uso asegura portabilidad para otros productos que soporten el estándar.
En Oracle interMedia, un objeto de tipo SIStillImage, tiene un atributo "content_SI" de tipo ORDSource (igual que el atributo "source" de ORDImage). ORDSource contiene un atributo "localData" de tipo BLOB que es el que almacena la imagen real.
Además, SiStillImage tiene entre otros atributos:

- "contentLength_SI" que representa el tamaño de la imagen en bytes,
- "format_SI" que indica el tamaño de la imagen,
- "height_SI" y "width_SI" que indican el alto y ancho de la imagen,
- "colorPositions_ora" que almacena los arreglos de colores por posición,
- "texturePositions_ora" que almacena los arreglos de texturas por posición.

En la Figura 2, se presenta la composición de SIStillImage, con sus respectivos atributos y métodos, y se puede observar claramente la estructura compleja de este UDT.

Figura 2: Atributos y métodos de SI_StillImage y sus UDT relacionados.

Las instancias de SIStillImage almacenan las características visuales (arreglos de frecuencia de colores, color por posición, etc.). Sin embargo, no contiene métodos para la recuperación por contenido. Para esto es necesario valerse de otros UDT, del estándar Still Image, que contienen el método SI_Score() (Figura 3). El uso de estos métodos se tratará en la sección IV.2.

Figura 3: UDTs y métodos de Still Image para recuperación de imágenes.

IV. Ejemplos de aplicación

Veremos dos implementaciones en las que se detallarán los mecanismos de inserción y recuperación de imágenes por medio de ORDImage y SIStillImage, descriptos en la sección anterior.
La primera aplicación está relacionada con el almacenamiento y recuperación de imágenes médicas y se utilizan objetos ORDImage para guardar las imágenes en la BD y ORDImageSignature para sus características físicas. El motivo por el cual se utiliza ORDImage es porque, a diferencia de SIStillImage, permite el almacenamiento de imágenes DICOM (Digital Imaging and Communications in Medicine) (DICOM, 1993) y el procesamiento de sus metadatos.
DICOM es un estándar en medicina para la comunicación de imágenes entre diferentes sistemas. Los equipos de medicina actualmente proveen la capacidad de generar imágenes en este formato. La importancia de la aplicación desarrollada es, precisamente, que permite emplear este formato y extraer sus metadatos tanto físicos (color, forma, textura) como otros incorporados a la imagen (nombre de paciente, tipo de estudio, fecha del estudio, etc.), de gran interés en la medicina actual.
En la segunda implementación se utiliza el estándar Still Image de SQL/MM, aplicada al almacenamiento y recuperación de imágenes de un diario digital. Esta aplicación tiene como ventaja el hecho que, al adecuarse a un estándar, permite una mayor portabilidad.

IV.1 Aplicación utilizando objetos ORDImage y ORDImageSignature

En esta implementación se presenta una aplicación al almacenamiento y recuperación de imágenes médicas en la que se utilizan imágenes del estándar DICOM correspondientes a Resonancia Magnética transversal de un cerebro.

IV.1.1 Modelo Conceptual

Las imágenes médicas están asociadas con un paciente y su historia clínica, por lo tanto parece apropiado emplear el modelo de referencia propuesto por HL7 (Health Level 7) (HL7, 2006) que puede verse en la Figura 4. HL7 es una organización sin fines de lucro que desarrolla estándares para minimizar las incompatibilidades entre sistemas de información en salud, permitiendo la interacción y el intercambio productivo de datos entre aplicaciones heterogéneas, independientemente de su plataforma tecnológica o de su lenguaje de desarrollo. Los desarrollos de HL7 están reconocidos en Estados Unidos por el American National Standards Institute (ANSI) y por la Standards Developing Organization (SDO). Una aplicación informática que se desarrolle para medicina no puede ignorar este estándar. Si bien las BDOR permiten una implementación completa del RIM de HL7, ya que es posible crear cada uno de los tipos definidos en el modelo y generar las relaciones de herencia, asociación, agregación y composición de manera natural para la implementación de las imágenes (Golobisky y Vecchietti: 2005), para el desarrollo del ejemplo que se presenta se hizo una gran simplificación del modelo propuesto, con el objetivo de centrar la atención en el tratamiento de las imágenes.

Figura 4: Extracto del "Reference Information Model" (RIM) de HL7.

En la Figura 5 se muestra el modelo empleado para la aplicación. Dada la complejidad del propuesto por HL7, se implementó solo la relación de la clase Paciente que engloba a "Person", "LivingSubject", "Entity", "Role" y "Patient"; con Diagnostico_Imagen que engloba a "Participation", "Act", "Observation" y "DiagnosticImage".

Figura 5: Asociación entre pacientes y las imágenes de sus estudios

La transformación de este modelo conceptual al modelo lógico de una BDOR es directa. Se pueden definir las clases del modelo conceptual como tipos definidos por el usuario (UDTs), para las relaciones de asociación del modelo se pueden emplear referencias entre objetos (Alvez y Vecchietti, 2007).
La relación entre Paciente y Diagnostico_Imagen es una asociación de cardinalidad 1:N. En Oracle 10g, se pueden utilizar "multiset" (del estándar SQL:2003). Los mecanismos que provee Oracle para el soporte de "multiset" son las tablas anidadas, que son las que se emplean en este trabajo. La definición del "schema" para ORACLE sería la siguiente:

CREATE OR REPLACE TYPE paciente_ob AS OBJECT(
DNI         NUMBER(9),
nombre VARCHAR2(30),
apellido VARCHAR2(30), ... ) NOT FINAL;

CREATE OR REPLACE TYPE diagnostico_imagen_ob AS OBJECT(
codigo NUMBER(6),
titulo VARCHAR2(256),
fecha DATE,
imagen ORDImage,
caracteristica_imagen ORDImageSignature,
DicomMD          XMLType;
ref_paciente REF paciente_ob;
);

CREATE OR REPLACE TYPE diag_image_tab AS TABLE of REF
diagnostico_imagen_ob;

ALTER TYPE paciente_ob ADD ATTRIBUTE(
imagenes diag_image_tab) CASCADE;

CREATE TABLE paciente_tab OF paciente_ob (DNI Primary key)
NESTED TABLE imagenes STORE AS reftoimagenes_tab;

CREATE TABLE diagnostico_imagen_tab OF diagnostico imagen_ob
(codigo Primary key);

Paciente_ob es el UDT definido para representar la información de los pacientes a los que se les hará el diagnóstico, y diagnostico_imagen_ob es el UDT para las imágenes. En este último, se definió el atributo imagen del tipo ORDImage, caracteristicajmagen que es del tipo ORDImageSignature; contiene la información de bajo nivel de la imagen como: color, forma, textura y posición de cada uno de estos atributos. La asociación con paciente se implementa como una referencia a objetos paciente en el atributo ref_paciente, que contendrá el OID (Object Identifier) de aquél al que pertenecen las imágenes. Aquí también se ha incluido el atributo DicomMD del tipo XMLType que se empleará para almacenar metadatos de imágenes DICOM cuyo uso se explicará más adelante. Diagjmagejab es un tipo colección "multiset" que contiene un conjunto de referencias a objetos del tipo diagnostico_imagen_ob. Cada elemento de este "multiset" contendrá el OID de un objeto imagen correspondiente a ese paciente. Dado que cada paciente puede llegar a tener a lo largo del tiempo un número variable y desconocido de imágenes de un tipo determinado, esta implementación se hace por medio de una colección "multiset". La sentencia ALTER TYPE modifica el UDT de paciente para que incluya este conjunto de referencias. Finalmente se crean las tablas de los UDTs definidos previamente, paciente_tab y diagnostico_imagen_tab, que son las que contendrán los objetos persistentes de la aplicación, y reftoimagenes_tab es la tabla anidada que en paciente_tab contendrá la colección de referencias a las imágenes del paciente. Un detalle de la estructura resultante se puede observar en la Figura 6.

Figura 6: Implementación de asociación 1:N utilizando tablas anidadas.

IV.1.2 Procedimiento para insertar imágenes y sus características

En esta sección se describirán los pasos para la inserción de metadatos y la extracción de sus características, principalmente aquéllas relacionadas con la recuperación de imágenes por contenido.
Para insertar datos en la tabla diagnostico_imagen_tab, en primer lugar se deben almacenar los datos alfanuméricos, y a continuación los objetos imagen y caracteristica_imagen se deben inicializar utilizando los métodos estáticos init() de las clases ORDImage.init() y ORDImageSignature respectivamente.

INSERT INTO diagnostico_imagen_ta VALUES (11250, titulo, fecha,
ORDSYS.ORDImage.init(), ORDSYS.ORDImageSignature.init(), .

En este punto se está en condiciones de importar la imagen a partir del archivo que la contenga. Para ello se especifica el origen por medio del método setSource() y con el método import() se carga la misma en el objeto imagen.
Para insertar la imagen 'imgcerebro11250.dcm' que se encuentra en el directorio IMAGENESMEDICAS, se realizan los siguientes los pasos:

· Seleccionar del registro insertado anteriormente, la imagen inicializada.

SELEC imagen INTO img_aux

FROM diagnostico_imagen_tab
codigo = 11250 FOR UPDATE;

· Establecer el origen del archivo.

img_aux.setSource('file','IMAGENESMEDICAS',

'imgcerebro11250.dcm');

· Importar la imagen con el método import( ).

img_aux.import(ctx);
donde "img_aux" es una instancia de ORDImage.

Del código anterior se pueden hacer algunas consideraciones:

· El origen de la imagen es establecido como "file", que significa que es un archivo ubicado en el sistema de archivos local.
·  El archivo "imgcerebro11250.dcm" debe encontrarse en el directorio 'IMAGENESMEDICAS', que es un objeto "directory" definido previamente.

Para extraer las características físicas de la imagen almacenada anteriormente se deben realizar las siguientes acciones:

·  Crear un objeto ORDImageSignature temporal.
imagen_sig := ORDSYS.ORDImageSignature.init();
· Crear un almacenamiento temporal para el atributo "signatura" del objeto imagenjsig de tipo BLOB (ver Figura 1).
DBMS_LOB.CREATETEMPORARY(imagen_sig.signature, TRUE);

·  Extrae la signatura de la imagen.

imagen_sig.generateSignature(img_aux);

·  Por último, se deben actualizar los atributos "imagen" y "característícajmagen" del registro seleccionado.

UPDATE diagnosticoimagentab
SET imagen = img_aux, caractristica_imagen = imagen_sig
WHERE codigo = 11250;

Los pasos expuestos anteriormente permitirán recuperar por contenido las imágenes insertadas.

IV.1.3 Recuperación de imágenes con ORDImageSignature

Oracle interMedia, provee métodos y operadores para la recuperación de información por contenido utilizando los objetos ORDImageSignature. Estos métodos permiten comparar imágenes calculando una medida de similaridad ("score") a partir de la "signatura" de las mismas. Para esto, se le asigna un peso a cada uno de los atributos visuales y además se establece un umbral ("threshold") para indicar hasta que "score" se tolera en la respuesta. Este puede tomar valores entre 0 y 100, donde "0" significa que la coincidencia es total y 100 que no hay similaridad.
Uno de los operadores que permite comparar la "signatura" de una imagen buscada con las signaturas de las imágenes almacenadas en la BD es ORDSYS.IMGsimilar(). En primer lugar se debe generar la "signatura" de la imagen buscada y almacenarla en un BLOB temporal. Luego se calcula la distancia ("score") entre ésta y las distintas imágenes almacenadas en la BD.
El problema de este operador es que no hace distinciones entre las imágenes que son muy similares con aquellas que se acercan al valor umbral. Si la aplicación requiere una distinción más fina sobre la similaridad de las imágenes, es conveniente utilizar el operador ORDSYS.IMGScore(). Este último retorna la distancia de las imágenes a comparar lo que permite, por ejemplo, ordenar los resultados por "score".
Para mostrar un ejemplo de cómo utilizar ORDSYS.IMGScore(), se trabajará con un conjunto de imágenes de resonancia magnética del cerebro de un paciente, que están disponibles en la Web. El operador ORDSYS.IMGScore() trabaja en combinación con el operador ORDSYS.IMGSimilar(). Esto lo hace utilizando un número de referencia en común (en este caso 100) que se muestra en negrita en la Figura 7.

Figura 7: Pasos para la recuperación de imágenes por contenido utilizando objetos ORDImageSignature.

En el ejemplo anterior, se han empleado los siguientes pesos: color="0.1" texture="0.3" shape="0.3" location="0.3" y se estableció un umbral de similaridad igual a 20, con lo cual, se obtendrá como resultado cualquier imagen almacenada con una distancia entre 0 y 20 con "IMG.dcm". Tanto los pesos como el umbral pueden variar acorde a las necesidades de la aplicación. Para tener un mejor detalle de los métodos de recuperación se deberían considerar distintos casos, mostrar resultados con más valores de parámetros, lo que no se hace por razones de espacio.
El propósito del ejemplo fue averiguar si la imagen se encontraba en la tabla diagnostico_imagenes_tab. Para ello se extrajo la "signatura" de la misma y se comparó con las "signaturas" almacenadas. Las imágenes obtenidas como resultado se guardan en la tabla salidas. Los datos son: nombre de la imagen "srcname", la distancia "img_score" y la imagen "localdata" (Figura 8). La imagen con "score = 0" se corresponde con la imagen buscada.

Figura 8: Resultado de búsqueda por contenido ordenado por "score"

La recuperación de imágenes expuesta en los párrafos anteriores se aplica a cualquier formato de imagen (DCM, JPEG, GIFF, etc.). Las imágenes utilizadas en este caso corresponden al estándar DICOM (DCM), que se generan en muchos equipos de diagnóstico para medicina. Los metadatos de estas imágenes que fueron generados por el equipo, tales como datos del paciente, tipo de estudio, fecha, etc., pueden recuperarse y hacerse disponibles en archivos XML (Extensible Markup Language (W3C, 2006), que pueden ser útiles para realizar búsquedas empleando XPATH (W3C, 1999). Los metadatos DICOM se pueden obtener utilizando el método getDicomMetadata() que retorna un objeto XMLType (Oracle, 2005b), procediendo de la siguiente manera:

dicom_metadata := imagen.getDicomMetadata('imageGeneral');

donde "dicom_metadata" es instancia de XMLType, e "imagen" es instancia de ORDImage.

Estos metadatos pueden luego almacenarse en el campo DicomMD de la tabla diagnonstico_imagen_tab (sección V.1.1). Una vez almacenados, pueden ser consultados y procesados fácilmente por medio de funciones provistas especialmente para tipos XMLType.

IV.2 Adecuación al estándar SQL/MM

Mostraremos aquí la implementación del segundo ejemplo, empleando imágenes de un diario digital y UDTs del estándar Still Image de SQL/MM. Dada la heterogeneidad de las imágenes en esta aplicación en cuanto a formatos, tamaños y tipos de escenarios, resulta adecuado para corroborar la robustez de los métodos del estándar implementados por interMedia. En la Figura 9 se muestra un extracto del modelo del diario digital y la definición del UDT fotografias_ob y la tabla fotografias que se utilizará en los ejemplos posteriores.

Figura 9: Extracto del modelo del diario digital.

IV.2.1 Inserción de imágenes y extracción de características con SI_StillImage

Para ilustrar las inserciones de objetos SI_StillImage, en el siguiente código se inserta una imagen en el atributo foto de la tabla fotografias, que es de tipo SI_StillImage. En este caso se utiliza uno de los métodos constructores SI_StillImage(BLOB), que emplea como parámetro un objeto BLOB:

INSERT INTO fotografias
(edicion, noticia, numero_foto, . , foto)
VALUES (12564, 20, 2, ., new
ORDSYS.SI_StillImage(fotblob));

donde al atributo "foto", es de tipo SI_StillImage, y "fotblob" es de tipo BLOB.

En el punto anterior, solo se insertó la imagen binaria. Para extraer las características visuales se debe utilizar el método InitFeatures como sigue:

... foto.SI_InitFeatures;
...

Dado que en "foto" se almacenan tanto la imagen binaria como las características visuales, la primera mencionada debe guardarse en la tabla (en nuestro caso fotografías) para luego ser recuperada por contenido.

IV.2.2 Recuperación de imágenes con objetos del estándar Still Image

Las instancias de SIStilllmage contienen métodos para la recuperación por contenido. Para esto se debe valer de otros UDT del estándar Still Image, que contienen el método SI_Score(), que permite realizar consultas por contenido. Éstos son: SI_AverageColor, Sljexture, SI_ColorHistogram, SI_PositionalColor y SI_Featurel_ist. Las instancias de estos UDT se construyen a partir de una instancia de SIStilllmage, al que se han extraído sus características como se trató en V.2.1. Por ejemplo, para construir una instancia de SIAverageColor, se procede de la siguiente manera:

...
avgColor := NEW SI_AverageColor(foto);
...

Un ejemplo donde se compara la imagen insertada en V.2.1 con el resto de las imágenes de la tabla, se muestra a continuación:

...
SELECT foto INTO cmpfoto
FROM fotografías

WHERE edición = 12564 AND noticia = 20 AND numero = 2;
avgColor := NEW SI_AverageColor(cmpfoto);
SELECT foto INTO otrafoto
FROM fotografías
WHERE avgColor.SI_Score(otrafoto) < 10;

donde "cmpfoto" y "otrafoto" son de tipo SI_StillImage y "avgColor" de tipo SI_AverageColor ,y la medida de distancia que retorna el método SI_Score(), varía entre 0 (la coincidencia es total) y 100 (no hay similaridad).
En el ejemplo anterior, al utilizar la media de color, sólo se está comparando la proporción de rojo, verde y azul, sin tener en cuenta la posición. Utilizando la media de color solamente, las imágenes de la Figura 10 tendrían una coincidencia total ("score" = 0).

Figura 10: Ejemplo de imágenes diferentes con medias de color idénticas

Si se desea tener en cuanta la distribución espacial del color en la comparación de imágenes, se pude utilizar el UDT SI_PositionalColor, que tiene en cuenta la cantidad de color por posición. Para comparar varias características a la vez, se debe utilizar el UDT SI_FeatureList. Para este último, se debe crear una instancia utilizando un constructor al que se le debe pasar como parámetros los valores de media de color, histograma de colores, posición de colores y texturas con sus respectivos pesos.
En la Figura 11 se muestra la secuencia de pasos necesarios para realizar una consulta utilizando el método SI_Score() de un objeto SI_FeatureList. Este objeto se crea a partir de una foto de la tabla fotografía y luego se la compara con el resto de las fotos de la tabla.

Figura 11: Pasos para la recuperación por contenido empleando Sl_ Stilllmage

Se puede notar que el método SI_Score() toma como parámetro objetos del tipo SI_StillImage. Cuando se declara el cursor obtenerImagenes, se utiliza el método SI_Score() de un objeto "FeatFoto" de tipo SI_FeatureList que se crea antes de ejecutar dicho cursor (se puede observar subrayado en la Figura 11). La distancia obtenida con el método SI_Score() es igual al promedio de las distancias de cada característica ponderada por los pesos asignados a cada una, como se muestra en la siguiente ecuación:

donde los f_i, son las características visuales, los W_i son los pesos y n la cantidad de características.
En el ejemplo de la Figura 11 se le asigna igual peso a todas las características de la imagen, y como condición de salida de la consulta se pide que la distancia sea menor o igual a 10. Los resultados se muestran en la Figura 12. La imagen con "score = 0" es utilizada como base en la búsqueda y aquélla con "score = 7", corresponde a una foto del mismo objeto tomado desde otro ángulo.

Figura 12: Consulta utilizando el método SI_Score de SI_FeatureList.

V. Discusión y conclusiones

En este artículo se ha presentado un estudio sobre las capacidades y ventajas de la tecnología Objeto-Relacional para la gestión de imágenes quietas y, en particular, las dos posibilidades que posee Oracle 10g empleando un desarrollo propio (ORDImage) y el estándar Stil Image de SQL/MM. Se presentó también la implementación de dos aplicaciones. En la primera se utilizaron imágenes médicas concordantes con el estándar DICOM, que es específico para ese tipo de imágenes, en tanto que en la segunda se emplearon imágenes heterogéneas de un diario digital, para verificar la robustez de los métodos utilizados para el almacenamiento, extracción de metadatos y recuperación por contenido de imágenes.
En la gestión imágenes médicas que responden al estándar DICOM, se emplearon objetos predefinidos ORDImage y métodos provistos por el mismo para extraer sus metadatos. Para este caso, los metadatos a su vez se pueden almacenar en tablas relacionales o en documentos XML, dando la posibilidad de definir índices para mejorar la eficiencia en la recuperación de imágenes basadas en su contenido. Las experiencias realizadas en nuestro trabajo nos permiten concluir que los objetos y métodos provistos por el SGBDOR empleado facilitan la implementación de un servidor de imágenes médicas y potencian el uso y extensión del mismo.
En la segunda aplicación se utilizaron los UDT del estándar Still Image de SQL/MM. Al comparar con los objetos nativos de Oracle se puede notar que, si bien ambos presentan mecanismos muy robustos para la gestión de imágenes, los provistos por los objetos nativos de Oracle tienen una mejor performance que los que responden al estándar SQL/MM. Sin embargo, al utilizar objetos basados en el estándar SQL/MM se asegura una mayor portabilidad a otras aplicaciones. Por otra parte, la estructura de los metadatos de los objetos SI_StillImage es conocida (Figura 2), a diferencia de los UDTs ORDImageSignature, utilizados para extraer la signatura de las imágenes en objetos ORDImage, que almacenan las características visuales en objetos binarios de tipo BLOB.

Referencias bibliográficas

1. ALVEZ C.; VECCHIETTI, A. (2006). SQL: 1999 y SQL/MM para el Modelado y Diseño de Bases de Datos Multimedia, en: Workshop de Investigadores en Ciencias de la Computación WICC-2006. Morón: 351-355.         [ Links ]

2. ALVEZ, C.; VECCHIETTI, A. (2007). Representación y recuperación de imágenes médicas en bases de datos objeto-relacionales, en: Jornadas Argentinas de Informática e Investigaciones Operativas- 36ª JAIIO Simposio de Informática y Salud. Mar del Plata: 163-174.         [ Links ]

3. DICOM - Digital Imaging and Communications in Medicine (1993). http://medical.nema.org/ [3 de marzo de 2007]         [ Links ].

4. DÖLLER, M. (2006). MPEG-7 meets Multimedia Database Systems, en: Journal of Universal Knowledge Management: 18-25.         [ Links ]

5. ORACLE (2005a). interMedia Reference Manual, 10g Release 2 (10.2), Part No B14297-01, June.         [ Links ]

6. Oracle (2005b). XML DB Developer's Guide, 10g Release 2 (10.2), Part No B14259-02. June.         [ Links ]

7. GOLOBISKY, M.; VECCHIETTI, A. (2005). Mapping UML Class Diagrams into Object-Relational Schemas, en: Proceedings of ASSE 2005, vol 1: 65-79.         [ Links ]

8. KOSCH, H. (2002). Enhancement of Processing Efficiency in Multimedia Database Management Systems and Video Servers supported by the Use of Meta-Data, en: Informatics Colloquium. Klagenfurt: HS-C University.         [ Links ]

9. HL7 (2006). Reference Information Model (RIM), http://www.hl7.org/library/data-model/RIM/C30213/, [10 de marzo de 2007]         [ Links ]

10. ISO/IEC (2000). ISO/IEC 13249-1:2000, Information technology - Database languages - SQL Multimedia and Application Packages - Part 1: Framework, International Organization for Standardization.         [ Links ]

11. ISO/IEC, (2001). ISO/IEC 13249-5:2001, Information technology - Database languages - SQL Multimedia and Application Packages - Part 5: Still Image, International Organization For Standardization.         [ Links ]

12. MELTON, J.; EISENBERG, A. (2001). SQL Multimedia Application packages (SQL/ MM). ACM SIGMOD Record, 30(4): 97-102.         [ Links ]

13. MELTON, J., (2003). ISO/IEC 9075-2:2003 (SQL/Foundation), ISO standard.         [ Links ]

14. W3C, (1999). XML Path Language (XPath), W3C Recommendation 16 November 1999, http://www.w3.org/TR/xpath. [23 de mayo de 2007]         [ Links ]

15. W3C, (2006). Extensible Markup Language (XML) 1.0 (Fourth Edition) http://www.w3.org/TR/2006/REC-xml-20060816/, [20 de febrero de 2007]         [ Links ]