- 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

>