Sun Oct 27 01:32:15 BST 2019
quality. On the other side, LibRaw is focused on RAW/metadata
extraction and pre-processing (before demosaic stage), there is no
(near) plans to change postprocessing stage.
> Thanks for the reply, Alex. =A0So, as I understand your comment, Highligh=
t Recovery shifts the entire histogram to the left, allowing extra capture =
data in the highlights to roll in.
Not so easy. Different color channels on (every) digikam have
different sensitivity. So, when green channel is already clipped,
there is some details in red/blue ones (for daylight and neutral
highlights, just an example). So highlight recovery tries to recover
clipped green channel data via correlation with other channels.
So, we need to rescale data (for example from 0...16383 to 0..8191 to
get 1 extra stop), then try to reconstruct green pixels above 8191.
> * What happens to the shadow data that was on the left? =A0Does it drop o=
ff and get clipped to 0?
Shadows are compressed
> * Why not fix the highlights and shift the histogram back to where it was=
Imagine some clipped and unclipped highlights. E.g. clipped cloud part
in range 255-255 (8bit values) and unclipped in range, say, 240-254.
If you recover clipped part to, say, 245-255, you need to shift
unclipped part to something like 230-245. If not, you'll get incorrect
> * In 16 bit mode, why do we need to shift and darken at all? =A0The image=
is 12 bits, so all operations can certainly be performed in a 16 bit space=
before any processing, RAW data converted to working RGB and scaled to
mailto:lexa at lexa.ru
More information about the Digikam-users