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

Re: Quest for effective high-res 360x180 VR pano distribution

Expand Messages
  • Hans
    ... I am on a 30 mbit fiber so I never see anything else than a 1 sec glimpse of the loading bar , does not matter if I go fullscreen directly or not.
    Message 1 of 27 , Jun 2, 2011
    View Source
    • 0 Attachment
      --- In PanoToolsNG@yahoogroups.com, "erik_leeman" <erik.leeman@...> wrote:
      >
      > Hi all,
      >
      > In an effort to avoid competiton by the likes of Google I'm still trying to find an efficient way to get full screen high resolution VR images on distant computers.
      >
      > My 10MB 'direct to full screen' testing didn't go down too well for some of you, especially for those on the other side of the globe, so this time I'm trying to find out if using Pano2VR's multiresolution feature is a better strategy.
      >
      > Of course a fast internet connection doesn't do much good when intercontinental routes are as congested as they apparently are (thanks YouTube & co!), so if you are based far far away from Amsterdam loading speed will remain an issue.
      > A solution to that particular problem would be to pay for the services of mirroring servers like Amazon or Akamai, but I don't think that's an option for many of us.
      >
      > For this test I am concentrating on transport and image quality only, the challenge of persuading viewers to click that full screen button will have to be dealt with some other time.
      >
      > After some experiments I settled on the following settings for Pano2VR for my Canon 5D + 15mm Fisheye equirectangulars:
      >
      > Multi resolution cube face levels: 1530 - 2550 - 3570
      > Bias: 0.35
      > Tile size: 510 with 1 px overlap (giving 512x512 pixel tiles)
      > Interpolator: Lanczos 2
      > initial pano window: 1000x540
      > initial vertical FoV: 60 degrees
      > minimum vFoV: 37.5 degrees (zoomed in)
      > maximum vFoV: 80 degrees (zoomed out)
      >
      > This works well on my 1920x1200 screen, hopefully it also does so on other screen sizes.
      >
      > Here are links to a number of test pano's treated this way:
      >
      > http://tinyurl.com/08-06-25-PodereCerale-EN
      > http://tinyurl.com/10-06-24-NovyBor-school-01-EN
      > http://tinyurl.com/10-06-30-Pacinek-1-EN
      > http://tinyurl.com/07-09-17-stServaas-EN
      > http://tinyurl.com/10-06-29-museumKamSenov-2-EN
      >
      > Please please click that full screen button, that's how they are intended to be seen!
      > Yes, there's a lot of aliasing ('shimmering'), but that's something we'll have to live with for at least the next year or two if we want sharp and highly detailed images now. For me blurring the sh*t out of them is no option.
      >
      > And no, there is no option to view them on hand held devices as this test is about high resolution work for which they are completely unsuitable.
      >
      > Feedback would be greatly appreciated.

      I am on a 30 mbit fiber so I never see anything else than a 1 sec glimpse of the loading bar , does not matter if I go fullscreen directly or not.
      Everything works perfect on my 27" iMac.

      Your first test did load just as fast.

      However I was interested in how well Pano2VR multi tiles work on Android.
      I tried it with my 3G connection which is just 1 mbit.

      Unfortunately it does not work. It loaded around 30% and then shuts off flash loading.

      Changing to WiFi and using my 30mbit connection did not help.

      With KRpano I have no problems loading 5 gigapixel panoramas which use 512x512 pixels tiles.

      I also have several of my own 28000x14000 panoramas which works perfect and on which you can zoom all the way in.

      I am not sure why Pano2VR does not work .
      Normal 6 cubefaces panos up to around 1600 with FPP does load even if they are hard to navigate.


      Hans
    • Jim Watters
      ... It worked fine on my PC but also had problem viewing on Android. I have been using Pano2VR to publish my panos recently and they work on my Android phone.
      Message 2 of 27 , Jun 2, 2011
      View Source
      • 0 Attachment
        On 2011-06-02 8:02 AM, Hans wrote:
        >
        > --- In PanoToolsNG@yahoogroups.com, "erik_leeman"<erik.leeman@...> wrote:
        >> After some experiments I settled on the following settings for Pano2VR for my Canon 5D + 15mm Fisheye equirectangulars:
        >>
        >> Multi resolution cube face levels: 1530 - 2550 - 3570
        >> Bias: 0.35
        >> Tile size: 510 with 1 px overlap (giving 512x512 pixel tiles)
        >> Interpolator: Lanczos 2
        >> initial pano window: 1000x540
        >> initial vertical FoV: 60 degrees
        >> minimum vFoV: 37.5 degrees (zoomed in)
        >> maximum vFoV: 80 degrees (zoomed out)
        >>
        >> This works well on my 1920x1200 screen, hopefully it also does so on other screen sizes.
        >>
        >> Here are links to a number of test pano's treated this way:
        >>
        >> http://tinyurl.com/08-06-25-PodereCerale-EN
        >> http://tinyurl.com/10-06-24-NovyBor-school-01-EN
        >> http://tinyurl.com/10-06-30-Pacinek-1-EN
        >> http://tinyurl.com/07-09-17-stServaas-EN
        >> http://tinyurl.com/10-06-29-museumKamSenov-2-EN
        >
        > However I was interested in how well Pano2VR multi tiles work on Android.
        >
        > Unfortunately it does not work. It loaded around 30% and then shuts off flash loading.
        >
        > With KRpano I have no problems loading 5 gigapixel panoramas which use 512x512 pixels tiles.
        >
        > I also have several of my own 28000x14000 panoramas which works perfect and on which you can zoom all the way in.
        >
        > I am not sure why Pano2VR does not work .
        > Normal 6 cubefaces panos up to around 1600 with FPP does load even if they are hard to navigate.
        >
        >
        > Hans
        It worked fine on my PC but also had problem viewing on Android.

        I have been using Pano2VR to publish my panos recently and they work on my
        Android phone.
        8400 X 4200 pano.
        Faces of 510, 1528, and 2548 with tiled to 510 with 1 pixel overlap creating
        tiles of 512x512.
        The 510 are embed in the swf file, the 1528 and 2548 are decoded at startup.
        http://photocreations.ca/camp/?Camp2011_16#Camp2011_16

        With yours, with the phone in portrait mode, and not going full screen, so it is
        only a small thumbnail size, I believe it was downloading all the faces and
        tiles. At 30% download flash would run out of memory and close. Even 1530 marked
        as Embed or Load_at_startup might be too much.

        For touchscreen devices using flash it is necessary to add zoom in/out buttons.
        I have also added a button to switch to drag mode on touchscreen devices.

        --
        Jim Watters
        http://photocreations.ca
      • Trausti Hraunfjord
        Just chiming in here with some boring facts. Hardware acceleration has been with us for 4 years already, and the future will depend much more on it that it
        Message 3 of 27 , Jun 2, 2011
        View Source
        • 0 Attachment
          Just chiming in here with some boring facts.

          Hardware acceleration has been with us for 4 years already, and the future
          will depend much more on it that it already does. The mobile devices are
          dictated by OpenGL 2 ES already, and with Flash 11, hardware acceleration
          will only kick in if standards are followed.

          It means that cubefaces/graphics have to go by the "power of two" concept
          (this is not a request, but a requirement) . The power of two means that
          graphics have to have the following dimensions:
          1/2/4/8/16/32/64/128/256/512/1024/2048/4096

          A cubeface of 510x510 will not be admitted for graphics acceleration. Nor
          will a cubeface of 2548 or an equi with dimensions of 8400x4200. The
          hardware acceleration can not and will not handle those optimally. Those
          who are still rendering their panos in sizes that are not covered by the
          power of two standards, will wake up with a headache later on, and have to
          re-render their panos in the future if they want those to be displayed in
          optimal quality with future technology.

          This goes for ALL hardware that is based on OpenGL 2 standards, and not some
          "evil Adobe plan" as some might like to think. All iDevices are already
          bound by these standards.

          So..... for preparing for the inevitable future (and the past 4 years),
          people need to start working in the power of two terms, and that will pay
          off.

          Trausti


          On Thu, Jun 2, 2011 at 10:50 AM, Jim Watters
          <jwatters@...>wrote:It worked fine on my PC but also had
          problem viewing on Android.

          >
          > I have been using Pano2VR to publish my panos recently and they work on my
          > Android phone.
          > 8400 X 4200 pano.
          > Faces of 510, 1528, and 2548 with tiled to 510 with 1 pixel overlap
          > creating
          > tiles of 512x512.
          > The 510 are embed in the swf file, the 1528 and 2548 are decoded at
          > startup.
          > http://photocreations.ca/camp/?Camp2011_16#Camp2011_16
          >
          > With yours, with the phone in portrait mode, and not going full screen, so
          > it is
          > only a small thumbnail size, I believe it was downloading all the faces and
          >
          > tiles. At 30% download flash would run out of memory and close. Even 1530
          > marked
          > as Embed or Load_at_startup might be too much.
          >
          > For touchscreen devices using flash it is necessary to add zoom in/out
          > buttons.
          > I have also added a button to switch to drag mode on touchscreen devices.
          >
          > --
          > Jim Watters
          > http://photocreations.ca
          >


          [Non-text portions of this message have been removed]
        • Roger D Williams
          Trausti, thanks for the heads up. I sometimes see people talking about not only cube-face dimensions but also a plus 1 or plus 2 margin for the seams. How
          Message 4 of 27 , Jun 2, 2011
          View Source
          • 0 Attachment
            Trausti, thanks for the heads up.

            I sometimes see people talking about not only cube-face dimensions but also a "plus 1" or "plus 2" margin for the seams. How does this affect the power of two limit? Is the extra pixel (or two pixels) inside this limit or outside it? Or is the critical dimension that of the original equirectangular image only?

            Roger W.

            Sent from my iPad

            On Jun 3, 2011, at 7:09 AM, Trausti Hraunfjord <trausti.hraunfjord@...> wrote:

            > Just chiming in here with some boring facts.
            >
            > Hardware acceleration has been with us for 4 years already, and the future
            > will depend much more on it that it already does. The mobile devices are
            > dictated by OpenGL 2 ES already, and with Flash 11, hardware acceleration
            > will only kick in if standards are followed.
            >
            > It means that cubefaces/graphics have to go by the "power of two" concept
            > (this is not a request, but a requirement) . The power of two means that
            > graphics have to have the following dimensions:
            > 1/2/4/8/16/32/64/128/256/512/1024/2048/4096
          • Trausti Hraunfjord
            The limit is very strict, so an extra pixel for overlapping will render the image useless for hardware acceleration. I can t speak for different players apart
            Message 5 of 27 , Jun 2, 2011
            View Source
            • 0 Attachment
              The limit is very strict, so an extra pixel for overlapping will render the
              image useless for hardware acceleration.

              I can't speak for different players apart from Flash, but in the case of
              Flash 11, there will be absolutely no need for an extra pixel added to
              cubefaces in order to try and avoid a seam opening up. F11 will
              automatically keep things correctly aligned.
              The need for an extra pixel for overlaps is based on bad math that needs to
              be "saved", and it has not been a real problem until now, but that seems to
              be about to change.

              Trausti



              On Thu, Jun 2, 2011 at 6:05 PM, Roger D Williams <roger@...>wrote:

              >
              >
              > Trausti, thanks for the heads up.
              >
              > I sometimes see people talking about not only cube-face dimensions but also
              > a "plus 1" or "plus 2" margin for the seams. How does this affect the power
              > of two limit? Is the extra pixel (or two pixels) inside this limit or
              > outside it? Or is the critical dimension that of the original
              > equirectangular image only?
              >
              > Roger W.
              >
              > Sent from my iPad
              >
              >
              > On Jun 3, 2011, at 7:09 AM, Trausti Hraunfjord <
              > trausti.hraunfjord@...> wrote:
              >
              > > Just chiming in here with some boring facts.
              > >
              > > Hardware acceleration has been with us for 4 years already, and the
              > future
              > > will depend much more on it that it already does. The mobile devices are
              > > dictated by OpenGL 2 ES already, and with Flash 11, hardware acceleration
              > > will only kick in if standards are followed.
              > >
              > > It means that cubefaces/graphics have to go by the "power of two" concept
              > > (this is not a request, but a requirement) . The power of two means that
              > > graphics have to have the following dimensions:
              > > 1/2/4/8/16/32/64/128/256/512/1024/2048/4096
              >


              [Non-text portions of this message have been removed]
            • erik_leeman
              Thank you Trausti. May I remind you that the tiles I used for this test were 512x512 pixels? That was not by accident. Pano2VR can make 510x510 tiles with an
              Message 6 of 27 , Jun 2, 2011
              View Source
              • 0 Attachment
                Thank you Trausti.
                May I remind you that the tiles I used for this test were 512x512 pixels? That was not by accident.

                Pano2VR can make 510x510 tiles with an overlap of 1 pixels all around.
                Width: 1+510+1=512 Height: ditto, 512x512.
                So I chose multiples of 510 (1530-2550-3570) for my cube face levels.
                The 1530 level is embedded in the .swf, the others are (pre)loaded separately.

                My initial test had many more levels, 510-1020-1530-2040-2550-3060-3570, but I found that in both a window of 1000x540 and full screen on my 1920x1200 monitor only three levels were actually used with a bias setting of 0.35, so I threw out all the unused ones.

                I tried to make it clear from the start that I am NOT interested in displaying VR panoramas on mobile devices. ANYONE (well, almost anyone) can make panos for those postage-stamp sized screens, you can even do it using the device itself! There is absolutely no way we can ever compete on that level with companies like Google, forget it!

                What I AM interested in is distributing and displaying interactive 360x180 images that are NOT easy to make, special-purpose VR panos with a level of detail and image quality that require a BIG screen. That is what this thread was intended to be about.

                Cheers!

                Erik Leeman

                <http://www.flickr.com/photos/erik-nl/> <http://www.erikleeman.com/>

                --- In PanoToolsNG@yahoogroups.com, Trausti Hraunfjord wrote:
                >
                > Just chiming in here with some boring facts.
                >
                > Hardware acceleration has been with us for 4 years already, and the
                > future will depend much more on it that it already does. The mobile
                > devices are dictated by OpenGL 2 ES already, and with Flash 11,
                > hardware acceleration will only kick in if standards are followed.
                >
                > It means that cubefaces/graphics have to go by the "power of two"
                > concept (this is not a request, but a requirement). The power of
                > two means that graphics have to have the following dimensions:
                > 1/2/4/8/16/32/64/128/256/512/1024/2048/4096
                >
                > A cubeface of 510x510 will not be admitted for graphics
                > acceleration. Nor will a cubeface of 2548 or an equi with
                > dimensions of 8400x4200. The hardware acceleration can not and will
                > not handle those optimally. Those who are still rendering their
                > panos in sizes that are not covered by the power of two standards,
                > will wake up with a headache later on, and have to
                > re-render their panos in the future if they want those to be
                > displayed in optimal quality with future technology.
                >
                > This goes for ALL hardware that is based on OpenGL 2 standards, and
                > not some "evil Adobe plan" as some might like to think. All
                > iDevices are already bound by these standards.
                >
                > So..... for preparing for the inevitable future (and the past 4
                > years), people need to start working in the power of two terms, and
                > that will pay off.
                >
                > Trausti
              • Trausti Hraunfjord
                Sorry if I may have taken this a bit off track, that was not the intent. I am quite interested in your projects... even when I may come across as grumpy...
                Message 7 of 27 , Jun 2, 2011
                View Source
                • 0 Attachment
                  Sorry if I may have taken this a bit off track, that was not the intent. I
                  am quite interested in your projects... even when I may come across as
                  grumpy... that's just how I am... the loader issue I addressed earlier is
                  however a real issue for slower connections such as the one I am forced to
                  use (there is nothing faster and more stable available in the country than
                  what I have). I do look forward to better speeds world wide, a future where
                  we don't have to reduce image quality/size in order to meet low speed
                  comnections.

                  Back on track, and I hope the info I put up will be of some use for others.

                  Trausti

                  On Thu, Jun 2, 2011 at 6:24 PM, erik_leeman <erik.leeman@...> wrote:

                  >
                  >
                  > Thank you Trausti.
                  > May I remind you that the tiles I used for this test were 512x512 pixels?
                  > That was not by accident.
                  >
                  > Pano2VR can make 510x510 tiles with an overlap of 1 pixels all around.
                  > Width: 1+510+1=512 Height: ditto, 512x512.
                  > So I chose multiples of 510 (1530-2550-3570) for my cube face levels.
                  > The 1530 level is embedded in the .swf, the others are (pre)loaded
                  > separately.
                  >
                  > My initial test had many more levels, 510-1020-1530-2040-2550-3060-3570,
                  > but I found that in both a window of 1000x540 and full screen on my
                  > 1920x1200 monitor only three levels were actually used with a bias setting
                  > of 0.35, so I threw out all the unused ones.
                  >
                  > I tried to make it clear from the start that I am NOT interested in
                  > displaying VR panoramas on mobile devices. ANYONE (well, almost anyone) can
                  > make panos for those postage-stamp sized screens, you can even do it using
                  > the device itself! There is absolutely no way we can ever compete on that
                  > level with companies like Google, forget it!
                  >
                  > What I AM interested in is distributing and displaying interactive 360x180
                  > images that are NOT easy to make, special-purpose VR panos with a level of
                  > detail and image quality that require a BIG screen. That is what this thread
                  > was intended to be about.
                  >
                  >
                  > Cheers!
                  >
                  > Erik Leeman
                  >
                  > <http://www.flickr.com/photos/erik-nl/> <http://www.erikleeman.com/>
                  >
                  > --- In PanoToolsNG@yahoogroups.com, Trausti Hraunfjord wrote:
                  > >
                  > > Just chiming in here with some boring facts.
                  > >
                  > > Hardware acceleration has been with us for 4 years already, and the
                  > > future will depend much more on it that it already does. The mobile
                  > > devices are dictated by OpenGL 2 ES already, and with Flash 11,
                  > > hardware acceleration will only kick in if standards are followed.
                  > >
                  > > It means that cubefaces/graphics have to go by the "power of two"
                  > > concept (this is not a request, but a requirement). The power of
                  > > two means that graphics have to have the following dimensions:
                  > > 1/2/4/8/16/32/64/128/256/512/1024/2048/4096
                  > >
                  > > A cubeface of 510x510 will not be admitted for graphics
                  > > acceleration. Nor will a cubeface of 2548 or an equi with
                  > > dimensions of 8400x4200. The hardware acceleration can not and will
                  > > not handle those optimally. Those who are still rendering their
                  > > panos in sizes that are not covered by the power of two standards,
                  > > will wake up with a headache later on, and have to
                  > > re-render their panos in the future if they want those to be
                  > > displayed in optimal quality with future technology.
                  > >
                  > > This goes for ALL hardware that is based on OpenGL 2 standards, and
                  > > not some "evil Adobe plan" as some might like to think. All
                  > > iDevices are already bound by these standards.
                  > >
                  > > So..... for preparing for the inevitable future (and the past 4
                  > > years), people need to start working in the power of two terms, and
                  > > that will pay off.
                  > >
                  > > Trausti
                  >
                  >
                  >


                  [Non-text portions of this message have been removed]
                • Ken Warner
                  Erik, I understand the need for sizes of textures to be a power of two. I won t go into the technical details here because I probably wouldn t get it right
                  Message 8 of 27 , Jun 2, 2011
                  View Source
                  • 0 Attachment
                    Erik,

                    I understand the need for sizes of textures to be a power of two.
                    I won't go into the technical details here because I probably wouldn't
                    get it right with the current graphics cards being so advanced.

                    But I have a question and need clarification.

                    A one pixel overlap on a 510x510 tile will give you 512x512
                    tiles. However, a multiple of 510 will give more than 1 pixel overlap

                    512; 1024; 1536; 2048 etc. are the multiples of two. So you want
                    1534 to give you a one pixel overlap not 1530 --- and same for other
                    multiples. The multiples are of (for example)512 - 2 = 510 to get the tile
                    size right or 2048 - 2 = 2046 etc.

                    Am I wrong?

                    erik_leeman wrote:
                    > Thank you Trausti.
                    > May I remind you that the tiles I used for this test were 512x512 pixels? That was not by accident.
                    >
                    > Pano2VR can make 510x510 tiles with an overlap of 1 pixels all around.
                    > Width: 1+510+1=512 Height: ditto, 512x512.
                    > So I chose multiples of 510 (1530-2550-3570) for my cube face levels.
                    > The 1530 level is embedded in the .swf, the others are (pre)loaded separately.
                    >
                  • Sacha Griffin
                    What happened with the thread 6 weeks ago apparently debunking this whole idea? I admit I didn t pay much attention but still.... Sacha Griffin Southern
                    Message 9 of 27 , Jun 2, 2011
                    View Source
                    • 0 Attachment
                      What happened with the thread 6 weeks ago apparently debunking this whole
                      idea? I admit I didn't pay much attention but still....

                      Sacha Griffin
                      Southern Digital Solutions LLC - Atlanta, Georgia
                      http://www.seeit360.net
                      http://twitter.com/SeeIt360
                      http://www.facebook.com/panoramas/
                      IM: sachagriffin007@...
                      Office: 404-551-4275
                      GV: 404-665-9990


                      On Jun 2, 2011, at 8:58 PM, Ken Warner <kwarner000@...> wrote:



                      Erik,

                      I understand the need for sizes of textures to be a power of two.
                      I won't go into the technical details here because I probably wouldn't
                      get it right with the current graphics cards being so advanced.

                      But I have a question and need clarification.

                      A one pixel overlap on a 510x510 tile will give you 512x512
                      tiles. However, a multiple of 510 will give more than 1 pixel overlap

                      512; 1024; 1536; 2048 etc. are the multiples of two. So you want
                      1534 to give you a one pixel overlap not 1530 --- and same for other
                      multiples. The multiples are of (for example)512 - 2 = 510 to get the tile
                      size right or 2048 - 2 = 2046 etc.

                      Am I wrong?

                      erik_leeman wrote:
                      > Thank you Trausti.
                      > May I remind you that the tiles I used for this test were 512x512 pixels?
                      That was not by accident.
                      >
                      > Pano2VR can make 510x510 tiles with an overlap of 1 pixels all around.
                      > Width: 1+510+1=512 Height: ditto, 512x512.
                      > So I chose multiples of 510 (1530-2550-3570) for my cube face levels.
                      > The 1530 level is embedded in the .swf, the others are (pre)loaded
                      separately.
                      >



                      [Non-text portions of this message have been removed]
                    • Ken Warner
                      I think the first thread was about the affect of powers of two on image quality which is (in my opinion) a non issue. But this is about efficiency and hardware
                      Message 10 of 27 , Jun 2, 2011
                      View Source
                      • 0 Attachment
                        I think the first thread was about the affect of powers of two on image quality
                        which is (in my opinion) a non issue.

                        But this is about efficiency and hardware acceleration and OpenGL textures
                        and powers of two which (I think) do bear on efficiency because of the way
                        blocks of memory (image buffers) are moved around. I could be wrong.

                        Sacha Griffin wrote:
                        > What happened with the thread 6 weeks ago apparently debunking this whole
                        > idea? I admit I didn't pay much attention but still....
                        >
                        > Sacha Griffin
                        > Southern Digital Solutions LLC - Atlanta, Georgia
                        > http://www.seeit360.net
                        > http://twitter.com/SeeIt360
                        > http://www.facebook.com/panoramas/
                        > IM: sachagriffin007@...
                        > Office: 404-551-4275
                        > GV: 404-665-9990
                        >
                        >
                        > On Jun 2, 2011, at 8:58 PM, Ken Warner <kwarner000@...> wrote:
                        >
                        >
                        >
                        > Erik,
                        >
                        > I understand the need for sizes of textures to be a power of two.
                        > I won't go into the technical details here because I probably wouldn't
                        > get it right with the current graphics cards being so advanced.
                        >
                        > But I have a question and need clarification.
                        >
                        > A one pixel overlap on a 510x510 tile will give you 512x512
                        > tiles. However, a multiple of 510 will give more than 1 pixel overlap
                        >
                        > 512; 1024; 1536; 2048 etc. are the multiples of two. So you want
                        > 1534 to give you a one pixel overlap not 1530 --- and same for other
                        > multiples. The multiples are of (for example)512 - 2 = 510 to get the tile
                        > size right or 2048 - 2 = 2046 etc.
                        >
                        > Am I wrong?
                        >
                        > erik_leeman wrote:
                        >> Thank you Trausti.
                        >> May I remind you that the tiles I used for this test were 512x512 pixels?
                        > That was not by accident.
                        >> Pano2VR can make 510x510 tiles with an overlap of 1 pixels all around.
                        >> Width: 1+510+1=512 Height: ditto, 512x512.
                        >> So I chose multiples of 510 (1530-2550-3570) for my cube face levels.
                        >> The 1530 level is embedded in the .swf, the others are (pre)loaded
                        > separately.
                        >
                        >
                        >
                        > [Non-text portions of this message have been removed]
                        >
                        >
                        >
                        > ------------------------------------
                        >
                      • Hans
                        ... Erik, Android is by no means just miniscreens, there are dozens of tablets in different sizes on the way and they all use pretty small processors. In
                        Message 11 of 27 , Jun 2, 2011
                        View Source
                        • 0 Attachment
                          --- In PanoToolsNG@yahoogroups.com, "erik_leeman" <erik.leeman@...> wrote:
                          >
                          > Thank you Trausti.
                          > May I remind you that the tiles I used for this test were 512x512 pixels? That was not by accident.
                          >
                          > Pano2VR can make 510x510 tiles with an overlap of 1 pixels all around.
                          > Width: 1+510+1=512 Height: ditto, 512x512.
                          > So I chose multiples of 510 (1530-2550-3570) for my cube face levels.
                          > The 1530 level is embedded in the .swf, the others are (pre)loaded separately.
                          >
                          > My initial test had many more levels, 510-1020-1530-2040-2550-3060-3570, but I found that in both a window of 1000x540 and full screen on my 1920x1200 monitor only three levels were actually used with a bias setting of 0.35, so I threw out all the unused ones.
                          >
                          > I tried to make it clear from the start that I am NOT interested in displaying VR panoramas on mobile devices. ANYONE (well, almost anyone) can make panos for those postage-stamp sized screens, you can even do it using the device itself! There is absolutely no way we can ever compete on that level with companies like Google, forget it!
                          >


                          Erik,
                          Android is by no means just miniscreens, there are dozens of tablets in different sizes on the way and they all use pretty small processors. In addition we also have TVs with internet and Android coming.

                          So you have to look forward unless you want to change it all at some time. As far as I remember you was also one of the first here with an iPad which you highly prised.

                          Hans



                          > What I AM interested in is distributing and displaying interactive 360x180 images that are NOT easy to make, special-purpose VR panos with a level of detail and image quality that require a BIG screen. That is what this thread was intended to be about.
                          >
                          > Cheers!
                          >
                          > Erik Leeman
                          >
                          > <http://www.flickr.com/photos/erik-nl/> <http://www.erikleeman.com/>
                          >
                          > --- In PanoToolsNG@yahoogroups.com, Trausti Hraunfjord wrote:
                          > >
                          > > Just chiming in here with some boring facts.
                          > >
                          > > Hardware acceleration has been with us for 4 years already, and the
                          > > future will depend much more on it that it already does. The mobile
                          > > devices are dictated by OpenGL 2 ES already, and with Flash 11,
                          > > hardware acceleration will only kick in if standards are followed.
                          > >
                          > > It means that cubefaces/graphics have to go by the "power of two"
                          > > concept (this is not a request, but a requirement). The power of
                          > > two means that graphics have to have the following dimensions:
                          > > 1/2/4/8/16/32/64/128/256/512/1024/2048/4096
                          > >
                          > > A cubeface of 510x510 will not be admitted for graphics
                          > > acceleration. Nor will a cubeface of 2548 or an equi with
                          > > dimensions of 8400x4200. The hardware acceleration can not and will
                          > > not handle those optimally. Those who are still rendering their
                          > > panos in sizes that are not covered by the power of two standards,
                          > > will wake up with a headache later on, and have to
                          > > re-render their panos in the future if they want those to be
                          > > displayed in optimal quality with future technology.
                          > >
                          > > This goes for ALL hardware that is based on OpenGL 2 standards, and
                          > > not some "evil Adobe plan" as some might like to think. All
                          > > iDevices are already bound by these standards.
                          > >
                          > > So..... for preparing for the inevitable future (and the past 4
                          > > years), people need to start working in the power of two terms, and
                          > > that will pay off.
                          > >
                          > > Trausti
                          >
                        • Hans
                          ... I have to say that this Pano2VR extra pixels idea seems to be his own. He used it also for Quicktime and I never understood why. There is no reason for
                          Message 12 of 27 , Jun 3, 2011
                          View Source
                          • 0 Attachment
                            --- In PanoToolsNG@yahoogroups.com, Trausti Hraunfjord <trausti.hraunfjord@...> wrote:
                            >
                            > The limit is very strict, so an extra pixel for overlapping will render the
                            > image useless for hardware acceleration.
                            >
                            > I can't speak for different players apart from Flash, but in the case of
                            > Flash 11, there will be absolutely no need for an extra pixel added to
                            > cubefaces in order to try and avoid a seam opening up. F11 will
                            > automatically keep things correctly aligned.
                            > The need for an extra pixel for overlaps is based on bad math that needs to
                            > be "saved", and it has not been a real problem until now, but that seems to
                            > be about to change.



                            I have to say that this Pano2VR extra pixels idea seems to be his own. He used it also for Quicktime and I never understood why. There is no reason for it.

                            Someone else explained it more technically some time ago.

                            Hans




                            >
                            > Trausti
                            >
                            >
                            >
                            > On Thu, Jun 2, 2011 at 6:05 PM, Roger D Williams <roger@...>wrote:
                            >
                            > >
                            > >
                            > > Trausti, thanks for the heads up.
                            > >
                            > > I sometimes see people talking about not only cube-face dimensions but also
                            > > a "plus 1" or "plus 2" margin for the seams. How does this affect the power
                            > > of two limit? Is the extra pixel (or two pixels) inside this limit or
                            > > outside it? Or is the critical dimension that of the original
                            > > equirectangular image only?
                            > >
                            > > Roger W.
                            > >
                            > > Sent from my iPad
                            > >
                            > >
                            > > On Jun 3, 2011, at 7:09 AM, Trausti Hraunfjord <
                            > > trausti.hraunfjord@...> wrote:
                            > >
                            > > > Just chiming in here with some boring facts.
                            > > >
                            > > > Hardware acceleration has been with us for 4 years already, and the
                            > > future
                            > > > will depend much more on it that it already does. The mobile devices are
                            > > > dictated by OpenGL 2 ES already, and with Flash 11, hardware acceleration
                            > > > will only kick in if standards are followed.
                            > > >
                            > > > It means that cubefaces/graphics have to go by the "power of two" concept
                            > > > (this is not a request, but a requirement) . The power of two means that
                            > > > graphics have to have the following dimensions:
                            > > > 1/2/4/8/16/32/64/128/256/512/1024/2048/4096
                            > >
                            >
                            >
                            > [Non-text portions of this message have been removed]
                            >
                          • tom_a_sparks
                            ... the reason, is the texture maps are created in wraparound memory When Bilinear filtering is used some poorly coded versions are not clamped to the texture
                            Message 13 of 27 , Jun 3, 2011
                            View Source
                            • 0 Attachment
                              --- In PanoToolsNG@yahoogroups.com, "Hans" <hans@...> wrote:
                              >
                              >
                              >
                              > --- In PanoToolsNG@yahoogroups.com, Trausti Hraunfjord <trausti.hraunfjord@> wrote:
                              > >
                              > > The limit is very strict, so an extra pixel for overlapping will render the
                              > > image useless for hardware acceleration.
                              > >
                              > > I can't speak for different players apart from Flash, but in the case of
                              > > Flash 11, there will be absolutely no need for an extra pixel added to
                              > > cubefaces in order to try and avoid a seam opening up. F11 will
                              > > automatically keep things correctly aligned.
                              > > The need for an extra pixel for overlaps is based on bad math that needs to
                              > > be "saved", and it has not been a real problem until now, but that seems to
                              > > be about to change.
                              >
                              >
                              >
                              > I have to say that this Pano2VR extra pixels idea seems to be his own. He used it also for Quicktime and I never understood why. There is no reason for it.
                              >
                              > Someone else explained it more technically some time ago.
                              >

                              the reason, is the texture maps are created in wraparound memory
                              When Bilinear filtering is used some poorly coded versions are not clamped to the texture map size, and access other sides of the texture map

                              some information about bilinear filtering http://en.wikipedia.org/wiki/Bilinear_filtering



                              > Hans
                              >
                              >
                              >
                              >
                              > >
                              > > Trausti
                              > >
                              > >
                              > >
                              > > On Thu, Jun 2, 2011 at 6:05 PM, Roger D Williams <roger@>wrote:
                              > >
                              > > >
                              > > >
                              > > > Trausti, thanks for the heads up.
                              > > >
                              > > > I sometimes see people talking about not only cube-face dimensions but also
                              > > > a "plus 1" or "plus 2" margin for the seams. How does this affect the power
                              > > > of two limit? Is the extra pixel (or two pixels) inside this limit or
                              > > > outside it? Or is the critical dimension that of the original
                              > > > equirectangular image only?
                              > > >
                              > > > Roger W.
                              > > >
                              > > > Sent from my iPad
                              > > >
                              > > >
                              > > > On Jun 3, 2011, at 7:09 AM, Trausti Hraunfjord <
                              > > > trausti.hraunfjord@> wrote:
                              > > >
                              > > > > Just chiming in here with some boring facts.
                              > > > >
                              > > > > Hardware acceleration has been with us for 4 years already, and the
                              > > > future
                              > > > > will depend much more on it that it already does. The mobile devices are
                              > > > > dictated by OpenGL 2 ES already, and with Flash 11, hardware acceleration
                              > > > > will only kick in if standards are followed.
                              > > > >
                              > > > > It means that cubefaces/graphics have to go by the "power of two" concept
                              > > > > (this is not a request, but a requirement) . The power of two means that
                              > > > > graphics have to have the following dimensions:
                              > > > > 1/2/4/8/16/32/64/128/256/512/1024/2048/4096
                              > > >
                              > >
                              > >
                              > > [Non-text portions of this message have been removed]
                              > >
                              >
                            • erik_leeman
                              Hans, For me TVs with internet capability do NOT fall into the portable device category, and they are MOST welcome in the context of this thread! I have no
                              Message 14 of 27 , Jun 3, 2011
                              View Source
                              • 0 Attachment
                                Hans,
                                For me TVs with internet capability do NOT fall into the 'portable device' category, and they are MOST welcome in the context of this thread! I have no doubt whatsoever that BIG screen devices running on (a special version of) Android will be able to handle content that is scaled accordingly, and I am sure they will be perfectly capable to show high resolution interactive panoramas.

                                Displaying interactive LOW RES panos on handheld devices is hardly a challenge, and ANYONE can produce reasonably acceptable content for them. I simply cannot generate the sheer volume that is necessary to survive in that segment, so I lost whatever interest I had in it.

                                My enthusiasm for the iPad was for a specific reason: finally I had instant access to my interactive panoramas during a (casual) conversation. For me that still is its ultimate purpose.
                                But as you might ALSO remember I was also one of the first to notice, and then sharply criticize its inability to use that wonderful screen to its full potential.

                                Handheld (or stationary) devices with screens of 1024x768 pixels and smaller are NOT what I aim for. I have no hesitation to make my work available for them, but priority it has not.

                                Erik Leeman

                                <http://www.flickr.com/photos/erik-nl/> <http://www.erikleeman.com/>

                                --- In PanoToolsNG@yahoogroups.com, "Hans" wrote:

                                > Erik,
                                > Android is by no means just miniscreens, there are dozens of tablets
                                > in different sizes on the way and they all use pretty small
                                > processors. In addition we also have TVs with internet and Android
                                > coming.
                                >
                                > So you have to look forward unless you want to change it all at some
                                > time. As far as I remember you was also one of the first here with
                                > an iPad which you highly prised.
                                >
                                > Hans
                              • erik_leeman
                                Hi Ken, I think you are confusing tiles and cube faces here. In this Pano2VR context tiles are the building blocks of a multi resolution panorama. They are
                                Message 15 of 27 , Jun 3, 2011
                                View Source
                                • 0 Attachment
                                  Hi Ken,

                                  I think you are confusing tiles and cube faces here.
                                  In this Pano2VR context tiles are the 'building blocks' of a multi resolution panorama. They are the .jpeg files that have to be shoveled in and out of the graphics engine in large numbers. Inside that graphics engine there is, as I understand it, one big soup of data, in which those cube faces do not really exist as such, they are abstract entities. Therefore I think their dimensions are not relevant, as long as they completely fit into the available amount of memory. But I could be wrong of course.
                                  The dimensions of those individual .jpegs on the other hand does matter. Not only for logistic purposes, but also for the efficiency of the JPEG compression algorithm. I do not have a link to solid information about this at hand, but what I remember is that you have to limit bitmap dimensions to multiples of 16x16 pixels because JPEG compression works best that way. 512x512 complies nicely to that requirement.

                                  Selecting cubefaces from a range of 510-1020-1530-2040-2550-3060-3570 in the Multiresolution tab of Pano2VR, a tile size of 510, AND an overlap of 1 pixel for each tile seems to me to be the way to 'get it right'. But again, I could be wrong.

                                  Cheers!

                                  Erik Leeman

                                  <http://www.flickr.com/photos/erik-nl/> <http://www.erikleeman.com/>

                                  --- In PanoToolsNG@yahoogroups.com, Ken Warner wrote:
                                  >
                                  > Erik,
                                  >
                                  > I understand the need for sizes of textures to be a power of two.
                                  > I won't go into the technical details here because I probably
                                  > wouldn't get it right with the current graphics cards being so
                                  > advanced.
                                  >
                                  > But I have a question and need clarification.
                                  >
                                  > A one pixel overlap on a 510x510 tile will give you 512x512
                                  > tiles. However, a multiple of 510 will give more than 1 pixel
                                  > overlap
                                  >
                                  > 512; 1024; 1536; 2048 etc. are the multiples of two. So you want
                                  > 1534 to give you a one pixel overlap not 1530 --- and same for
                                  > other multiples. The multiples are of (for example)512 - 2 = 510 to
                                  > get the tile size right or 2048 - 2 = 2046 etc.
                                  >
                                  > Am I wrong?
                                • Hans
                                  ... Well, If you exchange the iPad to one of the newer Android tablets and use KRPano you can. They should work just as well as my 3.7 Desire Z which has no
                                  Message 16 of 27 , Jun 3, 2011
                                  View Source
                                  • 0 Attachment
                                    --- In PanoToolsNG@yahoogroups.com, "erik_leeman" <erik.leeman@...> wrote:
                                    >
                                    > Hans,
                                    > For me TVs with internet capability do NOT fall into the 'portable device' category, and they are MOST welcome in the context of this thread! I have no doubt whatsoever that BIG screen devices running on (a special version of) Android will be able to handle content that is scaled accordingly, and I am sure they will be perfectly capable to show high resolution interactive panoramas.
                                    >
                                    > Displaying interactive LOW RES panos on handheld devices is hardly a challenge, and ANYONE can produce reasonably acceptable content for them. I simply cannot generate the sheer volume that is necessary to survive in that segment, so I lost whatever interest I had in it.
                                    >
                                    > My enthusiasm for the iPad was for a specific reason: finally I had instant access to my interactive panoramas during a (casual) conversation. For me that still is its ultimate purpose.
                                    > But as you might ALSO remember I was also one of the first to notice, and then sharply criticize its inability to use that wonderful screen to its full potential.

                                    Well,
                                    If you exchange the iPad to one of the newer Android tablets and use KRPano you can.
                                    They should work just as well as my 3.7" Desire Z which has no problems with even 5 gigapixel panos as long as you supply the zoom navigation buttons for it.

                                    I like my iPad very much also but it has limits which Apple or HTML5 never will change.

                                    Hans

                                    >
                                    > Handheld (or stationary) devices with screens of 1024x768 pixels and smaller are NOT what I aim for. I have no hesitation to make my work available for them, but priority it has not.
                                    >
                                    > Erik Leeman
                                    >
                                    > <http://www.flickr.com/photos/erik-nl/> <http://www.erikleeman.com/>
                                    >
                                    > --- In PanoToolsNG@yahoogroups.com, "Hans" wrote:
                                    >
                                    > > Erik,
                                    > > Android is by no means just miniscreens, there are dozens of tablets
                                    > > in different sizes on the way and they all use pretty small
                                    > > processors. In addition we also have TVs with internet and Android
                                    > > coming.
                                    > >
                                    > > So you have to look forward unless you want to change it all at some
                                    > > time. As far as I remember you was also one of the first here with
                                    > > an iPad which you highly prised.
                                    > >
                                    > > Hans
                                    >
                                  • Ken Warner
                                    Hi Erik, Yes, I understand the jpeg compression block thing. I thought it was 8x8 but no matter. 512 is a handy size for lots of memory management issues as
                                    Message 17 of 27 , Jun 3, 2011
                                    View Source
                                    • 0 Attachment
                                      Hi Erik,

                                      Yes, I understand the jpeg compression block thing. I thought it
                                      was 8x8 but no matter. 512 is a handy size for lots of memory management
                                      issues as is 1024.

                                      I also don't have a clue as to what is going on deep inside the rendering
                                      engine. It would be nice to know more about that and if you really have
                                      to have overlap for every 512 (or 510) block of memory or just for
                                      the whole cube face.

                                      I remember once an experiment I did with OpenGL and WebGL putting together
                                      6 cube faces. I got visible seams on the edges but nowhere else. Someone
                                      suggested a particular parameter for one of the OpenGL functions that
                                      blended the seams. I forget the details now.

                                      erik_leeman wrote:
                                      > Hi Ken,
                                      >
                                      > I think you are confusing tiles and cube faces here.
                                      > In this Pano2VR context tiles are the 'building blocks' of a multi resolution panorama. They are the .jpeg files that have to be shoveled in and out of the graphics engine in large numbers. Inside that graphics engine there is, as I understand it, one big soup of data, in which those cube faces do not really exist as such, they are abstract entities. Therefore I think their dimensions are not relevant, as long as they completely fit into the available amount of memory. But I could be wrong of course.
                                      > The dimensions of those individual .jpegs on the other hand does matter. Not only for logistic purposes, but also for the efficiency of the JPEG compression algorithm. I do not have a link to solid information about this at hand, but what I remember is that you have to limit bitmap dimensions to multiples of 16x16 pixels because JPEG compression works best that way. 512x512 complies nicely to that requirement.
                                      >
                                      > Selecting cubefaces from a range of 510-1020-1530-2040-2550-3060-3570 in the Multiresolution tab of Pano2VR, a tile size of 510, AND an overlap of 1 pixel for each tile seems to me to be the way to 'get it right'. But again, I could be wrong.
                                      >
                                      > Cheers!
                                      >
                                      > Erik Leeman
                                      >
                                      > <http://www.flickr.com/photos/erik-nl/> <http://www.erikleeman.com/>
                                      >
                                      > --- In PanoToolsNG@yahoogroups.com, Ken Warner wrote:
                                      >> Erik,
                                      >>
                                      >> I understand the need for sizes of textures to be a power of two.
                                      >> I won't go into the technical details here because I probably
                                      >> wouldn't get it right with the current graphics cards being so
                                      >> advanced.
                                      >>
                                      >> But I have a question and need clarification.
                                      >>
                                      >> A one pixel overlap on a 510x510 tile will give you 512x512
                                      >> tiles. However, a multiple of 510 will give more than 1 pixel
                                      >> overlap
                                      >>
                                      >> 512; 1024; 1536; 2048 etc. are the multiples of two. So you want
                                      >> 1534 to give you a one pixel overlap not 1530 --- and same for
                                      >> other multiples. The multiples are of (for example)512 - 2 = 510 to
                                      >> get the tile size right or 2048 - 2 = 2046 etc.
                                      >>
                                      >> Am I wrong?
                                      >
                                      >
                                    • Erik Krause
                                      ... [...] ... Do you have a source for this claim? According to Nvidia documentation (PDF): http://tinyurl.com/5s47pnz Previously core OpenGL required texture
                                      Message 18 of 27 , Jun 7, 2011
                                      View Source
                                      • 0 Attachment
                                        Am 03.06.2011 00:09, schrieb Trausti Hraunfjord:
                                        > It means that cubefaces/graphics have to go by the "power of two" concept
                                        > (this is not a request, but a requirement) . The power of two means that
                                        > graphics have to have the following dimensions:
                                        > 1/2/4/8/16/32/64/128/256/512/1024/2048/4096
                                        >
                                        [...]
                                        >
                                        > This goes for ALL hardware that is based on OpenGL 2 standards, and not some
                                        > "evil Adobe plan" as some might like to think. All iDevices are already
                                        > bound by these standards.

                                        Do you have a source for this claim? According to Nvidia documentation
                                        (PDF): http://tinyurl.com/5s47pnz "Previously core OpenGL required
                                        texture images (not including border texels) to be a power-of-two size
                                        in width, height, and depth. OpenGL 2.0 allows arbitrary sizes for
                                        width, height, and depth"

                                        Regarding Flash hardware acceleration Adobe writes in
                                        http://tinyurl.com/3qssbwz "Your bitmap dimensions do not have to be a
                                        power of two, but the more iterations over which they can be evenly
                                        divided, the better."

                                        However, if I understand
                                        http://www.khronos.org/webgl/wiki/WebGL_and_OpenGL_Differences
                                        correctly, non-power-of-two textures can't be mip-mapped in OpenGL and
                                        WebGL, which indeed would be a drawback. But the page also describes a
                                        mechanism how to work around this limitation...

                                        --
                                        Erik Krause
                                        http://www.erik-krause.de
                                      • Trausti Hraunfjord
                                        I am the source of the claim. You can read other sources with different claims, such as the ones you have provided. Here is one that deals with the issue
                                        Message 19 of 27 , Jun 7, 2011
                                        View Source
                                        • 0 Attachment
                                          I am the source of the claim.

                                          You can read other sources with different claims, such as the ones you have
                                          provided. Here is one that deals with the issue based on mipmapping, which
                                          is the way our F11 based panorama engine handles things.
                                          http://gamedev.stackexchange.com/questions/7927/why-would-you-use-textures-that-are-not-a-power-of-2
                                          Of course there exist workarounds, and some workarounds may be quite ok, but
                                          still, the best way to do things, is the right way.

                                          Probably I was too general in my claim, but since I am not an expert, nor a
                                          rocket scientist or a math genius, I only claimed what I thought to be
                                          absolutely true. More knowledge doesn't hurt, and I have read a little more
                                          about the subject. My previous knowledge comes from my programmer:

                                          I asked: So it will not be possible to use cubefaces that are 2500x2500
                                          pixels?
                                          He answered: No. Mipmapping for the GPU requires the power of two sizes.

                                          There was more, but from that I based my claim.

                                          Trausti



                                          On Tue, Jun 7, 2011 at 2:26 AM, Erik Krause <erik.krause@...> wrote:

                                          > Am 03.06.2011 00:09, schrieb Trausti Hraunfjord:
                                          > > It means that cubefaces/graphics have to go by the "power of two" concept
                                          > > (this is not a request, but a requirement) . The power of two means that
                                          > > graphics have to have the following dimensions:
                                          > > 1/2/4/8/16/32/64/128/256/512/1024/2048/4096
                                          > >
                                          > [...]
                                          > >
                                          > > This goes for ALL hardware that is based on OpenGL 2 standards, and not
                                          > some
                                          > > "evil Adobe plan" as some might like to think. All iDevices are already
                                          > > bound by these standards.
                                          >
                                          > Do you have a source for this claim? According to Nvidia documentation
                                          > (PDF): http://tinyurl.com/5s47pnz "Previously core OpenGL required
                                          > texture images (not including border texels) to be a power-of-two size
                                          > in width, height, and depth. OpenGL 2.0 allows arbitrary sizes for
                                          > width, height, and depth"
                                          >
                                          > Regarding Flash hardware acceleration Adobe writes in
                                          > http://tinyurl.com/3qssbwz "Your bitmap dimensions do not have to be a
                                          > power of two, but the more iterations over which they can be evenly
                                          > divided, the better."
                                          >
                                          > However, if I understand
                                          > http://www.khronos.org/webgl/wiki/WebGL_and_OpenGL_Differences
                                          > correctly, non-power-of-two textures can't be mip-mapped in OpenGL and
                                          > WebGL, which indeed would be a drawback. But the page also describes a
                                          > mechanism how to work around this limitation...
                                          >
                                          > --
                                          > Erik Krause
                                          > http://www.erik-krause.de
                                          >
                                          >
                                          > ------------------------------------
                                          >
                                          > --
                                          >
                                          >
                                          >
                                          >


                                          [Non-text portions of this message have been removed]
                                        • Wim Koornneef
                                          ... I agree but I think it is good to give an explanation why. With the default base tile size and the default steps of the tiles you most times get a lot of
                                          Message 20 of 27 , Jun 7, 2011
                                          View Source
                                          • 0 Attachment
                                            erik_leeman wrote:
                                            > .....
                                            > Selecting cubefaces from a range of 510-1020-1530-2040-2550-3060-3570 in
                                            > the Multiresolution tab of Pano2VR, a tile size of 510, AND an overlap of
                                            > 1 pixel for each tile seems to me to be the way to 'get it right'.......
                                            >

                                            I agree but I think it is good to give an explanation why.

                                            With the default base tile size and the default steps of the tiles you most
                                            times get a lot of tiles in each of the tile sets that are not equel in
                                            height and width, by doing some math yourself you can make sure that each
                                            tile in a set has the same size for height and width.
                                            By doing this you reduce the number of tiles in each tile set and this can
                                            speed up the download and processing time.

                                            By adding extra steps of tiles the transitions will be better, with the
                                            default number of tile steps you will see that when you are zooming in and
                                            are getting closer to the point that new tiles will be displayed that the
                                            image will be a bit fuzzy and then when you zoom further in suddenly (when
                                            the tiles are changed) the image will be sharp. With an extra step you will
                                            not see the point where the tiles are changed.

                                            Of course the total pano size will be larger with extra steps but you get
                                            extra quality back for it (better transitions and less visible shimmering)
                                            and when viewing the pano with a normal computer and an average internet
                                            speed connection the extra total size is not an issue.

                                            Skipping steps as Erik did is possible when you know the size of the screens
                                            you are making the panos for.
                                            It is a bit of work but when you make a pano with many steps from from very
                                            small to the max with extra steps in between and then give the tiles that
                                            contains the same part of the scene a "visible" number with photoshop that
                                            correspondents with the step then when you zoom in and out you can see the
                                            numbers in the pano changing.
                                            Also zoom in and out with a different size of the viewer window and by doing
                                            this you know which tiles are used for a specific display size.
                                            You can also use this test to see what happens when you change the bias and
                                            other settings.

                                            Wim




                                            --
                                            View this message in context: http://panotoolsng.586017.n4.nabble.com/Quest-for-effective-high-res-360x180-VR-pano-distribution-tp3565426p3579050.html
                                            Sent from the PanoToolsNG mailing list archive at Nabble.com.
                                          • Ken Warner
                                            1) WebGL and iDevices are OpenGL ES (embedded systems) Not clear to me if what you can say for OpenGL applies to OpenGL ES. I know some parameters to some
                                            Message 21 of 27 , Jun 7, 2011
                                            View Source
                                            • 0 Attachment
                                              1) WebGL and iDevices are OpenGL ES (embedded systems) Not clear to me
                                              if what you can say for OpenGL applies to OpenGL ES. I know some parameters
                                              to some functions are different.

                                              2) There is no rule that says the edge of a texture has to be mapped to a
                                              particular place on a surface. And there's no rule that says "cube faces"
                                              can't be bigger than the cube they surround. It's virtual space not real space.

                                              Erik Krause wrote:
                                              > Am 03.06.2011 00:09, schrieb Trausti Hraunfjord:
                                              >> It means that cubefaces/graphics have to go by the "power of two" concept
                                              >> (this is not a request, but a requirement) . The power of two means that
                                              >> graphics have to have the following dimensions:
                                              >> 1/2/4/8/16/32/64/128/256/512/1024/2048/4096
                                              >>
                                              > [...]
                                              >> This goes for ALL hardware that is based on OpenGL 2 standards, and not some
                                              >> "evil Adobe plan" as some might like to think. All iDevices are already
                                              >> bound by these standards.
                                              >
                                              > Do you have a source for this claim? According to Nvidia documentation
                                              > (PDF): http://tinyurl.com/5s47pnz "Previously core OpenGL required
                                              > texture images (not including border texels) to be a power-of-two size
                                              > in width, height, and depth. OpenGL 2.0 allows arbitrary sizes for
                                              > width, height, and depth"
                                              >
                                              > Regarding Flash hardware acceleration Adobe writes in
                                              > http://tinyurl.com/3qssbwz "Your bitmap dimensions do not have to be a
                                              > power of two, but the more iterations over which they can be evenly
                                              > divided, the better."
                                              >
                                              > However, if I understand
                                              > http://www.khronos.org/webgl/wiki/WebGL_and_OpenGL_Differences
                                              > correctly, non-power-of-two textures can't be mip-mapped in OpenGL and
                                              > WebGL, which indeed would be a drawback. But the page also describes a
                                              > mechanism how to work around this limitation...
                                              >
                                            Your message has been successfully submitted and would be delivered to recipients shortly.