New in Lightroom 3 Beta 2

And from Abobe TV a quick presentation of the latest additions in Lightroom: http://tv.adobe.com/watch/what-s-new-in-lightroom-3-beta/whats-new-in-lightroom-3-beta-2/

My first impression:
It really feels snappier. As an Olympus user I can’t use the tethering so that won’t be tested. And I really like the improvements in the noise, curves and watermark section.

A small problem though: if you don’t have anymore the RAW files on the disk, it doesn’t read the rendered previews from the previous Lightroom 3 beta 1.

I will offer one real life example just to give you some clues about the complexity and importance of correct color rendering. A while ago, in one of the advertising agencies I worked for, we had an apparently simple task: produce a new product catalogue for one of our clients. While building the whole catalogue was by itself a very challenging task because it had texts in 4 different languages: English, German, Japanese and Arabic, another problem proven to be the real deal: rendering texture and colors accurately for the marble tiles that constituted 90% of the product samples. Even after making sure the second time that the entire production chain was color calibrated (computers, printers, raster image processor in the prepress lab plus the offset printing machine) and after taking and processing a new set of photos, the customer was not completely satisfied by the color samples in the catalogue: very small color variances added up throughout the whole chain and the final result was somehow off.

For more info on the combined subject of color representation and photography you can start by reading the very good introductory lessons by Sean McHugh at Cambridge in Color. For more in-depth info about the problematics of color rendering, you can check the website of International Color Consortium (www.color.org). Some samples: Tutorial on Color Management; Color Management: Current Practice and The Adoption of a New Standard and the section regarding photography.

In the previous episode I’ve started pondering around the color rendering – especially in regard to the White Balance. But let’s see which are the instruments offered by each of the application and how they may help in our quest for the perfect color. First of all, we have two categories of color correction adjustments: global and advanced or fine tuning. While the global correction are best suited for everyday photography, fine tuning answer to the big question of pinpoint color accuracy.

In this part I will start with the applications having the minimal set of tools: no real color accuracy here. Click on each application name to preview the interface.

RAW Drop – the most basic support for rendering RAW files: Auto WB, Use Camera WB. No histogram, no preview. Combined with the fact that the application auto adjusts the exposure such as 1% of the resulting image pixels to be white, we have the perfect situation for a totally unpredictable result.

Picassa 3 – Has the all in one set of auto tools and effects plus manual adjustment of Fill Light, Highlights, Shadows and Color Temperature (WB) including neutral color picker.

IrfanView – in itself not a RAW Developer, but I have used it in the previous parts to provide a base reading since it extracts the jpg preview saved within the RAW file. It offers a very basic set of tools not specific to RAW processing but to image processing in general: Histogram, Brightness, Contrast, Gamma, Saturation, RGB Color balance plus the all automatic Auto adjust color and Convert to Grayscale. As a bonus, through the plug-in interface, it has support for Adobe Photoshop 8bf plug-ins. The bad news is that the adjustment previews are so small that they are of no real help.

Breeze Browser Pro – 8 WB Presets: Camera, Auto, Sunny, Cloudy, Shade, Flash, Fluorescent, Incandescent plus manual adjustments of Levels, Saturation and Gamma. Only luminosity/gray histogram. Almost full screen preview

Olympus Master 2 – the basic set of tools for global color correction. The interface is very modal: one edit at a time, click OK, then another edit. This mode is not suitable for batch processing. But the application has a second mode “Edit RAW” where the edits can be applied to a selection of photos. But for more advanced functions and for remote control of your camera you must buy Olympus Studio 2. The same situation is valid at Canon and Nikon. They include with the camera some basic applications, but to really develop your RAW files you have to pay.

Scarab Darkroom – All the basic color correction tools (including editing with numerical values and copy/paste of development settings. Everything available at hand as sliders and as numerical input boxes, no fiddling with tabs or application modes which are mostly a waste of clicks. While the interface is a bit unpolished, it sets the standard of minimal functionality, and it should be implemented by all the camera manufacturers in their basic editing software.

From this first set, only Scarab Darkroom and the basic offerings from camera manufacturers can be really classified as RAW developers. The above applications are best suited as viewers or for basic home use and are included here as reference only. Anyone really thinking about controlling the results in their photography should avoid them at all costs.

Technical data: Olympus E-3 body with Olympus Zuiko Digital 50-200 f:2.8-3.5 SWD lens, 200 mm, f:3.5, 1/500 s, ISO100, Auto WB, Color Profile: Adobe RGB.

Not wishing to go through the same nightmare as during the previous section, I’ve started with the latest version of DxO Optics since its supposed to support Olympus E-3 RAW files. Even if the module for the lens used for this photo is not yet available, DxO rendered the file. With one hiccup: it crashed just after it saved the rendered file. So I’ve proceeded with this test file and the rest of the group.

The glitch: it seems that even if the white balance was set to auto, every software has it’s own idea about what means that value. See the following table for the temperature and tint values reported by each software.

Next are the renderings from each software. The files were saved by each developer as Adobe RGB, full size, best quality jpg files, then stacked and aligned in Photoshop, converted to sRGB, resized to 800×600 px and each layer saved as jpg file by the script “Convert layers to files”.

Now the real problem would be to identify the real color temperature of the image. I’m inclined to go with the value from the Olympus Master as it’s the software from the manufacturer of the camera. But most of the other software developers color temperature value readings roam around 5200.

As a further step I’ve tried to bring the different color adjustments to the same values in all the different developers that had this option. And it’s a real mess.

Next step was to put the camera on a custom white balance value and go from there. No such luck. Each software still interpreted the white balance of the image as it considered. As a point, Silky Pix (5377 K) and Olympus Master were very close (5370 K) to the value shown in camera (5400 K).

Next you have the temperature value from each software:
Bibble Pro: 5044
Breeze Browser: WB Custom
Adobe Camera RAW: 5000
Capture One: 5150
DxO Optics Pro: 5327
Adobe Photoshop Lightroom 2: 5000
Adobe Photoshop Lightroom 3: 5000
IrfanView: WB Custom
LightZone: 5864
RAW Drop: WB Custom
RAW Therapee: 5095
Scarab DarkRoom: 6100
SilkyPix: 5377
SilverFast HDR: 5550
UF RAW: 5094
Corel Paint Shop Pro 12.5: 4999
ACD See Pro 3: 5036
Olympus Master 2: 5370
Picassa 3.5: WB Custom

I don’t have even the slightest idea why the different software developers choose to completely ignore the WB value stored in the RAW file and go with their own value. Somehow, this beats all the purpose of setting a custom white balance on location in your camera. It seems that you have to completely rely on your perception of color as no recommendation can be done.

Update: I have received the complaint that the file I have provided is not a repeatable situation. I didn’t say that I want to calibrate the different applications. My purpose was to see if there is a common denominator for color rendering. And considering the extensive batch of 20 different applications, I think I can safely consider my conclusion as correct.My photo is not a lab reproducible image, but it contains the full color spectrum in a late afternoon situation (June 23, 2009; 16:38) and is correctly exposed, with 0.1% of overexposed pixels in the left flag yellow area and no underexposed areas (info from UF RAW).

I don’t find the color rendering as being a show stopper for most exterior shots. But go in the studio for a product shot and that suddenly changes. And, as I have proven in the above article, you can’t rely on the software to accurately match the color!

2nd update: For reference I have added the resized PSD file with the aligned renderings and four different 31×31 pixel color sample points (20.1 MB).

The next step would be to statistically calculate the color variance and try to determine a set of settings for each software that renders identical files. But one question raises: do we need as consumers to establish the standards for color rendering, or the software developers need to, at least, take into account the custom set White Balance and start rendering the file from there, considering that this is the main tool we have in our cameras to establish accurate color?

RAW Drop can be found here: http://www.wizards.de/rawdrop/

Thanks to a tip from a reader on the forum at FourThirdsPhoto, there is a better method for recovering the “lost” pixels in a RAW file. Just use the DNG Recover Edges utility which was featured on the Luminous Landscape.

The best part is that you get the benefit of working with a DNG file. But be aware that not all the RAW Developers support the DNG file format and more than this not all the RAW Developers that support the DNG will recover all the data.

Adobe Camera RAW, Lightroom 2 and 3 beta, CaptureOne, SilkyPix do support the DNG file format and will recover the same number of pixels as RAW Drop.

LightZone, RAW Therapee, Scarab DarkRoom, SilverFast support the DNG file format but don’t save all the available pixels. They just reproduce their behavior with the original RAW files: i.e. they save more pixels than the specification. If you use any of these, the conversion to DNG is just a waste of time.

Bibble Pro 5 and DxO Optics Pro 6 don’t support the DNG file format.

IrfanView will see only the embedded preview and save only a small image 1024 x 768 px.

Breeze Browser Pro at first seems to read the DNG file but the convert function is disabled. Trying to send the file by email without downsampling is a useless attempt as the file attached to the email is the same small preview seen by IrfanView.

Technical data: Nikon D300, Nikon 18-70mm f/3.5-4.5 AF-S DX @ 35 mm, F:4.2, ISO 800, 1/60s
In camera noise reduction: Off

As you can see the image is heavily underexposed and as a first step we’ll crank up the exposure to the available upper limit. Each program has a different scale for exposure compensation and, in the case of RAW Drop you can’t even control the exposure but the software autoexposes so 1% of the image pixels will be white.

Each software will have (with some exceptions as you’ll see in the conclusions below) a rendering using it’s standard settings with just the exposure cranked to the limit and then some other renderings using the different methods of Noise Reduction available. Below is a gallery of 1:1, 400 by 400 pixel crops from the resulting renders.

By request, I have added also the renderings and the text comment for Nikon Capture NX2.

Comments regarding the results:
- Bibble Pro – a really nasty error, the file is only partially read (see here), the last 20% on the right side are black. And this happens on two of the NEF files I have. The third one, depending on the “mood” of the software is either correctly read, or it presents severely black banding across the image;
- Breeze Browser – even if the file is correctly previewed as portrait, the rendered files are landscape. Also, the difference between the renderings is so small that you can export without any noise reduction at all.
- Adobe Camera RAW, Lightroom 2 and 3 – the resulting images are overly saturated, in order to have a image on par with the other RAW developers you have to reduce also the black clipping levels to 0. As stated by the Adobe Labs Team, the new rendering engine in Adobe Photoshop Lightroom 3 is just another story in terms of noise reduction compared with the old engine. Just be careful about the position of the slider: cramming it up to 100 produces a bad halo around the edges in the high contrast areas.
- Capture NX2 – The default rendering is good, but we have to take into account the fact that the exposure compensation is for only 2 stops. The color noise removal is not effective at all. It masks alot of details and if the High Quality mark is checked, we are back to square one. The difference between the standard rendering and the HQ color noise removal is nearly invisible in a 16bit tiff file. If the images are used only as 8bit, then fiddling with noise removal is just a waste of time.
- Capture One Pro – Using the Colour Noise Reduction is just as bad as using a large blur brush in Photoshop. You lose details very quickly, and by dragging the slider up to 100 you can obtain a really, really nice out of focus image. The best solution here is to remain with the default rendering – no noise reduction at all.
- DxO Optics Pro – the bad surprise of the batch! With a supposed working combination of Nikon camera and lens the rendered image was totally out of control. One of the images I have was taken with another supposed supported camera/lens combination AF-S VR Micro-Nikkor 105mm f/2.8G IF-ED and its equally bad. And I’ve tried on four different operating systems: XP Pro 32bit, XP Pro 64bit, Windows 7 RC 32bit and Windows 7 64bit RTM. On top of that, I have to add the fact that the program is constantly crashing and you have the whole picture of a really bad combination. As a last resort I’ve tried also with the Canon CR2 File I have and it renders the file correctly but I won’t update the whole review just for the sake of a poorly written piece of software. As a note I’ve lost more than 5 hours to find the working combination in order to complete the review with the Nikon RAW file.
- LightZone – a nice treat: you can stack filters for a precise control of different developing processes.
- RAW Drop – As I’ve said before, it has no exposure compensation, but it automatically adjusts the exposure of the image to render 1% of the pixels white. I’ve exported the default rendering and 3 levels of noise reduction. From what I can see, it’s the last resort if you want to render RAW images.
- RAW Therapee – A medium contender for its noise reduction algorithm. But it gets a big plus because it’s a free RAW developer.
- Scarab Darkroom – I finally managed to install and to have a working combination of the software as it seems that some hardware/software combinations aren’t yet supported and Scarab crashes on start-up. It renders the file correctly and it has the basic editing tools but no noise reduction capability whatsoever. Though, you have to consider it’s still in the early beta stages.
- SilkyPix – just another case of weak noise reduction algorithms, better stay with the default rendering.
- SilverFast HDR – It has the most extensive array of noise reduction algorithms. I posted several combinations of the three different technologies included. Even if it’s not the most intuitive interface and the most accurate preview, I think it has the best potential to handle noise.

Just as an additional example of correcting exposures and noise reduction algorithms, I have added two one image HDR files made with Dynamic Photo HDR and Photomatix.

If you want to examine stripes of 400 px height across the rendered result from each developer and the results of the HDR processing, you can download them here (34.3 MB Zip file). The settings used are explained in the above gallery.

DxO Update: since DxO Labs published today the new Windows version of its software, I’ve decided to give it a try and reached the same conclusions as before. I have downloaded and installed the new version on the same test system as the previous version and it renders the test file exactly in the same way. The second test configuration for DxO Optics Pro 6 was a freshly installed Windows Virtual PC updated with the latest .Net FX 3.5 package as it is a prerequisite for installation. DxO worked fine on that single file but the rendered file is still totally wrong. I will install DxO on a second machine, but I don’t hold any hopes on that.

If somebody has the time and wants to test DxO Optics Pro 6 with my test files, please leave a comment on my blog and I will contact you.

DxO update 2: I have installed DxO Optics Pro 6 on another system just to exclude any hardware platform dependency (CPU: AMD Athlon XP 3000+, MSI Motherboard with nForce chipset, video card nVidia GeForce 5200 64 MB, 1 GB RAM, HDD Western Digital 40GB, Windows XP Pro SP3) and I got the same results on the test files: completely wrong rendering of the Nikon D300 NEF file and application hang-up if there are any unsupported RAW files in the folder(in this case one Olympus E-500 ORF file).

I’ve decided to run for the test only generally available tools for developing RAW files as the software from the camera makers is only good for their lineup.

All the software below is the latest (trial) version.

The contenders are:
- Bibble Pro 5.0
- Breeze Browser Pro 1.9.4.1
- Adobe Camera RAW 5.5 (ACR)
- Phase One Capture One 4.8.3
- Adobe Photoshop Lightroom 2.5
- Adobe Photoshop Lightroom 3 beta
- LightZone 3.8
- RAW Drop 1.11 – Free
- RAWTherapee 2.4.1 – Free
- Silky Pix 4.1.22.1
- SilverFast HDR 6.6.1r3a

As viewers, I’m using FastPictureViewer x64 and IrfanView 4.25. This post preview image is saved with IrfanView.

For file processing I use Adobe Photoshop CS4.

I tried to use also DxO Optics Pro 5.3.5 and Scarab Darkroom but DxO doesn’t support Olympus RAW files even when converted to DNG using ACR and Scarab is still detected as a potentially dangerous application by NOD32 even after announcing the developers more than 3 months ago.
(Due to the high response rate and by request, I’ll get some Nikon and RAW files and include also DxO in my review.)

The test platform is Windows 7 64bit, Intel Core2 Duo 6600, 4 GB DDR2 Dual Channel, dedicated HDDs for the OS (250 GB), photos (500 GB), pagefile (250 GB) and temporary files (160 GB) each one defragmented before the start of the test with Defraggler 1.14.159. The videocard is nVidia 6600 256 MB. Not the latest hardware bells and whistles but still working properly.

The first file processed is a real nightmare for any noise reduction engine. A night shot with Olympus E-500 firmware 1.3 at 1/10s, f4, ISO1600 with the Zuiko Digital 9-18 f:4-5.6 firmware 1.1 at 9 mm. You can see the preview in the post image.

First surprise:
As I tried to make identical crops from the unresized resulting TIFF files by using a predefined action, I realized that some of the crops were offset by more than a pixel. And so we come to the real surprise. The Olympus E-500 RAW image size should be as per specification of the manual: 2448 x 3264 px.
Five of the programs exported the files as per specification. The rest of them not:
- Bibble Pro: 2496 x 3328 px
- RawTherapee: 2496 x 3332 px
- Breeze Browser: 2502 x 3337 px
- SilverFast HDR: 2502 x 3338 px
- RAW Drop: 2504 x 3340 px
- LightZone: 2504 x 3340 px

As a curiosity I’ve looked at the EXIF data from IrfanView: 2504 x 3360 px …

At first I was thinking that somewhere in the export process I’ve scaled by mistake two of the files. But it wasn’t my error. The two files were really exported that way. I decided to investigate further and the result was unbelievable, not only the sizes were different, but also the relative margins of the file were really different as you can see in the image below (click for zoom). For the full size click here.

As reference for alignment between renderings I’ve used the name of the store “El Corte Ingles” and the top corner of the building.

As you can see, ACR and both versions of Lightroom rendered within the same borders, but all the products from the other vendors were off by at least 3 pixels in each direction. The good part is that the border of the Bibble Pro, RawTherapee and the other bigger files encompasses the area rendered by the other developers. I’ll try to get my hand on some RAW files from Nikon and Canon cameras to see if the “error” is consistent.

UPDATE:
I have got some NEF and CR2 files and it seems the story is repeating. RAW Drop and LightZone provided always the bigger files:
- Canon 400D CR2 File in ACR: 3888 x 2592 px versus 3906 x 2602 in RAW Drop and 3898 x 2594 px in LightZone;
- Nikon D300 NEF File in ACR: 4288 x 2848 px versus 4320 x 2868 in RAW Drop and 4312 x 2860 px in LightZone.

So, excluding RAW Drop and LightZone, all the other RAW developers had chosen different areas from the RAW file for rendering. If you have an object that just bites the edge in an unique photo, it’s worth trying another editor to see if that object is in fact complete or not.

On the next episode (November 2nd) I will post the noise reduction test results.