Enblend

Enfuse: artifacts - false colored pixels in dark regions

Bug #1709473 reported by strongheart on 2017-08-08

This bug affects 3 people

Affects		Status	Importance	Assigned to	Milestone
	Enblend	New	Undecided	Unassigned

Bug Description

enfuse sometimes produces false colored pixels around dark regions using the default options.

When using the option "--blend-colorspace=identity" the artefacts don't show (at least with the attached example images).

Tested with version 4.2 and 4.3-e93b798a0c5f. The artefacts show with both versions, although there are differences.

Attached are sample images and the result images after using the included script. There is also a self-compiled binary of the enfuse version 4.3-e93b798a0c5f and a text file ("Info.txt") containing info about versions, operating system and hardware.

The result images
"default.tif" and "default_dev.tif"
are the images made with default options,
the images
"identity.tif" and "identity_dev.tif"
are made with the option "--blend-colorspace=identity".

The images
"default_dev.tif"and "identity_dev.tif" are made with the development version 4.3-e93b798a0c5f

Tags:

Revision history for this message

strongheart (strongheart) wrote on 2017-08-08:

Example input- and output images , script Edit (11.5 MiB, application/zip)

Revision history for this message

zarl (carl-einem) wrote on 2018-04-04:

I think I'm also affected by this bug:

When stitching 16 bit (per channel) TIFFs the final panorama sometimes shows colour artefacts in dark areas.

Blender options in Hugin contain no additional command line options.
Tiffs from NEF using Adobe's Raw Converter (shipped with Photoshop CS6).

According to the documentation --blend-colorspace uses cieluv as a default. When switching to --blend-colorspace=ciecam (or cielab) the artefacts don't appear.

Hugin 2018.0.0 built by Niklas Mischkulnig (for Mac OS X)
enblend 4.2.1-f0304648cc0f

Revision history for this message

Christoph Spiel (cspiel) wrote on 2018-04-12:

Carl,

        The weird, bright pixels in dark areas are artifacts of the
LCMS color-conversions in so called open color spaces. Experience has
shown that it is hard to catch all of them. However, Enblend/Enfuse
have a lot of (undocumented) command-line parameters that control the
hedging of those outliers. Please take a look at source file
"fixmath.h" in the "src" directory and check out for example `class
OptimizableLuminanceSpace'. You can control _everything_ coded as
`parameter::as_*("foo-bar", ...)' from the command line, for example
the code reads
        parameter::as_boolean("mark-freaky-color-conversions", false)
so, you could say
        --parameter=mark-freaky-color-conversions=true
at the command line.

For a better understanding of what is going on in the color-space
conversion steps you will probably want to compile your Enblend and
Enfuse with `LOG_COLORSPACE_CONVERSION' or even
`LOG_COLORSPACE_CONVERSION_DETAIL'. The make(1) variable
`EXTRACPPFLAGS' was made for endeavors like this:
EXTRACPPFLAGS='-DLOG_COLORSPACE_CONVERSION -DLOG_COLORSPACE_CONVERSION_DETAIL'
Otherwise it will be enfusing-by-night.

On the technical side: all operations in "fixmath.h" only consider a
single, isolated pixel. We could think of a median filter or a
Kuwahara filter that operates on a N-times-N region of pixels at a
later processing step that mops up the outliers without impacting the
"good" pixels too much. Please send me your patches, if this idea
works out!

/cls

Revision history for this message

Gustavo L (gustavo-lapido) wrote on 2018-05-19:

I'm also affected by this issue.
If I can help by providing some data just let me know.
In my case, the colored dots show up on very bright areas of the sky.

Revision history for this message

Gustavo L (gustavo-lapido) wrote on 2018-05-19:

I forgot to mention, the issue I'm referring to is on enfuse