El pasado mes de Junio conseguí terminar algo que llevaba tiempo en mi lista de QUEHACER (TODO list para los que no lo hayan entendido) el interpretar y realizar una versión de una idea genial que tuvo Igor Chak, un diseñador industrial que personalmente me causa admiración, de crear una estantería para el salón basada en el clásico de los videojuegos “Donkey Kong“.
Igor Chak es también el creador del sofá “space invaders”, que por cierto pasó de ser un concepto a ser un producto que vende en su propia página web (por 5000 dolares de nada, gastos de envío aparte, por si os interesa).
Yo no aspiraba a tanto, el concepto de estantería estaba pensado para hacerse en fibra de carbono, aluminio, acero inoxidable y tapas de cristal templado… una pasta, vamos. Además tampoco necesitaba una estantería, hace mucho que no compro libros, ni CDs ni adornos para el hogar, así que mi proyecto se adaptó al material y al tiempo que tenía disponible, que era mas bien escaso.
Con un par de baldas de una estantería de malla de acero cromada que se encuentran fácilmente en LM y mi amiga la dremmel me hice varios pisos del entorno del juego original. Corté las estanterías por la mitad longitudinalmente y usé los nervios de acero de los extremos doblándolos a modo de ganchos, para que la estantería se pueda enganchar en un soporte de aluminio que también fabriqué para la ocasión y que va atornillado a la pared.
Para emular los barriles, use un par de latas de refresco a las que les eliminé la pintura con un buen lijado, así quedan en aluminio bruto y no desentonan con el acero de las estanterías.
Por último, las escalerillas, las saqué de algunos de los nervios de la mitad de estantería que me sobraba, y las pegué en su sitio con cola termofusible.
Como toque final, unas figuritas compradas baratas en la inagotable fuente de chorradas chinas que es DX y aquí está el resultado.
Es una lástima que no tenga fotos del proceso, pero sinceramente, pensé que nunca volvería a escribir en el blog .
Y volviendo al Donkey Kong, he de confesar que me gusta este juego porque a pesar de que el mono gordo basado en King Kong era el “malo” del juego, resultó tener mas protagonismo que el protagonista, que era Mario (Jumpman por aquel entonces), supongo que principalmente debido al propio nombre del juego. Esto sucedía en 1981 y de hecho en 1982 Mario fue el malo del juego en Donkey Kong Jr. que era la secuela. Mario no se convirtió en Mario y en un héroe hecho y derecho hasta que salió Mario Bros en 1983.
Para editar los vídeos RLV he usado el Sony Vegas Movie Studio, programa muy completo y versátil que permite hacer infinidad de cosas con ellos.
Los dos vídeos que he hecho para el Tacx Fortius, La Cruz Verde y La Morcuera, disponibles para su descarga en la web de la Liga de Entrenamiento Virtual en Español (LEVE), funcionan a la perfección en el software Fortius, pero pronto me hicieron notar algunos de mis colegas holandeses que no funcionaban tan bien en el nuevo software que ha sacado Tacx, el TTS (Tacx Training Software).
El problema es que ya desde el momento de la previsualización del video, mientras todos los demás RLV de Tacx y de otros autores particulares presentan el primer fotograma, mis vídeos se ponen en marcha inexplicablemente y a una velocidad endemoniada.
El efecto mola si no fuera porque al iniciar el entrenamiento el vídeo va a su bola, y avanza a toda mecha sin necesidad de que demos pedales en el rodillo.
Intentando aislar el problema descarté primero que fuese el archivo rlv, y al final me di cuenta de que era problema del propio vídeo AVI. He intentado cambiar datos de la cabecera del mismo con un editor hexa, cosas como el dwQuality que estaba a 0xFFFF y solo debe tener valores entre 0 y 10000, o el xdwSampleSize que debería ser cero y no lo era, pero nada daba resultado.
La última prueba ha sido recodificar de nuevo el vídeo de AVI a AVI usando el ffmpeg, la herramienta por excelencia para el transcoding, y mire usted por donde, se ha arreglado.
Parece que tendré que darles un lustre final a todos los videos que haga a partir de ahora pasandolos por el ffmpeg.
Como sabéis los mas asiduos, he pasado los 3 últimos meses intentando crear un vídeo RLV para el rodillo Fortius. En mi ultimo post, afinando aún mas los RLV, parecía que por fin había conseguido mi propósito, pero no. Debido a un incompleto entendimiento de uno de los conceptos fundamentales de los RLV, mis vídeos nunca estaban bien sincronizados con el perfil de la etapa.
El concepto en cuestión es el de “distance per frame“. Los archivos RLV tienen unos registros que se llaman así. Se componen de un número de frame y un valor que indica la distancia que es necesario recorrer con el rodillo a esa altura del vídeo para que se pase al siguiente frame.
Este dato se calcula a partir de la velocidad a la que nos movíamos mientras se grabó el vídeo y su tasa de frames por segundo, por ejemplo, si he grabado un tramo a 50Km/h, que son 13,8m/s y el video fue grabado a 25fps, en ese tramo el valor de distancia por frame será de 13,8 / 25 = 0,555 metros por frame.
Me he pasado semanas haciendo números, porque yo entendía que desde un registro hasta el siguiente el valor de distancia por frame se mantenía constante… y ademas no se me ocurría ninguna otra posibilidad.
Pregunté por el tema a Phil, el que hace los videos oficiales, y no obtuve ninguna respuesta (no les hace gracia que la gente haga sus propios vídeos). Pregunté a B. Maesen (Wesp_im), el que hace las camisetas oficiales del VR y aunque el no sabía nada, me puso en contacto con Hannes Schellnast, un Austriaco que ha hecho un par de vídeos a mano, usando una variante del sistema de hojas de cálculo de Carsten Jost.
El ha sido quien, después de investigar un poco se ha dado cuenta de una cosa muy importante. Desde un registro de distance per frame a otro, el valor de distancia NO se mantiene constante, sino que se interpola desde el valor de origen hasta el de fin. Una vez entendido esto, ya he podido corregir mi conversor para que saque unos valores de distance per frame adecuados.
Frame number
Distance per Frame
0
0,5
1
0,5
8
1
9
1
Esto es lo que yo pensaba que ocurría:
Y esto lo que ocurría en realidad:
Como se ve, el valor de distancia por frame varía de forma lineal en el intervalo que no está definida, es decir, entre el frame 2 y el 7. Esto explica todos los comportamientos anómalos que obtenía en mis pruebas ya que en cuanto creaba un registro nuevo, mis valores estimados de velocidad no coincidían con los que al final calculaba el software de Fortius y todo se desfasaba.
En palabras del propio Hannes: “Teóricamente la distancia cubierta se calcularía vía una integral desde el frame 1 hasta el 9. En nuestro caso hemos interpolado valores discretos para los puntos de distancia por frame. Esto significa que no usaremos integración gracias a que los saltos entre frames son discretos y no infinitesimales. Supongo que el algoritmo que usa Tacx calcula la nueva distancia cubierta para cada paso de frame al siguiente con el valor de distancia por frame interpolado. Hay que tener en cuenta que la dependencia entre frames y distancia cubierta no será lineal para el rango de frames entre el 1 y el 9. Debido al uso de valores de frame discretos se produce un pequeño error de cuantización respecto al valor que saldría con un cálculo teórico basado en integrales. Este error es tan pequeño que se puede despreciar.”
Ahora ya comprendido el funcionamiento he cambiado la generación de los .rlv y parece que todo coincide, casi a la perfección. A Hannes le debo una y probablemente le envie un regalito, ¿alguna sugerencia de algo que enviarle que no se rompa de aqui a Austria?
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.
Joomla es un CMS que me he pasado unas semanas evaluando para montar un par de sitios web en tiempo record.
A pesar de que estoy mas a favor de hacer webs robustas con tecnologías Java, he de reconocer que para ciertos sitios con poco tráfico usar frameworks java es matar moscas a cañonazos y el esfuerzo no merece la pena. Eso unido a que la mayoría de los hostings de precio razonable solo ofrecen soporte para tecnología LAMP me hicieron investigar las opciones en PHP con Mysql, especialmente las mas utilizadas como son Drupal y Joomla, heredero de Mambo. Antiguamente había llegado a usar PHPNuke también, pero no guardaba un buen recuerdo.
Por comentarios de mis amigos de Soygeek al final me decanté por Joomla y aunque al principio resultó un poco confuso el acostumbrarse a la terminología específica que usa, una vez interiorizada es mas sencillo orientarse por todo el sistema de administración.
Para usar Joomla sin contratiempos debes saber lo que es:
Article
Category
Section
Component
Module
Plugin (antes mambot)
Template
Artículo (Article)
La unidad básica de contenido en cualquier CMS, pero mas precisamente en Joomla, es el artículo. El artículo es el “content” que se trata de “managear”. Habitualmente un artículo consta de un texto adornado con diferentes estilos que engloban tablas, negritas, listas y todos los elementos habituales en HTML e incluyendo en ocasiones elementos multimedia como pueden ser fotos, o vídeos.
Categoría (Category)
Los artículos estar organizados en una estructura jerárquica de dos niveles. El primer nivel son las categorías, que sirven para clasificar de forma genérica los artículos, habitualmente dependiendo de su temática prevalente. Por ejemplo si tenemos una web de salud, podríamos montar categorías de “Médicos”, “Enfermedades”, “Medicamentos”, etc.
Dentro de cada categoría podemos tener…
Secciones (section)
Las secciones permiten agrupar los artículos para distribuir la visualización de los mismos por las diferentes áreas que presenta la plantilla. De este modo una opción de un menú nos puede llevar a una sección que nos presenta los artículos asignados a ella, o podemos tener un módulo que nos presenta dichos artículos de uno en uno, cada cierto tiempo, indicándole en la configuración (que se encontrará en el administrador) tan solo la categoría y sección que queremos usar.
Esta división entre categorías y secciones es una constante bastante extendida entre los desarrolladores de añadidos para el Joomla que suelen adoptar la misma organización jerárquica para sus unidades de información, sean estas fotografías, archivos, mapas, vídeos, mensajes o cualquier otra cosa.
Componente (Component)
Los componentes son las piezas funcionales básicas del Joomla. Cualquier funcionalidad de la que se quiera disponer tiene que venir en forma de componente. Por ejemplo si queremos poner un foro, una encuesta, un sistema de búsqueda, un repositorio de archivos, cualquier cosa menos la administración y mantenimiento de los artículos y los menus (o incluso eso mismo si queremos mejorarlo) hay que introducirla en forma de componente. Los componentes habitualmente constan de varios archivos php que conforman la funcionalidad básica del mismo, las opciones dentro del menú de administración del componente y los scripts de bases de datos que generan las tablas que necesita. Por fortuna el sistema de instalación de componentes de Joomla es muy bueno y el usuario no tiene que saber nada acerca de las interioridades del componente para poder instalarlo. Simplemente lo sube y lo usa.
Módulo (Module)
Los módulos son pequeños programas que crean una vista de determinados datos para ser insertada en la plantilla del CMS. Por ejemplo, si tengo un componente que es un calendario de eventos, puedo tener un módulo que me visualiza los eventos que están mas cercanos en el tiempo. Otro ejemplo son las encuestas, que tienen un componente para crearlas y administrarlas y luego un módulo para visualizarlas. Cualquier cosa que no sea un articulo o que no pueda ser mostrada como uno, necesitará un módulo.
Como norma general, un componente puede no tener módulos, pero un módulo siempre tendrá un componente que le provea de la información que necesita.
Plug-in
Los plug-ins, que antes se llamaban mambots como reminiscencia del precursor de Joomla, el Mambo, son unos añadidos que permiten tener funcionalidades añadidas dentro de los artículos. A veces mediante la inclusión de nuevos botones en el editor y otras, las mas, mediante el uso de marcas especiales (que van entre llaves) que son sustituidas en el transcurso de la renderizacion de la página por el contenido deseado.
Por ejemplo, si he instalado un componente que es una galería de fotos y quiero mostrar una foto aleatoria de la galería dentro de mi artículo, necesito un plug-in que me permita hacerlo, incluyendo un código como {imagenaleatoria idgaleria=20} que mostrará en ese lugar la imagen aleatoria.
Al igual que indicaba antes, un componente puede no tener ningún plug-in (por no necesitarlo o porque nadie se ha molestado en escribir el código aún), pero es bastante poco habitual encontrar un plug-in que no esté asociado a algún componente.
Plantilla (Template)
Todo el contenido que reside en Joomla se visualiza al cliente final mediante un sistema de plantillas relativamente sencillo. La plantilla define el aspecto de la página, ayudado por hojas de estilo CSS, y en su descripción reserva zonas o “areas” a las que se pone nombre, por ejemplo, si queremos reservar un lugar para la inclusion de un módulo en la parte superior de la página podemos usar el siguiente código:
<jdoc:include type="modules" name="top" />
Esta directiva hace que Joomla, a la hora de hacer render de la página, inserte en ese lugar el código HTML producido por el modulo que esté asignado al area “top”. Esa asignación se realiza desde el administrador de contenidos de Joomla.
Las plantillas por defecto de Joomla tienen unas 10 áreas para los diferentes módulos. En algunas áreas caben varios módulos y en otros solo uno.
Habitualmente lo mejor es elegir una plantilla ya hecha tal cual o modificarla a tu gusto. Hacerla de cero es un tema avanzado.
El ejemplo de como ha quedado lo que he hecho con Joomla se puede ver en la página de la Peña Ciclista Alpedrete y también en la web de LEVE, la liga de entrenamiento de ciclismo virtual.
Otro día presentaré las pautas para hacer un componente para Joomla.
Hoy aparecían reseñas en multitud de medios de comunicación, como El País, del nuevo juego para PSP que está a punto de sacar Sony España gracias a una nota de prensa que se ha distribuido sobre todo entre los medios dedicados a los videojuegos.
Es un hito mas de un largo camino que comenzó en 2001, cuando Dinamic Multimedia estaba a punto de suspender pagos y empezamos con las primeras pruebas en Flash 5 para hacer un juego de chapas. La idea fue tomando forma y, ya dentro de Zinkia, con el apoyo del director general que veía posibilidades en el producto, conseguimos hacerla tomar su forma final y publicar el WorldCapGame.
En 2006, la posición de Zinkia como empresa refutada de creación de contenidos hizo que Sony España confiase en ella para crear su primer producto propio. La idea de portar las “chapas” a la PSP les pareció muy buena y se comenzó su perfilación como producto.
Curiosamente las primeras etapas de preproducción a finales de 2006, contacto con Sony Europa para la aprobación de las características del juego y el inicio de la producción fueron uno de mis últimos cometidos en Zinkia, antes de abandonarla el pasado Octubre. Allí dejé la idea del juego, la adaptación de las reglas para hacerlo mas jugable, dinámico y divertido (que, contrariamente a lo que se dice en los medios de comunicación, no son tan parecidas a las de la federación de chapas, aunque si que se basaron en ellas), y dejé también el servidor multijugador, que desgraciadamente no se va a usar para la versión PSP debido a la escasa implantación del wifi en las PSP de los españoles, que es en principio el mercado objetivo de este nuevo título.
Espero que tenga mucho éxito comercial para que al menos me quede el orgullo de haber prendido la mecha, ya que los “técnicos” no tenemos ni el derecho de aparecer en los créditos .
Aunque aun no ha salido publicado (está en las últimas etapas de aprobación por parte de Sony Europa), a mi me gustaría ya ir dando las gracias a Tontolaba por esas primeras colisiones, Armengolo por terminar el WCG, vlopez por empujarlo cuesta arriba, Sego por la nueva cara del juego, Oscarchu por admitir el modelado de chapas y estadios como “trabajo interesante”, Raluy por hacer que se empezase a ver algo en la pantalla de la PSP y al equipo de desarrollo actual de Zinkia por retomar y llevar a buen fin lo que otros habían empezado, que es una de las tareas que mas esfuerzo supone y profesionalidad demuestra sobre todo en nuestro sector.
El nombre completo del juego, PlayChapas Football Edition, parece apuntar la idea de que va a haber otras “edition”, una de las cuales podría ser la edición de ciclismo que nunca llegó a cuajar en Zinkia. La idea está ahí, incluso tengo aún el documento inicial preliminar de reglas y características… ojalá sea ese el camino y haya mas hitos. Ya se verá.
Habrá gente que opine que sacar un juego de esta temática es una burla a la inteligencia de los jugadores… bueno, también pensarian eso del wii sports, y mira… ¡que el mercado juzgue!
Si alguno usáis este conocido software de diseño os habréis percatado de que cada cierto tiempo lanza un programa en segundo plano que se encarga de verificar si existen actualizaciones y se las descarga automáticamente.
Como esto es algo que no se puede desinstalar desde las propias herramientas de Adobe y como nadie me preguntó nada antes de instalarlo, lo he catalogado como software malintencionado (¿de que se esconde si no?) así que me he dispuesto a eliminarlo, pero no es tan sencillo.
Adobe usa el software “bonjour” de Apple para esta encomiable misión que se ejecuta en forma de servicio de windows. Para pararle los pies hay que desactivar el servicio y evitar que se vuelva a lanzar al reiniciar windows.
Existen unas pocas formas de hacerlo, explicadas todas perfectamente en este post de la web de kakkoi.
Hay que tener cuidado si usamos otros productos de Apple que puedan estar utilizando el Bonjour, como el iTunes o Quicktime, que no es mi caso. Si es el tuyo, utiliza un desinstalador llamado Revo Uninstaller y encuentra un programa cuyo nombre es “Adobe Version Cue CS3″. Ese es el que hay que quitar.
He hecho unas pruebas instalando un Fedora Core 8 en un Dell Optiplex 170L y después de comprobar una vez mas que para un aficionado es una completa pérdida de tiempo el tratar de configurarse un servidor completo en casa -lo que me ha llevado a mudar makinolo.com a un hosting- he querido volver a instalar el Windows XP que venía originalmente en la máquina.
Al introducir el CD en la unidad y arrancar, y tras indicarle que quería arrancar desde el CDROM, el programa de instalación de XP se quedaba colgado.
El problema era que el disco duro había sido formateado a ext3 para la instalación de Linux y el instalador de windows XP no lo reconocía.
Usando un viejo disco de Windows98 he procedido a la instalación y después de que esta formatease en FAT32, la aborté y comencé con la de XP.
Ahora si ha funcionado bien.
… y no, no pienso instalar Vista hasta que no me quede mas remedio.
La semana pasada finalizamos la 1ª edición de una rudimentaria liga española de rodillo de entrenamiento de bicicleta, usando el hardware de Tacx (Fortius e Imagic).
Gracias al esfuerzo coordinador y organizador de Santi Lerma hemos corrido 4 magníficas etapas que han servido para ver como es posible mejorar la forma con solo tener un aliciente tan tonto como el de medirse a una pandilla de tíos que no has visto en tu vida, ni siquiera durante la competición.
Una liga similar, pero mucho mejor montada (es de pago) lleva tiempo funcionando en virtualcycling.org
Al final nos hemos apuntado 23, cada uno con sus posibilidades y corriendo las etapas que ha podido, como ha podido.
El funcionamiento es sencillo: se elige un recorrido, bien de realidad virtual (VR), de Video (Real Life Video) o de Catalyst (en esta liga han sido todos de VR) y cada uno hace los intentos que puede en el periodo de tiempo estipulado y los envía al coordinador, que los valida según una serie de normas predefinidas. Una vez validadas, cada una de las carreras se pone a disposición de los demás para que compitan contra ella en modo diferido (shadow) o incluso para que la usen como “pacer” o “liebre”, con la posibilidad de meterse en su rebufo… si consigues seguirlo, claro .
Aunque el software tiene un modo multijugador en tiempo real, es mucho mas fácil en modo diferido, ya que cada uno encuentra el hueco para competir cuando puede y no es necesario quedar todos mismo día, misma hora. Como las etapas pueden ir desde los 15 minutos a los 50, es mejor tener libertad de elección de horario.
Es patente la diferencia que hay entre los ciclistas mas entrenados, los mediocres como yo y los que están empezando, pero no se trata tanto de ganar (que no hay premio) como de comprobar la capacidad de progreso que tiene el físico humano bajo unas sencillas pautas de incentivación. Comprobar como el cerebro humano es capaz de exprimir nuestro físico por el simple hecho de observar que un indicador numérico (el de los metros por detrás de ti que viene el contrario) va disminuyendo, es fascinante.
Si lo que ves es una representación en 3D del contrario a pocos metros por delante, y notas como flojea en la subida que acaba de acometer… el efecto es inmediato: ¡¡¡a muerte a por el!!!
Lo bueno es que cuando te ganan no se pasa mal, porque, al fin y al cabo… es solo un modelo en 3D
Menos mal que el aparato controla el pulso y te avisa cuando superas los límites, porque viéndome como termino de asfixiado cada etapa a veces me da por pensar si en una de estas alguno no se quedará tieso con las bielas puestas.
Mi puesto en la clasificación general es un poco engañoso. He quedado 6º porque los 3 siguientes han fallado en alguna etapa y yo las he completado todas, pero de todos modos se ve claramente que hay algunos que están en otra órbita.
Esta semana comienza la 2ª liga… a ver que tal y a ver si saco ganas para automatizar un poco el proceso de enviar las carreras, que parecemos tercermundistas.
Hace tiempo, en plena ebullición de Youtube y de Google Video, me topé con unos vídeos de mi deporte favorito, la bici de montaña, en los que con una cámara acoplada al casco, manillar o incluso el sillín, algunos descenders se grababan la ruta de descenso montaña abajo. En este post del foromtb se pueden encontrar enlaces a unos cuantos y en el blog de jelmetcam mucha mas información.
Por supuesto, debido a los rudimentarios montajes de sus cámaras, la grabación era como una gelatina royal, se movía tanto que era imposible distinguir nada en el recorrido y acababas mareandote… pero empecé a ver vídeos en los que aparecían bordes negros irregulares que cambiaban constantemente de posición mientras la imagen permanecía centrada y estable. Sin saberlo estaba viendo mi primer vídeo estabilizado por software.
Habitualmente, en la tele o el cine profesional se utilizan complejos aparatajes llamados “Steady-cam” o bien “dollies” para estabilizar la grabación de las imágenes. La estabilización de imagen que proporcionan las cámaras de video doméstica es de risa cuando se quieren usar con fines deportivos, sobre todo en terreno abrupto y bacheado como puede ser en el MTB o el esquí.
Mediante el uso de complejos algoritmos algunos genios de la programación han conseguido analizar los fotogramas de un vídeo y compararlos con sus adyacentes, anteriores y posteriores, “intuyendo” cual es el objeto que centra la mirada de la cámara. Esto se hace diferenciando el movimiento de la cámara del movimiento del objeto que estamos siguiendo y es algo tan simple a primera vista como que todo lo que se mueve en una dirección será debido al movimiento de la cámara y lo que se mueva en otra distinta sera el objeto a seguir.
Una vez se reconoce ese objeto, el software literalmente mueve, rota y hace zoom sobre el fotograma hasta que deja en el centro el objeto principal,
incluso si para ello es necesario dejar parte de la imagen fuera de vista y rellenar con bordes negros lo que se pierde de la imagen por el otro lado. De ahí los bordes negros de los primeros vídeos estabilizados por software que vi.
El software de todos modos permite eliminar esos antiestéticos bordes por varios medios, como haciendo zoom hasta llenar la pantalla, por ejemplo.
Algunos de los paquetes de edición de vídeo mas conocidos como After Effects, Combustion o Premiere tienen sus propios plugins que permiten este tipo de post-producción a nivel semi-profesional, pero para el ciudadano de a pie, que lo mas que tiene es el Windows Movie Maker o el VirtualDub, pues lo tiene un poco crudo, porque no hay nada gratis. El plugin para VirtualDub de DigiStudio, que es bastante antiguo por cierto, es Shareware, pero con una marca de agua igual que el SteadyHand de GooderVideo, del que se puede descargar una versión de prueba y que funciona de manera autónoma, pero tambien con una llamativa y molesta marca de agua.
De cualquier manera la estabilización por software, al menos de momento, no es una solución profesional. Para hacer visibles vídeos caseros o retocar pequeñas tomas nos vale, pero para poco mas, por eso el software disponible es escaso y antiguo.
Aquí tenéis un ejemplo de un vídeo grabado en la ruta del alto tajo la semana pasada.
A la izquierda sin estabilizar y a la derecha estabilizado:
Corté las estanterías por la mitad longitudinalmente y usé los nervios de acero de los extremos doblándolos a modo de ganchos, para que la estantería se pueda enganchar en un soporte de aluminio que también fabriqué para la ocasión y que va atornillado a la pared. 
.
de las imágenes. La estabilización de imagen que proporcionan las cámaras de video doméstica es de risa cuando se quieren usar con fines deportivos, sobre todo en terreno abrupto y bacheado como puede ser en el MTB o el esquí.
