You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To de-conflict between camera intrinsic values for drones which report the same make/model identifier for both their color and thermal camera, OpenAthena selects the intrinsic value of the nearest resolution width.
This causes an issue however when a scaled-down color image has a closer pixel width in linear terms to the thermal camera rather than the color one. E.g., a color image for this drone scaled down by 2x from the original sensor size (width 2672) would incorrectly match to the thermal camera rather than the color one:
The function getMatchingDrone in MetadataExtractor.java should be updated to use the drone of nearest width by ratio rather than linear difference. This would allow it to correctly select the color camera in scenarios such as described previously.
The text was updated successfully, but these errors were encountered:
To de-conflict between camera intrinsic values for drones which report the same make/model identifier for both their color and thermal camera, OpenAthena selects the intrinsic value of the nearest resolution width.
This causes an issue however when a scaled-down color image has a closer pixel width in linear terms to the thermal camera rather than the color one. E.g., a color image for this drone scaled down by 2x from the original sensor size (width 2672) would incorrectly match to the thermal camera rather than the color one:
The function
getMatchingDrone
in MetadataExtractor.java should be updated to use the drone of nearest width by ratio rather than linear difference. This would allow it to correctly select the color camera in scenarios such as described previously.The text was updated successfully, but these errors were encountered: