Polar to Cartesian and vice-versa conversion

[lzwicker]

We probably cannot settle on an aligned approach on how to convert Polar to Cartesian systems and vice-versa. However can we at least propose something everybody can stand behind so that when someone uses ADM-OSC, the same results are achieved?

[GuillaumeLeNost]

I would be inclined to recommend the EBU recommendation (the "inflated balloon" filling up the XYZ volume). This means that a perfect azimuth circle with nul elevation and a distance of 1 becomes a rectangular XY trajectory following the XY perimeter. See section 7.3.2.1 of this document: https://tech.ebu.ch/docs/tech/tech3388v1.pdf

---

From: lzwicker @.> Sent: 29 September 2023 17:22 To: immersive-audio-live/ADM-OSC @.> Cc: Subscribed @.***> Subject: [immersive-audio-live/ADM-OSC] Polar to Cartesian and vice-versa conversion (Issue #25)

We probably cannot settle on an aligned approach on how to convert Polar to Cartesian systems and vice-versa. However can we at least propose something everybody can stand behind so that when someone uses ADM-OSC, the same results are achieved?

— Reply to this email directly, view it on GitHubhttps://github.com/immersive-audio-live/ADM-OSC/issues/25, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAPEOR27KPZ3ZB3PLPU7A3LX43YUFANCNFSM6AAAAAA5MWNP3I. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[mzed]

More detail in section 10.1 of this: https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.2127-0-201906-I!!PDF-E.pdf

These maths are part of the EBU renderer here: https://github.com/ebu/ebu_adm_renderer/blob/master/ear/core/objectbased/conversion.py

[mzed]

That is the only official recommendation for conversion I'm aware of. That is what we should recommend if we want to be most compatible with ADM.

Note that this projects polar coordinates onto a 5.0.4 layout with corner speakers at (0º, +/-30ª, +/-110ª). Elevation is idiosyncratic, too.

[mzed]

Perhaps we should supply some boiler-plate code to help implementations? The EBU reference is Python. Should we add C/C++ too?

[madees]

This is good for implicit listener position at x=0, y=0, z=0 and straight to the front (Y axis) head orientation. Maybe worth to follow EBU work on AR, VR, head tracking and game engine compatibility to be able to define a more general approach to the transition from the physical world to individual perception and vis versa ?

[Daniel-Higgott]

I have created an open source project, written in Swift, that performs the conversion between polar and cartesian coordinate systems. You can find a link to the source code here.

I have attempted to keep the implementation as simple as possible, with the conversion happening within two small functions. The project comes with a demo app that allows the user to view the conversion. I hope that this approach will allow people to easily convert the maths to other languages, or use directly within their application.

[mzed]

@Daniel-Higgott This is a good start! The ADM spec implements a more complicated conversion: https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.2127-0-201906-S!!PDF-E.pdf The ADM-OSC stakeholders haven't made a decision about whether to require that math.

[lzwicker]

I have created an open source project, written in Swift, that performs the conversion between polar and cartesian coordinate systems. You can find a link to the source code here.

I have attempted to keep the implementation as simple as possible, with the conversion happening within two small functions. The project comes with a demo app that allows the user to view the conversion. I hope that this approach will allow people to easily convert the maths to other languages, or use directly within their application.

Awesome!

[lzwicker]

I would propose that refering to the EBU recommendation and Daniel's example code we can safely close this issue, once both has been added to the official documentation.

[firthm01]

I would be opposed to using a basic co-ordinate conversion algorithm as it doesn't represent positions within cartesian space from an allocentric perspective. The EBU algorithm should be implemented in order to ensure that, perceptually, we maintain spatial accuracy between rendering systems using the two different coordinate systems. We implemented C++ code in the EPS to do conversion; https://github.com/ebu/ear-production-suite/tree/main/reaper-adm-extension/src/reaper_adm/coordinate_conversion