Acelerar carga de imágenes desde archivo
 

Un saludo a todos.
Estoy desarrollando un programa que permite visualizar imágenes médicas, en formato .dcm.
Estas imágenes se almacenan en el disco duro en carpetas que poseen la siguiente estructura:

Estudio > Series > Imágenes (.dcm)

Se llaman las imágenes a partir de la ruta del directorio Estudio, la que se encuentra almacenada en una BD de Access.
El problema es que cada imagen pesa 0.5 Mb y un estudio puede contener hasta 2000 imágenes, o sea 1 Gb, lo que obviamente produce un retardo en su aparición en el visor.

¿Es posible acelerar este proceso?

El código que utilizo para llamar las imágenes es el siguiente:

Código Delphi [-]
procedure TVisor.ButtonCargarClick(Sender: TObject);
begin
CnsDMTable1.Clear;
DicomMultiViewer1.DicomDatasets.Clear;
try
CnsDMTable.LoadDcmFileDirEx(DBEditDir.Text);
Application.ProcessMessages;
finally
DicomMultiViewer1.ActiveView.Attributes.ImageData.MagnificationType:= mftCUBIC;
DicomMultiViewer1.Update;
end;
end;

CnsDMTable es una tabla temoral que permite la carga de imágenes desde directorios, archivos o streams.
DicomMultiViewer1 es el Visor de imágenes (algo así como un TImage mejorado).
DBEditDir muestra el directorio donde se encuentran almacenadas las imágenes en el disco duro.
Como siempre agradezco cualquier ayuda.

Salu2

¿No hay sugerencias para acelerar la carga de las imágenes?
Salu2

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

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.

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

¡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 :eek:
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.

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:

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:

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 ;)

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.

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

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

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:

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

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

Buenas de nuevo Radenf,
no, el MemoryStream no carga la ubicación de las imágenes sino la imagen (el fichero binario) memoria completamente que luego carga el DicomMultiviewer1 a través de ese memorystream. Pasar por un memorystream o incluso un Filestream no te va accelarerar la carga, creo yo, ya que muy probablemente, internamente, el CnsDCMTable tenga ese mecanismo implementado ya que tiene el metodo loadfromfile y loadfromstream (normalmente el loadfromfile suele ser una implementacion particular del loadfromstream donde se crea un stream a partir del nombre de fichero en parámetro y se pasa al loadfromstream, vamos el lo que tu has hecho en tu ejemplo).

Acabo de hacer pruebas con el DicomVCL para ver los tiempos de cargas que indicas estos son los tiempos:
100 img -> 0,875 s
250 img -> 3,8 s
500 img -> 13,5 s

Como puedes ver, la progresion no el lineal, con lo cual me extrañaria que sera realmente un problema de acceso al fichero (carga pura y dura), yo creo que es mas un problema de indexacion de la imagen en esa tabla interna en memoria que usa las DicomVCL (cuantas mas imagenes tengo, mas tiempo tardo en ordenarlas e indexarlas). He intentado ver si se puede desactivar la ordenación de la tabla durante la carga, pero no veo nada, la unica propiedad que hay es la de TCnsDMTable.ImageOrder, pero no permite un valor desactivado del estilo "dsNone".

No se si te ha ayudado...

Perdonad, pero en el mensaje anterior tengo un error:

"no, el MemoryStream no carga la ubicación de las imágenes sino la imagen (el fichero binario) en memoria completamente que luego carga el CnsDMTable1 a través de ese Memorystream."

Esto pasa por novato y no revisar las respuesta....

Agradezco enormemente tus comentarios jmvene.
Me alegra que alguien más use estos componentes, para conversar en el mismo idioma.

En general decepcionado, el soporte de Jiawen Feng que los fabrica es un desastre. A mi más me ha confundido que ayudado.
Yo soy médico radiólogo aficionado a la programación con Delphi, la que ido aprendiendo a golpes y errores. Mi sueño es realizar para Windows un programa igual o mejor que Osirix (puedes revisar mi página web) y distribuirlo gratuitamente, para incorporarle más adelante procesos de pago como Reconstrucciones vasculares, detección de nódulos pulmonares y un sistema de diagnóstico en TC de cerebro basado en algo similar al de reconocimiento de huellas digitales, para reconocer automáticamente las lesiones, tipo CAD (Soñar no cuesta nada). Tengo múltiples funciones ya habilitadas, sin embargo la ausencia de algunas como las reconstrucciones multiplanares dinámicas con scroll en visor independiente, que no utilizen el componente MPR y las reconstrucciones MIP, MinIP y Promedio necesarias para el diagnóstico se echan de menos, A pesar de que me prometieron que se incorporarían en nuevas versiones, así como el soporte para Delphi XE3 y para 64bits.
Y esto ¿cómo se puede hacer con delphi? Me puedes dar una mano ya que mi nivel de conocimientos es mínimo.
Saludos y muchas gracias por tus aportes

Buenas Radenf,
con respecto a Jiawen Feng, y sin querer extenderme demasiado ya que no se si se puede en el foro, solo te dire que lo de este hombre roza la estafa. Sus componentes valen 1200 Euros (la versión sin código fuente) y, por lo menos en la parte 3D, esta plagada de errores y fallos que para nosotros los vuelven inútil, estamos buscando alternativas... Si quieres, y si algún moderador me indica donde, abrimos un tema especifico para discutirlos. Lo que mas me preocupa, es que en una de sus contadas respuesta a nuestras peticiones me ha llegado a decir que "algunos bug se podrán solucionar y otros no"... es un poco "wtf"?. Se supone que esta vendiendo unos componentes de los cuales tiene todo el código fuente y nos dices que hay fallos que no vas a poder solucionar??.. en fin, si quieres lo discutimos en otro hilo... y por lo menos nos consolamos...

Con respecto a implementar lo que ya te ha comentado mamcx o algo parecido, el problema es que me parece difícil hacerlo por "encima" de los componentes DICOMVCL, ya que la relacion entre el visor (donde se ven las imagenes) y la tabla de almacenamiento (donde se cargan las imagenes) esta hecha en la propia definición de los componentes y con mecanismos interno. Para que los demás nos entiendan, el visor tiene una propiedad DicomDataset, es un poco como la relación entre un DBGrid y un TDataset (sin el TDataSource por medio). Cuando interactuas con el visor, este se encarga de leer y presentar las imágenes ya cargada a través de la tabla (cnsDMTable). No lo he mirado a fondo, pero habria que ver la posibilidad de interceptar alguno procesos a través de eventos (OnScrollDown, etc...) para poder alterar el modo de interacción y por ejemplo ahí mismo lanzar la carga de "las imágenes que quedan por cargar"... hay que mirarlo, sino, tener acceso al código fuente del componente e intentar alterar el comportamiento ya sea directamente o creando un componente heredado (aquí yo ya me pierdo y es para gurus de la programación...).

Con respecto a tu proyecto, me parece fantástico y la meta que te has puesto es de las mas audaz que he visto (igualar o superar a OsirX). Solo como apunte, desde mi humilde opinión y sin querer que pienses que de alguna manera te estoy intentando quitar el entusiasmo, tienes que tener en mente varias cosas: OsiriX, aunque no lo parezca, es un proyecto que tiene mas de 10 años, no estoy seguro pero creo que en realidad una evolución de un software que ya existía llamado "Osiris" (ambos de los Hospitales Universitarios de Ginebra, Suiza). Es un proyecto OpenSource con bastante colaboradores externos, tanto clínicos (medico y radiologos) como técnicos (programadores) y con una buena dirección de proyecto, lo que le ha permitido llegar a unos niveles de calidad bastantes altos. La colaboración de médicos y programadores puros (y muy buenos) ha permitido que se le vayan agregando herramientas muy especificas (como las que tu mencionas) usando tecnologías y librerías de bastante bajo nivel (como pueden ser las vtk para el 3D).

Resumiendo y, repito, sin querer que pierdas ni una onza de tu ilusión, es un trabajo de titanes y no a muy corto plazo. Quizás debas re enfocar la estrategia de tu proyecto, buscar otra manera de llegar al mismo fin ya que si, por ejemplo, dependes de componentes de tercero te puedes encontrar en un callejón sin salida o con limitaciones impuestas por estos componentes. Aqui hay una comunidad de desarolladores en delphi que tiene un muy alto nivel, quizas seria buena idea intentar implicar a gente de este grupo y avanzar hacia un proyecto collaborativo opensource. Tu formación como medico radiologo es una gran ventaja que puedes aprovechar para dirigir la parte "clínica" del proyecto, pero creo que debes buscar aliados con un perfil mas técnico para la parte de programación.

Con todo y con esto espero haberte ayudado o por lo menos aclarado algo.

Un saludo.

Puedes extenderte todo lo que quieras :)
Puedes crear un nuevo tema en el foro "Debates"
Y teniendo ese proyecto opensource, ¿para qué crear otro desde cero?, mejor aprovecharlo y usarlo. Luego, con tiempo, lo podéis adaptar más a vuestras necesidades.

Hola,
no es que sea muy profano en el asunto, pero habeis visto esto ?
http://cgarcia.blogspot.com.es/2006/...es-mdicas.html

Utiliza Delphi y OpenGL.

Espero que os sirva.

Saludos

Buenas Casimiro, tienes toda la razon del mundo, pero solo tiene un par de pegas:

- solo es para MacOS, debería poderse portar a otras plataforma, pero si no lo han hecho ya, con la multitud de peticiones que les llegan, es que debe haber alguna razón técnica que desconozco o por política del proyecto, ni idea.

- no esta hecho en Delphi... esto no debería ser un impedimento, pero estando en un foro dedicado a el...

Un saludo.

No lo sabía, no había oido nunca hablar de ese proyecto. Lo tenéis complicado, ¿qué mercado potencial puede tener un software de ese tipo?

Primero al maestro

Estimado Casimiro:

Sólo en mi país (Chile) lo deben utilizar unas 10.000 personas y en el mundo varios millones, ya que cumplía con todos los estándares necesarios para hacer diagnóstico basado en imágenes radiológicas. Las últimas versiones gratuitas incorporan una serie de limitaciones, como propaganda y mensajes irritantes como que no tienes suficiente memoria para abrir 1500 imágenes, pero sí para abrir 1499 (este mensaje casi permanente trae un slider que te permite disminuir el número de imágenes que carga).

Respecto al desarrollo realizado por la Universidad de Geneva en Suiza, casi sin temor a equivocarme debe tener financiamiento de la manzana. Sólo en mi hospital, ya que yo además soy profesor universitario y formo especialistas en radiología, en los últimos años hemos debido comprar un total de 16 computadores Mac, sólo para usar el software Osirix y yo soy sólo un ratón en el mundo radiológico, lo que puedes multiplicar por miles de centros hospitalarios similares en el mundo.

El gran problema radica que para Windows no existe ningún software con capacidades similares y los que hay, de menor calidad, valen desde U$ 300 a U$ 3000 la licencia anual.

Me encanta la idea propuesta por jmvene de crear una comunidad en este foro que tenga interés en un desarrollo como este, que como tu vez tiene un gran potencial tanto social como comercial, en especial por el enorme crecimiento del uso de las modalidades diagnósticas por imágenes. A modo de ejemplo en USA en 2012 se efectuaron alrededor de 30.000.000 de Scanner (en mi hospital realizamos 23.000 en una población de 900.000 habitantes) y todos deben ser evaluados con software de este tipo.

Saludos y gracias por el interés y apoyo

Estimado jmvene:

La ilusión no la voy a perder nunca puesto que este proyecto es un desafío personal, un placer que puedo darme, ya que no tengo fecha de término ni jefes a quien responder y puedo destinar algunos dineros a su ejecución, con el estímulo de que día a día he ido logrando, mediante estudio y el valioso aporte de los miembros de este foro, avances importantes que me permiten en este momento abrir e incorporar los estudios en la BD, visualizarlas en 2D, 3D y en MPR, además ya tengo funcionando sin problemas el DicomQuery a otros servidores y equipos y el DicomSend a servidores. Aún no logro implementar el DicomStore ni el DicomRetrieve desde servidores, porque no he podido entender como funcionan los famosos DBLink. El DicomPrint y el grabado de exámenes en CD lo voy a dejar para el final.
A pesar de que Osirix es OpenSource, cuando descargas el código fuente te envía mil restricciones y al intentar procesarlo con XCode dice que le faltan montones de cosas, en resumen, para mi escaso nivel de conocimientos de programación, me resulta inútil.
He revisado varias librerías, entre otras, las que alguna vez eran gratuitas de Charrua, la SDK de LeadTools cuando era para Delphi y varios ActiveX para manejo de imágenes Dicom y aunque no lo creas la DicomVCL fue la que me convenció y compré (todavía me duelen los U$ 1299 que pagé).
Respecto a usar componentes, no me queda otra alternativa porque no manejo mayormente la programación y a la fecha no he encontrado ningún programador que quiera compartir esta aventura.
En relación con el desarrollo te puedo decir de que a pesar que Osirix cuenta con numerosos colaboradores y programadores posee una estructura de programa compleja con múltiples herramientas inútiles que no usas nunca y opciones superfluas que la mayoría no entiende y no necesita.
Los médicos necesitan un programa simple, ojalá con poco botones, que funcione a click de ratón y ojalá sin manual de instrucciones que leer. La mayoría de usuarios de Osirix que conozco no son precisamente radiólogos, sino cirujanos u otros especialistas que necesitan poder visualizar los exámenes de sus pacientes para tomas decisiones terapeúticas.
Seguiré tu consejo y me pondré la armadura de Titan, para continuar adelante y ojalá con tu ayuda si es posible y la de los integrantes de este foro, que tan desinteresadamente me han apoyado.
Respecto de la pregunta inicial, de la que nos hemos alejado un poco, te cuento que ayer probé fragmentando los estudios y cargándolos mediante 8 threads simultáneos y logré cargar una Angiotomografía de extremidades de 1.203 imágenes en sólo 5.8 segundos, aunque todavía estoy cerrando los avisos de violación de acceso a memoria y el procesador de mi workstation parece que va a presentar una demanda en contra mía.

Saludos y muchas gracias por tu apoyo y comentarios

PD: Si te interesa te puedo enviar el exe de mi programa por correo, para tu evaluación.

Estimado fjcg02 :

Agradezco tu aporte pero ese programa es algo básico, fue publicado en 2006 y no ha sido actualizado. Su resolución es insuficiente para diagnóstico, ya que lo más importante es la visualización de las imágenes en 2D. En ese año recién salían al mercado los Scanner multicorte que son los que generan miles de imágenes, lo que constituye mi actual problema.
Salu2 y muchas gracias

Entonces no entiendo porqué me has contestado antes a mí :p

Bromas aparte, parece muy interesante un proyecto de ese tipo, aunque tiene el inconveniente del tiempo necesario para llevarlo a cabo, o sea, dinero.
Se me ocurre que si el otro programa está "subvencionado" por apple, entonces sería bueno contar con un amigo en google para conseguir que financien un proyecto que le haga la competencia, seguro que se apuntan, lástima que no conozcamos a nadie allí, seguro que algo surgiría.

Esto me suena raro. De donde sale esa idea?

Lo mas probable es que OSX pisa muy fuerte entre los miembros de la Academia y tiene una presencia importante entre ingenieros y cientificos. Ademas, que los APIs de OSX son particularmente utiles para este tipo de proyectos (como grand central, coreanimation, core sound, etc). Es muy facil hacer aplicaciones multimedia, multi-hilos, y de gran desempeño con estas APIs, e incluso para alguien muy novato en eso como yo, he podido implementar animaciones y efectos que jamas he podido en ningun otro entorno (osea, como la misma facilidad y desempeño).

Tanto, que el problema que se trata en este hilo (lo de cargar y procesar imagenes en gran cantidad) es algo casi trivial... incluso en un iPhone/iPad...

Ejemplos:

http://www.farmpd.com/Farm-Blog/bid/...ce-Mobile-Apps
http://www.popgive.com/2012/06/top-1...-apps-for.html
-----

Ahora, lo que me gustaria saber es si en tu entorno OSX es realmente la plataforma mas comun? O es windows?

De aquí:
...........

¿Qué te parece lo que presentan en este link?

Que tiene eso de raro? Seguro muchos usuarios preguntan si hay version pa Windows o Linux, y esa es la respuesta.


Donde esta la idea que Apple los financia?

Por cierto, ¿qué cantidad de RAM tiene tu equipo?, parece que necesita bastante.

16 Gb de RamECC

Potencia excesiva para aplicaciones creadas con Delphi 2007. Espero migrar en algún momento a DelphiXE3, pero me encuentro limitado por los componentes DicomVCL, que no han sido actualizados para 64bits.

Saludos

Afortunadamente, la RAM es barata!:

US 270 32 GB iMac:

http://macperformanceguide.com/Mac-M...ices-iMac.html

16 GB es lo que tengo en mi Imac... porque entonces no habia 32 GB. Con un macpro se puede llegar a 32 GB. Ahora se puede montar hasta 64GB+ en PCs normales!

Buenas tardes a todos,

nos estamos alejando de la discusión inicial, pero es igual de interesante. Si aburrimos o nos tenemos que mover a otro sitio, que nos lo indiquen los moderadores por favor.

Bueno aquí quiero puntualizar un par de cosas radenf con respecto a OsiriX. Por un lado, no creo que este subvencionado por Apple, es un proyecto con el respaldo inicial de una institución gubernamental Suiza, han creado luego una fundación para seguir con el desarrollo, no se si con animo de lucro o no. Es un trabajo de calidad, no se puede dudar, pero tambien se ha favorecido del empujón de estos últimos años de la "moda Apple" (justificada o no, eso cada uno tiene su opinion).


Bueno aquí tengo que discrepar un poco, ClearCanvas es también un muy buen sistema de diagnostico OpenSource. Esta hecho en C# y para plataforma windows.

Mi trabajo precisamente es el desarrollo de este tipo de soluciones (PACS, estaciones de diagnostico, visores web, etc.). Los precios de este tipo de aplicaciones son alto por una razon, las certificaciones. Como sabrás, un visor destinado a ser usado por un radiologo durante el proceso diagnostico esta considerado como "dispositivo medico" con toda la bateria de ISO's y certificaciones que eso conlleva (en EU la "FDA Clearance" y en europa el "Marcado CE"). Mi empresa, para poder desarrollar y vender software medico, tiene que estar certificada ISO 9001, ISO 13485, seguir unas cuantas normas durante el proceso de desarrollo, disponer de una licencia de fabricante de dispositivos médicos de la Agencia Española del Medicamento y seguir auditorias de calidad todos los años. Todo esto tiene unos costes bastante alto y el volumen de licencias no tan alto con el de otra aplicaciones (es un sector MUY focalizado).

De hecho es un poco revelador (y casi ironico) que teóricamente con la versiones Open Source de Osirix (la que no tiene marcado CE) no se puede legalmente diagnosticar (creo que esta indicado), pero que con las versiones de pago (con marcado CE) si se puede pero estas ya NO SON open source... con ClearCanvas pasa exactamente lo mismo.

Por otra parte hay que relativizar el costo de la aplicación con el rendimiento de su uso, un radiologo (por lo menos aquí en España) no es precisamente un usuario "pobre", el sueldo medio tiene que estar al rededor de 4000 euros netos al mes. Sin contar por otra parte el ahorro en consumibles que supone no tener que imprimir placas para hacer el diagnostico.

Con todo y con esto, si lanzáis este tipo de proyecto basado en Delphi, veré en que medida puedo aportar ayuda.

Voy a echarle un vistazo a ver si puedo aclararte algo.

No se exactamente como van las partes que no sean el 3D de las DicomVCL, pero hay una parte muy importante en las comunicaciones DICOM 3.0 (Storage, QueryRetrieve, etc.) que están definidas exclusivamente por el estándar DICOM 3.0. Una mala implementación o una violación de la norma por parte de estos componentes te pueden llevar a un callejon sin salida si el seños Jiaiwen no se hace cargo de corregirlo... y cada vez estoy mas convencido que es que en realidad no puede, por el motivo que sea...

Woww... habria que ver porque son esas violaciones de acceso a memoria (probablemente algún problema de syncronizacion de hilo), pero promete. Podrias poner el codigo?

Si quieres me puedes mandar el exe, pero te advierto de antemano que si veo una buena idea la copiare SIN REMORDIMIENTO..

Un abrazo

No e problema, pero debo advertirte que uso varios componentes de pago destinados a mejorar la interfaz gráfica, la conexión a servidores y las grids. Te lo enviaré por mail.
Ojalá puedas ayudarme con los Dblink. Yo uso Access por su facilidad y su límite de 4GB no me preocupa pues yo guardo los archivos de imágenes en directorios directamente en el HD y no en la BD, pero puedo intentar con cualquier base de datos.
Respecto a tu favorable opinión de ClearCanvas discrepo plenamente. Me parece realizado por alguien que no tiene experiencia en diagnóstico, ya que carece de herramientas indispensables como el MIP2D.
Yo no pretendo hacerle competencia a nadie, sin embargo por algo bautizé a mi programa Nemesis (el enemigo natural).
El código de los threads lo estoy puliendo. Utilizo los BDThreads gratuitos de Mitov Software que son a prueba de niños. Cuando lo tenga te lo subo.
Saludos y muchas gracias

Iván

Falsa alarma jmvene.
Lo que hize fue fragmentar el contenido de un ListBox donde a partir de un directorio recojo la ruta de todas las imágenes que componen un estudio y le asigné a cada fragmento un thread, puse a correr los threads simultáneamente y sincronizados esperando que cargara el directorio completo, pero la CnsDMTable sólo acepta la carga desde uno de los threads, por lo que sólo había cargado un octavo de las imágenes y por eso generó las violaciones de acceso a memoria.
Otra prueba fallida. Aparentemente la CnsDMTable tiene su propio sistema de organizar la información que recibe y lo hace en un sólo paso, ya que si le aplicas un ProgressBar y le asignas la propiedad StepIt ejecuta un sólo step.
No sé si la idea te sirva y con tu nivel de conocimiento puedas mejorarla, ya que yo utilicé componentes para crear los threads (BMThreads de Mitov Software), porque no sé implementarlos por código.
Quizás otra opción es cargar las diferentes series en distintas CnsDMTables, lo que aceleraría la carga de exámenes con múltiples series, pero igual demoraría en cargar las series con muchas imágenes.
Te envié un mail desde el foro, pero no me permite incluir archivos adjuntos. Debes responderlo para poder enviarte el exe.
Saludos

Solucionado
 

Después de muchos intentos y pruebas fallidas descubrí que la CnsDMTable carga las imágenes usando threads sobre un MemoryStream, mediante los parámetros AKeepStream y ALoadFrameinThread, es decir el componente, según entiendo viene desarrollado para cargar las imágenes a la máxima velocidad que permita el PC.
Utilizando el siguiente código logré acelerar la carga de las imágenes a escasos segundos en series grandes de más de 1000 imágenes:

Código Delphi [-]
procedure TVisor.ButtonCargarClick(Sender: TObject);
var
I:Integer;
c1: TCursor;
begin
c1 := Screen.Cursor;
Screen.Cursor := crHourGlass;
CnsDMTable1.Create(Self); // crea la tabla (este paso es fundamental)
ListBox1.Items.Clear;
FindFile.Threaded := False;
with FindFile.Criteria.Files do
begin
FileName := '*.dcm';
Location := (DBEditDir.Text); // Directorio donde se almacenan los archivos de imágenes, ruta guardada en la BD
Subfolders := Self.Subfolders.Checked;
end;
begin
FindFile.Execute;// Extrae la ruta de los archivos de imágenes y los muestra en un ListBox
Application.ProcessMessages;
end;
begin
for I := 0 to (ListBox1.Items.Count - 1) do
CnsDMTable1.LoadfromFile(ListBox1.Items.Strings [i]);// carga las imágenes
Application.ProcessMessages;
try
DicomMultiViewer1.DicomDatasets:= CnsDMTable1;// carga los visores
DicomMultiViewer2.DicomDatasets:= CnsDMTable1;
DicomMultiViewer3.DicomDatasets:= CnsDMTable1;
DicomMultiViewer4.DicomDatasets:= CnsDMTable1;
DicomMultiViewer5.DicomDatasets:= CnsDMTable1;
DcmMultiImage1.DicomDatasets:= CnsDMTable1;
finally
if assigned(DicomMultiViewer1.DicomDatasets) and (DicomMultiViewer1.DicomDatasets.Count > 0) then
begin
DicomMultiViewer1.ActiveView.Attributes.ImageData.MagnificationType:= mftCUBIC;// asigna propiedades
DicomMultiViewer2.ActiveView.Attributes.ImageData.MagnificationType:= mftCUBIC;
DicomMultiViewer2.LeftMouseInteract:= miZoom;
DicomMultiViewer1.LeftMouseInteract:= miZoom;
Screen.Cursor := c1;
end;
end;
end;
end;

y para llamarlo:

Código Delphi [-]
procedure TVisor.DBAdvGrid1ClickCell(Sender: TObject; ARow, ACol: Integer);
begin
if (ACol = 2) then
begin
CnsDMTable1.Clear;// esto vacía la tabla y libera la memoria
ButtonCargar.ButtonClick;
end;

y de este modo ya no tengo violaciones de acceso a memoria y el programa corre sin problemas.
FindFile es un componente que permite obtener la ruta de todos los archivos existentes en un directorio, incluidos los subdirectorios y cargarlos como strings en un ListBox. Para 1000 archivos tarda 180 msegs.
Espero que a alguien más le pueda servir.

Saludos y gracias por sus aportes

Cronometré los tiempos y se demora aproximadamente 3.8 msegs. en cargar cada imagen, permitiendo que un estudio de 1000 imágenes se encuentre disponible para visualización y proceso en 3.8 segundos. Un examen de cerebro habitualmente posee 350 a 400 imágenes y lo carga en 1 - 1.3 segundos.
Esto con un procesador Intel Xeon de 3.2 Ghz. utilizando sólo 1 de los núcleos, con un consumo de memoria menor de 300 Mb.
Estos resultados me parecen excelentes y satisfacen plenamente mi necesidad.
salu2

En hora buena Radenf, esos valores son excelentes. Creo que tienes un pequeño error en el código, ya que la llamada de las CnsDMTable1 deberia ser:

Código Delphi [-]
CnsDMTable1.LoadFromFile(ListBox1.Items[i], True, True);

Un abrazo.