Loading ...
Sorry, an error occurred while loading the content.

Re: Pano2VR makes different default cubefaces

Expand Messages
  • fierodeval
    Yes, I understand. But when you speak about the sqrt(2) , you are speaking about the figure in the right of this image
    Message 1 of 11 , Nov 1, 2008
    • 0 Attachment
      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
      >
    • Keith Martin
      ... Hi Thomas, I d really appreciate a hint for the maximum recommended cubeface size for whatever equirect is currently being used. CubicConverter does this -
      Message 2 of 11 , Nov 1, 2008
      • 0 Attachment
        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
        >the doubled tile size. Also if you use a percentage you can calculate a
        >resolution for the target screen size.

        Hi Thomas,

        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
      • Thomas Rauscher
        ... 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
        Message 3 of 11 , Nov 1, 2008
        • 0 Attachment
          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
        • fierodeval
          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
          Message 4 of 11 , Nov 2, 2008
          • 0 Attachment
            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
            >
          Your message has been successfully submitted and would be delivered to recipients shortly.