Acelerar carga de imágenes desde archivo

[Casimiro Noteví]

Hola, ¿y en qué tarda?, ¿descargarla, la red, el disco, procesado, presentación, etc.?, ¿lo has comprobado?

[radenf]

Empezado por Casimiro Notevi

Hola, ¿y en qué tarda?, ¿descargarla, la red, el disco, procesado, presentación, etc.?, ¿lo has comprobado?

Estimado Casimiro Notevi:

Muchas gracias por responder.
La demora se produce al cargar las imágenes desde el disco duro en la tabla temporal (CnsDMTable1), que está conectada al Visor (DicomMultiViewer1), dependiendo del tamaño del archivo puede ser desde unos segundos hasta 1-2 minutos. Esto ocurre en mi computador (HpWorkstation Z1) que posee un procesador Xeon de 8 núcleos, de 3.4 Ghz, con 16 Gb de Ram y un SSD de 240 Gb, aunque estoy seguro que todo ese potencial no lo aprovecha ni mi programa ni Delphi, por ser de 32 bits. Otros programas comerciales similares no presentan tanto retraso.
Es posible implementar streams o threads que aceleren el proceso. Si bien he leido algo sobre estos no tengo idea de como se pueden implementar.

Saludos

[Casimiro Noteví]

Está claro que tienes algún problema raro por ahí, no puede tardar 2 minutos en presentar una imagen, ni un minuto, vería normal como mucho 1 segundo.
¿Acaso cargas las 2000 imágenes de una vez?
Haría falta saber exactamente qué hace tu programa y cómo.

[radenf]

Estimado Casimiro Notevi :

Tienes toda la razón. Deben cargarse todas las imágenes de un determinado directorio, que pueden llegar a 2000 o más.
Los archivos de imágenes médicas en formato dicom3 se obtienen de equipos de Tomografía computada y Resonancia magnética, entre otros y representan volúmenes de diversas partes del cuerpo, que se segmentan en " cortes" de un determinado espesor. Una analogía burda podría ser por ejemplo un pan de molde, que representa el volumen y cada rebanada representa una imagen.
Este volumen puede manipularse ya sea rotandolo o seccionandolo en cualquier plano.
Si lo deseas te puedo enviar por correo un visor básico que yo desarrollé, que hace lo que te señalo, para que puedas comprender mejor lo que trato de resolver. Pesa sólo 2 Mb y no requiere instalación.

Te saluda y agradece

Iván

[Casimiro Noteví]

¡Oh!, es que cargar tantísimas imágenes es normal que tarde, salvo que tengas un equipo muy potente, con muchísima memoria, una tarjeta gráfica "monstruosa", etc.
Suponiendo que tarde 0,1 segundos en cargar una, para cargar 100 necesitaría 10 segundos, si hablas de 2000
No sé, quizás puedas tener las imágenes en pequeñitas cada una y sólo cargar las grandes cuando realmente sean necesarias, por decir algo.

[radenf]

Empezado por Casimiro Notevi

¡Oh!, es que cargar tantísimas imágenes es normal que tarde, salvo que tengas un equipo muy potente, con muchísima memoria, una tarjeta gráfica "monstruosa", etc.
Suponiendo que tarde 0,1 segundos en cargar una, para cargar 100 necesitaría 10 segundos, si hablas de 2000
No sé, quizás puedas tener las imágenes en pequeñitas cada una y sólo cargar las grandes cuando realmente sean necesarias, por decir algo.

Muchas gracias Casimiro Notevi.
Tus aportes me hacen encarar mejor este proyecto y sus desafíos.
De hecho las imágenes que identifican a cada serie de un examen justamente son .bmp tumbnails de 100 x 100 y se muestran en el programa como "aperitivo" de lo que contiene cada estudio.
Salu2

[radenf]

He estado intentando cargar las imágenes en un TMemoryStream con el siguiente código:

Código Delphi [-]
for I := 0 to ListBox1.Count - 1 do
begin
DicomStream := TMemoryStream.Create;
DicomStream.Clear;
DicomStream.LoadFromFile(ListBox1.Items.Strings[i]);
DicomStream.Position:= 0;
try
CnsDMTable1.LoadFromStream(DicomStream, False);
Application.ProcessMessages;
DicomMultiViewer1.DicomDatasets:= CnsDMTable1;
DicomMultiViewer2.DicomDatasets:= CnsDMTable1;
DicomMultiViewer5.DicomDatasets:= CnsDMTable1;
DcmMultiImage1.DicomDatasets:= CnsDMTable1;
finally
DicomStream.Free;

Donde el ListBox contiene los strings de las rutas de las imágenes y a partir del MemoryStream cargar las imágenes en la CnsDMTable que se conecta al visor para mostrar las imágenes de formato .dcm
Sin embargo el stream sólo carga los strings de la ubicación de las imágenes como tales y no como archivos de imágenes, por lo que la carga finalmente es igual de lenta.
¿Cómo puedo cargar en un TMemoryStream o TFileStream las imágenes y no sus rutas de ubicación en el HD?
Agradezco sus valiosos aportes.
Saludos

[mamcx]

Bueno, el problema es que obviamente cargar 2000 imagenes sequencialmente + sincronico va ser lento, y traga cpu y memoria. El asunto es como evitarlo.

Hay 2 cosas que son la causa de la lentitud.

1- Sequencial. Para acelerar un proceso sequencial, lo debes hacer es volverlo asincrónico y/o paralelo. Lo que describes se paraleliza facil porque la imagen N+1 no depende de la imagen previa N ni de la imagen N+2. Para esto, uso de threads y/o liberia asincronica con threads verdes o corutinas

Eso es lo que parece mas obvio, pero el dia que cargues 100.000 imagenes la PC se va a morir.

2- Lo mejor, es solo cargar lo que es necesario para que el usuario visualize las imagenes, pero no mas. Eso se llama un "stream" o una fuente de datos "virtual".

El ejemplo mas popular ahora es lo que se usa en iOS:

http://developer.apple.com/library/i...ViewDataSource

Lo que se hace es que en vez de cargar TODOS los datos en una estructura, se carga solos N necesarios (mas un poquito mas para que no haya un parpadeo al desplazarse con scroll) y se van reciclando las estructuras en la medida que vayan cargandose las cosas. Si buscas como se usa un UITableViewController en tutoriales de iOS veras el esquema, pero te lo voy a poner en seuodocodigo:

El truco se parte, al menos, en 2 partes.

Primero, debes usar un "Record Count" que puede ser totalmente inventado o real. Luego solicitas el "registro" numero N. Ese registro lo buscas en una cola (o matriz o lista). Si esta, lo devuelves, sino, lo cargas de donde sea que este el verdadero registro.

Esto significa que debes recordar en cual registro vas.

O sea:

function AltoVisualizacion:
  //Aqui calculas el alto de la celda o fila, o de la foto o lo que sea. Si es estatico retornas un #, sino debes llamarlo luego de retornar la imagen y consultar su alto
  return 100

function TotalImages:
    return 1000000 //De alguna manera averiguaste el total. O pones un numero alto pa arrancar, y progresivamente mientras avanzas creces el totalimagenes hasta que te das cuenta que no hay mas...

function RetornarImagen:(posicion:Int):
   img = nil
   imgCtrl = nil

   llaveControl = 'Imagen' //Si tienes varios tipos de visualizadores, un diccionario con cada uno.

   if llaveControl in ListaCache:
     imgCtrl = ListaCache[llaveControl] //Este es el control que muestra la imagen, no la imagen en si
   else
    imgCtrl = CrearControlImagen();
    ListaCache[llaveControl] = img

   img = CargarImagenAhoraSiEnSerio(posicion)

   return img

Una variacion que simplifica la cosa, si puedes obtener la lista de archivos a ver muy rapido (que es lo que parece) es meter en un array o hastable la info de los archivos y usarlo como apuntadores al dato real:

function AltoVisualizacion:
  //Aqui calculas el alto de la celda o fila, o de la foto o lo que sea. Si es estatico retornas un #, sino debes llamarlo luego de retornar la imagen y consultar su alto
  return 100

function TotalImages:
    return ListaArchivos.Count()

function RetornarImagen:(posicion:Int):
   img = nil
   imgCtrl = nil

   llaveControl = 'Imagen' //Si tienes varios tipos de visualizadores, un diccionario con cada uno.

   if llaveControl in ListaCache:
     imgCtrl = ListaCache[llaveControl] //Este es el control que muestra la imagen, no la imagen en si
   else
    imgCtrl = CrearControlImagen();
    ListaCache[llaveControl] = img

   img = CargarImagenAhoraSiEnSerio(ListaArchivos[posicion])

   return img

La ultima cosa es si la imagen es lenta de cargar. Uniendo a lo anterior, se peude colocar una imagen "temporal", se carga la real de forma asincronica, y se cambia la temporal por la real cuando esta lista. Asi es posible incluso cargar imagenes desde internet.

Eso se enlaza con el control que llama la fuente de datos virtual para alimentarse. Con este esquema, no importa si son 1 o un millon, el gasto d ememoria y CPU nunca sera mayor a AltoVisualizacion() * AltoDeLaVentana() + ImagenesPrecargadasExtra.

Este esquema es la razon principal por la que en iOS se pueden visualizar miles o millones de registro, super rapido, super eficiente en maquinas menos potentes que un desktop. Cuando lo aprendi, me di cuenta de lo idiota que es el modelo de todos los demas lenguajes y frameworks

[radenf]

Muchas gracias mamcx :

Parece que por ahí va la cosa.
Me imaginaba que la solución era utilizar algo como lo que tu señalas, que te muestre sólo lo que vas necesitando y guarda en memoria los posibles pasos siguientes.
A pesar de que no me manejo muy bien en lo que tú me has señalado, como mi proyecto es por hobby y por desafío personal, me mantendré entretenido con tus sugerencias por un buen tiempo.
Muchas gracias por tu aporte y espero encontrar la solución.
Saludos.

[[gatosoft]]

Empezado por radenf

Estimado Casimiro Notevi :

Tienes toda la razón. Deben cargarse todas las imágenes de un determinado directorio, que pueden llegar a 2000 o más.
Los archivos de imágenes médicas en formato dicom3 se obtienen de equipos de Tomografía computada y Resonancia magnética, entre otros y representan volúmenes de diversas partes del cuerpo, que se segmentan en " cortes" de un determinado espesor. Una analogía burda podría ser por ejemplo un pan de molde, que representa el volumen y cada rebanada representa una imagen.
Este volumen puede manipularse ya sea rotandolo o seccionandolo en cualquier plano.
Si lo deseas te puedo enviar por correo un visor básico que yo desarrollé, que hace lo que te señalo, para que puedas comprender mejor lo que trato de resolver. Pesa sólo 2 Mb y no requiere instalación.

Te saluda y agradece

Iván

Bueno, ¿¿¿pero realmente es necesario cargar las 2000 imagenes al tiempo???, una vez en memoria ¿cómo las muestras? armas una imagen tridimencioal del "pastel" con cada "corte"?...

Porque si no es asi, puedes hacer lo que te han aconsejado Casimiro y Mamcx... "Mostrar solo lo que necesites"....Trabaja cargando imagenes en un buffer... 20, 30 imágenes.... y como dice mamcx vas cargando y si quieres dejando en memoria lo que ya cargaste....

Por otro lado... ¿porque cargas la imagen físicamente en una tabla?, Si necesitas cargarlas todas, intenta dejarla en memoria (utiliza una lista de objetos TMemoryStream). Porque como entiendo el problema, cargar la imagen en el TMemoryStream es un trabajo y Grabarlo en la BD es otro trabajo para el procesador....

Si necesitas la tabla para almacenar datos adicionales, pues almacenalos, pero cambia el campo de la imagen por una referencia (un indice de tu arreglo de imagenes en memoria).....

Tu mismo lo dijiste:

Empezado por radenf

La demora se produce al cargar las imágenes desde el disco duro en la tabla temporal

[radenf]

Gracias por responder [gatosoft].
En realidad se deben cargar todas las imágenes, porque como tú señalas el programa posee la opción de hacer reconstrucciones volumétricas, ya que debe operar con datasets específicos DICOM. La CnsDMTable es uno de los componentes de DicomVCL y no está ligada a ninguna base de datos, es autónoma, de tipo temporal.
No tengo la más mínima idea e como estructurar un buffer, pero lo ideal sería poder ir llamando las imágenes como tú señalas, de acuerdo a lo que se va necesitando, 20 o 30 para la visualización 2D y todas para las reconstrucciones, con algún método que evite que consuma toda la RAM del equipo.
Una idea de cómo es el programa la puedes ver en mi proyecto inconcluso de página web www. softmedica.cl
Saludos y muchas gracias

[jmvene]

Buenas tardes Radenf,

yo también uso la DicomVCL pero solo para la parte 3D de nuestra solución, para el tema del 2D llevamos varios años con otras librerías que nos parecen mas robustas.

Con respecto al tema de la carga, es verdad que cuando empezamos a trabajar con estudios que tienen series de hasta 3000 cortes la cosa empieza a ponerse difícil. La solución "carga lo que muestra" es la mejor, y si quieres darle un apretón de tuerca mas, incluso tendría un segundo hilo que mientras no te estas moviendo por la serie ("lo que muestra" esta fijo) vaya cargando en "background" lo que queda de los ficheros.

En nuestra solución no hemos llega tan lejos pero hemos encontrado una solución "intermedia" que nos vale (por ahora) y es usar un hilo para cargar las imágenes y mostrar las imágenes que se tal y como se van cargado en el visor (a través de racionalización con el hilo principal). La principal ventaja, es que el radiologo puede empezar a visualizar y manipular imágenes desde la imagen 1. Problema, que hasta que no se halla terminado de cargar el estudio no puede lanzar el 3D ni el MPR (normal por otra parte ya que es necesario TODO el volumen de datos para poder hacerlo).

Otro de los inconvenientes es que si basas la visualización en algún tag DICOM (como puede ser el serie UID para agrupar las imágenes de una misma serie) no sabes lo que contiene el tag hasta que haya leído el fichero...

Una pregunta, que tal con las DicomVCL?

Saludos