В целом вы правы. Но так как libtorch это конкретный артефакт(библиотека) который компилируется из репозитория PyTorch то я предпочитаю говорить про PyTorch.
Здравствуйте, в общем случае увеличения производительности не будет, так используется одно и тоже ядро библиотеки. Получить выигрыш в скорости можно, например если будут использоваться специальные методы обработки данных оптимизированные c использованием C/С++/SIMD и таким образом можно исключить преобразование/передачу данных в структуры Python. Такая обработка может быть как в начале pipeline так внутри сети если использовать динамический граф. Ещё как вариант если сеть/pipeline описана на C++ может быть проще работать со специализированными расширениями для того же PyTorch, например если нужен прямой доступ к тензорам(их памяти), так не надо прокидывать специализированную функциональность через python bindings.
Здравствуйте, да думаю увеличение количества направлений может улучшить результат. Решение с HOG было в основном использовано для демонстрации одного из классических вариантов решения, сейчас можно использовать решения на базе NN которые будут более точными и функциональными, и возможно сравнимыми по производительности.
Ссылка в начале статьи, проект опубликован тут https://gitflic.ru/project/kolkir/androidobjectdetection
В целом вы правы. Но так как libtorch это конкретный артефакт(библиотека) который компилируется из репозитория PyTorch то я предпочитаю говорить про PyTorch.
А как выбираются соседние элементы для конкретной точки? С помощью knn и деревьев разбиений?
Здравствуйте, в общем случае увеличения производительности не будет, так используется одно и тоже ядро библиотеки. Получить выигрыш в скорости можно, например если будут использоваться специальные методы обработки данных оптимизированные c использованием C/С++/SIMD и таким образом можно исключить преобразование/передачу данных в структуры Python. Такая обработка может быть как в начале pipeline так внутри сети если использовать динамический граф. Ещё как вариант если сеть/pipeline описана на C++ может быть проще работать со специализированными расширениями для того же PyTorch, например если нужен прямой доступ к тензорам(их памяти), так не надо прокидывать специализированную функциональность через python bindings.
Здравствуйте, да думаю увеличение количества направлений может улучшить результат. Решение с HOG было в основном использовано для демонстрации одного из классических вариантов решения, сейчас можно использовать решения на базе NN которые будут более точными и функциональными, и возможно сравнимыми по производительности.