RT has rendered images with salt noise for a while, feature or bug?

[Beep6581]

Originally reported on Google Code with ID 1034

This is going to be the most unclear bug report ever, sorry.

Over the past couple of months, starting in late july or something I've noted that
my RT output contains salt noise (bright individual pixels), which usually appear when
doing deconvolution och USM sharpening. I often do deconvolution sharpening and now
nearly always turn on "impulse noise reduction" in combination to remove the salt noise.

However, it is a bit unclear to me if what I see actually is noise, clipping pixels
or something, or if it is extra detail that's being extracted. I've always built from
source and thought this salt thing was a temporary problem that would go away, but
now it has been there for a few months and it is still there.

Here is an example of a detail (showing rock) from a raw file that I developed in June
using some devel version of RT3, and the same file developed in RT4:

http://torger.dyndns.org/rt-grain.png

due to vibration issues the raw file is relatively unsharp, and deconvolution sharpening
were used in both cases.

As you can see there's lots of bright pixels in the RT4 render, which is not in the
older RT3. Why is that? Am I using poor settings in sharpening, is it supposed to look
that way, or is it a bug?

Reported by torger@ludd.ltu.se on 2011-10-07 09:59:24

[Beep6581]

Oh, forgot to add, I think the grain issue was introduced in RT3 before the stable release
so I think the current official stable RT3 release has the same issue, haven't used
that for a while though, I like to run bleeding edge :-)

Reported by torger@ludd.ltu.se on 2011-10-07 10:01:50

[Beep6581]

Looking around some it does seem like there's some default setting that I've missed,
"contrast by detail levels" with finest set to +3 per default, which in this particular
example contributed to almost all salt noise. However, I've seen other combinations
causing same type of effect. It seems to happen quite easily when playing around with
detail tools.

Reported by torger@ludd.ltu.se on 2011-10-07 10:16:22

[Beep6581]

Ok, first of all: please test it with the latest RT4 version. That's very important,
so we are not hunting bugs long solved already. Please state the RT4 version number
you are using.

If it's still there in the latest version, please try to reduce it to one tool. So
start of with everything switched off and 0, then enabled or change the settings, so
we can track it down to the tool (or demosaic algo) that causes the problem. Sharpening
is often not the cause, but just amplifies a problem that introduced by other tools.

Reported by oduis@hotmail.com on 2011-10-07 10:35:52

[Beep6581]

ok, I'll do a more detailed investigation after work.

The thing is that I have experienced this grain over a few months and so ubiquitous
that it felt as it would be an "RT look" that you nearly always get when using RT.
I'm a bit surprised that it haven't been discussed before (as far as I know), so I
was suspecting that the answer might be "it is supposed to look like that".

I shall investigate more...

Reported by torger@ludd.ltu.se on 2011-10-07 11:36:42

[Beep6581]

As Oduis said, start with the neutral profile using the newest RT version and work from
there. One thing that causes similar ugly dots is enabling the "sharpen only edges"
option (if I recall correctly - I'd have to check when I get home, as I haven't used
that option in ages precisely because of that problem, which I already reported long
ago).

Reported by entertheyoni on 2011-10-07 12:05:37

• Labels added: Component-Quality

[Beep6581]

Ok, I just compiled directly from latest source, 4.0.3.15, the result is the same.

It seems to be that RL Deconvolution is the tool that pulls out this grain, but it
must be combined with Contrast by detail levels +3 on finest (for example) to be as
visible as in the example.

I've done tests with some other pictures, and the default RL deconvolution setting
Radius 0.75, Amount 75, Damping 20, Iterations 30 together with Contrast by detail
levels +3 on Finest (the rest 1) Threshold 0.20 really brings out this grain.

The deconvolution is what makes it appear, and contrast shows it. Using unsharp mask
default settings (0.50, 250, 512) instead of deconvolution does not show much grain
despite +3 finest on contrast by detail levels.

Reported by torger@ludd.ltu.se on 2011-10-07 12:13:32

[Beep6581]

Just tested "sharpen only edges", and that does not bring out grain.

However, when doing unsharp mask and playing around only with the radius value, increasing
it from the default 0.5 to 0.6, there does appear some grain, increasing it to 0.7
some more appear. Increasing the "Amount" of course enhances this grain.

This shows an example with unsharp mask radius 0.70, amount 512, threshold 512:

http://torger.dyndns.org/grain2.png

(the grain is enhanced by contrast by detail levels, but is clearly visible without
too.)

The sharpening shows halos due to oversharpening, which is normal, but the grain seems
to me like a bug rather than normal oversharpening effect. I would suspect that it
is the same type of problem as seen in the RL deconvolution tool.

Reported by torger@ludd.ltu.se on 2011-10-07 12:22:55

[Beep6581]

I've also noted, at least with deconvolution, that when this happens some pixels turn
dark instead of bright. So I've speculated that there may be some sort of clipping
problem. 

It does not seem like the grain appear on random places, but that there is some normal
local variation in the unsharpened picture. In other words that a liiittle bit brighter
pixel in the original picture becomes veeeery bright. Perhaps it is a normal result
of the sharpening operation, but it does seem strange and I haven't seen the same effect
in other software with sharpening functions.

Reported by torger@ludd.ltu.se on 2011-10-07 12:48:07

[Beep6581]

Do you have a RAW+PP3 to demonstrate the effect. Are you using Canon maybe?

Reported by oduis@hotmail.com on 2011-10-07 15:50:53

[Beep6581]

Yes, I'm using Canon 7D. Here's RAW and PP3.

http://torger.dyndns.org/IMG_5922.CR2
http://torger.dyndns.org/IMG_5922.CR2.pp3

It is not the best picture I've shot, but I hope that's ok ;-)

Reported by torger@ludd.ltu.se on 2011-10-07 16:06:40

[Beep6581]

Thanks, I guess thats normal.
You cranked up sharpening a whole lot, and sharpened it afterwards with contrast-by-detail
a lot, and switched off halo control also. Using real world levels and halo control
it looks normal to me.

Reported by oduis@hotmail.com on 2011-10-07 16:32:27

[Beep6581]

Looks normal to me too, so closing the issue.

Reported by entertheyoni on 2011-10-07 18:04:13

• Status changed: Invalid

[Beep6581]

The default profile seems to have +3 contrast finest detail, probably a bit too extreme.

Reported by torger@ludd.ltu.se on 2011-10-07 21:03:24

[Beep6581]

The default profile sharpening settings do not produce these artifacts. I found that
it is not a good idea to combine USM with contrast by detail levels, try to avoid it
as this is leading to exactly these artifacts.

Reported by michaelezra000 on 2011-10-07 21:29:46

[Beep6581]

+3 on the finest scale of CBDL will hugely amplify demosaic artifacts, I am surprised
that is the choice for a default profile.  If one wants to provide microcontrast, would
it not be better to use one of Jacques' tools (I heard they are good for not amplifying
noise/artifacts, but have not tested this myself), or a lower value of the finest scale
of CBDL together with some amount of the second level of CBDL.

Reported by ejm.60657 on 2011-10-07 21:33:34

[Beep6581]

For choosing the sharpening settings for the default profile I did comparisons of various
options considering quality of sharpening and performance. Performance-wise CDBL was
best when a single band!=1. At the same time, it provided a more detailed rendering
of fine details, along with a higher value of the threshold for resilience to noise.
In some cases combination of microcontrast and CBDL is beneficial, but I chose not
to enable both in the default profile for performance consideration.

Reported by michaelezra000 on 2011-10-08 00:38:45

[Beep6581]

Another consideration towards enabling CBDL in default profile is because it is more
capable tool in itself, allowing wider range of detail enhancement, so in most cases
it seemed to me that user's input would be variation in the other bands for feature
enhancements suitable to the subject matter portrayed. 

Overall, the default profile was created for more generic purposes. My personal workflow,
for example, does not include use of any kind of sharpening tools in the raw conversion
process, instead I choose to use more detailed demosaicing and less intrusive noise
reduction. My study showed that this allows better enlargement of the master file with
lesser amount of artifacts. In some cases I make exceptions as sharpening a significantly
larger file takes much more resources. But on most part creative sharpening (manual
blending with masks)is done in the middle of the retouching (e.g. *after* blemishes
are removed) and then at the end of the workflow - when sharpening image for the printing.

Reported by michaelezra000 on 2011-10-08 00:58:13

[Beep6581]

Per default USM/deconvolution is not enabled, but CBDL is. If you enable USM with default
settings on top of it this grain artifact does get visible in some images, typically
those that are sharp and with small details (leaves on semi-distant trees etc). It
disappears when CBDL is disabled.

It seems to me to be more natural the other way around, to have USM enabled per default
but not CBDL, or something other that is more similar to what typical cameras do to
their JPEGs. I think it was that way before CBDL was introduced?

The USM/deconvolution toolbox is at the top and CBDL is at the bottom of the tab. If
CBDL should be enabled per default and USM disabled this seems to be an odd order.

(I like the CBDL tool as an alternative/completent to local contrast, I have used it
in many images, I am really surprised that I have managed to miss that it is enabled
per default...)

Reported by torger@ludd.ltu.se on 2011-10-08 06:59:15