Karim, Terry, Indeed clear explanation, Karim. Thank you. May I additionally to Terry's question (32-bit tiff export) ask whether exporting in a - wider than AdobeRGB - colorspace would be more beneficial too ? (Of course if that other photo editing program supports the wider colorspace and can export into AdobeRGB or sRGB.)
Marc. > Op 4 sep. 2020 om 08:08 heeft Terry Pinfold <tpinf...@gmail.com> het volgende > geschreven: > > Thanks Karim for explaining floating point in an easy and useful manner. Can > I ask, when you export an image from DT for further editing in programs like > GIMP would you suggest 32 bit FP or is there little benefit? > >> On Thu, 3 Sep 2020 at 07:04, Top Rock Photography >> <ka...@toprockphotography.com> wrote: >> Not really a bug, per se, (and not in Dt) >> >> The application which is being used to do tho merge is using integer >> arithmetic. (Dt uses floating point). When an int goes beyond its range, it >> gets clipped to the maximum. Any correction then gets evenly reduced. So for >> an integer between 0 and 255, a value of 255 gets increased by 30%, it >> remains at 255. If reduced by nineteen percent, it becomes 206. The clipped >> areas in your “bright” image got reduced to an even grey. >> >> With fp values, nothing is really “out of range” (technically possible, but >> nevermind that), meaning that if the value is to fall somewhere between 0 >> and 1, but it gets computed to 1.3 (or even 17.9), the variable can still >> hold the number. If these numbers are then later reduced accordingly, and, >> if reduced by nineteen percent, is still 1.053, or still at saturation (>=1). >> >> So, with the two images, the application does some maths on a certain value >> near zero, and a certain value at 255, and it results in another value, >> (somewhere in the vicinity of > 127). But with the tree images, at some >> point, the high value got clipped, and then reduced, resulting in the even >> grey circles. One can say, “but I used a 16-bit format.” Sure, but if it was >> a 16-bit integer format, one still has the same problem, except now, the >> values are 0-65535, and 65535 times 30% is still 65535, reduced by 19 % is >> still 53083. >> >> With a 16-bit fp, or a 32-bit fp, the answer is still 1.053; the only >> difference is to what decimal place accuracy. >> >> Perhaps, if the images were sent to the algorithm in a different order, it >> would not have resulted in the clipping. Pipeline order is important, >> especially with integer mathematics. >> >> Talk to the developers of the program doing the merge, to consider using a >> fp pixel pipeline in their next major upgrade. (That is no easy feat. It may >> involve a total rewrite, and a few years. Just ask the developers of The >> GIMP). >> >> Sincerely, >> >> Karim Hosein >> Top Rock Photography >> 754.999.1652 >> >> >> >>> On Tue, 1 Sep 2020 at 15:49, Michael <bmi...@gmail.com> wrote: >>> I merged three files of a room and got a round discoloration. I then >>> merged The lighter and darkest image and the pic was normal. If it is >>> a bug please fix it. If it isn't a bug nevermind:) >>> -- >>> :-)~MIKE~(-: >>> images >>> https://drive.google.com/drive/u/2/folders/0B2xvsVTZy4y1ODR6dTk5UldpR3c >> >> >> ____________________________________________________________________________ >> darktable user mailing list to unsubscribe send a mail to >> darktable-user+unsubscr...@lists.darktable.org > > > -- > Dr Terry Pinfold > Cytometry & Histology Lab Manager > Lecturer in Flow Cytometry > University of Tasmania > 17 Liverpool St, Hobart, 7000 > Ph 6226 4846 or 0408 699053 > > > ____________________________________________________________________________ > 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
