Sie sind nicht angemeldet.

Lieber Besucher, herzlich willkommen bei: Forum. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.


Sonntag, 12. Oktober 2014, 23:06

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!


Montag, 13. Oktober 2014, 10:51


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

Best regards,


Montag, 13. Oktober 2014, 15:02

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!


Montag, 13. Oktober 2014, 15:27


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,


Montag, 13. Oktober 2014, 15:42

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« hat folgende Datei angehängt:
  • (867 Byte - 4 mal heruntergeladen - zuletzt: 7. April 2015, 21:15)


Montag, 13. Oktober 2014, 16:03


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

Best regards,


Montag, 13. Oktober 2014, 16:21

Thank you!


Montag, 13. Oktober 2014, 17:02


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,


Montag, 13. Oktober 2014, 18:55

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


Dienstag, 14. Oktober 2014, 00:42

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.



Dienstag, 14. Oktober 2014, 08:50


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,


Dienstag, 14. Oktober 2014, 10:38

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 :)

Ähnliche Themen