Después de hacer pruebas con el programita que me hice y que comenté en el anterior post me he dado cuenta de que hay aún problemas para empatar correctamente las pendientes con las imágenes del vídeo.
Si antes el problema lo presentaba el mapeo entre pendientes y distancias, ahora el problema está entre distancias y velocidades de grabación del vídeo. En efecto, la pésima grabación que hice del track no solo afectó a las alturas mal calculadas, también hacía que las velocidades fuesen distintas a las que se reflejan en el vídeo.
Esto hace que al reproducir el RLV en su entorno propio, el software de Tacx, al cabo de unos kilómetros la posición que reflejaba el vídeo, por ejemplo en la entrada de una población, no correspondía con la distancia recorrida que marcaba el track y por eso las pendientes tampoco se correspondían.

El mejor método que se me ocurrió para arreglar esto de una vez por todas es el de usar un mapa de google sobre el cual se dibuja el recorrido y sobre el que se va actualizando la posición real. En este mapa podría ir marcando puntos a medida que se reproduce el vídeo para empatar momentos de tiempo (frames de video) con posiciones GPS y de esa forma consigo exactamente la velocidad entre los puntos que vaya marcando. Por ejemplo, cuando veo en el vídeo una curva a derechas, busco en el mapa de google si la posición actual que me marca en el mapa corresponde con el inicio de dicha curva y si no es así, lo que hago es colocar un marcador que indica donde debería estar (dentro de la propia linea del track) y el programa recalcula las velocidades para todo el recorrido. De este modo, colocando unos cuantos marcadores, se consigue cuadrar a la perfección el vídeo con el track GPS y la corrección que se haga después sobre el perfil quedará perfectamente sincronizada con el vídeo en el software de Tacx.
Para esto he usado el API de Google Maps para Flash. Tardé aproximadamente 30 minutos en poner el mapa, dibujar el recorrido y centrar el mapa en punto de latitud y longitud correspondiente a medida que se reproducía el vídeo, es muy fácil de usar.
En seguida se hicieron evidentes las diferencias entre la reproducción del vídeo y las posiciones en el mapa.
Hacer la funcionalidad para recalcular los tiempos y las velocidades me llevó alguna que otra semana, pero al final todo salió.

En la captura de pantalla se puede ver en azul los marcadores utilizados a lo largo del recorrido para empatar vídeo y latitud-longitud. Hay tramos en los que la velocidad es mas constante y hay menos marcadores y otros tramos en los que hay que colocar mas.
Los marcadores se colocan haciendo click en el punto del track que queramos y también se pueden eliminar si nos hemos equivocado al colocarlos simplemente clickando encima de su icono.
El resto del mapa funciona igual que cualquier otro mapa de google maps, con la salvedad de que en ocasiones al usar el zoom el programa da un error de seguridad (pero no siempre). Supongo que es un problema por usar AIR en vez de simplemente Flash ya que hace poco que el API de Gmaps soporta AIR.

Soy consciente de que es probable que no esté quedando nada claro lo que hago ni porqué lo hago, pero el explicarlo aquí no solo me permite documentarlo un poco sino también organizar mis ideas y conclusiones respecto a este tema. La verdad es que todo esto me resulta muy difícil de explicar porque el problema es bastante complejo de entender si no te has metido a resolverlo, pero lo importante es que voy a tener una herramienta fiable para producir casi en serie los vídeos RLV que quiera. De hecho con este nuevo añadido voy a poder incluso hacer RLV sin disponer del track GPS ya que me bastaría dibujarlo sobre un mapa, calcularle las alturas, ponerle una velocidad constante y luego ir ajustando visualmente con mi mapa las coincidencias entre fotogramas y posiciones geográficas.

Me imagino que en Tacx tendrán una herramienta similar, porque no me imagino a Phil, el encargado de hacer los RLV comerciales, corrigiendo a mano sobre una hoja de cálculo las cifras de pendientes tal y como hace Carsten Jost en su guía de creación de RLV.
… y si no la tienen, siempre estoy dispuesto a trabajar para alguien que conjugue bicicletas + informática

(Creo que esta última frase solo tendría sentido si postease en Inglés como mi colega futur3, pero me da tanta pereza…)

Escribe un comentario sobre "Afinando más los RLV"

Para cocinar un RLV de Tacx se necesita como materia prima los siguientes ingredientes:

• Un ví­deo de un recorrido en carretera o camino, grabado a una velocidad que no supere en mas de 20Km/h la velocidad que llevaría un ciclista normal en ese tramo
• Una grabación simultanea del track GPS del recorrido.

Como los GPS tienden a perder señal de vez en cuando y se vuelven un poco erráticos, siempre hay que hacer una labor de limpieza antes de poder pasar a usar el track obtenido.
Se trata de ajustar el archivo GPX obtenido del GPS eliminando puntos parados y sobrantes al inicio y final y puntos aberrantes a lo largo del recorrido. Usando CompeGPS sobre un mapa de google puedes darte cuenta cuando el track se ha desviado del recorrido e intentar retocar esos puntos para que cuadren lo mas posible.
Un indicador muy sencillo es pedirle al Compe la lista de puntos poniendo una columna con la velocidad entre ellos. Como los puertos los subo a una velocidad baja, cuando hay perdida de señal suele haber variaciones imposibles de velocidad, como 120 o 200 Km/h. Esos puntos hay que corregirlos ubicandolos de tal modo que la velocidad entre ellos sea la que tiene que ser, o cercana.
También se toman medidas erróneas de altitud y estas son mas difíciles de corregir, ya que los errores suelen acumularse y luego corregirse de golpe, con lo que aparecen escalones de varias decenas de metros en el perfil que serian sencillas de suavizar si no fuera porque lo mas probable es que luego la pendiente obtenida no coincida con lo que estamos viendo en el vídeo.

Cuando el track está ya limpio paso a ejecutar la aplicación de conversión que he creado, que convierte el GPX en un fichero RLV que básicamente contiene las velocidades a las que ha sido grabado cada tramo del video y un PGMF que contiene las pendientes para cada tramo del recorrido. Ambos tramos, el de la velocidad y el de la pendiente, no tienen por qué ser coincidentes.

Aún con estas correcciones, la mayoría de las veces no se consiguen unas pendientes coincidentes con la carretera que estamos viendo en el vídeo. Si suavizas mucho poniendo tramos largos con la misma pendiente, habrá cuestas arriba y abajo que no se reflejen en el rodillo. Si por el contrario haces tramos demasiado cortos, en algunos momentos las pendientes serán ridículamente altas para distancias muy cortas y variarán mucho, por lo que no se consigue un recorrido fluido.

Todo esto es especialmente cierto si, como me ocurrió en las primeras grabaciones, has configurado mal el GPS y has grabado muy pocos puntos. Si el GPS captura un punto del track cada 10 segundos, por ejemplo, a 40 o 50 por hora recorres mas de 100 metros en ese tiempo (50km/h = 11.1m/s) y ahí puedes haberte perdido muchos altibajos del camino. Lo ideal es configurar el GPS para grabar un punto por segundo.

He intentado arreglar el desaguisado resampleando el track con un programa que he descubierto que te permite hacer esto y muchas otras cosas (cosas muy curiosas como redes de caminos a partir de tracks y varias opciones muy interesantes para ciclismo) con los mapas y tracks. El TopoFusion tiene una opción de interpolar mediante splines un track que te permite insertar el número de puntos que quieras entre los puntos de tu track, trazando curvas donde antes habí­a rectas y siguiendo así­ de manera mas natural lo que podrí­a ser el movimiento real que ha habido entre dos puntos capturados por el GPS.
Aquí se puede ver un ejemplo de track resampleado con splines.
A pesar de que TopoFusion también interpola y splinea las alturas, decidí­ volver a recalcular automáticamente la altura de los puntos. Esto lo hace el CompeGPS mediante mapas de relieve, pero el TopoFusion también lo hace usando además diferentes métodos (Climbing Analisys) para que elijas el que mas se ajuste a la realidad. Las alturas interpoladas son inventadas y las del mapa de relieve, aunque no tienen mucha resolución, al menos son reales.

El problema es que muchas veces una carretera no se corresponde con la altura media de la zona donde se encuentra, y esto es especialmente cierto para pasos elevados, puentes, túneles, o curvas en herradura, que son bastante habituales, por lo que al final, el resultado del cálculo automático de alturas sigue siendo desastroso e irreal y las pendientes no corresponden con la realidad mas que en unos pocos tramos.

Por eso he tenido que construirme un programita en AS3, usando Air para poder guardar archivos, que sobreimpresiona el perfil de la etapa sobre el vídeo de la misma y permite ir seleccionando tramos para corregir o establecer su pendiente de forma manual, consiguiendo de este modo un resultado mucho mas natural y unas sensaciones mas realistas. A cambio, la programación para sincronizar el vídeo, que funciona por tiempo, con el perfil, que lo hace por distancia, ha sido bastante compleja, pero aquí tenéis un ejemplo de como luce la aplicación. Como es para uso interno, no tiene adornos, que nadie me tache de cutre!!

Le he ido añadiendo lo que necesitaba. Todos los datos sobre la posición actual, distancia, tiempo, pendiente y altitud así como botones para seleccionar tramos (zona en verde), cambiarles la pendiente, o flechas para subir o bajar el perfil y para guardar archivos con el resultado, tanto en un xml de cosecha propia que he llamado “prf” y que es el archivo que lee el programa para comparar el perfil original (en blanco), que se toma de un GPX, con el perfil retocado (en rojo), como en el formato nativo de Tacx pgmf.

Ahora ha producir perfiles como loco para la LEVE!!!

Escribe un comentario sobre "Mi primer RLV"

Estaba intentando parsear un archivo xml desde ActionScript 3 y me he encontrado con que no funcionaba.
El contenido estaba en el objeto XML pero al intentar acceder a cualquiera de los nodos mediante nombre, AS3 me devolvía un elemento nulo.
Solo lograba hacerlo funcionar si en la cabecera del fichero XML le quitaba la declaración de namespace que se hace mediante el atributo xmlns.
El problema es que el XML lo produce un software de terceros y no tengo control sobre su formato, así que eliminar la declaración del namespace no es posible.

El problema ha sido precisamente el namespace. El atributo xmlns estaba definiendo el nombre del namespace del tipo de archivo XML que estaba leyendo, pero yo no estaba usando dicho namespace para acceder a los elementos del arbol XML, por eso no los encontraba.
El namespace es una clase que se usa prefijando con ella cada nombre de nodo separándolo de este con el operador :: (name qualifier) , por ejemplo

Esto es un auténtico coñazo, sobre todo cuando te enteras de que esa URI que se declara en el XML no tiene por qué apuntar a nada en concreto, simplemente debe ser única con respecto a todos los namespaces declarados por otros tipos de archivos XML. Como es un identificador tan largo se suele asignar el objeto Namespace a una constante y acortamos.

Pero como sigue siendo un rollo prefijar todos los accesos a los nodos, lo mejor es definir que el namespace por defecto apunte a la declaración correspondiente y ya está. Esto se hace con la orden

Y a partir de ese momento todos los accesos a nodos del xml se realizarán como si fuesen prefijados con ese namespace.

Así todo vuelve a funcionar.

Escribe un comentario sobre "Namespaces XML en AS3"

El manejo de vídeo desde Flash es relativamente sencillo. Desde AS3 se utiliza la clase FLVPlayer a la que solo hay que definirle unos pocos parámetros para que enseguida comience a reproducir el vídeo en formato FLV que le especifiquemos.

Esta clase permite entre otras cosas posicionar la cabeza lectora del video en cualquier posición
de tiempo dentro del mismo con una precisión de milisegundos mediante la propiedad playheadTime, que es equivalente al método seek.
He necesitado usar esta propiedad pero me he encontrado una desagradable sorpresa cuando he intentado posicionar la cabeza lectora, por ejemplo, en el segundo 5, el vídeo se iba a la posición 5.75. Siempre.

Después de investigar un rato he llegado a la conclusión de que solo se puede posicionar la cabeza
en frames marcados como keyframes (o I-Frames), por lo que si has encodeado el vídeo con un keyframe cada 12 frames (valor habitual) y el video es a 25fps te encuentras con que solo te puedes posicionar en determinados momentos de tiempo del vídeo, en este caso puedes posicionarte en el segundo 0.48, 0.96, 1.44, 1.92, etc…
El caso es que necesito posicionarme en segundos exactos por lo que no me queda otra solución que encodear el vídeo con una frecuencia diferente, de un keyframe cada 5 o uno cada 25 si no necesito tanta resolución. La primera solución, por supuesto provoca un aumento significativo del tamaño del vídeo, pero en mi caso eso no es ningún problema, solo es algo que hay que tener en cuenta a la hora de preparar los vídeos para la aplicación. La segunda solución empeora la calidad, pero disminuye el tamaño. Como mi caso es para hacer una previsualización, pues tampoco es importante la calidad.

De los encoders de FLV que tengo a mano, el único que me ha dejado elegir el numero de keyframes ha sido el propio Adobe Flash CS3 Video Encoder y despues de esperar un buen rato porque es muy, muy lento, resulta que al principio lo hace bien, pero no es capaz de poner los keyframes EXACTAMENTE cada 25 frames de una manera constante, por lo que a los pocos segundos comienza a desincronizarse con lo que al final me encuentro con el mismo problema. Parece que los keyframes no son una ciencia exacta.

Escribe un comentario sobre "Precisión de playheadTime"

En los viejos tiempos de la demoscene nadie tenia dudas cuando le decías que tenias un MOD que flipabas, se sobreentendía que se trataba de un módulo de música secuenciada a partir de muestras de audio, que tenia 4 canales y que era una canción compuesta en un tracker, probablemente el Protracker en un Commodore Amiga.
Pero ahora ya no se respeta nada y alguien en alguna multinacional se ha apropiado de la extensión para marcar con ella los archivos de vídeo que generan principalmente las cámaras de JVC, Panasonic y de Canon que graban directamente a tarjeta SDHC o disco duro.

Lo primero que me llamó la atención al sacar los archivos que acababa de grabar con mi nueva cámara es que por cada escena había 2, y que ninguno de ellos tenía una extensión conocida o estándar. Los archivos eran MOD, que viendo su tamaño se hacía obvio que contenia el video, y MOI.
Como el VLC tiene fama de reproducir cualquier tipo de video sin importarle siquiera si el archivo está corrompido o la cabecera es errónea, intenté hacerle tragar el MOD directamente. No se lo traga. Sin embargo si lo renombras a MPG si funciona, aunque el aspect ratio es incorrecto.
Un MOD de vídeo no es mas que un archivo de video MPEG-2 con audio codificado en AC3. El archivo MOI contiene información acerca de la fecha de la grabación, el aspect-ratio (que habitualmente está en la cabecera de los MPG) y otros datos interesantes. El dividir la información en estos dos archivos es una recomendación de la definición del estándar de las tarjetas SD.
El problema es que este estándar que han adoptado las cámaras de vídeo aun no lo soporta ninguno de los programas mas extendidos de edición de vídeo, por lo que te encuentras con que tienes unos archivos que no puedes editar.

Para trabajar con ellos hay que convertirlos… lo cual es una bobada. Canon te proporciona un software, ImageMixer 3 for SD que hace básicamente eso, convierte el MOD/MOI en MPG. Pero si hay que convertirlos según los sacas de la cámara… ¿porque guardarlos como MOD y no directamente como MPG?

Un artículo de Robin Good me ha permitido conocer los vericuetos de este formato y lo que hay que hacer con el para poder usarlo con los programas habituales de edición de vídeo.

Las soluciones son:

• Renombrar el archivo de MOD a MPG y luego verificar en el programa que usemos para editarlo que las propiedades del vídeo corresponden a las reales, es decir, que es PAL/NTSC, que el aspect ratio que el programa ha asignado al vídeo es el correcto (4:3, 16:9) y que el interlacing también es el adecuado.
• Si has grabado en 16:9 es mejor que uses el programa SDCopy, que te convierte los MOD en MPG copiando la información de aspect ratio que tu le digas en la cabecera del MPG.
• Para editar correctamente los MPG resultantes es mejor que uses programas que permitan el “smart rendering” o renderizado inteligente.

Si después de convertir el vídeo necesitas saber cuales son los datos originales que vienen en el archivo MOI, que son básicamente la fecha y hora del inicio de la grabación, el aspect ratio, la calidad a la que se grabó, la longitud del mismo u otros datos, puedes abrirlo con un editor hexadecimal, y siguiendo esta tabla que ha elaborado mediante ingeniería inversa Karl Zeilhofer, averiguar que es cada valor.

Si solo quieres visualizar el vídeo, pues basta con renombrarlo, meterlo en el VLC y seleccionar el aspect ratio correcto en el menú de vídeo y la opción de desentrelazar “blend” o en la versión en español “mezclar”.

En la página que he referenciado anteriormente de Robin Good se explican cuales serían las soluciones de edición de MOD mas sencillas tanto en PC (muy sencilla) como en Mac (algo complicada). Increíblemente el Movie Maker que viene gratis con Windows, si se configura bien, importa correctamente los MOD renombrados a MPG.

Escribe un comentario sobre "Archivos de video MOD y MOI"

No es un error, estoy convirtiendo mi coche en una cámara de vídeo ambulante. ¿Para que? Pues para grabar recorridos en carreteras recónditas, subidas imposibles o lugares míticos del ciclismo y luego reproducirlos en mi rodillo de entrenamiento Tacx Fortius.
Los RLV (Real Life Video) no los he inventado yo, ya me gustaría, solo los he retroingenierizado (toma palabra) para averiguar como están hechos y poder crear los míos propios. Pero de eso ya hablaré mas adelante.

De momento he tenido que construir un soporte para anclar firmemente la cámara de vídeo al salpicadero del coche. Como en todo lo que hago, pretendo que sea reversible, es decir, que se pueda deshacer sin romper nada, por ello no puedo simplemente atornillar la cámara al salpicadero, que sería una opción rápida y fácil.
El lugar elegido para ubicar la cámara es un porta documentos que tiene mi coche en la parte central del salpicadero. Dentro de ese porta documentos ya alojé en su día la PDA reciclada que me hace de GPS. Ese porta documentos se puede extraer, con cuidado, dejando un hueco ideal para mis propósitos.

Con dos pequeñas planchas de madera, una ancha, la que sostendrá la cámara, y otra estrecha, la que amarra el conjunto al plástico del salpicadero, he construido una especie de mordaza o tornillo, que una vez apretado conforma una base plana perfecta para colocar la cámara.

Pero la cámara necesita poder ser girada y cambiada de ángulo para ajustar la posición antes de comenzar la grabación. ¡Que mejor que la cabeza de un trípode de fotografía, de esos minúsculos de a 7 euros la pieza!. El tornillo encaja a la perfección en el agujero para trípode de la cámara, y al ser totalmente desmontable, se le pueden quitar las patas sin siquiera romperlo, con lo que podemos seguir usándolo para lo que en un principio fue ideado, cuando no lo estemos usando.
La cabeza del trípode tiene un agujero para atornillar tornillos de métrica 4. Con uno de estos tornillos atravesando la plancha de madera desde abajo consigo asegurar la cabeza del trípode a la base y de este modo obtengo el sitio perfecto para poner la cámara.

Para mis propósitos también necesito grabar el recorrido con un GPS que guarde tracks (los de coche normalmente no lo hacen). Mi Garmin tiene un hueco reservado en la base de madera, con un soporte hecho de aluminio que imita el que tengo en el manillar de la bici y en el que encaja perfectamente.

Una vez montado el conjunto, usando el mando a distancia de la cámara, puedo poner a grabar los dos aparatos al tiempo y así obtengo un metraje de vídeo que se corresponde con un track GPS que me proporciona alturas y velocidades. De este modo puedo luego escribir los archivos de Tacx con las pendientes de las cuestas y sincronizarlas con los puntos del vídeo donde comienzan, para que el rodillo aumente o disminuya de dureza dependiendo de si vas cuesta arriba o cuesta abajo y ademas, puedo escribir también la velocidad en Km/h a la que fue grabado el vídeo para que el software del RLV pueda acelerar o frenar la reproducción del mismo dependiendo de la diferencia entre esa velocidad a la que fue grabado y la velocidad que le imprimo a la bici al dar pedales en el rodillo.

La primera prueba está hecha, y me ha servido para detectar unos cuantos problemas.

1. Las vibraciones. Cuando el firme está un poco irregular se transmiten demasiadas vibraciones y la cámara tiembla. El estabilizador de imagen no es capaz de “comérselas”. Supongo que esto tiene algo que ver también con el tipo de coche y la cutre suspensión. He probado con un poco de goma espuma y juntas tóricas de goma en las arandelas para desacoplar un poco la cámara del coche, pero no ha sido una gran diferencia.
2. El parabrisas. Hay que limpiar el cristal a conciencia para que no se vean las manchas. Voy a tener que echarle cristasol o algo. (Corrección: el cristal no está manchado, está “chinado”, tiene multitud de impactos de pequeñas chinas de tierra que no se quitan limpiando, quizás se puedan quitar puliendo, tendré que visitar a mi colega de Shinycars). Una solución sería poner la cámara fuera del coche (tiene mando a distancia), pero no se puede por la apertura focal que explico mas abajo.
3. Los reflejos. Hay que tapar con una tela negra u otro material que no refleje la luz para evitar que la propia base de la cámara se refleje en el parabrisas del coche y se vea en la grabación.
4. El sol. Hay que evitar grabar de cara al sol, está es de perogrullo jeje. Es mejor en las horas centrales del dia ya que el sol está alto y normalmente no pega directamente en la cámara. No es solo por los cambios de luz, sino porque los defectos del parabrisas se hacen demasiado evidentes a contraluz.
5. La apertura focal. Las cámaras domésticas no tienen una gran apertura focal lo que hace que al tomar curvas demasiado cerradas en ocasiones el foco pierde de vista la propia carretera y eso queda muy feo en los vídeos que intento grabar. La solución estaría en atrasar un poco mas la cámara, pero esto haría que se grabase mas zona del parabrisas, captando mas imperfecciones. Por eso tampoco se puede poner la cámara en el capó, porque cuanto mas cerca de las ruedas directrices, menos carretera se ve en los giros cerrados.

Por lo demás no estoy demasiado contento con la calidad. He grabado en XP y se ve bien si la imagen no se mueve mucho, pero si hay mucho movimiento (como cuando se va en coche) se ven líneas, como si tuviera un entrelazado (interleaved). La calidad no es mala, el problema del entrelazado de lineas se soluciona poniendo en el reproductor que haga blending con el entrelazado. Entonces dejan de verse las lineas. Aún me queda mucho por aprender de esto del video .

En la primera prueba no me he dado cuenta y grabé un trocito del capó, pero con la base del trípode como soporte eso se ha corregido muy fácilmente .
Aquí va una primera prueba. La compresión que hace youtube no permite apreciar la calidad real de la grabación, y además me ha cambiado el aspect ratio, pero es para hacerse una idea.

Escribe un comentario sobre "Video Car-mera"

Como se puede ver en mi whislist, recientemente he sido obsequiado por mi cumpleaños con una magnífica videocámara Canon FS100. No, no me malinterpreteis, no es que yo sea el típico personaje coñazo que armado con su cámara intenta inmortalizar aburridos eventos familiares dejando para la posteridad en algún formato de almacenamiento digital las tonterías que se dicen o se hacen cuando las personas ven, o presienten, que se les está grabando; no, mis intereses van mas por el tema de experimentar y hacer algún webcast en condiciones de mis experimentos como un dia me sugería Futur3.
El caso es que al elegir pedí consejo a alguno de mis compañeros de Soygeek (DJ Shivan) que se dedica al 3D y la producción de vídeo y para una cámara amateur, me recomendaron Canon. Como no quería que fuese demasiado cara, pero me interesaba huir de las cintas MiniDV, al final opté por la Canon FS100, que es igual que la FS10, solo que 100 euros mas barata y sin memoria interna.

La FS100 es una de esas cámaras que apuesta por la memoria de estado sólido evitando los problemas de los discos duros y las averias mecánicas de los motores de las cintas MiniDV, y funciona con tarjeta de memoria, para ser exactos con las nuevas tarjetas SD HC (Secure Digital High Capacity) que son incompatibles con los lectores antiguos pero que permiten superar el límite de 2Gb que tienen sus hermanas pequeñas, las que no son HC. Las HC empiezan en los 4Gb y llegan hasta los 32Gb (por el momento).
Como la cámara viene pelada, sin tarjeta, me tuve que poner a buscar que tarjetas necesitaba y donde conseguirla económica, que la cosa no está para ir tirando la pasta.
Al final acabe de nuevo donde PROMETO que no voy a volver a acabar, comprando a un chino por Ebay.

Lo malo de meterse en nuevos vicios o inquietudes, es que se aprende poco a poco, y a mi no me gusta aprender poco a poco, soy un tanto impaciente para el conocimiento, así que he intentado absorber toda la información posible en poco tiempo para tener lista la cámara y realizar las primeras pruebas.
Como digo, después de saber que necesitaba una SD HC le compré una tarjeta de 8Gb a un chino que la vendía por escasos 10Euros, gastos de envío incluidos. Lo que no había estudiado suficientemente es que hay 3 tipos de tarjetas HC, las de clase 2, clase 4 y clase 6 y que la diferencia entre unas y otras es la velocidad de lectura y escritura.
Parece una tontería, pero como es lógico, mi tarjeta, que llegó perfectamente en aproximadamente una semana, era de clase 2.

• Class 2: Mínimo 2Mbps de transferencia (habitualmente entre 3 y 5Mbps), válidas para MPEG2(DVD) y MPEG4
• Class 4: Mínimo 4Mbps de transferencia, válidas para MPEG2(DVD), H.264(HDV), Hi-speed D-SLR
• Class 6: Mínimo 6Mbps de transferencia (habitualmente entre 12 y 22,5Mbps) , válidas para HDV Profesional y D-SLR de alta velocidad.

El caso es que mi SDHC funciona de manera correcta, PERO, aquí llega el gran pero, la cámara tiene 3 modos de grabación en dos formatos diferentes (modos XP, SP, LP y formato 4:3 o panorámico) y resulta que para formato panorámico, el modo LP necesita una velocidad de escritura de 3Mpbs, el SP de 6Mbps y el XP de 9Mbps… y como eso no lo pone en el manual (si, si, me lo he leído de cabo a rabo y en inglés además) esto no lo sabes hasta que:

1. Estás atento y te fijas al seleccionar el modo de grabación que te indica la velocidad de escritura (3,6 o 9 Mbps)
2. Montas una tarjeta de Clase 2 y te das cuenta de que al cabo de 1 minuto la cámara da un error de buffer overflow y para de grabar, con el consiguiente cabreo y recordatorio para la madre de todos los chinos. Cuando se te pasa el cabreo vuelves al punto 1.

Total, que solo puedo grabar en LP (3mbps, la mínima calidad de la cámara) hasta que consiga, esta vez en una tienda, y con prueba de por medio, una tarjeta de 8Gb clase 6 que cuesta el doble que en china, pero va cuatro veces mas rápido. Por ejemplo una transcend que da hasta 13Gbps en escritura.

Repite conmigo: no mas chinos, no mas chinos, no mas chinos… es inútil, se que volveré a caer XD

Escribe un comentario sobre "De videocámaras y tarjetas SDHC"

Recordatorio: Si una consulta compleja a una base de datos, que contiene subselects dependientes, o LEFT JOINs no te funciona como esperas o no lo hace correctamente en phpMyAdmin y te produce un error sin mucho significado, no desesperes, intenta ejecutar directamente la sentencia desde php porque es posible que está bien, pero que phpMyAdmin la está cagando en algún momento.
Me lo digo a mi mismo para no tener que volver a perder 3 horas intentando rehacer una query que el dia anterior funcionaba correctamente.

Otra cosa a tener en cuenta. En subselects dependientes las dependencias solo son validas con la select padre, no con la abuelo (la padre de la padre). P.ej.

Esta select da error ya que el select mas interno, está a dos niveles del select que define tabla2, por lo que no la ve.

Ya me lo decía mi madre… ¡no trabajes con bases de datos de juguete!

Escribe un comentario sobre "No te fies de phpMyAdmin"

Como ya dije, según fuese aclarando las dudas acerca de detalles de la creación de componentes en Joomla 1.5.6, las iría publicando, así que allá voy con las primeras:

¿Como insertar una definición de hoja de estilo propia desde una vista generada por mi componente?

Pues no es muy elegante, pero asi es como se hace:

¿Como hago para que mi módulo aparezca en el Pathway de la página, también llamado modulo BreadCrumb?

Para variar, menos elegante aún que la anterior, usando la palabra clave global que es la antitesis de la ocultación de datos y por tanto de la orientación a objetos, hacemos referencia a una instancia del JAplication que se llama mainframe (¿y como sabemos eso?). Ignoro si hay una forma mas ortodoxa de hacerlo. En una de tus vistas mete este código en el método display:

¿Por qué no consigo recuperar el modelo desde una de mis vistas?

Lo mas habitual es que se te haya olvidado poner el nombre del modelo en cuestion que necesitas. Si dejas el parámetro del nombre del modelo vacío, la vista tratará de encontrar un modelo con el mismo nombre que ella. La solución es poner el nombre del modelo o crear un modelo con el mismo nombre que la vista.

o

Escribe un comentario sobre "Dudas Joomla"

Llevo varias semanas investigando como hacer componentes para Joomla 1.5.6. Ya he conseguido alguna cosilla, pero no es tan sencillo como en un principio se suponia que iba a ser.
Joomla 1.5.6 usa una arquitectura basada en el patrón MVC (Modelo Vista Controlador), algo que no es nada nuevo en otros lenguajes como Java o Ruby pero que en php no es tan habitual, al ser php históricamente un lenguaje menos formal.
En MVC las aplicaciones tienen 3 partes diferenciadas:

• El modelo: se encarga del manejo de datos, de extraerlos, validarlos y almacenarlos, ya sea en base de datos (lo mas habitual) o en otros medios. Si alguna parte de la aplicación necesita manejar datos, se los pide al modelo.
• El controlador: recibe las peticiones del usuario y las transforma en acciones reales del programa. Habitualmente pidiendo datos al modelo y haciendo operaciones con ellos para después elegir una vista adecuada con la que mostrarlos.
• La vista: se encarga de la visualización de los resultados del proceso que ha tenido lugar en el controlador.

Esta división supone una gran ventaja, y es que cuando necesites ampliar la aplicación es muy sencillo saber que parte debes tocar, que es cada cosa y donde está ubicada. Como contrapartida la complejidad de hacer una aplicación se dispara, la programación orientada a objetos se hace obligatoria y muchos desarrolladores de php amateur quedan fuera de juego.
Con esta aproximación, programar en php no difiere mucho de hacerlo en Java, ya que php orientado a objetos (php 5) tiene una sintaxis muy similar a C++ y por tanto a Java, pero sin las ventajas que este ultimo ofrece en cuanto a tipado fuerte (los tipos de datos hay que declararlos siempre y el compilador da error si se asignan valores u objetos de un tipo incorrecto), por poner un solo ejemplo.
La laxitud en determinados aspectos del lenguaje que presenta PHP era muy buena cuando se trataba de hacer pequeños (o grandes) scripts que funcionaban de manera secuencial, o funcional, pero cuando entran en juego conceptos como la herencia de clases, los interfaces o las clases abstractas PHP te obliga a hacer casting especifico en cada asignación si quieres tener la certeza (mediante un error en tiempo de ejecución, ya que php no se compila) de que estas asignando una objeto válido, y eso es muchísimo mas trabajo.
Lo que ofrece el framework de Joomla en su implementación del MVC que mejora o al menos aligera el trabajo que tiene programar en entornos similares en Java como Spring o Struts es que Joomla tira mucho de “convención” en lugar de hacerlo de “configuración” como hacen los frameworks Java. En eso se parece mucho mas al RubyOnRails aunque sin llegar al extremo de este ultimo, que es el lenguaje de las convenciones por antonomasia.

Lo bueno de la programación por convención es que te ahorras escribir innumerables ficheros de configuración en los que le indicas al framework que es cada clase, si es parte del modelo, de la vista o del controlador, donde se ubica, etc. ya que automaticamente Joomla espera que las clases que representan cada cosa tengan un nombre concreto que se compone de varias partes. Lo malo es que tienes que saberte esas convenciones, que no son estándares, o si no puedes recordarlas, al menos tener una buena documentación de referencia que las explique, cosa de la que, a mi modo de ver, carece Joomla.
La documentación de Joomla está muy orientada al usuario o administrador del sitio que se crea con el, pero es mas difícil de encontrar buena documentación para el desarrollador que a menudo se ve tirando de tutoriales hechos por terceros, consultando foros recónditos y buceando en el código de los componentes que vienen de serie para poder entender como se hacen determinadas cosas.

Y bueno, despues de este “Rant & Rave” no me queda mas que recomendar un par de tutoriales para aprender lo básico (y solo lo basico) sobre como hacer componentes en Joomla 1.5.6. Soy un poco pesadito con la versión de Joomla porque la anterior, la 1.0, no usa el paradigma MVC y por lo tanto la creación de componentes es completamente diferente.

El primer tutorial está en español y es el de Nosolocodigo de David Noguera. Lo cierto es que es un tutorial muy clarito y desmenuzado, aunque no entra en muchos detalles (lo cual es de agradecer si es el primer tutorial que lees), es sin embargo muy bueno para empezar. Si hay algo que echarle en cara es el ejemplo escogido. El “hola mundo” habría sido una birria, pero llamar “prueba” a tu componente es bastante poco esclarecedor y antieducativo
Otro tutorial lo he encontrado en el propio wiki de Joomla y consta de 4 partes. Puede parecer que me contradigo pero no, el tutorial está bien (salvo por el hecho de que, si, en efecto, al componente lo han llamado “Hello”), es un poco mas completo que el de nosolocodigo (de hecho estoy casi seguro de que David se ha basado en este) pero hay cosas que se quedan sin explicar y que no son fáciles de encontrar. Algunas que echo en falta yo: ¿como metes tu aplicación en el menú del administrador? ¿como creas date pickers en tus formularios? ¿como insertas una hoja de estilo propia de tu componente en la vista? Cuando encuentre las respuestas las iré poniendo.

Es poco probable que haga un tutorial, ya que ya existen estos dos, pero lo mismo problemas concretos si que publico.

Escribe un comentario sobre "Componentes en Joomla"