You are not logged in.

Dear visitor, welcome to 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.


Sunday, October 12th 2014, 11:06pm

stitches when using levelsizes?

Dear Klaus,

here's an issue I've been running into lately. Mind you, we only recently started using multires panoramas, so it very well might be that all of this is just a result of my lack of understading the multires method and it's settings. So we've started creating these multires panoramas with predefined levelsizes, and we are experiencing various stitch lines along some tiles.

Please don't mind the upper line (the one fading out to the bottom-right), that is part of the image itself.

So at first I did some searching on the forum, and found this topic. However, it is 4 years old, refers to flash player issues (we do html5 only now), and also in that topic you've explained that these artifacts only happen when zoomed in (at more than a maxpixelzoom = 1.0 level). In fact, we do only experience these stitch lines when zoomed in beyond that, however the real reason I'm making this post is that it seems to happen only when we tile the image up with predefined levelsizes. Simply put, if we just drop the image on the default multires droplet, there are no stitch marks, regardless of the zoom.

So my question is, am I doing something wrong with the settings, or...?

Here are our settings, for reference:

# multiresolution settings

Cheers, and thanks for any help in advance!


Monday, October 13th 2014, 10:51am


can you provide have more information:
  • Link to the example?
  • krpano version?
  • WebGL or CSS3D?
  • Which browser and system?

Best regards,


Monday, October 13th 2014, 3:02pm

Hello! Yes, sure, here you go:

- example panorama (zoom in and look near the bottom)
- viewing with firefox 32, same with chrome 37, both on windows 7 x64
- webgl
- krpano version is 1.17.5

Hope that helps!


Monday, October 13th 2014, 3:27pm


that 'line' is already there inside the tile images - see here:

That means when it's there, it's probably also in the source image...

Additionally the images seems to be modified or scaled, they are not aligned correctly (visible as 'jumping' when zooming).
How have these tiles been generated?
The krpano tools shouldn't produce such output...

Best regards,


Monday, October 13th 2014, 3:42pm

Now that you mention it, I do see some of these lines on the tiles. Also, didn't even realize the jumping effect, I was probably too focused on the lines, but yes, this is also an issue.

In any case, the tiles have in fact been generated by krpanotools. I have attached the full config file (although the only difference compared to the default multires config are in the lines I posted earlier), and the panorama image aswell, if it helps. Again, if I use the default template for the droplet, all these issues are gone. If I use with these predefined levelsizes, this is what I end up with.

Edit: the panorama image was too large to attach, so here it is .
justil has attached the following file:
  • (867 Byte - 4 times downloaded - latest: Apr 7th 2015, 9:15pm)


Monday, October 13th 2014, 4:03pm


I was able to reproduce this - it seems to be a problem in the vertical upscaling... I will analyze this now.

Best regards,


Monday, October 13th 2014, 4:21pm

Thank you!


Monday, October 13th 2014, 5:02pm


I just found and fixed the problem - it was a kind of stupid minimal typo in the code (a state variable was initialized inside the vertical tile loop instead of outside)...

This bug was affecting the output tiles when the tool was vertically upscaling and tiling at the same time. Normally the tools are only downscaling to create the lower resolution levels, this was the reason why that problem hadn't appeared before or why it is working when using the default settings.

The bug will be fixed in then next krpano release (version 1.18).

As workaround you could manually upscale the input image (e.g. to 12868x6434 if you want to get 4096x4096 cubes).

Best regards,


Monday, October 13th 2014, 6:55pm

Thanks for the help Klaus, will check this out a bit later! Cheers!


Tuesday, October 14th 2014, 12:42am

Klaus, is there an article somewhere explaining the (basic) math behind the tilesizes and levelsizes, and how to properly set these up?

So for example, with an input image like the one I posted earlier, using


produces good results, no 'jumping' effect and no stitches.

However using


the jumping is there. Why? I'm sure there's a simple reason, it's just I cannot seem to understand the basics behind these settings and how the multires should ideally work. We could of course just use the automatic settings, but we wish to understand and to have fine control over as much as possible.



Tuesday, October 14th 2014, 8:50am


the main problem is not the setup itself, it's a bug in the krpano tools which is causing these wrong generated output tiles in this case.

I will try to explain it more detailed here:
  • Your input pano image has a pixel size of 5200x2600.
  • This will be converted to a cubical pano with a cube size of 1655x1655 (5200 / PI ~= 1655).
  • Due your custom level sizes setting - 'levelsizes=1024,2048,4096' - the tools will now UPSCALE these 1655x1655 to 2048x2048 and 4096x4096 to generate these levels.
  • And here is a bug in the krpano tools - when doing UPSCALING and tiling the results CAN be wrong (depending on the upscale factor).
  • As long as the krpano tools would only need to DOWNSCALE the generate the levels (that's normal the case, because upscaling isn't any quality win) everything will be correct.
  • So as workaround you could manually upscale your 5200x2600 input image to 12868x6434 (=4096 x PI), then the krpano tools would only need to DOWNSCALE, even for generating the 4096 level.

That upscaling bug itself will be fixed in the 1.18 version.

Best regards,


Tuesday, October 14th 2014, 10:38am

Thanks Klaus, but you slightly misunderstood me. I already understood what you wrote earlier about upscaling per se, what I didn't know for example is this:

"This will be converted to a cubical pano with a cube size of 1655x1655 (5200 / PI ~= 1655)"

I had no idea it works that way. Now I know how to properly set up the level sizes :)