Convert Tool is not handling cylindrical panoramas correctly

  • Krpano tools convert tool (v 1.20.10) is not converting cylindrical panoramas to cubes correctly. It is "pinching" the zenith and nadir in the resulting cube faces. I am having to use PTGui to do these correctly for the moment.

  • Hi,

    converting a cylindrical image to cubical would work correctly,
    but it will be necessary to manually pass the '-cylinder' option:
    https://krpano.com/docu/tools/#spheretocube

    Currently there exists no EXIF meta setting to define a pano image as cylindrical, so the default assumption is always sphere.

    The krpano tools would theoretically support also the non-standard the EXIF setting GPano:ProjectionType=cylinder for automatically detecting the image as cylinder, but currently there is no stitching-software that would write that information.

    Best regards,
    Klaus

  • I was referring to the Krpano Tools App. The tab for "Convert" that you drag images on to, not the command line tool.

    I was under the impression that this was supposed to handle conversion of cylindrical to cubic properly (because it should already know that a cylindrical image is being dragged into it, due to it's size ratio). Is this not the case?

  • Hi,

    because it should already know that a cylindrical image is being dragged into it, due to it's size ratio


    It's not possible to differ between spherical and cylindrical projecting depending on the size-ratio.
    In both cases any size-ratio is possible.

    And the convert tool assumes spherical as default projection.
    Cylindrical projection would require the -cylinder parameter, but that's currently only available when directly calling the tool.

    But 'automatically' converting partial panos without any additional information is generally a bit problematic:
    - the horizontal fov can be also anything (360 is just used as default)
    - the vertical fov can be calculated when knowing the horizontal fov and the projection, but the vertical offset can be also anything.

    That means these information are essential to be able to convert a pano image.
    There exists EXIF meta information to provide these information (from the camera or from the stitcher), but today only for spherical projection images. When outputting a cylinder image in PTGUI, no EXIF information about the projection or fov are included.

    That means correctly converting cylinder image is currently possible only manually by specifying all information, e.g. this way:

    Code
    krpanotools spheretocube CUBE input.jpg pano.jpg -cylinder


    or when the horizontal fov is not 360 and/or if there is a vertical offset:

    Code
    krpanotools spheretocube CUBE input.jpg pano.jpg -cylinder -infov=300x100/20

    Best regards,
    Klaus

  • It's not possible to differ between spherical and cylindrical projecting depending on the size-ratio.

    Given that both images are going to be 360 panoramas, if one image is equirectangular than it is spherical, if the image is not, then it is cylindrical.

    How is that "not possible"?

    You even provide an example command-
    krpanotools spheretocube CUBE input.jpg pano.jpg -cylinder


    The only additional information provided above is "-cylinder". If the supplied 360 image (which should always be considered the default) is not equirectangular than you would/could already know that yes? So why even require it in such a case?


    EDIT:
    The reason I am bringing this up is that for many years, dragging a cylindrical panorama onto krpano's make pano droplets resulted in creation of proper viewable panorama. Now it appears there is no way to do that. Why has this functionality been lost? Furthermore, why are you suddenly saying "it is not possible" when I have thousands of cylindrical panoramas made with your software over a decade that says otherwise?

    EDIT 2- UPDATE:

    I have now created a simple droplet with Pano2VR that automatically converts a cylindrical panorama dropped upon it to proper cube faces. No extra information is required for input. Pano2VR just figures it out and does the right thing. What you have stated is "not possible" is most certainly not the problem you think it is. Why this is not possible for Krpano all of a sudden escapes me, but whatever. It's your program.

    2 Mal editiert, zuletzt von brad (11. Januar 2022 um 15:27)

  • Hi,

    it's about the 'default assumptions' - should an undefined image be spherical or cylindrical.

    Zitat

    Why has this functionality been lost?


    Only the default settings of the make droplet have been changed - now since multiresolution cylindrical panos are directly supported, it makes much more sense to use them also without cube-conversion. That's faster, provides higher image quality and needs less memory and storage space.

    That means just drop the cylindrical image on the MAKE VTOUR Droplet,
    then edit the pano-type and set it to Cylinder and optionally adjust the fov and/or correct the horizon.

    See here for how to do that:
    https://youtu.be/pzOpGmKNTJM?t=62

    and here for more details:
    krpano 1.20.9 - New MAKE VTOUR Droplet, Panotype-Editor, Leveling, Chroma-Key/Transparent-Videos, Updates for macOS Big Sur and iOS 14

    Best regards,
    Klaus

  • should an undefined image be spherical or cylindrical

    There is no "undefined", if an image is equirectangular than it is a spherical panorama, if it is not then it is a cylindrical panorama. Don't know why I have to point this out yet again. Mind you- this is for 360 panoramas.


    As far as dragging a cylindrical panorama onto the VTour droplet, it does not wok properly. Hence the reason why I have posted about the issue to begin with. In the config file there is "panotype=autodetect". Why even have "autodetect" if you are not in fact "autodetecting" anything? In fact, "hvof=360" is also already a default, and yet with that additional information Vtour still isn't making the correct files. Even when panotype is set to "cylinder".

    EDIT:
    Are you just pretending to not know the how to tell the difference between a cylindrical panorama and a spherical one? Because I am finding it hard to believe that after all these years you suddenly think it's some impossible problem. This is basic stuff and now krpano all of a sudden (to me anyway) can't deal with them properly. Which is surprising to say the least.

    Einmal editiert, zuletzt von brad (11. Januar 2022 um 18:52)

  • I am seeing now on one of the pages you linked to, the following-

    "A difference to the old droplets is the processing of partial-panos -
    instead of asking the user for the pano-type, now all
    non-cubical/non-full-spherical panos (or image without Photoshpere EXIF
    metadata) will be always automatically build as 'flat'-panos. This is
    intentional because the tile/image-structure is the same for flat-,
    spherical- and cylindrical-panos and because the updated VTour Editor
    has now a new tool for changing the pano-type and pano-field-of-view
    later after building."

    This is actually a much worse situation you have made now that completely screws up fast and simple production flows with regards to 360 cylindrical panoramas.

    There is no need for manual intervention for each and every cylindrical panorama that needs to be converted. Yet now you are requiring such a detour? How does this make ANY sense at all?

    I will state it here as clearly as possible, again-


    I need to drag a 360 cylindrical panorama onto krpano and have it produce a proper panorama ready to go. With no other interaction required.

    I need to, when required, drag a 360 cylindrical panorama into krpano and have it output proper cube faces with no other interaction required.

    Krpano currently cannot do this, correct? It used to- but now it cannot. Correct?
    Because that seems to be exactly the case. And if so, then these panoramas need to be handled by some other program that is capable of doing it.

  • Hi,

    First - why so aggressive?!
    That's not helpful in any way!
    I'm ready to help, otherwise I would not write here.

    I will add settings for the next release to allow automateing your usage case (more about that when I have some time for checking that in detail) - but that doesn't mean your needs are the only onces and that are the only right ones.

    In versions before 1.20.8 the makepano tool was asking for the panotype and the fov in this case. So a manual intervention was necessary there too.

    That manual intervention was now moved to one step later in the editor. And beside of the technical stuff (faster, better quality) it now even allows using images that couldn't be used before. Projections that couldn't be automatically detected, can now be changed quick and easy without the need of manually rebuilding the image. Additionally there are longer term plans behind this, that whole process will get even more changed and improved.

    Beside of that I agree of course that more settings for automatizing special cases can be helpful. I have no problem with that.


    Zitat

    Are you just pretending to not know the how to tell the difference between a cylindrical panorama and a spherical one? Because I am finding it hard to believe that after all these years you suddenly think it's some impossible problem. This is basic stuff...

    Yes, I'm trying to telling you that, but unfortunately I'm not that good at explaining...

    Here two images:

    And they have these pixel-sizes: 2048x711 and 2048x757

    So based on ONLY(!) these pixel-size information, how can you tell me which image has a spherical projection and which one has cylindrical projection?
    That's impossible, please think about it.

    Best regards,
    Klaus

  • So based on ONLY(!) these pixel-size information, how can you tell me which image has a spherical projection and which one has cylindrical projection?
    That's impossible, please think about it.

    Are you even reading what I am writing? I am talking about progmmatically knowing the difference between an equirectangular 360 panorama (and thus spherical) and a 360 cylindrical panorama, when the following are already given to be true- 360 HFOV, which is what a 360 panorama is.

    If I provide an equirectangular 10,000 x 5,000 panorama, then obviously a spherical projection is assumed. Even your own documentation states this is the case.

    If it is a 10,000 x 3,000 panorama, then it is cylindrical.

    I am puzzled as to why you all of a sudden can't figure this out and are arguing with me about it when it can't be more obvious.

    Einmal editiert, zuletzt von brad (11. Januar 2022 um 21:32)

  • In versions before 1.20.8 the makepano tool was asking for the panotype and the fov in this case. So a manual intervention was necessary there too.


    Yes, which was *completely unnecessary* if one was to default to 360 HFOV and compare if either equirectangular or cylindrical.

    Moving this selection to the editor doesn't work because my xml files require different XML paths and thus will not load in your editor. No big deal because I do not want to have to manually edit each panorama anyway. Furthermore, trying to add cylinder option this the config file defaults, does not work either.

  • but that doesn't mean your needs are the only onces and that are the only right ones.

    Again with the gaslighting. These are not just "my needs", it is how software should work to properly handle cylindrical panoramas vs spherical panoramas. You are over-thinking things and bringing edge-cases into it as if it were what I was talking about. Which it isn't. I have already shown how Pano2VR has no issue with this whatsoever, yet you consider it "impossible".

    EDIT:

    Note that I have been using your software for probably over 18 YEARS. Making panoramas full-time for 25 years. I am not pulling this stuff out of thin air. If you are not understanding my point it's only because you are not taking time to actually understand the issue I am talking about.

    2 Mal editiert, zuletzt von brad (11. Januar 2022 um 21:21)

  • I fully understand you - you say every non 360x180 image should be considered as (centered) cylinder, right?

    Unfortunately there are also many other usage cases where this is not the solution. I would even say that centered 360 cylinder images are the exception (at least to my(!) experience due requests). And when cylinders are used, then the horizon is often not in the center. When such image is considered as centered cylinder and get converted to a cube, then there is no way to correct that later anymore. But by not converting to cube and just setting the pano type and the fov in the xml, this is an easy to solve problem.

    But okay, as written above my offered solution are settings to allow configuring the krpano tools for your usage case.
    E.g. so that every non 360x180 image should get processed as cylinder.


    What would be your proposed solution?


    Btw - as manual 'workaround' for the moment you could replace all '<flat' with '<cylinder' texts in the xml (search & replace).

    Btw2:

    Zitat

    Moving this selection to the editor doesn't work because my xml files require different XML paths and thus will not load in your editor.

    Do you have an example?
    Such things could be addressed of course.

  • I had just finished typing a lengthy response but then your forum logged me out without warning and all of it was lost.
    Not going to type a long one again.

    In short,
    Yes it should be the default. There should be a baseline to start off, no reason why that shouldn't be it.

    If not going to use defaults, "MakeVTour" should work with cylinders properly through the config files, without having to use VTour Editor as a second step. Currently this is not the case. Changing "panotype=" appears to have no effect on the output.
    "Convert Tool"- If you aren't going to have default options, one should be able to specify things like cylinder etc in a config but it appears this is not possible.

  • RE: "Btw - as manual 'workaround' for the moment you could replace all '<flat' with '<cylinder' texts in the xml (search & replace)."


    Tried the above and it does not work. It still shows a flat pano instead of a cylindrical one.
    EDIT:

    Ok, got it to work but apparently HFOV also needs to be replaced in the XML and so does VFOV because they aren't being calculated for cylindrical panoramas.
    EDIT 2:
    The config file glitch issue described below has changed the issue above. Initially the generated XML was showing <flat.. but the VFOV was set to something like "1.0034", hence why I had to manually put in the VFOV when changing <flat.. to <cylinder.. Now I don't have to do that.

    2 Mal editiert, zuletzt von brad (12. Januar 2022 um 08:44)

  • I switched to a different "template/config" file in the Krpano Tools MakeVtour ui via the pop-up menu, generated a panorama that I threw out, and then switched back to the "template/config" I originally had selected and now changes to "panotype=" are having the proper effect, where it was not before, even though it was using other params in that config file correctly (I know this because I use a different naming convention on the generated files from default).
    What is going on here then that would cause this? Is there some sort of temp cache files or something going on? Or something left over from a different version of Krpano when upgrading?
    Anyway- this is working now regardless, so I created two configs, one for regular panoramas and one for cylindrical and switch between them. One more file to keep track of between version upgrades but not a big deal. Maybe this was a glitch on my own system or not, I don't know now because I am unable to reproduce it.

    Speaking of the "MakeVTour" panel, it would be nice if one did not always have to click the "Close" button in that panel each time after generating a panorama in order to generate another one?
    This still leaves the original issue with the "Convert Tool" though. Why would I create cube faces for a cylindrical panorama? I do this when I have cylindrical panoramas (legacy images shot with Panoscan MK3) that have 90 degrees or more of VFOV. And previously, for player compatibility issues (when krpano or other programs or player don't support certain features for cylinders, but do when they are cubic).

  • Hi,

    there is new version out, which includes also improvements for this topic:
    https://krpano.com/docu/releasenotes/#top

    The panotype config setting has now an optional second parameter to define the type for images that can't be detected.

    The default is:

    Code
    panotype=autodetect,flat


    for your case change that to:

    Code
    panotype=autodetect,cylinder

    The Convert Droplet has now also an option for enabling cylindrical processing.

    Best regards,
    Klaus

Jetzt mitmachen!

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