pixel artefacts in fused image stacks and panoramas

[louan...@me.com]

Hi,

 

I have been using the 2014 release of Hugin for a while, and have noticed some artefacts appearing in shadows of exposure-fused images.  I have searched high and low and have found only one similar post (from 2011), but have not found any fixes for this issue, or any current discussions of this topic.

https://bugs.launchpad.net/enblend/+bug/787387

 

I noticed this first when attempting some pseudo-HDR merges from single RAW files (3 to 5 images with different exposure compensation, converted to 16 bit tiffs in Capture NX). Brightly coloured pixels (mainly shades of green, magenta, cyan and blue, sometimes white) would be lurking in shadowy areas of the stacked or stitched final images. These are generally worse when using "exclude masks", but can also appear in images where no masks were used.

 

These brightly coloured "random" pixels appear in dark areas of the fused image stacks and also stitched panoramas. They have appeared in many different projects.  I have just checked some panoramas made earlier this year, which must have been made with the older (2013?)  Hugin version, and there are no artefacts in those images.

 

You need to be zoomed in 100% plus to see them. These pixels can be selected and replaced (i.e., with black) in an image editing software, but because they are not exactly the same colours it takes a long time to manually select all the erroneous pixels - even with a moderate tolerance threshold set – so not an ideal solution.

 

Just wondering if anyone else has noticed this and is there is any way around this issue?

 

Dougal.

 

Mac OSX 10.9.4

3.1 GHz Intel Core i7

8 GB 1600 MHz DDR3

NVIDIA GeForce GT 750M 1024 MB

 

Hugin 2014.0.0-beta1

[cspiel]

Try the tip of the Development Branch of Enblend/Enfuse

or any revision after d3a7966801dd.

CIECAM blending has been prone to one-pixel artifacts

in the shadows. The cheapo workaround is forcing

blending/fusing within the RGB-cube.

/cls

[louan...@me.com]

Hi Christoph, thanks for the info.

I did a complete clean re-install of Hugin 2014 after I noticed this problem. I used the installer released in October 2014. It appeared to be the same build that I previously had as a beta (2014.0.0), which I thought was a bit odd. 

I am also having trouble verifying the "latest" versions of enblend/enfuse. I just downloaded the so-called latest version from the official web page but they were exec files created in 2009 (enblend-enfuse 4.0-mac). I doubt these are the latest versions...  Wouldn't the versions of enfuse/enblend included in the Hugin 2014 install be the latest ones? I can't see what revision they are, but at least those files were created this year...

I am not a developer (obviously), so this is all a bit new to me. Assuming I did get a suitable revision (e.g. after d3a7966801dd), do I just replace the files in the Macintosh HD ▸ Applications ▸ HUGIN ▸ Hugin ▸ Contents ▸ MacOS folder? Or do I need to do something in the command line?

Thanks for any advice!

Cheers,

Dougal.

[cspiel]

Dougal -

On Wednesday, December 10, 2014 10:58:08 AM UTC+1, louan...@me.com wrote:
> --- snip --

> It appeared to be the same build that I previously had as a beta (2014.0.0),
> which I thought was a bit odd.

        This is a question to ask the guy who produced your installer
package.  I am just an Enblend/Enfuse developer.

> I am also having trouble verifying the "latest" versions of enblend/enfuse.

        The notion is not well defined.  We already have two main
branches of Enblend/Enfuse development: "Stable Branch" and
"Development Branch".  At the package level, i.e. when somebody
bundles Hugin with Enblend/Enfuse we get another bifurcation as "the
latest version" becomes something like "the latest version in the
Enblend/Enfuse Stable Branch that is compatible with the targeted
version of Hugin on the given platform".

To make a long story short, the minimum revision I suggested for
Enblend certainly is not in any bundle yet, for it is close to the tip
of the Development Branch.  It is a massive rewrite of the CIECAM
blending code to catch those falsely colored pixels in deep shadows.

Some possible ways to go from here:

 - Force Enblend to blend inside the RGB-cube.  This works with _any_
   version of Enblend or Enfuse, but may not cure your
   problems.  Moreover, it may introduce other artifacts, but you can
   do this hic et nunc.

 - Ask a MacOS builder (on this list?) to create Enblend and Enfuse
   binaries based on the tip of the Mercurial repo for you.  She/he
   will be able to tell you how to loop-in them on your system.


HTH,
        Chris

[louan...@me.com]

Hi again Chris,

I have just tried another fused image stack, both with the "default" of no specified options for enfuse and another with "--no-ciecam" option... 

The default one rendered a few pixel artefacts in the shadows, as before, but there were NO artefacts in the image made with the "no ciecam" option. This may have solved the problem! The two images were visually the same, so it appears that there are not any new artefacts introduced. I will continue with this option, trying a few other images and also some panoramas. 

I very much appreciate your suggestions an the time you have taken to respond. 

I also hope other users take this on board, that there may be some issues with rendered images on a pixel level using the "out of the box" default parameters. This is probably not much of an issue with most users, but as I am archiving some of these images in a photo library I wanted to make sure the quality is as good as possible. 

Again, many thanks.

Dougal.