Yellow lines in output tiff

Asked by tikhon03 on 2017-07-07

I am using Hugin on linux mint on a desktop with 16GB of RAM and a core i3 processor. I am trying to make a high resolution image of a map. I shot about 40 images in a grid with at least 50% overlap between adjacent images in the grid. The camera was held in place on a beam and the map was moved around, so all of the shots were equidistant, and really only the position was changing. Based on the tutorials I decided to use the following settings:

Mosaic mode, rectilinear projection, with a "new lens" specified for each image. Position and translation were optimized. I used CP find to create control points but also manually added vertical and horizontal lines. Even without the lines Hugins was able to align the images properly, but the horizontal and vertical lines made the fit even better. The input files were 16bit tiffs with about 20 megapixels each, and the output was set to uncompressed tiff. As a consequence the output file is about 1.5 GB.

In spite of all my very precise attempts to take the images and align them in hugin, the output file has horizontal yellow lines in certain places almost like stretch marks. Each line is only one pixel wide, but they are obvious and hideous to look at. Why does this happen? Why are they only horizontal, and never vertical or diagonal? Are there some settings I can change to prevent this from happing? Thank you.

Question information

English Edit question
Needs information
Hugin Edit question
No assignee Edit question
Last query:
Last reply:
tmodes (tmodes) said : #1

The output process consists of (at least) 2 steps:
1.) Remapping to the output projection (here are also the photometric corrections applied). This is done by nona.
2.) Blend the remapped images to final output. This is done by enblend or verdandi.

So the first step is to check in which step the yellow marks appear: Are they already in the remapped images or appear they only in the blended images?

tikhon03 (tikhon03) said : #2

In the version I tried before posting the question I was using enblend. After posting I tried verdandi and I am not getting yellow lines with verdandi. I also looked at the intermediate files produced by nona, and there are no yellow lines in them. So I'm pretty sure the issue is with enblend. During step 2 with enblend I get this:

enblend: warning: unable to run Dijkstra optimizer
enblend: note: seam-line end point outside of cost-image

I also experimented with changing the image cache settings. The default seems to be 256MB which is very low, but the setting seems to be ignored anyway. The output of top indicates about 1GB RES regardless of the setting, with virtual memory in excess of 10GB.

So now what?

tmodes (tmodes) said : #3

So this seems to be an enblend bug: please try to find the smallest set which shows this bug and report it to then enblend tracker at (see also )

If verdandi works then there is a workaround available, isn't it.

PS: The warning about the Dijkstra optimizer have probably nothing to do with the yellow marks.

tikhon03 (tikhon03) said : #4

I am not confident I can determine a "smallest" set. Using one image set, I can avoid the yellow lines with as many as 15 images, but by trying a different set, the yellow lines show up with as few as 13. And since enblend is not parallelized there is a lot of waiting around before I can tell if the yellow lines show up. Do you think 13 images is a small enough number to work with for debugging purposes? I assume you want me to provide the images and the pto file for debugging.

As for verdandi, it has some of its own problems. Without photometric optimization I get sharp edges at the seams, and with photometric optimization the image is blotchy and has some loss of texture detail. I have basically concluded that photometric optimization only makes things worse with my current image set, and only enblend accomplishes the feat without sharp edges at the seams.

You are probably correct about the Dijksta optimizer not being the issue, because the warning still shows up even without yellow lines marring the output image.

tmodes (tmodes) said : #5

A small set would be one which you could easily attach to a ticket or maybe provide via a webspace.

> As for verdandi, it has some of its own problems. Without photometric optimization
Now you mix up things. One is the blending, which is done by verdandi or enblend.
The other thing is the photometric correction. If there is a problem then verdandi and enblend would be affected both. Maybe for a map the fitting of the response curve does not work so good, because there are not so much different lightness values. So I would only optimize the exposure values, the white balance and vignetting, but not the response curve.
Also verdandi has another blending mode which should decrease the seam visibility.

tikhon03 (tikhon03) said : #6

Well, yes. enblend is also affected by the photometric optimizations. I have not been doing photometric optimizations with enblend either for the same reason: the result with the map is blotchy. What I mean is that photometric optimization seems to be useful to prevent verdandi from showing sharp edges at the seams, which enblend doesn't need because it does a fine job blending the seams.

But back to the original issue with enblend, I actually am not allowed to upload the map images because they belong to a college. I will try to make a different set of images to upload which still causes the yellow lines, but I won't be able to do that until August because I will be traveling. The set of 15 images that did not produce yellow lines resulted in an output tiff of only 841 MB, whereas the set of 13 images that did produce the yellow lines resulted in an output tiff of 1.5GB. On all occasions where the yellow lines occurred, the output tiff file was at least 1.5GB. So, I don't think I can upload a set much smaller than 13 images. It will have to be via google drive, or dropbox, or something.

tmodes (tmodes) said : #7

And when you only take 2 images from the 13 image set - where the yellow marks appear in the final image - and then enblend only these two?

PS: Which enblend version do you use? Also when you are using a version with image cache (use enblend -v -V to see compiled in options) you could try a version without image cache. The image cache implementation is known for some artifacts with bigger images and been removed from the repository.

tikhon03 (tikhon03) said : #8

Using just 2 images in the region where yellow lines appear, then they no longer appear. I have only been trying this with 16bit tiff files, so I do not know if file type matters. No compression is being used. Yellow lines do not seem to appear anywhere for any output tiff with 800MB or less, but always appear with the full map at 1.5GB. It is possible there is some cutoff in between.

I'm just using the binaries from the mint repositories:
enblend version 4.1.4+dfsg-5
hugin version 2015.0.0+dfsg-1
I'm not sure whether it is with or without the image cache. Hugin has image cache as an option in preferences, but changing the value seems to have no effect on memory usage as indicated by top. This does seem like it could be an issue with memory though. I am on vacation now, but maybe when I get back, I can try installing the latest version of hugin from github, and see if there is a difference.

tmodes (tmodes) said : #9

The current stable versions are enblend 4.2 and Hugin 2017.0.
So please update first. Maybe the issue has be already fixed.

Regarding image cache: run enblend -v -V from the terminal/command line.
The image cache setting in Hugin has nothing to do with enblends image cache. These are 2 different things.

Can you help with this problem?

Provide an answer of your own, or ask tikhon03 for more information if necessary.

To post a message you must log in.