Page 2 of 3

Re: Problem with flat Pano

Posted: 01 Feb 2019, 09:56
by mjau-mjau
voyezvousca wrote:in fact, can you check this pano : https://portfolio.voyezvousca.fr/portfo ... #pano=lama
Can you tell me if for you the cache is ok ?
Yes it works fine, and your flat pano's look great.
voyezvousca wrote:I don't understand why, but the loading is very bad...  my parameter is :
Not quite sure what "loading speed" you are referring to. I am in Thailand, and the loading seems entirely fine from here, especially considering how far away I am. Perhaps peak hours for internet and server access around your location? It's important to understand that flat panoramas do require a lot of bandwidth. For example after panning one of your panoramas slightly, it started loading 10 - 15 new tiles, and many of those tiles are almost 250kb each ... That's 2-3 MB that must be loaded into the visitors browser to satisfy the view [screenshot]. The only way to improve loading speed of static panorama assets, might be to use a CDN service (like Amazon), but I don't think it's gonna make a HUGE difference.

The loading speed certainly has nothing to do with your parameters, which are correct.

Tip: For maximum optimization, you could drop your tiles in an application like Imageoptim. Even with LOSSLESS compression, it will shave off up up to 10-20% of the file size of all images, making your flat panoramas load 10-20% faster. I have done this in our demo.
https://imageoptim.com/mac

Re: Problem with flat Pano

Posted: 01 Feb 2019, 11:36
by voyezvousca
i did some different test. I'ts not my local network (fiber 1gbps/300mbps)

I tryed to upload the pano2vr project with html5. And it's look like very better, i don't know why. It's the same files.
Can you test please : https://portfolio.voyezvousca.fr/portfo ... #pano=lama and this : https://portfolio.voyezvousca.fr/demo/ <- pan2vr export

is different for you? For me its very very better with pano2vr, i don't see the "square loading" when i scroll in image. And for example in x3 panorama plugin, if i scroll at right to left, the image reload with square all the time. In pano2vr, is seem to be preload, all the time.
 
edit : the scrool with the mouse work in microsoft edge (ex internet explorer) but not in firefox. I will test in chrome later

Re: Problem with flat Pano

Posted: 01 Feb 2019, 13:43
by mjau-mjau
Well, that's an interesting comparison of course. I compared side by side after a few browser refreshes with cache DISABLED (to force all tiles to load from server). Before anything else, let's look at the pure technical side, with last tile load highlighted on the bottom right:

X3
Image

pano2vr
Image

Visual:
There is certainly no difference in visuals after everything is loaded into initial view. You should be able to see that from the screenshots. Basically the SAME tiles have been loaded into view, based on my display pixel resolution (1920 x 1080). In BOTH cases, I see it has loaded LEVEL4 into view (screenshots X3 vs pano2vr). This was entirely expected of course.

Loading speed:
There should not be any big difference in loading speed. After all, the tiles are simply loaded as JPG files from your browser, limited to the speed of server vs internet. For the sake of comparison, as in my screenshots:

All tiles loaded X3: 13.64 seconds
All tiles loaded pano2vr: 28.38 seconds

That difference is probably a bit random. After refreshing a few times, the total loading time for all tiles is similar, almost identical. And of course, this is to be expected ... It is after all loading pretty much the same tiles from the same server. In the case of X3, you are also loading the entire X3 page first, including JS/CSS/HTML/IMAGES, although they will load very fast. X3 is also preloading previews for the other panoramas (next/previous). From a pure technical perspective, there is certainly no reason to believe X3 is slower at getting from A (nothing loaded) to Z (the current view entirely loaded).

Perceived difference in loading:
Ok, this is interesting, and is likely what you are referring to. Did you notice in the bottom left of the screenshots that X3 had loaded 1.8 MB of tiles while pano2vr had loaded 2.4 MB of tiles? This is because pano2vr loads through all levels (0,1,2,3,4) to get to level 4, while X3 only loads the level 0 (only 1 tile) and the level which is targeted to display 4. This basically means:

PROS pano2vr
Tile quality looks better while loading target level (in my case level 4), because the previous level (in my case level 3) is already displaying as a temporary placeholder for the loading tile. X3 on the other hand, will only display level 0 below the loading target level, which of course is a tiny image and will therefore look blurry until the target tile is loaded. There is NO visual difference after all target tiles are loaded into current view.

CONS pano2vr
Loading all levels prior to target level will of course require more loading (in this case, about 33% more), and ultimately, it will take longer time before target level is loaded into view (because it will load smaller preview levels first). Basically the browser is loading tile levels that are not used, or at least only used to display behind "loading" tiles. Also, it requires more memory from the device, because multiple levels are actually stored as textures for immediate access.

My conclusion: There is no technical speed difference ... If anything, X3 will get from A to Z faster than pano2vr because it loads less "progressive" tiles. Also, there is no visual difference once all tiles for a view are entirely loaded. I do see benefits of loading a higher quality "pinned" level into view ... After all, the visitor will be panning the panorama around, and tiles will be added/removed as they navigate the panorama, and it looks nicer with a higher-quality "loading level". I am pretty sure I can add this to X3 ... It's a method referred to as pinLevel, and we can choose what levels to "pin" (and force load) into the panorama texture. I am however not quite sure how to implement it in a smart way ... In X3, there is another factor also: multiple panorama scenes, which are actually preloaded, with first level already pinned into texture memory ... If you have several scenes, each with several levels pinned into texture memory, you are asking for trouble. For a single-scene pano2vr, this is less critical of course.

Interesting, and something to think about!
voyezvousca wrote:I tryed to upload the pano2vr project with html5. And it's look like very better, i don't know why. It's the same files.
It might look better while panning/loading, because the temporary-tile is of higher quality, but no difference once target tiles are loaded.
voyezvousca wrote:For me its very very better with pano2vr, i don't see the "square loading" when i scroll in image.
Actually, you do see the "square" loading in pano2vr, but since it's a higher quality "loading tile", there will only be a subtle difference from "loading tile" to "target tile" is loaded
voyezvousca wrote:And for example in x3 panorama plugin, if i scroll at right to left, the image reload with square all the time. In pano2vr, is seem to be preload, all the time.
For optimal memory management, unused tiles are unloaded from texture, and reloaded on demand ... normally very fast from your browser cache of course (unless you have disabled cache for testing). In pano2vr, all levels are "pinned" into texture memory ... Seemingly all previous levels of current level, that fit into the view, as well as all tiles that are already loaded once. May I ask, for the sake of comparison, have you been testing in from browser developer tools with cache disabled? That would give a huge disadvantage to X3, because you are preventing tiles from being stored in browser cache ... pano2vr stores all tiles in webGL texture memory.

Re: Problem with flat Pano

Posted: 01 Feb 2019, 18:59
by voyezvousca
Thank you for your analyse !! :)

I have tested with firefox, chrome and edge. It's the same fact in all. And all are the default value, so i think with the cache on.

For a better view and a better comparaison with my feeling on my screen, you can look at this : https://youtu.be/hBrUztJZcvc It's on chrome, default value (cache on i think). At first, is x3. and after is pano2vr, and again x3.

You know, when the pano is load, it's look like very good in x3 too, my feeling is very good. But its true, when i'm scrooling, it's look like a bad connexion because its visual on screen, but of course, when is load, the quality is very very good !

And for all, thank you very much for your patience :D

Re: Problem with flat Pano

Posted: 01 Feb 2019, 23:30
by mjau-mjau
voyezvousca wrote:For a better view and a better comparaison with my feeling on my screen, you can look at this : https://youtu.be/hBrUztJZcvc It's on chrome, default value (cache on i think). At first, is x3. and after is pano2vr, and again x3.
Good video. Basically related to the TWO things I mentioned: 1) pano2vr uses a higher quality preview levels behind the tile that is loading, and the loading squares are less obvious (although you can still see it when target tile loads on top of background tile), 2) Mainly, in the case of your video, we see the effect of X3 loading/unloading tiles as they appear/disappear, while pano2vr pins all loaded tiles into memory. Even when pano2vr DOES have to load new tiles, it's less noticeable because of #1.

Pano2VR clearly wins in the visual department according to your video. I would probably mention however, an actual visitor navigating a flat panorama is more likely to zoom/pan to an area and wait for it to load so they can review it ... After all, that is the primary point of gigapixel flat images, to be able to see a specific zoomed in area in high detail ... and once the detail is loaded, X3 certainly does the job as well. When pinning tiles (pano2vr), more bandwidth and more memory is used, although you would not notice that from a desktop with a fast connection (but it may affect mobile devices on slower connections).

I will definitely be looking into improved tile pinning options!

Re: Problem with flat Pano

Posted: 02 Feb 2019, 03:29
by voyezvousca
mjau-mjau wrote:
voyezvousca wrote:For a better view and a better comparaison with my feeling on my screen, you can look at this : https://youtu.be/hBrUztJZcvc It's on chrome, default value (cache on i think). At first, is x3. and after is pano2vr, and again x3.
Good video. Basically related to the TWO things I mentioned: 1) pano2vr uses a higher quality preview levels behind the tile that is loading, and the loading squares are less obvious (although you can still see it when target tile loads on top of background tile), 2) Mainly, in the case of your video, we see the effect of X3 loading/unloading tiles as they appear/disappear, while pano2vr pins all loaded tiles into memory. Even when pano2vr DOES have to load new tiles, it's less noticeable because of #1.

Pano2VR clearly wins in the visual department according to your video. I would probably mention however, an actual visitor navigating a flat panorama is more likely to zoom/pan to an area and wait for it to load so they can review it ... After all, that is the primary point of gigapixel flat images, to be able to see a specific zoomed in area in high detail ... and once the detail is loaded, X3 certainly does the job as well. When pinning tiles (pano2vr), more bandwidth and more memory is used, although you would not notice that from a desktop with a fast connection (but it may affect mobile devices on slower connections).

I will definitely be looking into improved tile pinning options!
Yes it's true, with flat panorama, the visitor will zoom in portion of the image. In my video i exaggerated the movement to illustrate. Of course in the "real" life, the movement is less hard.

Maybe can be a compromise between visual (on first load of pano) with a better quality preview level, and the same performance in background :) (i think is more complicated for you :D )

Re: Problem with flat Pano

Posted: 02 Feb 2019, 03:39
by mjau-mjau
voyezvousca wrote:Maybe can be a compromise between visual (on first load of pano) with a better quality preview level, and the same performance in background :) (i think is more complicated for you :D )
I'll definitely be looking into it. I think it's better the way pano2vr works ... It just has to be "done right".

Re: Problem with flat Pano

Posted: 02 Feb 2019, 05:31
by voyezvousca
If you want, i can share you entire folder of pano2vr make's (html, js etc) :)

Re: Problem with flat Pano

Posted: 02 Feb 2019, 05:53
by mjau-mjau
voyezvousca wrote:If you want, i can share you entire folder of pano2vr make's (html, js etc) :)
Possible you can zip one of your smallest pano2vr projects for me? Good for testing purposes.

Re: Problem with flat Pano

Posted: 02 Feb 2019, 07:21
by voyezvousca
Of course :) mp sent

Re: Problem with flat Pano

Posted: 06 Feb 2019, 01:17
by mjau-mjau
X3.27.1 was released, which fixed so that 1) buttons are clickable on panorama gallery items, and 2) EXIF items work nicely with all skins, and 3) New pin_levels parameters for flat panoramas.

@voyezvousca: For X3.27.1, I was looking into preloading and pinned levels, as discussed earlier in this post. For now, there is a new pin_levels option/parameter, which allows you to preload level tiles, and "pin" them into memory. This will help, possibly quite a lot, but it is not really a solution. In your case, since your tilesize is quite low, I would try to apply "pin_levels=3" in the panorama parameters. This will make sure the temporary tiles are much higher quality while higher-quality tiles are being loaded. It will not however affect the fact that blocks are unloaded and re-loaded while you navigate around the panorama.

I was researching this loading/unloading, and it's because Marzipano (the X3 panorama render engine) uses an LRU cache mechanism set by default to cache 32 tiles into memory. This means that while you navigate the panorama, 32 tiles will remain in memory, but while new tiles are loaded into memory, old tiles (that don't fit into the cache), will be unloaded. Therefore, when navigating around the panorama, you will briefly see that tiles are re-loaded into panorama even if they were loaded earlier. I found a related topic where the author explains:
https://github.com/google/marzipano/issues/110
 
As noted by the author in the link above, 32 is probably too "conservative" value, but it is in place to "protect" low-memory devices from basically crashing. I am not 100% sure how pano2VR deals with this, but it's definitely generous about caching tiles into memory, although surely there must be a limit. From desktop devices, I am pretty sure we could easily 10x the LRU cache, and most modern mobile devices probably support much higher levels also. The challenge is to figure out how to set the limit, because we cannot detect "memory availability" for a device, although we could make some smart estimate based on screen size and perhaps texture_max_size. Also, the LRU tile cache should depend on the tilesize ... For example, 1024 px tiles require 4x the amount of memory as 512 px tiles.

Anyway, this is on my radar now, and although a bit too complicated to squeeze into X3.27.1, I will be looking into it for a new release.

There is another related issue: It seems that pano2VR automatically pins ALL levels lower than target level. For example, in my test case (my screenshots), levels 1-3 were pinned while my target viewing level was 4. This is kinda what the new pin_levels parameter does, but in pano2vr I assume it's automated to pin all levels below target level ... I'm not sure quite how it works, because surely it can't just load ALL tiles on ALL levels below target level, even if target level is zoomed in at 7 ... That would require insane preloading and pinning to memory. Anyway, this is also on my radar now, and I found a related post here:
https://github.com/google/marzipano/issues/99

Re: Problem with flat Pano

Posted: 06 Feb 2019, 05:36
by mjau-mjau

Re: Problem with flat Pano

Posted: 06 Feb 2019, 12:41
by voyezvousca
Hi,

foremost, thank you very much for attaching importance to this :) I think it will make x3 and marzipano again better.

I have implanted the pin_levels=3 and you can check here : https://portfolio.voyezvousca.fr/portfo ... #pano=lama 
I think is better ! but it's true, in comparaison with pano2vr, the view is again a little less well. I understand of course the problem with the memory availability, and the loading of tiles.

I tried some test with a bandwidth limit (NetLimiter 4 software) (for example 5mbps), to simulate a "low" web acces, and i tested with different pin, to level=2 to 7 (!!) :
- in x3, i see a little difference. as a bandwidth limit, the loading is a little more long, and we see the 32 tiles loading too.
- in pano2vr........nothing... is the same, very good sensation. With your explanations, it is to understand nothing how it work... :D :D :D

Maybe and hope it can help you :/

Re: Problem with flat Pano

Posted: 07 Feb 2019, 00:42
by mjau-mjau
voyezvousca wrote:I have implanted the pin_levels=3 and you can check here : https://portfolio.voyezvousca.fr/portfo ... #pano=lama 
I think is better ! but it's true, in comparaison with pano2vr, the view is again a little less well. I understand of course the problem with the memory availability, and the loading of tiles.
I checked, and it makes minimal difference. The reason is because of the width of your levels, and your tilesize ... Your entire level 3 (l_2, levels start from 0), is only 8 tiles and 139kb (see screenshot)! Quality is really not that much higher than level 0-1. For this panorama, to see any difference, you should probably try pin_levels=4 or even 5. After all, on my 13" retina screen (2880 px), it already loads level 5 (l_4) into view just for the panorama un-zoomed. This panorama seems to have several low levels that probably aren't used for any screens / devices.
Image
voyezvousca wrote:I tried some test with a bandwidth limit (NetLimiter 4 software) (for example 5mbps), to simulate a "low" web acces, and i tested with different pin, to level=2 to 7 (!!) :
- in x3, i see a little difference. as a bandwidth limit, the loading is a little more long, and we see the 32 tiles loading too.
If you pin ALL levels (bad idea), and wait for everything to load, you should definitely NOT see the 32 tile memory limit. Because when you PIN tiles, you bypass the 32-limit cache, and simply tell the viewer to LOAD and PIN ALL tiles on ALL levels to memory, and never unload them. If you "see the 32 tiles loading too", are you sure you waited for everything that was loading to load finished?

Of course, pinning all tiles would require preloading tons of data, and is unproductive.

Re: Problem with flat Pano

Posted: 07 Feb 2019, 09:03
by voyezvousca
Hi,

I have change for pin 5 for now, it look like better ! 
This evening i will try to test with titles at 128 (256 now), for my curious. Do you think it can be better with this?