there where several reports of problems with the 360° seam even if the -w switch is used. I was able to reproduce the problem. In my testpano the seam was not very much visible, but it's definitely there.
best regards -- Erik Krause Offenburger Str. 33 79108 Freiburg
> there where several reports of problems with the 360° seam even if > the -w switch is used. I was able to reproduce the problem. In my > testpano the seam was not very much visible, but it's definitely > there.
> best regards > -- > Erik Krause > Offenburger Str. 33 > 79108 Freiburg
They reproduce the zenith vortex problem as well...
Theses are two equirectangular images out of 6 Simply pass them to enfuse using the -w parameter. View the result in a spherical panorama viewer, like f.e. PTViewer. If you look straight up there is the vortex and from that a faint line (a brightness difference) goes down where the 360° joint is. This line is not visible if you view the source images.
I'm waiting for some examples that show the effect better.
When blended with the -w option you can easily see a seam in the sky.
To reproduce, run enfuse on these, use the -w option and then use your
favorite image editor to offset the results and you'll see a seam. I
believe it also shows the zenith vortex.
Hi Robert,
The individual layers show slight blend seams from the 4 incremental
shots. Vignetting or crop control can eliminate that, i think.
The original filess have an odd size and are not equirectangular. It
produced a vortex and 360 blend seam in enfuse360
Resizing to proper eq dimension did not show the blend seam but the
vortex at zenith meridian.
On Jan 25, 6:46 pm, VRdundee <vrdun...@gmail.com> wrote:
> Hi Robert,
> The individual layers show slight blend seams from the 4 incremental
> shots. Vignetting or crop control can eliminate that, i think.
> The original filess have an odd size and are not equirectangular. It
> produced a vortex and 360 blend seam in enfuse360
> Resizing to proper eq dimension did not show the blend seam but the
> vortex at zenith meridian.
Hi Milko,
To make the files a bit easier to upload/download there were resized
to half their original size in PS and reduced to 8 bits from 16. And
yes it looks like PS has rounded up so there is 1/2 an extra pixel in
the width. But, in the original fliles, they are an exact 2 to 1
relationship and the seam is there.
If any one of these input files is produced as a 360 it does not show
a seam. When run through Enfuse a seam is produced.
> The individual layers show slight blend seams from the 4 incremental
> shots. Vignetting or crop control can eliminate that, i think.
> The original filess have an odd size and are not equirectangular. It
> produced a vortex and 360 blend seam in enfuse360
> Resizing to proper eq dimension did not show the blend seam but the
> vortex at zenith meridian.
Hi Milko,
I just tired resizing the files I made available by changing the size
to 4036 by 2018. The fuse process still produces a seam, it's
especially strong by the tree.
> > The individual layers show slight blend seams from the 4 incremental > > shots. Vignetting or crop control can eliminate that, i think. > > The original filess have an odd size and are not equirectangular. It > > produced a vortex and 360 blend seam in enfuse360 > > Resizing to proper eq dimension did not show the blend seam but the > > vortex at zenith meridian.
> Hi Milko,
> I just tired resizing the files I made available by changing the size > to 4036 by 2018. The fuse process still produces a seam, it's > especially strong by the tree.
It seems that there was a long-standing bug in the Laplacian pyramid code regarding the wraparound boundary condition. I have checked a fix into CVS. This will effect both enblend and enfuse. I am surprised this issue did not appear earlier. If anyone encounters further artifacts please let me know.
On the topic of equirectangular images, it is not necessary for the image to have an exact 2:1 aspect ratio in order to use the -w flag. This flag only states that the left and right edges of the output image are supposed to meet up. For example you can make a long and skinny 360 cylindrical image that omits the zenith and nadir and still use -w.
The "zenith vortex" artifact stems from the extreme warping at the top and bottom edges of equirectangular images. Enblend and Enfuse do not understand that all of the pixels along these edges are supposed to meet up. This is not a bug, it's a "missing feature". Unfortunately I don't know how to do this. Erik Krause suggested implementing a boundary condition where each top edge pixel matches with another top edge pixel 180 degrees away. I tried this several years ago and it does not work. It only produces a zenith vortex that is symmetrical through the zenith.
Yuval's idea to use cube faces is more promising. All six cube faces would have to be made available to Enfuse at the same time. Then every edge would have a corresponding edge to draw boundary pixels from. The fact that all of the boundaries are horizontal or vertical makes this approach a better fit with the current pyramid algorithms. The same code would be useful for Enblend as well. Enblend would also need a nearest feature transform that operates on the surface of a cube. If anyone knows an efficient algorithm to solve this, please send me a reference.
Andrew
On Jan 27, 2008 11:00 AM, Andrew Mihal <andrewcmi...@gmail.com> wrote:
> I can reproduce the bug. Thanks for posting the test images. I'll keep you > posted.
> Andrew
> On Jan 27, 2008 10:18 AM, Robert Harshman <image...@gmail.com> wrote:
> > > The individual layers show slight blend seams from the 4 incremental > > > shots. Vignetting or crop control can eliminate that, i think. > > > The original filess have an odd size and are not equirectangular. It > > > produced a vortex and 360 blend seam in enfuse360 > > > Resizing to proper eq dimension did not show the blend seam but the > > > vortex at zenith meridian.
> > Hi Milko,
> > I just tired resizing the files I made available by changing the size > > to 4036 by 2018. The fuse process still produces a seam, it's > > especially strong by the tree.
Andrew> The "zenith vortex" artifact stems from the extreme warping at the top and Andrew> bottom edges of equirectangular images. Enblend and Enfuse do not understand Andrew> that all of the pixels along these edges are supposed to meet up. This is not a Andrew> bug, it's a "missing feature". Unfortunately I don't know how to do this. Erik
How about using the panotools projection stack. Enfuse/enblend can work in spherical coordinates, instead of cartesian. I don't really know how enblend/enfuse work and if this will be useful, but it will not be difficult to add the coordinate transformations (the input equirectangulars make it easy).
Andrew> Krause suggested implementing a boundary condition where each top edge pixel Andrew> matches with another top edge pixel 180 degrees away. I tried this several Andrew> years ago and it does not work. It only produces a zenith vortex that is Andrew> symmetrical through the zenith.
Andrew> Yuval's idea to use cube faces is more promising. All six cube faces would have Andrew> to be made available to Enfuse at the same time. Then every edge would have a
This might sound stupid, but how about processing the equirectangular twice:
* Pass 1. Enblend/enfuse
* Pass 2. Rotate the images 90 degrees (pitch), such that zenith and the nadir are in the horizon. Then enblend/enfuse.
* Blend the resulting images at aproximately the 45 degree parallel (this can be done simply with a alpha channel in both images).
It will be significantly slower, though, but it does not require any changes to enblend/enfuse. It can all be done via scripting with the tools we currently have.
We can even require the user to provide the rotated images.
On Saturday, February 02, 2008 at 21:55, Andrew Mihal wrote: > Erik Krause suggested implementing a boundary condition where each top > edge pixel matches with another top edge pixel 180 degrees away. I tried > this several years ago and it does not work. It only produces a zenith > vortex that is symmetrical through the zenith.
Well, it didn't avoid the vortex completely in my test case but it reduced significantly. What I did was to mirror the image on the top edge, then shift it sideways half width. But I understand that this is no solution, since it gives no perfect result.
Pablo mentioned that probably sinusoidal projection would be beneficial. It has no horizontal pixel stretching and to produce it from equirect there is only a 1-dimensional transformation needed if the vertical pixel count stays the same. And there is only one boundary to process. Unfortunately I don't have any idea whether this is feasible.
Andrew Mihal wrote: > Yuval's idea to use cube faces is more promising.
I have some ugly script hidden somewhere. I'll have to grab it out, rewrite it (it's PHP, meant to run on a server) and forward it to you.
what it does is: - extract the cubefaces from the equirct - combine them into "crosses" - one cross per cubeface
then you could work on the crosses, however I am not sure if the four corners would be a problem. I like much better Daniel's idea of pitching the equirect 90°.
For the sinusoidal: will the black around the boundaries be an issue?
Erik> On Saturday, February 02, 2008 at 21:55, Andrew Mihal wrote:
>> Erik Krause suggested implementing a boundary condition where each top >> edge pixel matches with another top edge pixel 180 degrees away. I tried >> this several years ago and it does not work. It only produces a zenith >> vortex that is symmetrical through the zenith.
Erik> Well, it didn't avoid the vortex completely in my test case but it Erik> reduced significantly. What I did was to mirror the image on the top Erik> edge, then shift it sideways half width. But I understand that this Erik> is no solution, since it gives no perfect result.
Erik> Pablo mentioned that probably sinusoidal projection would be Erik> beneficial. It has no horizontal pixel stretching and to produce it Erik> from equirect there is only a 1-dimensional transformation needed if Erik> the vertical pixel count stays the same. And there is only one Erik> boundary to process. Unfortunately I don't have any idea whether this Erik> is feasible.
The sinusoidal is area preserving, so this is a very good idea. Perhaps it will give better results when combined with doing the blending/enfusing in polar coordinates than the equirectangular. There is less of a worry of interpolation. I guess it is a matter of trying it.
|
