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... >> 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
