Recupera¸c˜ao Combinando Metadados e Conte´ udo de Imagens DICOM

5.2 A Extens˜ao MedFMI-SiR

5.2.3 Recupera¸c˜ao Combinando Metadados e Conte´ udo de Imagens DICOM

As versões mais recentes do SGBD Oracle possuem suporte a dados DICOM, por meio do módulo Oracle Multimedia DICOM (introduzido na Se¸cão 3.4.2). O módulo Multimedia DICOM permite que as imagens DICOM sejam armazenadas no banco de dados utilizando um tipo de dados especial, que extrai os metadados do cabe¸calho da imagem e os armazena em formato XML, utilizando o subsistema de gerenciamento de dados XML nativo do SGBD Oracle. Tendo os dados DICOM armazenados no banco de dados, as aplica¸cões médicas que manipulam os bancos de imagens podem se beneficiar de todos os recursos providos pelo SGBD, tais como controle de acesso e seguran¸ca, execu¸cão concorrente, garantia de integridade, entre outros. Além disso, armazenando o cabe¸calho das imagens DICOM em XML, é poss´ıvel efetuar buscas baseadas em metadados diretamente em senten¸cas SQL.

Para ilustrar a recupera¸cão de imagens combinando metadados e conteúdo de imagens médicas no MedFMI-SiR, considere uma rela¸cão para armazenar imagens DICOM definida como segue:

CREATE TABLE exam_images ( img_id INT PRIMARY KEY,

dicom_img ORDDICOM NOT NULL);

onde o atributo img_id é um identificador único e o atributo dicom_img armazena as imagens DICOM no tipo proprietário ORDDICOM, fornecido pelo Oracle Multimedia DICOM. Considere, também, que existe uma outra rela¸cão associada à rela¸cão exam_images que guarda os vetores de caracter´ısticas das imagens, definida como:

CREATE TABLE exam_signatures (

img_id INT PRIMARY KEY REFERENCES exam_images(img_id), img_sign BLOB);

onde img_sign é o atributo usado para armazenar os vetores de caracter´ısticas das imagens. Neste exemplo, utilizam-se duas rela¸cões separadas para guardar os dados relativos às imagens armazenadas. Embora possa ser utilizada apenas uma rela¸cão, a abordagem adotada de usar duas delas é melhor porque em uma institui¸cão médica normalmente o banco de imagens é compartilhada entre várias aplica¸cões usadas na rotina da institui¸cão, sendo que muitas delas não fazem uso de recupera¸cão por conteúdo, e que a quantidade de imagens armazenadas é tipicamente grande (da ordem de milhões de imagens).

Inicialmente, as imagens DICOM devem ser carregadas no banco de dados. Em seguida, são invocadas a fun¸cão para extra¸cão de caracter´ısticas do MedFMI-SiR e a fun¸cão para extra¸cão dos metadados do cabe¸calho das imagens (fun¸cão setProperties() do tipo ORDDICOM). Depois disso, é poss´ıvel consultar o banco de imagens utilizando opera¸cões baseadas em metadados e opera¸cões baseadas em similaridade.

A opera¸cões de consulta baseadas em metadados utilizam os operadores SQL de consulta sobre dados XML do Oracle. Já as opera¸cões baseadas em similaridade utilizando os operadores fornecidos pelo MedFMI-SiR, sob as diversas formas apresentadas na se¸cão que descreve o FMI-SiRO. Por exemplo, considere a Consulta 15, definida como segue.

Consulta 15: Dentre as 50 imagens de exames mais similares `a imagem de consulta, representada pelo vetor de caracter´ısticas center_sign, retorne aquelas que sejam de s´eries de protocolos de epilepsia de rotina (Routine Epilepsy Protocol ).

A Consulta 15 utiliza uma condi¸cão baseada em metadados (a descri¸cão da série deve ser Routine Epilepsy Protocol ) e uma condi¸cão baseada em similaridade (consulta aos k-vizinhos mais próximos). Esta consulta pode ser expressa no MedFMI-SiR como:

SELECT e.dicom_img

FROM exam_images i, exam_signatures s WHERE i.img_id = s.img_id

AND Manhattan_kNN(s.img_sign, center_sign) <= 50 AND extractValue(i.dicom_img.metadata,

’/DICOM_OBJECT/LONG_STRING[@tag="0008103E"]/text()’) = ’Routine Epilepsy Protocol’;

onde Manhattan_kNN é o operador de consulta aos k-vizinhos mais próximos do MedFMI-SiR para a fun¸cão de distância Manhattan, retornando os 50 vizinhos mais próximos a center_sign dentre os valores de img_sign, e extractValue é uma fun¸cão que percorre um “arquivo” XML, no caso, a propriedade metadata do atributo dicom_img (definida no tipo ORDDICOM), retornando os valores que casam com a expressão de caminho fornecida (’/DICOM OBJECT/LONG STRING[@tag="0008103E"]/text()’). A descri¸cão da série (Series Description) de uma imagem é armazenada na tag DICOM (0008,103E), in- formada na expressão de caminho da consulta. Toda tupla da rela¸cão exam_images cujo valor de retorno da fun¸cão extractValue seja igual à string de compara¸cão (’Routine Epilepsy Protocol’) satisfaz a condi¸cão baseada em metadados fornecida.

As consultas com condi¸cões baseadas em metadados DICOM são bastante custosas, pois exigem recuperar cada tupla da tabela de entrada e processar o arquivo XML contendo os metadados. Entretanto, é poss´ıvel agilizar muito o processo de busca definindo um ´ındice baseado em fun¸cão sobre o resultado da fun¸cão extractValue. A instru¸cão a seguir define um ´ındice sobre o conteúdo da tag DICOM (0008,103E), para acelerar a consulta apresentada no exemplo:

CREATE INDEX dicom_series_description_ix ON exam_images i ( extractValue(i.dicom_img.metadata,

’/DICOM_OBJECT/LONG_STRING[@tag="0008103E"]/text()’)); indexando o resultado da fun¸cão extractValue para a tag DICOM Series Description. Na verdade, esta instru¸cão adiciona um atributo oculto à rela¸cão exam_images para armazenar o resultado da fun¸cão e cria um ´ındice (B-tree) sobre este atributo. Com a cria¸cão deste ´ındice, a verifica¸cão da condi¸cão baseada em metadados é verificada diretamente no ´ındice, evitando o processamento do arquivo XML.

No exemplo, como trata-se de uma busca combinando duas condi¸cões, se houver um ´ındice no atributo image_sign, este ´ındice também poderá ser usado na execu¸cão da consulta. O MedFMI-SiR permite gerar planos de execu¸cão alternativos para a consulta, que podem ser explorados para otimizar o desempenho da execu¸cão, dependendo das opera¸cões existentes na consulta e das seletividades das condi¸cões de busca. Esta é uma caracter´ıstica herdada do módulo FMI-SiRO. Esta potencialidade é particularmente útil

para aplica¸cões sobre grandes bancos de dados complexos, que demandem consultas en- volvendo condi¸cões baseadas em metadados e baseadas em similaridade, como é o caso de aplica¸cões médicas com suporte a recupera¸cão por conteúdo. Infelizmente, o módulo não é capaz de guiar o processador de consultas na tarefa de otimiza¸cão, ficando a cargo do programador a escrita da consulta em sua forma mais eficiente.

5.3 Experimentos Sobre o M´odulo FMI-SiR

O módulo FMI-SiR foi testado sobre várias conjuntos de imagens. Esta se¸cão apresenta resultados de experimentos comparando a recupera¸cão de imagens por conteúdo no SGBD Oracle usando o módulo FMI-SiRO e usando o módulo padrão de CBIR do Oracle inter-

Media (introduzido na Se¸cão 3.4.2), referenciado nesta se¸cão como Oracle padrão.

O conjunto de imagens utilizada nestes experimentos foi a ALOI3 _{(Amsterdam Library}

of Object Images – biblioteca Amsterdam de imagens de objetos) (Geusebroek et al., 2005), que é uma cole¸cão de imagens coloridas de mil pequenos objetos, com 108 imagens de cada objeto, variando a cor de ilumina¸cão, o ângulo de ilumina¸cão e o ponto de vista, totalizando 108.000 imagens. A Figura 5.5 apresenta uma amostra das imagens deste conjunto.

Figura 5.5: Amostra das imagens do conjunto ALOI.

O conjunto de imagens foi carregada no banco de dados utilizando os mecanismos de carga em lote. Para cada imagem foram gerados quatro vetores de caracter´ısticas:

1. Oracle padrão: vetor de caracter´ısticas OrdImageSignature, do módulo de CBIR do Oracle, que inclui as caracter´ısticas de Cor, Forma e Textura utilizadas pelo módulo da Oracle;

2. Histograma: histograma de cores de 256 bins, utilizado pelo FMI-SiRO como vetor

de caracter´ısticas de Cor;

3. Zernike: vetor contendo os primeiros 256 momentos de Zernike, utilizado pelo FMI-SiRO como descritor de Forma; e

4. Haralick: vetor com descritores de Haralick, totalizando 140 caracter´ısticas, utilizado pelo FMI-SiRO como descritor de Textura.

Em seguida, foram realizados vários testes em um SGBD Oracle Database 11g Enter- prise Edition Release 11.1.0.6.0 64bit, sobre o sistema operacional Kubuntu GNU/Linux 8.10 64bit, executado em uma máquina equipada com um processador Intel Core 2 Quad 2.83GHz, 4GB of memória RAM e um disco r´ıgido SATA2 de 750GB e 7.200RPM. As próximas se¸cões apresentam os resultados destes experimentos.

No documento Tratamento de condições especiais para busca por similaridade em bancos de dados... (páginas 164-168)