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
|
||||
|
||||
Hola Peregrino.
Acabo de ver el ejemplo que muestra en el enlace. Se trata de un algoritmo sencillo, y no es demasiado eficiente (por lo de pixels[]) Lo que hace es leer pixel por pixel y acumulando la "diferencia" entre cada pixel. Y con ello calcula un margen de error. Para ir comprendiendo algunas cosas te va a sentar bien, pero para cosas más elaboradas, esto te va a resultar chico. La teoría que yo te expongo está más sustentada por algunos conceptos más matemáticos que estos. Saludos, |
#2
|
||||
|
||||
Con justa razon Delphius... por ejemplo: una webcam como la usada en el ejemplo que cito, no te proporciona una verdadera calidad de imagen; por lo que el algoritmo podria ser "inutil", para detectar diferencias de luz y sombra... ademas como de los movimientos "rapidos"; en este caso el algoritmo deberia ser una base y no la solucion terminada para conseguir el resultado esperado y confiable... obviamente con una camara de vigilancia profesional
__________________
Web |
#3
|
||||
|
||||
Hola Delphius, se me ocurre algo que puede ser una tontería, aplicar sobre las dos imágenes un filtro sobel con un valor de umbral bastante alto (para detectar los bordes) y luego compararlos. Si los bordes han cambiado es que existe movimiento.
En cualquier caso, la comparación la haría utilizando el Scanline y no la propiedad Pixels, la diferencia en rendimiento puede ser grandisima. |
#4
|
||||
|
||||
Hola seoane,
Me gusta la idea. Y no es ninguna tontería. Puede ser una buena aproximación. Y es como dices, emplear Scanline. Los métodos que yo he mencionado, lo que hacen es, en pocas palabras, explorar las imagenes por bloques (subimagenes) y se va dezplazando a medida que encuentra el más mínimo movimiento. Por lo general son bloques de 8x8 u 16x16. Tu idea es relativamente sencilla de hacer, aunque el dilema sería hacer la comparación (que es donde está el verdadero problema). ¿Como estás pensando hacer la comparación? ¿Por bloques de Scanline? ¿O algo un poco más rebuscado, como tratar de buscar un borde y moverte según la dirección? Saludos, |
#5
|
||||
|
||||
Peregrino, si haz logrado avanzar en algo y/o si haz encontrado algo que pudieras compartir con el club me gustaría que lo expusieras, si no te es molestia.
Si bien ya hemos dado unas cuantas ideas, sería oportuno que ofrezcas alguna idea o planteo que hayas conseguido de tus investigaciones. Al menos dime si debo seguir pensandome algun algoritmo parecido al método tree step... porque desde hace 2 días que mi mente anda haciendo round-robin entre todo lo que tengo en mi cabeza y esto... y bueno... todavía no consigo armar algo. Lo que me estaba cruzando por la cabeza es aplicar algo parecido al filtro direccional. Unicamente que en vez de hacer que el pixel tome el valor de la "dirección" hacer que el bloque se mueve hacia dicha en dicha dirección. La idea es que teniendo los pixeles: a b c d e f g h i j j k l m n ñ o p q r s t u v w Siendo el pixel l el central (a examinar), y los pixeles en cursivas (a,c,e,j,n,s,u,w) los posibles candidatos a ser el nuevo punto de detección. El algoritmo lo que debería hacer es tomar la mínima diferencia entre la distancia entre l y cada punto candidato.
Obviamente, debería tomarse el valor absoluto. Y una vez conseguido esto determinar si hay movimiento:
Siendo la MinDifA la menor diferencia en la dirección determinada en la imagen A. El significado es análogo para MinDifB. Y el umbral un valor que refleje a manera "porcentual" lo que podría considerarse un error. Por ejemplo si la diferencia entre MinDifA y MinDifB es de 70, obtendríamos un valor de 0,28 aprox. (o 28%) y si se considera que hay movimiento cuando los valores difieren un 50% entonces, el resultado sería que no lo hay. Si se detecta movimiento en dicha dirección... nos movemos a ese punto y repetir el proceso. Es decir que si por ejemplo se detecta que el movimiento está en la dirección n. Hacemos que el nuevo l sea el pixel n. El algoritmo debería comenzar desde el centro de la imagen (que es donde más probabilidad hay de hallar el movimiento). El algoritmo podría programarse para repetir el proceso entre 3 y 6 veces (lo que podría dar una aproximación de que realmente se ha producido movimiento) No se si les resulta chino pero al menos da una idea. Tras dos días de pensar no he logrado traducir mi idea a código. A lo mejor alguno de ustedes puede llevar a la práctica y someterlo a prueba. Aunque reconozco que la idea de seoane de aplicar sobel y examinar el contorno es una buena opción. Tal vez más eficiente que ésta. Bueno, me despido por ahora... me está venciendo el sueño. Saludos, Última edición por Delphius fecha: 14-02-2008 a las 05:30:03. |
Herramientas | Buscar en Tema |
Desplegado | |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Deteccion de Dispositivos USB | marceloalegre | Varios | 9 | 22-09-2016 13:12:55 |
Detección de una unidad removible | Pascalizado | API de Windows | 13 | 22-05-2011 18:54:51 |
Gradiante de Sobel. Detección de contornos | Delphius | Gráficos | 15 | 04-03-2007 04:06:32 |
Detección de navegador WEB | aerosB4 | Internet | 5 | 08-03-2004 17:27:10 |
Detección de Carga de un programa | craven | Varios | 3 | 24-11-2003 16:10:46 |
|