Varios años después y con bastante más experiencia pude conseguir un Home Assistant Yellow, basado también en hardware de Raspberry Pi pero que prometía ofrecer la mejor experiencia por un precio reducido, a la vez que ayudaba directamente a mantener el proyecto libre para todos, ya que era diseñado y distribuido por la misma Nabu Casa, empresa creada a partir de Home Assistant, y lo he estado usando desde entonces sin mayores problemas. Es estable, eficiente y, por lo general, se puede decir que simplemente funciona, así que ha sido una buena inversión.

El hardware es correcto pero nada demasiado potente, el corazón del sistema es un Compute Module 4, que es básicamente una Raspberry Pi 4B+ pero sin puertos y con memoria eMMC incluida (dato no menor), que es como una tarjeta MicroSD que viene soldada de fábrica en la propia placa, sólo que un poco más confiable y, a veces, rápida. Es, además, más que adecuado para el uso que le doy en el día a día a mi instancia de HA: un par de decenas de sensores por aquí, unos cuantos focos por allá, algunas automatizaciones y poco más, es raro ver que el uso de mi CM4 supere el 10% de su capacidad en cuanto a CPU.
Como dije, ha estado trabajando bastante bien durante los últimos dos años, así que poca queja.

Sin embargo, hace unos días tuve la oportunidad de conseguir un Compute Module 5 al precio sugerido por la propia Raspberry Pi y no pude resistir las ganas de comprarlo. Lo único malo es que comprar un módulo con el chip eMMC incluido se me iba un poco de presupuesto, así que realicé una búsqueda rápida en Google para ver si aún así funcionaría bien en mi Yellow y todo parecía ser buenas noticias, así que procedí.

Los dos módulos tienen el mismo footprint físico, así que, en teoría, este debería ser un reemplazo de quitar y poner. En teoría.

Hice un backup de configuración y otro de sistema por si acaso y los transferí a una computadora externa. Todo estaba listo para el upgrade.

Primer obstáculo: El CM5 no me vino con thermal pads, así que al retirar el CM4 tuve que reemplazar el pad del procesador por un poco de pasta térmica que compré hace años para cuando tenga que realizar ensamblajes más tradicionales de computadoras de escritorio.

Una vez realizado el cambio de hardware, simplemente volví a conectar el Yellow re ensamblado a la red y esperé verlo revivir después de un par de minutos.

5 minutos después sabía que había cometido alguna torpeza.

Resulta, según algunos foros y la guía oficial de actualización de CM4 a CM5 de Home Assistant Yellow que el CM5 tiene una secuencia de inicio un poco distinta a la del modelo anterior; además, y como mencioné líneas arriba, es de vital importancia que el CM5 no posea un chip eMMC. No estoy 100% seguro de no haber usado nunca ese chip en el caso del CM4 cuando armé por primera vez mi Yellow, pero aún habiéndolo querido evitar es posible que el módulo esté configurado para sí o sí usar esa memoria interna para almacenar algunas cosas, memoria que no estaría presente en el nuevo módulo.

Felizmente tenía la guía y los backups. La idea era usar el disco NVMe como única fuente de almacenamiento, para eso había que borrar absolutamente todo lo que había ahí con anterioridad, instalar Home Assistant OS nuevamente y luego hacer una restauración a partir de las copias de respaldo que había obtenido minutos atrás.

Obviamente, es una simplificación ligeramente obscena del proceso que tuve que llevar a cabo, pero los detalles se explican bastante mejor en la guía enlazada un par de párrafos arriba.

No fue tan fácil, tuve que buscar entre mis cachivaches una fuente de alimentación de 12V para poder encender el Yellow e instalar lo necesario mientras lo tenía conectado a mi computadora de escritorio, en donde tenía los backups y también un par de herramientas (mencionadas en la guía) vitales para el proceso. Lamentablemente, no tengo acceso a un cable Ethernet con capacidad PoE en mi escritorio.

Ahora que lo pienso, hubiera sido más fácil usar una laptop y llevarla hacia donde normalmente reside mi Yellow, así no hubiera tenido que buscar una fuente alternativa de alimentación.
Menos mal este artículo no se trata de mi capacidad intelectual en momentos oportunos.

Home Assistant tiene un asistente de restauración de copias de seguridad bastante simple pero amigable, así que no fue nada difícil restablecer el sistema tal cual como lo dejé antes de la actualización.
Hubo un par de cositas por corregir, como el coordinador Bluetooth que, al parecer, había cambiado de dirección MAC y algo bastante similar con el coordinador Zigbee, así que ni mi sensor de temperatura ni mis Philips Hue funcionaron apenas terminado el proceso, pero la solución fue bastante simple: en el caso del Bluetooth, el “nuevo” coordinador estaba listo para ser adoptado, sólo lo acepté y eliminé el anterior, nada más que hacer; en el caso de la antena Zigbee, más de lo mismo, aceptar el nuevo ID y dejar que los handshakes necesarios se realicen por sí mismos.

Ya, pero ¿eres o no eres… mejor que el CM4?

Sí, sí, claro que lo es. También es claro que no era necesario hacer el cambio, pero como entusiasta de este tipo de trivialidades, juguete nuevo es juguete nuevo.

Hice unas pequeñas pruebas tanto en el CM4 como en el CM5 para ver qué tan más rápido era el nuevo modelo:

CM4:

CM5:

No son las pruebas más adecuadas científicamente hablando pero ver mejoras de hasta casi el 69% (nice) en tareas del día a día es bastante significativo.

Obviamente, todo ese poder no es gratuito y la capacidad extra de procesamiento se tiene que pagar de alguna manera.
No me preocupé de tomar muestras del comportamiento térmico de los dos distintos módulos pero asumiré que es relativamente similar, aunque es cierto que el Yellow se siente un poquito más toasty al contacto, aunque nada preocupante. La temperatura promedio del CM5 con el uso que le doy a diario empleando el disipador de fábrica es de aproximadamente 69 °C, no extremadamente saludable pero nada demasiado preocupante tampoco. Quizás si consigo un thermal pad adecuado el disipador pueda hacer un mejor contacto y reducir un poco esa temperatura, pero por ahora es un número decente.

De lo que sí me preocupé fue del consumo energético. Con la ayuda de mi USW-24-PoE pude verificar que, efectivamente, la quinta versión del módulo consume más energía que la cuarta, nada sorpresivo, pero nada como tener los datos en la mano:

Como se ve en los gráficos, la diferencia promedio en consumo es de 1W después de la actualización. ¿es eso mucho o poco? Bueno, para tener una idea un poco más clara, es más o menos lo que un teléfono inteligente moderno usa mientras se navega por la web, o, de nuevo más o menos, lo que consume la linterna de dicho teléfono al máximo.

Quizás en términos monetarios se entienda un poco mejor: el mayor consumo del CM5 frente al CM4 representaría al año, teniendo en cuenta el precio actual de la electricidad en mi ciudad, un gasto de aproximadamente un dólar y medio más. O sea, casi nada.

Es una pena que Home Assistant haya descontinuado el, en mi opinión, mejor producto que pusieron en el mercado en todos estos años, aunque confío firmemente en su compromiso de seguir ofreciendo soporte para él. Si bien ahora existe Green, que parece bastante bueno también, creo que la capacidad, flexibilidad y características de Yellow lo hacen claramente superior aunque un poco más costoso.

Si tienen la oportunidad de conseguir un Yellow, incluso de segunda mano, no podría yo recomendar más su compra, más aún si lo van a emparejar con una pequeña bestia como el CM5. Esa cajita tendrá todo lo que necesitan de un sistema de domótica por los siguientes 5 años como mínimo.
Si un módulo de 75 dólares es muy caro, incluso con un CM4 de unos 50 dólares se puede tener una experiencia más que decente.

Ah, y Happy International Pi Day. 😀

Mi primera idea fue que había cometido algún error al momento de configurar WLED, aunque me pareció un poco raro porque no era la primera instalación del estilo que hacía, aún así me metí a los foros y encontré que el flickering en WLED (y con varios otros software de controlador para LEDs) es bastante común si no se tiene en cuenta ciertas cosas al momento de hacer las conexiones eléctricas entre el controlador y las luces.
Cosas como el voltaje al que funcionan los LEDs, la longitud de los cables, si los mismos están acompañados o no por otros cables, qué tipo de señal llevan los cables que acompañan y varias otras cosas pueden afectar el funcionamiento de una instalación.

Por supuesto, yo no había tenido en cuenta ninguna de estas cosas, así que sí era un error de configuración de mi lado, y me puse a mejorar todos los aspectos de mi proyecto que podrían contribuir a un funcionamiento más estable.

El diagrama eléctrico inicial era más o menos así:

Y ya, sólo eso. Nada de resistencias, condensadores o diodos. Ninguna forma de compensar los cerca de 10 metros de cable que habría entre el controlador (un NodeMCU ESP8266 en este caso), eso sin tener en cuenta que los cables durante una parte no despreciable de su recorrido están acompañados muy de cerca de varios otros que llevan señales como Ethernet y HDMI y durante otra parte, menos despreciable aún, lo están de cables de flujo eléctrico alterno a 220V y 60Hz, lo cual casi definitivamente estaba causando algún tipo de crosstalk, o sea que las señales se contaminaban unas a otras.
Me parece que la señal que envía el pequeño microcontrolador iba a pasar un mal momento realmente.

¿por qué no cambiar el cableado? Bueno, no es mala idea, pero la configuración eléctrica actual de la habitación en donde desplegué estas lámparas hace complicado llevarla a cabo. Además, me interesa ocultar los cables tanto como se pueda y eso significa en muchos casos utilizar tuberías dentro de las paredes que, en un principio, sólo tenían como tarea servir como canal para cables de alta tensión (bueno, alta con respecto a los voltajes que requiere el proyecto en cuestión, ustedes entienden).

Además, aún sin tanto cable al lado, pretender que una señal de varios megahercios y 3.3V (el voltaje al que funcionan las terminales del microcontrolador) mantenga su integridad a través de un cable de 20AWG y sin protección a lo largo de más de 10 metros es, como mínimo, iluso y como máximo mejor no lo digo.

El tercermundismo contraataca

La solución más a la mano parecía ser conseguir algún controlador ya construido para sólo conectarle los cables necesarios y disfrutar. De hecho, hay varios proyectos que apuntan precisamente a eso, algunas personas han dedicado su tiempo a diseñar circuitos plug and play para WLED para los que no tenemos demasiada idea de cómo conectar bien un par de LEDs. Seguramente el más notable sea QuinLED, que tiene varios productos interesantes pero, como de costumbre, una de dos opciones: el envío hacia este rincón olvidado del mundo es inexistente o cuesta el triple de lo que cuesta el producto.

Además, eso no es divertido.

Una vez más, tenía que hacerlo yo mismo, bien punk.

Fine, I’ll do it myself

Junté algunas resistencias, condensadores, elevadores lógicos de voltaje y otras cositas que tenía por ahí en la mesa como cualquier persona y volví a armar el circuito.

En el mundo real se veía más o menos así:

Siempre me causó gran curiosidad qué causaba esos destellos y cómo se verían reflejados en una gráfica de la señal. Era momento de sacar las armas pesadas.

Con ayuda de un RIGOL DHO804 me puse a husmear en las señales que enviaba el microcontrolador, o las que recibían las tiras LED 10 metros más allá, mejor dicho.

Para ser justos, ninguna de las dos es una señal perfectamente cuadrada, tampoco están particularmente cerca de serlo, aunque creo que sí es apreciable la reducción de ringing en el circuito no tan básico, pero lo más importante, por lo menos a simple vista, es que en el segundo circuito la señal alcanza picos de voltage más altos, producto de usar un elevador lógico de voltage como el SN74AHCT125N de Texas Instruments, lo cual permite que viaje por más distancia manteniendo un poco mejor su integridad.

Las mediciones en los circuitos mismos (es decir, sin tomar en cuenta la longitud del cable que lleva la señal) son bastante más parecidas en cuanto ringing. Y es de esperar, la verdadera diferencia debería ser aparente una vez la señal haya recorrido que generaba el problema en primer lugar.

“But first, a word from today’s sponsor, JLCPCB”

Comprobado el funcionamiento del nuevo circuito, era hora de mejorar la implementación. No podía dejar esa maraña de cables ahí. Incluso si pudiera ponerlo dentro de una caja para un mejor resultado estético, internamente no sería muy confiable, los cables DuPont y los breadboards son excelentes para la fase de prototipado pero no para una solución a largo plazo, aunque muchas veces lo temporal se vuelve permanente, lamentablemente.

Pensé en usar una placa universal y soldar ahí los componentes necesarios pero parecía una idea un tanto incompleta. Incompleta porque es un paso intermedio entre un breadboard y un circuito impreso, como los que se encuentran normalmente dentro de los aparatos electrónicos estos días. No me sentía muy cómodo sabiendo que se vería, en mi opinión, tan poco profesional. No es que yo suela solucionar mis problemas electrónicos de la forma más profesional posible pero también es cierto que si ya iba a ponerme a soldar componentes en una placa, no veía un gran motivo por el cual no poner todas las fichas en el proyecto y diseñar un circuito integrado yo mismo.
Bueno, ese fue el razonamiento inicial, resulta que el gran motivo era la considerable inversión de tiempo necesaria para poder diseñar un PCB, silly me.

Hace un buen tiempo que quería aprender a hacer este tipo de cositas, siempre creí que era muy complicado pero esta era la oportunidad ideal, era un circuito bastante simple, yo tenía algo de tiempo para disponer y, bueno, tenía ganas.
Un par de posts de Reddit después llegué a EasyEDA, me gustó que era lo suficientemente simple de usar para un novato como yo y, también, su integración con JLCPCB. Más sobre esto último un poco más abajo.

Luego de un poco (un montón, en realidad) de prueba y error, llegué a esto:

Como decía píxeles más arriba, algo que me gustó mucho de EasyEDA fue su integración con JLCPCB. Yo sólo conocía a esta compañía debido a la constante publicidad que hacen en canales de YouTube de tecnología y electrónica que suelo seguir (junto con PCBWay, las dos más conocidas en este rubro gracias a sus prominentes campañas de mercadotecnia), pero no tenía idea de que era un distribuidor de componentes electrónicos también. Bueno, no ellos, si no su empresa hermana LCSC.

La ventaja es que, al momento de diseñar tanto el esquema como el circuito en sí, se puede buscar componentes en su catálogo y usarlos sin tener que definir características manualmente, ahorrando así un montón de tiempo. Sirve mucho, además, para obtener los planos 2D y los modelos 3D de las partes involucradas, es un verdadero golazo.

Hubiera sido muy difícil para mí generar el modelo en 3D de todo el circuito terminado. Me siento cómodo haciendo algunas cosas en 3D pero no a ese nivel ni con ese nivel de precisión.

JLCPCB, claramente, no sólo vende piecitas electrónicas, también se dedica a lo que me interesaba en ese momento, la fabricación de circuitos impresos. Gracias, nuevamente, a la integración con EasyEDA (es su programa de asistencia de diseño de PCBs después de todo), una vez terminado mi diseño pude simplemente subirlo a sus servidores y obtener una cotización en un par de minutos. Los precios para la fabricación de un circuito básico de dos capas como este son bastante asequibles, el problema, como de costumbre suele ser el envío.

Para un mejor detalle, este es el desglose del total que tuve que pagar para tener mis ansiadas placas finalmente en mis manos:

Un poco más de 6 dólares por 10 placas, aunque pequeñas y básicas, me parece un gran precio. Como dije, el problema es el envío. No quería estar esperando 3 meses para finalizar el proyecto ni tratar con el servicio nacional de correos de este país, lo cual le hubiera agregado cantidades industriales de incertidumbre a la ecuación, así que opté por FedEx. Quizás no sea el envío más cómodo del mundo, sobre todo si se hace desde China, pero con un cupón de descuento por ser la primera vez que uso el servicio creo que llegué a un precio con el que me sentía relativamente bien, así que el precio final fue de unos 25 dólares. Nada asombroso pero pudo haber sido mucho peor.

Electronic components, assemble!

El color azul parecía apropiado. 😺

El PCB negro no es realmente uno, es una maqueta impresa en 3D para propósitos demostrativos y como reemplazo de los verdaderos mientras llegaban, sobre todo para el siguiente paso: una caja para el circuito. Era lo más lógico para cuando ya estuviera todo casi listo, no quisiera que la habitación tenga circuitos expuestos que, además de ponerlos en cierto riesgo, desentonan con el resto de la decoración. Felizmente, en Fusion 360 no es muy complicado diseñar algo medianamente decente para poder imprimir luego.

Con ayuda del PCB falso podía validar si las tolerancias de mi diseño eran apropiadas. Menos mal no tuve que hacer demasiadas modificaciones una vez listo el modelo final, salvo los agujeros en la tapa en donde van los tornillos.
La idea es la siguiente: la tapa se imprime “boca arriba” para evitar usar innumerables soportes en toda su extensión, ya que no es uniforme por la parte baja, mientras que sí lo es por arriba. El problema con eso es que, al tener un tope los agujeros para los tornillos, son estos topes los que necesitarían soportes para no ser impresos, literalmente, en el aire. A este tipo de agujeros se les conoce en inglés como counterbores y en español se le conoce como avellanado al proceso de creación del tope para que los tornillos queden al ras de la superficie.

Normalmente son agujeros fáciles de hacer con otro tipo de procesos de fabricación, pero no siempre es así con la impresión aditiva, menos aún si se imprime al revés, así que hay que encontrar alternativas.

Hasta ahí todo bien, pero yo no quería imprimir soportes, ya que demora un poco más y sentía que alguna manera de hacerlo de forma “limpia” debía existir.

Tras mucha prueba y error, encontré en el canal Maker’s Muse una técnica para imprimir este tipo orificios llamada sequential bridging, aparentemente inventada por nophead como consta en su blog.

Básicamente, la estrategia consta en no dejar que la máquina imprima círculos enteros sin un punto de apoyo, si no en cubrir el mismo espacio en pasos, dos o tres, con cuerdas que tienen puntos de apoyo al inicio y al final y atraviesan distancias cortas, lo cual los vuelve fácilmente imprimibles.

Y así luce un tornillo al ras de la superficie superior de la tapa. El método funciona.

* * *

Volviendo al circuito, ahora sí tenía todo listo para soldar y ensamblar.

Una vez todos los componentes estuvieron en su respectivo lugar, utilicé silicona caliente para fijarlos temporalmente, así sería más fácil poder soldarlos por la parte posterior. Como nota, no aplicar tanta silicona como se ve en la fotografía, luego es un poco difícil quitarla, así que mejor mientras menos se haya aplicado. Fuera de eso parece una alternativa decente, sobre todo si se trabaja en solitario.

Después de un buen rato soldando, este fue el resultado:

Ahora sí puedo morir en paz. Para ser sincero, aún hay, muy ocasionalmente, algunos destellos por aquí y por allá, pero estoy convencido de que la causa es el compresor de aire del mini refrigerador que está en esta habitación. Por ahora lo voy a dejar así, no es algo que sea molesto, pero quizás deba empezar a pensar en una suerte de supresor de picos para ese electrodoméstico.

Lo importante, sin embargo, es que funciona, que aprendí muchas cosas en el camino y que me divertí.

Ahora hasta funciona de forma sincronizada con las luces estilo Ambilight del televisor. Quizás algún día escriba sobre mi setup televisivo luminoso.

La excusa

Hace unos meses quería cambiar unas lámparas de iluminación indirecta que yo mismo había armado con un par de LEDs y unos tubos de cartón, quería que fueran un poco más flexibles en cuanto a los colores que podían mostrar; aparte, quería que fueran un poco más elegantes dentro de lo posible, digamos que el cartón no es el material más noble.
Por algún motivo, ni siquiera me molesté en buscar alternativas comerciales disponibles, supuse desde el principio que mi situación era un poco específica.

Para que la idea quede un poco más clara, necesitaba un par de cosas de estas lámparas:

• Que se vean “bien” y “elegantes”, lo cual es determinado principalmente por mi cuestionable sentido del gusto y de la clase.
• Que puedan ser fabricadas, en su totalidad, en casa.
• Que alumbren con luz de colores, no únicamente blanca.
• Que estén diseñadas para ser pegadas a una superficie, asegurarlas con tornillos estaría bien como opción pero necesito adherirlas.
• Que sean compatibles con WLED, que es un webserver de control de LEDs NeoPixel, no necesariamente una nueva tecnología de televisores.

La primera versión, la que está entrando en jubilación, sólo cumplía, en su totalidad, con los requerimientos 2 y 4 y con el primero de forma peligrosamente parcial; además, había escogido LEDs demasiado potentes para este uso y el calor generado por ellos había derretido un poco los soportes impresos que los sostenían. Era tiempo de una renovación.

Fue fácil decidir que serían lámparas impresas tridimensionalmente, al fin y al cabo creí que podía diseñar unas piezas de baja complejidad sin demasiados problemas y que en unos días el proyecto podría estar terminado. Creo que no estaba particularmente cerca de tener razón.

Con la ayuda de Blender —cuyo uso no recomiendo mucho para piezas mecánicas o del ámbito de la ingeniería, para eso mejor algo como Fusion— llegué a un diseño con el que estaba conforme. Si todo salía bien el diseño permitiría el cumplimiento de todos los requisitos.

La idea es simple, es un conjunto de cuatro piezas:

• La parte de color naranja es la principal, una de las que van ancladas a una pared o columna y ofrece algunas opciones de manejo de cableado pero, sobretodo, soporte para dos segmentos cortos de tiras LED; 7 módulos LED WS2812B por lado con una separación de 1 cm, más o menos.
• La parte de color morado es la pantalla, la cual impide el paso de la luz hacia el frente y los lados.
• Las partes superior e inferior de color verde son los los difusores, que se encargan de suavizar la luz emitida por las tiras al ser impresos en filamento transparente.
• Las partes azules son una representación de las tiras LED con fines estéticos.

Con todo listo copié los archivos a una tarjeta MicroSD que puse en mi queridísima y veterana Ender 3 para imprimir la pantalla. 12 horas y media era lo que demoraría la pieza en estar lista y lo que demoraría yo también en saber si finalmente mi diseño servía para algo, así que la dejé imprimiendo y me fui a la cama.

La mañana siguiente (sí, aparentemente duermo 12 horas) no iba a ser la más grata de mi vida, lamentablemente. Lo que encontré fue algo tristemente muy similar a esto:

Después de todas las obvias preguntas que me hice al ver semejante abominación en la impresora, ninguna con una obvia respuesta en ese momento, hice varios intentos más cambiando casi todo lo que se puede cambiar en este tipo de procesos. Cambié la configuración del slicer que usaba (Cura), nada; cambié de slicer, nada; recalibré la impresora, nada; usé un filamento diferente, nada.
No importaba qué ni cuánto lo cambiara, la impresión resultaba igual o peor que en la fotografía anterior.

La Ender 3 me ha acompañado bastante bien y me ha ayudado mucho a aprender sobre la impresión en 3D, es una máquina de potencial bastante decente por el precio, pero claro, el potencial no siempre se traduce en realidad. Tiene problemas de confiabilidad y hay que estar muy atento a todas sus necesidades antes de que pueda ser un artefacto de simplemente prender y usar. Requiere una cantidad de trabajo no menor.
Sin embargo, su enorme popularidad no miente, era, en sus buenos años, la impresora para comenzar.

Aún teniendo en cuenta que la tengo desde 2018, llevaba unos meses queriendo hace un pequeño upgrade pero no lograba convencerme. No era estrictamente necesario, pocas veces lo es, no imprimo 3 piezas por día como para que se vuelva algo obligatorio comprar una máquina más capaz (y vaya que han aparecido varias de esas en estos años), pero decidí tomar este pequeño desastre como una señal para apretar finalmente el gatillo e ir por una impresora superior.

En los meses que llevo coqueteando con la idea de comprar una nueva he estado viendo y leyendo mucho sobre el estado actual del mercado y una marca (y una impresora en específico) llamó mi atención poderosamente: Prusa.
Para ser más concreto, me emocionaba la idea de ser el dueño de una MK4S, tiene una pinta excelente, es rapidísima, confiable, puede ser operada remotamente y, lo mejor de todo, es de código abierto.

Okay, okay, ya sé, no, Prusa técnicamente ya no produce impresoras de código abierto, por lo menos no en su totalidad, pero muchos de los componentes tanto de hardware como de software sí lo son; aparte, no requieren una cuenta o conectarse con sus servidores para usar la impresora. Además de eso, ha sido un agente importante en el desarrollo de la escena de la impresión 3D tanto como hobby como en ambientes más profesionales, así que le debemos de alguna manera algunas de las innovaciones que hoy en día son moneda común.

Y por si todo eso fuera poco, el color de acento de sus productos es un naranja muy sexy. No sé, para mí eso suma puntos.

Bueno, tomada la decisión, sólo era cuestión de ir a la página y verificar si hacían envíos a mi área. Ja.

Y todos esos dólares no toman en cuenta el proceso y costo de desaduanaje, el cual podría incrementar el total hasta en 20%, dependiendo de cómo se apliquen las reglas tributarias. Creo que son precios un tanto difíciles de justificar.

Una vez descartada la Prusa…

Bueno, después de matar la Prusa, como diría Karol G, era momento de mirar hacia otro lado. Lamentablemente, o quizás no tanto, la siguiente mejor opción era una Bambu Lab A1.
Según mis averiguaciones, una de las mejores impresoras del mercado en el segmento de entrada: rápida, precisa, confiable y, sobretodo, barata (comparada con sus rivales, claro).

La A1 tiene varias ventajas frente a la MK4S, como el hecho de venir de fábrica con una cámara (que va a menos de 1 fps y cuyo feed sólo es observable a través de las apps de Bambu Lab, eso sí) y una pequeña lámpara, ser más fácil de ensamblar, tener una comunidad aún más grande aunque quizás no tan técnica y ser significativamente más barata. Definitivamente facilitan la toma de decisiones.

El único problema real era la compañía detrás de tan buen producto, Bambu Lab, y no porque esté llena de malos profesionales (se formó originalmente a partir de un grupo de extrabajadores de DJI, después de todo), si no porque a inicios de este año decidieron llevar a cabo una jugada bastante desleal con sus usuarios y estuvieron a punto de requerir marcas de filamento específicas y hasta suscripciones para usar ciertas funciones de sus impresoras, entre otras cosas. El asunto fue bastante discutido en ciertos espacios de internet y la empresa hizo algunos cambios significativos a su plan en respuesta, aunque el panorama sigue sin pintar demasiado bien. En este artículo de The Verge explican bastante mejor que yo el problema.

Aún así, no deja de ser un gran aparato; claro, en contraste a cómo maneja Prusa estos menesteres la diferencia es grande y hasta desagradable, pero en realidad no están haciendo nada que no haga la gran mayoría de empresas que proveen servicios atados a sus productos, como empresas de lavadoras, hornos microondas, teléfonos o autos. Para la gran mayoría de personas, incluyéndome, no es un verdadero problema que haya que crear una cuenta o descargar un programa específico, pero para un puñado eso se siente como una suerte de invasión, especialmente en un rubro en el que históricamente el conocimiento, el código y hasta el hardware se han compartido de forma tan abierta.
Es evidente que la impresión 3D ya no sólo les es accesible e interesante a unos cuantos y las impresoras están alcanzando el nivel de commodities.

Aún después de toda esa queja decidí que no era tan mala idea ir por una A1. Me sentía un traidor, claro, pero las necesidades (y la comodidad) muchas veces pueden más. Era hora de la prueba de fuego, el proceso de envío. Ja.

Bambu Lab tiene tiendas oficiales para otras regiones, más específicamente en Asia, la Unión Europea, Reino Unido, Australia, Canadá, Japón y Corea del Sur, pero nada de América del Sur. Al igual que con el costo de envío de las Prusa, consecuencias de vivir en el tercer mundo.

Menos mal tienen listas de distribuidores autorizados en regiones donde no están presentes de manera oficial y encontré una tienda en mi ciudad. Al final pagué menos por la A1 incluyendo el sistema de filamentos múltiples de lo que habría pagado por la MK4S sin ensamblar y sin dicho sistema. Una locura.

Ahora sí, juguete nuevo

Era hora de jubilar a la entrañable Ender 3 y darle paso a la juventud, al ímpetu, a la sangre nueva. ¡Los viejos a la tumba, los jóvenes a la obra! Así era, ¿no?

Para dejarlo claro, la A1 tampoco vino armada, no del todo por lo menos, literalmente son dos o tres piezas grandes que se juntan con algunos tornillos y ya está. Es un proceso que debería demorar menos de 30 minutos, probablemente. Es más, para dar un poco más de contexto, demoré bastante más desarmando la Ender 3 que armando la A1.

De todos modos, dejo por aquí algunos videos, tanto del desarmado de la antigua como del armado de la nueva.

¿la diferencia? El día y la noche. La A1 no sólo es más rápida, bastante más rápida, entre 3 y 4 veces más en condiciones y configuración estándar, si no que también es más confiable y por fin puedo enviar modelos para imprimir “a través del aire” y no tengo que acercarme necesariamente llevando los archivos en una tarjeta de memoria. También es bastante sexy, más que la MK4S inclusive.

Lo único que me resulta un poco raro es que al momento de ordenarle que imprima algo, en la etapa de precalentamiento y preparación el ritmo al que consume energía supera los 1000 vatios momentáneamente, como se puede ver en la siguiente imagen, pero luego todo dentro de lo normal.

No tuve oportunidad de medirlo, pero por lo que pude leer, el consumo energético medio de la Ender 3 en una hora es de unos 0.12 kWh, por lo que la A1 y sus 0.15 kWh estarían un 25% por encima. Considerando que para una impresión cualquiera ésta última puede demorar un 66% menos, terminaría siendo hasta 150% más eficiente que la Ender 3 y con mejor calidad. Una diferencia abismal.
Claro, si tomamos en cuenta el importante spike energético al inicio de la impresión en el caso de la A1, cuanto más filamento se imprima, más eficiente terminará siendo, ya que ese pico es menos representativo mientras más tiempo pase. En comparación, si la impresión hubiera tardado 30 minutos en vez de 60, la A1 habría resultado “sólo” un 100% más eficiente.

Pero ¿recuerdan que había comprado el combo que incluía el sistema de filamento múltiple? Era hora de armarlo, quería poder usar PETG como interfaz de soporte al momento de imprimir con PLA, que es casi siempre, es una combinación que ha probado dar buenos resultados cuando se trata de separar los soportes de las partes importantes de los objetos impresos. El problema es que no tenía espacio en mi rincón 3D para semejante soporte, tuve que buscar una alternativa. Felizmente, @arzhanglotfi en MakerWorld hizo un remix de un modelo original de Bambu Lab para anclar el módulo a la parte superior de la impresora, ocupando espacio extra sólo en el eje Z y le quedó de rechupete.

Ahora sí, con todo en su sitio, me puse a imprimir unos clips para gabinetes de servidores para colgar algunas cositas ligeras, así como unos pequeños ganchos para colgar juguetitos en las repisas, todo sin sobresaltos.

De vuelta a la lámpara

La pieza más grande demoró un poco menos de 4 horas (en vez de 12 en la Ender 3) en ser impresa y quedó bastante bien. No libre de errores, sin embargo.
Debí haber previsto que una pieza de base tan amplia y plana para evitar la ligera curvatura que se formó abajo, pero después de eso todo excelente.

Y más o menos así se ve en funcionamiento:

Esta nueva versión otorga una flexibilidad importante debido al uso de WLED como software de control, puedo escoger entre decenas de efectos y hasta existe la posibilidad de usas estas lámparas como una extensión de mi propia versión de Ambilight para iluminar las columnas con los colores de las imágenes que se reproducen en la tele en todo momento. Exquisito.

Todo bien, todo lindo, pero con cierta frecuencia se pueden apreciar unos destellos que arruinan la experiencia. En el video, en unos pocos segundos, se puede apreciar un par, pero a lo largo del día son innumerables y la situación empeora cuando se usa efectos con mayor dinamismo. En el caso de un color estático la cantidad de destellos por unidad de tiempo se ve reducida considerablemente.
Tengo una idea (o quizás un poco más que eso) de lo que puede estar sucediendo, así que mi configuración de WLED debe cambiar para deshacerme de tan molesto fenómeno.

Por el momento, una solución mínimamente elegante parece requerir una pieza que más o menos luce así por detrás:

Pero el proceso será descrito en detalle, cual youtuber, en un próximo video.

Entonces, ¿pertenece realmente la A1 al lado oscuro?

Bueno, sí y no. Por supuesto, hubiera preferido conseguir una Prusa MK4S pero, como expliqué más arriba, el precio y las complicaciones en la importación hicieron que mirara hacia el mercado local y optara por una A1. ¿me arrepiento? Yo diría que no y no con poca convicción.

Si bien Bambu Lab tiene políticas algo restrictivas y volubles, la impresora no deja de ser fantástica. Es cierto, en cualquier momento pueden quedar en bancarrota o apagar sus servidores y yo ya no podré enviar archivos para imprimir desde mi teléfono o ver desde cualquier lugar el estado de una impresión en tiempo real (o la convierten en una característica de pago), quizás un día un par de personas encargadas de cierto tipo de decisiones despiertan de mal humor y deciden que, ahora sí, no dejarán que se use filamentos de terceros en sus impresoras o tal vez sufran en algún punto de una filtración de datos privados de los usuarios, no lo sé, pero todo eso no los hace peores que compañías gigantescas cuyos productos usamos a diario y cuyos potenciales (o actuales) problemas ni siquiera entran en la consideración al comprarlos.

Además, existe el LAN Mode que, claramente, no es igual de conveniente pero es bastante más seguro, privado e independiente de la empresa. La impresora puede funcionar tranquilamente sin una conexión a internet pero se pierden características que la convierten en una mejor herramienta o, por lo menos, una más fácil de usar. He ahí el asunto, en el trade-off entre conveniencia y control.

Mi punto es que podría ser mejor pero tampoco me puedo quejar demasiado, no todo puede ser (y no es) tan open como me gustaría, pero es un modelo totalmente válido y ciertamente mayoritario. A veces hay que intentar jugar un poquito más de acuerdo a las reglas y quejarse un poquito menos.

Recomendada ampliamente. Por unos 500 verdes (maldito impuesto del subdesarrollo) difícilmente se encuentra algo mejor.

Desde luego, todos los modelos mostrados en este artículo sí son libres y están disponibles para descarga y/o modificación en GitHub.

Era cierto, el sueco, intentó reemplazar cada servicio de Google que usara por uno de código abierto y gratuito. Más de una vez, la única (o la mejor) opción lo obligaban a instalar software localmente y administrarlo él mismo con todas las ventajas y desventajas que eso conlleva, convirtiéndolo a él mismo en su propio sysadmin personal.

No podía dejar de sonreír durante todo el video mientras trataba de adivinar con qué alternativa libre reemplazaría a cada aplicación de Google, fue divertido de una forma muy nerd. Pero lo que más me embargó durante la duración del video fue una sensación de What the fuck?, no entendía muy bien, a pesar de estarlo disfrutando, por qué un grande de internet estaba en estos asuntos.

El inicio del descenso de PewDiePie hacia la locura. Bienvenido al club.

By the way, la intro del video es la versión instrumental de Moon Men de Jake Chudnow, popularizada por el genial Michael Stevens en el canal educativo Vsauce

Es difícil saber si esto ayudará mucho o poco a que 2025 sea el año de Linux en el escritorio, no lo fue cuando Valve presentó la Steam Deck y probablemente nunca lo sea, pero es reconfortante saber que alguien con tanto alcance se ha vuelto un aliado de forma tan natural. Y cuando hablo del alcance no ignoro a canales tan grandes como Linus Tech Tips que llegan a millones de personas todos los días, si no que gente como PewDiePie no sólo tiene 5 veces más personas viendo sus videos constantemente, si no que es gente que no está particularmente metida en estos temas, lo cual lo vuelve algo más raro y esperanzador, es como si Taylor Swift se volviera activista ambiental. Wait, no, no es tan malo.

Significativo y esperanzador también es el aporte de personas como DHH, quien con proyectos como Omarchy ha popularizado y facilitado el uso de Linux para uso cotidiano en el escritorio, lo cual, teniendo en cuenta su alcance mediático, incrementa el acceso y la adopción en forma no menor. No es el tema de hoy si Omarchy es realmente una pieza de software revolucionaria o sólo una buena colección de librerías para hacer del uso de Arch una experiencia menos peliaguda, si no cuánto suma a la noble causa.

Slowly but surely.

¿Por qué es importante?

No es mi intención disfrazarme de activista de balcón cuyo intento de carrera pseudopolítica dura lo que demora una persona en terminar de leer este artículo, pero siempre me interesó la tecnología y, más recientemente, los servidores y la administración de sistemas desde que descubrí Plex en 2014 y eso me ha traído consecuencias.

Por ese entonces, no tenía idea de lo que significaba auto alojar servicios localmente pero mis ganas de ver películas que no encontraba en Netflix (prácticamente el único servicio de películas on-demand que se usaba por estos lares en aquella época) hicieron que me metiera en ese rabbit hole. Pronto fue evidente que no podía simplemente tener Plex instalado en la única computadora de escritorio del hogar si quería ver películas en mi teléfono o en el televisor, así que necesitaba un servidor que estuviera prendido a toda hora, o lo más que se pueda, para tener un servicio mínimamente decente en una cantidad mayor de dispositivos.

Poco después descubrí que podía instalar Home Assistant en una Raspberry Pi 3B+ que tenía sin usar por ahí y así dar mis primeros pasos en cuanto a automatización y domótica, así conocí uno de los pasatiempos en los que más tiempo he invertido y que más satisfacciones me ha dado también.

No es casualidad, entonces, que más de 10 años después, mi visión de ciertas cosas haya sido moldeada por este tipo de actividades. Cuestiones como la privacidad, seguridad, posesión de lo adquirido, apertura de código, derecho a reparar e intercambio de conocimiento tienen peso en mi toma de decisiones digitales, si cabe el término. Obviamente, no estoy en contra de productos bajo licencias restrictivas o la monetización del trabajo, no propongo un movimiento anárquico, una rebelión o sabotaje, no soy Tyler Durden ni Louis Rossmann, no quiero que caigan Google y Microsoft, yo también uso Windows o algún producto de Apple, pero me parece que un poquito más de control de la gente sobre el software que usa y la información que expone a diario no vendría nada mal y lo que ha hecho PewDiePie, quizás sin ser demasiado consciente, es acercar —mínimamente— a mucha gente a estas ideas.

Es tremendamente difícil convencer a las masas de sacrificar un poco de la conveniencia que representa usar servicios totalmente controlados por grandes empresas en favor de un poco de autonomía, ¿de qué podría quejarme si yo mismo no puedo dejar de usar X, YouTube o iOS?. No es realista esperar que más de 700 millones de usuarios de Dropbox compren una decena de discos duros y empiecen a usar TrueNAS de la noche a la mañana, o que tres cuartas partes del mundo cambien de Windows a alguna rara, rarísima distribución de Linux.
¿Por qué lo harían? No quiero decirle a nadie lo que tiene que hacer. La verdad es que para la gran mayoría de nosotros no tiene mucho sentido y estoy de acuerdo. Es poco productivo cambiar lo que funciona, tan bien. Toma demasiado tiempo y muchas veces no funciona como debería, cuesta mucho, trae frustraciones y puede llegar a ser incluso más peligroso e inseguro que subir todas tus fotos a Google Photos si no se tiene cuidado. Yo ni siquiera entré por ideales de privacidad o libertad, sólo tuve curiosidad y me dejé llevar, sentimiento que espero videos como el de arriba generen en alguien en algún momento.

Sólo quería decir que me pone contento. Ya debería dejar de escribir tan solemnemente.

¡No tan rápido, Felix!

Todo muy bonito pero estás publicando un video sobre deGoogleización en YouTube. ¡En YouTube!

¿y cuál es el problema? Bueno, al señor YouTube no le gustan estas cosas porque podrían representar “Contenido peligroso o dañino”.

Hace unas semanas, el también youtuber Jeff Geerling, recibió más que una advertencia por parte del gigante rojito y un video suyo enseñando cómo consumir contenido (películas, series o música en este caso) de forma local, legal y sin pagar suscripciones fue removido de la plataforma porque, aparentemente, “Contenido que describe cómo obtener acceso no autorizado o gratuito a contenido audiovisual que usualmente require un pago no está permitido en YouTube”.

Geerling en ningún momento publicó un tutorial sobre cómo obtener y ver Desperate Housewives o el último disco de Lisa de forma gratuita; es más, nunca ha sido defensor de la piratería, pero YouTube lo eliminó automáticamente de todas formas y hasta ahora el motivo es incierto. Es posible que el algoritmo de identificación de contenido no deseado haya relacionado algunos términos usados en el video con palabras que se suelen usar en videos donde sí se promueve la piratería, pero son sólo conjeturas.
El video ha sido repuesto después de una revisión manual pero el mal momento y sobretodo, la preocupación de que los términos y condiciones del sitio pueden ser aplicados de forma totalmente arbitraria, quedan.

El video de Geerling previamente eliminado por YouTube

Por supuesto, Felix no ha publicado ese tipo específico de contenido aún y, de llegar a darse el mismo escenario, tiene una voz lo suficientemente fuerte como para reclamar y ser oído al instante, pero quizás sería mejor que ande con un poquito de cuidado en estas nuevas aguas, sólo un poquito. Quizás a papá YouTube no le excita que se hable de estas cosas, precisamente.

Por último, un saludo

No sé cuál será la motivación detrás de esta especie de cambio de carrera pero me agrada. Aunque siempre supe de su existencia nunca fui un seguidor suyo pero si empieza a publicar más videos de este estilo, quizás se vuelva un creador de contenido al que deba prestarle atención.
Sólo sé que el tipo dedicó gran parte de su vida a lo que le gustaba, fue, literalmente, el más exitoso en su campo, hizo quién sabe cuánto dinero y ahora, semijubilado, se ha mudado a Japón con su familia, vive tranquilo, trabaja por gusto y se divierte aprendiendo y experimentando con cosas en las que, quizás, siempre estuvo interesado.

Si la vida es un juego, PewDiePie terminó la misión principal en la mitad del tiempo y con todas las habilidades al tope y ahora se dedica a las misiones secundarias por diversión. Él ya ganó, qué envidia.

Fue ahí donde elaboré, por primera vez, una interfaz gráfica para mi proyecto musical, dicha interfaz necesitaba de un fondo colorido para la imagen que indicaba qué canción se reproducía.
El problema es que, fijándome en la documentación del portal para desarrolladores de Spotify, en ningún lado se hacía referencia a colores y mucho menos se hacía pública esa información (cosa que sí hace Apple, por ejemplo), tampoco en su blog de ingeniería y tecnología; además, yo no tenía idea de cómo si quiera empezar a programar un algoritmo de obtención de color por lo menos similar. Tenía una idea meramente intuitiva de qué color era el que se escogía dependiendo de cómo se veía las carátulas de los álbumes, pero eso difícilmente sería suficiente.

Me puse a ver unos cuantos ejemplos, quizás así se me ocurriría algo, un punto por el cual empezar.

¿puedo evitar la fatiga?

Pensé que las imágenes seguramente se procesan en el lado del servidor ya que los colores se mantienen (en su mayoría) a través de distintas plataformas pero también estaba seguro de no haber encontrado nada al respecto en la documentación, entonces me fui al reproductor web para escudriñar las solicitudes y respuestas y sí, efectivamente, encontré que, cuando se realiza la solicitud para obtener las letras de una canción, también incluye la respuesta el color de fondo que deberían tener, color que estaba buscando.

La diferencia es que la dirección a la que se hace la solicitud no tiene mucho que ver con la API oficial, imagino que serán servicios internos que sólo pueden usar aplicaciones first party. La dirección tiene la forma https://spclient.wg.spotify.com/color-lyrics/v2/track/{track_id}/image/{image_url} y sólo retorna el color esperado si Spotify (o Musixmatch) tienen registro de las letras correspondientes o si están disponibles para la región en la cual está registrada la cuenta y si la imagen a procesar también es parte de su base de datos; de lo contrario, no hay ni letra, ni color.

Sólo tenía que descifrar cómo obtener el token que se requiere para automatizar el proceso, simular ser un cliente web desde la terminal y obtener todos los colores que pueda querer. El impedimento fue mi flojera para encontrar patrones en los 10 encabezados que tenían las solicitudes y la amenaza de sentencia de muerte que me hizo Spotify, así que no continué por ese camino. Parecía prometedor.

Intentando entender a Spotify

Tenía que idear alguna otra forma, así que intenté entender qué color escoge Spotify para los fondos. ¿quizás el más colorido? ¿quizás el que ocupa una mayor región en la imagen? ¿quizás el que más resalta? ¿a lo mejor una combinación de todos los anteriores y aún más aspectos?

Veamos unas cuantas imágenes acompañadas de su color de fondo seleccionado:

• Figura 1: parece fácil, el color más vivo (o el más alejado del blanco y negro, como lo entiendo yo) es el rojo y no en una proporción despreciable. Color resultante: rojo.
• Figura 2: supongamos que ni el blanco ni el gris de las letras superiores serán elegidos, así que quedan como opciones el magenta, amarillo, celeste y hasta verde pero ninguno sobresale demasiado. Color resultante: rosa.
• Figura 3: yo esperaba que fuera negro pero, aparentemente, el algoritmo lo evita a toda costa, al igual que el blanco. Color resultante: gris.
• Figura 4: aquí hay problemas, descarto el negro pero el rojo/naranja resalta del azul, parece que el azul no es tan discriminado pero me genera dudas. Color resultante: azul.
• Figura 5: bueno, se va comprobando la hipótesis del color más colorido, aunque el amarillo pudo haber sido descartado por apagado o por poco representativo. Color resultante: magenta.
• Figura 6: se pone difícil, hay por lo menos tres colores que se podrían considerar vivos de alguna forma pero aparentemente, de entre ellos, se elige al más oscuro. Color resultante: azul.

Si tomamos en cuenta también las primeras imágenes de este artículo, la idea se suele mantener en pie salvo por dos. En el caso de la segunda, yo diría que el color predominante, en todo aspecto, debería oscilar entre el naranja y el rojo pero el fondo elegido oficialmente es azul; un poco más de lo mismo con la tercera, el color que resalta es una suerte de naranja pero resulta en azul también.

No he podido hasta ahora determinarlo del todo, pero creo que la cosa va más o menos así:

• La imagen se repartirá en N grupos de colores similares para no lidiar con potencialmente cientos de colores ligeramente diferentes. Esto ayuda al rendimiento del algoritmo.
• Siempre se va a preferir a los colores más coloridos o vívidos (definidos más adelante) por encima del resto. Este factor de preferencia será definido por qC.
• En igualdad de condiciones en cuanto a qué tan colorido es un color, el color más oscuro (o sea, el menos luminoso) gana. Este coeficiente de preferencia será almacenado en qD.
• El porcentaje de la imagen que ocupa el color se tendrá en cuenta pero no se le dará tanta relevancia como su nivel de vividness, permítanme el neologismo coyuntural.Dicha relevancia será definida por qR.
• Si el color resultante es blanco o negro se elegirá, en su lugar, un gris más claro o más oscuro dependiendo del color obtenido previamente.
• Al color obtenido finalmente se le incrementará la saturación en un factor de S para hacerlo contrastar más con el color blanco.

En pseudo código, ignoren la caligrafía:

Intentando copiar a Spotify

Ahora, ¿cómo calcular la (permítanme la palabreja) “vividez”? Con coordenadas RGB es un poco complicado, así que trasladaremos los colores al espacio de color CIELAB, que nos permite realizar este tipo de operaciones matemáticas de forma más simple y sin tener que recurrir a trigonometría necesariamente. Es como pasar de coordenadas cartesianas a polares. En este enlace se puede encontrar una guía de X-Rite y PANTONE para entender mejor cómo se expresan matemáticamente los colores en sus distintos sistemas.

Según la teoría, qué tan vívido percibe un humano un determinado color depende de su saturación y su luminosidad, de la siguiente forma:

\begin{aligned} V = (L^*)^2 + (C^*ab)^2 \end{aligned}

Donde L* es luminosidad y C*ab es saturación

Pero la ignoré tras descubrir que centrarme en la saturación (C*ab) como primer componente me daba mejores resultados.

Sin embargo, para el cálculo de la luminosidad sí haremos uso del espacio RGB, ya que es más sencillo de esa forma. La ecuación (descrita en este manual del organismo de telecomunicaciones de la ONU en el apartado 3.2) es:

\begin{aligned} Y = 0.2126 * R_{lin} + 0.7152 * G_{lin} + 0.0722 * B_{lin} \end{aligned}

Donde cada componente RGB está expresado de forma lineal ―o sin la codificación gama―

Utilicé los valores de 10 para el número de grupos o clusters y de 5.0, 1.5 y 0.8 para qC, qD y qR, respectivamente, después de haber hecho unas pruebas rápidas viendo qué color devolvía el algoritmo y qué color ponía Spotify en sus aplicaciones. Funcionaba bien empíricamente pero quizás había coeficientes que funcionaban mejor y que me tomarían mucho tiempo de ensayo y error encontrar. Aparte de eso, la fórmula que se me había ocurrido podría o no ser una buena alternativa para el cálculo que necesitaba.
Era momento de usar la estadística para respaldar mis suposiciones.

Intentando mejorar la copia

Con ayuda de la dirección prohibida de la cual Spotify no quería que hiciera uso que mencioné líneas más arriba (de la que hice uso con una cuenta alternativa para no morir) armé un script rápido para obtener datos clave de unas 100 canciones medianamente aleatorias (aunque seguramente influenciadas por mis gustos musicales), lo cual me permitía someter las carátulas de los álbumes a ser procesadas por el algoritmo y comparar el resultado con el color oficial, aparte de los tres aspectos que contribuyen al puntaje final sin tomar en cuenta los coeficientes qX.

Algo más o menos así, aunque con bastantes más filas, con 10/20 resultados por id (dependiendo de N) y más decimales en los números:

chroma hace referencia a colorfulness en pseudocódigo. Parecía más apropiado.

En R pude realizar un par de regresiones lineales para encontrar los mejores coeficientes, por lo menos para las 100 canciones en mención, dando más peso a los casos en los que un score mayor coincidía con un color_delta menor, lo cual significa que la fórmula funciona (o que está en el buen camino) y quitando relevancia al resto de resultados por cada grupo de colores pertenecientes a una imagen.

Pero la fórmula podía no ser la más adecuada para el cálculo, así que también intenté un ligero cambio:

  S = qC * chroma + qD * darkness + qR * dominance =>  S = chroma ^ qC + darkness ^ qD + dominance ^ qR

Nótese el cambio de * a ^, pasando de una fórmula lineal a una exponencial.

Y volví a generar datos. El formato era el mismo que el de la tabla de más arriba pero los datos, claro, cambiaron. Decidí no dar demasiadas vueltas y empezar con valores bastantes parecidos a los que la fórmula lineal, 5.0, 1.2 y 0.9, y confiar en las matemáticas.

De esta forma, sin embargo, una regresión lineal ya no sería el análisis adecuado para los datos, así que después de algo de research fui por el método de mínimos cuadrados no lineales (o NLS para los amigos).

Luego de unas cuantas rondas de fitting puse los resultados en una pequeña tabla para poder escoger mejor el camino que tomaría.

Es claro que ninguna de las dos fórmulas, ya sea usando 10 o 20 grupos de colores, es demasiado acertada. Lo más seguro, creo, es que los ingenieros de Spotify tomen en cuenta más variables de las que yo con este algoritmo, aunque no se me ocurre cuáles. También es posible que la fórmula en sí sea bastante más complicada, por supuesto.

Pero no importa, en todo ese mar de números mediocres hay un método que seguramente lo es menos que el resto, así que iré a la guerra con él aunque sólo tenga un porcentaje de aciertos del 31%.

El código resultante para la fórmula lineal ajustada de 20 clusters terminaría siendo este:

import math
import numpy as np
from PIL import Image
from sklearn.cluster import KMeans

qC = 4.9226
qD = 1.4060
qR = 0.7932

def calculate_dark_colorfulness(rgb):
    red, green, blue = [x / 255.0 for x in rgb]

    red_greenness = red - green # or the a component
    yellow_blueness = (red + green)/2 - blue # or the b component. red + green output yellow in additive color (light)

    chroma = math.sqrt(red_greenness ** 2 + yellow_blueness ** 2)

    """
    Choose any of these three, bascially according to preference, the output is not going to change
    significantly. If you care about accuracy, you're free to do some research to determine the best
    option for your use case. Keep in mind that the overall formula coefficients might need to change too.

    They're as follows:

    First option: the standard way of obtaining luminance from RGB coordinates but without linearizing
    Second option: same as the previous, but linear (removing gamma correction)
    Third option: Independent HSP color space "percieved brightness" (https://alienryderflex.com/hsp.html)

    """

#    luminance = 0.2126 * red + 0.7152 * green + 0.0722 * blue # Relative luminance
#    luminance = 0.2126 * (red ** (1/2.2)) + 0.7152 * (green ** (1/2.2)) + 0.0722 * (blue ** (1/2.2))# Relative luminance without gamma correction
    luminance = math.sqrt(0.299 * (red ** 2) + 0.587 * (green ** 2) + 0.114 * (blue ** 2)) # Percieved brightness (HSP)
    darkness = 1 - luminance

    return (chroma, darkness)

### TO-DO: Implement improving picked color contrast with white, as lyrics are always white, to better match Spotify's choice
def improve_white_contrast(rgb, brightness_factor=0.85, saturation_boost=1.1):
    red, green, blue = [x / 255 for x in rgb]
    hue, sat, value = colorsys.rgb_to_hsv(red, green, blue)

    sat = min(sat * saturation_boost, 1.0)
    value = max(value * brightness_factor, 0.0)  # darken

    red, green, blue = colorsys.hsv_to_rgb(hue, sat, value)
    return tuple(int(x * 255) for x in (red, green, blue))

def extract_color_clusters(num_clusters):
    image = Image.open("./cover.jpg").convert("RGB")
    width, height = image.size

    try:
      pixels = np.array(image).reshape(-1, 3) # Turn a RGB matrix into an RGB 2D array

      # Cluster colors using K-Means
      kmeans = KMeans(n_clusters=num_clusters, random_state=0, n_init="auto")
      kmeans.fit(pixels)
      labels = kmeans.labels_

      colors = []

      # Group colors by cluster and calculate average for each
      clusters = [[] for _ in range(num_clusters)]
      for i, label in enumerate(labels):
        clusters[label].append(pixels[i])

      for group in clusters:
        color = np.mean(group, axis=0)
        chroma, darkness = calculate_dark_colorfulness(color)
        dominance = len(group)/(width * height)

        score = chroma * qC + darkness * qD + dominance * qR

        colors.append({
          'color': tuple(int(c) for c in color),
          'score': score,
        })

      return colors
    except Exception as e:
      print(e)
      print("Black and white image?")
      return [{
        'color': (128,128,128),
        'score': 10.0,
      }]

def get_best_color():
  return max(extract_color_clusters(20), key=lambda c: c['score'])

if __name__ == '__main__':
  print(get_best_color())

Código también disponible en este gist en GitHub.

Por supuesto, la fórmula final pasa a ser:

\begin{align} S = 4.923 * Ch + 1.406 * Dk + 0.793 * Do \end{align}

Es una idea que lleva en mi mente unos meses, quizás más de un año. Como siempre, me demoro en resolver las cosas que me causan molestias si no es urgente, así que lo más fácil era esperar a que la solución, o algo que se le parezca, llegue a mí.

Y sucedió. No recuerdo cómo, no recuerdo cuándo, no recuerdo dónde pero me enteré de la existencia del Vobot Mini Dock, que es una especie de reloj de escritorio conectado a internet que funciona como hub USB y con algunas aplicaciones que podrían servirle a alguien. Lo que más me llamó la atención fue que el producto permitía aplicaciones desarrolladas por terceros y hasta tenían una pequeña tienda para encontrar nuevas. Lo compré.

Interesante dispositivo.

Al conectarlo y probarlo por primera vez resultó aparente el uso principal que le quería dar. Necesitaba de él un servicio similar al que ofrecía el Spotify Car Thing (captura de Archive.org ya que la página original ya no existe) en sus buenos días antes de morir.

Obviamente, no podía pedirle demasiado. Está basado en el ESP32S3, que es un microcontrolador con 512 KB de RAM y un CPU a 240 MHz (para referencia, un Samsung Galaxy S25 tiene 12 GB de RAM y un procesador con núcleos que pueden alcanzar los 4.47 GHz) y tiene una pantalla LCD de 240x320 píxeles; o sea, bastante básico pero seguramente suficiente. Sólo necesitaba que me dijera qué canción se estaba reproduciendo en ese momento, el artista y, con un poco de suerte, que me muestre la portada del álbum al cual pertenece la canción en cuestión.

Busqué en la tienda de aplicaciones alguna app que ofreciera algo parecido pero no tuve suerte, la oferta es más bien pobre y sólo hay una aplicación de un tercero aparte de las aproximadamente 10 que ofrece la propia Vobot.

Era momento de llevar mi visión a la realidad yo mismo.

El problema

No tenía idea de qué lenguaje usaba Vobot para las aplicaciones del Mini Dock, pero seguramente C++ o alguna variante. Pues no, usa MicroPython para la lógica y LVGL para los gráficos. Experiencia con Python tengo, así que programar en su versión para microcontroladores debería ser similar, pero jamás había siquiera oído de LVGL; obviamente, tenía que leer toda la documentación que pudiera para aprender a usarlo.

La documentación de LVGl para C es bastante completa pero para MicroPython es, digamos, un poco optimista por no decir incompleta. No pude aprender demasiado leyendo la referencia de la API; además, los nombres de métodos son bastante parecidos entre uno y otro lenguaje pero el patrón no es totalmente evidente a primera vista. Menos mal tuve ayuda de un par de proyectos preexistentes precisamente para este relojito. Gracias a @itandy848 y su repo HK Weather y a la misma Vobot pude reconstruir las partes del código con las que la documentación oficial no me ayudó mucho.

Ah, por cierto, la documentación de Vobot para el desarrollo de aplicaciones es prácticamente inexistente. De no haber hecho público el código para algunas de sus aplicaciones pre-instaladas no estaría escribiendo este artículo o habría sido publicado 9 meses más tarde como mínimo.

Bien, con todas (o casi todas) las piezas en su lugar, finalmente podía dedicarme a escribir el código.

La idea es simple:

• Realizar el proceso de autenticación para que Spotify supiera quién está consumiendo su API
• Preguntar por la canción siendo reproducida con toda su información
• Mostrar la info relevante en pantalla
• Repetir cada N segundos para mantener la aplicación autorizada
• Volver a la autenticación cada vez que mi token de identificación expire

Las cosas salieron más o menos como se esperaba, me tomó mucho tiempo aprender a utilizar bien LVGL, no sabía cómo mostrar imágenes en pantalla, era importante si las imágenes eran PNG o JPEG (Spotify las devuelve en formato JPEG), LVGL parece sólo funcionar con imágenes en formato binario y algunos detalles más. Pero tuve más problemas con dos aspectos importantes de la aplicación: las imágenes y las constantes solicitudes a los servidores de Spotify, así como el tamaño de su respuesta.

Las imágenes

Como se ve más arriba, la primera versión (y lo más complicado) fue mostrar las imágenes en pantalla. Cuando, después de un buen rato, lo logré (había que especificar el peso de la imagen al momento de crear el objeto de LGVL que se encagaría del resto) me di cuenta de que las imágenes no cabían del todo bien en la pantalla. Además, aún faltaba agregar el texto y todo eso.
Resulta que en LGVL, sobretodo cuando se trata de microcontroladores como este ESP32, llevar a cabo el redimensionado de una imagen es un proceso costoso en términos de cómputo y no quería darle demasiado trabajo al pobre.

¿quizás si le pido a Spotify una imagen más pequeña? Bueno, Spotify mantiene 3 tamaños de imagen para las carátulas de los álbumes, pero ninguna de unos 150x150, que era lo que necesitaba. Las hay de 64x64, 300x300 y 640x640.

Las solicitudes

Cada cierto tiempo, digamos 3 segundos, tenía que hacer una solicitud para mantener el reloj relativamente sincronizado con el backend de Spotify, el problema es que cada una de las solicitudes que hacía demoraba unos milisegundos más de lo que me hubiera gustado y el tamaño de las respuestas era un poco atroz, estaban en el orden de decenas (o hasta centenares) de kilobytes. No pintaba bien para el pequeño ESP32.

Aparte de esto, se me ocurrió que quedaría bien pintar el fondo del color predominante tal cual como lo hace Spotify en sus aplicaciones. Siempre me gustó cómo se veía y también me causaba intriga cómo escogían el color.
Pintar la pantalla entera también tiene un costo no menor.

Con todo esto, resultaba medianamente evidente que seguir poniendo toda la lógica en el dispositivo iba a dejarme con una experiencia de uso mediocre, la lentitud se notaba, la escasa memoria se llenaba rápido y los 3 segundos de retraso que debían existir como máximo se convertían en 5 o 10 debido a todo lo que tenía que hacer el reloj antes de decirme qué era lo nuevo que se estaba escuchando. Sumado a la pobre optimización de mi código, por supuesto.

Cliente y servidor

No esperé a que fuera demasiado evidente y me puse a resolver los problemas mencionados en el Python de toda la vida en una máquina virtual en un servidor x86. En ese entorno la manipulación de imágenes y las solicitudes constantes no representarían ningún tipo de problema, aparte de que trabajar en Python es más fácil debido a la falta de limitaciones y que no todo el código tiene que ser un poquito especial o asíncrono.

Las ventajas eran evidentes, le entregaría al reloj una imagen exactamente del tamaño que necesita y con calidad rebajada para reducir el tamaño; además, al controlar yo la información que llegaba a él, podía quitar de las respuestas de Spotify todo lo que no fuera vital para el funcionamiento de la aplicación y así reducir también el tamaño del JSON que se transmitía, aparte de responder considerablemente más rápido por tratarse de un servidor “local”.

Finalmente pude terminar el proyecto. El ícono de estado de reproducción indica si se está reproduciendo o no algo (indica estado porque no es un botón, aunque estoy pensando en cambiar eso, así que pasaría a indicar acción), la barra de progreso se mueve con el tiempo, las etiquetas del nombre del artista y canción se mueven con efecto de marquesina si el texto es demasiado largo para el ancho de la pantalla y, lo más importante, logré pintar el fondo de la pantalla del color dominante o resaltante de la imagen.

¿cómo logré esto último? Bueno, ya escribí al respecto en otro post.

El código fuente tanto de la aplicación en el reloj como del servidor intermediario entre Spotify y el Mini Dock se encuentran en este gist en Github.

Hace un par de días llegó a mi mente la melodía de una canción que había escuchado hace no demasiado tiempo por última vez, quizás unos meses o un año. No recordaba nada salvo eso y que en algún punto el cantante (o cantantes) mencionaban la palabra “dangerous”.
Hice lo que cualquier mortal haría, preparé mi garganta para imitar un piano y un sintetizador de la mejor forma posible para que Shazam pudiera ayudarme. Me esmeré bastante pero no pude lograr que la reconociera, seguramente porque mi habilidad de imitar instrumentos es deprimente.

Para otorgar un poco de contexto y risas, este soy yo intentando sonar como la canción en cuestión:

Al no obtener una respuesta satisfactoria por parte de Shazam, decidí probar con ChatGPT. Estos son todos los datos que, luego de varias preguntas, logramos recopilar con lo poco que recordaba:

• Voces masculinas de ensueño
• Ambiente romántico y/o retro-futurista
• Una base melódica de sintetizador
• Piano de notas simples
• Ritmo de medio tiempo (~100 BPM)
• Sensación de electrónica/synth-pop
• Un ritmo suave con percusión mínima
• Atmósfera cósmica y ligeramente melancólica

Pero nada. Algunas recomendaciones eran bastante interesantes y hasta similares en melodía o tempo pero ninguna era la que buscaba. Comenté el problema con un par de personas con esperanzas de obtener un resultado satisfactorio pero si bien reconocieron el sonido que les proporcioné, no sabían decirme a qué canción pertenecía. Mala suerte.

Yo recordaba que la canción era algo simple en su esquema, me pareció que la recordaba relativamente bien, así que se me ocurrió armar una maqueta en GarageBand, hacerla sonar tan parecido a la original como pudiera y luego volver a recurrir a Shazam, así que me puse a jugar con la aplicación, era todo un primerizo.

El proyecto se terminó viendo así:

Sabía (o esperaba) que unos cuantos segundos de pista serían suficientes para que pueda ser reconocida. El proyecto sólo contempla un piano, un sintetizador y una base de batería electrónica, así que es bastante simple. No estaba muy seguro de si la batería sonaba en conjunto con el piano, por eso es que hay una sección con y otra sin ella.

Y terminó sonando así:

Un segundo intento con Shazam y voilà, encontré lo que tanto buscaba. La canción en cuestión es I Like Chopin de Gazebo y no era synthpop, no tenía dos voces masculinas y, sobretodo, no tenía en ninguna parte de sus letras la palabra “dangerous” (era “rainy days”, cómo falló mi memoria). Con razón ChatGPT no pudo ayudarme. 😔

Aquí una muestra de la canción:

Para terminar, sólo por si acaso

Quería ver si realmente fue mi responsabilidad no haber encontrado la canción con la ayuda de ChatGPT, así que armé una nueva sesión en donde le di todos los datos corregidos poco a poco. Hasta le dije que se centrara en buscar canciones que incluyeran las palabras “rainy days”, que en realidad son parte de la canción, y ni así me dio una respuesta satisfactoria. Es más, parece que no puede “leer” las letras de las canciones para discernir correctamente.

Aquí le doy mejores pistas sobre la letra de la canción:

Aquí le indico el género para probar suerte:

Y aquí, ya habiéndole dicho el título de la canción, me dice esto:

Al parecer no es la mejor fuente de conocimiento para encontrar música, aunque me ha salvado en alguna ocasión anterior.

El proyecto de GarageBand puede ser descargado desde este enlace.

Todo estaba yendo relativamente bien hasta que empezó a ir relativamente mal: me di cuenta de que, a veces, las películas o videos que guardo ahí tenían dificultades para comenzar a reproducirse y/o para continuar la reproducción cuando hacía saltos en la línea de tiempo. No era un problema enorme, ya que no es común que se hagan saltos temporales cuando se ve una película, pero el problema ya había captado mi atención.

Pensé primero que mis discos duros estaban fallando, ya que este problema no sucedía hace un par de años cuando mudé mi biblioteca multimedia a ellos, así que realicé un par de análisis SMART y parecía estar todo bien con ellos. Descartado.
Creí que podía ser un caso de cuello de botella de red, pero era muy improbable dado que el problema lo observé mientras se realizaba una reproducción local de los archivos y, además, recientemente había mejorado el ancho de banda de mi red local a unos nada despreciables 10 Gigabits (más de esto en algún otro post en el futuro). Descartado.
Se me pasó por la mente que alguno de los nodos (computadoras/servidores) podría estar teniendo problemas en el momento de saltar de un lado al otro de la película, pero no vi en ningún caso un uso excesivo del CPU. Descartado.

Descarté un par de opciones más durante días y semanas, pero me di cuenta de algo interesante mientras intentaba repetir adrede el error con fines de diagnóstico. No importaba de cuántos minutos era el salto, no importaba si adelantaba 5 o 50 minutos, de todas formas había una demora notable; pero más interesante aún, me di cuenta de que si no pasaba el cursor por encima de la línea de tiempo y saltaba directamente poniéndolo justo en el punto al que quería saltar el retraso prácticamente desaparecía. Muy interesante.

El problema

Revisando los registros en la ventana de DevTools del navegador, noté que había muchas solicitudes hechas al mismo endpoint, todas comenzaban por Thumbnail y entonces todo cobró sentido: mientras hacía scrubbing, o sea, mientras pasaba el cursor por la línea de tiempo para ver una pequeña previsualización de lo que pasa a lo largo de ella, se hacían decenas de solicitudes que permitían a Emby obtener las miniaturas para la previsualización. Miniaturas de poco peso, sí, pero que en el orden de decenas van retrasando de manera significativa que subsecuentes acciones se lleven a cabo.

No logré determinar cuántas solicitudes se realizan por cada ¿píxel?, ¿quizás por cada em?, pero resultan muchas en poco tiempo haciendo scrubbing y puede llegar a ser frustrante porque el video vuelve a reproducirse sólo cuando todas ellas (o por lo menos un buen porcentaje) han sido completadas, satisfactoriamente o no.

La solución

Visitando los foros de Emby vi que recomendaban activar la opción de guardar las miniaturas en el mismo disco donde reside el contenido. Es una opción que yo había deliberadamente dejado desactivada porque no quería usar espacio de forma innecesaria. Añadido a esto, se recomendaba también que cada archivo de video resida dentro de su propio directorio y no tenerlos a todos dentro del mismo nivel debido a que así tanto los sistemas operativos involucrados (Debian para el NAS y Windows para el cliente que estaba usando en ese momento) como Emby mismo tendrían menos trabajo encontrando y accediendo a archivos.

Manos a la obra, entonces.

Esto inició un proceso que haciendo uso de, hm hm, FFmpeg genera archivos BIF (creado por Roku) que encapsulan instantáneas tomadas a intervalos regulares de la totalidad del video. Hasta ahí todo bien, pero el proceso toma aproximadamente 9 segundos por gigabyte en mi hardware y con varios terabytes a cuestas iba a tomar unas buenas horas.

Un tiempo después, y con el proceso terminado, tenía el doble de archivos en mi directorio principal de películas/videos, cada archivo MP4 o MKV tenía un análogo en formato BIF con el mismo nombre. Si hago un poco de memoria, recomendaban por ahí no tener tantos archivos al mismo nivel y lo que hice duplicó el número original, todo mal. Lo bueno es que el siguiente paso seguramente mejoraría las cosas.

Tenía que pasar cada dupla de archivos a su propia carpeta, lo malo es que Emby no se pone nada contento cuando le mueven los archivos de lugar. No importa si sólo los pones dentro de otra carpeta y ya, representa un cambio en su ubicación y eso basta. La consecuencia de esto es que Emby no reconocería los “nuevos” archivos como archivos de los cuales ya tenía conocimiento y las referencias a los “antiguos” quedarían invalidadas, estropeando así listas de reproducción y favoritos, por ejemplo.

Leyendo por ahí, recomendaban el uso de los archivos NFO porque podrían preservar información importante sobre los archivos y siempre y cuando estén junto a los videos esa información estará disponible.

Hice la prueba, activé la opción de guardar todo en el disco multimedia en formato NFO y mover un par de películas a sus respectivas nuevas carpetas. Reescaneé la carpeta en Emby, refresqué los metadatos pero nada, las películas en cuestión habían desaparecido de las listas de reproducción en donde se encontraban así como de favoritos. Lo curioso es que si regresaba los archivos a su ubicación original todo volvía a la normalidad. Al parecer, la forma correcta de quitar ítems de estas listas es deliberadamente quitándolos mediante las aplicaciones o la API.

Claramente necesitaba otra forma de preservar mis favoritos y listas. Noté también que Emby parece darle un identificador único a cada video pero basado en un índice que va incrementándose conforme se van añadiendo nuevos archivos, lo cual significa que, al Emby considerar los archivos movidos como nuevos, tampoco conservaban sus IDs y obtenían uno nuevo.

Lo mejor que se me ocurrió fue resolverlo por medio de los nombres de las películas/videos. Estaba casi 100% seguro de que ninguno se repetiría y que, básicamente, funcionarían como un identificador único, pero Emby no piensa igual, así que habría que usar su API para hacer una búsqueda por el nombre y así poder llegar al verdadero ID (al nuevo) para poder volver a agregar los archivos a favoritos.

Algo a tener en cuenta es que cuando se hace la búsqueda mediante la API o GUI Emby no devuelve un solo resultado aunque haya una coincidencia exacta, así que tenemos que refinar la búsqueda. Una simple comparación de cadenas debería ser suficiente.

import requests
import json

EMBY_IP = ""
API_KEY = ""
USER_ID = "" # In the format XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
PARENT_ID = "" # In case the videos need to be filtered by library

HEADERS = {"X-Emby-Token": API_KEY}

def get_favorites():
    url = f"{EMBY_IP}/Users/{USER_ID}/Items?Recursive=true&IsFavorite=true&ParentId={PARENT_ID}&IncludeItemTypes=Movie"
    response = requests.get(url, headers=HEADERS)

    if response.status_code == 200:
        items = response.json().get("Items", [])
        return [item["Name"] for item in items]
    else:
        print("Error fetching favorites:", response.text)
        return {}

def search_new_item_id(name):
    url = f"{EMBY_IP}/emby/Items?Recursive=true&SearchTerm={name}"
    response = requests.get(url, headers=HEADERS)

    if response.status_code == 200:
        items = response.json().get("Items", [])

        matching_items = [item for item in items if item["Name"].strip().lower() == name.strip().lower()]

        if matching_items:
            return matching_items[0]["Id"]
    return None

def re_add_favorites(old_favorites):
    for name in old_favorites:
        new_id = search_new_item_id(name)
        if new_id:
            url = f"{EMBY_IP}/Users/{USER_ID}/FavoriteItems/{new_id}"
            response = requests.post(url, headers=HEADERS)

            if response.status_code == 200:
                print(f"Re-added favorite: {name}")
            else:
                print(f"Failed to re-add {name}: {response.text}")
        else:
            print(f"Could not find new ID for: {name}")

if __name__ == "__main__":
    print("Fetching current favorites...")
    old_favorites = get_favorites()

    input("Move your files now and press Enter when done...")

    print("Re-adding favorites with new paths...")
    re_add_favorites(old_favorites)

Pero ahora los archivos están en tríos, ya que tenemos el archivo multimedia, el archivo de miniaturas (BIF) y el archivo de metadatos (NFO), y moverlos manualmente a sus respectivas nuevas carpetas puede ser engorroso. Es engorroso.

Para resolverlo usé FileBot, que es aparentemente bastante usado por usuarios en los foros de Emby y Plex para organizar archivos, mover, copiar, eliminar y más cosas. Lo malo es que tiene costo, lo peor es que es una suscripción, pero considerando que no es muy caro (tiene un precio de 6 dólares anuales al momento de escribir este artículo) y que muy probablemente tendré que realizar este tipo de operaciones con cierta frecuencia en el futuro, sumado a que tenía flojera de escribir otro script, decidí darle una oportunidad a una herramienta probada por la comunidad.

Usando el preset “File to Folder Name” logramos que se cree una carpeta común para los tres archivos y que ese sea su nuevo hogar. En el ejemplo no hay archivos de otro tipo pero siempre que todos tengan exactamente el mismo nombre (sin contar la extensión, claro) serán puestos en el mismo directorio.

Para ir terminando

Con los cambios anteriores el rendimiento es observable en algunos aspectos y significativo en otros. Por ejemplo, cuando se trata de escanear las bibliotecas de videos, aparentemente se realizan un poco más rápido; cuando se trata del scrubbing, la aparición de miniaturas sobre la línea de tiempo es casi instantánea y ya casi no hay tiempo de espera al saltar a otro punto sin importar de qué forma se haga. Parecen resultados satisfactorios.

Para algún día

• Escribir un script para realizar el mismo proceso pero con listas de reproducción. No debería ser complicado, es bastante parecido al código que ya tenemos, se podría adaptar sin muchos problemas.
• Si bien puedo usar FileBot en cuantas máquinas necesite casi sin importar la plataforma (hay soporte para Docker, Ubuntu, macOS, Windows y hasta CentOS), sería prudente reemplazarlo con un script básico. Por el momento, ya hice el gasto y haré uso del programa para estos menesteres, pero para lo que necesito unas cuantas líneas de código deberían bastar.

Alquilé un auto y grabé el camino hacia unas tiendas de segunda mano que quedaban a las afueras de la ciudad en la que me estaba quedando. Más o menos unos 90 minutos de ida y una cantidad similar de vuelta.
Cuando llegó el momento de transferir los videos a un medio de almacenamiento más seguro, recordé algo que había olvidado, cada video de aproximadamente 7 minutos pesaba unos 4 GB. Se veía bien, era lo que importaba entonces.

Unas semanas más tarde, cuando me dispuse a transferir dichos archivos a mi servidor para poder visualizarlos en diferentes dispositivos gracias a Immich, a parte de tardar una eternidad en la transferencia en sí, encontré un par de problemas:

• Como mencioné más arriba, las cámaras seccionan la grabación para que los archivos de video no pesen más de 4 GB. DJI dice que usan FAT32 (sistema que presenta precisamente esta limitación), lo cual explica el fenómeno.
• Dada la configuración elegida al momento de la grabación (1080p 60 fps HQ), los videos tenían un bitrate de unos 80 Mbps, u 80000 Kbps, lo cual es más del doble de lo que se encuentra en algunos discos de Blu-ray convencional y un poco menos de lo que se puede encontrar en discos de Blu-ray 4K.
• Estas dos cámaras no tienen GPS incorporado, lo cual no es un problema ni para la mayoría de situaciones ni de personas, yo incluido, pero justo en ese caso, dada la naturaleza de la grabación, era un feature más que bienvenido.

Veamos…

FAT32

El primer problema no es tan problemático, ni siquiera es un problema, es hasta una buena característica de este tipo de cámaras. El hecho de que los de DJI usen FAT32 y los videos individualmente no pesen más de 4 GB facilita trabajar con ellos y podría prevenir problemas serios de corrupción.

Transferir archivos MPEG-4 (o sea, MP4) demasiado grandes puede ser complicado. Superando los 36 GB por hora de grabación, una transferencia de ese tipo podría demorar horas entre dispositivos inalámbricos y al no ser un formato de contenedor que se lleve muy bien con los errores y la corrupción si el proceso se interrumpiera por algún motivo se tendría que reiniciar, lo cual es terriblemente engorroso.

Por otro lado, si los errores ocurrieran en el momento de la grabación o almacenamiento en las tarjetas MicroSD en las cámaras, al estar seccionada la grabación, se incrementan las probabilidades de recuperar una mayor porción del proyecto original. Bueno, un poco inconveniente en algunos aspectos pero nada muy malo. Next.

Bitrate

Este sí es un problema, aunque uno de esos que no está tan mal tener. A ver, no tendría por qué ser un problema, yo entiendo que mientras más grande sea el archivo, lo más probable es que más información contenga el video y sea mejor cuando se trate de editar, pero creo que en este caso los archivos masivos no son de demasiada ayuda.
Con un sensor de 1/2.3 pulgadas, la cámara no está capturando tanta luz (comparativamente hablando, claro está) y todo ese peso adicional viene de ¿el ruido?, no lo sé. Aún así, más información no suele caer mal, pero en este caso creo que puedo deshacerme de unos cuantos bytes sin sacrificar mucha calidad de imagen. Por lo menos es la ida.

Con eso en mente, la tasa de ~36 GB por hora (80000 Kbps) es un innecesariamente alta para videos caseros o personales que seguramente querríamos subir a redes sociales, con esas tasas de bits demoraremos mucho en hacer cualquier cosa con los videos, ya sea editarlos, subirlos a alguna nube o simplemente moverlos a un disco externo. Es aquí donde entra FFmpeg al juego.

FFmpeg (pronunciado /‘ɛfɛfɛm’pɛɡ/ 😉), me ayudó a reducir el tamaño de los archivos sin reducir su calidad de forma muy apreciable. Estos son los parámetros que usé:

ffmpeg -hide_banner -loglevel error -hwaccel qsv -c:v h264_qsv -i {input} -c:v h264_qsv -global_quality 25 {output}

• -hide_banner previene la impresión de cosas como el banner, cosas del copyright y opciones con las que fue compilada la librería, datos que son de poco uso la mayoría de veces.
• -loglevel error muestra todos los errores.
• -hwaccel qsv hace uso de los codificadores de hardware de los procesadores Intel Quick Sync Video (qsv) que aceleran el proceso significativamente.
• -c:v h264_qsv especifica el códec que vamos a usar, uso h.264 por compatibilidad.
• -global_quality 25 establece el nivel de calidad que obtendremos, mientras menos sea ese número, mayor será la calidad, la idea es tener un equilibrio y 25 está bastante bien para la reducción.

El resultado es bastante prometedor, los videos se reducen de alrededor de 4 GB a unos nada despreciables ~850 MB, una reducción de hasta el 80%.

Imágenes comprimidas para mejorar el rendimiento de la página. Aquí y aquí se pueden encontrar los archivos originales.

Pero no confíen simplemente en mis (o sus) ojos, existen algoritmos de comparación de imágenes y videos como VMAF, que desarrolló Netflix, o SSIM, desarrollado en universidades de Estados Unidos, que pueden ayudarnos a tomar decisiones sobre cuáles son los mejores parámetros de codificación para nuestros videos según las necesidades.

Por ahora elegiré SSIM debido a que para usar el algoritmo de Netflix (por cierto, recomiendo visitar su blog técnico de vez en cuando) es necesario completar un par de pasos con anterioridad, como convertirlos al espacio de color YUV, por ejemplo. La flojera me gana en estos momentos.

SSIM, el índice de similitud estructural, funciona simulando la percepción que tendría un ser humano sobre dos imágenes y su similitud, incluyendo aspectos como la luminosidad y el contraste. Hay más de una forma de calcularlo, yo opté por usar FFmpeg que lo trae incluido de “fábrica”:

ffmpeg.exe -i {input1} -i {input2} -lavfi ssim=stats_file={output} -f null -

Este comando nos devuelve un archivo largo en donde podemos ver la comparación entre cada uno de los fotogramas de los dos videos, dándonos un valor general y valores parciales por los tres componentes del espacio YUV (parece que no había que convertir los videos antes de usar VMAF después de todo 😛).

Tiene una estructura similar a esta:

Al hacer un pequeño análisis estadístico de los resultados tanto para valores de 24 como de 25 para la configuración -global_quality del comando usado para reducir la calidad, 24 gana por poco, un margen que me pareció aceptable. Esta corta distancia numérica, sumado a que en nivel 25 el cambio no era drástico comparado con la reducción de tamaño me hizo ratificar mi decisión.

Aquí unos cuantos números cortesía de CalculatorSoup (Wolfram Alpha no pudo con tanta data en su versión gratuita ☹️) del promedio de similitud de fotogramas entre videos, así como la desviación estándar de los valores. A mayor promedio y menos desviación estándar (σ), mejor.

Teniendo en cuenta que, en general, un valor de MSSIM (SSIM promedio) mayor o igual a 0.99 significa que dos imágenes o videos son indistinguibles (Sec. 4.1 Luminance), los valores resultantes parecen satisfactorios.

Por un lado, con calidad 24, la más alta de las dos, tenemos un promedio de 0.9862 con un σ de 0.0084. Esto significa que, según la fórmula de arriba, el ~95% del tiempo los videos tienen un nivel de similitud de entre 96.94% y 100% y que más del 99% del tiempo ese nivel está entre 96.1% y 100%. Además, en promedio son 98.62% similares. Bastante bien.

Por el otro, con calidad 25, el promedio es de 0.9844 con un σ de 0.0109, lo cual significa que el ~95% del tiempo los videos tienen un nivel de similitud de entre 96.26% y 100% y que más del 99% del tiempo ese nivel está entre 95.17% y 100%. Además, en promedio son 98.44% similares.

Parece un precio justo a pagar en términos de calidad por ahorrar varios bytes aquí y allá.

¿Fue innecesario todo esto? Muy probablemente, pero me hacía ilusión tener números respaldando o desaprobando mi decisión; felizmente, sucedió algo más cercano a lo primero.

GPS

Me di cuenta de la falta de información de geolocalización de los videos al añadirlos a Immich, en donde se indica en un mapa en dónde fueron capturados si tienen los metadatos disponibles. Lo bueno es que cuenta con un editor de metadatos, el cual usé para guardar las coordenadas del punto de inicio de cada video; tuve que verlos y contrastar con Google Maps para poder ubicarlos exactamente.
Una vez geolocalizados los videos, Immich creó archivos Exif externos correspondientes a cada uno de los videos, todos ellos compartían el nombre con su contraparte videográfica aunque con una extensión distinta: xmp.

Hasta ahí todo bien, si bien en este caso los metadatos Exif son externos, al tener el mismo nombre de archivo pueden ser recogidos por diversos reproductores de video, no debería ser un problema; sin embargo, yo quería que estuvieran todos los datos en los mismos videos, es más fácil organizarlos de esa forma.

Usé ExifTool para solucionarlo:

exiftool -gpsposition -c "%.7f" {input}

• -gpsposition -c "%.7f" extrae los datos de geolocalización en el formato “%.7f”, que es un número entero con siete cifras decimales (ej. -31.8267316).

exiftool -TagsFromFile {input} -All:All -XMP -ExtractEmbedded -overwrite_original {output}

• -TagsFromFile ayuda a tomar las etiquetas Exif guardadas en los archivos que creó Immich previamente.
• -All:All indica a la herramienta tomar en cuenta todas las etiquetas Exif que pueda.
• -XMP lo mismo que lo anterior pero con etiquetas XMP, que suelen ser metadatos no estándar definidos por cada fabricante de cámaras o desarrollador de software de video.

Había un pequeñísimo problema adicional, desgraciadamente: al parecer, las cámaras DJI necesitan conectarse a un teléfono o tablet por Bluetooth después de haber estado desconectadas por mucho tiempo para poder obtener la fecha y hora adecuadas. Esta característica causó que la hora de mis videos estuviera atrasada unos 90 minutos. No sé la cantidad exacta de minutos porque no tenía una buena referencia más que una grabación que hice con mi teléfono, así que calculo que debo tener un error de 3 minutos como máximo. Aceptable.

Tenía que cambiar esas horas en los archivos y en las etiquetas Exif, ya que si sólo lo hacía con los archivos, reproductores de video que leen dichas etiquetas mostrarían mal las marcas de tiempo y software de organización de medios, como Immich, no colocarían de forma adecuada los videos en las líneas de tiempo.

Cambiar de fecha los archivos era simple. En Windows (PowerShell) sería más o menos así:

(Get-Item {input}).LastWriteTime = {new_date}

No olvidar que new_date debe tener el formato correcto, en este caso opté por MM/dd/yyyy HH:mm ya que fue el que funcionó en mis pruebas en mi instalación de Windows.

(estamos cerca)

Peeeeero la intención era quitarle 90 minutos al tiempo de creación/modificación actual de los archivos, así que tuve que extraer y restar. Lo bueno es que es una operación no destructiva, así que se podía dejar para el último paso una vez que los procesos de FFmpeg y ExifTool hubieran culminado.

Una cosita antes de tener el script completo: cuando se trata de etiquetas exif, por lo menos en mi caso, la zona horaria de las marcas de tiempo siempre era UTC y estaban en el formato yyyy-MM-dd HH:mm:ss, así que había que tener eso en cuenta para ese paso, mas no para el cambio de hora de los archivos en sí.

Bueno, con todo eso en cuenta y algunas cosas más, el script terminaría luciendo así (y ahora con versión bash incluida):

$originals_path = {originals_path}
$processed_path = {processed_path}

Get-ChildItem $originals_path -Filter *.mp4 | Sort-Object -Property Name | Foreach-Object{
    ""
    "Original file: $($_.Fullname)"
    "Reducing video bitrate"
    ""
    ""

    ffmpeg -hide_banner -loglevel error -hwaccel qsv -c:v h264_qsv -i $_.Fullname -c:v h264_qsv -global_quality 25 {original_file}

    # qs stands for Quick Sync
    $qs_file = (Get-Item "$processed_path\$($_.Basename).mp4")

    "Bitrate-reduced file: $($qs_file.Fullname)"
    ""
    
    # Get the current creation datetime (wrong creation date)
    $wrongCreationDateTime = "{0:yyyy-MM-dd HH:mm}" -f $($_.CreationTime)

    # Get the right creation datetime but in Windows format
    $rightDateTimeWindowsFormatted = [datetime]::parseexact($wrongCreationDateTime, 'yyyy-MM-dd HH:mm', $null).AddMinutes(-90).toString('MM/dd/yyyy HH:mm')

    # Get the right creation datetime but in Exif format (UTC with seconds)
    $rightDateTimeExifUTCFormattedWithSeconds = [datetime]::parseexact($rightDateTimeWindowsFormatted, 'MM/dd/yyyy HH:mm', $null).AddMinutes(300).toString('yyyy:MM:dd HH:mm:00')

    ""
    "Original file: $($_.Fullname)"
    "QS file: $($qs_file.Fullname)"
    "Wrong creation datetime: $wrongCreationDateTime"
    "Right creation datetime in Windows format: $rightDateTimeWindowsFormatted"
    "Right datetime in ExifTool UTC format with seconds: $rightDateTimeExifUTCFormattedWithSeconds"
    ""

    "ExifTool copying all tags from original..."

    exiftool -TagsFromFile $_.Fullname -All:All -XMP -ExtractEmbedded -overwrite_original $qs_file.Fullname

    # Extracting coordinates info from XMP files
    $coords = exiftool -gpsposition -c "%.7f" "$($qs_file.Fullname).xmp"
    
    ""
    $coords
    ""

    "ExifTool setting geoposition and updated timestaps..."

    exiftool "-CreateDate=$rightDateTimeExifUTCFormattedWithSeconds" `
     "-ModifyDate=$rightDateTimeExifUTCFormattedWithSeconds" `
     "-Track*Date=$rightDateTimeExifUTCFormattedWithSeconds" `
     "-Media*Date=$rightDateTimeExifUTCFormattedWithSeconds" `
     -gpsposition="$coords" `
     -overwrite_original $qs_file.Fullname

    (Get-Item $qs_file).LastWriteTime = $rightDateTimeWindowsFormatted
    ""
    ""
    "================================================================================================="
}

#!/bin/bash

$originals_path = {originals_path}
$processed_path = {processed_path}

for filename in `$originals_path/*.mp4`; do
  echo
  echo "Original file: $filename"
  echo "Reducing video bitrate"
  echo
  echo

  $qs_filename =  $"$processed_path/$(basename "$filename")"

  ffmpeg -hide_banner -loglevel error -hwaccel qsv -c:v h264_qsv -i $filename -c:v h264_qsv -global_quality 25 $qs_filename

  echo "Bitrate-reduced file: $qs_filename"
  echo

  $wrong_datetime = $(date -r "$filename" +"%F %H:%M")
  $right_datetime = $(date -d ""$wrong_datetime"  90 minutes" +"%F %H:%M")
  $right_datetime_exif_utc_w_seconds = $(date -d ""$right_datetime"  300 minutes" +"%F %H:%M:%S")

  echo
  echo "Original file: $filename"
  echo "QS file: $qs_filename"
  echo "Wrong creation datetime: $wrong_datetime"
  echo "Right datetime: $right_datetime"
  echo "Right datetime in ExifTool UTC format with seconds: $right_datetime_exif_utc_w_seconds"
  echo

  echo "ExifTool copying all tags from original..."

  exiftool -TagsFromFile $filename -All:All -XMP -ExtractEmbedded -overwrite_original $qs_filename

  $coords = exiftool -gpsposition -c "%.7f" "$qs_filename.xmp"

  echo
  echo $coords
  echo

  echo "ExifTool setting geoposition and updated timestaps..."

  exiftool "-CreateDate=$right_datetime_exif_utc_w_seconds" \
          "-ModifyDate=$right_datetime_exif_utc_w_seconds" \
          "-Track*Date=$right_datetime_exif_utc_w_seconds" \
          "-Media*Date=$right_datetime_exif_utc_w_seconds" \
          -gpsposition="$coords" -overwrite_original $qs_filename

  touch -d "$right_datetime" $qs_filename

  echo
  echo
  echo "================================================================================================="
done

Para ir terminando

Todo este proceso me dejó con videos de mucho menor tamaño, con la información correcta sobre en dónde fueron capturados y con archivos con las fechas y horas correctas. Pasamos del panorama de la imagen de portada de este artículo a esto:

De esta forma es más fácil editarlos, transmitirlos o simplemente reproducirlos.

Yo sé que mientras más información haya en un video, más flexibilidad otorgará al momento de ser procesado; al fin y al cabo, las computadoras no pueden mágicamente inventar información prácticamente de la nada. ¿O sí? Es por eso que quizás termine usando todos los fragmentos originales para juntarlos y formar un video largo al que después pueda aplicar todo lo aprendido aquí para terminar con un archivo razonablemente pesado.

Lo importante es que si hubo aprendizaje no fue una pérdida de tiempo, aunque el tiempo invertido en geolocalizar cada fragmento por separado difícilmente sea recompensado, a menos que pueda generar una suerte de ruta descrita por las coordenadas para luego animar un mapa con mi recorrido en tiempo real y superponerlo al video o algo por el estilo.

Quién sabe. 😉

¿Por qué no Premiere, Resolve o simplemente Movie Maker?

Bueno, me parece que FFmpeg es no sólo más versátil si no también más divertido de usar cuando se trabaja con varios archivos a la vez and cuando no se sabe bien qué hacer, es una herramienta que permite la experimentación casi extrema. Además, esto se trata de obtener diversión mientras se resuelven problemas; hasta cierto punto, claro.
Obviamente, es también más difícil que usar Resolve, que uso típicamente, pero a veces me siento más cómodo en la terminal y la iba a usar de todas formas debido a ExifTool.
Además, en esta casa se usa FFmpeg, es gratuito y de código abierto y permite usar la tarjeta de video para la codificación; aparte, tiene una comunidad enorme.

Usaré Resolve para la corrección del color, creo que no quiero tener que lidiar con FFmpeg cuando se trate de usar LUTs. 😔

Para algún día

• Mejorar el código, seguramente se puede optimizar y no hacer dos llamadas a ExifTool, ya que es una operación destructiva y consume bastante tiempo. Aparte, no es el código más lindo del mundo.
• Darle un poco de color al video, está un poco feo así.
• Recordar enlazar las cámaras a un teléfono antes de grabar para evitar desfases temporales.