wingtracking bug

[allenleetc]

Sweta A reported a bug (see unheatedpassivechase20150917132253_CSP1xtrp_1xsqmag_1_40hz) where tracked wings appear on the opposite side of actual wing extension.

Investigation reveals apparent bugs in wingtracking:

• During an initial pass at wingtracking (Track2FliesWings1Frame1ROI), wing data (trx.wing_anglel, perframedata.wing_areal etc) are computed for all 4 possible combinations of fly orientations: {fly1,fly2} x {forwards,backwards}.
• During a later stage (Track2FliesWings2), identities are assigned to tracks (either by 'size' or 'wingsize'). This can lead to tracks being swapped, eg it is decided that trx(2) is actually fly1 for certain frames etc.
• The bug is that the swapping of tracks is not carried over appropriately to the previously-computed wing data. So in a simple case, tracks 1 and 2 are exchanged, but the wing data is left untouched and is not transformed. Later, when chooseorientations3 is run to resolve head/tail, wingdata is pulled out using the incorrect indices (because chooseorientations3 is performed relative to the swapped indices).

Moreover, in sha 5071a49, Track2FliesWings2.m:Line289 just looks like a bug, those arrays are 3D with size 1 x Nfrm x 4, so the code as written is only swapping the first page/combination of data for each wing PFF, rather than swapping the data for all 4 combinations.

[allenleetc]

Appears fixed, but generally speaking risk in this area is still high due to state of code. Fix tested by fully retracking Sweta experiment and browsing significant/large before/after differences in wingtracking. Improvements confirmed by AR. Awaiting further confirmation from Sweta.