the k values are pretty hacky, so don't shudder reading on..
these are normalized to daylight wb, which is said to be 5000k. the values
live relative to that. so that's somewhat an approximation, and we have to
try to get daylight balance from somewhere. judging from a quick look at
your raw i don't think we get daylight white balance values from anywhere,
i think we first check the raw file, then the wb presets for something with
the name `daylight' and then fall back to something totally idiotic (i'm
quite sure that's what happens here). the d7100 seems to have daylight wb
presets, but with more esoteric names. which one would you prefer to be
used as 5000k reference? daylight fluorescent, white, or 5000k?
/me tries a few things.
j.
On Tue, Dec 17, 2013 at 8:12 AM, Chris Siebenmann <[email protected]>wrote:
> | > It's easiest to explain what I'm seeing with a sample NEF and its
> | > embedded preview:
> | > http://www.cs.toronto.edu/~cks/tmp/darktable/DSC_4429.NEF
> | > http://www.cs.toronto.edu/~cks/tmp/darktable/DSC_4429_preview4.jpg
> |
> | Your second link is broken, looks like it should be:
> |
> | http://www.cs.toronto.edu/~cks/tmp/darktable/DSC_4429-preview4.jpg
>
> Oops, yes. My fault and thanks for letting me know. (I've added a
> symlink so that it works now, or at least so that it should.)
>
> | IIRC, it was stated that the temperature control on the white balance
> | module is for convenience only, and the value is not related to any
> | objective measure... of course, if it's maxing out, that's not very
> | convenient. :)
>
> My view is that getting it into the rigth ballpark is important for
> both adjustability (a 100 kelvin change means more at lower K values)
> and for understanding what's going on and general usability. For
> example, the D7100 '5000K' white balance present currently comes out
> with a DT K value of 8364K and the 'shade' preset to 17199K. And if the
> values are arbitrary and way off, clamping them to 23000K is (as you
> mentioned) not too useful.
>
> (Part of the usability is for adopting processing suggestions written
> for other RAW processors to Darktable. Right now, 'add 200K of white
> balance' is not really useful or easily adoptable directions for at
> least some cameras.)
>
> In fact I would go so far as to say that if Darktable's Kelvin scale of
> colour temperature is so arbitrary and so far off the scale should not
> be called '(kelvin) colour temperature'. Call it 'white balance index'
> and scale it differently using whatever units are convenient.
>
> (Of course I would prefer if DT really had a Kelvin colour temperature
> scale and it worked right. But clearly it doesn't right now, so the
> easiest fix may be some redefinitions. This might also allow for it to
> be in more convenient units for changes.)
>
> - cks
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Darktable-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/darktable-users
>
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Darktable-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/darktable-users
