small artifacts in fused 16bit TIFFs

[KFJ]

When blending a set of 16bit TIFF images, I noticed artifacts in the output. Depending on the enfuse setting used, these occur in different places and look different. When I used the default setting, the artifacts looked like groups of coloured dots (see enfuse_problem_fused_default.tif) and when I used exposure only, they came as single pixels (see enfuse_problem_fused_only_exposure.tif), also see the respective jpg screenshots where the artifacts are enlarged. The images were created by hugin's nona, I tried several sizes and also the original unmodified images, the effects were the same. The 16bit TIFFs were created by digiKam's batch RAW import from Canon CR2, using conversion to 16bit and storage as TIFF as the only active processing steps. I converted the images to JPG with gimp, and when I fused the JPGs, there was no problem. I also opened the images with fotoxx and saved them in a different file but the same format, in which case the problem persisted. I suspect the problem may stem from the 16bit format. Here's my session which produced the flawed results:

>enfuse enfuse_problem_[0-2].tif -o enfuse_problem_fused_default.tif
enfuse: info: loading next image: enfuse_problem_0.tif 1/1
enfuse: info: loading next image: enfuse_problem_1.tif 1/1
enfuse: info: loading next image: enfuse_problem_2.tif 1/1
>enfuse enfuse_problem_[0-2].tif --saturation-weight=0 -o enfuse_problem_fused_only_exposure.tif
enfuse: info: loading next image: enfuse_problem_0.tif 1/1
enfuse: info: loading next image: enfuse_problem_1.tif 1/1
enfuse: info: loading next image: enfuse_problem_2.tif 1/1

>enfuse --version
enfuse 4.1-101796703d73

I use a Kubuntu 11.4 system on an intel processor. Find enclosed a tar file of the files in this session.

Kay

[KFJ (kfj)]

I doublechecked with 8 bit TIFFs of the same images and I'm also getting artifacts there, though they seem to be less.

Kay

[Yuv (yuv)]

Confirmed with enfuse 4.1-2f3c9caab556. Kubuntu 11.04

I don't have a tarball release at hand, can anybody test with a tarball release to determine if this is only in the development version or also in the release?

And test this on other systems than 64bit Ubuntu Natty?

[David Benes (dbenesj)]

I can blend images from the archive without any artifacts. I used commands above.
enfuse 4.0-753b534c819d, RHEL6 64bit

[KFJ (kfj)]

I downloaded the tarball from SF:

enblend-enfuse-4.0.tar.gz

Was that the tar ball release you meant, Yuv?
I compiled it here, (Kubuntu 11.4, intel 32 bit).
The resulting enfuse

enfuse 4.0-753b534c819d

does not produce the artifacts.

Kay

[Yuv (yuv)]

On May 31, 2011 05:14:52 AM KFJ wrote:
> Was that the tar ball release you meant, Yuv?
Yes, thank you for testing, Kay.

> I compiled it here, (Kubuntu 11.4, intel 32 bit).
> The resulting enfuse
>
> enfuse 4.0-753b534c819d
>
> does not produce the artifacts.

Good news. So at least a large chunk of the user base seem not to be
affected. Will still need confirmation for 64 bit.

A critical bug affecting an unreleased future version is much less of a
problem than a critical bug affecting the current release.

The advice / workaround for affected users will be to stick with the 4.0
release for the time being.

Yuv

[Yuv (yuv)]

On May 31, 2011 03:53:30 AM dbenesj wrote:
> I can blend images from the archive without any artifacts. I used commands
> above. enfuse 4.0-753b534c819d, RHEL6 64bit

thank you for testing and confirming that it is not a 64 bit issue.

Yuv

[Christoph Spiel (cspiel)]

Try the current development head, i.e. rev add97764deef or later.

[KFJ (kfj)]

Am 25.02.2012 10:20, schrieb Christoph Spiel:
> Try the current development head, i.e. rev add97764deef or later.
>
Thank you very much. I've just pulled bleeding edge from the repo,
compiled and built, and the problem is gone. Seems like you've fixed it!

Kay

[KFJ (kfj)]

Prompted by your comment, I just built bleeding edge enfuse 4.1-e378b04ea3b7, and the problem is gone here (Kubuntu 11.4 on intel 32bit) now. Thanks!

Kay

[KFJ (kfj)]

... oops

just noticed the bug is still there. Plus more bugs. The newly built enblend totally botched up a stitch I had it attempt this morning, and the artifacts in dark areas are still there, see attached image still-there.jpg

[KFJ (kfj)]

... and the overall result is wrong: the sky is black and there's a big hole in the floor, see attached image overview.jpg

Kay

[KFJ (kfj)]

another two oopses- the black sky and floor were my fault, and of course this time the artifacts showed up after running enblend, not enfuse. But the artifacts are definitely gone now that I reverted to the old version of enblend. Maybe the bug was fixed only in enfuse and not enblend? When I ran the test images I sent when I reported the bug with the newly-built enfuse it was fine, but this stitch didn't use enfuse at all, just enblend - the bug looks precisely the same, though. Sorry for the noise and confusion...

Kay

[Christoph Spiel (cspiel)]

WRT"artifacts in dark areas are still there": We need a minimal
set of (preferably small) images that clearly show the problem. Please
attach them to _this_ bug report.

The faulty CIECAM blending, which was the cause for some weird
colored pixels is fixed in _both_ applications: Enblend and Enfuse.
(Technically, they both rely on the same pyramid interface and this
was the part that was on the blink.)

WRT "black sky and floor": Enblend 4.1-devel has e.g. a new primary seam
finder, which was introduced with GSoC 2011. Moreover, several defaults
have been changed. Please consult the "NEWS" file to get an impression
what exactly is different. Maybe (and hopefully) your problems are rooted
there. Otherwise you should open a new bug report so that we can track
different issues in separate places. THX.

[KFJ (kfj)]

I tried to reduce the images to recreate the bug, but I only get the bug when I process my (large) images all together, and the size is forbidding at 400M altogether. When I work on smaller sections, the bug doesn't occur. This makes me suspect it could have to do with the coarse/fine mask, because when I use the smaller images it tells me they are too small and it switches to fine masks. I hope this may turn out a helpful hint. If I come across the bug on more manageable image sets, I'll post here.

Kay

[Christoph Spiel (cspiel)]

Without small images to reproduce the problem, this is fly-by-night-in-deep-fog hacking.

Let's see whether we can narrow down the issue.

1. Please make sure you are using the _non_ image-cache version of Enblend.
  We do not want to trip over an image-cache bug here. Though the image-cache
  bugs always have shown up as line shaped never as isolated dots.

2. Compare the results when you blend with "--ciecam" and "--no-ciecam". The
  no-CIECAM02 mode, i.e. plain RGB-blending never had any problems with weirdly
  colored pixels, whereas the CIECAM02 blending mode was problematic until the
  fix.

[rew (r-e-wolff)]

Kay,

How big is your output image?

Does the problem go away if you make your output image size half that what it is now? (both X and Y).

What happens if you start with horribly compressed jpg images? If you set the quality very low, they will become very ugly, but this doesn't matter for the computer.

[KFJ (kfj)]

Am 28.02.2012 16:01, schrieb rew:
> Kay,
>
> How big is your output image?

400MB

> Does the problem go away if you make your output image size half that
> what it is now? (both X and Y).

... I'm not sure if I want to go down this road any further. With the
original bug in enfuse, which seems to have been fixed by now, I managed
to reduce the problem to a manageable size. I've tried the approach
here, but failed. Even though I could reproduce the bug with the
original big image set, it was exotic data, so it may just have been a
freak incident never to show up again. I had to revert back to an
earlier stable enblend version anyway, because the bleeding edge was too
slow (even though I compiled the Release version and used
--primary-seam-generator=nearest-feature-transform or whatever the
relevant flag was called...).

> What happens if you start with horribly compressed jpg images? If you
> set the quality very low, they will become very ugly, but this doesn't
> matter for the computer.

I'd first have to create all the horribly compressed JPEGs... I may try
again later, but just now I'm too busy with other stuff.

Kay

[Christoph Spiel (cspiel)]

If you cannot trigger the bug anymore -- for whatever reason,
I'll close this issue and mark it as fixed.

[KFJ (kfj)]

Am 04.03.2012 17:10, schrieb Christoph Spiel:
> If you cannot trigger the bug anymore -- for whatever reason,
> I'll close this issue and mark it as fixed.
>
Please do so. The enfuse bug really seems to be fixed after all, and if
the problem I had with enblend the other day should ever resurface I'll
start a new bug report.

Kay