For those who asked or who are interested to see what 16 bit (or 12 resp. 14 bit from RAW) image editing can bring out, might watch the “Basic Tools” video on Bibble Labs: Learning Center. IMO, very impressive the highlight recovery tool. Note, that the hidden details are in the image data, but they need to be made visible, even for your 8 bit monitor or printer output.
The highlight recovery tool is pleasant, but of course it cannot recover fully saturated areas. In reality, the white lace areas of the bride’s dress didn’t recover in the film: they remained completely white. Which is true, since there is no way to deduce the original color from a pixel with color (255, 255, 255) or (65535, 65535, 65535).
So the highlight recovery tool more correctly should have been called “saturation prevention tool”.
Sure, you can “recover” only what’s in the image data. If a part of the image is already saturated or even clipped, there is no way to get it out again: no magic.
IMO, “prevention” is not the right term for it: you can prevent this only when you take the pictures with the right camera settings. However, the details of the white dress shown in example in the video are in the 12/14/16 bit image data - so the photographer didn’t do much wrong. You just make these existing details visible with the right editing tools for your output. Using Bibble’s tools I’ve “recovered”, e.g. details in RAW-photographs I took on the gate of an old locomotive shed (outside quite bright, inside dark). On a first glance, everything inside looked drown in pure black but it wasn’t.
One more note: it is hard to compare PS/Gimp and Bibble. The first two are a general image editing applications with tons of features which allows the user to make a lot of fancy things. The latter is a workflow centric application designed for photographers and for speed: asset management, tagging, rating, basic (and with additional plug-ins even advanced) editing capabilities and batch output. YMMV. Bibble is, compared to PS, a native Win/Mac/Linux application and version 5 (RC) is on trial now. It installs (it is just one rpm file) and runs fine on my openSUSE 11.2. In case you shoot RAW, feel free to give it a go.
So, I’ll stop contributing to this thread now: I go on holidays for skiing and to welcome the New Year. Wishing you all a nice time.
The lack of 16-bit editing may or may not be a show stopper; I’ve done semi-professional photo editing in both PhotoShop and the Gimp for several years, all using 8-bit, without any real difficulty.
Where the Gimp and Linux as a whole fall apart is in the lack of an integrated Color Management System that ensures what you see, for example, on your monitor will closely resemble what you’ll see on a printed copy - and, more importantly, will resemble what you saw on your monitor when it is viewed on someone else’s system and monitor.
There have been several attempts at a CMS for Linux; so far, none have been integrated into the OS and applications. Although Gimp provides hooks for CMS, a per-application solution is no solution at all - CMS requires integration at the OS level to be useful.
Until this happens, the Gimp will never be more than a somewhat useful toy. If you’re doing anything like professional work, bite the bullet and use PhotoShop.
But the GIMP is cross-platform so the weakness of CMS support in Linux is hardly its fault. And with Scribus, Inkscape, etc also supporting CMS (through ICC at least) I’m not quite sure what the problem is? It may be a little more complicated but a colour-managed workflow, including calibrated monitors (as the key link in the chain) under Linux is entirely feasible these days.