Versão do VMTK que importa os arquivos de Philips-Achieva 3T

Autora: Wu Shin - Ting

Revisado em 28/02/2010
Revisado em 02/01/2010
Primeira Versão: 30/10/2009

• Organização do Aplicativo VMTK
• Código Executável para Windows com bibliotecas estáticas (é necessário instalar a biblioteca de gdcm por causa da base de especificação DICOM): versão mais recente. As imagens dos ícones necessários para o aplicativo estão contidos neste arquivo. O arquivo deve ser desemcopactado e colocado no mesmo diretório do executável. Dicas de instalação de gdcm podem ser encontradas aqui. Se o aplicativo Visual Studio C++ não estiver instalado na máquina, instale vcredist_x86.exe. Este é um arquivo executável de extração automática que instala a versão mais recente dos arquivos de tempo de execução do Microsoft Visual Studio e componentes do sistema operacional necessários para a maioria dos projetos criados com Visual Studio.
• Características da versão atual:
1. Roda-se em placas de vídeo de distintos fabricantes. Os shaders implementados em assembler da NVidia foram re-implementados em GLSL - uma linguagem de shading em alto nível - suportada por uma grande variedade de placas programáveis. Como exercício foram traduzidos os shaders do aplicativo Spvolren em GLSL. Os shaders traduzidos estão disponíveis aqui (28/02/2010).
2. É executável na plataforma Linux (28/02/2010).
3. Implementada com uso das bibliotecas OpenGL para placas programáveis NVidia série GeForce 6600GT ou superior, gdcm, wxWidgets, glew e glut.
4. Só importa um exame através da seleção de um dos arquivos nome no diretório DICOM do exame de interesse (File > ImportDICOM ...). O nome do arquivo deve conter uma sequencia de caracteres a-z ou A-Z.
5. A cada série de um exame é aplicada a seguinte sequência de processamentos: Equalização, Derivação de Gradientes, Filtragem de Gradientes, Quantização de Gradientes. Pode-se acompanhar o fluxo pela mensagem na barra de estado da janela (barra inferior). Os resultados são armazenados em nome.raw (arquivo de valores de densidade equalizados da imagem 3D) e nome.grd (arquivo de gradientes em cada amostra). Adicionalmente, há ainda um meta-arquivo nome.dat que descreve a caracterísitca geral da imagem 3D. O diretório onde estes arquivos devem ser armazenados deve ser selecionado no momento de importação (caixa de diálogo com o último campo preenchido por DAT Files). Vale comentar que são gerados ainda alguns arquivos temporários ao longo do processo. Na versão atual, somente a série VBM é extraída e visualizada.
6. Os arquivos *.dat, *.raw e *.grd são lidos para formar uma textura 3D a ser carregada na memória de vídeo. Caso estes já tenham sido gerados, pode-se lê-los diretamente através do comando File > Open...
7. Quando o volume de dados ultrapassa de em torno 1/4 da capacidade da memória de vídeo (128MB), os valores de densidade são quantizados para 1 byte automaticamente.
8. O processo é lento. Para a máquina em que estamos trabalhando, AMD Athlon 64-RAM 1GB-GPU GeForce 6600 512MB, os arquivos obtidos através do novo aparelho, Philips-Achieva-3T, levam em torno de 15 a 25 minutos para serem pré-processados.
• Images 3D testadas: algumas do aparelho antigo 2T e o conjunto de imagens que o Bergo nos passou em um DVD.
• Exemplos: Conjuntos de imagens pré-processadas Philips-Achieva 3T (limiar = 200) e Elscint 2T (limiar = 200), (limiar = 350). Na máquina em que fizemos os testes, estes arquivos se encontravam no diretório G:\DICOM\output1. Ao copiá-los para a sua máquina deve-se trocá-lo para o diretório em que foram copiados, re-editando os arquivos *.dat.
• Problemas e possíveis soluções:
  1. Ocupação de memória é crítica: Como só usamos os gradientes para orientar a direção do cursor em cada iteração. Os valores dos gradientes poderiam ser computados localmente, on-the-fly. Não precisamos enviar os gradientes para placa de vídeo.
  2. O ajuste do limiar é demorado, pois cada ajuste requer o reprocessamento da imagem 3D. Uma possível solução seria prover uma interface interativa para apoiar este ajuste.
  3. A versão atual não consegue ainda interpretar os meta-arquivos DICOMDIR. Conjeturo que, interpretando diretamente estes meta-arquivos, podemos melhorar o desempenho de pré-processamento.
  4. Só se visualizem as imagens 3D da série VBM do aparelho 3T no formato que o Bergo nos passou e as imagens 3D do aparelho 2T que a Clarissa nos passou. É necessário que esta importação seja mais flexível. Uma solução seria adotar o esquema de importação que os exemplos de aplicativo da biblioteca gdcm utiliza.
  5. Cropping só pode ser feito na região visível e em uma área conexa. A solução poderia ser introduzir um procedimento de costura para juntar as regiões pintadas separadamente. Um algoritmo para tal já foi proposto pelo nosso grupo de pesquisa.
     

  6. Ao descascar um volume de alta resolução, aparecem várias falhas. Tais falhas se devem ao processamento interno baseado em um fator de escala empírico, ao invés de estimar este fator com base na transformação de projeção. Uma solução seria aplicar o algoritmo de descascamento diretamente no espaço do volume de dados.