Quantcast

Quest for effective high-res 360x180 VR pano distribution

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Quest for effective high-res 360x180 VR pano distribution

erik_leeman
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.

Cheers!

Erik Leeman

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Greg Voisan
I'm in California and the work great here! Beautiful panos.



--- In [hidden email], "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.
>
> Cheers!
>
> Erik Leeman
>
> <http://www.flickr.com/photos/erik-nl/>  <http://www.erikleeman.com/>
>


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Roger D Williams
In reply to this post by erik_leeman
On Wed, 01 Jun 2011 19:19:48 +0900, erik_leeman <[hidden email]>  
wrote:

> 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.

I can't imagine Google competing at THIS level for quite a while. For
one thing they would have to get photographers of the same ability,
and they are not common.

> 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.

Well, I'm in Japan, so I suppose that makes my experience relevant.

> 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.

I notice a difference between the behaviour for the first three and the
last two.

The first three quite rapidly load up to 50, 51 or 52% and then the
indicator freezes. It doesn't seem to make any difference whether I
click on the full-screen button at once, or leave it off. However,
the image appears in full colour almost at once, and is obviously
getting clearer while the meter ticks up to 50%. Getting bored with
the 50% meter display, I tried panning around, and this works, both
with full-screen ON and OFF. Only of course there are large areas
that remain blurred.

Eventually, the meter starts moving again, and I can enjoy these
splendid panoramas with full clarity. I do not notice shimmering, but
I do find the panning a little jerky--perhaps "stuttery" would be a
better word. Smooth it is not.

The fourth image showed no loading meter, and although the coloured
image could be panned, the image retained unclarified areas for so
long that I fear the casual viewer would ask themselves why the focus
is so bad in places, and move on without waiting. I did wait until
this dark image of a church eventually clarified (I have a particular
interest in and love of panoramas of churches) and it was worth the
wait.

The fifth image just suffered a long, slow load.

Hope this helps.

Roger W.




>
> 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.
>
> Cheers!
>
> Erik Leeman
>
> <http://www.flickr.com/photos/erik-nl/>  <http://www.erikleeman.com/>
>
>
>
> ------------------------------------
>


--
Work: www.adex-japan.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

DemonDuck
In reply to this post by Greg Voisan
I'm also in California on a very slow connection.  I
tried PodereCerale.  It took a minute and a half to load.
The image quality is good -- I can read some book titles
and the thermometer is clear.  Not much shimmering.

In full screen, there is some tearing because I have
only the Intel GX45 chip set for graphics -- that's
low end graphics.  Screen size is 1280x1024 old but
good tube monitor with 85Hz refresh rate.

The transition between resolutions is very smooth and
unnoticable.  Thomas did a good job on that.  I noticed
how smooth it was in tests I did for myself.

Mouse zooming is weird though.  But Thomas knows about it.

gregoryv92821 wrote:

> I'm in California and the work great here! Beautiful panos.
>
>
>
> --- In [hidden email], "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.
>>
>> Cheers!
>>
>> Erik Leeman
>>
>> <http://www.flickr.com/photos/erik-nl/>  <http://www.erikleeman.com/>
>>
>
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

erik_leeman
In reply to this post by Roger D Williams
Thanks for having a look and your reports!

@ Roger:
As was to be expected the vast distance between you and the server causes a problem that really can only be solved by moving that server closer to your location.
Microsoft, Apple or Google couldn't do their business any other way, but for people like us it's a bit too expensive.
So now we have to deal with a situation where we (including our potential audience) all have powerful enough computers, good enough screens, and fast enough internet connections, but we STILL cannot shift our pixels fast enough to far-away locations. What a bummer!

However, reading your report makes me think there might also be a second limiting factor for these relatively large panoramas: available memory.
With my 'direct to fullscreen' preloaders I made sure memory is released every time you 'escape' a panorama. Not doing so would lead to a browser crash if you tried to load a series of these large panos quickly one after the other. But that flushing mechanism made some people complain about having to endure another complete download if they wanted to revisit a panorama.
So this time I did nothing to influence unloading, and the slowdown and choppyness you are experiencing might have something to do with that.
Pano2VR does have some parameters in its Multi-resolution menu that seem to provide a means to fine tune memory use, but I have no idea what to do with them (yet).

In fullscreen I see no hesitations or anything, panning is very smooth, but to my surprise there's a lot of tearing in the windowed view! Apparently Flash is MUCH less efficient in an HTML page when compared to its full screen performance, at least on my computer.

Let's hope things can still be improved, because being able to produce  panos of higher resolution and quality than the likes of Google can means nothing if no one can see them!

Cheers!

Erik Leeman

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

--- In [hidden email], "Roger D. Williams"  wrote:

> ...snip...
> Well, I'm in Japan, so I suppose that makes my experience relevant.
>
> I notice a difference between the behaviour for the first three and > the last two.
>
> The first three quite rapidly load up to 50, 51 or 52% and then the
> indicator freezes. It doesn't seem to make any difference whether I
> click on the full-screen button at once, or leave it off. However,
> the image appears in full colour almost at once, and is obviously
> getting clearer while the meter ticks up to 50%. Getting bored with
> the 50% meter display, I tried panning around, and this works, both
> with full-screen ON and OFF. Only of course there are large areas
> that remain blurred.
>
> Eventually, the meter starts moving again, and I can enjoy these
> splendid panoramas with full clarity. I do not notice shimmering,
> but I do find the panning a little jerky--perhaps "stuttery" would
> be a better word. Smooth it is not.
>
> The fourth image showed no loading meter, and although the coloured
> image could be panned, the image retained unclarified areas for so
> long that I fear the casual viewer would ask themselves why the
> focus is so bad in places, and move on without waiting. I did wait
> until this dark image of a church eventually clarified (I have a
> particular interest in and love of panoramas of churches) and it was
> worth the wait.
>
> The fifth image just suffered a long, slow load.
>
> Hope this helps.
>
> Roger W.



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

erik_leeman
In reply to this post by Roger D Williams
Hi Roger,

I replaced the old, barely visible, loading bar of the church pano.
Thanks for reminding me ; )

In case you'd like to know, here is it's official name:
Basilica Sancti Servatii Trajecti Ad Mosam
or more informal: 'Basiliek van Sint Servaas'.
It's in the city of Maastricht, the Netherlands.

Cheers!

Erik Leeman

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

--- In [hidden email], "Roger D. Williams" wrote:

> ...snip...
> The fourth image showed no loading meter, and although the coloured
> image could be panned, the image retained unclarified areas for so
> long that I fear the casual viewer would ask themselves why the
> focus is so bad in places, and move on without waiting. I did wait
> until this dark image of a church eventually clarified (I have a
> particular interest in and love of panoramas of churches) and it was
> worth the wait.
> ...snip...
> Roger W.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Hans-74
In reply to this post by erik_leeman


--- In [hidden email], "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



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Jim Watters
On 2011-06-02 8:02 AM, Hans wrote:

>
> --- In [hidden email], "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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

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 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
<[hidden email]>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]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

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 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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

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 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 <[hidden email]>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 <
> [hidden email]> 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]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

erik_leeman
In reply to this post by Trausti Hraunfjord
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 [hidden email], 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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

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... 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 <[hidden email]> 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 [hidden email], 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]



------------------------------------

--
<*> Wiki: http://wiki.panotools.org
<*> User Guidelines: http://wiki.panotools.org/User_Guidelines
<*> Nabble (Web) http://panotoolsng.586017.n4.nabble.com/
<*> NG Member Map http://www.panomaps.com/ng
<*> Moderators/List Admins: [hidden email]
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/PanoToolsNG/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/PanoToolsNG/join
    (Yahoo! ID required)

<*> To change settings via email:
    [hidden email]
    [hidden email]

<*> To unsubscribe from this group, send an email to:
    [hidden email]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

DemonDuck
In reply to this post by erik_leeman
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.
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

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 Digital Solutions LLC  - Atlanta, Georgia
http://www.seeit360.net
http://twitter.com/SeeIt360
http://www.facebook.com/panoramas/
IM: [hidden email]
Office: 404-551-4275
GV: 404-665-9990


On Jun 2, 2011, at 8:58 PM, Ken Warner <[hidden email]> 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]



------------------------------------

--
<*> Wiki: http://wiki.panotools.org
<*> User Guidelines: http://wiki.panotools.org/User_Guidelines
<*> Nabble (Web) http://panotoolsng.586017.n4.nabble.com/
<*> NG Member Map http://www.panomaps.com/ng
<*> Moderators/List Admins: [hidden email]
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/PanoToolsNG/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/PanoToolsNG/join
    (Yahoo! ID required)

<*> To change settings via email:
    [hidden email]
    [hidden email]

<*> To unsubscribe from this group, send an email to:
    [hidden email]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Hans-74
In reply to this post by erik_leeman


--- In [hidden email], "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 [hidden email], 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
>


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Hans-74
In reply to this post by Trausti Hraunfjord


--- In [hidden email], 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]
>


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

tom_a_sparks
--- In [hidden email], "Hans" <hans@...> wrote:

>
>
>
> --- In [hidden email], 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]
> >
>


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

erik_leeman
In reply to this post by Hans-74
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 [hidden email], "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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

erik_leeman
In reply to this post by DemonDuck
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 [hidden email], 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?

12
Loading...