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
Well, first of all, my apologizes for picking up old thread, but I’m right on subject and feel kind of guilty for not posting a bug report.
However, there is a good workaround for those color artifacts that I did not find elsewhere.
In the latest Enfuse 4.2 manual I have found extra parameters for color model:
(sorry preformatted text did not work here, pasting as image instead)
My parameters of choice were --blend-colorspace=cielab. No frenzy colors were found after using this parameter. Moreover, I extensively use Lab within Darktable for panorama postprocessing so this kinda aligns it. I also added the same parameter to Hugin engine and Holger’s HDR script into darktable. Feel free to ask for instructions where to paste them.
Combined with other parameters set properly it gives very good results 
Happy fusing everyone!
2 Likes
I guess Enfuse fails to identify colorspace properly and enforces RGB, which is not a good choice for luminosity blending. Please consider my last comment, what do you think about it?
Thinking back, @patdavid recommended using l-star (=cielab) in one of his tutorials. However, as @Morgan_Hardwood noted, that would not negate the alleged problem with ciecam.
Yep! Correct me if I’m wrong, EnfuseGUI is an old GUI that does not work on contemporary distros.