Thanks a lot for your answer!
Le mer. 12 déc. 2018 à 22:24, johannes hanika <hana...@gmail.com> a écrit :
> 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:
>
> No problem for the delay, this is clearly not an urgent matter ;-)
> 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).
>
>
I have seen that only variance measured in the green channel is used, but I
do not think it is an issue. All channels should behave more or less the
same, as long as their values are not amplified.
> > 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.
>
I do not have enough background in probability, so maybe I am wrong.
Yet, I can't get the intuition why with more samples the variance will be
lower:
- with a higher brightness on all samples, I agree the variance will be
lower.
- with simply more samples, my intuition is that the noise characteristic
is unchanged: for instance if we take a picture of a smooth surface to see
only the noise, I don't see why having more samples would change the
histogram that we get.
Maybe my intuition is false?
>
> > 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 noise per color, or at least the multipliers associated, matters
indirectly in the distance metric:
the anscombe transform performed will be different from one channel to
another: the values obtained will not be in the same range. As such, when
we do the squared difference to compare patches, a channel that have a more
spread range will probably lead to bigger difference than a channel that
has a narrower range. Thus, it would have "more weight" in the similarity
measure.
> > 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.
>
The white balance is basically the same as a channel relative exposure: it
just amplifies the values.
As such, if the red channel has a white balance multiplier of 2, and the
image ISO is 6400, it would be like if we have an image with a perfectly
exposed green channel at 6400 ISO and a perfectly exposed red channel at
12800 ISO (if we suppose that the noise is mainly due to photon noise).
That's why I think we should use the white balance multipliers for the
anscombe transform
>
> > 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.
>
In practice it seems that we can get similar results with current
implementation by lowering the force parameter.
You can compare easily with current version of darktable:
- open a noisy image
- activate the denoise profile module
- disable the highlight reconstruction to see the difference (disabling
this module will make the processed_maximum values equal to the
temperature.coeffs values)
Note that if the white balance multipliers are close to one, the difference
may be hard to see.
Here is a picture for testing:
https://drive.google.com/open?id=1SDhvb1mxdNXxYxCByNnVdac_9KTX4DBR
Also, please zoom at 100% zoom level to be able to compare correctly.
>
> > 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 :)
>
Thanks again for your answer! :-)
cheers,
rawfiner
>
> 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
