Ваши вопросы определенно на отдаленную перспективу :) Экосистема это отличная цель, но к сожалению увидим мы ее не скоро… И прежде чем приступать к ее формированию, нужно решить ряд сугубо технических задач внутри самой библиотеки. И о какой-то конкретике говорить пока еще рано, поэтому обрисуем идею в общих чертах.
В свое время OpenCV уже пережила серьезную переделку, когда старые модули (core, aux, ml и highgui) были разбиты на ряд модулей поменьше. Это существенно упростило жизнь разработчиков, которые использовали OpenCV в реальных проектах, поскольку вы зависели только от нужных вам модулей. Это позволило упростить поддержку и сэкономить место на конечных устройствах.
То, что предполагается сделать сейчас — это продолжение этого процесса, когда вся библиотека разбивается на большее количество модулей, но меньшего размера и с более понятными ответственностями. Фактически, разработчики получат возможность собирать свою версию библиотеки, отбирая только необходимые модули, и при необходимости добавляя свои собственные.
Уже сейчас, конфигурируя сборку OpenCV при помощи CMake вы можете отобрать модули, которые необходимо собрать, и выключая ненужные модули. Это например активно используется при построении под Android, поскольку например CUDA и OpenCL там не поддерживаются, но нужен Java API и несколько специфических модулей. Кстати стоит почитать про «фиктивный» модуль opencv_world, позволяющий упростить себе жизнь при использовании такой кастомной сборки.
Таким образом, все что изменится на первых порах — это раскладка библиотеки по большему числу узконаправленных модулей. Плюс станет удобно подкладывать свои папочки с кодами таким образом, чтобы OpenCV считала их своими модулями. Впоследствии стабильные сторонние разработки могут добавляться в состав официальной версии библиотеки. Ну а когда будет закончена эта техническая работа, можно будет всерьез задуматься и про экосистему! :)
Вот findContours скорее всего все еще работает в один поток. В OpenCV сейчас идет попытка вставить многопоточность во все места, где это можно сделать задешево. Например, во многих случаях можно картинку нарезать на полоски, и обрабатывать их независимо. Но даже это еще далеко не везде сделано, и мы продолжаем увеличивать покрытие. Если хотите получить актуальный список функций, которые распараллелены, я бы предложил сделать grep parallel_for по исходникам, вхождений будет не очень много, но как было сказано, это один из приоритетов на будущее :) Ну и конечно, если у вас появится своя реализация, есть все шансы добавить ее в библиотеку!
Милости просим в нашу группу поддержки, OpenCV4Android. Желательно указать марку устройства, версию ОС и откуда был получен пример (Google Play, SDK, TADP). Попробуем помочь!
Если вам и вправду интересно, то лучше спросить какие конкретно части библиотеки вам любопытны. К сожалению всех авторов алгоритмов не упомянешь… Вот например несколько заброшенный список контрибьюторов: code.opencv.org/projects/opencv/wiki/Contributors. Еще можно почитать лог SVN :)
Ну а если серьезно, то в планах стоит подробно рассказать, как OpenCV приобретала CUDA-оптимизации и портировалась под Android. Еще скорее всего будет рассказано про QA и непрерывную интеграцию в проекте и про то, каким образом обеспечивалась кросс-платформенность.
OpenCV хоть и большая, но модульная. И в недалеком будущем она станет еще более модульной. Прямо сейчас OpenCV включает более 15 модулей. Если вашему приложению нужна лишь часть, вы берете только их, и ваш бинарник получается относительно скромного размера. Это важно например для мобильных ОС, и мы сейчас этим заняты отдельно. Если вам наоборот, не важен размер, а важна простота использования — недавно был создан специальный модуль opencv_world, который позволяет утянуть сразу все зависимости.
В будущем планируется еще более мелко разбивать модули. Например, всем известный opencv_highgui скорее всего разлетится на несколько модулей: GUI, ввод/вывод видео и ввод/вывод изображений. Соответственно, приложение сможет брать только те части, которые ему нужны. Также нужно отметить, что зависимость от многих библиотек (Eigen, TBB и т.д.) является опциональной.
Короче говоря, команда старается, работа кипит. Будут предложения, добро пожаловать на форум для разработчиков!
В свое время OpenCV уже пережила серьезную переделку, когда старые модули (core, aux, ml и highgui) были разбиты на ряд модулей поменьше. Это существенно упростило жизнь разработчиков, которые использовали OpenCV в реальных проектах, поскольку вы зависели только от нужных вам модулей. Это позволило упростить поддержку и сэкономить место на конечных устройствах.
То, что предполагается сделать сейчас — это продолжение этого процесса, когда вся библиотека разбивается на большее количество модулей, но меньшего размера и с более понятными ответственностями. Фактически, разработчики получат возможность собирать свою версию библиотеки, отбирая только необходимые модули, и при необходимости добавляя свои собственные.
Уже сейчас, конфигурируя сборку OpenCV при помощи CMake вы можете отобрать модули, которые необходимо собрать, и выключая ненужные модули. Это например активно используется при построении под Android, поскольку например CUDA и OpenCL там не поддерживаются, но нужен Java API и несколько специфических модулей. Кстати стоит почитать про «фиктивный» модуль opencv_world, позволяющий упростить себе жизнь при использовании такой кастомной сборки.
Таким образом, все что изменится на первых порах — это раскладка библиотеки по большему числу узконаправленных модулей. Плюс станет удобно подкладывать свои папочки с кодами таким образом, чтобы OpenCV считала их своими модулями. Впоследствии стабильные сторонние разработки могут добавляться в состав официальной версии библиотеки. Ну а когда будет закончена эта техническая работа, можно будет всерьез задуматься и про экосистему! :)
Ну а если серьезно, то в планах стоит подробно рассказать, как OpenCV приобретала CUDA-оптимизации и портировалась под Android. Еще скорее всего будет рассказано про QA и непрерывную интеграцию в проекте и про то, каким образом обеспечивалась кросс-платформенность.
В будущем планируется еще более мелко разбивать модули. Например, всем известный opencv_highgui скорее всего разлетится на несколько модулей: GUI, ввод/вывод видео и ввод/вывод изображений. Соответственно, приложение сможет брать только те части, которые ему нужны. Также нужно отметить, что зависимость от многих библиотек (Eigen, TBB и т.д.) является опциональной.
Короче говоря, команда старается, работа кипит. Будут предложения, добро пожаловать на форум для разработчиков!