Talk:Proposal 0.4 - Revision history

Petibub: /* Datatype: Complex spectra */

2013-05-28T16:11:47Z

Datatype: Complex spectra

← Older revision		Revision as of 18:11, 28 May 2013
Line 1:		Line 1:
	== Datatype: Complex spectra ==		== Datatype: Complex spectra ==

		⚫	'''Fixed''': Conventions and DataType proposed.

			Discussion

	A new datatype has been requested, allowing to store complex spectra. While in general quite clear what to do, a few details require clarification:		A new datatype has been requested, allowing to store complex spectra. While in general quite clear what to do, a few details require clarification:
Line 6:		Line 10:

	* It seems like saving data for (sparse) discrete frequencies as complex spectra might be interesting for HRTFs coming directly from BEM simulations. New conventions and its needs in general SOFA specs are being discussed		* It seems like saving data for (sparse) discrete frequencies as complex spectra might be interesting for HRTFs coming directly from BEM simulations. New conventions and its needs in general SOFA specs are being discussed
⚫	* '''Fixed''': Conventions and DataType proposed.

	== Coordinate systems ==		== Coordinate systems ==

Petibub: /* Fix if datatypes can change within conventions */

2013-05-28T16:04:20Z

Fix if datatypes can change within conventions

← Older revision		Revision as of 18:04, 28 May 2013
Line 1:		Line 1:
	== Fix if datatypes can change within conventions ==
	When we say "conventions" do we mean a fixed data type?
	* yes: because it will be very easy for applications: they just have to check the conventions and the data type is fixed. On the other hand, we'll need a separate conventions for each datatype even though the measurement setup might have not changed.
	* no: we will have conventions which do not consider the datatype (=less conventions). On the other hand, each application has either to provide '''all''' datatypes or to check two things: conventions '''and''' datatype

	== Datatype: Complex spectra ==		== Datatype: Complex spectra ==

Petibub: /* Fix versioning of SOFA and conventions */

2013-05-28T16:03:47Z

Fix versioning of SOFA and conventions

← Older revision		Revision as of 18:03, 28 May 2013
Line 1:		Line 1:
	== Fix versioning of SOFA and conventions ==
	For the moment, we have a version number for the SOFA specs and each conventions has its own version number. This appears rather much, but gives us more freedom (formulate that!)

	== Fix if datatypes can change within conventions ==		== Fix if datatypes can change within conventions ==
	When we say "conventions" do we mean a fixed data type?		When we say "conventions" do we mean a fixed data type?

Petibub: /* Fix mandatory metadata */

2013-05-28T16:02:10Z

Fix mandatory metadata

← Older revision		Revision as of 18:02, 28 May 2013
Line 1:		Line 1:
	== Fix mandatory metadata ==

	The table is in the main page. I used the following rules:
	* Mandatory because without this metadata '''any''' conventions will fail
	* Or, mandatory because users might forget it, resulting in inconsistencies for '''all''' conventions

	In other words, my suggestion represents the minimal version of any conventions. Let's see if this is consistent...

	== Fix versioning of SOFA and conventions ==		== Fix versioning of SOFA and conventions ==
	For the moment, we have a version number for the SOFA specs and each conventions has its own version number. This appears rather much, but gives us more freedom (formulate that!)		For the moment, we have a version number for the SOFA specs and each conventions has its own version number. This appears rather much, but gives us more freedom (formulate that!)

91.119.127.146: /* Datatype: Complex spectra */

2013-05-27T19:51:14Z

Datatype: Complex spectra

← Older revision		Revision as of 21:51, 27 May 2013
Line 22:		Line 22:

	* It seems like saving data for (sparse) discrete frequencies as complex spectra might be interesting for HRTFs coming directly from BEM simulations. New conventions and its needs in general SOFA specs are being discussed		* It seems like saving data for (sparse) discrete frequencies as complex spectra might be interesting for HRTFs coming directly from BEM simulations. New conventions and its needs in general SOFA specs are being discussed
			* '''Fixed''': Conventions and DataType proposed.

	== Coordinate systems ==		== Coordinate systems ==

Petibub: /* Datatype: Complex spectra */

2013-05-23T07:58:05Z

Datatype: Complex spectra

← Older revision		Revision as of 09:58, 23 May 2013
Line 21:		Line 21:
	* Most of the measured IRs are real-valued. Complex spectra introduce redundancy for those IRs, resulting in increase of the file size. This disadvantage might be small because of the compression available in SOFA. Another way to handle that would be to store only parts of the spectra. This issue should be clarified.		* Most of the measured IRs are real-valued. Complex spectra introduce redundancy for those IRs, resulting in increase of the file size. This disadvantage might be small because of the compression available in SOFA. Another way to handle that would be to store only parts of the spectra. This issue should be clarified.

			* It seems like saving data for (sparse) discrete frequencies as complex spectra might be interesting for HRTFs coming directly from BEM simulations. New conventions and its needs in general SOFA specs are being discussed
	The corresponding requester/researcher has been contacted. Waiting for response...

	== Coordinate systems ==		== Coordinate systems ==

Petibub: /* Coordinate systems */ new section

2013-05-17T15:36:58Z

Coordinate systems: new section

← Older revision		Revision as of 17:36, 17 May 2013
Line 22:		Line 22:

	The corresponding requester/researcher has been contacted. Waiting for response...		The corresponding requester/researcher has been contacted. Waiting for response...

			== Coordinate systems ==

			Need to fix a few details:
			* In "spherical": Elevation angle vs. Zenith angle
			* Quaternions?

Petibub: /* Datatype: Complex spectra */ new section

2013-05-17T15:25:28Z

Datatype: Complex spectra: new section

← Older revision		Revision as of 17:25, 17 May 2013
Line 14:		Line 14:
	* yes: because it will be very easy for applications: they just have to check the conventions and the data type is fixed. On the other hand, we'll need a separate conventions for each datatype even though the measurement setup might have not changed.		* yes: because it will be very easy for applications: they just have to check the conventions and the data type is fixed. On the other hand, we'll need a separate conventions for each datatype even though the measurement setup might have not changed.
	* no: we will have conventions which do not consider the datatype (=less conventions). On the other hand, each application has either to provide '''all''' datatypes or to check two things: conventions '''and''' datatype		* no: we will have conventions which do not consider the datatype (=less conventions). On the other hand, each application has either to provide '''all''' datatypes or to check two things: conventions '''and''' datatype

			== Datatype: Complex spectra ==

			A new datatype has been requested, allowing to store complex spectra. While in general quite clear what to do, a few details require clarification:
			* Do data exist? Most of the data are saved as IRs and can be easily transformed to frequency domain on loading by the application. Data natively stored as spectra or special needs for storing data directly as spectra would help.
			* Most of the measured IRs are real-valued. Complex spectra introduce redundancy for those IRs, resulting in increase of the file size. This disadvantage might be small because of the compression available in SOFA. Another way to handle that would be to store only parts of the spectra. This issue should be clarified.

			The corresponding requester/researcher has been contacted. Waiting for response...

Petibub: /* Fix mandatory metadata */

2013-05-17T15:10:59Z

Fix mandatory metadata

← Older revision		Revision as of 17:10, 17 May 2013
Line 1:		Line 1:
	== Fix mandatory metadata ==		== Fix mandatory metadata ==

			The table is in the main page. I used the following rules:
			* Mandatory because without this metadata '''any''' conventions will fail
			* Or, mandatory because users might forget it, resulting in inconsistencies for '''all''' conventions

			In other words, my suggestion represents the minimal version of any conventions. Let's see if this is consistent...

	== Fix versioning of SOFA and conventions ==		== Fix versioning of SOFA and conventions ==

Petibub: Created page with "== Fix mandatory metadata == == Fix versioning of SOFA and conventions == For the moment, we have a version number for the SOFA specs and each conventions has its own version..."

2013-05-17T15:06:57Z

Created page with "== Fix mandatory metadata == == Fix versioning of SOFA and conventions == For the moment, we have a version number for the SOFA specs and each conventions has its own version..."

New page

== Fix mandatory metadata ==

== Fix versioning of SOFA and conventions ==
For the moment, we have a version number for the SOFA specs and each conventions has its own version number. This appears rather much, but gives us more freedom (formulate that!)

== Fix if datatypes can change within conventions ==
When we say "conventions" do we mean a fixed data type?
* yes: because it will be very easy for applications: they just have to check the conventions and the data type is fixed. On the other hand, we'll need a separate conventions for each datatype even though the measurement setup might have not changed.
* no: we will have conventions which do not consider the datatype (=less conventions). On the other hand, each application has either to provide '''all''' datatypes or to check two things: conventions '''and''' datatype