Hotspot getcenter wrong result

Umalo

Profi

Beiträge: 1 051

Wohnort: Osijek, Croatia, EU

1

Sonntag, 17. Dezember 2017, 21:16

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:

Quellcode

<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"/>		
</hotspot>

Result is:
ath= 0.05000000000001137
atv= 0

It should be: 0.05 and 0.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Umalo« (18. Dezember 2017, 13:44)

Zum Seitenanfang

spacerywirtualne

Profi

Beiträge: 1 117

Wohnort: Poland, Europe

Beruf: krpano developer : virtual tours : the cms4vr owner

2

Montag, 18. Dezember 2017, 12:19

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
Piotr

»spacerywirtualne« hat folgendes Bild angehängt:

Your own professional, online cloud tool for creating virtual tours - www.cms4vr.com

facebook page :: youtube :: wiki.cms4vr.com

cms4vr team *thumbsup*

Zum Seitenanfang

Umalo

Profi

Beiträge: 1 051

Wohnort: Osijek, Croatia, EU

3

Montag, 18. Dezember 2017, 13:08

Zitat von »spacerywirtualne«

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.

Zum Seitenanfang

$»indexofrefraction« ist offline$ indexofrefraction

Profi

Beiträge: 1 362

4

Montag, 18. Dezember 2017, 13:34

@umalo

hotspot[test].getcenter(ath,atv);
roundval(ath, 3);
roundval(atv, 3);

if you want more precision, use 4 or 5

zFilter plugin -- zFlare plugin -- zSnapshot plugin

Zum Seitenanfang

Umalo

Profi

Beiträge: 1 051

Wohnort: Osijek, Croatia, EU

5

Montag, 18. Dezember 2017, 13:46

Seams headline was misleading you in direction of seeking for rounding solution while I was pointing to offset in real center vs krpano calculated.
Changed headline to Wrong result.
Thanks anyway.

Zum Seitenanfang

spacerywirtualne

Profi

Beiträge: 1 117

Wohnort: Poland, Europe

Beruf: krpano developer : virtual tours : the cms4vr owner

6

Montag, 18. Dezember 2017, 15:14

You're right Umalo. In gigapanoramas, the precision is very important and crucial.

Kind regards
Piotr

Your own professional, online cloud tool for creating virtual tours - www.cms4vr.com

facebook page :: youtube :: wiki.cms4vr.com

cms4vr team *thumbsup*

Zum Seitenanfang

$»indexofrefraction« ist offline$ indexofrefraction

Profi

Beiträge: 1 362

7

Montag, 18. Dezember 2017, 19:34

you should clarify what you want...

Zitat

Result is:
ath= 0.05000000000001137

i dont understand it ... this is the result of what?

zFilter plugin -- zFlare plugin -- zSnapshot plugin

Zum Seitenanfang

Alexey Tkachenko

Profi

Beiträge: 770

Wohnort: Russian Federation

Beruf: Interpreting, Building virtual tours

8

Dienstag, 19. Dezember 2017, 07:30

Hi)

Umalo wants more precise result of getcenter function fot the hotspots https://krpano.com/docu/xml/#hotspot.getcenter

Correcte me, if I misunderstood something (sorry then, Umalo). ;-)

Regards,

Alexey

Zum Seitenanfang

klaus.krpano

Administrator

Beiträge: 13 499

9

Dienstag, 19. Dezember 2017, 10:01

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

Zum Seitenanfang

Umalo

Profi

Beiträge: 1 051

Wohnort: Osijek, Croatia, EU

10

Dienstag, 19. Dezember 2017, 14:39

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.

Zum Seitenanfang

Umalo

Profi

Beiträge: 1 051

Wohnort: Osijek, Croatia, EU

11

Samstag, 23. Dezember 2017, 22:40

Hi Klaus

See what I am getting when placing result at hotspot center. This is how I came to testing more to see if my code is wrong or Krpano Hotspot getcenter.

Zum Seitenanfang

klaus.krpano

Administrator

Beiträge: 13 499

12

Donnerstag, 28. Dezember 2017, 15:51

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:
https://arxiv.org/ftp/arxiv/papers/1212/1212.3193.pdf

Best regards,
Klaus

Zum Seitenanfang

Umalo

Profi

Beiträge: 1 051

Wohnort: Osijek, Croatia, EU

13

Donnerstag, 28. Dezember 2017, 18:05

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:

Zum Seitenanfang

klaus.krpano

Administrator

Beiträge: 13 499

14

Sonntag, 21. Januar 2018, 12:20

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:

Zitat

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

Zum Seitenanfang

Umalo

Profi

Beiträge: 1 051

Wohnort: Osijek, Croatia, EU

15

Sonntag, 21. Januar 2018, 21:29

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.
Regards
Umalo

Zum Seitenanfang

klaus.krpano

Administrator

Beiträge: 13 499

16

Sonntag, 21. Januar 2018, 23:58

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

Zum Seitenanfang

Umalo

Profi

Beiträge: 1 051

Wohnort: Osijek, Croatia, EU

17

Montag, 22. Januar 2018, 10:57

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)

Quellcode

<hotspot name="test" keep="true" ath="0" atv="0" align="center" edge="center" fillcolor="123456" fillalpha="0.9" borderwidth="2" bordercolor="123456"
  onloaded="showlog();  
  hotspot[test].getcenter(ath_center,atv_center);  
  trace('center ath:',get(ath_center));
  trace('center atv:',get(atv_center));  
  "> 
  <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"/>		
</hotspot>

When result is:

	Quellcode
1 2	INFO: center ath:0.05000000000001137 INFO: center atv:0

It is clearly not calculating correct center.

Zum Seitenanfang

klaus.krpano

Administrator

Beiträge: 13 499

18

Montag, 22. Januar 2018, 13:05

Why?
0.05 / 0.0 is correct.

Or do you mean the 0.00000000000001137 difference for ath?
If yes, please see here for more:
http://floating-point-gui.de/

Visually that wouldn't matter, even with very very very deep-zoomed flat panos ;-)

.
You can safely skip/round everything behind the 6 decimal point.

Best regards,
Klaus

Zum Seitenanfang

Umalo

Profi

Beiträge: 1 051

Wohnort: Osijek, Croatia, EU

19

Montag, 22. Januar 2018, 14:09

Comparing two images (krpano get center and mine) you will see why following statements are not applicable:
"Visually that wouldn't matter, even with very very very deep-zoomed flat panos ;-)

.
You can safely skip/round everything behind the 6 decimal point."

Krpano get center
New center

Zum Seitenanfang

klaus.krpano

Administrator

Beiträge: 13 499

20

Montag, 22. Januar 2018, 14:34

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.

Zum Seitenanfang