That's interesting, Matt. So, let's say I want to edit an out-of-camera JPG file in darktable (which can be useful for Fuji shooters!); is it advisable first to convert the JPG to, say, a 32bit TIF before editing it?
mac On Fri, 31 Jan 2020 at 19:09, Matt Maguire <matthew.magu...@gmail.com> wrote: > > The thing is, you have a limited number of bits per pixel, and human > perception of changes in brightness fall off logarithmically as things get > brighter. So, to make sure you get the most “bang for your bits”, you want > smaller quantisation steps for low intensity and bigger quantisation steps at > higher intensities. L*a*b achieves this by using a (non-linear) gamma > encoding. > > In the case of linear RBG, if you use floating point numbers, they consist of > a mantissa and an exponent (like in scientific notation), so as things get > brighter, the quantisation steps naturally get larger due to the fixed > precision of the mantissa. So, using floating point numbers for linear RBG > representations is actually pretty important. > > On Sat, 1 Feb 2020 at 2:03 am, David Vincent-Jones <david...@gmail.com> wrote: >> >> darktable's use of floating point calculation, as I understand it, was >> important for maintaining accuracy through L*a*b processing. Is this >> still valid as the emphasis in processing shifts to RGB? The reason that >> I ask this is to question whether RGB modules still are greatly helped >> by the use of OpenCL. >> >> ____________________________________________________________________________ >> darktable user mailing list >> to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org >> > > ____________________________________________________________________________ > darktable user mailing list to unsubscribe send a mail to > darktable-user+unsubscr...@lists.darktable.org ____________________________________________________________________________ darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
