Hotspot getcenter wrong result

  • Hi Klaus

    Can you please improve get center function to give more precised results, please? *love* When working on big Flat where high precision is needed (doing polygonal area calculation) there seams to be some internal rounding in the Krpano making result with just small offset to real result.

    Test with simple 4 point poli hotspot:

    <hotspot name="test" keep="true" ath="0" atv="0" align="center" edge="center" fillcolor="123456" fillalpha="0.9" borderwidth="2" bordercolor="123456"> 
    <point ath="-0.2" atv="0.2"/>
    <point ath="0.30" atv="0.20"/>
    <point ath="0.30" atv="-0.20"/>
    <point ath="-0.20" atv="-0.20"/>		

    Result is:
    ath= 0.05000000000001137
    atv= 0

    It should be: 0.05 and 0.

    Edited once, last by Umalo (December 18, 2017 at 1:44 PM).

  • The reason is IEEE 754

    I use roundval in this case. I know that there are different methods in a clean JS, but it seems to me that Math.round(num) is better than num.toFixed(0);. I think roundval is enough.

    Kind regards

  • I use roundval in this case.

    Thanks for your try but it is other way around. I need not rounded result as I work with huge Flat pano. We know that ath and atv values there are very smll so I need as precised NOT rounded result. As part of the code I also display selected area rounding would make mistakes. So I need correct (as possible) result in first place. If I would work on sphere system then this rounding would be used.
    Waiting for Klaus opiniion if he can come up with something.

  • Hi,

    there is no rounding here, but getcenter doesn't return the average of the ath/atv values.

    First the ath/atv values will be converted to 3d vectors, then these 3d vectors will be averaged and then the resulting 3d vector will be converted back to the 'center' ath/atv value. So the result can be different to an averaging of the ath/atv values.

    But I don't understand where the problem here is, even with very large gigapixel panos, that point should be in the in 'center/middle' of the polygon, the precising will be never intentional reduced...

    Best regards,

  • Simple use case I posted in my first post with 4 points is giving center that has offset to real center.
    Real center should be: ath= 0.05000000000000000 Krpano gives ath= 0.05000000000001137 for center.
    Do you really need to go in sphere to coordinate conversions as simple sum of ath divided by number of points gives correct ath as center? If we do the same for atv result should be exact. Or?
    I have project where I am calculating area of selected object using polygonal hotspots. I place result in center of the polygonal hotspot which is visually never real hotspot center. Then I went into simple posted use case to see if result from Krpano center is correct and I see it is not. Before going into doing calculations of center on my own wanted to check with you if you see some bug in Krpano calculations there what you can fix for next versions.

  • Hi,

    okay, the hotspot getcenter function might be too simple for this case - it calculates only the average of the <point> coordinates...

    Check if there are no double-points (e.g. the same point for the start and end of the polygon), because these would shift the center point.

    For generally visually better results more complex algorithm would be required - e.g. something like this by finding the largest fitting circle:

    Best regards,

  • Thanks for hint but this is not the case. Now I made my own calculator of the center and result is different to what Krpano is giving. I still think you are calculating average of the <point> coordinates where due to work with huge number of decimal points (maybe also floating point as suggested by spacerywirtualne) there is offset to expected result.
    What I did is first calculate sum of all points ATH. Then dividing it with number of points. And then first time making spheretoscreen conversion. I got this as result which tells me you could do the same in your get center calc internally. For me this point is solved but if you like to improve this for some other users addressing same issue in the future.

    Result with my center calculator:

  • Hi,

    could you please send me your example for testing?

    I found a bug and want to verify it also with your case.

    About the bug - here how the getcenter function was working:


    First the ath/atv values will be converted to 3d vectors, then these 3d vectors will be averaged and then the resulting 3d vector will be converted back to the 'center' ath/atv value.

    But the building of an 'average' (summing and dividing by the number of point) is wrong for 3d vectors - all vectors were unit-vectors (length 1) and I was wrongly assuming that the resulting averaged vector would be also an unit-vector (which is it not course). The correct solution is summing and then normalizing the resulting vector.

    And this leaded to the wrong values.

    Btw - about your 'own calculator' - directly working with ath/atv values will work for flat panos, but will be problematic in all other cases - the ath/atv coordinates are spherical ones, but the hotspot itself is a flat-plane. The problem will become observable especially for hotpots warping around the +180/-180 border and for hotspots around the zenith and nadir regions.

    Best regards,

  • Working example sent. Yes I guess for non Flat this need more tweaking (e.g. adding somenumber*180 to all ath values to avoid wrapping) but I needed it only for Flat panos to be able to calculate selected area so that works for me now. Looking forward to help improving Krpano.

  • Hi,

    thanks for sending the example - but in your case the problem is something different:

    Your polygon drawing code adds the last polygon point 2-3 times (I think because of the doubleclick detection code - consider using the krpano onsingleclick / ondoubleclick events instead to avoid such problems) and these duplicated points are moving the weighted center.

    For the next release I have added an automatic duplicate-point detection in the getcenter function, then these points will be skipped and the getcenter function should return the best possible center location ;-).

    Best regards,

  • Hard coded example where you can test getcetener with 4 points (no problem with dupluicated points even I easy skip last added point in my code)

    When result is:

    INFO: center ath:0.05000000000001137
    INFO: center atv:0

    It is clearly not calculating correct center.

  • With 'Visually' I mean the 0.00000000000001137 degree difference - even on a very high zoom that will be less than a screen pixel difference.

    The getcenter comparisons is different because your center code doesn't use all points defined for the polygon. When one point is defined a several times then the center will move to that point - that's the reason for the visually off-center point.

    I just wanted to explain the reasons - in the next release all cases should be solved - then the math will be more accurate and duplicated defined points will be automatically skipped.

Participate now!

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