- fierodeval wrote, On 01.11.2008 19:04 Uhr:
> Hi Thomas,

But for the "best cube face possible" you have to think the other

>

> I saw this behavior too, if I open a 4000x2000 panorama, then the

> default cubeface is width/4 = 1000. But if you use width/4 you are

> loosing quality in all the cubeface, not only in the edges of the

> cubeface. If I display a MOV with 1000x1000 cubefaces I see the same

> quality than with a 3140x1570 equirect.

direction. You have to think of the necessary equirectangular to produce

these cube faces.

Just imagine a cube face with black and white lines, each 1 pixel in

width. To produce such a cube face with an equirectangular image the

width would need to be tile size * pi * sqrt(2) to produce such a

resolution.

To simplify the problem for a moment just think of it in two dimension,

looking onto the scene from the top. The equirectangular image is a

circle and the cube faces build a square.

To produce the highest possible resolution *in the corner* the circle

needs to have a radius of (tile size / 2) * sqrt(2). The resulting

circumference is now (square width / 2) * sqrt(2) * 2 * Pi = square

width * sqrt(2) * Pi.

If you look at this problem back in 3D the corner of the cube has a

distance of (cube size / 2) * sqrt(3) and the sphere that hits this cube

exactly at the corner needs to have this radius. Fortunately the same

amount of "stretching" happens from the equirectangular projection so

not more resolution is needed as for a cylinder.

> I don't understand when you say "loose quality in the center" or

The equirectangular image of this size would provide a higher resolution

> "sharp line near the cube face". If you modify the cubeface you change

> the quality in all the cubeface, not only in the center or in the

> edge. Or maybe I did not understand anything?

for the center of the cube face but as we want to produce a cube face we

reduce this portion by 1/sqrt(2) so approximately 3 pixels in the

equirectangular would just produce 2 pixel on the cube face.

As a conclusion: The formula to keep the resolution

cube face size=equi width/Pi

is only true in the equi -> cube direction. For the other direction

equi width=cube face size * Pi * sqrt(2)

would be true. As in the normal panorama workflow you start with an

equirectangular and convert it to cubic (or extract a view) to patch

stuff. In this process you are not adding high frequency information to

the image so it is safe to convert the image back with just the factor Pi.

> Another issue about Pano2VR. I always ask me what is the practical

Yes. This is just a *hint*. If you plan a zoom in of x2 then you need

> function of "Optimal" value for the cubeface. This value depends of

> the window size, but almost all panoramas are shown with a percentage

> size of the window, not a fixed size. And the existence of an optimal

> cubesize for a display window size, avoid the possibility to do

> zoom-in in the panorama, because the optimal value is calculated for a

> resolution of 1:1 cubeface:screen. Is this correct?

the doubled tile size. Also if you use a percentage you can calculate a

resolution for the target screen size.

--

MfG,

Thomas - Yes, I understand. But when you speak about the "sqrt(2)", you are

speaking about the figure in the right of this image

http://www.devalvr.com/fiero/equicube.jpg . Te correct figure is in

the left and this figure is valid in the two directions.

Then, if I understand correctly, you say that the figure for

equirect->cube conversion is the left image and for cube->equirect is

the right image?

fiero

--- In PanoToolsNG@yahoogroups.com, Thomas Rauscher <yahoo@...> wrote:

>

> fierodeval wrote, On 01.11.2008 19:04 Uhr:

> > Hi Thomas,

> >

> > I saw this behavior too, if I open a 4000x2000 panorama, then the

> > default cubeface is width/4 = 1000. But if you use width/4 you are

> > loosing quality in all the cubeface, not only in the edges of the

> > cubeface. If I display a MOV with 1000x1000 cubefaces I see the same

> > quality than with a 3140x1570 equirect.

>

> But for the "best cube face possible" you have to think the other

> direction. You have to think of the necessary equirectangular to

produce

> these cube faces.

>

> Just imagine a cube face with black and white lines, each 1 pixel in

> width. To produce such a cube face with an equirectangular image the

> width would need to be tile size * pi * sqrt(2) to produce such a

> resolution.

>

> To simplify the problem for a moment just think of it in two dimension,

> looking onto the scene from the top. The equirectangular image is a

> circle and the cube faces build a square.

>

> To produce the highest possible resolution *in the corner* the circle

> needs to have a radius of (tile size / 2) * sqrt(2). The resulting

> circumference is now (square width / 2) * sqrt(2) * 2 * Pi = square

> width * sqrt(2) * Pi.

>

> If you look at this problem back in 3D the corner of the cube has a

> distance of (cube size / 2) * sqrt(3) and the sphere that hits this

cube

> exactly at the corner needs to have this radius. Fortunately the same

> amount of "stretching" happens from the equirectangular projection so

> not more resolution is needed as for a cylinder.

>

> > I don't understand when you say "loose quality in the center" or

> > "sharp line near the cube face". If you modify the cubeface you change

> > the quality in all the cubeface, not only in the center or in the

> > edge. Or maybe I did not understand anything?

>

> The equirectangular image of this size would provide a higher

resolution

> for the center of the cube face but as we want to produce a cube

face we

> reduce this portion by 1/sqrt(2) so approximately 3 pixels in the

> equirectangular would just produce 2 pixel on the cube face.

>

> As a conclusion: The formula to keep the resolution

>

> cube face size=equi width/Pi

>

> is only true in the equi -> cube direction. For the other direction

>

> equi width=cube face size * Pi * sqrt(2)

>

> would be true. As in the normal panorama workflow you start with an

> equirectangular and convert it to cubic (or extract a view) to patch

> stuff. In this process you are not adding high frequency information to

> the image so it is safe to convert the image back with just the

factor Pi.

>

> > Another issue about Pano2VR. I always ask me what is the practical

> > function of "Optimal" value for the cubeface. This value depends of

> > the window size, but almost all panoramas are shown with a percentage

> > size of the window, not a fixed size. And the existence of an optimal

> > cubesize for a display window size, avoid the possibility to do

> > zoom-in in the panorama, because the optimal value is calculated for a

> > resolution of 1:1 cubeface:screen. Is this correct?

>

> Yes. This is just a *hint*. If you plan a zoom in of x2 then you need

> the doubled tile size. Also if you use a percentage you can calculate a

> resolution for the target screen size.

>

> --

> MfG,

> Thomas

> - Sometime around 1/11/08 (at 20:39 +0100) Thomas Rauscher said:

>Yes. This is just a *hint*. If you plan a zoom in of x2 then you need

Hi Thomas,

>the doubled tile size. Also if you use a percentage you can calculate a

>resolution for the target screen size.

I'd really appreciate a hint for the maximum recommended cubeface

size for whatever equirect is currently being used. CubicConverter

does this - in fact it limits the maximum size that it will make to

equirect width / pi. (Actually, when I just checked this it went to

two pixels larger - 2548px for an 8000px equirect - but that's

splitting hairs.)

(This is a separate issue from feedback regarding ideal cubeface size

for a specific (non-zoomed) display size. I appreciate that and I do

deliver in fixed sizes as well as scaled ones.)

Pano2VR provides no hint or warning when someone tries to push the

output beyond the input's ideal. I like the fact that the software

doesn't prohibit larger outputs (although I will endeavour never to

do it this way), but I think it would be *great* if the UI helped

keep people from overcooking their images like this.

k - fierodeval wrote, On 01.11.2008 21:59 Uhr:
> Yes, I understand. But when you speak about the "sqrt(2)", you are

Yes. correct. Because the cube faces *could* contain more information in

> speaking about the figure in the right of this image

> http://www.devalvr.com/fiero/equicube.jpg . Te correct figure is in

> the left and this figure is valid in the two directions.

>

> Then, if I understand correctly, you say that the figure for

> equirect->cube conversion is the left image and for cube->equirect is

> the right image?

the corners.

If the source was a equirectangular with 1/Pi as factor for the cube

faces size then it is safe to just use the left type of conversion again

because the pixels in corners are stretched by a factor of sqrt(2).

If the source images are cube faces, for example of a rendering from a

3D software, then you need to use the conversion on the right side to

avoid losing resolution/information.

The factor Pi*sqrt(2) would also be true if the equi->cube was executed

with a factor smaller then 1/Pi*sqrt(2) to get the maximum out of the

cube faces. Another case would be if you recover a equirectangular from

a QTVR where you don't know the original resolution.

--

MfG,

Thomas - Hi Thomas,

But, if the default value is width/4 you are using this figure:

http://www.devalvr.com/fiero/equicube2.jpg , loosing a lot of

information in the conversion.

If you take the output equirect from PTGui, all values superior to

3.14 in the divisor are loosing information in the conversion.

regards!

fiero

--- In PanoToolsNG@yahoogroups.com, Thomas Rauscher <yahoo@...> wrote:

>

> fierodeval wrote, On 01.11.2008 21:59 Uhr:

> > Yes, I understand. But when you speak about the "sqrt(2)", you are

> > speaking about the figure in the right of this image

> > http://www.devalvr.com/fiero/equicube.jpg . Te correct figure is in

> > the left and this figure is valid in the two directions.

> >

> > Then, if I understand correctly, you say that the figure for

> > equirect->cube conversion is the left image and for cube->equirect is

> > the right image?

>

> Yes. correct. Because the cube faces *could* contain more

information in

> the corners.

>

> If the source was a equirectangular with 1/Pi as factor for the cube

> faces size then it is safe to just use the left type of conversion

again

> because the pixels in corners are stretched by a factor of sqrt(2).

>

> If the source images are cube faces, for example of a rendering from a

> 3D software, then you need to use the conversion on the right side to

> avoid losing resolution/information.

>

> The factor Pi*sqrt(2) would also be true if the equi->cube was executed

> with a factor smaller then 1/Pi*sqrt(2) to get the maximum out of the

> cube faces. Another case would be if you recover a equirectangular

from

> a QTVR where you don't know the original resolution.

>

> --

> MfG,

> Thomas

>