RAW Developers Review – Color Rendering (updated)
Do you love the gay community? I’ve just found one compelling reason for you: RAW Developer color rendering. With their colorful symbols they are the perfect real life situation for a color rendering comparison. See the post image for the rendering from IrfanView.
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.
RAW Developer |
Temperature |
Tint |
| Bibble Pro | 5215 | 8 |
| Breeze Browser | WB Auto | |
| Adobe Camera RAW | 5150 | 0 |
| Capture One | 5350 | -3 |
| DxO Optics Pro | 5380 | -2 |
| Adobe Photoshop Lightroom 2 | 5150 | 0 |
| Adobe Photoshop Lightroom 3 | 5150 | 0 |
| IrfanView | WB Auto | |
| LightZone | 6100 | 0 |
| RAW Drop | WB Auto | |
| RAW Therapee | 5266 | 1 |
| Scarab DarkRoom | 6200 | 0 |
| SilkyPix | 5556 | +2 |
| SilverFast HDR | 5750 | -2 |
| UFRAW | 5265 | 1 |
| Corel Paint Shop Pro 12.5 | 5177 | 2 |
| ACD See Pro 3 | 5205 | 0 |
| Olympus Master 2 | 5548 | 0 |
| Picassa 3.5 | WB Auto | |
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”.
[Gallery not found]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).
Further investigating the problem, I’ve decided to read the full EXIF data from the camera in order to see where could be the problem of such a big difference between WB readings. By using the PhotoME, I got access to this info. The values of interest for us are the following:
White Balance 2: Auto
White Balance Temperature: Auto
White Balance Bracket: R-G: ±0, B-M: ±0
Custom Saturation: 0 (min -5, max 5)
Modified Saturation: Off
Contrast Setting: 0 (min -5, max 5)
Sharpness Setting: 0 (min -5, max 5)
Color Space: Adobe RGB
[...]
Red/Blue Levels: 478, 358
[...]
Red/Blue Levels 3000K: 270, 728
Red/Blue Levels 3300K: 332, 565
Red/Blue Levels 3600K: 358, 515
Red/Blue Levels 3900K: 381, 478
Red/Blue Levels 4000K: 433, 567
Red/Blue Levels 4300K: 402, 447
Red/Blue Levels 4500K: 440, 457
Red/Blue Levels 4800K: 438, 406
Red/Blue Levels 5300K: 466, 377
Red/Blue Levels 6000K: 513, 342
Red/Blue Levels 6600K: 515, 381
Red/Blue Levels 7500K: 560, 295
As you can see the EXIF values for Red/Blue levels are in the interval between 5300 and 6000 K. But we have no less than 10 applications that report a WB value outside of that range.
And for the second image that I took, the value is hardcoded in the EXIF data. So there should be no confusion.
So now we have a reasonable question. Where is the error in the color reproduction? Could be the lens, the sensor, the camera software or the RAW developer? While the first three really have a contribution in color rendering – and I will point just the common causes of color shifts: chromatic aberrations, incident light, color & mix of the available lights, exposure duration – the RAW developing engine is the nastiest culprit. We could never remember the exact values of WB Temperature for each photo we take, but we have a reasonable expectation to see that value read “as is” from the file. If we, as photographers, consider later on that we have to correct the WB, add emphasis in some areas or alter the color in any way we see fit, that is another story.
As final points:
One: I don’t consider that controlled environment as being the real problem in my approach. I could make a complex studio test scene a la DP Review or any other review entity out there. But the point is that even if you can use the same objects, and the same reference color charts, you would use at least a different camera and lens, different soft boxes, flashes and a different neutral painted room. And each and every one would slightly alter the colors.
Second: Take a photo in broad daylight and do this simple test in your usual RAW developer: change the WB value of the photo from 5000 K to 6000 K, save the renderings and compare them.
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).
This is part of a more technical argument regarding the method I used: I started by using the same RAW file and from 20 different applications exported full size and full quality, AdobeRGB, jpg files. I open all of them in Photoshop and align them by using Automate/Photomerge then I verify that each layer is properly aligned. I take 4 different color sample points with 31×31 pixel size to mitigate any remaining alignment errors and close the layers one by one. The read values in the sample points are different. There is no subjective wrong perception of color it’s just the fact that using another software gives different results.
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?
Related posts:
Tags: Adobe Camera Raw, Bibble Pro, Capture One, CR2, Developer, DxO Optics, FastPictureViewer, IrfanView, Lightroom, NEF, Olympus, Photoshop, RAW, RawTherapee, Review, Scarab Darkroom, Silky Pix, Software
“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.”
-They don’t ignore it, they use the colour stored in the raw file. The problem is sticking a temperature value to it. I think what makes this difficult is that the human eye adapts to the light’s temperature to some degree. So to reproduce the impression, one needs to correct using a colour that’s not exactly the light’s colour. This correction colour is the one that’s saved in the raw file. The algorithm used (which is not public) to guess this colour differs from manufacturer to manufacturer – and also how well this usually correlates with the light’s colour. The value that raw converters try to display is the light’s colour.