- Primero este deb que es un soft que hace que el modem se comporte como un modem y no como una memoria usb (o algo así). Yo he instalado la última versión para 64 bits pero también la hay para 32 bits:
ozerocdoff_0.4-2_amd64.deb

A continuación instalamos el Vodafone Mobile Connect que es un soft similar al existente para Win y Mac:
vodafone-mobile-connect_2.20.01-1_all.deb
Hay que satisfacer algunas dependencias pero como es un deb nuestro sistema se encargará de casi todo 

Estos archivos sirven para Debian,Ubuntu y Mint, si tenéis otra distribución encontrareis paquetes para casi todas las más conocidas en Betavine. Por lo que leo en su web parece ser que Betavine es un área de desarrollo del grupo vodafone que trabaja con software open source.

Lógicamente después de la instalación solo hay que ejecutar vodafone-mobile-connect (bien desde consola o bien desde el enlace que se crea en Aplicaciones-Internet y configurar ahí el servicio, pin y demás para que se conecte siempre automáticamente al pinchar el modem.
Yo en vez de hacerlo así lo he hecho desde Sistema-Preferencias-Conexiones de red-Banda ancha móvil añadiendo una conexión nueva, donde incluso sin tener el modem pinchado el sistema nos va indicando cual es la configuración clásica para estos dispositivos (en función de nuestra compañía proveedora del servicio). El primer método que indico es el más sencillo pero ambos funcionan.

Por último comentar que en la configuración de vodafone-mobile-connect aparece la posibilidad de usarlo con Simyo, por lo que supongo que el método también funciona para dispositivos de esta compañía.

Una vez comprobado el sistema puedo aseguraros que comparado con el soft de Mac es mucho más cómodo el de gnu/linux, plug and play total. En Mac hay que abrir dos programas uno para activar el modem, otro para activar el servicio en Mac e introducir el pin en cada acceso, lo que es un peñazo. En Win no tengo ni idea de cómo va.

Un saludo

La luz sobre el macizo rocoso sólo me dio una oportunidad, porque el sol sólo asomó un breve instante entre la línea del horizonte, para ocultarse en las nubes, la foto de antes es azulada y la de después ya es gris por las nubes. Volveré al lugar porque me dejé visto otra localización para fotografiar esta imponente montaña.

Leer más...

La sinopsis:
¿Y si volvieses a casa… y ya no hubiese nadie?
En 1975, el primer cosmonauta ruso en la Luna no consigue regresar, y se le da por perdido en el espacio. Él, sin embargo, a través de fantasmales mensajes de radio, clama haber vuelto a la Tierra y haberla encontrado vacía, sin un alma.
Su irreal presencia y su voz irán destruyendo poco a poco el mundo de sus seres queridos.

Otra de las características más curiosas del proyecto es su sistema de financiación: Crowfunding, según la web: "Crowdfunding quiere decir que financiamos la película entre todos. Conviértete en productor desde sólo 2€ y recibe a cambio un wellcome pack, tu certificado de productor, la entrada en el sorteo de un traje auténtico de cosmonauta auténtico y tu nombre en los títulos de crédito."

El proyecto y el guión me han parecido muy interesantes así que he decidido sumergirme en la industria del cine y me he hecho productor con una pequeña colaboración. Ojalá cunda el ejemplo de modelo de producción en el sector.

Os dejo un enlace al Teaser-trailer oficial de la peli en Vimeo rodado con una Canon 5D MarkII y un 50mm 1.8.

Espero que os guste el proyecto.

La autoría de las fotos y logotipo es del paquete de prensa de http://elcosmonauta.es

por la lista de correo de OpenStreetMap en Español acabo de ver este artículo, La respuesta de OpenStreetMap al desastre de Haití. A raíz del terremoto se pidió colaboración a las diferentes listas de todo el mundo para mapear la isla. En el artículo podéis ver el antes y el después, así como unas comparativas con Google Maps que, como algunos sabéis, fuera de las zonas "de negocio" tampoco se luce mucho que digamos.

Aquí podemos verlo en real ahora:

Un trabajo para quitarse el sombrero.

Saludos,
Colegota

Leer más...

tras muchos años viviendo junto a la Sierra Norte de Madrid, todavía me quedan muchos de sus rincones por explorar y descubrir. Así que decidí darme una vuelta por alguno de los que me faltan para ir ubicándome y planificando próximas visitas con más detalle. En esta ocasión realicé un rápido recorrido por los puertos de Canencia y Navafría para terminar en el de Navacerrada.

Estos puertos de montaña en invierno pueden estar cerrados por la nieve o necesitar del uso de cadenas. Antes de viajar por ellos es conveniente informarse.

Partiendo de Miraflores, la carretera es una delicia de colores otoñales. A veces atraviesas bosques más densos, otros más claros, pero verdes y ocres crean un festival muy recomendable.

Ver en el mapa donde fue tomada esta foto (Openstreetmap.org)

En lo alto del puerto de Canencia pisé las primeras nieves, aunque escasas todavía. Y las vistas desde sus 1500 metros, siempre son interesantes.

Ver en el mapa donde fue tomada esta foto (Openstreetmap.org)

Bajo el puerto en dirección norte y tras un frugal almuerzo en Canencia pueblo, me dirijo al Valle de Lozoya. Junto al embalse de Pinilla, Lozoya da para un agradable paseo. Tiene algunas construcciones interesantes.

Ver en el mapa donde fue tomada esta foto (Openstreetmap.org)

Y una fuente con cuatro caños, de la que podéis apreciar un par de ellos.

Ver en el mapa donde fue tomada esta foto (Openstreetmap.org)

De nuevo en dirección norte, tomo la carretera que me lleva al Puerto de Navafría. Aquí ya hay más nieve compartiendo paisaje con el musgo en los troncos de los árboles.

Ver en el mapa donde fue tomada esta foto (Openstreetmap.org)

Tomo una de las pistas de esquí de fondo que todavía no está practicable. Aunque siempre hay quien le encuentra uso a unos copos de nieve.

Ver en el mapa donde fue tomada esta foto (Openstreetmap.org)

Más adelante está el mirador de Navalcollado, pero como no sabía exactamente a qué distancia y se hacía la hora de comer, me quedé a medio camino. Apreciando como la sierra acaba disolviéndose en la meseta castellana.

Ver en el mapa donde fue tomada esta foto (Openstreetmap.org)

Y es que ya se sabe que ancha es Castilla.

Ver en el mapa donde fue tomada esta foto (Openstreetmap.org)

Al igual que la mirada, bajé la carretera hasta el llano y giré en dirección sur para ir a comer al Torreón. Toda esta zona es buena para las setas y los boletus están de temporada. Después acudió Manolo para el café y subimos al Puerto de Navacerrada para realizar experimentaciones fotográficas más o menos nocturnas. Pero eso será otro reportaje.

Aquí la nieve no ha llegado con la suficiente intensidad para dar gusto a los esquiadores, aunque algo pueden hacer los de los trineos.

Ver en el mapa donde fue tomada esta foto (Openstreetmap.org)

Las montañas cercanas dicen que ya falta menos para estar todo blanco.

Ver en el mapa donde fue tomada esta foto (Openstreetmap.org)

Espero que os haya gustado. Dentro de poco, más.

Saludos,
Colegota

Un saludo

• 300 ppi, 150 ppi, 100 ppi, 75 ppi, …
• 360 ppi, 180 ppi, 120 ppi, 90 ppi, … por debajo de estas resoluciones mínimas no tiene sentido trabajar para tamaños razonables.

Tal vez alguien esperase algo más concreto, algo así como una tabla de tamaños y resoluciones, pues bien, yo no soy nada amigo de esas cosas que implican memorizar números y tablas, y me decanto más por entender el por qué, y aplicarlo en función los factores más influyentes, que para lo que nos ocupa, en mi opinión son:

• El tamaño de impresión, por supuesto.
• El tipo de información, como por ejemplo:
  • Imágenes con muchas lineas finas inclinadas son muy sensibles a estas cosas.
  • Retratos de grupo de mucha gente, donde alguien se puede intentar acercar más de lo normal para tratar de identificar personajes.
• El objetivo final de la imagen:
  • Colgarla de una pared, que se verá de lejos y los efectos del pixelado pasarán desapercibidos.
  • Un álbum fotográfico que siempre puede ser susceptible de que alguien intente ver detalles más de cerca.
  • Fotografías de cartera como las que yo llevo de mis hijas , …

De todos modos, y aunque esto obvia algunos de los puntos que he mencionado antes, este podría ser un buen criterio generalista:

^*1Normalmente impresoras de inyección de tinta Epson o con cabezal piezoeléctrico.
^*2 Generalmente impresoras de inyección de tinta de cabezal resistivo, impresoras láser de tóner o láser químicas.

El por qué de este criterio no es en absoluto arbitrario, para entenderlo, en primer lugar, hay que diferenciar bien entre resolución de imagen y resolución de impresión. Esta es una de esas cosas que, aunque sencillas, al principio lían un poco, sobre todo por las nomenclaturas y por cierto problema de traducción:
La resolución de la imagen o Píxeles Por Pulgada (ppp) no son más que los puntos de la imagen en una pulgada del dispositivo que nos la muestra, fácil ¿verdad?. Cada uno de estos puntos puede ser de cualquiera de los colores que la profundidad de color de la imagen nos permita.
Si lo preferís, las unidades se pueden traducir al sistema internacional, de Píxeles Por Pulgada a Píxeles Por Centímetro (ppc), pero hay que tener en cuenta que cada pulgada son 2,54 cm, por lo que el valor en ppp habrá que dividirlo por 2,54.
También es bastante común encontrar la nomenclatura inglesa ppi (Pixel Per Inch).

En cuanto a la resolución de impresión, se habla de los Puntos o gotas de tinta que puede llegar a poner la impresora en una pulgada o centímetro de papel, es decir Puntos Por Pulgada (ppp otra vez), pero cada una de estas gotas son de uno de los colores base que la máquina puede utilizar, que a día de hoy, van desde un mínimo de 4 colores, (los famosos Cian, Magenta, Amarillo, (Yellow en Inglés) y Negro (CMYK)) hasta 11, y quien sabe si no más en el futuro (espero que no, ¡qué locura! ).
Si cada punto es sólo una gota de tinta de uno del los 4, 6, … 11 colores, ¿cómo se generan el resto de tonos de mi foto?, … “fácil ”, combinando varios de estos puntos; por ejemplo, si pongo varios puntos de tinta amarilla junto a varios puntos de tinta cían, obtendré un verde, y no será necesario que los fluidos estén mezclados, bastará con que estén suficientemente cerca unos puntos de otros y bien intercalados, para que desde la distancia apropiada, no se aprecien los colores por separado sino solo un verde.

Con todo esto, es fácil de imaginar que para imprimir un sólo píxel de nuestra fotografía, es necesario utilizar varias gotas de tinta (ver Figura 1), por lo que es también fácil de suponer que la resolución de impresión siempre deberá ser mayor que la de la imagen.
Lo que se puede ver en la figura 1 no es del todo riguroso, ya que la disposición de los puntos de tinta no tiene porqué ser tan ordenadita, y si lo está, no es tan simplista, pero representado así resulta muy ilustrativo, así que permitidme la licencia.

Fijaos en la mala idea que tienen las siglas: Píxel Por Pulgada (ppp) y Punto Por Pulgada (ppp). He aquí una de las fuentes más común de error. Esto no pasaría si habláramos Inglés: Pixels Per Inch (ppi) y Dots Per Inch (dpi), por lo que con vuestro permiso, voy a utilizar la nomenclatura anglosajona.

Bien, teniendo más o menos claro esto de las resoluciones , solo hay que mirar la figura 1 para imaginar que debe utilizarse el mismo número entero de posibles gotas de tinta por cada píxel, y no tiene sentido pensar en utilizar, por ejemplo, 5 gotas y media para imprimir dicho píxel; es decir, la división de ambas resoluciones, impresión e imagen debe dar el número entero de puntos sobre el papel.
Como ya he comentado antes, la cosa no es tan sencilla ya que existen muchos más factores como: tecnologías de gota variable que permiten variar el tamaño de los puntos, que aunque los algoritmos de rasterizado no contemplan esta opción, podría por lo menos hacernos pensar en la posibilidad; la distribución de dichos puntos no tiene porque ser tan ordenada y/o simple; la concentración de los mismos no es uniforme en el papel, habiendo más puntos en los tonos oscuros, (hasta un máximo de la resolución elegida para imprimir) y menos en los tonos claros (hasta un mínimo de cero para el blanco) … pero expresándolo así, resulta bastante didáctico, ¿no?.
Pues bien, ya que para determinar el tramado de los puntos sobre el papel, el controlador debe adaptar la resolución de la imagen a una divisora de la mínima de la impresora para no intentar imprimir un píxel con medios puntos, si la imagen no cumple con esta característica, se deberá remuestrear.
En función de la calidad de dicho remuestreo, el resultado final puede ser mejor o peor, pero en cualquier caso no lo controlaremos al 100% nosotros, y en caso de no ser suficientemente bueno, se traducirán defectos de resolución en la imagen impresa: pixelados, dientes de sierra o efectos escalera, …, y estos serán más o menos perceptibles en función de infinidad de factores tales como, el tamaño de la impresión, la distancia de visionado, luz ambiente, ganancia de punto y textura del papel utilizado, … aunque para mi los más importante para que sea perceptible o no, son los tres mencionados anteriormente: el tipo de información, tamaño de la impresión y la distancia de observación.
En cualquier caso, perceptible a simple vista o no, los problemas de resolución pueden aparecer si no controlamos al 100% el sistema de impresión, y teniendo los medios para evitarlos, no veo porqué no aplicarlos .

Para demostrar esto realicé un experimento utilizado la misma fotografía a diferentes resoluciones de imagen, pero conservando el tamaño de impresión:

En primer lugar cree varias copias del mismo archivo a igual tamaño de impresión (90×60 mm) y diferentes resoluciones de imagen: 360 ppi, 300 ppi, 254 ppi y finalmente 180 ppi. Y las imprimí utilizando el comando “Imprimir” de Gimp 2.6.1, y el controlador de Gutenprint de una impresora Epson Stylus Pro 7880, conservando los ajustes del controlador idénticos en todas las impresiones.
Para presentar los resultados, he realizado un escaneo al máximo de la resolución óptica que me permitía el escáner sin ningún tipo de interpolación, ni para eliminar, ni para añadir puntos (1600 ppp en el caso del escáner utilizado EXPRESSION 1640XL) y he los aquí:

Imagen a 254 ppi:

Imagen a 180 ppi:

En ambas se puede apreciar un pixelado debido a problemas de resolución de imagen, normales a 180 ppi por la falta de puntos (el mismo efecto pueden verse en pantalla poniendo el zoom al 100%), pero que no deberían aparecer a 254 ppi, y efectivamente, si ponemos el zoom al 100% en la imagen origen, no se aprecia.
Y curiosamente, aumentando la resolución a 300 ppi, el resultado en lugar a de mejorar como parece de esperar, resulta ser incluso peor que a 254 ppi o 180 ppi:

Y ahora mi propuesta para optimizar la calidad si se necesita, 360 ppp:

Estos resultados son fuertemente dependientes del controlador utilizado ya que como he comentado, para adaptar la resolución de la imagen a una divisora de la mínima de impresión, dicho controlador ha de aplicar un remuestreo cuya calidad determinara finalmente la de la imagen impresa.

Esto mismo lo podemos reproducir sin necesidad de imprimir nada:
Cogiendo la misma imagen con la que he hecho las pruebas, en el menú “Imagen” de Gimp, con el comando “Escalar imagen”, se aumenta la resolución conservando el tamaño original (al tanto, que para conservar dicho tamaño, es necesario cambiar las unidades por defecto para el tamaño, de píxeles a mm, cm, o cualquier unidad de longitud, y una vez cambiada la resolución, volver a poner el tamaño que tenia antes, pues de lo contrario Gimp intentará no remuestrear la imagen, y esto es justamente lo que se pretende).
En el campo interpolación, en Gimp 2.6.x hay cuatro opciones: Ninguno, Lineal, Cúbico y Sinc (Lanczos3), si no se utiliza ninguna interpolación, (opcinón Ninguno) y la nueva resolución elegida es múltiplo de la inicial, viendo la imagen al 100% de zoom, se nota cierto pixelado, pero bastante uniforme debido a la reducción de puntos, en cambio, si la resolución destino no es múltiplo de la original, ese pixelado es horrible, y curiosamente, muy parecido al que se puede ver en mis pruebas de impresión.
Pues esto mismo es lo que hacen los controladores de impresión, ya sean los propios de los fabricantes de las impresoras, programas RIP, o lo que más me interesa, controladores de software libre: realizan un remuestreo con una interpolación mejor o peor, activada o no por defecto, y que no siempre es evidente o fácil de encontrar.
Incluso, puede suceder que dependiendo de la interfaz de impresión utilizada, que no tanto del controlador de impresión, se produzca el problema o no. Un ejemplo de esto mismo es lo que sucede al reproducir las pruebas anteriores, pero en lugar de utilizar el plugin de impresión de Gimp mediante el comando “Imprimir”, utilizando el plugin de Gutenprint (comando “Imprimir con Gutenprint…”), y en ambos casos el controlador para CUPS de Gutenprint, los mismos ajustes de impresión y cuidando las opciones que pudiéramos suponer un redimensionado; y los resultados:

Imagen 254 ppp:

Bastante mejor que con el comando simple “Imprimir” de Gimp.

Imagen 180 ppp:

Similar al resultado con el comando Imprimir, pero se ve algo raro, como si se hubiera remuestreado cuando en principio no era necesario

Y finalmente a 300 ppp:

En mi opinión sigue siendo la peor opción posible, pero mucho mejor que con el plugin print de Gimp.

Como añadido, comentar que otras cosas que he visto en este experimento, es que la calidad de impresión, y ya no hablo de temas de resolución de imagen y pixelados, sino de calidad general en la impresión, resultado de color, trama, degradados, … con el plugin “Gimp-Gutenprint” es muy superior al comando Imprimir,  y no deja de sorprenderme ya que en teoría el controlador es el mismo “Gutenprint”, pero los parámetros que el dialogo de impresión le pasa a dicho controlador son diferentes, … Muy interesante, para seguir jugando, …

¿Por qué los sistemas de trama ordenada son diferentes en este aspecto?.

Simplificando mucho el tema ya que mis conocimientos al respecto son limitados y la extensión de mismo parece ser que da para algún que otro libro, trataré de explicar porqué estos sistemas de impresión son diferentes a este respecto:

Los sistemas de trama ordenada de impresión a color, utilizan una trama de semitono para cada una de las tinta base y las superpone dándole un angulo diferente a la retícula que forman cada una de ellas (ángulo de trama).
Pero vallamos por partes. La trama de semitonos, sería la manera más sencilla de realizar una trama de punto ordenada con la que se podría realizar una impresión monocromática. Esta consiste en disponer los puntos en una retícula uniforme, dentro de la cual, se modula el tamaño de los puntos para aumentar o disminuir la densidad de tinta y en consecuencia del color especifico del semitono, (ver figura 2) por esto se denominan también tramas de amplitud modulada o AM.
En ningún caso se modifica la distancia entre los centros de lo puntos, solo el tamaño de los mismos, siendo esta distancia la que marca su característica de resolución que en estos casos se expresa en lineas de retícula por pulgada (lpi Lines Per Inch), lo cual también se conoce como lineatura de trama.

Visto esto, es fácil intuir que el paso de la resolución de imagen a la distribución de los puntos en una trama ordenada, no es tan directa como lo que se ha visto hasta ahora, esta distribución de puntos ahora dependerá, como mínimo, de la lineatura de la trama y el ángulo de trama.

Por esto para determinar la resolución optima de imagen para enviarla a imprimir a una máquina que utilice un sistema de trama ordenada como un imprenta se suele utilizar un valor multiplicador sobre la lineatura de trama de dicha máquina. De este multiplicador me he encontrado varias versiones, supongo que dependiendo del angulo de trama para el autor ha querido expresarlo, y así se pueden encontrar autores que recomiendan que la resolución de la imagen sea de 1,41 por la lineatura de trama, de 1,67 por dicha lineatura o incluso 2 veces la misma. Por ejemplo, para imprimir en una máquina con una lineatura de trama de 150 lpi, se recomiendan valores de resolución de imagen de 211 ppi, 250 ppi o 300 ppi.

dlRaw es uno de estos reveladores de raws que en este caso recuerda estéticamente al estilo del conocido Bible pero con una licencia GNU GPL. Es decir, es libre.
Este detalle fundamental es la razón del presente artículo.

dlRaw se basa en el conversor de raw de Dave Coffin DCRaw y en algunos conceptos de UFRaw. Precisamente la idea original del autor, Jos De Laender  era mostrar de la manera más clara posible el flujo de proceso del programa y su documentación para facilitar la colaboración de la comunidad, que el estimaba que no se daba de la mejor manera en el ámbito de UFRaw. Posteriormente estos esfuerzos derivaron en la inclusión y desarrollo de complementos externos como reductores de ruido, algoritmos de enfoque y demás, que han hecho que el creador del proyecto se retire del mismo por no compartir plenamente esta linea.
Sin embargo esto ha hecho que como usuarios podamos disfrutar de un revelador con algunas características que echamos de menos en UFRaw como: ajustes de enfoque y nitidez (además con diversos métodos como filtros paso alto, máscara de desenfoque y más), ajustes de curvas por componentes RGB y Lab, reductores de ruido (GreyCStoration), correción de lente mediante lensfun (aunque esta ya esté también disponible en ufraw para compilar) y procesamiento por lotes desde la interfaz gráfica. Por supuesto también comparte muchas características de UFRaw.
En cuanto probemos esta aplicación nos daremos cuenta de que precisamente una de sus características es la abundancia de parámetros que se pueden ajustar. Esta, pienso, es a la vez su virtud y su defecto.

Para empezar a usar dlRaw lo primero que hay que hacer es compilar la aplicación. Podemos descargar el tarball de la última versión desde la web del proyecto en sourceforge:dlRaw.
Podemos compilarla tanto en linux como en windows, sin embargo en el presente artículo nos centraremos en el caso del sistema operativo libre. En la página del proyecto viene ampliamente explicado el proceso para hacerlo en el sistema propietario.
Una vez descargado el archivo comprimido lo extraemos en la carpeta donde deseemos trabajar y a continuación comprobamos que tenemos las siguientes librerías necesarias:
libqt4
libjpeg62-dev
liblcms1-dev
liblexiv2-dev (libexiv2-dev en mi ubuntu)
compilador g++
Hasta aquí las que figuran en la documentación. Yo tuve que instalar también estas:
ccache
libmagick++-dev (tiene algunas otras librerías asociadas)
qt4-qmake
libqt4-dev

Hay que resolver algunas dependencias, si no sabes como hacerlo lo mejor es usar synaptic o similar.
A continuación desde una consola y en la carpeta donde descomprimimos el archivo ejecutamos qmake y después make.
Con esto concluirá el proceso y podremos lanzar la aplicación ejecutando el archivo dlRaw que se encuentra en la carpeta de trabajo. Si quieres poder exportar el revelado directamente a gimp deberas pegar en la carpeta de plugins de gimp (generalmente /home/tuusuario/.gimp-2.6/plug-ins) el archivo dlGimp generado en la carpeta de trabajo.

Una vez lo ejecutemos, con File>Open podemos abrir el raw que queremos revelar y empezar a trastear.
Cuando terminemos podemos exportar nuestra foto a .jpg o .tif (a 8 o 16bits) con el botón del icono del diskette abajo a la derecha, mandarla a gimp con el boton inmediatamente a su derecha o guardar un archivo de configuración (job file) .dlj que nos servirá como base si lo deseamos para un proceso por lotes (batch).
Estos procesos también pueden llevarse a cabo desde File. En el resto de desplegables podemos configurar un poco el comportamiento de organización y visualización de las herramientas.

Pasemos ahora a dar un vistazo general de los parámetros de ajuste que tiene el programa.
Vemos que está organizado en base a un grupo de pestañas horizontales, algunas con pestañas verticales anidadas, un histograma, una barra con ajustes de zoom y una ventana de previsualización.
Cuando abramos nuestra foto la primera pestaña que veremos será la de Procesing con la subpestaña Camera. En ella podemos realizar correciones genéricas como cargar un "Darkframe" y lo que dlRaw llama "Bad pixels file" para corregir píxeles quemados y ruido del sensor.

También tenemos un completo ajuste del Equilibrio de blancos (parece que basado en UFRaw) con muchas situaciones preconfiguradas y ajuste manual tanto del punto blanco como del negros.
A continuación tenemos otro grupo de ajustes como Denoising, Interpolation, Median Filter y Highlight. Todos ellos orientados a los ajustes iniciales de conversión del raw y su representación: interpolación de los píxeles, reducciones de ruido y artefactos y comportamiento en la representación de altas luces.

Para ayudarnos en nuestros ajustes en la parte inferior tenemos un histograma muy configurable y un activador de avisadores de sobre y subexposición que se reflejan en la ventana de la derecha donde vemos un previo de la imagen en la que estamos trabajando.

Es importante destacar que en dlRaw casi todos los ajustes se realizan sobre un previo, y que podemos trabajar sobre una reducción a 1:4 del tamaño original, cuando terminemos podemos variar este parametro a 1:1 para comprobar el resultado a tamaño completo y entonces exportar el resultado. De esta forma se reduce el tiempo de proceso.
Además algunos de los ajustes pueden realizarse indicando que no se hagan efectivos hasta el procesamiento final, justo antes de la exportación.
A la derecha de este ajuste tenemos los controles habituales de nivel de zoom sobre la imagen del previo.

En la siguiente subpestaña LensFun tenemos como su nombre indica los ajustes de este plugin de corrección de lentes. Si tienes la suerte de utilizar material listado en las bases de datos de LensFun podrás aprovechar su potencia para corregir aberraciones ópticas diversas como distorsiones geométricas, cromáticas y viñeteos.

En la subpestaña RGB podemos realizar ajustes de geometría y reencuadre de la imagen como recortar con una relación de aspecto determinada, girarla libremente, voltearla horizontal y verticalmente e incluso utilizar unas plantillas de la regla de los tercios, la proporción aurea y de diagonales para guiarnos en nuestro reencuadre.

Así mismo tenemos unos parámetros de Intensidad de Color, Mezclador de canales, corrección de la exposición, Gamma y linealidad, normalización de color, recuperación de altas, medias y bajas luces, contraste y niveles de negros y blancos que actuan sobre la imagen en modo RGB.
Estos ajustes se repiten en la siguiente subpestaña LAb Color/Contrast pero esta vez actuando en modo Lab.

A continuación tenemos la subpestaña Lab Sharpen/Noise en la que encontramos una de las secciones potentes en cuanto a lo que suele echar en falta en otros reveladores raw.
En ella podemos trabajar con reductores de ruido como GreyCStoration y Wavelet Denoising con todos los parámetros posibles. También tenemos herramientas como USM (máscara de desenfoque), Filtro paso alto y otras menos conocidas para entresacar la nitidez que se oculta en el raw.

En la misma subpestaña por último tenemos un generador de ruido llamado Film grain simulatión con unos resultados creativos bastante interesantes que realmente recuerdan al grano de la época de la película química.
Todos estos ajustes se realizan también sobre el modo LAB, que parece que es en el que mejores resultados se obtienen.

En la subpestaña EyeCandy nos encontramos con varias e interesantes herramientas. Una de ellas es una herramienta de conversión a blanco y negro que lejos de ser un simple mezclador de canales incluye tanto un simulador de filtros (los tradicionales del b/n: rojo, amarillo, naranja, verde y azul) como un selector de modos: Baja y Alta sensibilidad, Hiperpancromático, Ortocromático, Alto contraste, retrato, Paisaje y algunos más. Muy completo y con buenos resultados.
Tenemos también una herramienta de ajuste de tonos para sombras, luces y tonos medios por separado que nos permitirá realizar virados de una manera muy versátil, un ajuste de superposiciones graduadas (ajustes de luz simulando un filtro degradado con diferentes tonos, densidades y ángulos), un ajuste de viñeta para crear un viñeteo artificial, un generador de softglow algo parecido al tradicional efecto flou y un nuevo ajuste de intensidad de color que desconozco que diferencia tiene con los anteriores.

La última subpestaña es la Out donde definimos algunos parámetros del espacio de color de salida de la imagen, el reescalado para web y su algoritmo y los ajustes de compresión del .jpg.
Con esto damos por finalizado el recorrido por las subpestañas anidadas dentro de la pestaña Processing.

Fuera de esta última nos encontramos con la pestaña Curves donde disponemos de un potente editor de curvas por componentes: RGB, R, G, B, L, a, b, Curva Base y Curva después de gamma.
En todas ellas podemos generar puntos de inflexión mediante el botón derecho del ratón y desplazarlos después con el izquierdo mientras observamos el resultado en el histograma y en la ventana de previo.
Disponemos también de la posibilidad de salvar y cargar las curvas que diseñemos. En la instalación del programa ya se incluyen algunas interesantes para trabajar con ellas. Para seleccionar el tipo de curva que queremos retocar solo hay que pulsar en la pestaña correspondiente.

La siguiente pestaña horizontal es la de Info en la que podemos consultar parte de la información EXIF que nuestro raw lleva asociada.

La última pestaña es la de Settings donde podemos hacer la gestión de color de la aplicación y definir el comando de gimp que utilizaremos para la exportación. Aquí disponemos de muchos perfiles de cámaras pero como espacios solo disponemos de sRGB en la instalación. Lógicamente podemos cargar los que queramos, o dispongamos, manualmente. Por los comentarios de algunos compañeros de fotolibre.net se valora muy positivamente la cantidad de perfiles de entrada (de cámara) disponibles. Lógicamente esto simplifica mucho la obtención de un resultado que nos acerca mucho al conseguido a nivle de gestión de color en el jpg directo de cámara.
Otra opción disponible en esta pestaña es la de registrar todos o varios de estos parámetros como configuración base del programa, lo que nos ahorra un tiempo precioso manteniendo una coherencia en el trabajo en series, por ejemplo.

Este ha sido un recorrido general sobre dlRaw, una primera toma de contacto para hacernos una idea de las herramientas de que disponemos. Su potencia aun está por comprobar aunque tiene una pinta estupenda y durante mis pruebas no ha sufrido ningún problema de ningún tipo más allá de algún texto de ayuda que no corresponde con el botón a que apunta.
Para el trabajo diario quizás sean demasiados parámetros a controlar, sin embargo al mismo tiempo dispone de muchos ajustes que a veces echamos de menos en otros programas y que puedes necesitar en algunos momentos. Estos complementos son practicamente los mismos que podemos instalar en Gimp y es bastante fácil hacerse con ellos.
Espero que alguno de los colaboradores del autor, Jos De Laender , siga con el proyecto adelante porque sería una pena que se perdieran estos avances. En mi opinión es el revelador raw libre con más variedad de herramientas y ajustes que he visto nunca, el que más cerca está de hacerte prescindir de Gimp para rematar las fotos.

Espero que os haya parecido interesante el 'tochito' y gracias por haber llegado hasta aquí.

Un saludo

Actualización:
Precisamente al ir a publicar el artículo he recibido una invitación de Jos De Laender  para unirme a las listas de correo de jdlRaw, un fork de dlRaw que se convertirá en su próximo proyecto. Parece ser que va a intentar mantener las motivaciones iniciales del anterior sin buscar una suite completa como le ha sucedido a dlRaw. El apartado de documentación parece ser uno de los pilares fundamentales. Ojalá salga el proyecto adelante. Yo de momento me apunto a la lista de correo para seguirlo de cerca.

En la pestaña de luminosidad-saturación ahora tenemos un deslizador de contraste, muy práctico también para no pelearse con la herramienta de curvas.

Los controles para corregir la inclinación molan, va bastante fluido (para ser algo inicial) y las reglas guía son muy prácticas.

Voy a sacar un par de capturas de la primera herramienta, que me ha gustado, para comentar un poco más a fondo sus resultados:

He utilizado esta foto del castillo de Pedraza como modelo, porque tiene dos partes cromáticas muy diferenciadas:

Como veis está bastante bien expuesta y con una saturación adecuada, pero vamos a ver si la estropeamos un poco.
Lo primero nos vamos a la pestaña Lightness Adjustments, seleccionamos el azul del cielo y pulsamos sobre el cuentagotas de la pestaña. Entonces se activa una barra deslizante:

Ahora movemos la barra para bajar la luminosidad del azul para oscurecer (aun más) el cielo:

Se ve bastante bien si abrís las dos capturas a tamaño grande y saltáis de una a otra.
Seleccionando una zona de las piedras y activando el cuentagotas se despliega un nuevo control que afectara al color del castillo. En este caso ampliamos la luminosidad (solo a efectos experimentales) hasta 2 y comprobamos el resultado:

He comprobado que a veces cuesta un poco hacerse con el color que más se va a ver afectado en la imagen y hay que repetir varias veces la selección. Seguiré probando a ver que sale.
Como última ilustración os dejo una captura de como trabaja la herramienta de control de inclinación con las reglas activadas:

Como ya se dice los comentarios sobre la versión en la web de UFRaw todavía están verdes algunas de las nuevas implementaciones y no van todo lo fluidas que deberían, aunque se va a hacer un esfuerzo para agilizarlas en próximas actualizaciones.

A disfrutarla!

Haciendo click sobre la imagen veréis una versión a más resolución, y si prestáis un poco de atención al lado izquierdo, veréis que se adivina mi primera caza, el primer rayo de la tarde.

Y hubo más:

Pero fue más el ruido que las nueces, así la calma volvió a reinar, y la luna que en ningún momento llego a desaparecer del todos, como si quiera participar del espectáculo de luz, acabó como única reina en el cielo de la ciudad condal:

De a tarde previa en el parque del Castell de L’Oreneta, también tengo alguna foto que ya subiré más adelante.

De Pedro Madruga se cuentan todo tipo de mitos, incluso hay teorías que aseguran que era el mismísimo Cristóbal Colón. Se cuenta que el apodo de 'Madruga'  se lo ganó porque que ajusticiaba a sus enemigos a horas muy tempranas. Esta fortaleza fue testigo de su historia y de sus más sanguinarias batallas.

Lejos de lo que pudo haber sido su pasado hoy el castillo de Soutomaior es un sitio para visitar plácidamente y sobre todo darse un buen paseo por los jardines que lo rodean.

con su maquinaria todavía intacta

Si vais en pareja es obligada la foto de la chica asomada a los arcos de la Galería de damas:

Si la visita por el interior es interesante

No lo es menos asomarse desde cualquiera de sus almenas a contemplar las maravillosas vistas…

Y como ya dije un recorrido por los alrededores hará las delicias de cualquier interesado en la botánica…