Nuestro blog tocará muchos programas y aplicaciones, sobre todo libres, "como en libertad", aunque puede ocurrir que hablemos de algunos que no lo sean por motivos prácticos. Te lo haremos saber.
Parece mentira, pero hemos llegado al final… de la primera parte. Voy a dedicar este artículo a cerrar la serie de FLAC en su formato “web”, y al mismo tiempo me servirá para trazar las líneas de trabajo de cara a la segunda parte del proyecto: la edición y maquetación de FLAC en formato “libro”.
Voy a completar la entrega anterior con un revelado de retrato en blanco y negro. Aunque los puntos esenciales de nuestro flujo de trabajo son idénticos a otros tipos de fotografía, hay unos cuantos trucos y técnicas que son de especial importancia para esta modalidad fotográfica. Vamos a repasar unos cuantos de ellos, que no todos.
Tras tantos capítulos, este será el dedicado al revelado digital propiamente dicho. Voy a intentar aportar mi punto de vista en torno a los flujos de trabajo de revelado, y para ello voy a partir de todos los conceptos descritos hasta ahora. Todos tienen, en mayor o menor medida, su papel en el revelado digital. Me atreveré además a darle un nombre a este método: lo voy a llamar “revelado narrativo” y trataré de justificar esta denominación de manera razonada. Este será, pues, un capítulo en el que, además de aprender a usar Darktable en contextos prácticos, repasaremos todo lo descrito hasta el momento relacionado con la composición, su valor narrativo y cómo aprovecharla para revelar mejor nuestras fotos.
Después de un somero repaso a las posibilidades de Darktable en el revelado en blanco y negro, le toca el turno al color. Como veremos en este capítulo y el siguiente (al menos), la cosa se complica un poco, pues ahora contamos con más personajes en el escenario.
Hola amigas y amigos. Hoy os voy a hablar de un tema que hace tiempo que quería probar. Os explico un poco. Hace años que trabajo con servidores web. Mis primeras experiencias fueron con Apache, el servidor web número uno en el mundo, quizá uno de los más estables y versátiles. Con el paso del tiempo, es cierto, no me terminaba de gustar el uso que hacía de la memoria, teniendo en cuenta que en mis servidores personales no disponía de muchos recursos por un tema económico evidente. Finalmente me decidí a cambiar a Nginx, que por aquel entonces (al igual que ahora) tenía buena fama en su relación rendimiento/recursos. Y hasta ahora he estado muy contento. Pero pasa que el sistema se puede exprimir aún más, creo yo, y ahí tenemos la idea del artículo.
Tal y como he comentado, Apache es muy potente, pero no termina de jugar bien con la memoria. En cambio Nginx tiene problemas con el contenido dinámico (es genial para el estático), ya que necesita módulos como php-fpm para hacerlo funcionar. Sabiendo esto, ¿por qué no hacemos que trabajen juntos? De esta manera aprovechamos sus potenciales y solapamos sus carencias.
