You are not logged in.

Dear visitor, welcome to krpano.com Forum. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

1

Tuesday, February 25th 2014, 8:59am

Downscaling vs crop

My wife and I have been experimenting with animated hotspots to get some "life" into a panorama. Animated frames are tiled into a single "filmstrip-like" image and a crop is dynamically applied, pretty much like the animated hotspot example (but a bit more advanced):
http://files.fieldofview.com/temp/blinkie
Here is one of the animation tiles:
http://files.fieldofview.com/temp/blinkie/rose_01.jpg

As you can see this is quite a large image. The technique works both in flash and html5 (in contrast with either animated gifs or video hotspots) but I fully expected the panorama with these added images to run out of memory and crash on my (ageing) iphone 4. It would have with previous versions of krpano, but krpano 1.17 does not crash! Instead it applies downscaling to the hotspot-imagery, which is awesome. Unfortunately it does not *quite* work; on my iphone 4, I some of the animated hotspots show as a "matrix" of frames. It looks as-if the scale of the image is not taken into account when applying the crop.

TL;DR: krpano 1.17 scales down graphics when it is running out of memory (which is awesome), but when applying a crop this scale is not taken into account.


We ended up creating a smaller version of the animations for device="mobile", circumventing the problem (at least for my iphone) while at the same time lowering the bandwidth:
http://weeklyworld.skizzie.nl/world/2013…rose-garden-ink
This version also has improved animation etc.

2

Tuesday, February 25th 2014, 4:38pm

Hi,
krpano 1.17 scales down graphics when it is running out of memory (which is awesome), but when applying a crop this scale is not taken into account.
Sorry to disappoint you, but that's not krpano, that iOS .

krpano will only automatically downscale (non-multires) pano images when they are too large for the current device (see the display.hardwarelimit setting for details), but the images from plugin/layer or hotspot elements were directly displayed as they are (internally as CSS background image; the cropping simply works via CSS background-position).

The downscaling that you see here, is an automatic iOS feature - iOS will automatically downscale images that are 'too large', where that 'too large' and the result depends on the iOS version and maybe also on the device itself. For the application itself it's not possible to know if the image was downscaled or what its real image size was.

I have made here a test case for this behavior:
http://krpano.com/temp/imagesizetest/index.html

When the text becomes blur or smaller, then iOS had internally downscaled the image.

In older iOS versions the imagesize itself also has got changed, but it seems in the latest iOS version, this was already fixed - at least in iOS 7 the imagesize will stay the same and only the image itself will become blur.

Best regards,
Klaus

3

Tuesday, February 25th 2014, 6:03pm


For the application itself it's not possible to know if the image was downscaled or what its real image size was.


Rats!

Anyway, 1.17 is more stable for me than previous versions, so the "awesome" still stands.
Looks like I chose a good path providing smaller imagery for mobile.

4

Tuesday, February 25th 2014, 6:08pm

Hey, from the testcase it looks like the app does know the actual size (which makes me think that it should be possible to adapt a crop, but what do I know...)

5

Wednesday, February 26th 2014, 7:13am

Hi,

as long as the imagesize itself is correct the cropping should also work correct, but when iOS would change the imagesize the cropping values wouldn't fit anymore and result in a wrong display.

Here a screenshot from an iPad 1 with iOS 5.1.1 - there changing the imagesize starts after 1448px:


Maybe try to trace the imagewidth and imageheight values in the onloaded event in your example too see if some scaling had happen.
But generally choosing a smaller image for mobile would be already the best way .

Best regards,
Klaus