Something fuzzy from the back of my head: I read in some paper about denoising that treating channels not independent of each other, but a as a vector, should improve the local stability of the denoising. When it comes to denoising colors, that would mean treating a,b or cbcr as a two dimensional vector. It’s interesting that in your case, switching to RGB gave you better results. Did you treat all channels as one vector and denoised that, or each channel independently?
(of course treating channels independently is easier to implement I guess, you just need to denoise a b&w image per channel)
Yeah, this does sound promising. Using some information from the luma channel, such as edges, to put hard stops on chroma noise reduction to prevent color bleed does seem like the right direction.
Personally, when I denoise, I always do it before demosaicing, on the assumption that noise come from sensels (sensor elements) and that’s the time to remove it, before demosaicing spreads the noise to other pixels.
If demosaicing is done before denoising, then noise that was isolated to one sensel becomes spread to a number of pixels, and to all channels of each of those pixels. So it may make sense to treat two or three channels of each pixel as a vector, and denoise that.
A couple of points relating to the OP:
I can’t see any reduction in intensity of the colours, either in your screenshots or the resized 600px versions.
Using Gimp eyedropper on the 600px versions, I can’t find any general difference.
Noise is random, by definition, and any group of pixels might happen to have noise that shifts colours in the same direction. This is a variation of the random walk (Random walk - Wikipedia) process. So any noisy group of pixels might be lighter, or more saturated, or redder, than the non-noisy pixels.
There are two effects:
(a) We interpret noise as detail (humans are good at inventing pattern from noise), so removing noise will remove apparent detail.
(b) No algorithm can guarantee to remove noise without also removing valid detail.
This can be about personal preferences. I generally prefer somewhat noisy images to denoised images.
1 Like
Well, I can see it! And the point is that noisy regions are desaturated, not randomly more saturated and or sometimes lighter/darker/value-shifted. Sounds a bit nitpicky, but it relates to your second effect: the detail which is removed is specifically saturation. The algorithm used seems to desaturate noisy saturated patches. Whether or not this is real…it is at least perceived as such.
To find out I propose an image pair from a tripod. One low iso, one high iso with and without applied NR. After that define 3pxby3px patches in both pics with mean and sd values for Hue Saturation and Value. Or simpler take the difference of both pics’ ab/uv/cbcr planes. If the residual has a consistent negative value where it was saturated before…that should tell more than an eyedropper. Would that setup suffice? Did I miss something?
The comments are a bit long. 
What I would say is that when you are removing noise there will always be a softening effect because you are essentially smoothing the image. This will reduce features and flatten contrast and hues locally and globally. The goal is to find ways to recover from this. Of course, finding a suitable algorithm and optimal parameters would help. The key is to be careful not to remove too much signal while removing noise. If you nuke the image, you won’t have anything left to recover.
PS Upload your image. I am sure plenty of people can provide you with a *.pp3 that will perfectly address the issue. 
1 Like
I had some nr brick issues a while ago. See this thread
1 Like
Hi, sorry for not responding, I hope tommorow I will have the time to react for all great response, especially I would like to try some provided hints,
here is my original raw photo, sorry for not uploading it the first post - generally I have no problem uploading the files,
regards!
DSC09955.ARW (20.2 MB)
Ah, so by “intensity” perhaps @nullnull meant “saturation”? I can’t see it (dodgy eyes or screen or whatever) but I agree it is there.
f:\web\im>%IMG7%magick e04c1c4c7b9d934f5a9f68516abe48a6c6df1384.jpeg
-crop 37x18+38+78 +repage -colorspace HCL -channel 1 -separate -format %[fx:mean] info:
0.0970853
f:\web\im>%IMG7%magick 3904708ea9fe41d2b6712dc5ed20b0631c8b0fcc.jpeg
-crop 37x18+38+78 +repage -colorspace HCL -channel 1 -separate -format %[fx:mean] info:
0.0752635The denoising has reduced saturation, the chroma channel of HCL. Well, that’s not surprising. Consider a photo of a neutral gray card, so the chroma is zero. In any pixel, the chroma cannot be decreased. Noise will either increase it, or leave it unchanged. So any noise will increase the average chroma.
Your photo isn’t of a neutral gray card but, like any normal photo, the chroma is low: about 0.1 on a scale of 0.0 to 1.0. So adding noise will increase chroma, and denoising will lower chroma.
EDIT: My misattribution of a quote. Sorry.
I am using one of GMIC’s inbuilt filters as a base, so I am not entirely sure what is going on inside. However, it is a patch-based noise reduction, so I assume that it is using a full RGB vector to compare the difference between patches. In fact, I use an RGB guide image that I desaturate somewhat to improve chroma noise reduction, so I guess that confirms my assumption.
I’m definitely not denoising the channels independently.
One downside to this approach is that it does not remove as much chroma noise as other approaches.
1 Like
I never talked about intensity, that was @nullnull . Some mixup there.
Every actual photo has noise. Every actual color photo thus has chroma-noise (greycard chroma noise is not zero). Adding noise will leave the mean of a group of pixels unchanged. Any objections against this reasoning?
The decrease in saturation is a factor 0,0752635/0,0970853=0,77. It’s fair to call this an artifact. And yes artifacts will happen, during NR, no question.
Thank you for the answer! I guess if it’s patch based it should be the full RGB vector, it would make less sense to do a channelwise patch-aggregation as this has the highest computational cost.
Have you tried different guide images? I mean different methods for generating the guide?
Cheers!
@PhotoPhysicsGuy and @nullnull: Sorry for my misattribution above, now corrected.
I agree with your reasoning. Adding noise to any channel will leave the mean of that channel unchanged, more or less. (But almost certainly not exactly.)
In my fairly limited experience of photographic noise, it isn’t an addition to a chroma (or saturation) channel. Rather, it is an addition to each of the camera RGB channels. If the chroma was low, this noise increases chroma. If chroma was high, this noise decreases it.
Late to the thread, but this quote resonates with something I do: most of my final images are downsized. To that end, I generally don’t denoise until I’ve had a chance to view the image at its final resolution, as the reduction interpolation really does mitigate a lot of noise expressed in the higher resolution. And, if I do decide to insert a denoise step after that, it is mostly less than if i’d have done it straightaway.
One thing I haven’t played with much is the introduction of a gaussian blur just prior to resize. That is supposed to tame the resizing artifacts from noise, but it might not mitigate the color changes being discussed.
FFT… (food for thought)
You can probably take a look at
– CImg/plugins/nlmeans.h at master · GreycLab/CImg · GitHub
– CImg/plugins/chlpca.h at master · GreycLab/CImg · GitHub
Yes, the guide image in my filter is user definable, so I have tried many things.
Blurring the guide image can be useful for noisy images, and I included a control for a very light blurring in the filter. Blurring the guide does not degrade the result as much as you could expect.
Another approach is applying a different method of noise reduction to the guide (you could use the same kind of NR if you want). This improves finding similar patches. Using frequency domain noise reduction on the guide can be quite good because it can recover patterns that are swamped by noise much more easily than patch-based methods.
However, I have found the best use of frequency domain NR in conjunction with patch-based, is to do a slight over-smoothing with the patch based and then use frequency domain NR on the difference to recover residual patterns.
Oh! Almost forgot. You can also draw on the guide image to emphasise edges etc. that you know are there but are overwhelmed in noise.
If that is your experience, then are there colorspaces which show less desaturation artifacting than this example case?
Oh gosh! So the nlmeans has it (I can read commented code, yay!) and the chlpca probably too, but my reading skills of C (I am assuming this is C) are not developed enough. 
That is a really sexy trick! And you do that normalized to local lightness if I remember correctly?!
Alot of food for thought, indeed!
I normalise the noise levels in the residual locally before applying the frequency domain NR. Then I undo the normalisation to get back to ‘normal’.
You might be interested in this paper which uses a combination of patch-based and frequency domain NR:
Data Adaptive Dual Domain Denoising: a Method to Boost State of the Art Denoising Algorithms
1 Like
Not as far as I know. I suppose the amount of desaturation will depend on both the cause of the noise, and the denoising method. But I suspect that denoising of ordinary photos (which have low saturation) generally results in saturation decrease.
When a photo has high saturation, I get virtually no change in saturation. See examples at Camera noise.
As I mentioned, I generally denoise the R,G0,G1,B channels independently, before demosaicing. With DSC09955.ARW, going through the process but with no denoising, we get:
I have cropped to some bricks near top-left. For this, the C channel of HCL has a mean of 0.148742. The Cz channel of JzCzhz has mean 0.00341112.
With my dnsePsh2Mn denoising, we get:
The C channel of HCL has a mean of 0.111013. The Cz channel of JzCzhz has mean 0.00283577. So chroma has decreased by denoising. We can always boost chroma if we want:
%IMG7%magick ^
c_bdp_den.png ^
-colorspace HCL ^
-channel 1 -evaluate Multiply %%[fx:0.148742/0.111013] +channel ^
-colorspace sRGB ^
c_bdp_den2.png
EDIT: Bother, the images aren’t showing. They are at:
Non denoised:
http://snibgo.com/imforums/c_bay_deg
Denoised:
http://snibgo.com/imforums/c_bdp_den
Denoised, with adjusted chroma:
http://snibgo.com/imforums/c_bdp_den2
… but put “.png” at the end of each.
EDIT2: Uploaded images with drag-drop.
EDIT3: Now the original images show. I’ve been notified: “system 1 hour — downloaded local copies of images”. Hooray. Perhaps it was a sidekiq problem, as mentioned on [Friendly reminder] Limit JPEGs to maybe full HD resolution - #40 by Thomas_Do , and now fixed.
I dunno. Nothing in my pixls.us profile looks like a problem. I did my usual practice: upload images to snibgo.com/imforums, and paste the urls here between [ img ] and [ /img ] tags. After a few seconds, the forum software usually copies the images from snibgo.com, but not this time.
When I paste the URLs with [ img ] tags, the forum software doesn’t show that text, but a “image unknown” symbol.
Creating a local HTML page with <img src=“http to snibgo.com”/ > works fine. I can’t find a control panel setting in my web hoster that might create problems.
It’s probably a bug somewhere. Possibly in my brain.