Noise Reduction: Auto Chroma

[Beep6581]

Originally reported on Google Code with ID 2495

Chroma noise reduction is likely the most widely used. It would be great to have the
auto mode for this slider. Would be helpful if RT could evaluate the amount of chroma
noise present in a small dark patch of the image and auto-set the slider value to reduce
the noise to specific objective. As a reference, for well exposed images, modern sensors
and lower ISO the value of 15 (the current default) is suitable.

Reported by michaelezra000 on 2014-09-06 12:39:42

[Beep6581]

I'll look :)

Reported by jdesmis on 2014-09-07 11:34:31

[Beep6581]

I knew it:)!

Reported by michaelezra000 on 2014-09-07 13:49:06

[Beep6581]

Here a new patch

It automatically calculates the values of chroma denoise(master and red/green or blue/yellow)..It
takes into account all noise (visible in grey and dull and less visible in saturated
colors)

It takes  also into account quality "standard" / "high"

I added an indicator that shows the level of noise "medium" and the "medium + sigma"
(high)

There are differences between Lab and RGB, the RGB values are less accurate because
the RGB mode does not completely separates luminance and chrominance.

I have had a curve denoise=f(Chroma), because visible noise can be corrected differentially
==> more for grey and dull and allow more details in saturated colors! This curve acts
(multiply) on Chroma master and chroma red-green / blue-yellow

Of course there is increased memory consumption

Some GUI improvments must be done  after !!

No pipette (as for luminance curve) ! (Perhaps Hombre) 

:)

Reported by jdesmis on 2014-09-16 16:19:33

---

• Attachment: issue2478-1.patch

[Beep6581]

Hi Jacques! I can't wait to try this patch. I will get back to my workstation tomorrow
evening and test it the first thing! Thank you for looking into this feature:)

Reported by michaelezra000 on 2014-09-17 03:58:41

[Beep6581]

I have add colored bar for "chroma curve"

Reported by jdesmis on 2014-09-17 06:04:15

---

• Attachment: issue2478-2.patch

[Beep6581]

I tested patch 2 on a few images I previously applied chroma NR to, and each time the
auto value was very close to what I chose manually! Good work!

It seems the auto value is only applied when "Chrominance - Master" is not equal to
0.

Now that we have two curves, one "auto" button (maybe two "auto" buttons in the future?
:) ), a quality setting, a median filter and a gamma slider in the NR tool, maybe we
should re-think the widget layout of the whole tool. For example now that we have the
luminance curve, I never use the luminance slider. Perhaps the same will happen with
the chrominance curve and slider. With the curves, I also don't think we need the gamma
slider anymore.
Here's a first idea:

> Noise Reduction
  [x] Enabled
  Method [combobox]
  Quality [combobox]
   --  Luminance (frame)  --
  | Luminance type [combobox for curve or slider]
  | [curve or slider here]
   -------------------------
   -- Chrominance (frame) --
  | [ ] Auto (when enabled, the widgets below are disabled gray)
  | Chrominance type [combobox for curve or slider]
  | [curve or slider here]
  | Red-Green slider
  | Blue-Yellow slider
   -----------------------
   --  Median (frame)   --
  | Method [combobox]
  | Window size [combobox]
  | Iterations slider
   -----------------------

Reported by entertheyoni on 2014-09-17 20:59:46

[Beep6581]

NR is really getting complex... :) I didn't even realize there is now a curve also for
chrominance!

I'd suggest to remove the quality combobox. Reason: If one's computer is capable enough,
I think one will always want to use the high quality mode, so it's nothing users will
change more than once. Instead I suggest to move all "performance vs. quality" options
to the respective tab in the options dialogue (where there is e.g.  number of NR threads;
CIECAM precision setting should also be moved there IMO). Then users can set up the
options they need to get RT to perform adequately on their machine once and then forget
about it... :)

Another question: The several chroma NR comparison examples on the Rawpedia page all
show better results with Lab mode (vs. RGB), is this generally the case or are there
use cases where usually RGB is better?

Reported by stefan.ittner on 2014-09-18 08:14:54

[Beep6581]

I've found it depends on taste and on the colors and white balance.
Agreed about Preferences.

Reported by entertheyoni on 2014-09-18 08:21:25

[Beep6581]

Hi Jacques, I have a question, and this applies to  most of the new automated tools.

1. During editing in RT, the auto calculation of specific parameters is based on the
preview area displayed at >=100% zoom. If image is scrolled and image content in the
preview area is changing, the auto calculation results are also varied. 

2. I suppose this varies the amount of chroma NR applied to the preview.

3. For  the new auto-chroma option, when image is zoomed out to <100% zoom, the values
of the auto-calculated parameters don't change. And considering #1 & 2, it is unclear
to the user what would the auto-chroma NR when it gets applied to the full image. 

4. Partly, this is OK, as NR preview is not available for <100% zoom. But it would
be interesting to know the final outcome, as #2 above may not let user to preview the
chroma NR that would actually be applied when the entire image is processed.

5. Would it be possible to analyze and cache image noise characteristics early in the
pipeline and use that information for auto-calculation of chroma NR, instead of doing
it dynamically per previewed portion of the image? I guess that would require quite
a bit of rewiring, but this is how the auto exposure works, for example.

If I recall correctly, this pattern also applies to CIECAM automated tools. There was
a recent issue opened on discrepancy of preview vs output, and I suspect it may be
for the same reason.

4. At this point

Reported by michaelezra000 on 2014-09-18 11:26:35

[Beep6581]

Hello Michael, Stefan, DrSlony
Thank you for testing :)

@michael
1.2 when you change preview area (and refresh) level noise, and auto settings depends
of the area. Noise is important in saturated color. But noise is visible in grey and
dull colors.

3. if zoom < 100%, in all case (excepted output TIF/JPEG), denoise is not call.

4.5 all is possible...but in this case, we must call wavelet...the same function...No
gain...and necessary of zoom 100%. Theoretically possible, but all on a "total picture",
with the same process as now. So time consuming and memory. A priori, little or no
interest, otherwise the complexity

@Stefan DrSlony
#7 and #8 : I'm not quite agree, for now I'll keep the combo, even remove at a later
stage

#7 : yes Lab is always superior to RGB, although sometimes for luminance, RGB gives
the impression of being better. This is due to the lower channel separation luminance
and chrominance in RGB (with interaction between chroma and luma in RGB).

I'll try to make other improvements, such as a more attractive GUI (not my thing!),
but also try to develop auto-luminance, etc.

I'll be away - without internet connections - for 10 days from tomorrow.

thank you again.

:)

Reported by jdesmis on 2014-09-18 12:04:03

[Beep6581]

I would like to re-word Michael's question, as I feel it wasn't answered:
Is the automatic value that this tool comes up with based on an analysis of the visible
preview area or the whole image including parts not currently visible?

Reported by entertheyoni on 2014-09-18 18:49:32

[Beep6581]

DrSlony

It is based on the visible preview area !

Now next intervention within 10 days

Reported by jdesmis on 2014-09-19 05:18:21

[Beep6581]

I rewrite what I just said in issue2493 for CIECAM

"It is two things totaly differents...

For CIECAM, the real good choice, is what it is installed now...Use full screen, it
will be to make you happy, but contrary to CIECAM

For Denoise, would be ideal to have both. A full screen for an overall assessment of
the noise, the other preview to assess specific areas (face, details, etc.). Maximum
chroma noise does not follow the logic of the luminance, the most noisy areas are often
the most saturated.

But to implement full-screen CIECAM is easy, no cost in time and memory.
To implement full screen for denoise, is very complex (I'm not sure it is possible
without rewrite all code ??), it cost memory and much time (about the same  as for
Denoise all image ==> TIF, JPG)"

Reported by jdesmis on 2014-09-19 06:13:10

[Beep6581]

Since noise amplitude varies for different regions of the image, I think it is bad to
have Auto Chroma base its values on what you currently happen to be looking at. As
I understand it, it should check the whole image before it comes up with a reliable
value.

"To implement full screen for denoise" Do you mean full image?

Reported by entertheyoni on 2014-09-19 08:51:16

[Beep6581]

My bad english!
You must read "full image".
But I think, "local" is better than "global". Often chroma noise is not
visible (or less) , it is very different from luma noise.

From my smartphone.
 Le 19 sept. 2014 10:51, <rawtherapee@googlecode.com> a écrit :

Reported by jdesmis on 2014-09-19 09:02:52

[Beep6581]

This explains the oddity i noticed but hadn't figured out yet.
What happens if while activating auto chroma noise reduction I happen to zoom into
an area with, for example, only bright un-saturated tones? The preview looks nice,
but when i save the whole image it looks bad, because the rest of the image was not
taken into account.

I tested now in cactuses_hut.pef and confirm that the behaviour is unpredictable, varies
too much:
chroma master 10.29: http://i.imgur.com/nqG0nmH.png
pan to a different area, 42.61: http://i.imgur.com/Llokk8Z.png
Open a detail window or two, then whichever you clicked last (main preview, or any
of the detail windows) take precedence.

I believe using only the area visible in the preview is wrong. It does not help the
photographer, it makes the tool unpredictable. The whole image, or the visible cropped
part if cropping is enabled, should be used.

Of course I'm open to being proved wrong and shown how this is more useful than otherwise
:)

Reported by entertheyoni on 2014-09-19 11:53:12

[Beep6581]

Jacques, about #5 in comment 9 - could the noise evaluation step be limited to avoid
scanning the entire image - E.g. it can look at image corners & center, sample *small*
square fragments and evaluate noise based on them only. This would be much faster then
scanning the entire image.

Reported by michaelezra000 on 2014-09-19 12:00:52

[Beep6581]

Another two suggestions:
- Disabling Auto Chroma should not re-process the image since nothing changes.
- If the Auto Chroma values are based on the visible preview and will change after
every time I pan the preview, then instead of a checkbox maybe a button would be better.
After a few hours of use I came to the conclusion that when enabling Noise Reduction
with Auto Chroma I should pan to an area most representative of the whole image which
contains both details and areas without detail (e.g. if it is a portrait photo, then
a piece of the in-focus face and a piece of bokeh background should be visible in the
preview at the same time for a good auto-chroma value). Then, I disable the Auto Chroma
checkbox so this good value does not get changed if I pan to some other area. So instead
of a checkbox, a single-click button would be better. Though I still think it would
be best if the whole crop was used when calculating the Auto Chroma value, not just
the part visible in the preview.

Reported by entertheyoni on 2014-09-19 12:56:20

[Beep6581]

Screenshot for comment #18:
This is a good area to turn Auto Chroma on, and then off so the values do not change:
http://i.imgur.com/AuRN1xp.jpg

If I forget to turn it off and then I pan here next, then the values are not good:
http://i.imgur.com/maJus5t.png

Reported by entertheyoni on 2014-09-19 12:58:55

[Beep6581]

That is an interesting approach for use case when one is working on a single image.
An now I seem to understand Jacques' intent:)!

Another use case is auto NR for batch of images, to let RT do auto NR - this is when
check box is useful, as long as RT will re-estimate NR parameters during development
when check box is on.

Reported by michaelezra000 on 2014-09-19 13:09:41

[Beep6581]

I was wrong in #18 when I wrote that turning Auto Chroma off makes no difference. It
makes no change to the numbers shown, but the noise in the preview changes! Bug?
Auto chroma on, look at the noise in the image especially in the shadows: 
Auto chroma off, the numbers did not change but the preview changed, there is more
noise!

Another bug:
Open image A, Zoom in, turn Auto Chroma on (reset the Chrominance - Master slider if
its 0 so that the auto value is updated), Auto Chroma off. e.g. Ch Master is 9.80,
Ch Red/Green is 6.9 and Ch Blue/Yellow is 0. Open image B. Go back to image A. Now
all Chroma sliders are at 0.

More reason to not use the currently visible preview: every time i show and hide a
panel, the NR values change.

Reported by entertheyoni on 2014-09-19 13:35:25

[Beep6581]

Oops, forgot to paste the link:
http://filebin.net/y7pfiz2xco
Noise levels everywhere change, most visible in the shadow area between his neck and
the hood.

Reported by entertheyoni on 2014-09-19 13:40:00

[Beep6581]

I am in the train for north of France.
I'll find a solution,  I think will satisfied everybody.
Jacques
Le 19 sept. 2014 15:40, <rawtherapee@googlecode.com> a écrit :

Reported by jdesmis on 2014-09-19 15:34:58

[Beep6581]

I just returned home after more than 10 days of absence, without internet connection.

I rewrote the code for "denoise"
1) by separating the evaluation function of the noise from the rest of denoise
2) by various optimization code, cleaning, number of tiles, etc.

Now you have multiple mode "chroma".

a) Manual - each parameter affects the "entire image" 

b) Automatic global - acts on the "entire image", using 9 areas to calculate parameters

c) Auto multi zones - acts on "each tiles" used by Denoise code . For an image of D3x
this corresponds to 35 zones, and for a D800 to 63 zones. Each zone has its own calculates
values.
This mode only works in "Output / batch...", no preview

d) Preview - acts on the "entire image" using settings from the chosen area preview.

This local adjustment, for example a face, can be completed by using the curve C=f(C)
increasing the action on the zones where chroma is higher

You can choose from, in "Preference" (Performance-Quality), the size of areas for "automatic"
and "auto multi zones": mini=100x100 pixels (default), small=250x250, medium=half tile,
maxi=tile.
Of course, the greater the size of the areas, plus processing time increases. There
are advantages and disadvantages to each mode, depending on the homogeneity of the
image.

You can also choose (Preferences) the number of Tiles: Standard (default 1024x1024)
or high (768x768) (about 80% more) - usefull for image with low definition. Same remarks
as above.

The system needs to be calibrated with different users.
You can used 4 variables in "option":
* NRauto=8 - between 5 to 20...The lower the value, the mean action will be great (equivalent
slider "Chroma master")
* NRautomax=20 - between 5 to 50 - The lower the value, the action for red/green or
blue/yellow, will be great (equivalent slider "Chroma red-green and blue-yellow")
* NRhigh=0.4 - between 0.1 to 0.9 - this coefficient determines the effect of Quality
mode "high"...The lower the value, effect on "high" will be small.
* NRlevel=0 - between 0 to 2 - this value acts on wavelet level (increase level with
NRlevel) in Quality mode "high" - the higher the value, more wavelet increase effect
(and also time: about 40% or 80%). Usefull for reduce "blotches".

Remarks:
* I have enabled "Lab" by default instead of RGB: in all cases it is superior. You
can think RGB is best but it is always a mistake. In RGB mode there is interaction
between L and C.
* Probably, GUI must be enhanced...(I take into account Michael remarks), this is not
my specialty, but ..!!
* I think that globaly (quality) "Standard mode" is at least as good as "High"...:
Denoise is a compromise between reducing noise and preserve detail
* There probably has bugs, changes are important. Be tolerant !
* It may, perhaps, still further improvements ..!!!...

:)

Reported by jdesmis on 2014-10-01 11:50:45

---

• Attachment: issue2478-3.patch

[Beep6581]

I'm testing. Patch applied and compiled fine. There is a speedup possible for 'RGB_denoise_info'
function. Shall I post a patch with the speedup or wait, Jacques?

Ingo

Reported by heckflosse@i-weyrich.de on 2014-10-01 19:28:14

• Status changed: PatchSubmitted

[Beep6581]

Ingo
Thank you. I think, it is better to wait a little :)

Reported by jdesmis on 2014-10-02 05:23:02

[Beep6581]

About # 7 and # 8, I do not see any downside to put in "Preferences" some features,
which affect the "quality" of the noise reduction.

You can put "Quality: Standard / High", but also "Method: Lab / RGB".
I can also add "NRlevel" -see #24 (wavelet level)

But I have a doubt because Hombre said he did not put in "Options / Preference" variables
that affect the rendering of the image

Ingo, could you send me (by mail), your code for 'RGB_denoise_info'. Thank you very
much

:)

Reported by jdesmis on 2014-10-02 06:11:42

[Beep6581]

Jacques, mail sent :-)

Reported by heckflosse@i-weyrich.de on 2014-10-02 13:06:04

[Beep6581]

The same, with Ingo optimization, cleaning code, some enhancements...

No changes to algorithms 

:)

Reported by jdesmis on 2014-10-03 10:37:31

---

• _Attachment: issue2495_4.patch_

[Beep6581]

Here some enhancements !

And a raw file, for testing :)

http://filebin.net/na1t3vz2mk.

Reported by jdesmis on 2014-10-04 15:28:36

---

• Attachment: issue2478-5.patch

[Beep6581]

Jacques, there is another BIG speedup possible for 'RGB_denoise_info'. I'm at 300 ms
now (was 1300 ms before). Still testing.

Reported by heckflosse@i-weyrich.de on 2014-10-04 18:00:32

[Beep6581]

Jacques, to get the speedup:

FTblockDN.cc

line 2557: // static MyMutex FftwMutex;
line 2558: // MyMutex::MyLock lock(FftwMutex);

line 2726: // float * Lblox;
line 2727: // float * fLblox;

line 2759: // Lblox  = (float*) fftwf_malloc(max_numblox_W*TS*TS*sizeof(float));
line 2760: // fLblox = (float*) fftwf_malloc(max_numblox_W*TS*TS*sizeof(float));

line 3166: // fftwf_free ( Lblox);
line 3137: // fftwf_free ( fLblox);

Explanation: The lock was only needed because fftw is not thread safe. But in 'RGB_denoise_info'
fftw is not used.

Ingo

Reported by heckflosse@i-weyrich.de on 2014-10-04 20:47:13

[Beep6581]

I compared a) no chroma reduction to b) 'Auto multi zones' using my usual D800 NEF.

Here the result: http://www.i-weyrich.de/rt/auto_chroma_wrong.png

left is a) and right is b)

That's clearly wrong. Jacques, I think I've sent you the test file D800FAR2I3200.NEF
some time ago. In case you don't have it anymore, I can send it to you again.

Ingo

Reported by heckflosse@i-weyrich.de on 2014-10-04 22:16:31

[Beep6581]

Ingo

I test #32...yes it speedup, but it leads to significant abnormalities.

Try "automatic global"...without modification. In all cases with the same image, and
the same settings, in preview, if you move the preview, sliders chroma master / red-green
/ blue-yellow has alway the same values

With modification, sliders changes

No I have not the file D800FAR2I3200.NEF, can you send me.

Thank you :)

Reported by jdesmis on 2014-10-05 05:24:36

[Beep6581]

Jacques, I found the reason for abnormalities. I'll send you a mail later

Reported by heckflosse@i-weyrich.de on 2014-10-05 11:14:56

[Beep6581]

I would put online a new version, with many improvements, as soon as Ingo has solved
the problem of processing speed in "auto" mode (calculated parameters)
:)

Reported by jdesmis on 2014-10-05 14:55:03

[Beep6581]

I solved it and I'm preparing a patch. Shall I post the patch or send it to you, Jacques?

Reported by heckflosse@i-weyrich.de on 2014-10-05 15:00:26

[Beep6581]

Ingo

Please send me your work :)

Reported by jdesmis on 2014-10-05 15:18:25

[Beep6581]

Jacques, mail sent :-)

Reported by heckflosse@i-weyrich.de on 2014-10-05 16:08:51

[Beep6581]

Ingo

Thank you very much :)

Reported by jdesmis on 2014-10-05 16:09:49

[Beep6581]

Ingo

I have quicly tested! All seems to work fine...

Tomorrow I'll send a new patch, with this modification (now noise evaluation is realy
fast !), and others 

Thank you again :)

Jacques

Reported by jdesmis on 2014-10-05 16:56:02

[Beep6581]

de rien :-)

Reported by heckflosse@i-weyrich.de on 2014-10-05 17:05:39

[Beep6581]

Here the patch, I hope no error :)

Thank you again Ingo !

Comments follow in the day ... !! my bad English !! I hope it will be understandable

Reported by jdesmis on 2014-10-06 05:19:38

---

• Attachment: issue2495-6.patch

[Beep6581]

Testing patch 6 using cactuses_hut and neutral:
1- All the inner frames lack padding http://i.imgur.com/K2mdBYs.png See the CIECAM02
and Color Management inner frames for reference. By the way, I just noticed that the
Color Management "Free gamma" frame lacks padding too.
2- The bombobox "Luminance type" lacks its own padding too.
3- The "Chroma Residual Noise (Preview) Mean=x High=y" label is too long, people with
large font sizes and translators (especially Italian) will have a problem.
4- I would change "Wavelet + Luminance" and "Wavelet Chrominance" to "Luminance" and
"Chrominance". Users don't need to see that there, it can be mentioned in RawPedia.
5- "Automatic global" seems broken: http://i.imgur.com/XxKKAAz.jpg Compare to "Manual":
http://i.imgur.com/S8IMtdc.jpg "Preview" seems good http://i.imgur.com/KnzAc4A.jpg
6- Automatic chroma methods should still show us the computed numbers in the sliders.
I believe this worked correctly in patch 2. In patch 6 "Automatic global" and "Preview"
come up with some values but I can't see them http://i.imgur.com/amG3ygZ.png I have
to change it back to Manual to see them http://i.imgur.com/D1Jk3m1.png The sliders
do change, its just the numbers next to the sliders that I can't see.
7- "Preview" can be very off too: Compare http://i.imgur.com/14C5H3D.png to http://i.imgur.com/KdjSrC1.png

Reported by entertheyoni on 2014-10-06 08:16:12

[Beep6581]

re# 44 6.) Just a hint for Jacques. In the patch I sent you "Automatic global" and "Preview"
show different values, as it should be.

Reported by heckflosse@i-weyrich.de on 2014-10-06 10:00:33

[Beep6581]

A link to D3x_6400.NEF
http://filebin.net/822cnsheeg

I begin the explanation of the new features and functionality provided by this patch
(although I have already given previously)

News:
Of course they concern Denoise
1) wavelet (I think we should call 'wavelet' in RT, to differentiate it from the median
...it costs nothing and allows a minimum of understanding....otherwise it must also
delete "median")
A) I introduced three automatic features for chroma noise:
a) automatic global: 
** the calculated setting is for the entire image. Nine areas spread over the overall
image, are used to calculate an average setting
** you can choose, size of area in "Preferences / Performance-Quality"
** this feature is operating in "batch / output" mode and also preview (> = 100%)
** you can choose the level of denoise (low / standard) in  "Preferences / Performance-Quality"
** you can increase action in function of chroma, with the curve f(C), often for high
chroma

b) Auto multi zones:
** the calculate settings are for each "Tiles" used by "denoise algo". To reduce time
and memory, image is cut in Tile (size around 1000*1000),this leads to the usual images
a number of Tiles between 30 and 80.
** you can choose, size of area in "Preferences / Performance-Quality" (same as "automatic
global") 
** this feature is only operating in "batch / output" mode - no preview
** you can choose the level of denoise (low / standard) in  "Preferences / Performance-Quality"
** you can increase action in function of chroma, with the curve f(C), often for high
chroma

c)Preview
** the calculated setting is for the entire image. Preview are is used to calculate
an average setting
** this feature is only operating in preview (> = 100%)
** you can choose the level of denoise (low / standard) in  "Preferences / Performance-Quality"
** you can increase action in function of chroma, with the curve f(C), often for high
chroma

B) Curve chroma :
** this curve, multiply action of the 3 sliders chroma (master / red-green / blue-yellow)
** for example, in manual or preview mode, you can choose a setting for a face, and
increase denoise for the rest of the image that is generally more color (so often with
more noise)

C) Information : "Chroma Residual Noise (preview) - Mean=xx High=yy"
** only for manual, automatic global, preview
** give an approximation of residual noise in preview
** 300 and above - very noisy
** 100 to 300 - noisy
** 30 to 100 - low noisy
** under 30 - very low noisy 

It is clear that each method results in different results, because the image, without
exception, is heterogeneous, with more noisy than other areas.

D) How it works ?
The algorithm "denoise" uses MAD (median absolute deviation) for each level of wavelet
and each "direction". 
I pulled out of the algorithm these parameters to make them available and interpretable.
Of course you need to calibrate the system (see manual option).

2) Median :
a) method :
** I have add 2 methods : a) "chroma 'ab' only" - In Lab mode, acts only on chroma;
b)"ponderate L + ab" - as noise is more difficult to treat in Chroma,a type of median
largest is used for chroma, such Chroma 7x7, and luma 3x3
** these 2 methods allows to complete wavelet
b)type :
** I have add, 9x9 principaly for chroma noise

Settings :
Disposing of used 4 settings accessible via "Preferences" and 3 accessible manually
"option"
Preferences / Performance-Quality :
a) Denoise auto : size of zones 
** Mini 100x100, Small 250x250, Medium Tile/2 (about 450x450 according to number of
tiles), Maxi Tile (about 900x900 according to number of tiles) - Default = medium
** it is not easy to choose the right size :
***the more cells are smaller, the processing time is reduced, but the greater the
risk of falling on a very noisy area (lots of chroma) is great. 
***In this case, the setting "very noisy" will be given to the entire Tile
*** conversely choose "Tile" increases the processing time and blurs the very noisy
areas

b) Denoise auto - level denoising
** you can choose between low (default), and standard
** in low mode (according to manual provisory setting), level denoising is minimal,
and probably (matter of taste) must be increase by chroma curve, or median chroma

c) Number of tiles :
** you can choose between Standard and High
** Standard = 1024*1024 with Overlap 128
** High = 768*768 with Overlap 96
** High may be useful for images with a small number of pixels to increase the number
of tiles
** I am not sure (to verify), that "high" is always a good choice (it reduced time
treatment). Tested on several images, I did not see any differences or banding

d) Increase wavelet level in quality 'high':
** you can choose between : 
*** "No", in "Quality high" and "Quality Standard" same values of wavelet levels
*** "One level", in "Quality high" one level more for wavelet levels: increase time
treatement (about 30%), but reduce artifacts, blotches,...
*** "Two levels", in "Quality high" two levels more for wavelet levels: increase time
treatement(about 70%), but more reduce artifacts, blotches,...

"Manual option"
** after period testing (1 mounth..) we will fixed this value and suppress these settings
**NRauto=9  : between 5 and 20...the less, increase effect of wavelet "mean"(chroma
master)
**NRautomax=40 : between 10 to 100...the less, increase effect of wavelet - take into
account max noise in zone (chroma red-green and blue-yellow)
**NRhigh=0.4 - For quality high - between 0.1 to 0.9 - reduction apply to wavelet settings
to take into account 2 passes : fist pass with algorithm "bi shrink", second pass with
algorithm "normal"

Other remarks :
1) Activation of the wavelet :
** Luminance : if slider > 0.4 or if curve > epsilon
** chroma : if slider > 0.4 

2) usage of wavelet and median:
** wavelet is not a "miracle" and has advantages and disadvantages

** the wavelet uses a lot of memory and time, even at very low settings, its effectiveness
at low setting values is often poor, for example to reduce motonnement in blues skies
for non-noisy images 
*** in this case (eg: amsterdam_moving_boat_1.pef) must prefer the median "luminance
only" 3x3 and put settings wavelet to luma=0.5  (need to activate wavelet to use correct
data format)

** for high values of "denoise chroma", the wavelet can "bleed", for example a gray
zone between two color zones very chroma... the gray area will gradually become colorful
*** in this case, I think it is better to use low values for wavelet and complete with
median 7x7 or 9x9

** for high values of "denoise chroma", the wavelet can significantly decrease the
saturation and make the sad picture, it is not the case with median...

** but median has also disadvantages, it is slow, and often less effective, and sometimes
give artifacts,...

3) Lab or RGB
For wavelet and median, Lab is quasi always superior to RGB. RGB gives the impression
of being better in some cases, but in fact it blurs the image because the separation
of luminance and chrominance is not good. 
** When are believed to influence the brightness, it also affects the chrominance.

4) where chroma noise is maximum :
** it depends on each image and shooting conditions. A long exposure will not have
the same effect as a short exposure. The nature of the light is also important. But
overall chrominance noise will be greater in areas of high color (red / yellow by example)
** select "preview" and zoom 400% or more and select different areas of the image and
look the sliders...the results are surprising
** eg try with D3x_6400.NEF picture. I think the most noisy zone is in the area of
colored pencils at the left

DrSlony, with my configuration (Windows64) all works fine, with "Cactus", I see always
numbers...
For the rest, GUI !!

:)

Reported by jdesmis on 2014-10-06 10:59:13

[Beep6581]

DrSlony

I solved #44 1) and 2)
Have you a proposition for 3)

For the rest see my comment...and I have not Linux...

Reported by jdesmis on 2014-10-06 11:34:03

[Beep6581]

Here a change with
#44 1) 2)
A short label for 3)

A little modification to pass parameters to GUI...I doubt it's effective, but I work
"blind" with Linux !

:)

Reported by jdesmis on 2014-10-06 12:45:02

---

• Attachment: issue2495-7.patch

[Beep6581]

The same with display anomalies (GUI) removed  "Residual denoise (sometimes bad display)",
and some improvements to the GUI for auto-sliders. 

DrSlony, I hope this solves the problem  :)

Reported by jdesmis on 2014-10-07 06:46:33

---

• _Attachment: issue2495_8.patch_

[Beep6581]

A new patch that try to take into account :
1) TIF and JPG : 
this files are not raw !! and MAD (mediam absolute deviation) is different (histogram)...I
have put an empirical coefficient that try to compensate gamma, and others parameters
(

2) working profil: 
This may seem obvious, but sRGB is smaller than Prophoto. When the noise is important,
choose sRGB will "cut" the noise of high chroma. But also the colors rendered by Prophoto
are removed. Again, I put an empirical correction factor

:)

Reported by jdesmis on 2014-10-07 12:12:21

---

• Attachment: issue2495-9.patch