[Digikam-users] 16bit editiing and auto-whitebalance

Fri May 9 09:31:26 BST 2008

Hi Elle

Thanks for the very detailled reply. You are of course right that an unmanipulated tif is better than the one with the secret sauce to work with when doing manipulations. 
The thing is... I don't know in advance which picture I'm going to manipulate. This means that I'll shoot everything in raw which makes processing every picture using dcraw extremely time-consuming. So - to me at least, but I guess for many others as well - the ideal workflow would be: 

- Develop all raw files as a batch process using the secret sauce. Gives a good starting point
- Throw away bad pictures
- Reprocess pictures that need manual processing

To me, it seems this first step is kinda hard to do nicely on linux atm. I wasn't able to get ViewNX/CaptureNX to work in wine, lightroom isn't available either. Rawstudio does not really do anything by default (which is good in it's own way) and doesn't have any exif support (in the works, but not released) and the kipi-plugin doesn't do the secret sauce thing. There is rawtherapee and lightzone - both of which are closed source and don't contain support for my D60 (yet)

So this is kinda bad atm

Cheers, Benjamin
elle stone wrote:
> 
> Bugzilla from arnd.baecker at web.de wrote:
>> On Tue, 15 Apr 2008, Gilles Caulier wrote:
>>
>> Should we now switch to 16 Bit as default ?
>>
>>> Done in 0.9.4. auto-gamma is implemented with 16 bits color depth
>> Most likely this is not digikams fault (i.e., ufraw's output
>> looks similary dull to me) as no one (in open source) knows
>> the secret methods of raw to jpg conversion used by Nikon
>> (same with Canon of course, but there the results
>> looked much better, in the cases we looked at together, Gilles).
>>
>> I am not sure if much can be done, though ....
>>
>> Best, Arnd
>>
>>
> 
> Hi, all,
> 
> I think it's very true that Canon and presumably Nikon have some kind of
> "secret sauce" that they use to produce really good-looking images, whether
> straight out of the camera as jpegs, or whether as the result of using the
> proprietary Canon/Nikon raw developer software.  The "secret sauce" has two
> parts - color (hue and saturation) and tonality (distribution of lights and
> darks).  
> 
> Canon DPP, the "not for linux" Canon proprietary raw development software,
> is based on the same "picture styles" that Canon uses for in-camera jpegs. 
> Most Canon picture styles automatically add a heavy S-curve and extra color
> saturation to give the picture more "pop".  Even if you (1)choose "neutral"
> (the Canon picture style that gives you the most accurate "scene-referred"
> colors); and (2)select "less contrast", "less saturation", "no noise
> reduction", and "no sharpening" in the DPP raw development dialog, you will
> find, if you know what to look for, that an S-curve and also shadow
> denoising has been applied to your image.
> 
> Dcraw gives you the lights and darks that are actually recorded by the CCD. 
> According to Tindeman
> (http://21stcenturyshoebox.com/tools/ACRcalibrator.html; alas the site is
> down at present), dcraw is one of only a very few raw developers that
> actually gives you the "scene-referred" tonality.  And it IS flat-looking,
> because the camera CCD records light linearly, whereas our eyes are
> constantly interacting with our brain to accomodate dim and bright areas in
> a scene. 
> 
> Color fidelity is a different story.  Color is where the Canon (and
> presumably Nikon) secret sauce really comes into play.  With the latest
> dcraw, you can apply Canon's camera-model-specific color profile(s) to the
> 16-bit dcraw output tiff during the raw development process, and the colors
> will still NOT not be exactly the same as what Canon produces.  I've checked
> extensively, using an "eyedropper", comparing the output of various raw
> developers using various camera profiles - a very tedious though instructive
> process.  Canon default jpeg and DPP colors are really good.  (If you want
> to hear some belly-aching about Canon colors being "better", try a google
> search on what Adobe Camera Raw does to Canon colors - NObody likes the
> default ACR output for Canon raw files.)  It seems to me that the only way
> to "do better" color-wise than what Canon produces with their "secret sauce"
> is to produce your own color profile for your camera, using Argyll, for
> example, and give your custom color profile to dcraw/digikam,ufraw/etc.  I
> haven't taken that step yet (next on my "learning the digital darkroom"
> agenda).  
> 
> So why on earth would anyone want to use dcraw to develop a raw file, only
> to have an image with rather flat tonality (no S-curve), noise in the
> shadows (no noise reduction unless you specifically choose the wavelet
> denoising, which I never do), and colors that are not as accurate as what
> Canon can produce "in-camera"?  
> 
> The answer is artistic control.  When you take a picture, presumably you
> have an idea of what you want the final image to look like.  It is much
> easier to achieve that final image if you don't have to "undo" stuff that
> has already been done to your image.  Once Canon (or Nikon, or Bibble, or
> etc) has applied their proprietary S-curves and shadow-denoising,
> sharpening, etc to your image, then your shadows (highlights, edge detail,
> etc) are already squashed, clipped, chopped, and otherwise altered and
> mangled.  You've thrown information away and you can't get it back. 
> Especially in the shadows, even with 16-bit images (actually, 12- or
> 14-bits, depending on the camera, but it's encoded as 16-bits for the
> computer's convenience), there just isn't that much information to begin
> with, as explained in Ron Bigelow's excellent article, 
> http://www.ronbigelow.com/articles/raw/raw.htm.   
> 
> Anyway, I hope my long-winded discussion of why dcraw output looks "flat"
> helps cast some light on a confusing subject.  "Flat is good" if you'd
> rather give your images your own artistic interpretation.  The alternative
> is to let the canned, proprietary algorithms produced by Canon, Nikon,
> Bibble, etc interpret your images for you.  Which is not entirely a bad idea
> - for most images, most of the time, those canned alrorithms are really
> pretty good!   
> 
> If I've made mistakes in my explanation, please correct me!
> 
> Elle
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20080509/d92ede18/attachment.sig>