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
    multires=true
    tilesize=512
    levelsizes=1024,2048,4096
    maxsize=auto
    maxcubesize=auto
    leveldownload=auto

    Cheers, and thanks for any help in advance!

  • Hi,

    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,
    Klaus

  • 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 .

  • Hi,

    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,
    Klaus

  • 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

    levelsizes=1024,1536,2560

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

    However using

    levelsizes=512,1024,2048

    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.

    Cheers!

  • Hi,

    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,
    Klaus

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

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!