Would it be feasible to implement an alternative “projection” for full
sphere panoramas that would actually consist of six 90°×90° projections,
equivalent to the faces of a cube with the center of the cube as the
point of view?
http://heh.fi/tmp/skybox_faces
http://heh.fi/tmp/skybox_faces_alternative
If enblend and enfuse were modified to understand the proposed format
(each face’s border wraps to another face in the image), the
zenith/nadir problem could be avoided completely.
Additionally, if the format happens to be suitable for whatever is used
to view the resulting panorama, the image’s pixel estate would be more
evenly spent compared to an equirectangular projection.
Sincerely,
--
Jοhan Kiviniemi http://johan.kiviniemi.name/
Carl
Equirectangular is 2:1, so no, this would not confuse the programs
> Johan Kiviniemi wrote:
> > Would it be feasible to implement an alternative "projection" for full
> > sphere panoramas that would actually consist of six 90°×90° projections,
> > equivalent to the faces of a cube with the center of the cube as the
> > point of view?
There is already such a projection, except it is 6:1. Spi-V treats any
image with such aspect ratio as cubic.
http://wiki.panotools.org/Panorama_formats#Cubic
http://www.fieldofview.com/spv-dev/docs/howto/preparing
I think that making enfuse/enblend cope with the border problems in
the cubic projection is not simpler than making them understand
spherical projections directly.
Cheers,
Seb
and "skybox_faces" is already very well known and discussed as
"cubefaces" ...
now let's see if I add to the fun or to the confusion:
<humor>
IMO this thread deserves the nomination for best thread in the category
"I wish I had a coffee before processing e-mail" =8^D
</humor>
Yuv
Come on Yuv, have a coffee !
Obligatory smiley to add even further to the confusion ;-)
blush...
Creating spherical panoramas is fairly extreme behaviour, I imagine
that most hugin users are creating single wide-angle images intended
to be seen as a complete composition.
>2) It _does_ solve the zenith/nadir blending problem. Each face is a
>simple rectilinear stitching job, piece of cake for enblend or
>anything else. Don't worry about the cube edges spoiling things, just
>stitch a little extra all around and saw it off after blending.
I'd like to see some tests, yes the cube edges should blend
similarly to the left/right edges of a 360 panorama, but I'm not
sure what will happen around the corners.
>3) Remapping between circularly symmetric formats (e.g. nearly all
>camera images and the cube faces) is both faster and less subject to
>aliasing problems than mapping the same images to equirectangular. So
>this path can lead to quicker and/or more accurate results.
What problem is being solved here? I don't see aliasing issues
mapping to and from equirectangular. Scaling equirectangular images
can be problematic, but so can scaling cube-faces (see any QTVR
preview track for evidence - and the extra work erect2qtvr does to
work around the problem).
With a cubic format, you still won't be able to open a single file
in photoshop and apply a large radius unsharp mask.
--
Bruno
Tom Sharpless wrote:
> Johan's proposal is actually very sensible.
nobody said it's not. AFAIK it has been discussed a few weeks ago by
different people under a different name.
> 1) 99% of spherical images are going to end up as QTVR's
as cubefaces / or stripes. Without starting a format war, it is not only
Quicktime. Cubefaces are the optimal format for interactive display,
used by SPi-V/Shockwave, Flashpanoramas, and many others.
Note that QTVR is not exactly cubefaces. IIRC, there is a one pixel
overlap on each side of each cubeface in the QTVR specs.
> 2) It _does_ solve the zenith/nadir blending problem.
you're right again. Andrew Mihal commented in that sense:
<http://groups.google.com/group/hugin-ptx/browse_thread/thread/a90169a794bb69d6/b63898bc952a02b3?lnk=gst&q=andrew+mihal#b63898bc952a02b3>
> 3) Remapping between circularly symmetric formats (e.g. nearly all
> camera images and the cube faces) is both faster and less subject to
> aliasing problems than mapping the same images to equirectangular. So
> this path can lead to quicker and/or more accurate results.
still, equirectangular "looks" more natural. It is easier to spot
stitching errors without being confused by the edges of the cube. I
personally need both formats.
I edit zenith and nadir in cubeface and I edit the 360° around me in
equirect.
And ah, not in QTVR - because QTVR comes after post-production / editing.
> I say it should be a hugin development goal.
what should be a hugin development goal and how would you spell it out
into specific functionalities?
I currently output the cubefaces straight out of hugin. I could see
slight user interface improvements, but I don't see it as such a radical
change. Am I missing something?
What I do is set the parameters right in the Stitcher tab, for the
Panorama type (rectilinear), the FOV (90°x90°) and the Canvas Size. Then
I use the numerical transform in the panorama preview window to point
the view up and down for zenith and nadir. Could also do the four side
faces if needed.
I'd love an automatism in the stitcher tab to create zenith and nadir
cubefaces without tweaking the numerical transform and the stitcher tab
every time, but even more pressing for me would be to have the layered
output go straight into a PSD file for post-processing in Photoshop.
Anyway, if you would like to give it a try, you have more C++ skills
than me, add a table to the stitcher tab. Call it cubefaces. headings +
six lines.
The six lines are called Zenith/Nadir/Front/Left/Right/Back.
On each line, a radio button to decide if that face should be output or
not. And the resolution for the faces (only one number, since
width=height, in pixes). Then a few columns for the output - eight if we
take the current output section of the stitcher tab). Then my dream
radio button: merge into a single multi-layered PSD.
Then hugin can programmatically extract the views at +90 pitch, -90
pitch, 0pitch {0,90,180,-90yaw}.
Yuv
Yuv
which brings a related question: does it make sense to apply such a
transform on an equirectangular? I mean, with the extrem stretches at
zenith and nadir, I would intuitively not apply noise filters to the
equirect. Same for sharpening?
Yuv
I large radius USM does not sharpen, it enhances local contrast.
However, although I know that there should be problems I actually
didn't ever see some at zenith and nadir. There is a problem with
large radius USM at the 360° seam, if there are structures with very
different brightness just behind the seam.
Anyway: It's best to apply a basic sharpening before stitching. This
removes lens and bayer interpolation blur. Then probably only an anti
alaising slightly sharpening interpolator like Lanczos3 or
Blackman/Sinc is necessary for the final output, which (if I
understood that correctly) takes care of the source mapping.
BTW.: Does hugin/nona/PTMender support the anti alaising filters
meanwhile? My current snapshot (0.7.0.2825) lacks of a possibility to
choose an interpolator...
best regards
Erik Krause
http://www.erik-krause.de
I am afraid this has been disabled in the user interface which needs
some rewriting that is likely to happen after 0.7.0 release.
Yuv
I had to interpolate each pixel as I projected it. A real
challenge to get any kind of performance out of the code.
Just for the record, rectilinear is not conformal. Stereographic, yes.
Mercator, yes too.
Cheers,
Seb