Sinuosity dependent on call box size?

[VoiceScientist]

The DeepSqueak "export-to-excel" page of the wiki defines sinuosity as the "Length of the path between the first and last points on the contour, divided by the euclidean distance between the first and last points". I've always thought this meant the measure was only dependent on the detected contour. However, we've discovered that sinuosity changes when the box around the detected call is changed. I assume this is because the detected contour is slightly changing, but the variability is higher than I expected. Attached is a pdf with an example of the sinuosity changing from 1.3474 to 2.4172 as we increase the height and width of the box. Any best practices to reduce this variability and find the "true" sinuosity? Thanks.
SinuosityBoxSizeComparison.pdf

[livelovelarynx]

I've had this issue too! Please advise if you have suggestions...

[DrCoffey]

Ok, I found the spot with the code: CalculateStats line 126

try
D = pdist([stats.ridgeTime' stats.ridgeFreq_smooth],'Euclidean');
Z = squareform(D);
leng=Z(1,end);
c=0;
for ll=2:length(Z)
c=c+1;
totleng(c)=Z(ll-1,ll);
end
stats.Sinuosity=sum(totleng)/leng;
catch
stats.Sinuosity = 1;
end

It looks like it is using the contour, but it is very sensitive to changes in wavy contours. In the example below the contour jumps up and down while the call transitions from low to high freq.

[DrCoffey]

If we change line 127 to include additional smoothing the sinuosity is much more stable, but also much lower:

D = pdist([stats.ridgeTime' smooth(stats.ridgeFreq_smooth,10)],'Euclidean');

[DrCoffey]

I'll have to think about how to change this because it will mess with comparisons to old files. I you have any suggestions, let me know.

[VoiceScientist]

Thanks for the quick response. I certainly appreciate the concern about backwards compatibility. How heavy of a lift would it be to add a contour smoothing option (maybe in the call detection options)? Or if no one else wants this feature, we could just add the code above to our version. We'll experiment with how much smoothing is necessary to keep sinuosity fairly stable for our specific data. Was there a specific rationale for the value '10' you used?

[DrCoffey]

10 samples of smoothing was totally random. I'll try to think about a more permanent solution....

[VoiceScientist]

We tried different levels of smoothing, but I think the way the sinuosity is calculated isn't the problem. It really seems to be the variability in how the contour is detected based on the box size. Do you have any advice on how to reduce that variability? We often end up manually redrawing the boxes to get the contour to more accurately resemble what we see in the spectrogram, but that introduces a level of human-based variability I'd like to avoid. We have thought about training our own network based on our data. Do you think that would improve consistency in the contour detection? The default network picks up our USVs, I'm just wanting to improve the consistency of the contour (and, subsequently, the measure of sinuosity). If we do train our network, do we follow the two steps in the wiki instructions? Are there any more detailed guides? Thanks.

[DrCoffey]

I played around with the example file and this seems to be a bigger issue for trills where the contour is harder to extract, which is unfortunate as they have the high sinuosity you are looking to capture. We have played around with a lot of automated contour extraction methods and haven't found one that works better on a broad range of files and calls. If you can find a better solution, we would love to integrate it, I'm always ready to review pull requests! Unfortunately, I don't have time for actual development at the moment.

[VoiceScientist]

Thanks - we'll keep exploring and keep you posted.