Corrección de fugas y distorsión

En los resultados de esta prueba hay grandes diferencias, pues hay programas que cuentan con múltiples funciones de corrección óptica, mientras que otros no tienen ninguna.

La referencia, recuerda, la establece el revelado de Lightroom (por incorporar RawShooter, al menos en teoría, visto lo visto) corregido posteriormente con el software PTLens desde Photoshop.

Vemos que DxO y Silkypix son los únicos que han conseguido corregir todos los defectos (la foto torcida, las fugas y la distorsión de barril). DxO preserva una mayor parte de imagen, que siempre permite reconstruir alguna parte lisa para aprovechar más lienzo, así que podemos decir que DxO es el ganador.

En el segundo grupo tenemos a los que han conseguido corregir la distorsión, pero no las fugas: Capture NX2, Bibble 5 y CaptureOne 4. Hay que señalar que Bibble 5 cuenta con función para enderezar, pero no funciona, cosa que seguramente se debe a que se encuentra en estado Beta, pero funcionará cuando se termine esta fase. No se lo tendré en cuenta. Los tres consiguen un resultado similar, aunque he de aclarar que con Nikon Capture NX2 es bastante engorroso conseguirlo, por lo poco intuitivo que es. Cuando está activada la corrección de distorsión, resulta que se desactiva sola al enderezar la imagen. Me llevó un rato encontrar la forma de conseguir mantener ambas activas y guardar la imagen.

Por último tenemos a Aperture 2 y Camera RAW-Lightroom, que sólo permiten enderezar la imagen y en último lugar a Raw Developer junto a DCRAW y UFRAW, que no permiten corregir nada.

Con algunos programas la foto no quedó bien enderezada debido a que el cursor en cruz y la línea intermitente que trazan mientras dibujas la línea que sirve para indicarle al programa cómo debe enderezar, tapa los detalles de la imagen que usas como guía, estorbando totalmente en el proceso. Es el caso de Capture NX2 o DxO Optics. No penaliza el resultado, pero sí hace perder tiempo y le resta productividad.

Corrección del viñeteo

Corregir el viñeteo tampoco es fácil y verás que, de nuevo, hay diferencias notables. Recuerda que la referencia consiste en el RAW revelado con Lightroom sin ningún tipo de corrección, posteriormente corregida con PTLens.

Después de un vistazo a todos, vemos que los que más se aproximan al resultado ideal serían (en este orden) CaptureOne-Bibble (empatados), DxO-ACR-Lightroom (empate a tres bandas), Silkypix y Aperture 2. El resto, sencillamente, no han corregido nada, así que todos están igual, salvo porque Capture NX2 se niega a revelar un RAW de Canon y UFRAW se negaba a guardar el revelado del RAW de esta Canon EOS-5D Mk II.

Corrección de la aberración cromática

Y llegamos a la última prueba de la comparativa. Agudiza la vista porque las diferencias no son fáciles de apreciar. Recuerda que de lo que se trata es de ver qué programas eliminan mejor los dobles contornos azules y amarillos.

Bien, pues parece que -una vez más- CaptureOne y DxO ganan claramente la prueba, corrigiendo perfectamente esta aberración. De hecho, superan el resultado marcado por la referencia, cosa que me ha sorprendido.

Ligeramente peor, aunque con un resultado bastante bueno y equiparable a la referencia, están ACR-Lightroom y Silkypix, seguidos de Capture NX2 y Bibble, estos dos últimos con algunos artefactos.

Curiosamente, DCRAW sí consigue corregirlo mientras que UFRAW no ofrece esta corrección (sorprendente, ¿no?). Ambos han reproducido esta zona con un tono demasiado oscuro, pero esto no afecta a la aberración en sí.

Aperture 2 y Raw Developer no cuentan con función para corregir este defecto, así que suspenden la prueba junto a UFRAW.

Tiempo de procesado

Otro de los factores importantes de la comparativa es el tiempo que tarda en procesar y en guardar la imagen en el disco. Como es de suponer, para conseguir la mejor calidad de imagen se necesitan cálculos más depurados y mejor optimizados, que casi siempre requieren más tiempo de proceso. Por eso, lo difícil es encontrar un buen equilibrio entre calidad de imagen y velocidad de procesado. Por otra parte, con la popularización de los procesadores de doble núcleo, se hace imprescindible aprovechar toda la potencia que brindan. Por ello, pondré a prueba su optimización cronometrando el tiempo tanto con uno como con dos procesadores.
Puedes aprender más sobre la CPU y otros componentes del ordenador con la Guía de compra de un ordenador que, aunque no está actualizada te puede ayudar, puesto que los conceptos esenciales no cambian.

Además de la calidad de imagen, para un fotógrafo es importante tener una buena productividad, de forma que un programa que consiga una calidad sublime pero tarde uno o dos minutos por foto no sea muy interesante, porque al final se pierde mucho tiempo. De ahí la importancia de la velocidad.

Para hacer la prueba he revelado con los mismos ajustes dos RAWs (concretamente el del bodegón y la carta de WB) y he medido el tiempo con un cronómetro en mano. La gestión de color estaba activada y configurada (siempre que fuese posible) para usar el perfil de cámara en la entrada y el Adobe RGB 1998 en la salida. El archivo final se ha exportado en formato TIF a 16 bits/canal, ocupando 70,5 MB.

Debido a que algunos programas son de Windows y otros de Mac, decidí instalar todos en un portátil de Apple (un MacBook Pro del 2007), aprovechando que se puede instalar Windows en una partición junto al sistema de Apple en otra. Así, el hardware es exactamente el mismo.
El Mac que he utilizado es un MacBook Pro (de la generación del 2006), y tiene las siguientes características:

* NOTA: El disco duro no es el original, sino que lo he cambiado personalmente por uno muchísimo más rápido.

Con Capture NX2 los tiempos resultaban sorprendentemente cortos, porque guardaba un TIFF en sólo dos segundos, cosa que me extrañó mucho. Al final, descubrí el truco: Capture NX2 mantiene una imagen revelada en una carpeta temporal en todo momento, así que al guardar sólo hace una copia de ésta en otra carpeta. Eso explica porqué es tan lento abriendo cada RAW (lo pre-revela) y porqué tarda tanto en presentar en pantalla cada cambio que se hace (porque lo revela con ese parámetro). Al final, el revelado por lotes (si es que se le puede llamar así, por lo limitado que es) confirmó los tiempos reales, mucho mayores de lo inicialmente visto.

Para la primera prueba he desactivado manualmente uno de los dos núcleos, tanto en Windows como en OS X, y estos han sido los tiempos.

Veámoslo gráficamente:

<<< Atrás