unblended triangle in fused version?

[Brandan]

That is a blended_fused version of a pano. It looks good to my eye, except that for some reason it missed a small part by the lamp. See this photo

The normal low range copy does not have that, but the over all coloring is not as good as this fused version. Any idea what causes that in the fused version and how to fix it?

[Wirz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Brandan,

I think you are experiencing this bug

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

For me, changing the output resolution, choosing a fine mask, switching
off mask optimization and combinations of these sometimes helps.

cheers, lukas


On 11/07/14 19:29, Brandan twisted the bytes to say:
>
> <https://lh6.googleusercontent.com/-uuRvdaTdrrA/U7-RjS_h6XI/AAAAAAAAABg/GCxzmyyIJag/s1600/living_blended_fused.jpg>

> That is a blended_fused version of a pano. It looks good to my eye, except
> that for some reason it missed a small part by the lamp. See this photo
>

> <https://lh5.googleusercontent.com/-XC1pV-oS9qY/U7-RzB7R9rI/AAAAAAAAABo/WUVIuNrHrEY/s1600/zoomin.jpg>

>
> The normal low range copy does not have that, but the over all coloring is
> not as good as this fused version. Any idea what causes that in the fused
> version and how to fix it?

> <https://lh5.googleusercontent.com/-XC1pV-oS9qY/U7-RzB7R9rI/AAAAAAAAABo/WUVIuNrHrEY/s1600/zoomin.jpg>
>


- --
Do not believe the naysayers who say it cannot be done.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iEYEARECAAYFAlO/skQACgkQ1m2kmG8CIy2PNACfYIxI3m5DoHTRuDSLax98kMeL
0g8AoKX2h6W7zrgi/6r4nuqtOfRGL0m6
=gzlB
-----END PGP SIGNATURE-----

[Brandan]

It is good to know I am not messing up. This bug sounds like a bugger to
pin down as it has been here for over 4 years.

Is it just with the fused versions or will the low dynamic range do it as
well?

Before a week ago I had not seen it on either version. Now it is showing up
in the fused one once in a while, but so far not the low dynamic range.

Thanks for the tips. I will see if any of them help me.

[Wirz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Brandan,

> Is it just with the fused versions or will the low dynamic range do it
> as well?

The bug I'm talking about is an enblend bug, so the fusing itself is
irrelevant and your ldr version can be affected as well. It doesn't
have to ... slightly moving single pictures or changing their order in
the project can introduce or remove these artefacts.

cheers, lukas

- --
Do not believe the naysayers who say it cannot be done.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iEYEARECAAYFAlPDoSMACgkQ1m2kmG8CIy0CHACfR38iU2/amxNg8HliccsnBv+J
L4EAoKSYy9q3wneqFv6DwA5qeqTrRzZm
=6wt8
-----END PGP SIGNATURE-----

[Bruno Postle]

On 14 July 2014 10:21, Wirz <sp...@lukas-wirz.de> wrote:
>
> The bug I'm talking about is an enblend bug, so the fusing itself is
> irrelevant and your ldr version can be affected as well. It doesn't
> have to ... slightly moving single pictures or changing their order in
> the project can introduce or remove these artefacts.

I believe that this bug might be fixed in enblend-4.1.3. This was
released in March this year, but it doesn't look like there was ever
an announcement:
http://sourceforge.net/projects/enblend/files/enblend-enfuse/enblend-enfuse-4.1/

--
Bruno

[Wirz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 14/07/14 22:13, Bruno Postle twisted the bytes to say:

I remember that commit.

Actually I suspect that more than one bug causes the same type of
artefact. With my locally compiled version I could reproduce these
artefacts well past 4.1.3 (but haven't tried recently). But if that
patch fixed the problem in some situations/for some people that's
already something.

cheers, lukas


- --
Do not believe the naysayers who say it cannot be done.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iEYEARECAAYFAlPDz5AACgkQ1m2kmG8CIy2s2gCgu6Ki3957BYRLzF8Zgz3ByrbM
nTkAn1bqpVIke3uq+WF3/o3qS1yf/2NI
=+DQ4
-----END PGP SIGNATURE-----

[Battle]

I read the bug report, and admittedly I've never tried to change image order as one on the posters suggests.  

I often get this kind of artifact in Hugin.  For me it seems to occur when there is too much overlap between adjacent photos or when making is involved.  I find if I have too much overlap, adding a mask resolved the problem.  If its a masking related issue then often changing the shape or amount of area masked solves the problem.  

I wonder if it could be related to small, but mathematically calculable parallax error in the original photo set as it related to straight line objects.  The blend errors I tend to have seem to cut off at areas like yours did, the vertical line of the lamp shade, a curved object out of plane to the larger planar background, the wall.

Cheers.  

[Monkey]

I had a similar problem crop up while I was developing multiblend, though that had a slightly different cause. My guess at what may have happened is that, given three images in horizontal order, A B C, enblend has blended the small overlap between A and C before considering B. When it does come to add B to the composite, some parts of the blended A/C end up being included in the output image, when ideally that whole area should have been covered by B.

Another possibility is that neighbouring images overlap so much that, despite A being largely to the left of B, some parts of remapped A are off to the right of B, again giving them the chance to appear in the final composite when they should be covered up (this isn't likely in your single row pano).

Those sweeping spurs at the corners of remapped fish eye images could be the cause of just such problems.

Putting the images in shot order or overlapping a little less could stop the first case happening. Or you could use <a href="http://horman.net/multiblend">multiblend</a> ;)

Just a guess!

David

[Brandon]

Thanks for the tip on using the newer version of enblend. I have not stitched enough since switching to say if it has solved the problem or not, but I have not seen it yet so I am hopeful.

Another possibility is that neighbouring images overlap so much that, despite A being largely to the left of B, some parts of remapped A are off to the right of B, again giving them the chance to appear in the final composite when they should be covered up (this isn't likely in your single row pano).

Actually I think that may be exactly what happened. That pano and the others are full 360 by 180s and the down row can have a lot of over excessive overlap.

Putting the images in shot order or overlapping a little less could stop the first case happening. Or you could use <a href="http://horman.net/multiblend">multiblend</a> ;)

I am very interested in multiblend. The idea of something that is as much faster as it claims to be has my full interest but I have not been able to figure out how to get hugin to use it. I have put it in the bin folder but after that I am at a loss as far as how to tell hugin to use it. There are some settings under preferences that look like they should do the trick, but near as I can tell when I change them it is still using enblend. Any tips on how to install multiblend so that hugin will use it?

Thanks all,
Brandon
 

[Monkey]

The following applies to a 2012 Windows build, but...

Go to File->Preferences, Programs tab, tick "Use alternative Enblend program" and specify the path to a multiblend executable. If that doesn't work, you could just replace the enblend executable, though that's not a neat solution.

Multiblend's speed comes at a cost, of course - it uses more memory than Enblend and isn't quite so smart about the paths of seams (although the initial calculation of seams is better). Also for 360 degree panos, you will need to run Hugin's stitched and blended single output file through multiblend again to blend around the left/right edges.