Átomos y Bits en redes sociales
|
Por Leonard, publicado el 02.02.12. ¡Buenas tardes, queridos lectores!
Hoy, para darles un toque polícromo a vuestras vidas, os traemos un tema muy amplio, curioso, y que observamos a diario sin darnos cuenta de ello muchas veces: el maravilloso mundo del color.
Hay que decir que este tema surge a raíz de mi última adquisición tecnológica, un monitor Samsung LED de 27 pulgadas (concretamente el modelo S27A550H, cuya información podéis encontrar en este enlace). Buscaba un monitor grande, no de gama alta, pero lo suficientemente bueno para poder jugar en condiciones a mis amados videojuegos. Partiendo de la base de que no soy ningún entendido en la materia, sí que he querido realizar una correcta configuración del color de mi pantalla para obtener los mejores resultados posibles y, así, he aprendido un poco más sobre todo lo relativo al color. Por tanto lo que aquí os presentamos es sólo un resumen en el que comentaré una serie de términos muy utilizados cuando trabajamos con colores, que conviene que conozcáis si queréis comprender mejor aspectos más avanzados del tema. Os recomiendo que, para obtener una información más profunda y detallada sobre el tema, visitéis el blog dZoom, del que hemos sacado la mayor parte de información para realizar este artículo.
Así, para empezar, si os encontráis en mi situación y queréis configurar correctamente vuestra pantalla, lo primero que tendréis que aprender es qué es la calibración de color, y qué es perfilar el color. El motivo de toda esta complejidad a la hora de “simplemente mostrar imágenes por pantalla” es que los monitores no pueden ofrecer toda la gama de colores que nuestro ojo puede ver, sino que sus posibilidades están acotadas a un determinado espacio de color fruto de su propia tecnología. Lo que nosotros entendemos por rojo, verde, azul y blanco, no es entendido del mismo modo por todos los monitores. Cada uno tiene su propia respuesta, con sus matices particulares, por lo que si queremos asegurarnos de que estamos viendo (por ejemplo) una fotografía con los mismos colores con que el fotógrafo la captó en su día y decidió guardarla, tendremos que preparar nuestro monitor para ello.
 Ejemplo típico de pantalla de calibración Por tanto, para comenzar a tener buenos resultados, nuestra primera misión será calibrar el monitor. Esto es, ajustar correctamente la luminancia del blanco (su intensidad), el tono del blanco (su temperatura, que trataremos más adelante), el nivel del negro (su profundidad) y la compensación gamma (una curva que trata de neutralizar el efecto del monitor compensando algunos factores, también la trataremos con más detalle posteriormente). Una vez calibrados los valores, podremos comenzar a perfilar el monitor, o sea, configurar la gama de colores que mostrará el monitor, y cómo compondrá dichos colores a partir de los básicos. Al proceso de calibrado y perfilado se le conoce como ajuste del monitor, y es lo que os desglosamos en los siguientes párrafos, mediante la definición de sus principales factores.
Como comentamos, el monitor no puede trabajar con todos los posibles colores existentes en la naturaleza, al igual que nuestro ojo no puede apreciar todas las posibles longitudes de onda de la luz (no podemos ver en ultravioleta e infrarrojos, sólo en el llamado espectro visible). Su abanico de posibilidades está limitado a un conjunto más o menos extenso de colores, conocido como espacio de color, que no es más que una región de un mapa de color… ¿queda más claro así? No hasta que expliquemos qué es un mapa de color, pero no os preocupéis, porque este extraño término hace referencia simplemente a una representación gráfica en forma de ejes en la que podemos ubicar todos los colores (en teoría), y definir un color a través de sus coordenadas en los citados ejes. El mapa de color más conocido es el CIE XYZ (que cumple algunas características curiosas, como que el color blanco se encuentra en las coordenadas 0.333, 0.333, o que los colores complementarios están unidos por una línea imaginaria que atraviesa el blanco). Pues bien, si de este mapa de color nos quedamos con una región específica, estaremos trabajando con un espacio de color. Los espacios de color pueden ser dependientes del dispositivo (o sea, son los que el monitor o impresora o escáner o chisme en general puede manejar, interpretar, ofrecer…) o independientes del dispositivo (que son los estándares fijados por la industria de una u otra forma, para poder tomarlos como referencia a la hora de caracterizar dispositivos). Los espacios de color independientes más conocidos son el sRGB, el Adobe RGB y el ProPhoto RGB (RGB deriva de las iniciales de red, green y blue, o rojo, verde y azul en inglés). Los espacios de color dependientes del dispositivo son los que configuran su gama de colores posibles, y se les suele conocer como “gamut”. Normalmente el espacio de color dependiente se suele expresar como un porcentaje de un espacio de color independiente, por ejemplo podemos decir que un monitor cuyo espacio de color represente el 95% del espacio Adobe RGB es un monitor de gama alta, y bastante caro (en torno a los 1.000 €). Si conocemos el espacio de color que utiliza nuestro monitor, podremos conocer los colores primarios (rojo, verde y azul) que maneja, que vendrán dados por su tono, brillo y saturación, cambiando de una pantalla a otra.
 Espacios de color Conocidos los posibles colores que puede representar nuestra pantalla, ¿cómo le indicamos qué color es cual? O sea, necesitamos saber qué valor enviar al monitor para que pinte el color del mapa que ocupe las coordenadas X, Y que queramos (que no tiene por qué ser lo que observaremos por pantalla, ya que eso vendrá a su vez afectado por otros factores que veremos, sino que simplemente es lo que nos gustaría que el monitor entienda que queremos que muestre). Pues bien, para ello se suelen usar los perfiles de color, que son ficheros .icc o .icm con información para describir la respuesta de color de un dispositivo, traduciendo para un programa los valores que él entiende a los valores que entiende el monitor.
Otro factor (nombrado anteriormente) con el que jugamos a la hora de establecer los colores lo más cercanos a la realidad posible con nuestro monitor (o con nuestra cámara de fotos) es la temperatura de color. Esta característica nos sirve para definir correctamente el blanco, o lo que nuestro dispositivo debe interpretar como blanco, y se mide en grados Kelvin, como si de una temperatura se tratase. Su importancia radica en que, a lo largo del día, la luz que observamos va cambiando. Determinadas tonalidades del espectro de luz predominan sobre las demás, tiñendo los rayos a su alrededor y afectando a la imagen percibida. Esta alteración se traduce en un desplazamiento en el espectro de color hacia el rojo o hacia el azul. La luz perfecta diurna se sitúa en 5.500 K, y su valor va cambiando según las condiciones atmosféricas, la hora del día, o dependiendo de la existencia de otras fuentes de luz.
 Temperatura color Las cámaras de fotos digitales suelen incorporar una función llamada “balance de blancos”, que compensa la forma en que la cámara capta la luz, ajustando los niveles de los colores básicos para obtener resultados lo más parecidos al original posibles. El funcionamiento de las cámaras permite seleccionar unas condiciones predefinidas (día nublado, luz de bombilla, fluorescente, soleado, etc.), o bien utilizar un modo de balance automático, que suele ser menos preciso que los modos predefinidos. Dicho modo automático funciona tomando como blanco la zona más brillante de la imagen, y como negro la zona más oscura, de forma que calibra el resto de colores en función a esos valores, tratando de compensar los efectos indeseados de la iluminación. También podemos realizar un balance manual de blancos, sin más que enfocar con nuestra cámara a un objeto de color blanco como un folio, de forma que lo que para nosotros (porque sabemos que es blanco) será un objeto blanco, lo será también para la cámara, con lo que el resto de colores se parecerán más a lo que deberían ser si no existiesen efectos de iluminación añadidos. Hay otros métodos que muchos aficionados a la fotografía utilizan para realizar un balance de blancos manual, como el Expodisc (un accesorio para la cámara fotográfica que puede resultar algo caro si sólo estamos iniciándonos) o la cartulina de tonos de grises. Pero también hay otros métodos caseros más rudimentarios y que a menudo dan buen resultado, como utilizar una tapa de un bote de Pringles de las antiguas (que eran menos transparentes que las de hoy en día), o bien un filtro de café. Si enfocamos a través de estos objetos, la lente recibirá una información lumínica que le permitirá compensar correctamente los diferentes colores, para que después al realizar la fotografía sin el objeto delante podamos obtener resultados de mayor calidad.
 Diferentes balances de blancos para distintas temperaturas Continuando con los parámetros más importantes a tratar, y sin que el orden tenga que ver con su importancia, hablaremos sobre la gamma, que ya hemos nombrado anteriormente. La gamma es un factor de compensación que forma parte de una ecuación cuya curva trata de neutralizar la respuesta no lineal que el monitor introduce a la imagen que queremos mostrar en él, en lo que a luminosidad se refiere. Y es que en las pantallas la luminosidad no depende linealmente del voltaje, sino que sirve una curva exponencial. Ello hace que cuando queremos mostrar un valor de luminosidad media por pantalla, no tengamos que enviar un voltaje medio a la misma, sino más alto. De no corregir este comportamiento, tendríamos que las imágenes que observamos son más oscuras de lo que en realidad deberían ser. Al contrarrestar este comportamiento con la curva de compensación gamma, logramos una relación más lineal entre la entrada y la salida. Los fabricantes incorporan su propia curva gamma a los dispositivos, cuya ecuación exponencial puede resumirse como:
Luminosidad=voltajeG
con un valor G=2.2 habitualmente. Hay quien dice que no debería ser necesario utilizar compensación con los nuevos monitores con conexiones digitales, ya que la información permanece incorrupta desde el ordenador a la pantalla, pero lo cierto es que ajustar el gamma puede producir muy diferentes efectos en lo que observamos, y de hecho suele usarse a menudo en juegos para conseguir una ambientación adecuada al género del que se trate. La compensación de la gamma suele dejar el valor final (o sea, el resultante de la gamma original del monitor y la gamma de corrección) en aproximadamente G=1.14, pero esto no siempre es así, ya que para una determinada entrada, la salida no siempre puede definirse linealmente (y no hablamos ya sólo de luminosidad, sino de todos los factores que afectan a cómo se ve un pixel en pantalla). La respuesta del monitor presenta irregularidades que hacen que sea necesario aplicar una nueva curva de corrección para obtener una graduación más fina de los colores. A esta curva se le denomina curva de ajuste, y su información se almacena bien en una tabla LUT (Look-Up Table) en la tarjeta gráfica o bien en el monitor (si dispone de LUT). La tabla LUT presenta una serie de equivalencias entre los valores que se desean mostrar y los que hay que enviar al monitor para que los muestre. Cuantos más bits tenga la tabla LUT, más precisión permitirá mostrar en los resultados (no es raro encontrar tablas de 8 ó 10 bits).
 Cuadro correspondencias de Gamma. El cuadro que mejor se confunda con el fondo nos da una aproximación del gamma de nuestro monitor. Siguiendo la línea de lo comentado hasta ahora a la hora de realizar la calibración del monitor, hay otros dos aspectos que requerirán nuestra atención: el ajuste del punto blanco y el ajuste del punto negro. Para comprenderlos, debemos definir algunos términos:
- Por una parte, hay que conocer qué es la luminosidad o luminancia del blanco. Se mide en cd/m2 (donde cd es la abreviatura de candelas), y nos informa de la intensidad que toma el monitor para representar el color blanco. Nos interesará que sea un valor lo más bajo posible (en monitores de buena calidad, estará entre 60 y 90 cd/m2, y en pantallas de portátiles de calidad puede superar 115 cd/m2).
- Por otra parte, también aquí influye la temperatura de color. Normalmente resulta que para obtener un blanco lo más neutro posible, tendremos que elegir temperaturas tirando a frías. Se suele utilizar a menudo el valor de 6.500 K para obtener buenos resultados.
- Además, también es muy importante la luminosidad del negro, que se mide en las mismas unidades que la del blanco, y que de nuevo nos interesa que sea el menor valor posible (menores de 0’5 cd/m2 si es posible). Esta magnitud cambia enormemente dependiendo de la tecnología con que esté hecho nuestro monitor (CRT, TFT, LED…).
Asociado a estos conceptos de luminosidad, está el archiconocido contraste. El contraste se define como la relación entre la luminosidad del blanco y la del negro. Nos interesa un monitor que tenga un gran contraste, pero no a costa de conseguir una gran luminosidad del blanco (que puede llegar a dañor nuestros ojos tras un uso prolongado), sino gracias a tener negros muy poco luminosos y blancos lo suficientemente bajos para obtener buenos resultados. Volviendo al ejemplo del monitor que he adquirido, presenta un brillo según sus especificaciones de 300 cd/m2, lo cual le deja totalmente fuera de la gama de monitores profesionales, porque utiliza demasiada luminosidad del blanco para obtener una buena relación de contraste.
Merece la pena comentar que, más allá de usar nuestro “ojo clínico” para tratar de encontrar los mejores valores de los parámetros que hemos comentado hasta ahora, hay una serie de ayudas técnicas y determinados dispositivos que facilitan esta tarea (y que sin duda tendremos que usar si queremos lograr resultados cuasi-profesionales, por ejemplo si nos dedicamos a la fotografía). Se trata de los colorímetros, que son herramientas capaces de identificar el color y el matiz para realizar mediciones objetivas de los mismos y así poder configurar nuestro monitor de manera óptima. Normalmente consisten en un pequeño dispositivo (del tamaño del ratón) que se sitúa pegado a la pantalla para captar el color que ésta emite, y en ocasiones también cuentan con una especie de chasis que se coloca en torno al monitor para aislarlo lumínicamente del entorno. Así, realizando diferentes pruebas, el colorímetro y su software asociado pueden saber, para un determinado estímulo, qué salida está ofreciendo el monitor, de forma que caracteriza con gran precisión sus parámetros. Sería algo así como: “Dime lo que muestras cuando te digo que muestres esto, y te diré cómo eres”.
 Colorimetro Si calibramos y perfilamos nuestro monitor, identificamos su espacio de color, conseguimos un perfil de color adecuado para el programa que estemos usando, ajustamos correctamente su temperatura de color, configuramos adecuadamente su gamma, su curva de ajuste, su punto blanco y su punto negro, ajustamos su luminosidad y su contraste (quizá con la ayuda de un colorímetro), y trabajamos con imágenes con un balance de blancos adecuado, podremos disfrutar de una imagen que no podrá compararse con las que nos ofrecen las pantallas que no han pasado por este proceso. Puede resultar complicado, largo o engorroso, pero en realidad cuando nos familiarizamos con estos conceptos veremos que todo está relacionado, y que un poco de tiempo invertido en dichos ajustes nos proporcionará una experiencia de usuario mucho más rica y, lo más importante, ¡nos permitirá poder ver Átomos y Bits en todo su esplendor! :)
¡Hasta pronto!
Por Leonard, publicado el 31.12.11. ¡Buenos días, queridos lectores!
En esta fría mañana (por lo menos aquí en España) del último día del año, queremos simplemente desaros unas… ¡muy felices fiestas y un feliz y próspero año nuevo!
Esperamos que el próximo año venga con muchas sorpresas agradables para todos, y que podamos seguir compartiendo con vosotros posts interesantes que os guste leer. ¡Muchas gracias por seguirnos!
Un abrazo de Leonard y Sheldon 
¡Hasta el año que viene!
Por Leonard, publicado el 19.12.11. ¡Buenas tardes, queridos lectores!
Hoy queremos avisaros de que ya podéis seguir a Átomos y Bits y a sus creadores (o sea, Sheldon y yo, Leonard) en las redes sociales.
Para ello, tenéis disponible en la columna de la izquierda los enlaces de nuestros Twitters y de la página de Facebook de Átomos y Bits. Además, os dejamos los enlaces a continuación:
Esperamos que os animéis a seguirnos. Como podéis imaginar, publicamos contenidos referentes a física, matemáticas, informática, tecnología, y ciencia en general. ¡Contamos con vosotros!
¡Hasta pronto!
Por Leonard, publicado el 08.11.11. ¡Buenas tardes, estimados lectores!
Es probable que entre vosotros (dada la temática de nuestro blog) se encuentren lectores a los que les gustaría programar aplicaciones iOS para iPhone, iPod o iPad que tengan hecho el Jailbreak. Si es así, en este post os ofreceremos las ideas básicas para que sepáis al menos por dónde empezar, y qué podéis esperar encontraros.
Si decidís embarcaros en este complicado viaje, hay varias nociones que sería interesante que conozcáis antes de comenzar con el desarrollo de aplicaciones de este tipo. En primer lugar, es altamente recomendable tener algunas nociones básicas de los lenguajes C / Objective-C. Además, conviene tener un ordenador con MacOS (si bien no es imprescindible) con la versión del SDK (el kit de desarrollo) para la que queramos programar, y si queremos usarlo, necesitaremos tener Xcode instalado. Con estos elementos y algunos manuales, podemos empezar a intentar programar algo con sentido. El problema es precisamente que existen pocos repositorios de información donde vayamos a poder encontrar ayuda sobre el tema.
Para aquellos con menos conocimientos sobre el tema, Xcode es el programa proporcionado por Apple para desarrollar aplicaciones para iOS. Este software nos ofrece un entorno de programación “amigable”, muy gráfico, y con multitud de ayudas visuales que facilitan la edición del código. También incluye el Interface Builder (que hasta la versión 4 de Xcode era un programa aparte, pero ahora ambos elementos están integrados en una sola interfaz) que permite, gráficamente, diseñar el aspecto de nuestra aplicación mediante vistas, botones, sliders, menús de selección, textos, etc. El hecho de contar con Interface Builder nos ahorrara muchas horas de trabajo, más cuanto más vistosa sea nuestra interfaz de usuario. Si queremos desarrollar aplicaciones para AppStore, tendremos que usar Xcode y necesitaremos un Mac, o bien podremos instalar una máquina virtual de Mac en nuestro PC mediante herramientas como VMWare o utilizar otros métodos más peregrinos (como el hackintosh). Si tenéis un ordenador medianamente potente, la opción de la máquina virtual suele funcionar bien. El problema es que a menudo la máquina se queda congelada si no la usáis durante unos minutos (es decir, si cambiáis al sistema operativo anfitrión, Windows por ejemplo, al volver a la máquina virtual pasados unos minutos es probable que encontréis que no responde). Si esto ocurre, basta con reiniciar la máquina virtual, aunque perderéis todo el trabajo que no tengáis guardado.
 Pantalla de Xcode Si somos curiosos, es probable que nos preguntemos por qué surge la necesidad de utilizar otras técnicas diferentes para desarrollar aplicaciones para iOS con jailbreak. ¿Por qué no pueden ser todas aplicaciones normales como las que encontramos en AppStore? Pues bien, la respuesta se encuentra en la propia filosofía de Apple: para la compañía de la manzana, lo principal y más importante, el motivo vital de toda su obra, es la optimización de la experiencia de usuario. Esto quiere decir que no nos van a permitir programar aplicaciones de cualquier tipo, sino que “limitan” sus funcionalidades evitando ciertos comportamientos que pudieran hacer empeorar la experiencia de uso, o comprometer en cualquier aspecto la integridad de los datos, la privacidad del usuario, información delicada del terminal, etc. Bien, aclarado esto, ¿cómo decide Apple qué aplicaciones pueden ser aptas para el App Store y cuáles no? Comprobando qué API‘s y qué métodos utiliza: hay determinadas clases que son privadas y otras son públicas. E incluso dentro de las públicas, hay determinados métodos que son privados. Cuando Apple detecta que estamos utilizando alguno de éstos métodos, rechaza nuestra aplicación y no nos permite subirla a AppStore.
En este punto, si queremos distribuir nuestra aplicación tendremos que buscar mercados alternativos para ella, como puede ser Cydia. Ahora bien, ¿cómo podemos acceder a métodos y clases privados de Apple, si no los conocemos? Mediante una técnica que se conoce como “dump“. Esta idea consiste en volcar los frameworks que tenemos embebidos en nuestro SDK de forma que podamos entrar a ellos y navegar para estudiar sus clases, sus controladores, qué parámetros recogen y qué parámetros pasan, etc. Para profundizar en este tema, recomendamos que leáis el artículo Dump Public and Private iOS Frameworks de Conor Burgess. En él, se explica cómo utilizar un script que el propio Conor ha desarrollado, y que con ayuda de la herramienta class-dump nos permite tener accesible todos los frameworks del SDK. Además necesitaremos otros dos ficheros (substrate.h y libsubstrate.dylib) que el script utiliza para el parcheo de los frameworks. Una vez seguidos los pasos que el script de volcado requiere (simplemente un par de líneas de comandos), todos los archivos de cabeceras para el SDK habrán quedado volcados, parcheados y unidos. Es importante señalar que esto no interferirá en absoluto con el correcto funcionamiento de nuestro Xcode, aclaración imporante en el supuesto de que queramos desarrollar posteriormente otras aplicaciones válidas para AppStore, en cuyo caso no tendremos ningún problema.
De acuerdo, en este punto ya tenemos disponibles todos los métodos, incluidos aquellos que Apple no quiere que veamos. Ahora, el siguiente paso lógico será comenzar a desarrollar nuestra aplicación. Ésta evidentemente es la parte más complicada, no sólo porque tendremos que pelearnos con el código, sino porque para muchas de las cosas que querremos hacer, no podremos utilizar Xcode e Interface Builder de la manera clásica. En su lugar, necesitaremos otro “entorno de desarrollo”, más adaptado a aplicaciones para jailbreak: el conocido Theos y Logos. Una vez instalado Theos, ejecutaremos el NIC (New Instance Creator), que nos preguntará qué tipo de programa queremos comenzar a desarrollar: podremos elegir entre una aplicación, una librería, un grupo de preferencias, una herramienta o un tweak.
 Pantalla de Theos Después de seleccionar el tipo de programa, y tras asignarle un nombre, un autor, etc., obtendremos todas las plantillas necesarias creadas sobre las que podremos comenzar a programar. A modo de referencia y para que os sirva de ejemplo, programas como LockInfo, Activator, SBSettings, etc., son todos librerías dinámicas (dylib), en vez de aplicaciones como tal. Por su parte, Logos nos ayudará cuando compilemos nuestro desarrollo, al convertir la sintaxis simple de Theos en el complejo lenguaje de Mobile Substrate, del que hablaremos a continuación.
Para finalizar esta mini-guía, es imperativo comentar brevemente una de las características fundamentales en las aplicaciones para terminales con jailbreak: la inyección de código. Una vez que tenemos nuestros frameworks disponibles, nuestro Theos instalado, y creada nuestra plantilla sobre la que trabajar, necesitaremos de alguna forma (y sobre todo si estamos programando alguna librería dinámica o algún tweak) poder interferir en la ejecución normal del código de Apple en el dispositivo. Para ello, tendremos que conocer el funcionamiento de Mobile Substrate. Esta capa es un componente requerido por multitud de programas (como SBSettings, Winterboard, Five Icon Dock…) , y fue desarrollada por Saurik. Su forma de actuar es montar librerías cuando carga el Springboard, de forma que pueda inyectar su código en las aplicaciones que lo ejecutan. Esto es lo que se conoce como “hook“, o sea, situar anzuelos en el código en los que nosotros podremos insertar el nuestro propio para engancharlo. Por otra parte, Mobile Substrate nos protege de posibles cuelgues del terminal, poniéndolo en una especie de modo “a prueba de fallos” en caso de que haya algún error en el Springboard.
Resumiendo, como veis, el proceso para comenzar a desarrollar aplicaciones de este tipo requiere una cierta preparación, unas buenas dosis de paciencia y una visión general del proceso que estamos siguiendo. A pesar de que no hay mucha información (especialmente en castellano) al respecto, en el servidor de IRC irc.saurik.com, canal #theos, podréis recibir más ayuda especializada y concreta para cada aspecto en particular. Lo que aquí os presentamos son sólo unos primeros pasos, que esperamos os resulten útiles para saber dónde podéis buscar más información, y qué información podéis buscar.
Si alguno de vosotros se anima, y esta breve introducción le ayuda a desarrollar alguna aplicación, hacédnoslo saber. ¡Estaremos encantados de hablar de ella en Átomos y Bits!
Por Sheldon, publicado el 17.10.11. Buenas de nuevo amigos,
Hoy quisiera hablaros de Eureka, y no me refiero a la mítica frase atribuida al matemático griego Arquímedes, del que ya hemos hablado en otra ocasión. En realidad me refiero a la serie de Syfy (personalmente prefería Sci-Fi) con el mismo nombre.
Antes de comenzar me gustaría aclarar que aunque la idea básica de la serie me parece curiosa y entretenida, la realidad es que, desde el punto de vista científico, los argumentos que en ella se dan no son más que una sarta de barbaridades y patadas a la ciencia que sólo podrían tener lugar en un universo paralelo ideado para guionistas perezosos que buscan soluciones fáciles. A su lado, la serie Fringe (que también me gusta bastante) parece ciencia empírica.
 Eureka A pesar de ello la veo, sí lo sé, no me juzguéis. Recordad que una serie científicamente incoherente no tiene por qué ser sinónimo de aburrida, aunque la verdad es que creo que darle un marco de realidad sólo podría mejorarla. Es el eterno debate, la ciencia-ficción por definición incluye cosas que no son reales (sino ficción) pero no debemos olvidarnos de la ciencia, señores. Sin un marco de referencia adecuado el contexto de la historia se pierde. En las series, por lo general y si nadie nos dice lo contrario, damos por hecho que la naturaleza es la misma que en nuestro universo y por lo tanto las leyes físicas son las mismas. Para justificar la parte de ficción se pueden utilizar varios métodos, incluyendo tomarse ciertas licencias que dejan colgando con pinzas algunos argumentos. Pero, como en todas las cosas, debe saberse dónde poner los límites. Desde mi punto de vista, tanto mejor será el argumento cuanto mejor se represente la realidad y más ingeniosa sea la “excusa” para explicar la ficción.
Pero bueno, no era en este punto dónde quería centrar el artículo que nos ocupa, que puede ser algo controvertido, centrémonos.
Recientemente he visto el capítulo 7 de la 3 temporada en el que una niña prodigio (como todos en Eureka) de 9 años, y para un trabajo del instituto, crea un segundo sol en el cielo sobre la ciudad (a unos 300 metros de altura, si no recuerdo mal). A lo largo del capítulo se dicen bastantes barbaridades relacionadas con este tema y otras que no lo están directamente. Voy a intentar ver algunas de ellas, aunque espero que eso no haga este artículo demasiado extenso.
Podría hablar de lo que ellos llaman “radiación variogénica” (¿mande?), o de la “hidratación por nanotecnología”, o de “esculpir nubes hidrogénicamente”, o incluso de que, a pesar de que tienen la más alta tecnología jamás concebida, incluyendo hologramas, tan sólo disponen de las simples y actuales (ya casi anticuadas hasta para nosotros) ecografías en 2D. Sin embargo, me voy a intentar centrar en el tema del sol, que ya sabéis que es un tema que me gusta bastante (ya hemos hablado de las estrellas en algún artículo anterior, hablando de la miniserie Impact).
En el capítulo se comenta que el nuevo sol tiene las propiedades de una estrella enana principal y no se sabe cuál es su fuente de energía. Mmm… A ver, a ver… Las estrellas enanas sí que existen, aunque el tema del tamaño es bastante relativo (tan tan pequeña nunca podría llegar a formarse), pero eso de “principal” imagino que hace referencia a que es una estrella perteneciente a la denominada “secuencia principal”, que es una región del diagrama de Hertzsprung-Russell. Éste es una catalogación de las estrellas en función de su magnitud absoluta y su temperatura superficial, y la secuencia principal representa la región de este diagrama en la que se encuentran la mayor parte de las estrellas. Esto también debería darnos bastantes más datos, pues las estrellas más pequeñas de la secuencia principal son las de tipo espectral M5, que tienen una masa de 0,12 veces la de nuestro sol y una temperatura de 3.200 K. Es decir, que para que fuese una de ellas debería tener un radio de 83.500 km, con lo que nos engulliría y abrasaría, claro. Pero bueno, también puede ser que ese “principal” se refiera a otra cosa que no se me haya ocurrido.
 Diagrama de Hertzsprung-Russell También se dice de la estrella que no se sabe cuál es su fuente de alimentación. En fin, una estrella no es como una tostadora que puedes enchufar a tu antojo. Una estrella no necesita fuente de alimentación pues, por definición, si ya es una estrella ya se han iniciado los procesos de fusión que generarán su energía. Otra cuestión aparte sería cómo se las ingenió la niña para conseguir que comenzase ese proceso. Pues también hay respuesta para ello, según la propia niña el proceso “es muy sencillo, tan sólo se necesita un generador gravitacional rodeado por plasma reactivo”, lo que quiera que eso signifique. Lo que sucedió para que se les fuera de las manos fue que hubo un error en el cálculo de la densidad del plasma… Ehhh…. (si alguno no lo habéis leído aún y queréis saber qué es eso del plasma, podéis leer un poco más acerca de ello en el artículo agregando estados a los estados agregados de la materia). Vaaale, vaaaale, ya sé que sólo es ficción, así que continuemos.
Tampoco puedo dejar de comentar lo poco exagerados que son los guionistas de la serie cuando en un momento determinado uno de los personajes utiliza un portátil para desbloquear una cerradura (típico), con una capacidad de procesamiento de, nada más y nada menos, que 20 zettahercios. A algunos puede que esto no les diga nada, así que analicémoslo brevemente. Nuestros ordenadores actuales tienen una capacidad de procesamiento de varios gigahercios, y aunque probablemente dentro de algunos años si releo esto me ría de mí mismo, creo que son bastante potentes (aunque en realidad la potencia siempre será relativa a lo que se quiere conseguir). Esos hercios (Hz) nos indican la capacidad de procesamiento de nuestros microprocesadores o, dicho de otra manera, la frecuencia de su reloj. Mi ordenador actual es de 3,5 Ghz, que son 3,5×109 o unos 3.500.000.000 ciclos por segundo. El portátil de nuestro protagonista dispone de 20 Zhz, es decir 20×1021, o lo que es lo mismo 20.000.000.000.000.000.000.000 Hz, apenas nada. No digo que no sea posible, sólo que quizás hayan exagerado un poquito.
Volviendo al tema de la estrella, más adelante vemos como “evoluciona a supergigante”. Según dicen esto provocará una explosión muy grande, “habrá una supernova, una explosión más grande que la de Hiroshima y Eureka se convertirá en un cráter muy grande”. Pues bien, es cierto que uno de los posibles finales de una estrella es una supernova, pero la comparativa de las explosiones quizá no sea la más adecuada.
La bomba atómica lanzada sobre Hiroshima, bautizada como Little Boy, tenía un potencia explosiva de unos 13 kilotones, es decir 5,5×1013 J. La bomba atómica más potente jamás detonada por el hombre, fue la denominada Bomba del Zar, con una potencia de unos 50 Megatones, o lo que es lo mismo, 2,1×1017 J, unas 4.000 veces más potente que Little Boy. La potencia de una supernova dependerá de cada caso, pero se puede hacer una estimación sobre los 1044 J, es decir, 1027 veces más potente que la Bomba del Zar, 1031 veces más potente que Little Boy. Eso es 10 quintillones de veces más potente que la de Hiroshima!!!
Como decía, creo que no han tenido muy en cuenta la escala, pero bueno, también es cierto que tan sólo comentan que sería una explosión mayor que la de Hiroshima, en ningún momento hablan de proporciones ni magnitudes. En realidad no importa el tamaño de la estrella, si realmente pudiera ser posible que se convirtiera en una supernova, no creo que Eureka se convirtiera en un cráter pues dudo mucho que se mantuviera en pie algún trozo de La Tierra sobre el que formar ese cráter.
 Bomba del Zar Cambiando un poco de tema, hablemos sobre cómo pretenden destruir la estrella: “si pudiéramos acercarnos y lanzar un módulo con una concentración de átomos de hierro al núcleo el sol implosionaría”. No se me ocurre ninguna explicación razonable para la relación entre la concentración de átomos de hierro y la destrucción de la estrella, y mucho menos por qué produciría una implosión, pero se me ocurre que no han tenido en cuenta las implicaciones que eso tendría. Una implosión real se consigue detonando explosivos en la superficie de un objeto de manera que la onda expansiva se mueva hacia adentro, comprimiéndolo. Pero esta compresión no es ilimitada, finalmente se alcanza un estado de alta densidad. La estrella no desaparecería, el problema seguiría allí, o aún peor, porque si todo esto fuera posible comprimir en exceso la estrella podría aumentar su densidad hasta formar una singularidad, un agujero negro.
Incluso teniendo en cuenta que toda la masa de la estrella pudiera desaparecer por la implosión, desintegrándose de alguna manera, su equivalente de energía debería distribuirse por la atmósfera en su lugar, por aquello de que la energía no se crea ni se destruye (Principio de conservación de la energía), lo que a su vez originaría graves problemas climáticos y medioambientales.
Y ya, por último, también me gustaría comentar otro pequeño detalle que me llamó la atención. En los minutos finales, estando a punto de convertirse en una supernova, la estrella emite tanto calor que las ruedas del coche en el que se desplazan el sheriff Carter y Zane Donovan se derriten y deben continuar el camino a pie. Bueno, lo primero es que en realidad las estrellas cuando se convierten en gigantes rojas se enfrían, no se calientan más, por lo que esto no sería posible. Y por otra parte, me resulta curioso que los neumáticos de un vehículo se derritiesen en dicha situación. Los neumáticos, al estar formados por distintos compuestos, no tienen un punto de fusión como tal, sino que se considera la temperatura a partir de la cual se vuelve maleable, que está en torno a los 160 o 170 ºC. Me cuesta pensar que se alcanzase dicha temperatura para que se derritieran los neumáticos del coche patrulla, sobre todo porque es lo único que parece estar afectado. Bueno, eso y que las superficies metálicas están calientes (¡pero es que eso ya ocurre en mi terraza durante el verano sin necesidad de un segundo sol!).
En fin, la verdad es que cada capítulo de la serie es un completo desafío a la realidad. Refiriéndonos a Eureka sí que podemos decir sin temor a equivocarnos: “cualquier parecido con la realidad es pura coincidencia”.
|
¿Nos echas una mano? Aceptamos donaciones de cualquier importe a través de PayPal, para ayudar a mantener el dominio y alojamiento de Átomos y Bits.
Suscríbete con FeedBurner
|
Twitter de Leonard
Encuéntranos en Facebook
