PREALIGN confirmation please

  • Hi, I have a quick and simple question.
    My panos are registered with Pitch, Roll and Heading. I would not only like to adjust the Pitch and Roll, but also have the current front facing north.
    I thought a quick PREALIGN would be handy, but now (I think) I realise that prealigning with the heading (for Y) would apply an incorrect Pitch and Roll. Because the Pitch registration for instance would be the up/down value at the 'front' of the pano, so at ATH=0, or in other words, where Y = 0. Correct right?
    Unless the parameters of the PREALIGN are applied with Pitch and Roll first and then afterwards the adjustment of the Heading. But I guess not?


  • And I am sorry that I haven't been more clear:

    Our photo's are taken with the camera on a vehicle, with the middle of the pano-photo being the heading/azimuth as well as front of the vehicle.
    Calculations are simpler if the middle of the photo is North.
    At the same time we register Pitch and Roll. They are registered with the middle of the photo (front of vehicle) being direction 0.
    So, in order to prealign the photo, ideally we would like to first PREALIGN the image with [Pitch|0|Roll] and then again with [0|heading|0] ( or shift the image the amount of the heading).

    I assume that the PREALIGN with all 3 values set to something other than 0, does a whole different calculation than the one I would like to achieve...

  • Hi Klaus,

    I would still like a confirmation of the prealign adjustment.
    I would still like to know how these parameters are applied? I assume all at once, in which case I need to find a way of applying the heading (horizontal shift) in a different way.

    Just to recap: our photos are taking on a vehicle, registering Pitch and Roll of the vehicle, which coincides with the middle of the resulting equirectangular facing to the front of the vehicle (driving direction). So in order to level the equirectangular, I would like to apply PREALIGN [Pitch|0|Roll].
    At the same time, I am registering compass direction. For calculation of hotspots, and speed of loading, it is preferable to have the front of the vehicle facing north, so compass 0 (and heading 0).
    Which would require another prealign of [0|-compass|0]. Unless your PREALIGN already does this (I reckon not) and applies the horizontal shift after correcting Pitch and Roll?

    I had an action to reset heading on every photo after loading, but that also means applying it to hotspots and compass layer, which is not so difficult, but I think creates overhead and could be better managed with a prealign?

  • I'm going to make a guess about what I think you are asking.

    So you take 360-180 pano from a fixed position on a car, but the camera not being on a gimbal, when you go down a slope or have the car on a side-angle, the resulting panorama still puts the horizon smack-bang in the middle or makes it slanted. So you want to compensate for that by using pitch and roll to correct the panorama object, which means that you want to rotate the 3D object on which the equirectangular is projected on 2 axis, resulting in the appearance of going downhill ( like shooting a slope with a level pano-rig).

    Is this is the case, and the center of your equirectangular image is always facing front, then you would need to rotate pitch in the Z-axis and roll on the X-axis. This should always be true regardless of the compass direction which can simply be derived from the recorded heading.

    Is this close to what you need?

    EDIT : After looking over it again, I don't think this is your problem.. Rotating the pano is easy..

  • Hi Timescale,

    thanks for following up. Yep, you are right, it is not a problem. I am accurately registering the Pitch and Roll and I know how to apply it (either using the old PTTools or with the PREALIGN in KrPano) and level the pano. But, I also want the ATH of 0 being the same as North, so I also want to apply the registered compass/heading.
    All this can be done with the PREALIGN setting, but as you can imagine, the registered Pitch and Roll values are valid only for the direction where the ATH =0. In other words, if I look to the front of the vehicle, the nosedive of the vehicle is the registered Pitch and the left or right banking is the Roll.
    So, in order to apply those correctly, I would need to apply those with direction is 0.
    That would be step 1. And step 2 would be to rotate/shift the pano, so that the ATH=0 would be the same as compass-North. And the vehicle's front facing direction would be the registered compass/heading value.

  • just a final clarification: In my opinion, but I might be wrong, it makes a difference to the levelling if you first apply Yaw (horizontal rotation or compass direction), then Pitch and Roll OR the other way around, first Pitch and Roll, and then Yaw.
    I would like to use the latter, so I would be very happy if that's already the way PREALIGN works...

  • It looks like the coordinate system used for rotation is world based. The axis of rotation do not rotate with the object, so any rotation axis is parallel to either the Y,X or Z plane. This does indeed mean that the order of rotation matters.

    In using prealign="0|0|0", I found that roll is implemented before yaw for instance. Where it an object coordinate roll/yaw, the results would have been different as the yaw would have followed the horizon.

    Assuming this is a world coordinate driven system, you want to yaw first and then figure out what to do with roll and pitch but I don't think that is possible just with prealign. I also doubt that setting roll and pitch at a later time with set will change this because it requires a complete update of the scene, so I assume the same function is responsible for the prealignment procedure.

    I think your best bet is to simply use pitch and roll and forget about using yaw for ath0 = north and simply use an action that uses the compass data to translates the horizontal component. like with the set(heading, 0); option on the compass plugin.

  • Hi Timescale,

    And again, thanks for following up.
    I totally agree with you and probably that's the way it is setup as well. I was hoping to get confirmation from Klaus about this.

    A while ago, I already implemented the same you suggested, with a 'set(heading)'. The only thing is that I need to carefully watch and apply it as well for hotspot placements and other stuff. In itself not a problem, but it makes the whole environment less obvious to follow and read for other people. Also, I was wondering if a setheading on every pano, makes it open slower, as we have largescale projects (20.000+ panos) and I am looking to make things as easy as possible.

    I am looking at another option of applying Pitch and Roll first to all equirectangulars before slicing them for use with KRPano. It is not too difficult with the good old PTStitcher, but it takes another step and a considerable delay with a lot of panos...


  • Mmmmm...., very interesting. Just ran a testset with panos in mountainous area (steep road), and it doesn't seem to matter at all.

    The Pitch and Roll only have been applied on Set1 with PTStitcher and then in the KrPano viewer I have added PREALIGN with only heading, like: 0|hhh|0
    For Set2 I have applied all at once in KrPano, using PREALIGN like ppp|hhh|rrr

    And the outcome is totally the same! So, either Klaus is applying Pitch and Roll first and then heading with the PREALIGN (which would make me very happy :-))
    Or our assumption of application is wrong and it simply doesn't matter in which order it is applied, but that would also contradict explanations on for instance:…euler/index.htm

  • It seems to me that with the amount of imagery and associated data, the options for automated optimizations are pretty extensive.

    How are you generating the krpano XML files? From a database, dynamically or statically? Do you have to manually edit every file to add hotspots, or do you have some sort of tool to make placement easier?

    Our projects don't involve nearly that much pano's, but I figured that with 4 pano's or more in a tour, it would then even be worth it using a database driven approach and generate the XML dynamically from the DB.

    Perhaps this is could be something to consider.

    If you can link the location of a pano to a database record with the roll,pitch,yaw data, then you could automatically set-up each pano with the correct orientation. The placement of hotspots will be relative to that.

  • Yep, that is all true. But whether created dynamically or statically, there are extra actions and considerations involved if all three Pitch, Roll and Heading need to be applied for every pano and for every hotspot. I am creating the XMLs statically with a script with data in a database, which involves more or less the same calculations and is more or less the same as creating online dynamically, right...?

    But my main point is understanding what happens with the PREALIGN and as I see it now, it does exactly what I would like it to do, even though I find it strange (first P and R, then Yaw).

  • Do you mean tweaking the numbers because the data is slightly off? or something else?

    Theoretically dynamic and static should yield the same result. I tend to favor dynamic because it's easier to modify data and code, see results and not having to process an entire batch every time.

    I guess you also generate at least 2 hotspots automatically? The from and to hotspots? Re-positioning them with some form of in-pano editor would be an option.

  • Like measuring, overlaying, etc.
    I create at least 15 hotspots per pano, and a lot more on the maps. Repositioning 15 x 20.000+ hotspots is of course not very enjoyable *smile*

    In any case, whichever way you calculate, I started this thread, because I wanted to know how the PREALIGN works and if it could make life easier. I think I know now, although it is still strange, so if Klaus could confirm it would set my mind at ease..


Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!