image quality issue

Q&A about the latest versions
Post Reply
ffurger
Posts: 102
Joined: Mon Mar 24, 2014 11:45 am

I have attached two screenshots showing the same scene:

The first was taken from the preview panel in pano2VR 5.
The second from the generated output in the Safari browser.

As you can tell, the second image, the one taken in Safari, is of less quality.
I am not sure what to make of this. I thought that the preview panel in pano2VR would display the pano in the actual output quality, but that doesn't seem to be the case. Is there a way address this issue?

Thank you for your help,
Franco
Attachments
Browser window
Browser window
Screen Shot 2.png (5.1 MiB) Viewed 7558 times
Pano2VR preview window
Pano2VR preview window
Screen Shot 1.png (4.53 MiB) Viewed 7558 times
User avatar
Tony
Posts: 1342
Joined: Mon Feb 15, 2010 6:54 am
Location: Adelaide, South Australia
Contact:

Hi Franco,

I just did a quick test with one of my panoramas and I'm not seeing the image degradation you are! Preview Panel left, Safari right.

Image

What quality setting do you have for your images in the Output section and are you using a Download/Preview file in color by any chance?

cheers,

Tony
Tony Redhead | Panoramic Photographer | mobile: +61438501002 | website: https://tonyredhead.com - https://redsquare.com | Pano2VR Tutorials: https://tonyredhead.com/pano2vr | instagram: https://www.instagram.com/tonyredhead/
User avatar
Hopki
Gnome
Posts: 13005
Joined: Thu Jan 10, 2008 3:16 pm
Location: Layer de la Haye, Essex UK
Contact:

Hi Franco,
Are you using the default settings?
If not what are your settings.
Regards,
Hopki
Garden Gnome Support
If you send an e-mail to support please send a link to the forum post for reference.
support@ggnome.com
https://ggnome.com/wiki/documentation/
ffurger
Posts: 102
Joined: Mon Mar 24, 2014 11:45 am

Thank you both of you.

These are my data:

Input pano: 13777 x 1653 px;
Suggested optimal cube face size: 1273px. That's what I have selected for a additional test.
Quality: was 90%, I raised it to 100%;
Tile quality: was 90%, I increased it to 100%;

One more thing. Here is the code I use in my template to load the pano:

<script type="text/javascript">
var loadSkin = document.createElement("script")
loadSkin.type = "text/javascript";
loadSkin.src = locationPath + "skin.js";
$("body").append(loadSkin)
var loadPano2vrPlayer = document.createElement("script")
loadPano2vrPlayer.type = "text/javascript";
loadPano2vrPlayer.src = locationPath + "pano2vr_player.js";
$("body").append(loadPano2vrPlayer)
pano = new pano2vrPlayer("panoContainer");
skin = new pano2vrSkin(pano, locationPath);
pano.readConfigUrl(locationPath + "pano.xml");
</script>

Result: possibly even worse.
ffurger
Posts: 102
Joined: Mon Mar 24, 2014 11:45 am

One more thing:

I was using a single resolution setting. I did a test with multi-resolution at the default values.The quality improved dramatically.

Best,
Franco
User avatar
Hopki
Gnome
Posts: 13005
Joined: Thu Jan 10, 2008 3:16 pm
Location: Layer de la Haye, Essex UK
Contact:

Hi Franco,
Yes that would do it.
With multi resolution you have the full resolution of the input image when you zoom in.
The down side is more data on the server but the user experience is much better.
Regards,
Hopki
Garden Gnome Support
If you send an e-mail to support please send a link to the forum post for reference.
support@ggnome.com
https://ggnome.com/wiki/documentation/
ffurger
Posts: 102
Joined: Mon Mar 24, 2014 11:45 am

Hi Hopki,

thank you for your feedback. I'd like to better understand the quality issue, though. Here is my question:

What exactly is being shown in the preview pane ? Is the image a true panorama (i.e. an output view) or simply a view onto the original rectangular input image scrolled horizontally?

If the former, then I am not sure why I would need a multi-resolution output to get the same image quality as in the preview.
Alternatively, what face size would I have to select if I wanted to get the same quality as in the preview for a single resolution output image?

Thank you so much for your help!

-Franco
User avatar
Hopki
Gnome
Posts: 13005
Joined: Thu Jan 10, 2008 3:16 pm
Location: Layer de la Haye, Essex UK
Contact:

Hi Franco,
The viewer uses the full resolution of the input image.
So the viewers resolution would be that of the multi resolution output.
Just for information, the optimal cube face size is for if you are displaying the pano in a smaller window and with no zoom.
The calculation is made by looking at the window size as set under the HTML tab and pano width.
This is legacy and before HTML5 multi resolution.
If file size is an issue you can select manual multi resolution and then limit which levels you would use.
Otherwise just use multi res.
As for Quality, it is not linear, in other words you wont see much difference between 90 and 100% apart from the file size will go through the roof.
Again the default of 90 is probably the best setting.
The only setting that could do with changing IMO is the interpolation filter found in the settings/preferences.
The default is Mitchell but I set mine to Lanczos3 which gives a sharper image. But this is a personal preference and worth having a play.
The further down the list the sharper the image, but you could over sharpen if you also sharpen the Equirectangulay in the stitching software.
Regards,
Hopki
Garden Gnome Support
If you send an e-mail to support please send a link to the forum post for reference.
support@ggnome.com
https://ggnome.com/wiki/documentation/
ffurger
Posts: 102
Joined: Mon Mar 24, 2014 11:45 am

Hi Hopki,

Thank you very much for your feedback. I have a follow-up question. You said:
The viewer uses the full resolution of the input image.
So the viewers resolution would be that of the multi resolution output.
So when I zoom into viewer pano2VR is using a multi-resolution version of the input image for that purpose? In other words, the only way for me to get the same image quality I am seeing in the preview pane is to produce a multi-resolution output image?
Just for information, the optimal cube face size is for if you are displaying the pano in a smaller window and with no zoom.
The calculation is made by looking at the window size as set under the HTML tab and pano width.
This is legacy and before HTML5 multi resolution.
Oh, this a very helpful. I never quite understood what the optimal cube face size was supposed to mean. I never paid much attention to it, but it kind of troubled me that I wasn't using the "optimal" face size. Does it still make sense to have it?

Best,
Franco
User avatar
360Texas
Moderator
Posts: 3684
Joined: Sat Sep 09, 2006 6:06 pm
Location: Fort Worth, Texas USA
Contact:

Lessons Learned: In a not so Long Long time ago History

The cube face legacy stems from 15+ or more years ago. Big file size and slow download became an issue that needed fixing.

Dave's AXIOM: "The internet content travels at the speed of light only to be slowed down by slow servers, connection hub's and copper wire"

Faster download speed, smaller the file content ARE better for both developer and visitor. "Instant" became an important word in our vocabulary and workplace. Fast content download was and still is ALL to important. Its now complicated by several platforms for computers /smartphones O/S platforms, camera file formats and browsers types and versions.

One tool called the "Progress bar" or timer became useful because it was displayed on the screen while the large panorama file was being downloaded from a slow server/ internet connection. It gave the visitor a device to watch (keep them visually engaged in anticipation of experiencing a truly new form of panorama photography)

The small cube face file workflow was necessary because of the very slow "128kb Dial up" internet connection speeds around the world. Even the THEN 256kb - 3mbps ADSL connection speeds were slow through - put. Which means that the visitor had to sit and wait a long 30 to 60 seconds or more for the imaging content to transfer from the server down to the desktop computer then display on the screen. The rule was that if the panorama took longer than 20 seconds to display the visitor would bolt (immediately leave) to go and find a faster website. Read lost of potential paying client or customer.

Camera's and fisheye lenses were taking large mega byte panoramas. Camera resolution (file size) grew from 500 kb to greater than +Mega byte size and panoramas were getting exponentially larger and larger.

Internet connection speeds grew faster and faster. Camera and panorama files were growing larger and larger. Server download speeds like wise increased over time.

Out of necessity, the Cube face technique evolved as a method of a faster delivery solution. Small cube face file sets means faster download's over most all types of internet connections. Cube face image sets are based on levels of zoom in/out.

Workflow Technique: How to slice and dice an image into cube faces while maintaining quaility (read no zoom in pixelation):

All this "how fast is really fast" hysterical madness is really based based on a simple mathematical solution.

Panorama Images are by definition 2:1 aspect ratio. Where the stitched image width is double the image height like 6000 pixels wide x 3000 pixels high.

Image width divided by the mathematical function called Pi (3.1415) where a cube face pixel dimension image would be 1909.91564 or 1910 pixels square (1910 h x 1910 w pixels square).

Levels:
Is your project an HTML5 Multi-Res output type?
If so what was your 'Level Tile Size' and
how many levels did you create and their level sizes ?

For example we use these Multi Res configuration values shown in pixels:
Level Tile Size 336 pixel (px)

Level 1 1344 px
Level 2 672 px
Level 3 336 px

Where the value Level Tile Size 336 px is equally divided by Levels 1, 2 and to result in a whole number and not a value like 3.551
Level 1 3344 px / 336 = whole number 4
Level 2 672 px / 336 = whole number 2
Level 3 336 px / 336 = whole number 1

The results in an HTML5 multi-res output fewest number of tile with the smallest level 336 px are small enough to fit small smart phone screen and slow CPU graphics processing.

At this point you probably are at 'INFORMATION Overload' point and your head hurts.

LOLLLLL my head hurts just trying to remember all this content.
After all we started creating panoramas back almost 20 years ago in 1998.
Dave
Pano2VR Forum Global Moderator
Image
Visit 360texas.com
User avatar
Hopki
Gnome
Posts: 13005
Joined: Thu Jan 10, 2008 3:16 pm
Location: Layer de la Haye, Essex UK
Contact:

Hi Franco,
Does it still make sense to have it?
Yes because in other templates it is used, example for the iBooks template you need to set the logical widow size and this is where you do it.
Regards,
Hopki
Garden Gnome Support
If you send an e-mail to support please send a link to the forum post for reference.
support@ggnome.com
https://ggnome.com/wiki/documentation/
ffurger
Posts: 102
Joined: Mon Mar 24, 2014 11:45 am

Dave,

thank you for the ... historical summary. I do remember quite well the times when I used to dial-in at 56kb ... At the time it felt like a big improvement over 28kb!

You said that
Panorama Images are by definition 2:1 aspect ratio. Where the stitched image width is double the image height like 6000 pixels wide x 3000 pixels high.
I assume this is true only for spherical panoramas ? For my project I often use "kiwi"-panoramas, where the top and bottom are cut off. In my view, top and bottom often don't add much to the user experience and in the case of the bottom adding it can be a real pain.

So far I stayed away from multi-resolution images because they introduce a whole new level of complexity to an already complex project:

a) The platform/application is intended to be used both on the desktop and on mobile devices.
b) On desktops I assume users do have access to a reasonably fast internet. Dial-up is excluded.
c) It should also be possible to use the application on mobile devices, but not necessarily on phones with small screens.
With mobile devices, I can't assume that the user generally will have a reasonably fast access to the internet or even any access at all. In these latter two cases the applications should still usable, although with some minor limitations.

With all this in mind caching becomes of paramount importance. Obviously I could rely on the cache manifest IF the panoramas are single-resolution. With multi-resolution images the data volume for a given image size increases too much to be used on mobile devices, even on last generation iPhones. And it's not clear to me that as a practical matter I can use the cache manifest to store multi-resolution images. Also of relevance is the fact the the cache manifest is tricky to implement and maintain. It has also officially been deprecated. Unfortunately Apple so far has not provided a future-proof replacement.

Last but not least I also need to define a few cut-off points for different display sizes, both for desktop and mobile. I did some statistical analysis and I think I can get away with few cut-off points.

Oh, and if you are curious about the project have a look at http://www.immersive-tours.ch

best,
Franco
ffurger
Posts: 102
Joined: Mon Mar 24, 2014 11:45 am

Oh, I see, thank you for the clarification.

-Franco
User avatar
Hopki
Gnome
Posts: 13005
Joined: Thu Jan 10, 2008 3:16 pm
Location: Layer de la Haye, Essex UK
Contact:

Hi Franco,
The default export for HTML5 is multi resolution. You don't need to do anything, Pano2Vr works out the levels and exports.
You just need to add a skin and hotspots.
Regards,
Hopki
Garden Gnome Support
If you send an e-mail to support please send a link to the forum post for reference.
support@ggnome.com
https://ggnome.com/wiki/documentation/
ffurger
Posts: 102
Joined: Mon Mar 24, 2014 11:45 am

Thanks Hopki, I appreciate it.

-Franco
Post Reply