pvQt -- a new portable OpenGL panorama viewer

[Tom Sharpless]

Another panorama viewer? Well, yes, I think some of you might be
interested in this one. It began as an exercise for learning Qt and
OpenGL, which I hoped might produce a useful viewer for Linux. But it
works so well (on the right hardware) that I've decided to release it
to the world (https://sourceforge.net/projects/pvqt/).

pvQt uses the advanced texture mapping capabilities of OpenGL version
2.0 or better, to generate true 3D views: the panorama is projected on
a cylinder or sphere, whose interior is seen in perspective from a
movable point of view. That makes it possible to rotate the view in
all 3 dimensions (yaw, pitch, and roll) and to change the perspective
continuously from rectilinear (when the eye is at the center) through
increasingly "fisheye-like" views, out to a "super fisheye" that can
show almost 288 degrees of the panosphere.

At present pvQt only knows how to display spherical panoramas, in
equirectangular or cubic formats (including cubic QTVRs). But it is
designed to handle all the common pano formats and show "flat" photos
too. It has a few glitches, the worst of which is that it can't tell
whether it is running on an OpenGL implementation that actually
supports it -- if not, it just shows all white images.

Building pvQt requires the Qt development framework, which is huge but
reliable and easy to use, and zlib, which is tiny and ubiquitous.
There is a prebuilt win32 (MinGW) executable on SF, along with the
needed MinGW and Qt DLLs. It is in a self extractor that only runs on
Windows, but soon there will be a source tar too. And you can check
out the source tree with "svn co https://pvqt.svn.sourceforge.net/svnroot/pvqt
pvqt ".

Cheers, Tom

[Philipp B. Koch]

Tom Sharpless schrieb:
> (...) But it works so well (on the right hardware) that I've decided to release it

> to the world (https://sourceforge.net/projects/pvqt/).

Hey Tom,

this look really interesting! Especially the superfish and full frame
views are awesome!
Just three small things, though:

a) I'd love to see mouse support. Is this a planned feature?

b) When choosing cube faces, the up and down keys are inverted, compared
to their function while displaying an equirectangular image.

c) How come you decided to use "CTRL + =" for zoom in and not simply the
PLUS key? It's a little inconvenient IMHO.

Anyway, thanks a lot for sharing this!!
Regards, Philipp

[Tom Sharpless]

Hi Philipp

Thanks for trying pvQt. What are you running it on, and did you build
it?

On Oct 11, 8:11 am, "Philipp B. Koch" <p...@philippkoch.com> wrote:
> Tom Sharpless schrieb:> (...)  But it works so well (on the right hardware) that I've decided to release it
> > to the world (https://sourceforge.net/projects/pvqt/).
>
> Hey Tom,
>
> this look really interesting! Especially the superfish and full frame
> views are awesome!
> Just three small things, though:
>
> a) I'd love to see mouse support. Is this a planned feature?

Probably; but I also want to support drag-and-drop (especially for
loading image into cube faces) so I want to think more about mouse
protocol before I write anything.

>
> b) When choosing cube faces, the up and down keys are inverted, compared
> to their function while displaying an equirectangular image.

I hadn't noticed, but will check this. The coordinate system is
oriented differently for equirectangular and cubic displays.

>
> c) How come you decided to use "CTRL + =" for zoom in and not simply the
> PLUS key? It's a little inconvenient IMHO.

Because I use Photoshop all the time, I instinctively hit Ctrl+ and
Ctrl- when I want to zoom. But I think I'll take your suggestion and
use plain + and -.

When I figure out how to get Qt to actually use multiple keyboard
shortcuts (it accepts them but only the first one seems to work) I'll
put in some aliases for several of the commands.

>
> Anyway, thanks a lot for sharing this!!

You are welcome!

> Regards, Philipp

[Philipp B. Koch]

Tom Sharpless schrieb:

Hi Tom,

thanks for your reply.

Thanks for trying pvQt.  What are you running it on, and did you build
it?
  

Oh sorry, forgot to mention... I run it on Windows XP Prof SP3. No, I did not build it, I used your precompiled Version.

[mouse-support]

Probably; but I also want to support drag-and-drop (especially for
loading image into cube faces) so I want to think more about mouse
protocol before I write anything.
  

Ah, I see. Drag'n'drop would be nice indeed. Right now I'm using it as a entry in my SendTo-folder and thus have to choose file format everytime I give it one or more file(s) that way.

[reason for "CTRL + =" as zoom key]

Because I use Photoshop all the time, I instinctively hit Ctrl+ and
Ctrl- when I want to zoom.  But I think I'll take your suggestion and
use plain + and -.

When I figure out how to get Qt to actually use multiple keyboard
shortcuts (it accepts them but only the first one seems to work) I'll
put in some aliases for several of the commands.
  

Same with me and Photoshop :-) It's just that -- at least here, on my PC (maybe due to my German keyboard layout?) -- it tells me to use CTRL and "=" (equal) to zoom in, not PLUS, while zoom out is CTRL and MINUS. If I press CTL and PLUS, nothing happens.

I'm anxious to see the next releases. Please keep us informed :-)

Best, Philipp

[Tom Sharpless]

Thanks again Philipp

I'm glad to hear that the prebuilt program works for you. I haven't
been able to test it fully as my only machine that can run it already
has Qt4 and MinGW installed, so I couldn't be sure all the
prerequisites are in the distribution. But unless you have those,
too, I guess it can be considered OK.

Of course zoom in is Ctrl= in fact; I guess calling it Ctrl+ (really
CtrlShift=) is another Photoshop-ism.

Regards, Tom

On Oct 11, 10:08 am, "Philipp B. Koch" <p...@philippkoch.com> wrote:
> Tom Sharpless schrieb:
> Hi Tom,

> thanks for your reply.Thanks for trying pvQt. What are you running it on, and did you build it?Oh sorry, forgot to mention... I run it on Windows XP Prof SP3. No, I did not build it, I used your precompiled Version.[mouse-support] Probably; but I also want to support drag-and-drop (especially for loading image into cube faces) so I want to think more about mouse protocol before I write anything.Ah, I see. Drag'n'drop would be nice indeed. Right now I'm using it as a entry in my SendTo-folder and thus have to choose file format everytime I give it one or more file(s) that way.[reason for "CTRL + =" as zoom key] Because I use Photoshop all the time, I instinctively hit Ctrl+ and Ctrl- when I want to zoom. But I think I'll take your suggestion and use plain + and -. When I figure out how to get Qt to actually use multiple keyboard shortcuts (it accepts them but only the first one seems to work) I'll put in some aliases for several of the commands.Same with me and Photoshop :-) It's just that -- at least here, on my PC (maybe due to my German keyboard layout?) -- it tells me to use CTRL and "=" (equal) to zoom in, not PLUS, while zoom out is CTRL and MINUS. If I press CTL and PLUS, nothing happens.

[Ken Warner]

Hi Tom,

That tool you mentioned on the other list:
"GPU capabilities viewer" at oZone3D.net

Good tool!

I'm at OGL 1.5 so .....

[Tom Sharpless]

Hi Ken

It seems most of us have OGL 1.5 systems, so I am going to try to make
pvQt support them. That is mostly a matter of making texture images
with power-of-two dimensions, as 1.5 does have cube mapping. But I
need to learn more about how to probe OGL's capabilities. Most OGL
1.5 systems have far less video RAM than a typical 2.0 system, however
that might just make pan & zoom jerky.

I suspect that pvQt will display a 1024x512 equirectangular (such as
snall_eqr.tiff in pvQt/test) on your system, at least that is Harry
van der Wolf's experience. I asked him if he would mind trying some
bigger power-of-2 images to see what the size limits might be, and I'd
be glad if you could do the same.

Regards, Tom

[Ken Warner]

Sure. Glad to help. Let me know when you have a 1.5 compatible .exe...

[Tom Sharpless]

Hi Ken,

Well, it is becoming clear that I don't know much about OpenGL.
Several people with OGL 1.5 systems have now reported that pvQt will
display non-power-of-two images, but nothing over about 2 megapixels.
So I'm going to go back to the drawing board for a while and see if I
can make pvQt discover the feasible limits for itself.

Regards, Tom

[Ken Warner]

Hummm... That limit doesn't make sense to me. Unless
OGL is somehow using video memory. Do you use doubles
or floats internally?

[Tom Sharpless]

Hi Ken

I believe that OGL does store texture images in video RAM, where they
compete for space with lots of other things; so the maximum usable
texture size varies dynamically. The textures in pvQt are all 24 bit
RGB,

BTW the upgrade I mentioned earlier was a success. With the addition
of an EVGA GeForce 6200 PCI card ($45 at NewEgg.com) my aging AMD
Sempron box is now OGL 2.0 capable, and pvQt can display 20 Mpixel
cubic QTVRs. So that is the way to go if you can.

But I'm still going to try to work with OGL 1.5, because I have an
otherwise nice IBM laptop at that level, on which I often stitch in
the field.

Regards, Tom

[Ken Warner]

Yeah, after I wrote I started to think back to the time
when I was doing OGL programming -- about 10-12 years
ago. I vaguely remember limits on textures.

BTW: Have you tried a tessilated sphere for the viewer?
I once wrote some code -- long gone now -- that tesselated
a sphere recursively starting with a tetrahedron. Works pretty
good. Use polar coords and keep your radius at 1.0 and recursively
subdivide the triangular faces of your tetrahedron. The code is
small and you can control the depth to which the recursive
subdividing goes to.

The only upgrade I'm planning to do with my old Win2K box is to rip
out the mother board and power supply and replace with new ones -- :-)

[Tom Sharpless]

Hi Ken

On Oct 13, 6:53 pm, Ken Warner <kwarner...@verizon.net> wrote:
> Yeah, after I wrote I started to think back to the time
> when I was doing OGL programming -- about 10-12 years
> ago.  I vaguely remember limits on textures.

OGL 2.0 systems can handle really big textures, and have no trouble
cube mapping a big panorama; 1.5 is barely adequate for small ones.

>
> BTW: Have you tried a tessilated sphere for the viewer?
> I once wrote some code -- long gone now -- that tesselated
> a sphere recursively starting with a tetrahedron.  Works pretty
> good.  Use polar coords and keep your radius at 1.0 and recursively
> subdivide the triangular faces of your tetrahedron.  The code is
> small and you can control the depth to which the recursive
> subdividing goes to.

I'm using the lat/lon sphere provide in glu; it would be nicer to have
all triangular faces but then I'd have to learn how to draw them all
clockwise....

>
> The only upgrade I'm planning to do with my old Win2K box is to rip
> out the mother board and power supply and replace with new ones -- :-)

I urge you to add an OGL v2 capable video card too. $50 will get you
one.

Regards, Tom

[Ken Warner]

Oh yes, forgot about the clockwise thing. Yeah, that
would be a brain teaser...