Suggestion on how to estimate the size of a Gigapixel Panorama
I noticed that people don't really agree on how to count pixels on gigapixel panoramas. Perhaps the most prominent example is the "Shanghai 272 Gigapixels".
The author himself says:
Alfred Zhao wrote:
Estimated optical pixels: 112G pixels
Pixels: 272,312,102,608 [which is 272 GP]
How can this be?
... the risk of generating a totally spurious projection of your panorama due to the fact that it is not symmetrical above and below the horizon. This was the problem with the Shanghai panorama. The reason why the size is so false, is because in order to maintain a projection where verticals stay vertical, the panorama has been massively stretched. It's the same with trying to correct images shot when a lens is pitched up to capture a tall building in a single shot. To get the building edges straight, you have two choices - stretch the top part of the image (interpolating pixels), or shrink the bottom part of the image (throwing away resolution.
How are pixels counted today? It's with a picture overlap model. In a nutshell: (Amount of pixels of an single picture) x (amount of total pictures taken) - ("not used overlap pixels") = Size of the gigapixel panorama Richard did a good job explaining that method here: http://www.kolor.com/forum/p76008-2011- … -51#p76008
Why is this method not accurate?
First let me make some assumptions:
1) All pictures were made from the same place, not multiple standpoints. 2) The same camera/lens was used for all pictures.
In this case the upper and lower part of the panorama does not need to be shot with same amount of pictures as the middle of the panorama does. In fact some automatic panorama-heads do this automaticly and save this info in a .xml-File
I will use the globe to illustrate that:
If you imagine every red dot to be the center of an image taken to make a panorama (supposing the earth is hollow and you sit in the center of it and photograph its outer layer) You see: as you get more and more away from the equator (in most cases it would be the horizon for our pictures) the overlap gets higher. And that is where the problem of the "picture overlap model" comes in to play. The pictures of the polar regions cannot be counted equally as the pictures of the equator.
What happens when we project our panorama into a flat image?
The polar regions get stretched.
Most gigapixel panorama look something like this:
1) The great amount of pictures is taken below the horizon 2) The "polar region" is not photographed 3) (In this case it would be an 360° image... it's rarely the case but I couldn't find a better picture)
How can the size be estimated while taking that into consideration?
It's not super easy, but it can be done:
What we need to know:
- What camera/lens combination that was used - The final field of view (FOV) of the gigapixel panorama (how much degrees above y=0° (more or less the horizon) and how much below, this is very important!)
that's it, easy as that! Overlapps do not make any difference!
How to calculate it:
I will use the well known "Shanghai 272 Gigapixels" as an example because it's one of the panoramas I know all the details of and because it's a good example of what we were talking above.
Field of view: Horizontal viewing angle: 175 degree Vertical viewing angle: 65 degree (+5 & -60)
- Horizontal FOV of hardware (held in landscape mode): 1.6°
- How much pixels can be shot per horizontal degree? ((360°/1.6°) x 5184px ) / 360° = U / 360° 3240px
- What would the radius of the sphere be? U/2π =r 185'638.33px
- How big is "h" (see picture above) above and under y=0? r x cos(90° - 5°) + r x cos (90°-60) = h 176'946.95px
- How big would be the panorama if the horizontal FOV would be 360°? 2πrh = A (if 360°) 206390924879px
- But the FOV is only 175° (A (if 360°) / 360°) x 175° 100328921816px or 100.3 GigaPixels
I know it could be calculated in a more elegant way, but I wanted to demonstrate every step that is needed. This calculation does not make any assumption about the picture quality itself. This way only the amount of pixels (good or bad) are estimated that were taken AND used to make a uncropped gigapixel panorama.
DISCLAIMER: I hope I didn't calculate something wrong, if so: Please correct me!
- The "picture overlap model" is easy to use and is totally ok for a raw estimation. - If someone would want to make a little tool that would calculate this automaticly for everyone, please contact me and I'll send you all calculations I did. (I would love to do it myself, but I have no programming skills at all) - Perhaps you guys from kolor want to integrate that in to your future autopano version? How about that?
So this is a "raw idea" I had and it might not be perfect, let me know what you guys think!
Re: Suggestion on how to estimate the size of a Gigapixel Panorama
Excellent calculation Zurich.Gigapixel ! In fact, we are doing such calculation internally in autopano. It is used to find where the slider 100% in rendering size is located. We could expose from that calculation the sphere surface compared to the equirectangulare surface ( a simple ratio if 360x180, it is much more complicated to explain when having a partial panorama ).