On Tue, Jul 2, 2013 at 6:01 PM, Pascal de Bruijn <[email protected]>wrote:
> On Tue, Jul 2, 2013 at 5:07 PM, johannes hanika <[email protected]> wrote:
> >
> > On Tue, Jul 2, 2013 at 4:37 PM, Emmanuel Lacour <[email protected]>
> wrote:
> >>
> >> On Sun, Jun 30, 2013 at 06:54:02PM +0200, Emmanuel Lacour wrote:
> >> > Hi,
> >> >
> >> > in recent git master, temperature seems to have lost (without effect)
> 1K
> >> > or 2K from the standard values. For example, now daylight is 3349K
> when
> >> > to my knowledge it should be near 5000K.
> >> >
> >> > What hapened, is this the wanted value?
>
> Please do supply a RAW sample (preferably via a Redmine issue), so we
> can actually investigate... Without samples there's little we can
> do...
>
i second that. sounds like your camera has some special needs wrt white
balance. maybe we fail to read anything useful from that file and fall back
to idiotic default multipliers that we dream up as last resort. oh, also
which version of dt are you using?
j.
>
> >> maybe this commit:
> >>
> >> commit 0ef76b617f7552bdca5ea3d7291d1fe7f3d6ffc5
> >> Author: Pascal de Bruijn <[email protected]>
> >> Date: Tue May 21 18:20:15 2013 +0200
> >>
> >> temperature: kelvin is high, introduce kludge factor
> >> (cherry picked from commit
> >> 7a194eb4777caa8f8dd5f9944924911cbd248a0b)
> >>
> >> but why?
>
> Because the values were off by a large scale and many many many
> cameras. I tested like twenty models from different vendors.
>
> It was common to see values > 10000K before that commit...
>
> The root cause probably stems from the fact that we are normalizing
> against daylight wb (D55???) now, while the original ufraw code did
> some tricks with the D65 matrix... I put that factor into there to
> kludge away that difference, until we could put some effort into a
> more structural solution.
>
> >> Also, I recently worked on photos taken indoor (theatre) and saw that
> >> the default "Camera WB" in darkroom is far away (many times too warm)
> >> from the camera auto WB one (which I can see on the embedded jpg)?
>
> Are we talking about displayed values now? Or how the image looks?
>
> Because nothing changes at all how the image looks, ZIP NADA NOTHING...
>
> Only the RGB multiplier -> Kelvins calculated changed. And it's the
> RGB multiplier that are stored and/or retrieved from the RAW. So the
> Kelvin slider is just a convenience, nothing more.
>
> > that's probably the embedded jpg vs processed raw story here. embedded
> jpg
> > thumbs aren't color managed etc. at some point i'll be tired of
> explaining
> > it and just delete the code that loads those broken jpg thumbnails in the
> > first place :)
>
> Yeah, that story is getting old, but loading RAW straight away is just
> too slow...
>
> Regards,
> Pascal de Bruijn
>
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Darktable-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/darktable-users
