heya,
sorry for the late answer, usual madness. but i think you're raising a
few important points here. let me try to answer some of it:
On Fri, Dec 7, 2018 at 4:04 AM rawfiner <rawfi...@gmail.com> wrote:
> 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)
yes, that is the bayer pattern. the code is from pre-xtrans days.
also, we're only ever using the variance measured in the green channel
when profiling noise. that's also a lazy coder thing, because we don't
measure noise on the raw, but on the input to the denoising module
(i.e. it holds the statistics that are relevant to the denoising at
this step).
> 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.
what do you mean? the noise model shows the standard deviation per
brightness input level. if you have 1/4th of the samples variance goes
up by a factor of two. not sure the formulas there are correct though.
> 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.
now that sounds like a bug to me.. on the other hand it may be the
product of careful engineering which i also very carefully forgot:
nlmeans just computes a full tile distances and then splats the thing
over your center pixel no matter what the colour channel. quite
possibly the noise per colour doesn't matter to the distance metric at
all.
> 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.
right. that sounds strange but may actually be like this for the same
reason: the noise statistics are only used for the green channel, and
the others just follow? it's possible that this is an oversight that
gives suboptimal results, but it may be possible that the two others
(RB) don't really affect the result at all, i'd need to carefully
check the code.
> 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.
that should be simple enough to check and see if it improves things at times.
> 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.
let's see the changes and decide then how to deal with that.
> What do you think about it?
> Thanks! :-)
thanks for looking into this at this detail :)
cheers,
jo
> 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
