Open ivanjimenez opened 1 year ago
3 La carga de ficheros grandes bloque la interface.
He hecho asincrona la siguiente linea que es la unica que veo que puede tardar:
await Dispatcher.BeginInvoke(() => videoViewport.Source = new Uri(path));
En mi ordenador se carga de forma instantanea aunque le ponga un video de 2 horas, no he podido comprobar si va bien.
Reviso
Ha mejorado mucho la carga. Hay altas probabilidades que sea esa línea.
ok
He hecho otra version que espera a todo el metodo public async void initReplay(string path)
creo que va mejor. Aunque pongo un delay en el metodo no se bloquea.
El gráfico de total de presiones de arriba cuando se ha importado al dar el play no hay scrolling y necesito que haga scrolling hasta que se vea todo el gráfico.
Quieres que no salga entero? Que salga solo un trozo y se vaya desplazando?
El gráfico de total de presiones de arriba cuando se ha importado al dar el play no hay scrolling y necesito que haga scrolling hasta que se vea todo el gráfico.
Quieres que no salga entero? Que salga solo un trozo y se vaya desplazando?
Que salga un trozo y se vaya desplazando.
Por eso se ve como parecido el butterfly y heatmap. Aunque sí que es cierto que en caminar se ve mejor el butterfly. Pero, sí, haz ese cambio. Gracias
He estado haciendo pruebas y creo que ya estaba bien como al principio. La cosa es que el fichero tiene 8500 frames entonces no se puede apreciar bien que lado tiene mas centros ya que al ser tantos se dibujan unos encima de los otros. He generado 2 ficheros falsos (uno donde right es siempre mayor que left y otro al reves) y me pone el centro donde lo tiene que poner. right_file.txt left_file.txt He sacado unas estadisticas del fichero grande i sale lo siguiente:
Left zeros: 320
Right zeros: 2081
Left wins: 229
Right wins: 5885
Total Center Row Avg335,7227837488625
Total Center Col Avg303,94638249824794
Total Rows 474
Total Cols 605
Lo importante el el Total Center Row/Col Avg:
Col es 303 de 605 total (~la mitad) (Col es la distancia horizontal, deberia ser vertical pero esta al reves)
Row es 335 de 474 (se va hacia la derecha) (Row es la distancia vertical, pasa lo mismo que con col)
(Esto no importa demasiado: Left/Right wins
es el numero de veces que la presion de un pie es mayor que la del otro y Left/Right zeros
el numero de veces que la presion es 0.)
En la version que dibuja los sensores como una superficie (sin reducirlos a un punto). Si calculas la formula para los sensores tambien (asumiendo distancia = 1) se ve mejor. No se ve tanto contraste. (Con los bordes en algunos sitios pasa algo raro pero eso debe ser algun bug, de momento no he intentado arreglarlo)
Se ve más direccional la presión. Pero el contorno de los sensores es lo que deberíamos no mostrar. Que sea lo más difuminado posible. Con lo de los bordes te refieres a los sensores?
No, el pie
Supongo a que te refieres a que pasan cosas raras pero en esa imagen no veo nada fuera de lo normal del todo. Que puede ser que sí. Eso lo puedes ir viendo, claro. Pero cómo ves lo del contorno de los sensores, se puede difuminar más para que no se note? Antes estaba bien, pero claro, tomaba como una presión central. Necesitamos que se distribuya.
ok
En el video que te mostré, es de las plantillas nuestras. Se nota que va presionando cada parte y como que se va desplazando, obviamente eso es en tiempo real. Entonces debemos sacar una distribución donde más se presione en rojo y luego las que menos en amarillo, tal y como lo estás haciendo. Pero sin que se sepa dónde está el sensor.
El unico metodo de interpolacion Open Source que he encontrado es esto https://numerics.mathdotnet.com/api/MathNet.Numerics.Interpolation/Barycentric.htm
Yo he encontrado esta librería:
Pero tal vez sea demasiado numérica
Tal vez ScottPlot no nos puede solucionar lo que necesitamos. Tal vez tengamos que coger algo de Machine Learning.
Mira este proyecto por decir algo:
https://github.com/Arction/lcu-tutorial-2DHeatMap-07
Hay que probar varias soluciones porque Scottplot, como te comentaba, puede que no esté ofreciendo todo lo que se necesita.
ALGLIB no creo que sirva la version gratuita por temas de licencia: https://www.alglib.net/faq.php
Can I distribute ALGLIB Free Edition as a part of a commercial application?
Almost surely - no. GPL license does not forbid commercial distribution explicitly, but it imposes several requirements that commercial users can't comply with.
The most important requirements are: a) you must distribute your program along with source code and under GPL, b) you can't restrict your users from copying your program, reselling copies or distributing them for free.
No te preocupes por la licencia. En caso de que sea útil en el producto y tenga venta ya se compra. Lo que se está haciendo es un prototipo
Ok
rama AlgLib
Me parece mucho mejor lo hablamos en un rato
Usando un metodo que he encontrado por internet consiste en coger 1/N puntos de forma aleatoria (donde N es el numero inicial de puntos). Por estadistica coge los puntos distribuidos. Cogiendo 1/40 puntos queda asi y tarda esto en segundos model left 0,1320884 model right 0,0245605 left foot 0,3959821 right foot 0,4032046 (Se puede hacer primero lo de coger los puntos y guardarlos por si acaso, por estadistica normalmente quedan distribuidos pero una de cada muchas veces puede quedar mal)
Esta última imagen es la realizada con la distribución que has utilizado para usar menos puntos? La puedes comparar con la que se hace con todos los puntos?
Todos los puntos. model left 5,2150779 model right 5,5166269 left foot 14,7329741 right foot 15,6535448
1/10 puntos model left 0,3537101 model right 0,2394186 left foot 1,4921597 right foot 1,5404089
1/ 5 puntos model left 0,8769586 model right 0,829519 left foot 2,9356716 right foot 3,0772102
Si, eso te iba a decir, que depende de los puntos que tomes será más o menos ajustada. Hay que tomar el número de puntos posible para que la imagen sea lo más ajustada sin perjudicar el tiempo.
He cambiado el bucle por este metodo: rbfgridcalc2vsubset()
Esto calcula todos los puntos a la vez y va bastante mas rapido.
Lo que se puede hacer tambien es mostrar max, min, avg segun se vayan calculando. Ahora se muestran cuando se han acabado de calcular los 3.
Ese es un método para hpc, seguro que está bastante optimizado. Está bastante mejor. De hecho, a mí me tarda unos 5s. Seguro que en otros equipos menos.
En caso de que no se pueda mejorar más. Podemos calcular primero las imágenes y guardarlas para cada paciente. En el caso que no se aceptable.
Pero yo creo que vamos bastante bien.
Lo que sí, no me gusta la plantilla del zapato que te he pasado. Me gustaría sacar una plantilla de un pie pero con arco. Porque, realmente no sé si está bien del todo esa plantilla para un médico. Lo hablaré con Jose.
Buen trabajo!!
Una pregunta, ya para mañana.
El scrolling de curvas de fuerzas va súper rápido. Va a 100Hz?
En capture se actualiza cada vez que llegan los datos de los 2 pies (suponiendo que los sensores vayan a 100Hz si que deberia ir a 100Hz) En replay hay un timer cada 10ms.
Ya, bien, es su tiempo. No obstante en el capture parece que va más lento por eso de que recibe 4 paquetes cada 25 Hz. Y claro, el replay va a lo que debe ir a 10ms. El problema es el capture, estimo. Dejémoslo en observación
Revisar con Jose para decidir gráfico heatmap.
mantengo para repasar los requeriments de insoles