Hola
When I use Hugin+enblend/enfuse sometimes I get unpleasant colour artifacts in dark areas (see example below). I suspect efuse causes it. My enfuse arguments are --exposure-weight=1 --saturation-weight=0.6
Anyone experiences the same? Ideas to eliminate those?
2 Likes
Find the problem image(s) and mask them out.
I get the same artifacts - blue and red pixels in dark regions.
Enfuse version 4.2.
Got to eliminate them with e.g. --exposure-optimum=0.7 - but the image gets too bright, then.
I don’t have experience using hugin, and it’s been a long time since I used enblend. However, the bright spots of highly saturated color in your image look familiar. They seem to be in the deep shadows of your image, and look exactly like highly amplified shadow noise.
Did the images start out as interpolated raw files? If so, try doing noise reduction such as RT’s impulse noise reduction, and/or using strong values to fix hot pixels.
Now I found this: https://bugs.launchpad.net/enblend/+bug/1576862
Try using this option: --blend-colorspace=identity
In my case the colored pixels have mostly gone, then.
1 Like
it’s a TIFF image after basic RAW development with noise reduction
gonna give it a try
Yes, that helped! Thank you so000 much!!!
@mosaster Glad you found a way 
.
@Elle Could the spots also come from out-of-bounds, out-of-gamut or nan issues?
With me the issue still remains, although not as strong as before. The funny thing is: the artifacts show on my 24000x4000 panorama created with hugin, but when I limit the area to a 3000x4000 region at the critical area, the result is totally fine.
Here is an area from the big panorama. The blue and red dots seem to be at the border to the blacked out areas.
@afre - I was thinking about images I’ve edited in GIMP 2.9, and in GIMP I think (hope!) all the NAN issues have been found and fixed (if you see any, please share!).
Sometimes the brightly colored shadow pixels that I’ve seen in GIMP are, as you suggest, clearly out of gamut because one or more channel(s) is negative and the Luminance blend mode applied over such a pixel produces really odd, bright colors.
I’m pretty sure I’ve seen such bright colors even even when all three channel values are above zero, when appliying a tone-mapped black and white layer over a color layer using Luminance blend. I’d have to check some images to be double-sure.
Wait— aren’t we talking about enfuse? I was suggesting that it is possible for the artifacts to come from something other than shadow noise. I haven’t used enfuse or enblend in ages, so I don’t know the answer.
Such artifacts were common in the past in RawTherapee when using CIECAM02. As I remember it, some were caused by bugs (NaN), and some by the fact the CIECAM02 has a small gamut and needs to handle pixels which go out of gamut in a way that doesn’t lead to such artifacts.
References (there were more):
Random bright pixels appear when using CIECAM02 and a wide gamut color space · Issue #1822 · Beep6581/RawTherapee · GitHub
Dancing pixels · Issue #2218 · Beep6581/RawTherapee · GitHub
@mosaster @Strongheart what you can do as users:
- Make sure you’re using the latest version (4.2).
- If you can reproduce the problem in the latest version, then upload the source files and report the problem upstream to the developers here: Enblend in Launchpad (“Report a bug” link in top-right corner)
Yes, the topic is an image processed with enblend/enfuse. But the pattern of artifacts in the shadows looks just like shadow noise amplified by a Luminance blend of a brighter layer. So that somewhat suggests that whatever the solution to the problem might be, the original source might be noise in the shadows.
But if CIECAM02 alone can produce such artifacts in deep shadows, even if the deep shadows are noise-free, and if the enblend/enfuse processing uses CIECAM02, then I shouldn’t have mentioned the possibility that deep shadow noise might be the problem.
Finding a combination of settings which do not produce the problem is not in your best interest, it is only a workaround. It is in your and everyone else’s best long term interest if you report the bug with sample files to the developers. This is true for any program.
2 Likes
So are you saying that you did not report it yet?
Yes, I have not reported it yet. I would like to test the latest development version before, but had problems compiling it ( or had not spent enough time ).
I don’t follow the logic. You reproduced the bug in 4.2, which is the latest release from 29 March 2016. The linked bug report is for version 4.1.4 from September 2015. It states that in May 2016 someone wrote that this was a duplicate of an issue from April 2011 which was allegedly fixed in February 2012. Clearly not.
The bug seems to be in the CIECAM02 code. Not using the feature does not qualify as a fix, just as not using a leaky boat does not render the leak fixed. So the sooner a bug report with sample files is submitted, the sooner others can reproduce and confirm, and the devs can then hopefully fix it.
1 Like
Well, the linked bug report was issued in 2016-04-29, which was after the release of 4.2.
However, now I have been able to test the development version, too, and the bug is still there.
I have reported bug #1709473.
2 Likes