![]() |
![]() |
| Paypal | FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
|||||||
| Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Buscar | Temas de Hoy | Marcar Foros Como Leídos |
![]() |
|
|
Herramientas | Buscar en Tema | Desplegado |
|
|
|
#1
|
||||
|
||||
|
Cita:
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: |
|
#2
|
||||
|
||||
|
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 |
|
#3
|
|||
|
|||
|
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 |
|
#4
|
||||
|
||||
|
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. Cita:
Saludos y muchas gracias por tus aportes |
|
#5
|
|||
|
|||
|
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. |
|
#6
|
||||
|
||||
|
Puedes extenderte todo lo que quieras
![]() Cita:
Cita:
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
|
#7
|
|||
|
|||
|
Cita:
- 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. |
|
#8
|
||||
|
||||
|
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
__________________
Cuando los grillos cantan, es que es de noche - viejo proverbio chino - |
|
#9
|
||||
|
||||
|
Cita:
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 |
|
#10
|
||||
|
||||
|
Cita:
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. |
|
#11
|
|||
|
|||
|
Cita:
Cita:
Cita:
Si quieres me puedes mandar el exe, pero te advierto de antemano que si veo una buena idea la copiare SIN REMORDIMIENTO.. Un abrazo |
![]() |
| Herramientas | Buscar en Tema |
| Desplegado | |
|
|
Temas Similares
|
||||
| Tema | Autor | Foro | Respuestas | Último mensaje |
| WebBrowser bloqueo de carga de imagenes | titomigue | Internet | 1 | 17-08-2010 09:53:34 |
| Acelerar apertura de consulta desde Delphi contra Access | Sergiov | SQL | 4 | 13-04-2007 10:42:59 |
| Acelerar carga de Delphi | mamcx | Noticias | 4 | 13-09-2006 00:51:52 |
| Transparencias y carga de imágenes | david.rguez | Gráficos | 1 | 04-09-2006 18:01:40 |
| carga de imagenes en timage | jvalles | Gráficos | 2 | 15-12-2005 19:06:57 |
|