On 02/07/2013 22:04, johannes hanika wrote: > > > comparisons to the jpg are really very useless.
yes, but it doesn't mean DT shouldn't provide a default WB as close as possible to the real one (not the jpg one). This may end up having an "auto WB" in darkroom that may even give better result than the camera auto WB, based on some magic image processing I'm far from imagine ;) thought, there is no need to discuss this so much, I don't think this is a priority in futur DT devs. > about the kelvin numbers: these are dreamed up by taking what the camera > or our presets claim to be daylight balance, identifying it as about > 5000 or 5500K and inferring a value for your current rgb coefficients > from that (as pascal said, very unscientific that part). it does seem a > little odd that the daylight preset ends up at 3400K, that's true. as > mentioned somewhere in this thread, this is a mere UI thing though, the > number doesn't matter at all for image processing, that's done using the > rgb coefficients. > > reverting pascal's commit will result in 5507K for daylight balance > instead, so i guess you have a valid point there. > that the main point I sent in my original email. Happy to see we agree :) I'm going to create a redmine bug to track it. ------------------------------------------------------------------------------ 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
