| Greg's comparison of photo processing tools |
| Greg's photography pages |
| Greg's photo albums |
| Greg's photos |
| Greg's photo index |
|
|
|
|
On 16 July 2008 I did some experimentation to compare various methods of exposure compensation for my Olympus E-510 camera. I took five photos of the same scene, with exposures bias of -2, -1, 0, 1 and 2 EVs, with both raw and JPEG images, and then tried to correct the exposure with four methods. I can't display a raw image directly on the web, so the following groups of 7 images are the results. Exceptionally, some of the originals are reduced by 75% linearly: the detail isn't important.
If you have JavaScript enabled, running the cursor over images in this section will give a direct comparison with the original (first) image.
|
|
|||||||||
|
|
|||||||||
|
|
|||||||||
|
|
|||||||||
|
|
|||||||||
|
|
|||||||||
|
|
|||||||||
|
|
|||||||||
|
|
|||||||||
|
|
|||||||||
|
|
|||||||||
|
|
|||||||||
|
|
|||||||||
|
|
|||||||||
|
|
|||||||||
|
|
|||||||||
|
|
|||||||||
|
|
|||||||||
|
|
|||||||||
|
|
|||||||||
|
|
|||||||||
|
|
|||||||||
|
|
|||||||||
|
|
|||||||||
|
|
|||||||||
|
|
|||||||||
|
|
|||||||||
|
|
|||||||||
|
|
|||||||||
|
|
|||||||||
|
|
|||||||||
|
|
|||||||||
|
|
|||||||||
|
|
|||||||||
|
|
|||||||||
|
|
|
|||||||||
|
|
|
|||||||||
|
|
|
|||||||||
|
|
|
|||||||||
The obvious problem here is that the contrast is strongly dependent on the exposure. I can't find a way to do any better with xv. In particular, overexposed images look hardly any better, maybe even worse.
|
|
|
|||||||||
|
|
|
|||||||||
|
|
|
|||||||||
|
|
|
|||||||||
|
|
|
|||||||||
The biggest problem here is the change in colour saturation. The underexposed images come out better, but the lack of detail is apparent in the shade. There's probably nothing to be done here, since the detail was probably never there.
|
|
|
|||||||||
|
|
|
|||||||||
|
|
|
|||||||||
|
|
|
|||||||||
|
|
|
|||||||||
These are the ones done simply by changing the exposure back by the same amount by which it had been misexposed. The results look quite good for the underexposed images, and surprisingly washed-out for the +2 EV overexposed image.
|
|
|
|||||||||
|
|
|
|||||||||
|
|
|
|||||||||
|
|
|
|||||||||
|
|
|
|||||||||
This even manages to make the original image worse! It does probably the best for overexposed images, but worse than the manual adjustment for the underexposed images.
|
|
|
|||||||||
|
|
|
|||||||||
|
|
|
|||||||||
|
|
|
|||||||||
|
|
|
|||||||||
On the whole, these images look pretty much the same as the original JPEG, but they are corrected for distortion.
|
|
|
|||||||||
|
|
|
|||||||||
|
|
|
|||||||||
|
|
|
|||||||||
|
|
|
|||||||||
These produce what I consider the best results for this kind of subject. In particular, the shadow detail is better than any of the others. Not surprisingly, it handles the underexposed images best, though they're clearly still inferior to correctly exposed images.
|
|
|
|||||||||
|
|
|
|||||||||
|
|
|
|||||||||
|
|
|
|||||||||
|
|
|
|||||||||
It's clear that using the raw image gives better results, but they're not spectacular. In the darkroom, 2 EV is not a big problem to compensate for. With modern digital sensors, it seems to be so. Like with diapositive film, it's also clear that it's better to underexpose than to overexpose. And the best way to do things is probably still manually with ufraw; there are less mechanical approaches than by EV.
Comparing the processing tools, it's clear that DxO wins. While the default results barely differ from the in-camera JPEGs, the “artistic” profile really lifts the shadows and makes even the -2EV image look almost acceptable.
After that, it's not so clear. With xv I was able to get better results from the underexposed images, at the expense of some burnout in the highlights. ufraw's auto-exposure compensation appears useless, and the manual use of ufraw is not very convincing. In particular, it handles the underexposed images badly.
It's also interesting to note that the raw files aren't much larger than the high-quality JPEGs, so I can move to using only raw images:
=== grog@dereel (/dev/ttyp2) ~/Photos/20080716 830 -> l full-size/
total 88
-rw-rw-r-- 1 grog 502 7699834 Jul 16 12:31 P7163674.JPG
-rw-rw-r-- 1 grog 502 11486466 Jul 16 12:31 P7163674.ORF
Despite claims on the web, these raw files must be compressed; otherwise they would be over 20 MB in size. That should save me having to buy a larger flash card for the camera.
| Friday, 18 July 2008 | Today's diary | Today's images | top | next | last |
It occurred to me that the tests above left out the obvious contender: the “Master 2” software provided by Olympus specifically for the camera. Somehow I have prejudices about that sort of thing, but today I decided to try it out anyway, on boskoop, my old G4 Apple. It did nothing to dispel my prejudices.
Admittedly, boskoop is not exactly state-of-the-art, but even so, taking 20 seconds of CPU time to start up is a bit extreme. Then it continued with an animated help screen, showing nothing more interesting than an adapter card being pushed into the side of a laptop, along with a text in a too-small window with a scroll bar, using about 90% CPU time—even when iconified! And that on a desktop machine to which I connect the camera with a USB cable:
|
|
|||||||||
This help brings with it an obligatory way of looking at the world that is completely different from mine. “How to Enjoy Slide show?”, for example. But where are my files? “How to Browse Images/Movies?” looks like the right one to choose, but it just tells you (in four screens with one or two sentences each) how to work your way around the “Browse” window. The only way I could find to actually get new images is from the camera. It seems that these people just don't understand file systems. Spent some time looking for a way to look at existing images; it doesn't seem to cater for that.
Took a look at the “Browse” screen, which offered a function “transfer”, which does exactly that, even when not necessary: it seems that to process photos, it first needs to copy them to an “Album”, and that it did—all 650 MB of the photos I took on Sunday—once I found a way to type in the name: it wanted me to select from a graphical representation of “folders” with duplicate names:
|
|
||||||||
|
|
||||||||
The directory I'm looking for was NFS mounted as /dereel/home/grog/Photos/20080713, so it would be reasonable to assume that dereel in that second image would be the place to look. But no, that's a different file system. This is one of the two entries marked home. Which one? No idea.
Fortunately, if you close that window you get the opportunity to enter the directory name manually, without any help like file name completion, and without the option of globbing for specific files only (at least, I couldn't find one). After only 15 minutes and the best part of a gigabyte of data, I was in the position that I am by default with real software.
Well, almost. After a bit of searching (WHY do you always have to search for these things? WHY can't they just tell you the path?), discovered:
=== grog@boskoop (/dev/ttyp1) ~/Pictures 8 -> l -rt
total 193
...
drwxr-xr-x 3 grog 1000 102 Jul 18 18:40 OLYMPUS Master 2
=== grog@boskoop (/dev/ttyp1) ~/Pictures 9 -> cd OLYMPUS\ Master\ 2/
bash: cd: OLYMPUS: No such file or directory
These horrible path names with spaces in them, which continually mess up scripts. In my case, I define cd as a bash function, and it trips over spaces even if, as in this case, they're quoted.
And of course the files were transferred in alphabetical order without maintaining the modification time stamps (even though they all had EXIF data), so I ended up with them all out of sequence.
Apart from that, the software seems to offer much the same functionality as ufraw. It has some things, like compensation for chromatic aberration, that I don't think ufraw has. But who can bear to use that sort of thing?
| Greg's home page | Greg's diary | Greg's photos | Greg's links | Copyright information |
| $Id: image-processing.php,v 1.6 2012/06/18 01:34:51 grog Exp $ |