Archivo del autor

Vuelve a pasar, “un carácter de la muerte” vuelve a los equipos de Apple

Share on Google+Share on FacebookTweet about this on Twitter

Para quien no esté al corriente de otras ocasiones, digamos que actualmente cualquier dispositivo de Apple (iOS o MacOS) por actualizado que esté (excepto versiones betas) provocará el cierre/bloqueo de la aplicación si esta tiene que renderizar un carácter concreto. En este caso es un carácter Telegu, un dialecto Indio: జ్ఞ‌ా

Sí, eso significa que incluso este mismo post producirá el bloqueo/cierre de la aplicación que lo abra en los dispositivos de Apple. Pero esto no es nuevo. Hace ya algunos años pudimos ver algo similar, aunque en aquella ocasión era más bien una cadena de texto: “سمَـَّوُوُحخ ̷̴̐خ ̷̴̐خ ̷̴̐خ امارتيخ ̷̴̐خ”. Ya en su día escribí un pequeño artículo al respecto:

La Cadena de la Muerte

La historia es la misma, de echo todo lo que puse en ese post se podría volver a poner aquí. La única salvedad es que en esta ocasión es un carácter, en vez de una pequeña cadena.

Vemos fallos de seguridad y bugs a diario, nadie se salva de ellos. La mayoría no suelen tener una gran transcendencia por grave que sean debido a que explotarlos es algo complicado. Es aquí donde este tipo de errores alcanza una importancia capital, aunque sea algo inocuo y que no afecte demasiado. Es decir, para que un fallo de seguridad o un bug sea realmente importante se deben de dar una de estas dos premisas: O que el grado de peligrosidad, a lo que afecta, sea enorme aunque sea muy complicado usarlo, o que con independencia de lo peligroso que sea, sea extremadamente sencillo disparar el fallo.

Algo similar vimos hace poco cuando se descubrió que cualquier usuario de MacOS podía resetear la contraseña de administrador de forma extremadamente sencilla, sin conocerla, sin tener los credenciales necesarios. En dicho caso, la peligrosidad, al margen del efecto logrado, es que era algo tan simple como hacer clic dos veces en un botón.

Vivimos ahora mismo en el mundo de las comunicaciones. Es más, la mayoría que lea este artículo lo hará posiblemente desde un teléfono. La mayoría del tiempo que pasamos con nuestros dispositivos es usando aplicaciones de mensajería instantánea, redes sociales, webs… es decir, precisamente los vectores por donde cualquiera, repito cualquiera, podría usar dicho carácter. Muchos podrán pensar que bueno, es cuanto menos “divertido” pero realmente no tiene mucha importancia, quien ha visto alguna vez ese carácter, y que en nuestros círculos no va a suceder. El problema es que mientras que Apple lance la actualización o no, y más sitios se hagan eco, más copias de dicho carácter veremos, en todos lados.

Usas WhatsApp?? No importa, como alguien lo use de esto, los usuarios de iOS que lo tengan a él en la agenda y vea la lista de estos no podrán abrirlo. Y en grupos?? Prueba y verás la gracia. No es peligroso desde el punto de vista que no van a robarte información ni acceder a ella, ni van a producir un daño a tu dispositivo irreparable, ese no es el problema. El problema es que sencillamente cualquiera puede dejarte inutilizada la mayoría de aplicaciones que se usan a día de hoy, ya sea por diversión, a modo de prueba…

Actualmente, como he dicho, no hay solución. Sólo la versión Beta de iOS última parece solucionarlo. Pasarán posiblemente días o alguna semana antes de que Apple lance una actualización formal. Quien use Apple, no puede protegerse de otro modo, en todo caso actuar si se ha recibido el carácter o hay sospecha de ello. Dependiendo del medio, tendrá que realizar diferentes acciones. Así por ejemplo si el carácter lo recibió por Safari al acceder a una web, tendrá que evitar dicha dirección, e incluso a lo mejor necesario eliminar del historial la página. Si es por WhatsApp en un estado, eliminar a dicho contacto, si es en un mensaje, eliminar dicho mensaje o incluso es muy posible que eliminar el historial de dicho contacto, o todo el historial… etc etc etc.

Así que amigos manzaneros, cuidado, si estos días el terminal se bloquea en algunas aplicaciones, cierres forzados de estas, congelaciones… puede ser que algún bromista (me declaro culpable de serlo también) esté causando estragos en tu dispositivo. Pero antes de las consabidas críticas, tener presente algo: No justifico en modo alguno quien lo haga de forma lesiva o para molestar o producir mal a otros, pero en el peor de los casos pensar que es como darle un caramelo a un niño pequeño, si se lo das se lo va a comer, lo que tendría que tener más cuidado Apple (o los padres) es que estos escenarios no vuelvan a producirse, que con este ya son 3-4 las veces que ha sucedido.

¿Y por qué sucede? Es por el modo que Apple renderiza las fuentes. Mientras no se cambien o al menos modifiquen como interacciona con el sistema, es muy posible que antes o después vuelva a aparecer otro “carácter” o frase o… y que la historia, de nuevo, vuelva a repetirse.

Saludos.

Cómo me “enamoré” de Xiaomi

Share on Google+Share on FacebookTweet about this on Twitter

No hay demasiadas “actitudes” que me den más pena que el fanatismo que existe a día de hoy; prácticamente sobre cualquier cosa. Siempre he creído que se puede ser fan de cualquier cosa, pero hay que tener cuidado de no convertirse en un fanático. Para mi la diferencia radica en que el fanático se deja llevar ya no sólo de un modo desmedido, sino sin atener a razones, motivos, números, explicaciones… Cuantos fanáticos conocemos, adoradores de alguna marca, que año tras año, y como si fuese un sectarismo, se acude a la misma por razones que por lo general son en el mejor de los casos vagas, sin sostenerse (las razones), dejándose llevar por el marketing o las opiniones del de al lado, y no mirando las verdaderas necesidades que uno pueda tener.

Antes que nada, y para evitar aquellos mal pensados, quiero dejar claro que jamás he recibido hasta la fecha un sólo céntimo (ni directa ni indirectamente) por parte de Xiaomi, ni regalías ni favores. Todo lo que expongo a continuación es mi mera opinión basada en estos últimos años. Como he hecho otras veces, antes que Xiaomi, cuando una compañía hace las cosas bien, creo que también hay que decirlo. Repito, es mi experiencia, estoy seguro que no habrá sido la misma para todos, y por supuesto respetando a cualquiera que pueda tener otra idea de ello.

 

Dejadme, a modo introductorio, contaros una historia

Aun a día de hoy hay quienes dicen que soy demasiado crítico con algunas empresas/marcas, especialmente con Apple. Bueno, para quien no lo sepa, mi blog original lo creé porque estaba cansado de aguantar algunas censuras y restricciones que tenía en, no recuerdo ya siquiera cual fue, foro precisamente sobre iPod Touch/iPhone. Puedo decir que adquirí el mío mucho antes de que se comercializasen aquí en España, y como me ha pasado siempre, empecé a destriparlo todo lo que pude, y a estudiarlo. Pero iPhone no era lo que es hoy, ni tampoco Apple. Lo más gracioso de todo es que la inmensa mayoría le da el éxito de los terminales actuales a Apple, y la historia es bien diferente, al menos para los que la conocen. Por aquel entonces no podía instalarse absolutamente nada en el dispositivo, no había una AppStore, no había SDK para crear aplicaciones, no había nada. El iPod Touch era un iPod de nueva generación con gran pantalla y táctil, y el iPhone lo mismo pero con posibilidad de realizar llamadas. Tampoco fue un gran shock, y habría quedado ahí si no fuese por los verdaderos autores del “boom”.

¿Que sucedió? que un buen día se logró de forma “sencilla” acceder como root al terminal, y ahí empezó todo. La curiosidad permitió crear aplicaciones nativas simples como servidores SSH, pequeñas utilidades… y poco a poco gracias a ingeniería inversa y la dedicación de la comunidad, aplicaciones con interfaz propia. Ya no sólo podíamos hacer llamadas y tener un teléfono que realmente poco o nada nos daba en comparación a la competencia, ahora podíamos instalar algunas utilidades extras, muy útil e interesante desde el punto de vista de los amantes en tecnología. Y entonces apareció él, para mí siempre será el “padre” de los móviles de hoy en día,  y no precisamente porque se dedicase a fabricar hardware, sino porque fue quien logró que se pusiese la maquinaría que hoy nos lleva aquí: Jay Freeman, conocido como Saurik. Saurik no sólo permitió/colaboró los primeros Jailbreak en iPhone/iPodTouch, sino que fue el creador de Cydia. Cydia fue/es un gestor de paquetes que creó para estos dispositivos, de modo que ahora los amantes de esta plataforma podían tener un lugar centralizado donde acceder a aplicaciones creadas en su integridad por la comunidad. Tan sólo tenías que añadir repositorios a Cydia, y este, al más puro estilo Linux/Unix accedía a ellos, listaba los paquetes disponibles y permitía instalarlos. Cydia era más que un gestor de paquetes, por debajo había todo un Framework para permitirlo. Pasaron muchos meses y años, y Cydia no paraba de crecer, donde se podían encontrar aplicaciones de pago incluso. Hasta que los de Cupertino quisieron enriquecerse a su costa.

Aquí empezó mi rechazo a Apple, sus políticas. Apple “copió” lo que era Cydia, para crear su propia tienda de aplicaciones. Entonces, hasta hoy, empezaron a jugar al ratón y al gato para poner cada vez más complicada la posibilidad de hacer Jailbreak, y con los años mataron, como es natural, Cydia. Lo triste de todo es que la AppStore no fue más que “el “trabajo robado” de toda una comunidad y de una plataforma totalmente abierta. Apple lanzaría su SDK, su AppStore, en paralelo ya corría Android y bueno… el resto lo conocemos más o menos todos. Así que podéis creerme, no me caso con nadie. Yo mismo creé mi propio repositorio para Cydia y algunos parches para iPod Touch/iPhone en su día, viví todo aquello.

Desde que existe el teléfono móvil, he pasado por todo tipo de dispositivos. Mi primer terminal fue el gran Alcatel One Touch Easy, me arriesgo a decir que el terminal más resistente que jamás se ha creado. De allí creo recordar que salté a Sony / Ericsson: T20e, T610i, K700, K610, W760 y C905. Luego iPhone 1G, luego HTC, Samsung, LG, y ahora Xiaomi. ¿Por qué todo esto? Bueno, como he dicho para alejar fanatismos, los tiempos cambian, las empresas y sus productos también, e incluso las propias necesidades lo hacen… pero siempre motivadas (las necesidades) por uno mismo, no por terceros.

En cualquier caso, esto no va de móviles siquiera, sino de una compañía en concreto, Xiaomi. Quizás el panorama del teléfono Móvil es el más significativo, pero no escribo un artículo para expresar lo contento o descontento que estoy de mi terminal, sino por la increíble escalada que ha dado esta compañía, podríamos decir que incluso mes a mes.

 

Xiaomi

La empresa se fundó en el 2010, aunque no sería hasta 2012/2013 en el que empecé a escuchar algo de ella. Fue la partida de Google del gran Hubo Barra (para tomar la vicepresidencia en Xiaomi) cuando empecé a indagar y echar un ojo en serio a lo que esta empresa estaba haciendo. Recordemos que de esto hace tan sólo un suspiro, y más cuando hablamos de empresas tecnológicas… y la proyección que ha tenido desde entonces.

En lo personal creo que el gran éxito de Xiaomi se ha debido a 3 factores fundamentales: Inmejorable oferta relación prestaciones/precio, gran soporte continuado en el tiempo, y filosofía de software por lo general abierta (y escuchando al usuario.). Podemos decir que a día de hoy es una de las empresas que mejor ha sabido leer realmente al usuario, no fabricando dispositivos destinados a vendérselos “a la fuerza” los necesiten o no los usuarios, sino mirando sobre todo a lo práctico.

 

Dispositivos

Mi primer gadget Xiaomi fue su Router Mi WIFI Mini. Buscaba un repetidor WIFI sin demasiadas pretensiones, así que empecé por los últimos que había adquirido para terceras personas (amigos, familiares y otros). TP-Link o D-Link habían sido anteriormente mis opciones, equipos baratos, funcionales y baratos, en una horquilla de los 20-30€. Y me topé con Mi Wifi Mini. Más o menos por el mismo precio de un AP 802.11n de 2 streams, tenía un Router completamente funcional, 802.11ac de 2 streams y posibilidad de poder usarse como AP/Repetidor/Router. Que diablos, pensé, no puede funcionar bien en la vida; ¿por el mismo precio que un AP sencillo tengo un hardware que en la competencia podría costar dos o tres veces más?. Un par de semanas después lo tenía en casa. Sólo diré sobre su funcionamiento/rendimiento que poco después compraría otro para otro allegado, y algo más adelante compraría su hermano mayor Mi WIFI R3. La experiencia fue inmejorable, y eso sin contar que incluso estética fue una gran sorpresa… para bien.

Mi segunda experiencia vino con unos auriculares/manos libre, específicamente Xiaomi Earbuds Sports Bluetooth.  Buscaba unos auriculares principalmente para música, sin cables y tipo earplugs. Me pasó lo mismo, después de mucho buscar las alternativas viables dentro del mercado “convencional” se iban a más del doble. De nuevo, un gran resultado. Muy poco después y casi paralelamente le tocaría el turno a un altavoz Bluetooth, Mi Bluetooth Speaker, que aunque originalmente estaba destinado a otros menesteres, terminó formando parte del elenco, buen audio, salida auxiliar, micro y tarjeta SD… de nuevo un gran precio.

Los productos de Xiaomi se disparaban, empecé a recomendar a mi entorno gadgets y móviles Xiaomi: Mi5, Mi5s, Redmi 4/4x… y después de esperar durante meses a un eventual lanzamiento en España del Google Pixel, me decanté después de mucho pensarlo por mi Xiaomi Mi 6… y no me arrepiento. Lo mejor de todo es que jamás he comprado por marca, siempre que necesito cualquier cosa lo primero que hago es ver realmente mis necesidades, me informo de lo que tengo en el mercado, mido todos los pros y contras y tomo la decisión. Y la decisión, cada vez más común en estos años, ha sido terminar acudiendo a Xiaomi. Esto mismo me pasó buscando un trípode para móviles y cámaras compactas/de acción, de nuevo, sin siquiera saber que existía, terminé adquiriendo un Xiaomi Selfie Stick, un buen mini-trípode, extensor, gran diseño, materiales y botón BT remoto.

A día de hoy tendríamos que sumar a la lista para terminarla (de momento), la cámara de acción Xiaomi Mijia 4K y la cámara Xiaomi 360º Sphere.

No soy un novato en la tecnología, no soy un usuario “medio”. Por lo general requiero de prestaciones por encima de la media, una fiabilidad importante. Es posible que los productos de Xiaomi no logren nunca alcanzar el top 1 dentro de su categoría, pues no nos engañemos, hay dispositivos muy superiores prácticamente en todas sus categorías, que podemos encontrar en el mercado. ¿Es el Mi A1 el mejor terminal del 2017? ¿Es el Mi Wifi Mini el mejor Router AC? ¿Es la cámara de acción Mijia 4K la mejor? No, posiblemente no. Casi con toda seguridad el Galaxy S8 es mejor terminal, un ASUS AC-3200 es mejor Router, y una GoPro Hero 6 mejor cámara. La cuestión no es esa, la cuestión es la gran calidad y prestaciones que obtenemos por su precio.

La cuestión es que por 200€ podemos adquirir un Xiaomi A1, un terminal de gama media-alta con la mayoría de todos los avances actuales dentro de los terminales móviles. Hace nada una persona muy cercana (usuaria siempre de iPhone) me comentaba que iba a comprarse el iPhone X. Gran compra le dije, si es que estás dispuesta a gastarte 1200€, y más importante, te compensa. Pero, ¿es que no tiene mejor cámara? ¿es que no tiene reconocimiento facial? ¿es que..??, sí, por supuesto, el iPhone X es mejor terminal que el Xiaomi A1, el problema no es ese… el problema es que para una persona normal, y con normal me refiero a más del 95% de la población, no van a notar en el día a día una mejora significativa. La cuestión es sencilla, por el precio que compras un iPhone X de Apple, puedes llevarte a casa 6 Xiaomi Mi A1. Ahí radica el éxito de Xiaomi, eso es lo que hace grande sus dispositivos. De forma similar, no dudo que una GoPro sea mejor en números que una Mijia 4K o incluso que la Yi… la cuestión es que por el precio de la GoPro puedes adquirir varias Mijia 4K, y os puedo asegurar que no tiene mucho que envidiarle.

¿Como ha logrado Xiaomi esto? ¿Donde está la trampa? Bien, hay dos factores importantes. El primero, y todo hay que decirlo, es que por lo general adquirimos sus productos en retailers extranjeros, ya sea GearBest, GeekBuying y tantos otros, y eso exime el pago de impuestos… siempre y cuando por supuesto estemos dispuestos a arriesgarnos a Aduanas, a no tener garantía… Pero existe un segundo factor mucho más importante. El primero lo es, pero recordemos que en España ya es posible adquirir algunas cosillas oficialmente en su tienda, y aunque los preciso son más inflados, aun compensa y mucho. El segundo factor de peso es, como dije anteriormente, han sabido leer realmente que necesita el usuario, sin maquillaje, y esto me gustaría extenderlo un poco más.

Por desgracia, la inmensa mayoría vive presa del consumismo, de los números, víctima del marketing barato. Hemos visto móviles que en su letra grande enseñan que poseen pantallas 4K, 128GB/256BG de almacenamiento, cámara de XMP… números, números y números, cuando la mayoría de ellos (sin dejar de ser ciertos ojo) realmente no tienen ningún impacto en el usuario de forma práctica. Es muy sencillo, un panel 4K para un móvil de 5-6 pulgadas es totalmente absurdo!! El ojo humano es incapaz de percibir más de 300dpi, cosa que se alcanza y de sobra con un panel FullHD, y consumiendo por cierto mucha menos batería. Lo mismo podemos decir del resto de la mayoría de las características que nos suelen poner en grande… ¿¿de verdad alguien necesita 256GB en el móvil?? Señores mi terminal es de 64GB, y después de unos 9 meses de uso tengo libre más de 50GB, y lo único que es verdad que hago cada cierto tiempo, y por seguridad, es vaciar fotos/vídeos, sin contar que sigo teniendo acceso a ello por Google Photos.

No nos engañemos, incluso los usuarios que podemos llamar de perfil avanzado no necesitan lo que les venden. Y este es el éxito de Xiaomi. No te voy a poner pantallas 4K que encarecen enormemente el producto y que además no sirve absolutamente para nada, te sobra con una FullHD, y a cambio te cuesta a lo mejor 100€ menos. La mayoría no juega constantemente, puede que determinado rango de edades, pero para la mayoría no es necesario tampoco el SoC más potente, ¿por qué no usar un buen SoC, fiable pero más barato? Qcom está haciendo un trabajo sensacional en la gama media. Y esto es aplicable no sólo a los móviles, sino a cualquier producto que vemos. No te venden el dispositivo más rápido, ni el más bonito, ni el más novedoso… te venden por lo general lo más equilibrado y a un gran precio.

 

Soporte

Para mi el soporte de un producto es esencial, por no decir que es de lo más importante cuando adquiero prácticamente cualquier gadget. He tenido malas experiencias en el pasado, y continúo criticando duramente a aquellas compañías que después de lanzar un producto lo abandonan a su olvido. Hay que ser también realistas, no podemos pretender que algo tenga un soporte de por vida. Supongo que en este punto es complicado llegar a estar alguna vez satisfechos, siempre querríamos ver como lo que hemos adquirido lo mantienen con mimo pese la suma de años. Pero las cosas no funcionan así, y ya sea por falta de presupuesto, por mala gestión, o sencillamente porque muchas empresas tan sólo les importa el vender y sacar nuevos productos, rara vez encontramos que un producto tiene un soporte de más de 1-2 años.

Obviamente muchos dispositivos no requieren de un soporte siquiera, quitando la garantía y en todo caso algún recambio. El problema viene cuando hablamos de un soporte por parte del Software que lo sustenta. Ya sean en forma de Bios/Firmware, Aplicaciones que los gestionan/manipulan, el propio software que los gobierna… posiblemente de nuevo lo más indicativo es si miramos los teléfonos móviles, pero para nada es algo específico de ellos, a día de hoy prácticamente la totalidad de los dispositivos tecnológicos que usamos son actualizables directa o indirectamente: PCs, Móviles, Routers, Cámaras, Altavoces, TVs, TV Boxs, Monitores, Drones… y repito sin contar las cientos de aplicaciones que tenemos para interaccionar con el hardware. Es importante, para mi esencial, que las políticas de soporte de los dispositivos que tengo son cuanto menos decentes. Para mí es imperativo que si mañana descubren un fallo de seguridad grabe en los Routers ASUS, en cuestión de días voy a tener disponible una versión nueva o un fix para ello. Y ya no sólo nos limitamos a problemas que puedan tener nuestros dispositivos a nivel de seguridad, sino que un buen soporte te va a brindar también mejoras importantes en el mismo dispositivo, correcciones de fallos, nuevas funcionalidades, más versatilidad… etc etc etc.

Hay muy pocas compañías que, en cuanto a soporte se refiere, podamos darle una nota alta. Los años por desgracia han ido poniendo en su lugar a más de una, y otras al contrario han logrado demostrar que sí respondían. Ejemplo de compañía que por lo general aprobaría con buena nota sería ASUS, Routers que pese a bastantes años después, siguen teniendo un soporte activo con actualizaciones no sólo de seguridad sino implementando y mejorando el software… y similar podemos decir como mayor fabricante de placas del mundo, actualizaciones de Bios generalmente extendidas bastante en el tiempo. Apple en el pasado también lo fue, un gran soporte sostenido en el tiempo, pero los últimos 10 años han demostrado todo lo contrario, gran decepción… el último fiasco, merecedor por cierto de un artículo exclusivo de ello, fue hace nada, cuando se descubrió que Apple en sus actualizaciones intencionadamente bloqueaba el uso de algunos procesadores a sus terminales de más de 2 años, produciendo que sus usuarios notasen un decremento de rendimiento actualización tras actualización, para que pensasen que su dispositivo estaba ya viejo y se viesen “obligados” a adquirir otro modelo nuevo (ni que decir tiene que los han demandado por todos lados). Samsung y Sony aprueban, lo cierto es que aunque quizás no con la mejor nota han logrado mantener un compromiso más o menos aceptable, lo cual se agradece teniendo en cuenta el pasado, han aprendido, espero, deseo que con el tiempo sigan mejorando. Google aprueba por pelos en cuanto a sus propios dispositivos Android, no así con sus aplicaciones/software, el cual aprueba con muy buena nota, pero teniendo en cuenta precisamente como son, tienen mucho margen de mejora. En fin… no vamos a detallar una a una las empresas, sería imposible…

El caso de Xiaomi es cuanto menos espectacular. Desde mi experiencia por supuesto, os diré que mi Router Mini/R3, tan barato, tan mono, tan… creo que salió al mercado sobre 2013/2014, pero es que después de más de 4 años está en mejor forma que nunca, actualizaciones habituales donde no sólo no solucionan problemas, sino que no dejan de mejorar el software e implementar cosillas nuevas. Cuando lo adquirí hasta la fecha, puedo hacer una larga lista de mejoras importantes.

Pero podemos mirar también a su división de móviles, en muchos casos superando incluso los 4 años de actualizaciones. En este punto hay que decir que es cierto que no siempre actualizando el código base de Android, pero al menos sí parches de seguridad y funcionalidades añadidas a través de MIUI, que a lo mejor no es la mejor capa de personalización (en lo personal la odio), pero es verdad que ha logrado llevar funciones interesantes a todo tipo de terminales. No todos sus terminales han tenido la misma suerte, pero aquellos que han sido mejor acogidos, han tenido un soporte bastante largo, muy lejos del año y medio al que parece que nos han acostumbrado.

 

Cercanía con el usuario y “apertura” a ellos

Esto es algo que me ha sorprendido. No es algo que me hubiese esperado de una compañía como Xiaomi. Es cierto que encontramos muchas otras que en este aspecto son sobresalientes, pero es mucho más sencillo para las grandes estar a la altura en este punto, como es el caso de Google. Quizás el título de esta parte no es muy auto aclaratorio… lo que quiero indicar es la importancia del trato directo de la compañía, que escucha al usuario, que se preocupa más de dar libertades al usuario que coartarlas. Google fue de los primeros que nos enseñó el valor de esto en muchos aspectos… fue Google con su familia Nexus quien logró que los fabricantes (y más tarde los propios ISP) permitiesen desbloquear por ejemplo los bootloaders de sus dispositivos, y lo que antes era algo extremadamente raro de poder hacer (sin hacks), a día de hoy casi la totalidad de fabricantes lo permiten, sí, con ciertas restricciones y letra pequeña, pero lo permiten. Esto ha permitido una comunidad mucho mayor, diversidad, un increíble aprendizaje para muchos (entre los que me encuentro), mayor confianza… se dieron cuenta que el usuario era algo que demandaban, y poco a poco se abrió el camino. Lo mismo lo vemos en otros hardware, no es algo específico de los móviles… ASUS por ejemplo en su división para hardware de red permite sin problema el acceso completo (root) a sus dispositivos, cosa que les hace ganar muchos enteros.

De cara a Xiaomi, en este aspecto, fue de los primeros que desde el principio ha permitido el acceso completo a sus equipos, sea de forma publicitada o no… da igual si es hardware de red, teléfonos, cámaras… nunca han querido complicar al usuario o coartarle libertades. Muchos pueden ver esto como problemas de seguridad, pero a mi modo de ver el usuario es mayorcito para saber que puede o no puede hacer como hacen otras, el colmo es que algo que compro me tengan que obligar a usarlo como ellos quieran que yo lo use… yo no soy así, lo siento, y si adquiero algo quiero poder hacer con ello lo máximo posible, aunque ello implique tener funciones o prestaciones por debajo de lo preestablecido, pero es mi decisión.

En cualquier caso no sólo se trata de que nos permitan ser dueños completos de nuestros dispositivos. Es necesaria una confianza, una cercanía, el sentirse “escuchado” por la empresa, que las opiniones importan, que los problemas se solucionan, que no se tira la culpa al otro lado, que se explican las cosas, que se entona el mea culpa si es necesario, que se da la cara y se responde como dios manda cuando existe cualquier problema, tenga la importancia que tenga. Básicamente, que no te dejen con el culo al aire. Google, repito, es un gran ejemplo de esto, sus grupos de soporte son muy amplios y con una comunicación directa con ellos. Es cierto que podrían dar muchas más explicaciones de las que dan, pero por lo general no esconden la mano y responden al usuario como deben. Por supuesto siempre hablamos en términos generales.

Xiaomi hace un trabajo muy bueno… quizás no llega al punto de Google, pero es notable. Foros oficiales de reportes de fallos, grupos amplios de usuarios beta/alpha para sus software, comunicados de los propios desarrolladores, noticias, explicaciones de decisiones que toman… Y todo ello mezclado con un gran “problema” que tiene Xiaomi que no tiene prácticamente ninguna otra compañía: Todo lo que abarca.

En realidad Xiaomi opera de muy diversas formas, sabemos que tienen dispositivos de todo tipo, desde hardware de red, audio, imagen, móviles, domótica, industria textil… pero no significa que Xiaomi fabrique o desarrolle todo ello. Xiaomi funciona con diferentes filiales propias como Mijia o Yi, por ejemplo, pero también con muchas otros fabricantes externos, los cuales permiten por así decirlo ponerle el sello de Xiaomi sólo si pasan una serie de controles, de especificaciones, de calidad de… esa es la razón por la que muchos no entienden como es posible que vendan casi de todo, patinetes, robots aspiradores, bombillas, adornos, televisores, cerraduras, drones, móviles, ropa… Y os aseguro que la gran mayoría de todos sus productos son bastante recomendables si se necesitan. Bien, aunar todo eso es extremadamente complejo, como es natural la compañía principal, Xiaomi, no puede dar la cara en todo ello, es imposible, y se delega precisamente en sus filiales o en esos externos. Y pese a ello, aprueban con bastante nota.

 

Unos puntos finales

Estamos acostumbrados a escuchar de forma despectiva eso de que no deja de ser una “empresa china”. Quizás ese san benito no sea capaz de quitárselo nunca. Esto no es algo que me preocupa demasiado, es también el desconocimiento del usuario. ¿Sabéis la de veces que he escuchado decir incluso con “asco” eso de que Huawei es una marca rara china? Sí, Huawei es una compañía china, pero de pequeña, de cutre, de falta de experiencia… tiene bien poco. Que la inmensa mayoría haya empezado a escuchar de ella “recientemente” por los móviles o que sea china, poco o nada tiene que ver con lo que es Huawei, una de las compañías de telecomunicaciones más grandes del mundo, que se dice pronto, y aun me atrevería decir que una mayoría aun la tildan de “chino malo”. Cisco no es una empresa que por lo general el público medio escuche nunca, y pobre el que pueda pensar o creer que es una empresa tercermundista (y no estoy para nada malmetiendo o desprestigiando a empresas más pequeñas, sean chinas, japonesas o Españolas).

China no es lo que era. Durante muchísimos años occidente ha usado China como su base principal donde asentar sus fábricas, mano de obra barata. Durante años las empresas han puesto allí sus mejores máquinas/tecnologías, y ha pasado lo que tenía que pasar, que China a aprendido, que los materiales que salen de sus fábricas ya no es ese plástico que daba miedo tocar, no son dispositivos mecánicos que al girarlo 2 veces se partía. A día de hoy la inmensa mayoría de todos los productos tecnológicos que tenemos vienen de allí, da igual que sea una empresa china o estadounidense, las fábricas muchas veces son las mismas. Han aprendido y siguen haciéndolo, y hay que decir que son bastante eficientes en “copiar”/”adaptar” tecnología.

Xiaomi está creando soluciones muy interesantes. Por supuesto está lejos de ser perfecta, y tiene algunos grandes problemas que aun la hacen poco “accesible” para muchos. El más importante, es que no es una compañía digamos internacional. Es verdad que ha aterrizado muy recientemente en España, con un abanico de productos bastante limitados. Para la mayoría, adquirir productos de Xiaomi que no estén en la tienda oficial Española puede ser un suplicio, y un riesgo, a veces no asumible por el usuario, cosa por otro lado totalmente normal. Al no existir una venta directa en nuestro país (en mucho de sus productos) se produce también muchos problemas indirectos.

Por ejemplo, la mayoría de sus dispositivos no están preparados para trabajar todo lo bien que podrían en las bandas de frecuencias con las que funcionamos aquí. Otra cuestión habitual es la necesidad de los adaptadores de cargadores y otros, por ser diferentes los usados en China que en Europa. Manuales e incluso el propio software de muchos de sus hardware sólo lo tenemos en chino!! Mis auriculares son geniales, los llamo cariñosamente “Juanchi” (关机 – Guānjī), que es lo que dicen cuando los apago. Xiaomi no es para todos, pero está conquistando a un ritmo vertiginoso todos los mercados.

Hay que entender que al margen de todo lo demás, Xiaomi puede ofrecer gadget a los precios que los ofrece (y no solo porque muchos los compramos fuera y no se pagan impuestos) porque su margen de beneficios es mínimo por venta directa. Para poner esto en perspectiva, pensad que el margen de beneficio de Apple con la venta de iPhone X es de aproximadamente un 60%. Es decir, que de los 1200€ que el usuario paga, unos 900€ van al bolsillo directo de Apple, y el resto para costear los gastos, pese a lo que muchos puedan pensar, el elevado coste que poseen no tiene nada que ver con el hardware que poseen, es más una cuestión de política de precios. Con esto en mente, pensad ahora que el margen de beneficio de Xiaomi por gadget, a lo mejor es de un 5%. No obstante, Xiaomi recibe inyecciones económicas por otro lado, por ejemplo por publicidad, datos estadísticos y otros que generan sus dispositivos, por ejemplo MIUI tiene preinstalado lo que podríamos llamar casi malware que nos puede mostrar publicidad, y recolectan datos sobre uso y más.

Como todo, es cuestión de preferencias. Hay quienes no tienen problema alguno en gastarse 700€ en un Samsung nuevo de última generación. Otros prefieren tener unos auriculares Sony de amplio espectro y cable… He oído decir más de una vez, por desgracia, que existen marcas/compañías más modestas porque sencillamente hay gente que no tiene tanto dinero para comprar lo que ellos creen que es la mejor marca. No es broma, forma parte del fanatismo de muchos, y eso da miedo: “Compras en Xiaomi porque eres un tieso, si tuvieses pasta te comprarías un iPhone/Samsung…”. No, actualmente compro más productos Xiaomi porque son los que más se acercan a lo que necesito. No necesito el Router más rápido del mundo, ni el teléfono con mejor cámara, ni necesito un lápiz óptico, ni necesario una pantalla 4K en el móvil… soy realista. Y sí, tengo mis caprichos como poco más o menos todo el mundo, pero dentro de ellos intento siempre ser coherente, sin perder la cabeza.

El futuro, como todo, es desconocido. Esta es mi opinión de Xiaomi en este mismo momento. Mañana, dentro de un mes o de algún año el panorama puede ser totalmente diferente al que es hoy. No podemos saber si Xiaomi cambiará su modelo de negocios o sus políticas actuales. No sabemos si surgirá una nueva compañía que deslumbre y despunte, o si alguna de las ya existentes se hundirán o se elevarán hasta la cima. A lo mejor ni siquiera es así y simplemente van apareciendo muy buenos productos de modo más esparcido entre diferentes compañías, diferentes rangos de precio, finalidades… como dije al principio, he pasado por cantidad de compañías, y casi con seguridad seguiré pasando por ellas, y por otras nuevas. No sé que cual será mi próximo gadget sinceramente, y mucho menos que marca o modelo tendrá, siempre están todas las opciones encima de la mesa, y creo que es la mejor forma de “enfrentarse” a esta sociedad tan consumista que tenemos. Me da auténtica pena quien sigue creyendo que todo esto va de dinero, de status, de “clase”, de… la tecnología está para hacernos en la medida de lo posible la vida mejor y más cómoda, no para ser sus esclavos, y mucho menos para ser los esclavos consumidores de nadie.

Saludos.

¿Un fallo de seguridad en High Sierra (MacOS) permite acceso Root a cualquiera? Sí, y más simple imposible

Share on Google+Share on FacebookTweet about this on Twitter

Generalmente no suelo hacer eco de estas noticias a menos que el fallo de seguridad (o el exploit) tenga una relevancia/peligrosidad tan elevada. Y es que creo que a estas alturas el que más o el que menos (y si tiene High Sierra espero que seguro) que esté en el “mundillo” habrá escuchado las noticias por todos lados. Sinceramente, creo que nos tenemos que remontar a la famosa “Cadena de la Muerte“, en 2013, para encontrar algo tan flagrante, y en esta ocasión Apple se ha superado, lo ha logrado, nadie lo sabe bien pero lo ha conseguido, basta invocar la cuenta Root en el sistema para que este la cree en ese momento y le asigne una contraseña en blanco. Dicho de otro modo, si cualquiera se pone delante del sistema tenga la cuenta que tenga e intenta entrar/usar el usuario “root”, sin especificar ninguna contraseña, al segundo intento generalmente entra (El primero la crea, el segundo accede).

Bien, no hace falta decir que el usuario root es por lo general la cuenta/usuario maestro en casi todos los sistemas UNIX/Linux, el super administrador. Es decir, que como tal usuario tendremos acceso total al sistema. La cosa es aun peor, porque si el equipo tiene habilitados servicios de acceso remoto, la gracia se puede mascar en el aire.

No es un exploit remoto que permita ejecución arbitraria de código, es un bug en principio con alcance local, y como tal requiere acceso físico al equipo. No obstante a nadie se le escapa la gravedad del asunto. Para usuarios particulares que usen el equipo en entornos digamos de confianza o familiares o… generalmente no va a suponer un gran problema si los que nos rodean tenían acceso igualmente al equipo de forma indiscriminada, pero en entornos más empresariales, equipos portátiles que en cualquier momento puede ser “dejado” en cualquier lugar, el problema no tiene parangón.

La cosa es aun peor, y es posiblemente una de esas políticas que tanto tiempo llevo recriminando a Apple con más intensidad. La falta de actuación y transparencia. Este fallo no ha sido descubierto hoy, Apple lleva tiempo con conocimiento de ello. Es más, hace más de dos semanas se comentaba abiertamente en los foros de soporte, e incluso por lo que dicen, se daba como solución a usuarios que necesitaban acceder a sus propios equipos como Root. En cambio, como siempre, silencio. Hoy, por el motivo que sea a saltado a la prensa, y nos hemos enterado la mayoría (personalmente no tenía constancia de ello), y como Apple hace siempre, es cuando lanza un comunicado diciendo que tendrán la actualización lista para solucionarlo “pronto”. No dudo en absoluto que lo solucionen pronto, eso no me preocupa, ni siquiera en realidad este bug por grave que sea, lo que me preocupa es la falta de inacción por parte de Apple, y que sólo se pone las pilas cuando el problema se escala a los medios de comunicación. La “cadena de la muerte” estuvo funcionando durante semanas sin que se solucionase incluso siendo ya un “vox populi”. Dicho de otro modo… si algo tan sencillo y tan absurdo como este bug (y tan grave) lleva semanas rondando por los foros oficiales de Apple y no han hecho nada, ¿qué exploits/bugs habrá en la trastienda (con conocimientos o sin ellos por parte de Apple) que no conocemos?

Siempre he dicho y “defendido” el error humano. Nadie es perfecto y todas las empresas cometen errores, y de todos los tamaños por cierto. A veces esos errores son tan tontos como es este caso y otras veces la gran genialidad de expertos de seguridad logran meterse en los resquicios más insospechados para hacer saltar un sistema. Esto sucede constantemente y no pasa nada, lo asumimos y lo aceptamos porque en cierto modo nos fiamos de los desarrolladores que, en función de la gravedad y la importancia, tal como los problemas vayan apareciendo, se irán solucionando de igual modo. Puedo perdonar a Apple de que alguno de sus programadores haya metido la pata hasta donde la ha metido, lo que no puedo perdonar es que la vulnerabilidad lleve circulando semanas por su propio foro, y no haya dicho ni hecho absolutamente nada. Eso sí, hoy que salta la noticia a la prensa es cuando se mojan. Deleznable.

Fotografía RAW: Sensores CFA, Demosaicing y Dcraw

Share on Google+Share on FacebookTweet about this on Twitter

 

Los Objetivos de Hoy:

  • Poder realizar capturas RAW con la gran mayoría de terminales móviles
  • Entender como son realmente las capturas RAW
  • Ser capaces de “revelar” dichas capturas RAW sea cuales sea su formato
  • Crear nuestras propias herramientas cuando lo que tenemos fuera no nos soluciona el problema
  • Versión Dcraw Modificada para dar soporte específico al Xiaomi Mi6 (Ver apuntes finales)

Como pequeña introducción, los amantes de la fotografía que usen Android, sabrán que este tiene dos APIs fundamentales a día de hoy: Camera1 y Camera2/HAL3.x. En teoría la segunda viene a sustituir la primera desde hace mucho tiempo ya, pero la vagancia de algunos fabricantes y el uso para variar de APIs propias de otros, hace que como todo se tomen su tiempo. La ventaja de usar Camera2/HAL 3.x es enorme, ya que de forma nativa Android permite la captura RAW, controlar controles ISO, tiempo de exposición, focus… y de ahí existe la extraña creencia que todo ello no puede hacerse en Camera1. Sí se puede, ojo, la diferencia es que es más complicado y no tan eficiente. Y ahí es donde todo esto empieza, por mi cabezonería. El Xiaomi Mi6, por ejemplo, es totalmente compatible con Camera2, pero no está habilitado por defecto. Así que me decidí a lograr capturas RAW sin usar Camera2 (que es trivial). Lo que no tenía ni idea es que iba a dar para tanto.

Siempre he dicho que yo no soy un genio, genio son aquellos que tienen las capacidades y habilidades de crear los códigos tan ingeniosos que crean. Que yo sepa programar y pueda en un momento dado crearme mis herramientas, utilidades y otros es una cosa, pero la capacidad de algunos compañeros para plasmar tanto problemas matemáticos, algoritmos… en código, siempre la he envidiado. Con esto quiero mandar un saludo especial a los creadores de las mismas herramientas que he usado/uso, y algunas que he modificado.

La primera, pienso que es la mejor aplicación de cámara en Android en cuanto a versatilidad y grado técnico. Por desgracia recientemente su creador, troop, eliminó no solo el repositorio de github, sino que terminó borrando casi todo rastro de sí mismo. Llego a estar en el PlayStore, y cada actualización era mejor que la anterior. No se saben bien los motivos, unos dicen que se cansó, otros que realmente la aplicación tenia malware… sea como sea, está oficialmente retirada, pero tenemos forks en github. La última versión que lanzó fue la 4.1 Alpha 5, de este mismo Julio. Por cierto, hablo de FreedCam. Y tengo que decir que fue la que empezó todo esto. Esta app tiene una peculiaridad (bueno tiene muchas) importante, y es que te permite cambiar de Camera1 a Camera2 (si el terminal es compatible), y usar en cada caso lo mejor que tu cámara pueda darte. Y es mucho, porque posiblemente no vas a encontrar otra cámara que en Camera1 sea capaz de hacer una captura RAW. Y sí, la hace… bueno, siempre y cuando claro el terminal exponga en su Driver que admite al menos la captura en algún formato que no sea JPG, y ya os digo que la mayoría puede!! Y sin usar Camera2. Pero todo esto lo veremos más adelante.

La segunda, ha sido la que después de mucho quebrarme el coco, me ha dado todo el código que necesitaba para que con unas simples modificaciones (realmente añadidos) me haya permitido “revelar” mis RAW. ¿Por qué? Bueno, porque aunque con Camera1 es posible hacer capturas RAW, estas capturas nada tienen que ver con las clásicas capturas RAW de Camera2 (DNG generalmente) o de otras cámaras, estos RAW suelen ser RAW pero RAW, sin cabecera, sin nada. En este caso ha sido el software de Dave Coffin el que lo ha hecho posible. Ahí tenemos la gran importancia del código abierto, por sí mismo su software no pudo ayudarme, pero su simplicidad y su buena estructura me hizo que fuese relativamente sencillo modificarlo. Y en este caso me refiero a su utilidad DCRaw, cuyo código fuente tenemos en su propia Web y podemos compilar/reescribir o hacer lo que queramos.

 

¿Por qué RAW?

Tengo que confesar que, entre otros muchos problemas o defectos, llevo muy mal eso de no entender algo. Por supuesto que nadie tiene conocimiento universal, me refiero a estar con algo entre manos y tener más preguntas que respuestas. Soy bueno el algunos campos, pero es obvio que en muchos otros soy un principiante o un completo negado. Y es lo que me ha pasado siempre con la fotografía, es un campo que me apasiona desde un punto de vista técnico y físico, no estético. Si me hubiesen preguntado hace una semana que era un Sensor CFA Bayer sin ponerlo en ningún contexto, sinceramente habría respondido con un: “No tengo ni puñetera idea”. Y eso me encanta, porque si es algo que me interesa tengo asegurados unos cuantos días de estrujamientos de sesos, y en el peor de los casos habré aprendido unas cuantas cosas. Así que si algún aficionado a la fotografía encuentra algún error en mis palabras o algo que no sea así, por favor, que me corrija, soy “nuevo” en esto.

Como me suele pasar siempre, suelo tener algo entre manos, de eso salto a lo otro, de lo otro a otra cosa… y al final estoy hasta arriba. Todo lo que voy a contar a continuación está basado en un Xiaomi Mi6 (Mi terminal actual), pero es aplicable de un modo u otro a cualquier (o casi) dispositivo Android e incluso en muchos aspectos a cualquier cámara de fotos en general.  Hace ya tiempo escribí un artículo principalmente versado sobre software fotográfico, hablando de características principales de las cámaras, HDR, RAW: Luces, Cámaras y… Software!!. La idea no es hacer una segunda parte, sino centrarme en puntos muy específicos dentro de la fotografía digital: La captura RAW.

La captura RAW ha ido aumentando en popularidad desde hace ya mucho tiempo, imprescindible para los profesionales, querida por los aficionados, y generalmente ignorada o desconocida para el resto. Llamamos fotos en RAW de forma genérica a cualquier foto digital que haya sido tomada por una cámara (DSLR, móvil, compacta…) sin que haya sido procesada por el propio dispositivo, o mínimamente procesada. Ya digo que para el aficionado o profesional esto es de primero, pero para la mayoría lo único que saben es que disparan y se genera un archivo digital, generalmente una imagen JPG. Pero esa imagen final que obtienen es el resultado de una serie de procesados internos que transforman/convierten las señales eléctricas recibidas por el sensor, la organización de estos datos, la interpretación, correcciones, interpolaciones… Digamos que el JPG es la foto revelada, mientras que la foto en RAW es el negativo, por tanto. ¿Y esto es importante? Bueno, para el usuario casual es indiferente, las cámaras hacen un procesado y post-procesado bastante decente y no necesitan más. Pero para quien busca ese digamos… “punto extra” o toque artístico añadido, o un resultado mucho más limpio y certero… entonces necesitas trabajar tú personalmente ese negativo. Hay una lógica aplastante en esto: Si un móvil o cualquier cámara de fotos a día de hoy es capaz de realizar todas esas conversiones, adaptaciones, interpretaciones… para obtener al final la imagen JPG, y lo hacen en tiempo real (de forma más o menos aceptable), imaginad el resultado que podría obtener un equipo de sobremesa que tiene infinitamente más potencial, sin necesidad de hacerlo en tiempo real y pudiendo usar filtros/algoritmos mucho más exactos, o que nos gusten más.

A todo ello hay que añadir un enorme problema adicional que hay en la fotografía digital. Los formatos de imagen como pueda ser JPG (el más usado), es un formato con pérdida, lo que significa que aun cuando el procesamiento de las señales fuese perfecto y todo acorde a nuestros deseos, el simple echo de inscribir dicha información como un archivo jpg, estaría ocasionando una pérdida importante de información. A lo mejor en una imagen de 20MP con una cámara profesional y para una foto de tamaño normal no se aprecia, pero para una foto con resoluciones más bajas o cuando necesitamos sacar un detalle concreto o… no son pocas veces las que vemos claramente los errores de compresión que provoca JPG, como “anillos”, “pixelado” de color y otros artefactos debidos a la cuantificación.

Si ampliamos y nos fijamos bien, se pueden apreciar diferencias en cada uno de todos los pasos, siendo por supuesto los dos últimos muy extremos. Entre Q100 y Q75 pude parecer correcta la imagen en cierto modo, pero si nos fijamos bien con Q75 la imagen tiene mucho más ruido, y la hélice ya empieza a generar un pequeño halo. Para Q50 los colores de la mitad derecha, sobre todo el cuarto superior empiezan a verse incluso bloques, para Q25 el efecto es visible en toda ella y a Q1… bueno, no es que quede mucha imagen. La mayoría de cámaras permiten seleccionar de un modo u otro este grado de cuantificación que por defecto suelen establecer entre 80 y 90. A valor más alto, la imagen como es natural tendrá un mayor tamaño.

RAW es indistinto a todo esto. No es que se trate de un formato de imagen sin pérdidas como pueda ser PNG, puesto aun así lo que se guardaría en el PNG sería la imagen procesada. Una imagen en RAW por lo general contiene casi con exclusividad la información pixel a pixel que se ha tomado. Ya depende de la decena de archivos RAW que usan los fabricantes, el como incluyan la información, en que formato, si añaden metadatos… y esto es un gran dolor de cabeza, porque al no existir un estándar de facto, cada fabricante genera el que cree mejor, y así al final se requieren suites como Adobe CameraRaw o RawTherapee (O por supuesto DCRaw del que ya hablaremos) para poder tratar dichos ficheros. Al contener en la medida de lo posible la información en crudo, por otro lado, son archivos mucho más pesados que sus homólogos comprimidos como JPG.

Pero… ¿Donde empieza todo?

 

Sensores CFA: Bayer

La fotografía digital es totalmente diferente a la tradicional en cuanto a como la luz queda al final plasmada en un formato digital. En la fotografía tradicional es una película fotosensible la que capta la luz externa desde el objetivo. En la fotografía digital, el sensor de imagen es el que es bombardeado por los fotones de la luz, los hace converger, y es capaz de generar pequeñas tensiones en función de la intensidad/variaciones de estos fotones. Como es de suponer su versión más simplista sería un sensor que tan solo fuese capaz de percibir la intensidad de luz, pero a día de hoy sabemos que tenemos sensores de alta definición con una gama de colores enorme. 

El color es un problema, puede que para el ojo humano sea bien sencillo, pero para la electrónica causa dolores de cabeza. Pensar en un sensor en realidad es sencillo, imaginar algo así como una superficie plana rectangular como un colador, que tiene un agujerito por cada pixel de resolución que tiene dicho sensor. Si el sensor es de 4032×3016 pues tendría dicho número de agujeritos. El sensor sería capaz de tomar la luz por cada uno de esos agujeritos, y registraría el estado de cada una de esas celdas fotosensibles, que pasaría luego a un formato digital. ¿Pero que pasa con el color? Esas “células” fotosensibles que habría debajo de cada agujerito no pueden conocer de forma genérica la longitud de onda que les llega… podrían saber si es rojo o azul, azul o verde, verde o… pero no tener una lectura completa de todo. A este problema existen varias soluciones.

La más obvia es usar sensores con diferentes “capas”, las cuales, cada una de ellas es capaz de atrapar la intensidad de uno de los tres colores primarios (Rojo, Verde y Azul, RGB), pero esto es caro. Así que al final, prácticamente la totalidad de cámaras de fotos usan una aproximación realmente al problema, y usan sensores CFA: Color filter array. Los sensores CFA son mucho más baratos, pero hacen trampa. Cada “celda” del sensor no es capaz de capturar la intensidad de más de un color, cada celda sólo sabe capturar el de uno sólo, pero se crea una matriz, un mosaico compuesto de dichas celdas, organizados de un modo muy concreto, y así dar la sensación de que cada celda (pixel) posee color propio. Pero es una ilusión. La efectividad de un sensor CFA empieza por tanto en el patrón o la organización concreta de esas celdas (que pueden ser rojas, verdes o azules) que tendrán en el propio sensor:

(Wikipedia)

 

 

Dentro de los sensores CFA, nosotros nos vamos a centrar a su vez en los sensores Bayer. Bayer fue el inventor del patrón mostrado en la imagen anterior. Bayer se dio cuenta que el ojo humano es mucho más sensible al color Verde que al color Rojo y Azul, tomando pues el Verde como el componente lumínico y el Rojo y Azul como componentes cromáticos. Así que estableció lo que a día de hoy se conoce como Mosaico Bayer o patrón Bayer, que es sencillamente la repetición de un mosaico/bloque de 2×2, que contienen dos componentes verdes siempre enfrentados, y un componente azul y otro rojo. Estos patrones Bayer se nombran en función del orden en el que aparecen dichos componentes, y como es lógico solo hay 4 posibilidades: RGGB, BGGR, GRBG y GBRG. Recordar que el patrón es un bloque de 2×2, no 4 celdas alineadas. En la imagen anterior vemos un patrón BGGR, que se repite indefinidamente. El por qué de tomar el sensor Bayer de ejemplo, es porque a día de hoy es de lejos el tipo de sensor más usado. Pero ojo, no es el único, y no es tampoco nada raro ver sensores CFA de otro tipo, con otros patrones diferentes.

Si nos fijamos en la imagen de arriba, vemos la trampa y en parte el problema. Vale, tenemos distribuidas celdas capaces de captar los tres colores (e intensidad de estos claro), pero si hemos dicho que cada celda representa por así decirlo un pixel… ¿¿como diablos representamos eso?? Que cada celda recogiese en sí misma toda la información RGB tendría sentido, un pixel, un color RGB asignado. Pero en el sensor bayer cada pixel sólo recoge un color, una intensidad. Si tenemos una imagen de 2MB (1920×1080), según el patrón BGGR mostrado, el resultado sería de todo menos fotográfico, veríamos claramente un efecto “mosaico” en la foto, no una imagen colorida y hermosa. Además, tendríamos la peor parte… si usamos bloques de 2×2, podríamos pensar que realmente “1 pixel” real correspondería a cada bloque, lo que implicaría que el sensor tuviese que tener el doble de tamaño. Y ya os digo que esto no es así.

 

Demosaicing (Teoría)

(Nota: Cuidado, si se hace clic pasa a la versión completa, 11MB)

Puede parecer una broma, pero, en la imagen podemos ver realmente la información que capta un sensor Bayer (El Xiaomi Mi6 usa un sensor RGGB). Vista en la previsualización es posible que no lo percibamos, y sólo veamos una imagen completamente verde (poco que ver con la imagen con la que empecé este artículo. Pero si tenéis una conexión mínimamente decente, os invito a hacer clic, ampliar y ver que está pasando. Y se ve, creerme que se ve. Si ampliamos la imagen unas 1600 veces, para quien no tenga ganas de abrirla, esto es lo que va a ver:

 

Ahora no parece tan verde… ahora podemos apreciar perfectamente cuales son los píxeles con las distintas intensidades verdes, y cuales los azules y rojos. El patrón siempre es el mismo, bloques 2×2 RGGB, RGGB…

Pero falta información en la imagen o eso parece… ¿¿donde están realmente los colores?? Es cierto que sabemos que con RGB podemos crear cualquier color, pero aquí tenemos filas y filas del mismo patrón, y dado que hay el doble de píxeles verdes, toda la imagen toma en este caso un color claramente verdoso, El color final se encuentra codificado en la información de la intensidad de los píxeles que les rodea. El patrón Bayer hay que deshacerlo para reconstruir los colores reales, el valor RGB de cada pixel, y no sólo uno de sus componentes. A este proceso es al que se llama demosaicing, que realmente es una interpolación de colores. Como tal, y como ya se dijo, es siempre aproximada, el sensor jamás será capaz de captar los colores “reales” en toda su resolución, pero gracias al software y a la física podemos reconstruir de un modo muy fidedigno la imagen original. Sí, no deja de ser un truco, pero en este caso un gran truco.

Por supuesto el resultado por tanto va a depender en gran medida del modo de interpolación que sea usado. No existe un modo de hacer este proceso de forma única, hay tantos como algoritmos de interpolación existan o queramos crear. Y esto no es exclusivo del sensor Bayer, de echo casi todas las cámaras a día de hoy sino todas, si no usan Bayer usan otro sensor CFA con otro patrón, que también hay que interpolar. Un equipo de sobremesa podría en todo momento aprovecharse de esto para cargar la foto sin “desmosaizar”, y aplicar diferentes algoritmos para ver cual de todos ellos da mejor resultado para dicha toma, o por fines puramente artísticos. Además un equipo puede permitirse el lujo de hacerlo ya no en tiempo real, sino todo tipo de algoritmos que sean complejos y sobrepasen la capacidad de cálculo de cualquier móvil o cámara de fotos.

Cuando empecé a ver todo esto, sinceramente me pareció una locura, sabía como funcionaban más o menos los sensores de imagen, pero creía que cada “celda” del sensor en realidad se subdividía en 2-3 subceldas cada una de ellas captando la intensidad de un color y conformando en sí misma un pixel completo, no tenía ni idea que realmente cada pixel tomado de forma independiente no poseía en sí mismo un valor completo de color RGB. Muchos pueden pensar que puede ser más o menos interesante, pero que a fin de cuenta que importa, si al final es el resultado lo interesante. Por supuesto, pero desde un punto de vista técnico, hay una importancia infinita, y es por culpa del desconocimiento que tenía en estas cosas por el cual no era capaz de “revelar” mi primera captura RAW que realicé con mi terminal con Camera1.

Soy un amante de Photoshop, pero si quieres un control más fino del revelado RAW o tener opciones más flexibles, quizás es mejor probar en esos momentos un poco de RawTherapee, además de ser gratuito. Puede mejorar en millones de cosas, pero a veces nos da ese algo más que no tenemos en PS. Por ejemplo, entre otras cosas, diferentes algoritmos  para “desmosaizar”

 

Parsear archivos RAW

Se desde hace tiempo que se podían hacer capturas RAW con algunas aplicaciones y potencialmente obtener del sensor los datos tal cual los captura, pero de ahí a interpretar dichos datos hay un abismo. Si fuera tan sencillo no existiría Adobe CameraRaw y sus constantes actualizaciones, precisamente para ir soportando poco a poco más formatos. Como he dicho cada fabricante usa sus propios formatos. Al menos incluso en esos casos podemos llamarlos “formato” de archivos. Si lees la información directamente del sensor, poco o nada tiene que ver con esos archivos. Cuando una cámara normal hace una fotografía en RAW o incluso con las APIs “normales” de Android, se genera un archivo RAW generalmente conocido, que además de incluir información a nivel pixel a pixel, incluye la información necesaria que después cualquier “revelador” RAW podría necesitar. Por ejemplo, los parámetros con los que se tomó la foto (exposición, distancia focal, lente, marca, modelo….), el tipo de sensor que usa, si Bayer que patrón Bayer usa, que matrices de color o multiplicación se han aplicado… un largo etc de lo que podemos llamar “metadatos”. Algunos tan importantes, por supuesto, como la resolución de la foto, la profundidad de bits de color… Realmente no componen la imagen en sí mismos, pero si aportan información de todo ello necesaria. Sin ella es poco probable que algún revelador RAW puede interpretarla.

Este es el caso que nos atañe. Sí, después de capturar una imagen RAW con Camera1 con Mi6 obtengo efectivamente un archivo pesado, de unos 15Mb, exactamente (y esto es importante) 15482880Bytes. Hace ya días me preguntaban que sí, que sabían que podía capturarse en RAW con Camera1, pero que les había sido imposible “abrirlas” (revelarlas). A diferencia de otras formas de captura, aquí la información que tenemos es mínima, y solo podemos empezar a teorizar, después de intentar pasarlo sin éxito por diferentes aplicaciones RAW. Cuando las herramientas disponibles no nos valen, hay que hacerse las herramientas, y ver que pasa. Por suerte no es la primera ni la segunda vez que parseo archivos… es decir, analizo archivos en principio de índole binaria, soy capaz de encontrar o identificar cabeceras, datos… y en función de la estructura de estos crear un parser que pueda interpretarlos de algún modo. Con el tiempo aprendes a ver “patrones” en los editores hexadecimales que te hacen pensar sobre que tipo de contenido pueden tener: Comprimido, cifrado, información de color, espacial… y siempre por supuesto no con un archivo, a ser posible al menos con 2 o 3 diferentes, así poder encontrar patrones similares, ideales para cabeceras, tamaños/offsets y otros.

Distribución más o menos uniforme, sin cabecera visible. Si tenemos en cuenta que estamos tratando con archivos de imágenes, y dada la estructura que a simple vista podemos ver, parece razonable pensar que el archivo generado es sencillamente la sucesión de pixeles de la imagen. En principio cada uno de los Bytes podría ser cualquier cosa, pero para empezar podríamos pensar que cada Byte representa la intensidad de color de un Pixel, y aun cuando no conociésemos que es un sensor Bayer, lo primero que pensaría es que los pixeles estarían representados por cada 3 Bytes, pongamos que el primer byte es la intensidad Roja, el segundo Verde y el tercero Azul, y se repite por cada pixel. No parece que exista cabecera y eso es un problema, ya que el archivo en sí mismo no nos da ningún tipo de información extra, que es totalmente necesaria, así que hay que extrapolarla de las cosas que sí sabemos.

Lo que sabemos:

Archivo: 15482880 Bytes
Resolución Foto Tomada: 4032 x 3016

Por lo general un archivo JPG tiene una profundidad de color de 8Bits por canal (24Bits en total), es decir que tanto para el canal Rojo, El Verde y el Azul, se usan 8bits en cada uno que indican su intensidad, y los 3 Bytes conforman el pixel. 1Byte permite 256 valores diferentes, así que una profundidad de 24Bytes podría darnos unos 16.7 Millones de colores posibles. Esto es más que suficiente, pero cada vez exigimos más, y en fotografía profesional, Juegos (ahora de moda), HDR y otras cosillas, se requieren profundidades de color mayores. No es nada raro a día de hoy por tanto ver cámaras que disparan RAW a 10, 12 y 16 Bits por canal, incluso los propios monitores soportan profundidades ya mayores a los 32Bytes de siempre (24Bytes+8 Bytes más del canal Alpha). Sin especificaciones en la cabecera y sin que nadie nos pueda ayudar, sólo nos queda presuponer y hacer cuentas, que no es complicado.

El archivo parece mantener la estructura de principio a fin, aunque si mirásemos al final del archivo veríamos una parte que está totalmente vacía y si miramos otros archivos siempre es el mismo tamaño… así que no es mala idea apuntar ese “extra” de archivo, siempre 282240 Bytes. Bueno, pues si es así sólo hay que multiplicar/dividir para adivinar que pasa. Si suponemos que cada byte es un pixel (un componente RGB), ¿cual debería de ser el tamaño final del archivo?? La resolución la conocemos de antemano

4032 x 3016 = 12160512 pixeles x 3Bytes (1Byte por componente, 8 bits de profundidad) = 36481536 Bytes. Un valor bastante superior al tamaño que realmente tenemos de archivo, con lo que si usásemos una profundidad de color aun mayor, el tamaño sería mucho mayo, y obviamente no vamos a tener menos de 8bits por canal.

Podríamos hacer otra hipótesis, y pensar que realmente no existen 3 componentes por cada pixel, es decir, 24bits por pixel, y tan solo 8bits por pixel, pero entonces tendríamos la percepción de tener una resolución 3 veces inferior. Aun así, vamos a ver como quedaría:

4032 x 3016 = 12160512 pixeles x 1 Bytes= 12160512 Bytes. Un valor mucho más cercano al tamaño original, pero aun no coincide, ni siquiera si sustrajésemos el espacio vacío de 282240 de final de archivo.

Una opción es seguir probando, otra sería hacerlo al revés, partir del tamaño original y ver que pasa:

 

15482880 Bytes x 8 = 123863040 Bits / 4032  = 30720 / 3016 = 10,185 Muy cerca, demasiado… podrían ser 10 Bits por componente, o 10 bits para los tres componentes. El caso es que teniendo en cuenta la resolución y el tamaño, cada pixel está codificado por algo más de 10bits. A ver que pasa si descontamos al tamaño completo el espacio en blanco final de archivo:

15200640 Bytes x 8 = 121605120 Bits / 4032 = 30160 / 3016 = 10 clavados.

Así que una de dos, o cada pixel se codifica con 10 Bits para las tres componentes, o cada “pixel” se representa con una sola componente y 10Bits, que teniendo en cuenta es una imagen RAW, es lógico que se use una profundidad de más de 8bits por canal. Aquí es donde automáticamente recordamos los sensores Bayer y como funcionan, y podemos sacar en conclusión que:

-El archivo no contiene ninguna cabecera
-El contenido del archivo es una sucesión de pixeles consecutivos, cada uno de ellos codificado a 10Bits
-Cada pixel codificado de este modo tan sólo posee una componente, lo cual coincide con lo que cabría esperar en un sensor Bayer.

Todo esto es sólo hipótesis, por ahora no hay una imagen de nada. Lo bueno de Bayer es que como cada pixel se codifica sólo como una componente, podríamos tratar toda la imagen como si no existiese color, y cada pixel sólo tuviese información en la escala de grises. Si fuese así, representar eso en cualquier editor tendría que darnos una imagen en escala de grises de la fotografía original. Eso sería trivial con cualquier aplicación, incluso en PS podemos forzar la apertura de una imagen RAW indicando la resolución, los bits por componente y cuantos canales. El problema que tienen todos esos editores es que la mayoría no contemplan profundidad de 10 Bits. Photoshop por ejemplo te permite forzar la apertura para 8, 16… pero no para 10. Otros si te lo permiten pero entonces no te permiten forzar que lo interpreten sólo como un canal… y ya sin entrar en las diferentes formas de codificar en 10 bits pueden existir.

Aunque sólo fuese para ver si vamos por buen camino, podríamos intentar usar alguna herramienta de conversión para transformar esos 10bits en 16 o en 8. Por ejemplo, cada 10bits leídos escribir 2 Bytes en otro archivo. El archivo final aumentaría el tamaño claro está, por usar 16bits por canal. Otra opción sería el proceso inverso, pasar esos 10bits a 8bits por interpolación, y el archivo final tendría un menor tamaño. Pero de cualquier modo por desgracia no existen herramientas sencillas para esto.

Lo más cercano que tenemos, sin entrar en programar nosotros mismos, quizás sea con ImageMagick, y su utilidad Convert, que precisamente hace cosas similares. Si definimos nuestra imagen de entrada como una sencilla representación gris en 10bits y con la resolución concreta, podemos pedirle que nos lo pase a 16bits:

convert.exe -size 4032×3016 -depth 10 GRAY:MiImagen.raw -depth 16 imagen_16bits.raw

Vemos que efectivamente el tamaño crece para acomodarse a 16bits por componente, y ser mucho más sencillo poder verla con cualquier visor. Tal cual, usando Photoshop o cualquier editor, especificando repito resolución profundidad (16bits ahora) y canales (1 en este caso, gris), tendríamos lo siguiente:

No es una imagen muy definida que digamos, pero sí que podemos ver realmente el motivo. Así que desde luego desencaminados no vamos. Ojo, si no hemos cometido error a este paso la imagen tendría que verse en escala de grises de forma correcta. Pero por ahora pueden ser muchas cosas… podría ser debido a la conversión realizada por ImageMagick y como ha mapeado los niveles de 10 a 16bits, o podría ser que pese a que cada 10bits represente un pixel, podría ser que dichos píxeles no estuviesen organizados, como hemos presupuesto, uno tras otro. Podrían estar organizados de otros modos. Está claro que muy diferente no puede ser, o no tendríamos imagen. De todos modos podemos ver que hace algo mal… podemos apuntar la cadena de Bits y comprobar a mano el valor que tendrían por ejemplo los 10 primeros pixeles en 10bits, y compararlo con el valor que después de la conversión a 16bits estos mantienen… y vemos que el valor no se corresponde, ni siquiera se acerca. Posiblemente porque ImageMagick remapee todo el rango y lo escale, o simplemente tomemos mal los bits.

A este punto, se nos han acabado los amigos que nos solucionen la papeleta. Toca picar código. Para la tarea de crear un pequeño parser según lo que sabemos y a ver que pasa, podríamos hacerlo de cero de forma simple casi en cualquier lenguaje, o podemos hacerlo sobre alguna aplicación ya pensada para estos menesteres. En realidad hacer nosotros el parser por nuestra cuenta tiene la ventaja de no depender de nada mas y el código es simple, pero usar en este caos Dcraw nos da muchas más opciones a la hora de procesar. En principio la tarea es “sencilla”, un script/app que lea el archivo original y cree otro transformando cada 10bits en 16Bits. Mi primera idea, y creo que la lógica, es no mapear ningún tipo de color, sencillamente tomar  de 10 en 10bits, y meterlos cada uno en 16bits, conservando el mismo valor. Así si los primeros 10bits poseen un valor de por ejemplo 958, codificado en 2 Bytes sería 0x03be. El archivo final debería de poseer un tamaño 1.6 Veces mayor, ya que cada pixel pasaría a tener en teoría una profundidad de 16bits, aunque de ellos sólo se usarían 10. Recordamos que buscamos un resultado que podamos abrir y veamos claramente una imagen adecuada en escala de grises. El pseudocódigo de esto sería algo así, pensando en el stream de bytes como si se tratase de una “matriz” de bytes

Ancho_de_matriz = (Resolución_horizontal * 10) / 8
Columna = Fila = 0
Imagen = prueba.raw
Puntero_ArchivoNuevo = ImagenFinal.raw
Buffer, Buffer_Aux

Para (Fila < Resolución_vertical, Fila ++)
  Almacenar en Buffer la cantidad de Ancho_de_Matriz Bytes desde imagen //En cada interacción lee a partir del último valor leído
  Para (Columna < Resolución_horizontal, Columna += 4, Puntero_ArchivoNuevo += 5. Buffer_aux = Buffer)
    ArchivoNuevo [Fila, Columna] = (Buffer_aux [0] << 2) | (Buffer_aux [1] >> 6)
    ArchivoNuevo [Fila, Columna+1] = ((Buffer_aux [1] & 0x3f) << 4) | (Buffer_aux [2] >> 4)
    ArchivoNuevo [Fila, Columna+2] = ((Buffer_aux [2] & 0xf) << 6 )| (Buffer_aux [3] >> 2)
    ArchivoNuevo [Fila, Columna+3] = ((Buffer_aux [3] & 0x3) << 8) | Buffer_aux [4]

Visto así no hay quien lo entienda… pero en realidad es muy sencillo, es lioso porque hay que trabajar a nivel de Bits, y no de Bytes. La premisa es que hay un patrón que se repite, constantemente, y de ahí los dos bucles anidados. El patrón que se repite son las 4 sentencias finales. El bucle externo itera sobre cada fila, el interno por columnas. La única salvedad es que la iteración de columnas no toma columna a columna (byte a Byte) sino de 5 en 5 bytes. La razón es sencilla, si se codifican 10bits por pixel, el valor entero más cercano que a la vez sea múltiplo de 10 y de 8 es el 40. 40 Bits son 4 píxeles (columnas en archivo viejo) y a la vez son 5 Bytes leídos. Así que tratamos directamente con 5 Bytes a la vez, y repetimos hasta terminar.

La conversión lo único que hace es ir almacenando en otro archivo/buffer cada 10bits extraídos en 16bits, y para hacer eso lo más cómodo es desplazando los bits para un lado u otro. Vamos a ilustrar esto, pero de un modo mucho más sencillo, imaginemos que estos son los primeros 5 Bytes, y para facilitar la visualización vamos a obviar que usamos binario y que obviamente no podemos usar otros caracteres que no sean 0/1. pero hacer el seguimiento a los números es más cómodo.

Queremos pasar de esto: 11111111 22222222 33333333 44444444 55555555
A 16 bit, algo como esto: 00000011 11111122 00000022 22223333 00000033 33444444 00000044 55555555

Ejemplo paso a paso de las dos primeras columnas, las otras dos serían similares

Columna 0

Tomamos el primer Byte completo: 11111111, pero ahora tratamos los datos como 16 bits puesto que ArchivoNuevo está definido como tal, luego realmente tenemos: 00000000 11111111.
Lo desplazamos 2 posiciones hacia la izquierda: 00000011 11111100
Tomamos el segundo Byte competo: 22222222, y al igual que antes, tenemos realmente 00000000 22222222
Desplazamos hacia la derecha 6 posiciones: 00000000 000000022
Operamos con OR lógico los dos resultados previos: 00000011 11111100 OR 00000000 00000022 = 00000011 11111122

Columna 2

Tomamos el Segundo Byte completo: 22222222, realmente tenemos: 00000000 22222222.
Aplicamos una máscara AND antes de desplazar para evitar propagar los 2bits superiores, seteándolos a cero: 00000000 22222222 & 00000000 00222222 = 00000000 00222222
Lo desplazamos 4 posiciones hacia la izquierda: 00000022 22220000
Tomamos el Tercer Byte competo: 33333333, realmente 00000000 33333333
Desplazamos hacia la derecha 4 posiciones: 00000000 000003333
Operamos con OR lógico los dos resultados previos: 00000022 22220000 OR 00000000 00003333 = 00000022 22223333

 

Por desgracia, este primer parser nunca me funcionó. Tenía un resultado ligeramente mejor que el anterior expuesto, pero muy muy similar. Quizás ImageMagick hacía un trabajo parecido después de todo. Pero lo bueno de hacerlo uno mismo es que una vez realizado, modificar algunos detalles es trivial, solo hay que modificar, compilar y probar de nuevo. Después de darle unas cuentas vueltas opté por algo muy sencillo… pensemos en compatibilidad… en 5 Bytes tenemos 4 píxeles, ¿¿y si realmente la mayoría de esa información que nos interesa estuviese realmente en esos 4 píxeles?? Es decir, que pasa si eliminamos el quinto Byte y tratamos realmente cada Byte como tal (con una profundiad de 8 bits y no de 10) Contamos 5, usamos y asignamos los 4 primeros y descartamos el quinto. Además es mucho más fácil programarlo, es trivial, sólo hay que asignar directamente sin desplazamientos ni historias.

    ArchivoNuevo [Fila, Columna] = Buffer_aux [0]
    ArchivoNuevo [Fila, Columna+1] = Buffer_aux [1]
    ArchivoNuevo [Fila, Columna+2] = Buffer_aux [2]
    ArchivoNuevo [Fila, Columna+3] = Buffer_aux [3]

Compilamos, convertimos, el quinto no será usado nunca, ya que en el iterador interno contamos de 5 en 5:

No sé como tendréis calibrado los monitores, porque está algo oscura, pero para mi que eso es una imagen perfecta en escala de grises (bastante oscura eso sí), a la original. Pero entonces, ¿para que sirve ese 5 Byte? Bueno, en realidad cuando llegas a este punto piensas que es lógico. El sensor manda los datos en 10Bits, y que mejor forma que hacerlo por cuestiones de compatibilidad que “empaquetados” en Bytes normales, + 1Byte adicional que porta los 2Bits restantes de cada uno de los 4Bytes (píxeles) anteriores. Como en la prueba simplemente fueron eliminados, la conclusión es clara, el quinto Byte contiene los 2 bits LSB de cada uno de los otros, es decir, los Bits de menos peso en esos 10 Bits. La idea original era errónea:

11111111 22222222 33333333 44444444 aabbccdd
No pasa a ser:
00000011 11111122 00000022 22223333 00000033 33444444 00000044 aabbccdd

Pasa a ser:
00000011 111111dd 00000022 222222cc 00000033 333333bb 00000044 444444aa

Lo cual implica una gran diferencia. En realidad podrían asignarse al revés, y suponer que la asignación se hace al contrario, es decir que al primer byte le corresponde los dos MSB del 5º byte, y no los 2 LSB. Por desgracia los resultados son demasiado similares como tener una certeza exacta ahora mismo de cual de las dos asignaciones es la correcta. Sería necesario hacer capturas muy concretas para que las diferencias se diesen en un borde o un cambio suficientemente brusco como para percibirlo. Actualmente he optado por la segunda, por ser más simétrica, los 2 MSB para el primero, los dos siguientes para el segundo… pero da igual una que otra realmente. La implementación, teniendo en cuenta ya expuesta las otras dos, creo que es sencilla, así que la dejo en manos de quien le interese como ejercicio, y en todo caso si le interesa a alguien y no puede, que la pida. El resultado es similar al anterior, aunque una imagen bastante más clara. Si ampliásemos, podríamos observar, aunque en escala de grises, el patrón Bayer, en este caso en monocromo. Se podría multiplicar la imagen anterior para obtener una imagen mucho más clara, Si podemos capturar 10 Bits en vez de en 8 Bits, es precisamente para poder tener una mejor precisión de color y poder representar una paleta mayor, si en la conversión eliminásemos esos 2 bits de más empaquetados en el 5º byte, , pues la verdad es que le quitamos gran parte de la gracia al asunto.

La importancia de la imagen en escala de grises es por la propia naturaleza del sensor Bayer. En realidad cada pixel no representa una tonalidad de gris, sino una intensidad Roja, Verde o Azul, pero mientras que no se deshaga el mosaico bayer, podemos tratarla como si cada pixel fuese ni más ni menos como un pixel gris. Podríamos representarla tal como es, pero al menos que yo sepa no existe ningún visor digamos… Bayer, que represente el color de cada pixel en función de un patron dado, para dar una imagen similar a la expuesta en la apertura de la sección de Demosaicing. No obstante se podría hacer uso de Photoshop para representar el mosaico de un modo bastante fidedigno, creando el patrón RGGB, rellenando una capa sobre la imagen con dicho patrón… pero sería complicar las cosas, cuando lo principal está terminado. Photoshop es cierto que no posee ningún filtro o sistema sencillo para realizar la interpolación de colores (a menos que se haga desde CameraRaw e identificando la imagen), con lo que dcraw nos va a servir para hacer la interpolación. De ahí que, una vez creado el parser, si lo implementamos dentro de dcraw, tendremos en la misma herramienta todo lo que necesitamos. Por supuesto este es el caso específico del Mi6, pero como dije en su momento es extrapolable a cualquier otra imagen RAW capturada por los teléfonos/cámaras… con los correspondientes ajustes, por supuesto.

 

Dcraw

Una gran utilidad, y al ser además de código abierto podemos meternos en sus tripas, editar lo que deseemos, añadir… en realidad nos viene perfecta, ella misma está preparada para gran cantidad de formatos de cámaras, y hace precisamente todo lo que queremos hacer nosotros. Si hemos sido capaces de crear un parser para nuestra cámara, siempre y cuando no esté incluida ya, implementarlo/añadirlo a dcraw es sencillo, además de poder luego procesarla. El código de dcraw está publicado en la propia web del autor ya mencionado, quien quiera una copia fresca la puede obtener de AQUI. Está creada de forma sencilla en C sin dependencias raras y se compila sin problema con gcc:

gcc -o dcraw -O4 dcraw.c -lm -DNODEPS -l ws2_32

En este caso sería compilado para Windows, de ahí la inclusión de ws2_32 por ejemplo, pero se puede compilar para cualquier OS realmente.

Llos cambios necesarios son escasos. Necesitaremos crear el parser por un lado, una metadescripción de nuestro formato y una llamada a nuestro parser cuando se encuentre/identifique nuestra imagen. Como digo el código de dcraw es bastante limpio y con un poquito de tiempo se comprende bastante bien.

Así pues nuestra primera parada es la descripción de nuestro archivo. Sobre la línea 8300 vemos una tabla ya creada con lo que parecen descripciones de diferentes cámaras, así que la idea es incluir la nuestra. Esto podemos hacerlo no sólo con una, sino con las que queremos. Pero recordar que aquí sólo describimos por así decirlo la cámara. Para nuestro caso sería algo así:

{ 15482880,4032,3016, 0, 0, 0, 0, 1,0×94,0,0,”Xiaomi”,”Mi 6″ }

Es necesario buscar en el código el significado de cada campo, en la misma estructura queda más o menos puesto:

fsize: Tamaño del archivo en bytes
rw, rh: Resolución horizontal y vertical respectivamente
lm, tm, rm, bm: Márgenes izquierdo, superior, derecho e inferior
lf; load_flag (usado en varias partes del código para “marcar” ciertos archivos
cf; Filtro a usar, en este caso tendremos que especificar que queremos usar un filtro Bayer RGGB, 0x94.
max: máxima profundidad de bits usada
flags: Diferentes flags, como inversión de imagen y otros.
make: Fabricante
model: Modelo

Hay que tener en este caso concreto algo claro e importante. Recordemos que en el caso del Mi6 el archivo que se genera añade al final del archivo unos miles de Bytes adicionales. Si queremos procesar el archivo directamente sin necesidad de eliminar previamente dichos Bytes, tendremos que especificar el tamaño completo, con dichos bytes incluidos, y en nuestro parser asegurarnos que no se lee más allá. En el pseudocódigo anterior esto no es problema, ya que se lee hasta que la fila leída coincida con la resolución vertical, con lo que el resto se ignorará. Pero hay que tenerlo en cuenta, si el parser lee el archivo completo hasta final de archivo, podría incluir dichos Bytes. Es más cómodo especificar el archivo completo, y no hay que estar metiendo tijera, o en el propio parser tener que cortarlo. La captura RAW lee todo el sensor, así que la resolución siempre será la  máxima por regla general, y el tamaño de archivo también.

Una vez definido nuestro archivo, esta tabla permitirá que el archivo sea reconocido y pueda seguir adelante, aunque no significa que hayamos terminado. Esta tabla es muy útil porque si por ejemplo tenemos otro terminal que captura de un modo muy similar, casi tan sólo tendríamos que añadirlo a la tabla para que directamente funcionase, y usar el mismo parser creado. Sea como sea, lo siguiente es crear el parser tal como quedó dicho anteriormente, cada uno que lo desarrolle como quiera. Podemos colocar el código por ejemplo encima de “minolta_rd175_load_raw” y para seguir con la misma nomenclatura llamar a nuestro parser: “xiaomi_load_raw”. Podemos servirnos de los propios métodos ya creados en dcraw para facilitarnos el parser, pero la cuestión es que al final la “imagen” final resultante quede en raw_image, accedida desde RAW(row,col)

Y para finalizar, sólo queda añadir el salto a xiaomi_load_raw cuando detectemos el archivo en cuestión. Pensar que el parser creado no es específico para xiaomi, en realidad es un parser MIPI de 10bits, y dcraw carecía de él. dcraw sí incluye ya parser parecidos incluso para parsear raw bayer en 10bits, pero tendríamos algo similar al primer resultado que obtuvimos al presuponer que que los bits estaban totalmente serializados, y no empaquetados, como al final fue el caso. Así que podemos hacer uso de esa misma función, sobre la línea 8595 más o menos vemos diferentes case, para 8, 10, 12… bits. Desdoblamos el Case 10, y simplemente llamamos a  nuestra función del mismo modo que hacen otros:

load_raw = &CLASS xiaomi_load_raw; break;

Eso es todo, compilar y listo. Si todo es correcto tan sólo tendremos que invocar dcraw como dice en su propio manual y con los parámetros que queramos. La idea de usar Dcraw es múltiple. Por un lado podemos hacer uso de sus propias funciones para facilitarnos la tarea de crear nuestro parser, pero además nos va a permitir realizar a la imagen diferentes transformaciones/conversiones. Por supuesto, principalmente lo que haremos será la interpolación de colores para convertir nuestro mosaico Bayer en una imagen todo color, pero también es muy útil para ajustar algunos parámetros antes de realizar la interpolación. Recordar que es una imagen RAW, es decir, vemos lo que ha tomado el sensor, sin procesar, sin aplicar matrices correctivas, cambios de espacios de color… nada. Pero precisamente por eso usamos RAW, ¿no? Si queremos precisamente una imagen procesada, nos quedamos con el JPG.

 

Uso de Dcraw

Dcraw es algo así como un revelador RAW, toma una imagen RAW de entrada y la convierte/interpreta a un formato más amigable. Ya sabemos que cuando se lo ordenemos nos va a decodificar la imagen Bayer en una ¿bonita? imagen, pero depende de lo que le digamos, la salida será realmente sin procesar o podrá realizarle algunos ajustes básicos. Cuando una cámara dispara una foto en RAW, por lo general adjunta en ella un perfil DCP que especifica las transformaciones de color, tipo de sensor… y otros ajustes que deberían de ser necesarios (al menos de forma orientativa), para que la imagen sea visualizada de forma correcta. De echo gracias a estos perfiles incrustados la mayoría del software RAW que existe en el mercado (Como Adobe CameraRAW) se basa en estos perfiles para automáticamente aplicar dichos ajustes a la imagen y tener nosotros algo bonito en pantalla.

Muchos podrían pensar que estos ajustes matan el principio del propio RAW, que es tomar una imagen sin procesar. Realmente los perfiles no dictan como se ha procesado la imagen, sino como se podría procesar en función de la información del sensor que el aporta. Así podemos usar el perfil tal como está, o podemos realizar en el editor los ajustes que deseemos, pero desde luego nos suelen servir de base. Aquí de todos modos tenemos un pequeño problema añadido… al archivo RAW nuestro no se le añade ningún tipo de información adicional, ni cabecera. Eso quiere decir que la imagen que vamos a obtener en este caso es totalmente RAW sin perfiles que especifiquen nada… ya no sólo información para que el software de tercero sea capaz de parsearla, sino tampoco ajustes básicos que habría que tener en cuenta del sensor: Matrices de Color, de conversión de espacio de Colores, punto negro… y no es una tontería, porque la no tener una referencia de estos, tendremos que valernos de nuestras habilidades para ajustar correctamente tanto colores como balances de blancos y otros, de nuestra imagen. Sobre la pregunta obvia de si sería posible implementar en Dcraw igualmente matrices de ajuste específicas para cada cámara/dispositivo, la respuesta es que por supuesto, pero esto varía enormemente de sensor en sensor, con lo que no se trata de poder usar una de otro modelo para ajustar la nuestra. Por supuesto si damos con los parámetros que nos gustarían, podríamos hacer que aplicase dichas transformaciones, cosa que hacen muchos otros modelos/dispositivos. Yo no he tocado las matrices, no hay correcciones de nada en principio, quitando eso sí los ajustes al vuelo que permite realizar Dcraw y que ahora veremos. Recordamos que en Dcraw realmente ya especificamos resolución, tamaño de archivos… así que será por este tipo de identificadores por los cuales Dcraw sabrá que imagen estamos metiendo de entrada, no importa la extensión o el nombre.

Algunos ejemplos sencillos y las salidas resultantes:

1. Conversión “estándar”. Imagen resultante no lineal, en 8bits, interpolada, y escalada: dcraw -v -c Camera1_bayer10.bayer > Test1.pgm

Es muy similar a lo que sería la imagen JPG resultante procesada, excluyendo el balance de blancos y un estrechamiento en los niveles. Por razones evidente este tipo de conversiones no son lo que deseamos, para eso menos lío realizando la fotografía normal. La idea de RAW es poder jugar con el máximo de información de la propia imagen para procesarla nosotros de un modo mucho más fino, y en este caso hemos de un plumazo eliminado la linealidad de la imagen, así como la mayor profundidad de colores. Esto se puede solucionar especificando que se realice la conversión en 16bits (manteniendo los 10bits que capturó el sensor), o directamente especificando que se mantenga la linealidad en la imagen, que por defecto también fuerza la salida en 16bits, en vez de 8.

 

2. Conversión manteniendo la linealidad de la imagen y los 10bis de profundidad (convertidos a 16), interpolada y escalada: dcraw -v -c -4 Camera1_bayer10.bayer > Test2.pgm

Pese a lo que pueda parecer, es muy diferente a la anterior. En este caso no sólo existe un mayor rango de colores (no apreciables aun), sino que la imagen es lineal, de ahí a que parezca más oscura (incluso estando escalada). Esto es importante. Prácticamente la totalidad de los sensores de las cámaras tienen un comportamiento lineal, es decir, que el “valor” de cada celda/pixel que es recogido debido a la intensidad de los fotones que llega a ellos, es siempre proporcional. Dicho de otro modo, si por ejemplo para 10 fotones el sensor registrase en dicho pixel un valor de 20, para 20 fotones recogería un valor de 40. Esto puede parecer una tontería, pero la cuestión es que el ojo humano y nuestra percepción es de todo menos lineal. Las imágenes lineales suelen comprimirse sobre todo en las sombras, mientras que las no lineales se expanden hacia los medios tonos e iluminaciones, produciendo un comportamiento, aparente, de más homogeneidad:

Se puede apreciar perfectamente los dos efectos. Los picos o “vacíos” que se encuentran entre las diferentes curvas en la primera imagen se deben a la reducción de la profundidad de color, no presentes en la segunda. Así mismo se puede observar perfectamente la linealidad de la imagen, mientras que el primer histograma se esparce por la mayoría de la escala, la segunda imagen, lineal, se condensa en la parte izquierda, en las sombras. La cuestión es simple, si queremos tratar lo más RAW posible una imagen, es de sentido común que no la transformemos en no-lineal como se hacía en el anterior ejemplo. Aquí no no la convertimos en lineal, sino que la mantenemos lineal, al igual que mantenemos su profundidad de 16bits (1obits). Obtenemos una imagen mucho más fiel a lo que realmente capturó originalmente el sensor.

 

3. Salida RAW pura (sin interpolar), escalada y sin escalar: dcraw -v -c -4 -d/-D Camera1_bayer10.bayer > Test3.pgm

Cuando hablamos que la imagen no está interpolada, significa que no se ha revertido el filtro Bayer. Como ya dijimos no es que la imagen esté en escala de grises, es que realmente cada pixel corresponde a la intensidad de un color concreto. Esta imagen la hemos visto anteriormente. Si se representase en vez de en escala de grises en color, el resultado sería la imagen verdecina que vimos anteriormente. Por lo general, cuando se representan las imágenes sin deshacer el mosaico Bayer, es así como lo hacemos.

Por otro lado, hasta ahora todas las imágenes que se han puesto están escaladas. ¿Que significa esto? Recordar que estamos tratando con imágenes de 16 bits de profundidad y encima lineales. Eso quiere decir que en teoría cada pixel de dicha imagen puede tomar un valor entre 0 y 65535 (debido a los 16bits), y que debido a la linealidad “empezamos” en el cero (negro absoluto, ausencia de fotonos). Pero en cambio el blanco absoluto no existe como tal concepto, dado que el sensor en teoría siempre podría ser más sensible, captar más fotones y aumentar el valor aun más, con lo que hablaríamos del concepto llamado blanco más allá del blanco. Por eso vemos siempre una condensación en el extremo izquierdo en fotos lineales. Bien, ya hemos hablado de la linealidad, ¿pero el escalado? Bueno, es útil/necesario por dos motivos. El primero como se ha dicho debido a la linealidad y la compresión en el lado izquierdo, pero también porque nuestro sensor no es sensible a 16bits, es decir, a los 65536 posibles valores. Para 10bits, nuestro sensor “solo” es capaz de distinguir entre 1024 valores diferentes (recordar que todas las imágenes que vemos en fotos y otros generalmente están a 8bits, 256 valores diferentes), con lo que a efectos prácticos si no escalamos los valores esta sería negra o prácticamente negra entera (de ahí que no vaya a poner una imagen haciendo la prueba). Esto se soluciona de un modo sencillo, y es multiplicando literalmente el valor de cada pixel. En este caso tenemos 10bits = 1024, 65536 / 1024 = 64. Es decir, un factor de escala de x64. Dado que el sensor no es capaz de ir más allá de los 10bits, no vamos a tener pérdida de información, aunque por supuesto no se nos escapa que si el sensor fuese más sensible podríamos captar más detalle en los colores.

Si hacemos, esto, si escalamos la imagen, el resultado pasa de ser negro a ser la imagen que he puesto anteriormente. El parámetro d/D en Dcraw especifica siempre que la salida será sin interpolar, sin deshacer el filtro Bayer, la elección de un parámetro u otro, es que D no escala la imagen, mientras d la escala automáticamente en función del valor que el estima que es el adecuado analizando internamente la imagen. En este caso acierta, y aplica un escalado de x64. Hay que indicar que el mismo resultado lo podemos obtener perfectamente sin escalar la imagen, y haciéndolo manualmente. Por ejemplo en Photoshop, podemos acceder a los ajustes de niveles de la imagen y modificar la salida. Photoshop independientemente de la profundidad de color que se use, usa sliders de 256 valores, pero pese a que sólo muestra 255 saltos mantiene igualmente la información intacta y escala en función a ello. En este ejemplo concreto si no escalásemos la imagen, para tener el mismo resultado tendríamos que desplazar el slider de photoshop al valor 3. Sí, desplazar el medidor derecho que está en 255 al 3. Y magia, la oscuridad desaparece (256/64 = 4, 3 teniendo en cuenta que el cero cuenta.)

 

4. Conversión lineal, interpolada, escalada, con ajuste de balance de blancos, y otros: dcraw -v -c -4 -T -a -k 50 Camera1_bayer10.bayer > Test1.tiff

El parámetro k permite especificar el punto negro. Dado que escalamos la imagen, esta tiene a desplazarse hacia la derecha, haciendo que se produzca un “agujero” en la zona inferior. El cero absoluto originalmente es el cero, pero si cuando se tomó la imagen el valor más pequeño era el 100 (por ejemplo), al multiplicarse por 64 deja un hueco más… “grande” en el negro. Este ajuste permite desplazar de nuevo la imagen hacia la izquierda, restaurando el negro “puro”. Obviamente eso produce un oscurecimiento generalizado debido a que el desplazamiento es a toda la imagen, cosa que luego se podría corregir. Aun en este punto la imagen seguiría siendo lineal.

El otro punto importante es el balance de Blanco. El sensor capta lo que capta, y aquí no está calibrado hacia nada. Es por eso que la imagen se muestra verdosa si se interpola y no se toca nada más, los colores no son los que deberían de ser. El ajustar el balance de blancos pone punto y final al problema. Por desgracia esos ajustes dependen de la fotografía tomada y del sensor. Dado que no tenemos datos más o menos fiables del sensor, sólo podemos probar diferentes ajustes en función claro está de lo que vemos… prueba error. Dcraw incluye el parámetro “a” que permite evaluar la imagen completa y estimar el balance de blancos adecuado, pero como todo es siempre relativo. Por ejemplo para la imagen anterior, dcraw calcula que los valores adecuados para el balance de blancos sería:

1.122304 1.000000 1.947417 1.000437

Dcraw especifica el ajuste de blancos multiplicando cada componente (antes de la interpolación por supuesto) por un valor concreto. En un filtro Bayer tenemos 4 componentes recordemos, en nuestro caso es un sensor RGGB, así que cada multiplicador se aplica a cada uno de ellos, aunque no en ese orden. El orden de aplicación es R G1 B G2. Si nos fijamos, la imagen es muy verdosa, y efectivamente ambos componentes tienen un valor de 1 (o cercano a él). Por el contrario aumenta de forma considerable el componente azul. La imagen resultante es mucho mejor, pero como es natural no está a la altura.

Si creásemos el parser como un complemento en Photoshop para CameraRaw, este tipo de cambios serían totalmente interactivos, al igual que lo usamos para otro tipo de formatos. Por desgracia Photoshop no tiene forma humana de interpretar nuestro archivo, pese a que no es muy complejo. Eso nos “limita” en tanto que si queremos realizar un ajuste de blancos antes de la interpolación, lo tenemos que hacer manualmente. Por supuesto podemos corregir luego todo lo que queramos a la imagen, pero recordemos que ya será sobre la imagen interpolada. De cualquier modo, aun estaríamos con una imagen lineal, y de ahí la apreciación de una imagen “triste”, sin un colorido importante. Ya hemos dicho que el ojo humano no percibe la realidad igual que la tecnología, así que para que la imagen se ajuste a algo más vistoso, el paso final sería retocarla en cualquier editor para romper la linealidad y ajustar correctamente el resto de parámetros.

 

Apuntes finales

Aunque la modificación realizada a Dcraw afecta únicamente en primera instancia al Mi6, es extrapolable a cualquier otro teléfono o dispositivo que sea capaz de capturar imágenes de un modo similar. Gracias a la granularidad de Dcraw, añadir o quitar “perfiles” de cámara es sencillo, y si usan un sensor similar o un sistema que transfiera los datos de igual modo, es suficiente con añadir resolución, tamaño y patrón bayer correspondiente a la lista. No importa que sea un Mi6 o un Mi5 o por supuesto terminales de otros fabricantes, si la cámara reporta que es capaz de capturar RAW en algún formato, podemos añadirlo. Como es lógico, añado sólo el terminal con el que he andado jugando, pero animo a cualquiera que pruebe si le interesa.

No me gusta distribuir binarios, prefiero que el usuario se las apañe y aprenda a compilar por si mismo, pero dado que voy a publicar la herramienta en otro lado también, no creo que haga mal en esta ocasión a nadie distribuirla, y ahorrar el trabajo a algunos. La versión usada es la más actual hasta la fecha de Dave, 1.477, que he cambiado a 1.478. Los únicos cambios realizados son los expuestos: Añadir el parser, desdoblar la rutina de reconocimiento de 10bits para llamar al parser e incluir el Mi6 dentro de la tabla de cámaras. Realmente debido a las pruebas que hice tengo creado 4-5 parser diferentes, pero a efectos del código compilado es indiferente:

Enlace a dcraw compilado

 

Dado el interés que se han tomado algunos, en la medida que tenga tiempo y me manden los archivos necesarios, añadiré soporte a otros dispositivo, incluyendo obviamente el Mi6.

 

Actualizado (15 Sept 2017):

Soporte adicional para los siguientes dispositivos:

-Xiaomi Mi 6
-Xiaomi Mi 5

Cuando te plagian artículos y aun así niegan la mayor

Share on Google+Share on FacebookTweet about this on Twitter

Esta no era precisamente la siguiente entrada que tenía pensado publicar, y por desgracia, a diferencia de tantos otros temas que hemos tocado, es de las pocas veces que creo que voy a usar mi propio blog a modo de reivindicación, indignación y también sorpresa. Así que hoy, lo siento, la poca tecnología de la que se va a hablar es debido a que el artículo en cuestión tocaba dichos temas, pero poco más. Con vuestro permiso, como siempre, dejadme que os cuente la historia de estos días atrás… por supuesto desde mi punto de vista y con los datos e información que he tenido, pero cada cual saque sus propias conclusiones, además de creer lo que crea oportuno. 

Además no está mal recordar algunas cosas que creo forman parte de la moral/ética, que a veces se olvida en Internet.

 

Antecedentes

Soy alguien que defiende las libertades, empezando por la libertad de expresión, por supuesto con educación y con un mínimo de cabeza. El principal motivo por el que hace ya muchos años abrí este pequeño espacio, y no es la primera vez que lo digo, fue para tener la libertad de escribir sobre cualquier cosa que quisiese sin preocuparme que cualquier tipo de politiqueo pudiese censurarme de modo alguno. Por aquel entonces frecuentaba mucho un par de foros, pero al final por no ser políticamente correcto siempre terminaba igual. Aquí encontré un lugar mucho mejor, y pese ser un amante de la tecnología, lo bueno de estar en la propia casa de uno es que no hay más normas que las que uno pone, y si quiero hablar del tiempo, de política, de sociedad o de lo que me de la gana, lo he hecho. Pero siempre he intentado mantener unas normas básicas, incluso en casa propia creo que es necesario, evitan el perdernos a nosotros mismos, evitan convertirnos a veces en aquello que decimos detestar o que incluso criticamos. No hablo de una larga lista, es algo muy básico y que en lo personal creo que es esencial:

Respetar siempre tanto al lector como a cualquiera que quiera dejar su comentario. Aquí no hay censuras, los únicos comentarios que he editado a lo largo de los años han sido siempre por razones de SPAM (los cuales no edito, los borro directamente) y aquellos que insultan o faltan el respeto a otros (no he tenido casos de racismo, apologías y otros, como es natural, es de sentido común que serían eliminados). Siempre he dicho que aquí todos somos caballeros, y con educación y buenas formas podemos hablar de todo, aunque a veces no estemos de acuerdo.

Pero hace muchos años que entendí que la buena voluntad no vale para todos, y eso obliga por desgracia a optar por medidas que no siempre gustan, y que básicamente coartan de algún modo libertades que de otro modo se podrían tener. Es de lo que hoy hablamos, de la propiedad intelectual, específicamente en este caso del contenido propio que uno genera. Esa es la razón por la cual en el pie de página de mi blog aparece las condiciones generales en las que se distribuye todo el contenido que yo escribo. No, no tengo una página de políticas o condiciones de uso, eso no va conmigo, sólo dejo claro que el contenido en todo mi blog, obviamente a menos que se especifique otra cosa, está bajo licencia Creative Commons BY-NC-ND. Es decir, en esencia dicha licencia dice que absolutamente todo lo que escribo puede ser usado siempre y cuando:

a) Atribución: Se especifique el origen del artículo así como su autor (yo en este caso). Normalmente ni siquiera me suelen citar por nombre/apodo, con decir que es de otro y enlazar a la fuente original me doy más que satisfecho siempre
b) No uso comercial: Se pude usar siempre y cuando dicho uso no conlleve directa o indirectamente una retribución económica
c) No se permite la creación de obras/trabajos derivados

Esta decisión no fue arbitraria, fue necesaria. Recordar por cierto que esos términos son generales, como ha sucedido estos años montones de veces, cuando alguien ha necesitado o ha querido “saltar” alguna de esas limitaciones, se ha puesto en contacto conmigo, y creo que prácticamente casi siempre les he dado luz verde… exceptuando el uso comercial, que rara vez lo he permitido.

No tengo ninguna necesidad de reconocimiento, esta “Almas Oscura” no busca número de visitas ni salir en las noticias, creé esto para contar historias, a mi modo y de lo que yo quisiese, y siempre he dicho que el mejor pago siempre fue que todo lo escrito pudiese ayudar a otros. Pero cuando vives en un mundo en el que por desgracia no todo el mundo comparte la misma visión de las cosas, y cada cual tiene su propia ética/moral, tienes que poner límites. Si alguna vez os topáis con alguien que coge un trabajo vuestro, lo destroza, hace un uso fraudulento de ello, me entenderíais. Una forma para luchar contra esto es obligar ha citar la autoría de dicho artículo y a no permitir obras derivadas. Podría explicaros todo esto de forma mucho más extensa, pero terminaríamos al final con mis artículos eternos 🙂

Y sobre el uso comercial bueno… creo que se deduce por mi modo de pensar. No soy alguien que se venda, lo que escribo es para todos, no para unos pocos. No quiero que nada de lo que sale de aquí pueda formar parte de un libro publicado por una editorial, o una revista que cobra a sus afiliados o… eso no va conmigo. Entiendo perfectamente que otros quieran hacerlo, no lo critico, simplemente como no quiero que ese sea el papel de lo que escribo, no lo permito. Ya he dicho que no me importa el reconocimiento, me da igual que por ser publicado en una revisa importante o en una gran editorial me diese renombre, no es lo que quiero

Bien, dicho todo esto, volvamos al caso… como muchos de los presentes habituales sabrá, hace ya unos meses hice una publicación (realmente la anterior a esta) por hartazgo de llevar días escuchando hablar sobre certificados SSL, sobre si Let’s Encrypt hacen un buen papel o no… y otras cosillas. Vamos, el artículo lo tenéis abajo como digo:

HTTPS no añade legitimidad o credibilidad a una Web, brinda seguridad

Tengo la mala/buena costumbre de explicar en el propio artículo el motivo por el cual lo he redactado. A veces es una idea tonta que me surge en la cama, otras veces algo que leo, otras veces algo que veo en la televisión, otras veces algo con lo que me estoy entreteniendo… y ese en particular fue a raíz de un artículo que leí en su día de Xakata.

Bien, hasta aquí todo normal, sólo diré de momento y para terminar este previo, que, y cualquiera lo puede comprobar tanto en R.R.S.S, RSS, blog y otros medios, dicho artículo fue publicado el 31 de Marzo de madrugada, sobre las 6.00 de la mañana, su artículo por contra, oficialmente fue entregado a la revista y por tanto terminado el 31 de Marzo sobre las 9 de la mañana, unas 3 horas más tarde… que como veremos, evidentemente no fue un dato que el me diese.

 

Sorpresa

Como casi siempre me pasa, estoy en otras cosas y de pronto lees algo que te llama la atención. En este caso fue una “noticia” que apareció en mi feed de Google Now hará unos 3 días. Para quien ande despistado, Google Now es un servicio de Google que te muestra de forma ordenada y sistemática información que puedas desear en cada momento, como noticias, el tiempo y otros. Bien, pues entre otras noticias que me aparecían, me apareció el siguiente titular:

“Aviso a navegantes: HTTPs implica seguridad, no legitimidad”

Obviamente no es de esos que eliminas del feed directamente porque no interese, principalmente porque lo primero que pensé fue un: “Ey!! Alguien me ha vuelto a citar, es mi último artículo”. No había entrado aun en el artículo, pero el titular era obvio, no era literalmente el que yo había puesto (que en ese momento ni me acordaba cual era mi título exacto), pero como digo obviamente era el mío… de echo si leemos los dos, literalmente es el mismo titular cambiado de orden las palabras. Bueno puse como hago siempre que veo mis artículo en algún lado, voy a la web que lo publica, no por control, al revés, me gusta ver quienes me han usado/citado, siempre me hace ilusión que divulguen mi trabajo, eso significa que ha gustado.

Por desgracia lo que me topo es un escenario con el que me quedo perplejo. El artículo está firmado por un tal “Pablo E. Iglesias“, y publicado en una revista “alternativa” perteneciente a voz.com. A su vez, el señor Iglesias trabaja parece ser como asesor y “Analista de la información”, y forma parte del equipo de una consultora llamada “SocialBrains”. Bueno, pensé, no es más que una enorme casualidad en el titular, me hace gracia, ya de camino, como no puede ser de otro modo, voy a leer el artículo. A este punto, invito a todos los que no se hayan leído mi artículo previamente citado que lo hagan, así como leer el artículo del señor Iglesias.

Al terminar de leer, ver la imagen de Paypal, de la “cita” que hacen en la revista, y de volver a releerlo por perplejidad, empecé a reírme:

“¿De verdad? Está claro que no han cogido mi artículo y han hecho un copiar/pegar, pero no significa que no me lo hayan plagiado de arriba abajo. Sí, está redactado de otro modo, y no hace uso de todo mi artículo original, sólo trozos de él que camufla entre otras líneas. Pero es imposible negar el plagio, no, no es un plagio total, es sólo parcial, pero sigue siendo plagio. Empezando por el titular que es prácticamente calcado, Let’s Encrypt, mi ejemplo de PayPal, el asunto de Symantec… e incluso algunas otras frases redactadas de otro modo.”

Bueno, eso es lo que yo llamo una obra derivada, sin contar que aun peor, se adjudica la autoría de dicho artículo… bueno técnicamente hablando su artículo lo ha escrito él, basado en el mío. Así que sin ningún tipo de mala voluntad por mi parte, os lo puedo asegurar, procedo a ponerme en contacto con el señor Iglesias para aclarar el asunto, instándole a optar por una de las siguientes dos opciones: Una retribución económica en caso de que quisiese que todo se quedase en el ámbito privado, o por el contrario que menos que una disculpa pública de haber plagiado mi trabajo.

No soy perfecto, nadie lo es, y creo que todos podemos meter la pata en cualquier momento. Para mi nunca ha sido humillante tener que disculparme, al contrario, eso siempre me enseña algo nuevo, y creo que nos hace mejores personas. Os puedo asegurar que si me pasa algo similar, tardo minutos en hacer una disculpa pública, aun sin que me lo pidiese la otra parte.

El señor Iglesias me respondió… en su propia web por cierto antes que por correo, pero tengo que decir en su defensa en ese caso que yo fui primero quien contestó en su propia web que dicho artículo era un plagio (parcial) al mío… momento en que busqué su correo y me puse en contacto con él directamente. La comunicación que he tenido con él no ha tenido desperdicio.

 

Argumentos y ¿Pruebas?

Al tiempo recibí contestación por su parte, y para más sorpresa, lejos de disculparse de nada, tan sólo niega la mayor. Pondría los correos de buen grado, pero por temas legales prefiero de momento (al menos) no hacerlo. Aun así, todavía se pude ver en su blog prácticamente lo mismo que me manda por correo, aunque redactado de otro modo, pero básicamente es eso. A continuación argumenta que su artículo se debe a la noticia de Symantec que sucedió por aquellos días, y que a raíz de aquello lo mandó a la revista.

Bien, en mi artículo, hablo de lo que pasó con Symantec esos días. Resumiendo, Google se mosqueó con ellos por emitir estos (Symantec) certificados de tipo EV sin controles más rigurosos. Esa es la razón por la cual dice en un primer momento Iglesias que le llevó a escribir su artículo, y por otro lado a pesar de decir que tenía registros (ambas partes, él y la revista) de la entrega de dicho artículo, nunca los presentó.

Es de risa… al margen de noticias, razones y de otros, cuando tienes una evidencia tan grande, que es el contenido del propio artículo en este caso, el resto ya sobraría, sólo con el contenido de su supuesto artículo y del mío, automáticamente queda demostrado el plagio. Pero no, para que reconocer algo, el prurito y ego del ser humano, que van a pensar de mi mis compañeros de trabajo, la revista y a fin de cuenta el “reconocimiento” que puedan tener de mi en Internet.

La evidencia del contenido, en un primer momento es indiferente. El sencillamente se “defiende” diciendo que él sólo se hizo eco de la noticia de Symantec al igual que hicieron muchos. Por cierto, eso es también bastante dudoso.., Yo en mi artículo explico lo de Symantec como de pasada, no escribí mi artículo por ello, lo escribí a raíz de lo de Xakata y de mi artículo anterior de Let’s Encrypt y el acaso y derribo que se había tenido con ellos. Lo de Symantec lo metí porque es cierto que pasó por aquellos días, y quería dejar patente que es realmente un certificado fraudulento de uno que puede ser usado con fines fraudulentos. Para Iglesias, según el cuenta, todo su artículo era una “simple” noticia del caso de Symantec.

Por supuesto le contesté a su correo, y aun bastante comedido, pero entiendo que tampoco tendría que haber tenido contestaciones tan grandes, me pasa por idiota y querer obrar de buena fe. Lo primero que le contaba en mi correo es que cuanto menos tenía que ver la inmensa similitud de ambos artículos (cosa que a día de hoy no ha sido capaz de reconocer tampoco),  y que de cualquier modo se podía resolver de un modo inmediato, si de verdad tenía dichos registros, problema solucionado. Hay que destacar que Iglesias no publicó hasta hace unos días dicho artículo en su blog, pero según me dijo desde un principio lo había entregado mucho antes a la revista, ya terminado. Todos estaremos de acuerdo que es algo extremadamente sencillo!! Tenemos por un lado la propia revista y tenemos por otro lado a él, vamos a ver dichos registros, si su artículo fue entregado antes de la publicación del mío, señores, asunto arreglado.

No sólo eso, le dije que por favor me los enseñase, que sería el primero en disculparme públicamente tanto en su web, como en mi propio blog de ser así, no sólo eso, sino que además sería el primero gratamente sorprendido de una casualidad así. Evidentemente si él me hubiese conocido un poco mejor entendería que, pese a que lo decía totalmente en serio, no significaba que tuviese ningún ápice de duda del plagio, no necesito ver un registro, el contenido ya lo estaba viendo. Y creo en las casualidades, pero no en los milagros.

Que sí, que pueden existir casualidades, pero intentar defender que su artículo pudiese ser similar al mío porque ambos nos basamos en la misma noticia (realmente yo no me basé en ella), es un argumento un poco cojo. Mi artículo, y el suyo por ende, son artículos de opinión, no una noticia, no era explicando una noticia que había salido, ni siquiera él, que decía que por eso lo escribió, nombra Symantec de forma directa, y lo nombra como yo, de pasada. Las enormes coincidencias de ambos artículos no dejan margen de duda, como pudiese ser el caso Symantec, el titular, el ejemplo de Paypal, Let’s Encrypt y las críticas que han tenido por la emisión de certificados… etc etc etc.

Entonces recibí su segundo y por ahora último correo, dudo enormemente que vuelva a contactar conmigo, lógicamente. Este fue aun mejor, en su blog me lo hace llegar también:

“Por privado te he pasado una de las pruebas que confirman que no se trata de un plagio. De hecho yo lo escribí un día antes de que tú lo publicaras.”

No estoy diciendo que la “prueba” que el me muestra sea falsa o haya sido modificada, que por otro lado sería trivial para cualquiera que tenga unos conocimientos mínimos, me refiero a que si quieres zanjar un asunto así, y creo que es lo que haríamos todos, es mostrar como prueba sencillamente el registro de salida/entrada de cuando el artículo fue enviado a la revista, ni más ni menos. Pues no, no me enseña eso, todo lo que me enseña es una captura de pantalla del versionador (revisiones) interno de WordPress, en el que se puede apreciar la fecha de la 1º edición (30 de Marzo), y debajo lo que parece ser un borrador de su artículo, y digo borrador porque sólo se ve el título y y un par de párrafos. Sobre el título, tengo que decir que era ya diferente: “Seguridad no implica identidad”, eso repito si tomamos por buena dicha captura y presuponemos que no hay nada modificado. El señor Iglesias dice que lo escribió un día antes y su prueba es la “apertura” en WordPress de un artículo… si, muy creíble.

Me siento ofendido señores. Entiendo que alguien que se vea ya de lleno en el “problema” quiera intentar defenderse como pueda, pero insultar al sentido común o creer que puedo tener 3 años… eso me lo tomo ya a lo personal. Vamos a ver… en la captura se ve que la línea temporal del artículo (de las diferentes revisiones) empieza efectivamente el 30 de Marzo, pero es muuuucho más larga…  ¿y me enseña la primera? ¿pero cual es la última modificación? No dudo que pudiese tener en mente o incluso que hubieses empezado a escribir un artículo cualquiera, eso me es indiferente, no me preocupa el borrador que pudieses tener. Ya podría tener igualmente ese borrador de hace 2 años. Por favor… con lo sencillo que hubiese sido, si hubiese sido cierto, de enseñar el correo en el que se enviaba el artículo terminado, o por supuesto la última revisión de su artículo, o… y lo que haces es enseñarme (repito, en el mejor de los casos y que no hubiese modificado NADA para camuflar más cosas, que sé que ha hecho) una captura de cuando empezó a escribir el artículo?? Tengo borradores en mi blog de hace más de 2 años, y algunas entradas que he publicado llevan en borradores tantos otros, que por supuesto antes de publicar los modifico o actualizo. Querer pasar de prueba algo tan subjetivo, teniendo en cuenta lo rápido y directo que hubiese sido enviar una prueba firme, es un insulto a la inteligencia.

Señores, si alguna vez me veo en una situación así, si yo fuese él y cualquiera llama mañana diciéndome cualquier cosa que sea mínimamente parecida, es que ni siquiera espero que me pida pruebas, es que en el primer correo que le mando no tiro balones fuera, y primero exalto la gran casualidad, le invito incluso a tomarnos una cerveza por pensar de un modo tan parecido a mí, y como adjunto al correo, le añado fechas y horas de cuando fue hecho público. Y si por el motivo que fuese, no es algo que transcendiese al ámbito publico aun, como fue su caso puesto que el no lo publicó hasta meses después, le hago captura del correo que envié con el artículo terminado, le mando registros del servidor en la medida de lo posible e incluso timestamps de archivos y otros. Que sí, que incluso todo eso puede ser modificado, pero al menos hago lo posible para que se quede tranquilo y contento. No espero que me pidan pruebas, no envío información sesgada, interpretable, ambigua… por favor, seamos un poco adultos.

Termina con una frase rotunda, sobre que yo no conozco el mundo digital y sobre que las personas pueden creer tener ideas únicas cuando no lo son. Su contestación en su blog, que es en parte la misma que me hace a mi por correo:

“Espero que para la próxima seas consciente de que las ideas que tenemos no suelen ser únicas, y que es probable que incluso otros ya hayan pensado en ello y dejado pruebas de tal hecho.”

Como todos saben yo acabo de conocer esto de Internet y del mundo digital, llevo aquí sólo un par de días… El señor Iglesias aun estaba intentando convencerme o hacerme creer que dos personas que no se conocen absolutamente de nada pueden tener la misma idea (o similar),  en las mismas fechas y encima para colmo plasmarlo de un modo semejante. Si es que me entra la risa tal como estoy escribiendo.

Claro que sí señor Iglesias, esa cosas pasan en el mundo digital, y estoy seguro que en 1905 le pasó también al gran Albert Einstein, cuando publicó su teoría de la relatividad, todo el mundo sabe de ese otro paisano Alemán que que salió para decir que, semana arriba o semana abajo, también tuvo la misma idea, y que escribió una publicación similar al respecto.

(Nota: Obviamente la alusión al gran Einstein es puramente con motivos jocosos e irónicos, en ningún momento estoy comparando a uno de los más grandes de toda la historia con mi persona, ni por supuesto su trabajo con el mío, hasta ahí podríamos llegar. Lo digo más que nada por si alguien no es capaz de captar el humor de mis palabras)

Creo en las coincidencias, claro que pienso que puede suceder que dos personas no sólo lleguen a tener la misma idea, sino llegar a las mismas conclusiones. Eso lo veo plausible. Lo que es yo diría imposible o milagroso es que además eso pasase en las mismas fechas y encima que ambos lo plasmasen con un grado de exactitud tan enorme. Eso ya no es casualidad, y sí, tiene nombre, se llama plagio.

 

Conclusión

No he vuelto a tener noticias de él. El último mensaje que le puse en su blog no lo ha publicado, el último que ha dejado es el que puso cuando me envío el correo con su gran prueba… en realidad lo entiendo, si ha negado la mayor no va a permitir en su blog comentarios por mi parte tirando por tierra sus afirmaciones una a una, y con pruebas sólidas.

Ah, es verdad, pruebas… se me olvidaba.

En lo que me compete, como entenderéis, no necesito pruebas de nada. Creo que cualquiera con dos dedos de frente que se lea ambos artículos va a llegar a la misma conclusión. Pero es verdad que aun así hay quienes prefieren agarrarse al clavo ardiendo, aunque sea una posibilidad entre 100 millones, puesto que aceptar que pudiese ser cierto (que su artículo era un plagio) para algunas personas, implicaría bastante más que simplemente una equivocación puntual. Como ejemplo sencillo, esta misma mañana me escribía por Twitter públicamente el que creo que es un compañero suyo de SocialBrains (por lo que pone en su Twitter), y me decía lo siguiente:

“@Theliels te aseguro por lo más sagrado que se te ocurra que lo último que haría @PYDotCom sería robar contenido. Le conozco muy bien.” “perdóname, pero no, nunca, bajo ningún concepto. Llevo años trabajando con él y sé que NO es capaz. Cuanto más insistas, más disculpas debes”

Como le contestaba igualmente por Twitter, por desgracia no conocemos tan bien a los que tenemos al lado. No conozco a Iglesias, no dudo que pueda ser un gran compañero y por supuesto que pueda ser generalmente un buen profesional en todo lo que hace. No tengo nada personal en contra de él. Sencillamente le critico que haya plagiado un artículo mío y que lejos de disculparse quiera hacer creer a todos que es sencillamente algo casual. Porque por supuesto el sí que no pude decir que yo le haya plagiado a él.

Esta mañana, antes de recibir el mensaje de Twitter de su compañero, me llegaba por correo la confirmación de la fecha/hora de entrega del artículo de Iglesias, gracias a la cortesía de la propia revista. Fechas y horas por cierto, que evidentemente el señor Iglesias tenía desde el primer momento, y nunca, en ninguno de sus correos ni de su blog se atrevió a poner. Es curioso, ¿verdad? Dice que tiene pruebas, dice que lo escribió el día antes, me muestra una captura de algo… y sin embargo alto tan simple como decirme sobre que día y hora entregó el artículo terminado lo omite. No estoy diciendo que de ponerme ese dato me lo hubiese creído, pero aunque sólo sea para tapar dudas, uno da la cara, y creo que es infinitamente más fiable, directo y menos sospechoso decir que el artículo se entregó/terminó/publico tal día tal hora, que ir a WordPress, ir al versionado, capturar pantalla… para adjuntar una captura que muestra el inicio de una entrada, que sólo se ven dos párrafos (podía tener más escrito, quien sabe).

No, me temo que por lo que se ve no lo conocéis bien. Para aquellos que quisiesen agarrarse al clavo ardiendo de que el contenido del artículo era sólo una casualidad y sacado de contexto y… añadir a todo ello que su artículo fue terminado después de publicar yo el mío

Después de toda la información que tengo… ¿que es lo que realmente creo que pasó? Sinceramente no creo que lo hiciese con demasiada mala intención. Lo que imagino, y esto es ya pura especulación, es que tendría que entregar un artículo antes de finalizar el mes, y que a día 30 aun no lo tenía terminado, quizás sea la razón por la que en su artículo se puede apreciar que hay… “dos partes”, una que es mucho más diferente a mi artículo donde las similitudes son menores, y una segunda parte donde sucede lo contrario, y las casualidades y similitudes son constantes. Supongo que le cogió el toro, tenía que enviarlo a más tardar el día 31, se quedaría trabajando con el el 30 para terminarlo el 31. El 31 se levantaría temprano, vio mi artículo, le gustó, cogió de él lo que estimó y las prisas hicieron que conservase incluso algunas frases de forma literal, como el título final, ejemplos… y en un santiamén estaba listo, y lo envió.

Para mi lo más importante no es que se pueda usar mi trabajo para adjudicárselo otro (que ya es duro), sino el poco estilo de al menos ser capaz de reconocer las cosas. Al final, yo en el peor de los casos no pierdo ni gano nada, nadie puede poner en tela de juicio mi artículo, y en todo caso a alguien le pueda caer peor por molestarme porque otro plagie mi trabajo, pero nada más. Por su parte, y ya se lo dije en el correo, lo peor que pudo hacer fue desde un primer momento no reconocerlo. No estoy diciendo que alguien que no haga nada tenga que reconocer algo, pero hombre, en este caso creo que esa opción está totalmente descartada… me refiero desde su propio prisma, si yo fuese él y me están diciendo que “me han pillado”, cabe dos opciones: Que la otra persona lo deje pasar o que al final puedas verte en un problema de verdad.

Teniendo en cuenta que no le di una sola oportunidad sino varias, y de muy buenas formas, tenía cuanto menos que pensar que quizás no lo iba a dejar pasar. En el mejor de los casos para él y que todos (su circulo) lo defienda, las pruebas son suficiente cuanto menos para un poso de desconfianza hacia su persona por parte de los mismos que lo defienden. Pero es que como le dije, y parece que creería que era una broma, la violación de la propiedad intelectual es un delito, y al margen de no tener ningún tipo de duda de lo sucedido y de tener todas las pruebas conmigo, visto su comportamiento, no me ha dejado otra elección, sólo espero que sea capaz de defender algo mejor su versión de lo sucedido, y con mejores pruebas, ante quien realmente le va a corresponder.

 

Como reflexión final… señores, todos nos equivocamos, incluso en cosas que pueden tener más repercusión que sencillamente decir “lo siento”. Estoy que voy a decir lo saben muchos que me conocen, lo aplico a la vida misma. Para mi, cualquiera puede cometer un error, y eso no lo convierte en una mala persona, sólo en humano. No importa lo grande que sea, todos la liamos en mayor o menor medida. La diferencia entre unos y otros no está en el tamaño de la equivocación, sino en que unos son capaces de reconocerla, y otros no. Con los primeros puedo compartir mi vida sin problema a pesar de sus defectos y de todas las putadas que puedan llegar a hacer, pero al menos puedo firmar de ellos. Con los segundos no tiene mucho sentido. Y no hablo de este caso en particular, que a fin de cuenta lo veo como un problema de ego desmedido y que por suerte resolverán los Juzgados, hablo en general.

 

Saludos a todos. Estoy seguro que el próximo artículo será mucho más halagüeño… realmente lo tengo terminado prácticamente desde hace semanas, pero creo que terminaré editándolo al menos en parte por no “mosquear” demasiado a los chicos de Xiaomi, que no creo que les siente muy bien eso de enredar en sus servidores.

Volver a arriba

Sobre Mí

Cambiar a la versión para móviles

Creative Commons License
Alma Oscura por Theliel is licensed under a Creative Commons Reconocimiento-No comercial-Sin obras derivadas 3.0 Unported License.
Basado en el trabajo de blog.theliel.es.
Para otros permisos que puedan exceder el ámbito de esta licencia, contactar en blog.theliel.es/about/contactar.