inmensia

Hará cosa de un año que me bajé los fuentes de Chrome y los estuve compilando. Muchas novedades ha habido en el navegador desde entonces, así que me he decidido a bajarme los fuentes actualizados y volver a compilarlos. Y si bien la primera vez utilice la versión 2008 Express de Microsoft Visual C++, esta vez he optado por utilizar la 2010 Express.

Esta es la secuencia de pasos que he seguido utilizando Windows 7 Ultimate 64 bits:

Instalación

1) Instalar Microsoft Visual C++ 2010 Express

2) Instalar Microsoft Windows SDK for Windows 7 and Framework .NET 4

3) Instalar Microsoft Visual Studio 2010 Service Pack 1

4) Instalar Microsoft Visual C++ 2010 SP1 Compiler Update for the Windows SDK 7.1

5) Instalar Microsoft Windows Driver Kit Version 7.1.0 en un directorio <DDK>

6) Instalar Microsoft DirectX SDK en un directorio <SDX>

7) Dar permiso de modificación y sustituir "v7.0A" por "v7.1" en los ficheros:

    C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\PlatformToolsets\v100\
Microsoft.Cpp.Win32.v100.props

    C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\x64\PlatformToolsets\v100\
Microsoft.Cpp.x64.v100.props

Configuración

8) Descargar depot_tools y descomprimir el .zip en un directorio <depot_tools>

9) Descargar chromium_tarball y descomprimir el .tar en un directorio <sources>

10) Añadir el directorio <depot_tools> al PATH del sistema

11) Ejecutar por primera vez las depot tools para actualizarlas:
    <depot_tools>\glclient

12) Editar el fichero <sources>\.glclient y añadir la url de una rama probada de los fuentes:
    "safesync_url" : "http://chromium-status.appspot.com/lkgr"

13) Actualizar los fuentes:
    <sources>\glclient sync

14) Crear la solución y los proyectos para Visual Studio 2010 Express:
    <sources>\set GYP_MSVS_VERSION=2010e
    <sources>\gclient runhooks

Compilación

15) Abrir solución de Visual Studio (ignorar mensaje de advertencia sobre properties):
    <sources>\chrome\chome.sln

16) Configurar el proyecto "chrome" como inicial

17) Añadir las siguientes rutas al principio de la lista de directorios de includes (Win32 y x64):
    <SDX>\Include

18) Añadir las siguientes rutas al final de la lista de directorios de includes (Win32 y x64):
    <DDK>\inc\atl71
    <DDK>\inc\mfc42

19) Añadir las siguientes rutas al principio de la lista de directorios de libs:
    Win32: <SDX>\Lib\x86
    x64: <SDX>\Lib\x64

20) Añadir las siguientes rutas al final de la lista de directorios de libs:
    Win32: <DDK>\lib\ATL\i386
    x64: <DDK>\lib\ATL\amd64

21) Lanzar el build sobre el proyecto "chrome"

El tiempo total en mi máquina para una compilación sólo del navegador Chrome para Win32 Debug sin los tests es de unos 40 minutos, lo que está bastante bien teniendo en cuenta la cantidad de proyectos y dependencias.

El orden de instalación que he puesto difiere un tanto de las instrucciones oficiales, pero es la mejor forma que he encontrado para evitar los errores con los que me he ido topando al instalar los distintos productos de Microsoft que necesitaba. La lista de pasos ahora la tengo clara, pero como de costumbre ha sido todo un proceso de prueba y error. Al final opté por bajarme las .ISO de cada instalación en vez de utilizar los instaladores webs, porque esperar por cada descarga cada vez era muy tedioso.

Con respecto a la instalación en particular del compilador, comentar que finalmente tuve que instalar primero el Visual C++, luego el SDK de Windows, luego el Service Pack 1 del Visual C++ y por último un parche para arreglarlo todo, aunque aún así es necesario modificar dos ficheros de manera manual, ya que se empeña en tomar la versión 7.0A del SDK de Windows en vez la más actualizada 7.1.

Finalmente, puede que sorprenda que haya tenido que instalar el SDK de DirectX, ya que este último pasó a formar parte del SDK de Windows hace tiempo, pero es necesario porque los fuentes de Chrome utilizan D3DX, que sólo está incluida en el SDK de DirectX. De igual forma, es necesario instalar el DDK porque la versión Express de Visual C++ no trae los includes y librería de ATL.

¡Feliz compilación a todos!

PlayN es una librería multiplataforma de Google para desarrollar juegos. El nombre viene de "... for N>=4 platforms", aunque a día de hoy más bien es "N>=3", ya que sólo compila para Java, HTML5 y Android. La cuarta plataforma que faltaría es Flash, que está desarrollada, pero actualmente no funciona.

En la Google I/O del año pasado la presentaron con el nombre de "ForPlay":

Con el nuevo nombre de la librería hicieron hace poco una nueva presentación, entrando más en detalle con un ejemplo más concreto explicando como portaron "Angry Birds" a HTML5. No está colgada en YouTube, pero el vídeo y las diapositivas se pueden ver (no muy bien) en Angry Birds on HTML5. Para los que tengan curiosidad, el juego está online y se puede jugar en http://chrome.angrybirds.com/.

Respecto a la librería, comentar que está montada sobre GWT, por lo que el código se escribe en Java. Y a través de Eclipse, con los plugins correspondientes, se genera el código para la plataforma destino preferida. Ofrece una abstracción del bucle principal habitual de un juego, leyendo la entrada del usuario, actualizando el mundo y renderizándolo. Además de dar soporte para los componentes básicos, como gráficos, sonidos, red, física (Box2D embebido), gestión de recursos, ...

El proyecto está en desarrollo todavía, es ambicioso, y GWT no ha acabado de terminar de cuajar entre el gran público. En cualquier caso la idea no es mala. Pero es lo de siempre, un mismo código que pueda ejecutarse en todas partes.

Un poco de humor para empezar el año.

Fuente: Farid Jamali

Buscando información acerca de métodos de tracking (seguimiento) de objetos en tiempo real, me he encontrado que hay toda una teoría desarrollada para la detección de regiones dentro de una imagen que parezcan corresponder a piel humana. Hay muchas técnicas, pero las más sencillas parecen ser curiosamente las que mejor funcionan. Y básicamente consisten en convertir los pixeles originales desde RGB a otro espacio donde sea más fácil estudiarlos.

Al final he acabado montado mi pequeño "laboratorio" en JavaScript para comprobar una de estas teorías, concretamente la explicada en este paper que realiza el estudio de los pixels en el espacio de color YCbCr. Para ello he escrito un conversor de RGB a YCbCr utilizando las siguientes fórmulas propuestas en el documento:

Las fórmulas admiten un valor RGB dentro del rango [0, 1] y generan su equivalente YCbCr en el rango [0, 255]. La idea clave es que dentro de dicho espacio el color correspondiente a la piel humana se encuentra dentro del rango [80, 120] para la componente Cb y [133, 173] para la componente Cr. La componente Y simplemente es ignorada. ¡Veamos si es cierto!

Al seleccionar una imagen del desplegable de abajo se muestra tal cual arriba a la izquierda. En los cuadros inferiores se dibujan los histogramas calculados para las componentes Cb (en azul) y Cr (en rojo). Las zonas destacadas en amarillo son los rangos que se corresponden teóricamente a la piel humana. Y la imagen superior derecha es el resultado de filtrar la imagen original dejando pasar sólo los pixels que se encuentran dentro de los rangos que corresponden a la piel humana.

Después de probar con una serie de imágenes he dejado tres fotografías de caras a modo de referencia. La de Lucy Liu corresponde a un caso bastante claro donde está bastante diferenciado del fondo y el algoritmo hace un buen trabajo. La de Nicole Kidman se complica un poco, ya que el pelo tiene una tonalidad tan clara que no se distingue de la piel. Y por último la de Whoopi Goldberg, que se corresponde al caso en que el algoritmo se confunde debido al color que tiene la ropa que lleva puesta.

El programa permite cambiar los rangos haciendo click sobre los histogramas para desplazar los valores mínimos y máximos. Por ejemplo, para la foto de Whoopi, si se aumenta un poco el mínimo del histograma de la componente Cb (azul) entonces el algoritmo ya no detecta la ropa como piel. De igual forma, jugando un poco con los rangos es posible eliminar la mayor parte del pelo de la foto de la Kidman. Reconozco que el control con el ratón es un poco complicado, la idea es que se modifica el límite más cercano a donde se hace el click.

Otra posibilidad que ofrece el programa es seleccionar una región dentro de la imagen original para ver los histogramas de esa región en concreto. Por defecto está seleccionada la imagen entera, pero haciendo click sobre ella se puede definir una región rectangular. La idea es poder ver como se distribuyen los valores para una región en concreto con más detalle para tener un mejor criterio a la hora de modificar los rangos. Lo ideal es seleccionar una región que incluya sólo piel, con brillos y sombras, y ajustar los mínimos y máximos de los histogramas obtenidos. Pulsando escape se restaura la composición original.

Resumiendo un poco, está claro que el criterio es válido en términos generales, pero hay mucha probabilidad de falsos positivos en función de la condiciones del entorno en que se pruebe. Los pixels aislados no representan un problema, ya que normalmente se eliminarán aplicando una operación morfológica del tipo erode. Y de igual forma los huecos se rellenarán con una operación dilate.

Para mejorar el proceso de detección en general hay que aplicar más criterios, y así lo hacen generalmente las técnicas propuestas, normalmente el estudio de la imagen en algún espacio de color, como el YCbCr o el HSV por ejemplo, es sólo la primera parte del proceso. Algunas técnicas más elaboradas utilizan una imagen de referencia, a modo de calibración del sistema, con la que se construyen unos umbrales de referencia. Otros sistemas, sobre todo cuando se trata de procesar vídeo en vez de imágenes estáticas, ajustan los umbrales del los histogramas de forma dinámica en función de la variación que se va produciendo en las imágenes que se van sucediendo.

En otro orden de cosas, buscando más información por la red, he encontrado fórmulas de conversión de RGB a YCbCr más sencillas que las propuestas en el paper. Por ejemplo las siguientes:

Estas fórmulas tienen además la ventaja de que los valores de entrada RGB están dentro del rango [0, 255] en vez de [0, 1].

Más alternativas a la creación de contenido para la web. A ver, un repaso rápido a lo más popular que tenemos ahora mismo. Por una parte está el omnipresente Flash, que se resiste a morir, sobre todo porque Google no hizo nada para matarlo en su día, aunque Adobe ahora está reculando un poco y prefiere que la gente empiece a utilizar su plataforma AIR. Por otra parte está HTML5, aunque hoy en día es complicado hacerse un desarrollo entero en JavaScript, poder se puede, pero faltan las herramientas adecuadas para hacerlo de una forma productiva, además de otras lagunas en los navegadores que tardarán un tiempo en cubrirse. IMHO, Flash hoy en día le gana a HTML5 por goleada.

Mención aparte para Unity3D, que a pesar de ser un plugin siempre ha sido bien visto por la comunidad. Y de Silverlight mejor no hablamos, aunque posiblemente deberíamos estar hablando más de él. Y por último X3D, el sucesor de VRML, que parece que va a acabar siguiendo su mismo camino de estándar caído en el olvido.

Y los experimentos de conversión de Flash a HTML5 por ahora son sólo eso, experimentos.

Native Client (NaCl) es una tecnología que implementa Chrome y que viene a ser una "sandbox" donde se permite ejecutar código nativo no seguro. El navegador ejecuta el código capturando las llamadas que interactuan con el sistema evitando que se ejecute código potencialmente malicioso. Y todo ello con sólo una pérdida de rendimiento estimada del 5% según los técnicos de Google.

Esta semana esta tecnología ha cobrado un poco de relevancia por la publicación en la Chrome Web Store de Bastion, un juego RPG muy popular. Lo he estado probando, unos diez minutos o así, y la verdad es que funciona bastante bien. Me ha sorprendido muy gratamente.

Recuerdo haber estado leyendo documentación sobre Native Client hace unos meses y me gustó por el enfoque que le estaban aplicando. Concretamente porque estaban migrando algunas librerías como la popular SDL. No trataban tanto de vender su producto, sino más bien de conseguir que fuera útil. Hasta entonces sólo me parecía un plugin más, como ActiveX, pero cuando vi ese movimiento me gustó bastante. Hay muchos desarrollos antiguos, o actuales, que podrían cobrar una nueva vida gracias a eso.

La filosofía es un poco como la de Java, un sólo código que se ejecuta en todas partes. Lo bueno es que el código en este caso puede estar escrito en C o C++, por lo que se puede reaprovechar todo lo que se tiene actualmente. Por ejemplo, recuerdo haber visto hace un tiempo un port del popular emulador DOSBox a NaCl, lo que automáticamente permitía ejecutar todas nuestras queridas viejas aplicaciones directamente en el navegador. Una locura.