On Sat, 1 Feb 2020 at 13:39, Patrick Shanahan wrote:
> ps: your chosen email client does not wrap lines so what you see is what
> you get.
> --
> (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri
This issue got me puzzled. Out of long habit (especially with linux mailing
On Fri, 31 Jan 2020 at 21:07, Patrick Shanahan wrote:
> ...
> the computations withing dt are floating point. number base of the image
> file is not a concern. two different points. and any conversion may
> introduce differences to original image, ie: the converted image in not an
> original,
* Archie Macintosh [01-31-20 15:37]:
> 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
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 wrote:
>
> The thing is, you hav
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 hi
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
