Imagem Digital em formato DICOM: Conteúdo e Estrutura

Transcrição

1 Acta Radiológica Portuguesa, Vol.XXIII, nº 92, pág , Out.-Dez., 2011 Nota Técnica / Technical Note Imagem Digital em formato : Conteúdo e Estrutura Digital Imaging in format: Its Content and Structure Luis Janeiro 1,2, Nuno Matela 2, Nuno Oliveira 2, Pedro Almeida 2 1 Escola Superior de Saúde da Cruz Vermelha Portuguesa, Lisboa 2 Faculdade de Ciências da Universidade de Lisboa, Instituto de Biofísica e Eng. Biomédica Resumo O objectivo deste trabalho é tentar ajudar a explicar o conteúdo e a estrutura de uma imagem médica em formato digital, que seja. Pragmaticamente, entende-se por ficheiro um ficheiro que contém uma ou mais imagens médicas armazenadas no sistema PACS do serviço ou gravadas num CD, que respeitam a norma. Propomo-nos, ainda, mostrar de que forma se faz a conceptualização do mundo real em objectos, como se constroem esses objectos a partir dos seus atributos relevantes e, finalmente, como se transpõem os atributos para o mundo digital, respeitando o disposto na norma. Terminamos com dois exemplos práticos, para os quais recorremos a software disponível gratuitamente na internet, com o objectivo de clarificar alguns dos aspectos referidos ao longo do texto. Palavras-chave Radiologia Digital;. Abstract In the present work our goal is to contribute to a better understanding of the content and structure of a digital medical image in format. Pragmatically, file stands for a digital file with one or more medical images, stored in a PACS or CD, in compliance with the standard. We also aim to show how objects are used to conceptualise the real world, how these objects are built from their relevant attributes and, finally, how objects are transposed to the digital world in accordance with the standard. For the sake of clarification, we conclude with two examples from practice, using a free software package available in the internet. Key-words Digital Radiology;. 1 - Introdução Nos tempos que correm a radiologia digital é cada vez mais omnipresente. Sendo certo que não se esgota na imagem digital, longe disso e cada vez mais basta pensar nos problemas técnicos, de segurança, éticos, etc., associados aos fluxos de informação a verdade é que a imagem digital é a base da radiologia digital. Uma imagem digital, médica ou não, mais não é do que um conjunto de pixéis (Picture Elements) organizados de uma determinada forma. Claro que, a informação codificada nesses pixéis tem as origens mais diversas, mesmo no domínio da imagem médica de diagnóstico, e, Recebido a 16/11/2010 Aceite a 07/10/2011 consequentemente, significados muito diferentes (pense-se, a título de exemplo, na forma completamente distinta como as imagens de TC e Ressonância são adquiridas e na informação que cada píxel traduz). Em todo o caso, considerado o processo físico de obtenção da imagem, toda a cadeia de transdução dos sinais e subsequente reconstrução de imagem / pós-processamento (quando for o caso), o objectivo é obter uma imagem, no caso vertente, digital. Porém, para além da necessidade de guardar a informação relativamente aos pixéis em si mesmos, é necessário guardar informação adicional que torne a imagem autosuficiente, isto é, que possibilite descodificar completamente o conteúdo dessa imagem de modo a que a sua abertura/leitura se faça correctamente, mas, ao mesmo tempo seja possível, por exemplo, perceber onde e em que condições foi adquirida. ARP 73

2 Este é um dos objectivos de qualquer norma que disponha sobre o formato dos ficheiros que contêm imagens médicas em suporte digital. As normas, e em particular a, vão, porém, muito para além disto. No entanto, para o trabalho presente, ficar-nos-emos pela tentativa de esclarecer alguns aspectos desta norma que permitam perceber o conteúdo de ficheiros com imagens médicas em formato. 2 - Nota breve sobre a origem da norma O standard (Digital Imaging and Communications in Medicine) é uma norma internacional que estabelece várias coisas relativamente à imagem médica digital, aos dispositivos físicos e software necessários para produzir essas imagens, bem como à gestão e circulação de toda a informação que lhes está associada. Está publicada com a referência NEMA PS3 e ISO 12052, e foi desenvolvida em conjunto pelo ACR (American College of Radiology) e pela NEMA (National Electrical Manufacturers Association). Quando, em 1983, o comité conjunto desenvolveu esta norma, pretendeu [1]: promover a circulação de informação digital entre dispositivos, independentemente do fabricante (isto é, reduzir o impacto causado pelo software proprietário e incompatibilidades daí decorrentes); facilitar o desenvolvimento e expansão de sistemas PACS (Picture Archiving and Communication Systems); potenciar a criação de bases de dados de auxílio ao diagnóstico, que pudessem ser consultadas a partir de um conjunto vasto de dispositivos em diferentes localizações geográficas. A norma original foi publicada em 1985 sob a designação ACR-NEMA, versão 1.0. Desde então foram publicadas várias revisões e constituídos diferentes grupos de trabalho, de modo a que a norma possa ser tão abrangente e versátil quanto necessário, respondendo aos desafios cada vez mais complexos levantados pelas tecnologias da informação. A partir de 2009 a norma NEMA PS3 passa a ser designada apenas por. Como se referiu, as exigências levantadas quer pelo desenvolvimento da imagem médica quer pelas tecnologias de informação de que faz uso extensivo, fazem com que, actualmente, a norma tenha de responder a muitos outros aspectos para além daqueles que foram inicialmente identificados. Uma descrição mais pormenorizada dos objectivos desta norma pode ser encontrada em [1]. Enquanto documento, a norma está dividida em diferentes partes (Fig. 1) [2]. É um documento extenso, modular, em que o grau de detalhe parece, por vezes, exagerado. No entanto, se pensarmos que o documento está feito de modo a que possa ser aumentado de forma coerente, percebe-se que as definições tenham de ser construídas com minúcia. A cada uma das partes da norma corresponde um documento designado PS 3.x, em que x é o número da parte. Por exemplo, o Dicionário (Data Dictionary) é denominado PS 3.6. No contexto do presente trabalho são especialmente importantes as partes 10, 5 e 6. A elas nos referiremos quando apresentarmos alguns conceitos fundamentais. 3 - Objectos e Atributos A norma, servindo o propósito da imagiologia digital, tem de passar para o mundo digital aquilo que é do mundo real, isto é, tem de conceptualizar o mundo real (na verdade, aquilo que no mundo real está associado à imagem médica). A perspectiva adoptada na concepção da norma aproxima-se da que está na base do paradigma de Part 1 Overview Part 2 Conformance Part 4 Service Class Specifications Part 3 Information Object Definitions Part 6 Data Dictionary Part 5 Data Structure & Encoding Part 11 Media Storage Application Profiles Part 7 Message Exchange Part 10 Storage Media and File Format Part 5 Security Profiles Part 8 Network Communication Support for Message Exchange Part 11 Media Formats and Physical Media Fig. 1 Representação das diferentes partes da norma (adaptado de [2]). 74 ARP

3 programação orientada a objectos. Isto é, o mundo real é conceptualizado através de objectos, cada um dos quais com um determinado conjunto de propriedades ou atributos. Por exemplo, um paciente do mundo real (Fig. 2) será conceptualizado em (transposto para o mundo digital) considerando, de entre os vários atributos que tem, aqueles que são fundamentais para o fim em causa. Do ponto de vista da radiologia digital, será pouco relevante a cor do cabelo ou o tipo de telemóvel que possui, mas já será importante saber a sua idade ou o seu número de paciente no centro de imagiologia. Será, pois, o conjunto dos atributos do paciente que são relevantes do ponto de vista da imagem médica que servirá para conceptualizar o objecto paciente. Procedimento análogo é adoptado para uma imagem médica que se pretenda cumpra com a norma. O que há a fazer é pensá-la como um objecto e reter, de entre os seus atributos, aqueles que são fundamentais para o efeito. Em suma, um objecto em mais não é do que o conjunto dos seus atributos. Em tese, poderíamos representar todos os objectos do mundo real que quiséssemos, para o que necessitaríamos de um número infinito de atributos. Ora, esta abordagem, para além de irrealista, revelar-se-ia também largamente inútil, na medida em que apenas nos interessa conceptualizar uma parte reduzida o mundo real. Logo, o número de objectos conceptualizados será finito, sendo também finito o número de atributos usados nesta conceptualização. Não obstante, será necessário impor regras, nomeadamente quanto: ao conjunto dos atributos que podemos usar em para conceptualizar os objectos (todos os objectos serão construídos a partir destes atributos e haverá atributos que serão parte integrante de diferentes objectos); ao modo de formatar esses atributos, isto é, ao modo de os representar no mundo digital. Ambas as questões são regulamentadas no âmbito da norma, aí se estabelecendo que a definição dos objectos e dos respectivos atributos é feita de acordo com Information Object Definitions (IODs). Mais: há em uma lista de todos os atributos disponíveis (Dicionário, parte 6 PS 3.6 [3]) são já em número superior a 2000-, do mesmo modo que são definidas 27 formas diferentes de formatar esses atributos, isto é, 27 Value Representation(s) diferentes. Na sequência do que foi dito nos parágrafos anteriores, importa clarificar o seguinte: se uma imagem médica é, em, um objecto, isto significa que é um conjunto de atributos bem definidos, formatos de acordo com regras precisas. Logo, um ficheiro com uma imagem médica deverá conter o conjunto destes atributos em suporte digital. E, se quisermos usar uma terminologia mais próxima do, diremos que os atributos são, afinal, Data Elements ou s e, portanto, um ficheiro com uma imagem médica é, em resumo, um conjunto organizado de vários Data Elements, cada um deles representando em suporte digital um atributo do objecto em causa (a imagem). O conjunto destes os, com a coerência que lhe é conferida pela norma, é a tradução digital da conceptualização do objecto imagem médica. Esta coerência obriga, por exemplo, a que os os estejam organizados em grupos, de acordo com a sua natureza ou função. Na secção seguinte tentaremos explicar um pouco melhor a formatação dos diferentes os. Para a parte final do trabalho reservamos a discussão da organização dos os em grupos, bem como dos grupos dentro de um ficheiro. 4 - Elementos ( s) A estrutura de um o é a que se ilustra da Fig. 3. O atributo em si mesmo é representado por um valor, o qual, dentro da estrutura do o, está guardado no último campo ( VALOR, na Fig. 3). Os outros três campos passam a explicar-se de seguida Tag Cada o é identificado univocamente por uma tag. Por um lado, quando para a construção de um objecto é necessário aquele o, ele é sempre : objecto paciente Mundo real: paciente Nome John Smith ID Data de nasc Peso 79 Sexo M Fig. 2 Exemplo da conceptualização de um paciente e sua representação enquanto objecto. ARP 75

4 FICHEIRO... Tag VR Tamanho do valor VALOR Campo optativo Fig. 3 Estrutura de um o (adaptado de [3]). identificado por aquela tag; por outro, essa tag está reservada para aquele o, não podendo corresponder a nenhum outro. Como se disse, tendo por base a sua natureza ou função, os os são organizados em diferentes grupos. Logo, a tag deve reflectir isto mesmo: indicar qual é o grupo a que o o em causa pertence, bem como a ordem específica dentro desse grupo. Por esta razão, a tag é um par ordenado de inteiros com 16 bits (2 bytes) cada, sendo o primeiro reservado para a informação sobre o grupo e o segundo para indicação do número de ordem dentro desse grupo, como se pode ver esquematicamente na Fig. 4. Tomemos como exemplo o atributo nome do paciente, parte integrante do objecto imagem. Sendo um atributo essencial de uma imagem, é expectável que a norma tenha previsto a sua existência. Para o comprovar, consulta-se o Dicionário, verificando-se que, efectivamente, está definido um o para esse atributo, cuja tag é (0010,0010). Descodificando esta tag, concluímos que pertence ao grupo 0010, sendo neste grupo o o com o número de ordem Ainda neste grupo, os os com os números de ordem 0020, 0030 e 1010, são, respectivamente, a identificação do paciente (0010,0020), a data de nascimento (0010,0030) e a idade do paciente (0010,1010). Grupo Fig. 4 - Estrutura de uma tag. Nº. o no grupo g g g g e e e e 1 byte 1 byte 1 byte 1 byte 1 inteiro 1 inteiro Posto isto, uma questão de levanta: por que razão são necessários 4 dígitos para representar cada um dos inteiros? A resposta prende-se com o facto de esses dígitos serem dígitos em numeração hexadecimal. Ora, em hexadecimal são necessários 2 dígitos para representar um byte, o que significa que serão precisos 4 para codificar um inteiro com 2 bytes, como é o caso. Terminando a discussão em relação à tag, importa ter presente que quando, por simplicidade, dizemos que o nome do paciente corresponde a um o do grupo 0010, estamos, de facto, a usar o sistema numérico hexadecimal. 4.2 Value Representation (VR) Tal como se refere na Fig. 3, trata-se de um campo optativo. A sua presença, ou não, na estrutura do o depende da Transfer Syntax UID, isto é, do protocolo que for adoptado para a transferência do ficheiro entre a máquina em que foi produzido e o dispositivo de armazenamento. Estando presente, porém, terá de ser um dos 27 VRs definidos pela norma, explicados na parte PS 3.5 [4]. Voltaremos a este assunto mais tarde. Os objectivos deste campo são: dar indicação sobre o tipo de informação que o o contém do seu valor; estabelecer o conjunto de caracteres que pode ser usado para a representação desse valor. Consultando a parte PS 3.5, verificamos que alguns dos VRs possíveis são: PN (para Person Name ), DA ( Date ), DS ( Decimal String ), etc. Para uma data, ou seja, um VR do tipo DA, por exemplo, a norma define que só podem ser usados os caracteres 0 a 9, o que significa que no campo que contém o valor relativo a este o apenas é autorizada a utilização daquele conjunto de caracteres. Na parte 5, ainda a propósito dos diferentes VRs, verificamos que para alguns VRs é definido o número máximo de bytes que podem ser usados para representar o valor (por exemplo, para um o cujo VR seja do tipo DA, o número de bytes usados para o valor é fixo e igual a 8), ao passo que, para outros, apenas se estabelece um máximo (no caso de um VR do tipo CS Code String podem ser usados no máximo 16 bytes). Isto significa, na prática, que nem sempre é possível saber a partir do VR qual é o tamanho do campo onde vai ser guardado o 76 ARP

5 valor, o que justifica que na estrutura do o deva existir um campo para guardar explicitamente essa informação. Nos casos em que VR está presente tem, obviamente, de ser reservado espaço na estrutura do o para guardar essa informação. Como a informação é codificada por um par de caracteres e cada caracter usa 1 byte, o tamanho do campo VR é, ele mesmo, de 2 bytes. 4.3 Tamanho do valor (VL Value Length) Como se disse no ponto anterior, nem todos os VRs obrigam a que o número de bytes em que se vai guardar o valor seja fixo; alguns estabelecem apenas máximos. Por conseguinte, torna-se necessário que haja na estrutura do o um campo reservado para guardar informação sobre o tamanho do valor. Esse campo surge imediatamente a seguir a VR (ou à Tag, nos casos em que aquele não está presente) e, em inglês, é denominado Value Length. É um campo obrigatório que indica, portanto, o número de bytes reservados para armazenamento do valor do o. Sem esta informação para todos os os, não seria possível saber onde começa e acaba cada um deles, o que inviabilizaria completamente a leitura correcta do ficheiro. A norma estabelece que todos os os devem ter um comprimento par. Logo, quando isto não acontece originalmente, tem de se adicionar um byte extra de modo a garantir o cumprimento desta condição. Por exemplo, se estiver em causa o nome do paciente e este for constituído por um número ímpar de caracteres, à string original será adicionado um espaço em branco para forçar o comprimento par. Se, por outro lado, o valor for dado por algarismos e for necessário adicionar um byte, adicionarse-á o byte correspondente ao valor NULL. Ao contrário do que acontece para a Tag e para VR, o espaço reservado para o campo Value Length não é sempre o mesmo. Depende, uma vez mais, da Transfer Syntax UID: há casos em que são reservados 2 bytes para guardar o tamanho do valor, mas há outros em que são reservados 4. Em suma: a estrutura de um o é a que se discute nos pontos anteriores. Porém, o tamanho do o depende da Transfer Syntax UID, podendo, inclusivamente, diferir da soma dos tamanhos da Tag, VR (quando estiver presente), Value Length (VL) e do valor em si mesmo. Isto é, o tamanho do o pode não ser igual à soma dos tamanhos dos 4 campos identificados na Fig. 3, devido à possibilidade de existência de bytes reservados no meio desta estrutura (nomeadamente entre VR e VL). A questão do tamanho prende-se com três coisas: existência, ou não, do campo VR; tamanho do campo VL (2 ou 4 bytes); existência, ou não, de 2 bytes reservados. Certas são também duas coisas: num ficheiro, todos os os que traduzem atributos do objecto têm exactamente a mesma estrutura e tamanho; a estrutura e tamanho dos os é definida inequivocamente pela Transfer Syntax UID, a qual deve constar no ficheiro. 5 O ficheiro Vimos já que há pelo menos uma coisa que não é directamente um atributo do objecto mas que deve ser acrescentada ao ficheiro que contém a imagem digital, de modo a que seja possível descodificá-lo: a Transfer Syntax UID. Serve isto para dizer que o ficheiro com o objecto imagem, para além de conter os os com os atributos desse objecto aquilo que é o essencial e a que se chama Data Set contém mais alguma informação adicional agrupada num cabeçalho prévio ao objecto, denominado File Meta Information. Esquematicamente, um ficheiro com uma imagem digital pode representar-se do seguinte modo (Fig. 5): Quanto ao Data Set, isto é, aos os que dizem directamente respeito ao objecto, importa sublinhar que cada o pode aparecer no máximo uma vez. Por outro lado, os os estão organizados por ordem crescente da sua tag e agrupados de acordo com a sua natureza. Por exemplo: o grupo (0010) reúne todos os os relativos ao paciente (nome, ID, peso, altura, data de nascimento, etc.); o grupo (0028) contém informação sobre a imagem (número de linhas, número de colunas, profundidade dos pixéis, etc.); os grupos ímpares (como, por exemplo, o (0009)) são reservados para uso privado. Assim sendo, espera-se que no ficheiro apareçam primeiro todos os os do grupo (0008), depois os do grupo (0010), e assim sucessivamente. Chegados a esta altura do trabalho, será importante esclarecer onde estão, afinal, armazenados os bytes relativos à imagem propriamente dita. Efectivamente, esta é um dos atributos do objecto imagem: o mais importante, certamente, mas apenas um. Logo, terá de haver um o que tenha como valor todos os bytes da imagem. Esse o é o o (7fe0,0010) e é o últimos de todos os que constituem o ficheiro digital. Ou seja, depois de tudo o resto, aparece finalmente o conjunto de bytes relativos à imagem digital. No outro extremo, como vimos, está a File Meta Information. 5.1 File Meta Information A File Meta Information (FMI) é um cabeçalho obrigatório no início de cada ficheiro (ver Fig. 5). Começa por incluir um preâmbulo com 128 bytes que, não sendo especialmente relevante (o seu conteúdo, é regra geral, ignorado por Viewers ou outro software para editar imagens ), tem de estar presente para que o ficheiro cumpra com a norma. Seguem-se-lhe 4 bytes (bytes 128 a 131), cada um dos quais com uma das letras seguintes, pela ordem indicada: D, I, C, M. Uma vez mais, não contendo nenhuma informação extraordinária, são mais um indicador de que o ficheiro é, provavelmente, um ficheiro, o que só poderá ser confirmado se houver o cumprimento efectivo de todos os outros requisitos de que temos vindo a falar. File Meta Data SET (Conjunto de os relativos ao objecto) Fig. 5 Representação esquemática de um ficheiro com uma imagem digital. ARP 77

6 A restante informação contida neste cabeçalho está organizada por os, em sintonia com o que se passa no objecto propriamente dito. Os os da FMI correspondem ao grupo (0002). Uma descrição detalhada de cada um dos os da FMI pode ser encontrada na parte 10 do standard [2]. O primeiro o da FMI tem a tag (0002,0000). Daqui deduzimos, portanto, que para além de se tratar de um o do grupo (0002), tem o número de ordem 0000 dentro deste grupo. Ora, quando existem, para este ou outros grupos, os os (gggg,0000) contêm informação sobre o tamanho do grupo em causa. Percebese que seria interessante que estes os existissem sempre, uma vez que seriam pontos de referência através dos quais poderíamos navegar mais facilmente pelo ficheiro, saltando, por exemplo, por cima dos grupos que não nos interessassem e indo directamente para o grupo a que pertencesse um determinado o cujo valor quiséssemos conhecer. Quanto aos restantes os da FMI, não nos vamos deter na sua explicação, uma vez que não é esse o objectivo do presente trabalho. Há um, porém, que pela sua relevância e pelo facto de ter sido já nomeado, será visto a seguir com um pouco mais de detalhe: a Transfer Syntax UID. 5.2 Transfer Syntax UID A Transfer Syntax UID é o nome do o (0002,0010), um dos que constitui a FMI. O seu valor contém aquilo que pode ser entendido como um código para a forma como os dados vão ser transferidos entre os dispositivos em questão: no caso, o dispositivo que produz a imagem e aquele onde se guarda o ficheiro. Este código pode ter vários valores, cuja função exacta está descrita no Dicionário. Para aquilo que interessa no contexto do presente trabalho, há dois aspectos codificados neste o que são de especial relevância: a informação quanto à ordem dos bytes e a que determina se o valor de VR está explícito ou implícito. Por exemplo, se o valor contido neste o for , isso significa que os os relativos ao objecto estão codificados como Implicit VR Little Endian, que é, aliás, a codificação por default em. Ou seja: quanto à ordem dos bytes, eles estão organizados do menos significativo para o mais significativo Little Endian. O facto de ser Implicit VR significa que, na estrutura do o, o campo relativo ao tipo de representação não existe. Retomando a Fig. 3, cada o terá na sua estrutura apenas a Tag, o Value Length e o valor propriamente dito. Finalmente, quanto ao tamanho destes os, consultando as tabelas 7.1 da parte PS 3.5 [4], constatamos que são usados 4 bytes para o Value Length e não há bytes reservados. Logo, o tamanho dos os de um objecto cuja transferência tenha este código, será: 4 (2 +2) (tag), mais 4 (Value Length), mais o tamanho indicado no campo Value Length. 6 - Exemplos de Aplicações Práticas Para concluir este trabalho deixamos dois exemplos práticos que permitem concretizar o que foi exposto até aqui. Para tanto, far-se-á uso de software específico disponibilizado gratuitamente na internet. Dos pacotes de software disponibilizados gratuitamente que permitem visualizar a estrutura de ficheiros com imagens digitais, alguns permitem ainda editar os. Um dos que apresenta diversas funcionalidades interessantes e é modular, instalando-se apenas as componentes pretendidas, é o DVTk (adopta-se este software não porque seja melhor ou pior que outros não pretendemos, de todo, fazer essa avaliação -, mas tão somente porque: 1) é gratuito; 2) é de utilização bastante simples; 3) permite-nos resolver os dois problemas concretos que temos em mãos) [5]. Vamos, portanto, usar algumas das suas potencialidades para abordar dois problemas concretos. 6.1 Tornar anónima uma imagem Uma aplicação importante é tornar uma imagem anónima. O DVTk oferece duas variantes: a básica e a completa. A diferença reside no número de campos cujo valor é alterado. No caso de se optar pelo processo básico para tornar a imagem anónima são alterados os valores de 8 os (os mais óbvios): (0008,0050) Accession Number; (0008,0080) Institution Name; (0008,1060) Name of Physician(s) Reading Study; (0008,1070) Operators Name; (0010,0010) Patient s Name; (0010,0020) Patient ID; (0010,0040) Patient s Sex e (0010,1010) Patient s Age. Na opção completa, para além do valor destes os, são alterados mais dez: (0008,0018), (0008,1010), (0008,1030), (0008,103e), (0010,0030), (0018,1030), (0020,000d), (0020,000e), (0020,0010) e (0020,0052). A identificação dos os alterados é feita automaticamente pelo programa. 6.2 Extrair os bytes relativos à imagem A solução que apresentamos pretende ser pedagógica e não necessariamente a mais elegante. Se quisermos extrair para um ficheiro apenas a parte dos dados relativos à imagem, necessitamos, em primeiro lugar, de saber quantos bytes estão em causa. Para tanto, retomamos o raciocínio apresentado no início deste trabalho: o número de bytes da imagem é igual ao produto do número de colunas, pelo número de linhas (de que resulta o número de pixéis), pela profundidade dos pixéis. A informação relativa ao número de linhas e colunas está nos os (0028,0010) e (0028,0011), respectivamente. Quanto à profundidade dos pixéis, está expressa em bits no o (0028,0100), denominado Bits Allocated. Todavia, pode dar-se o caso de o valor não ser múltiplo de 8 (número de bits num byte). Nestas situações, e porque o armazenamento da informação é feito em bytes, usa-se o menor múltiplo de 8 bits que seja superior àquele valor, sendo esse múltiplo o número de bytes efectivamente usados para guardar a informação contida em cada píxel. Ou seja, isto significa que, na prática, não é exactamente a profundidade dos pixéis que 78 ARP

7 condiciona o tamanho, em bytes, da imagem, mas o número mínimo de bytes que pode acondicionar a profundidade dos pixéis. Este número é um atributo da imagem, traduzido no o (0028,0101) Bits Stored. Reformulando o raciocínio em função do exposto no parágrafo anterior, o tamanho, em bytes, da imagem (a que chamaremos y) será dado pelo produto do número de colunas, pelo número de linhas, pelo número de bytes usados para armazenar o valor de cada píxel. Se usarmos o Explorador do Windows (ou equivalente noutro sistema operativo) para verificar o tamanho total do ficheiro, obtemos um valor. Se subtrairmos a este valor o valor y, obtemos o número de bytes que temos de saltar no ficheiro até chegarmos ao primeiro byte da imagem, que designaremos por z. Na posse deste número podemos escrever uma rotina simples, numa linguagem de programação que conheçamos, para extrair a totalidade dos bytes correspondente à imagem, e apenas estes. Essa rotina deve compreender os seguintes passos: 1) abrir o ficheiro ; 2) apontar para o byte z; 3) extrair y bytes a partir do byte z. Vale a pena dizer, para terminar, que nem sequer seria necessário fazer as contas que fizemos para chegar ao tamanho, em bytes, da imagem. De facto, se nos lembrarmos que na estrutura de cada o deve constar o tamanho, também em bytes, do campo com o valor desse o, então pela consulta do campo Value Length para o o (7fe0,0010) obtém-se automaticamente o tamanho da imagem. 3. National Electrical Manufacturers Association - Digital Imaging and Communications in Medicine (), Part 6: Data Dictionary, Rosslyn, VA, USA, National Electrical Manufacturers Association - Digital Imaging and Communications in Medicine (), Part 5: Data Structures and Encoding, Rosslyn, VA, USA, [acesso em 25 de Outubro de 2010]. Correspondência Luis Janeiro Escola Superior de Saúde da Cruz Vermelha Portuguesa Edifício Urbiceuta Av. de Ceuta, nº Lisboa ljaneiro@esscvp.eu 7 - Conclusão Pretendeu-se com este trabalho dar a conhecer um pouco melhor a forma como está organizado um ficheiro com uma imagem médica em formato e o modo como esse conhecimento pode ser explorado através da utilização de algumas ferramentas informáticas disponibilizadas gratuitamente on-line. Como se referiu, a definição de regras para guardar imagens é apenas uma das valências da norma. O passo seguinte neste contexto, que se deixa a título de sugestão, poderá ser o estudo da norma do ponto de vista da circulação das imagens numa rede de dispositivos, nomeadamente quanto aos requisitos básicos que esses dispositivos devem satisfazer e qual o protocolo que rege a comunicação. Abreviaturas FMI: File Meta Information. IOD: Information Object Definition. VL: Value Length. VR: Value Representation. Referências Bibliográficas 1. National Electrical Manufacturers Association - Digital Imaging and Communications in Medicine (), Part 1: Introduction and Overview, Rosslyn, VA, USA, National Electrical Manufacturers Association - Digital Imaging and Communications in Medicine (), Part 10: Media Storage and File Format for Media Interchange, Rosslyn, VA, USA, ARP 79