sorry i was confused, we normalise to D65 daylight, not D50. so i'm now
using the first preset with `daylight' or similar in the name, not 5000k.
which unfortunately means that 5000k shows up as 5300odd in the gui. not
sure i want to special case my way around that, definitely not before 1.4
though. fix pushed.
cheers,
jo
On Tue, Dec 17, 2013 at 9:02 AM, Chris Siebenmann <[email protected]>wrote:
> I'd say go with the 5000k value(s) in the abscence of better information.
>
> Unfortunately I don't have Nikon's official software (or any commercial
> software) that could be used to double-check the nominal official WB to
> try to match their results. If someone does have Capture NX or Lightroom
> or etc to check I'd be interested in what the results are.
>
> (I tried Nikon's free View NX2 software in a Windows VM but I couldn't
> get it to report the actual white balance colour temperature. It did
> seem to avoid the initial magenta colour bias, though.)
>
> - cks
>
> | hm. using 5000k results in your camera wb as ~13000k, using the first
> | daylight one results in ~9300k. you get to choose, i don't have to work
> | with files from that camera..
> |
> | j.
> |
> |
> | On Tue, Dec 17, 2013 at 8:29 AM, Chris Siebenmann <[email protected]
> >wrote:
> |
> | > Somewhere in the Darktable Redmine system I have a couple of
> | > contributed white balance coefficients for a range of D7100 white
> | > balances (both the presets and a range of absolute K values). I think
> | > that 5000K should be used as the 5000K normalization point.
> | >
> | > (If I remember the D7100 manual's discussion of this correctly, also
> | > reported in the Redmine system, the plain 'daylight' preset is close
> | > to but not quite on 5000K. So Darktable might as well use the one that
> | > Nikon claims is exactly 5000K.)
> | >
> | > - cks
> | >
> | > | 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
