Hi,
that's a really good question! I cannot understand that also, as the
comments are not very useful unfortunately....
Is it in some way related to issue
https://redmine.darktable.org/issues/10704
best,
Bjoern
Am Do., 6. Dez. 2018 um 16:05 Uhr schrieb rawfiner <rawfi...@gmail.com>:
> Hi,
>
> Looking at the code of denoise profile, I noticed a few things that seems
> strange to me concerning the anscombe transform.
>
> For wavelet codes, there is a 2x multiplier on B and R channels, while it
> is not the case for the anscombe transform of non local means:
> const float wb[3] = { // twice as many samples in green channel:
> 2.0f * piece->pipe->dsc.processed_maximum[0] *
> d->strength * (in_scale * in_scale), piece->pipe->dsc.processed_maximum[1]
> * d->strength * (in_scale * in_scale), 2.0f *
> piece->pipe->dsc.processed_maximum[2] * d->strength * (in_scale * in_scale)
>
> Why is there this multiplier? I understand from the comment that it is
> related to the fact that we have 2 times more green pixels than R or B
> pixels on a bayer sensor (note that this is not perfectly valid on xtrans
> sensor). Yet, I do not see the link between this, and the distribution of
> the poisson noise, and thus of the anscombe transform to be done.
> In addition, I do not understand why this multiplier is only here in the
> case of the wavelets process, and not here in the case of the nlmeans
> process.
>
> The second thing I noticed, is that the "processed_maximum" are all equal
> if highlight reconstruction is activated. Basically, they are equal to the
> maximum multiplier of the white balance. Thus, the anscombe transform is
> the same for R and B for instance, even though one may be much more
> "amplified" than the other.
> If highlight reconstruction is turned off, the processed_maximum values
> are equal to the white balance multipliers, so we don't get this effect.
> On images were some white balance multipliers are very different, turning
> off the highlight reconstruction results in a big change in the denoising
> (more or less equivalent to a big reduction of the force factor).
> I guess we should use piece->pipe->dsc.temperature.coeffs instead of
> piece->pipe->dsc.processed_maximum in this code.
>
> Doing this correction will allow to "copy-paste" more reliably the
> settings from one image to another, even across images that have very
> different white balance.
> Otherwise, a setting which works well on a picture with a white balance of
> (1,1,1) for instance may not work well on a picture with a white balance of
> (1, 1, 2) for instance.
> Though, correcting this will break backward compatibility.
>
> What do you think about it?
> Thanks! :-)
> rawfiner
>
>
> ___________________________________________________________________________
> darktable developer mailing list to unsubscribe send a mail to
> darktable-dev+unsubscr...@lists.darktable.org
>
___________________________________________________________________________
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
