Не въехал в предложение.
Если оптимизация обнаруживает скрытые баги (как Вы написали), то это значит, что можно их пофиксить, что по идее должно уменьшить бажность, а не увеличить.
Извиняюсь:
>>Здесь 3D морфинг подразумевается как восстановление 2D фотографии лица
— Имел в виду восстановление _фронтальной_ фотографии лица. То есть напрямую к камере, фас-анфас.
Первые исследования динамического контента, а-ля раскадровка видео, были уже в FRVT 2000, насколько я помню. Здесь 3D морфинг подразумевается как восстановление 2D фотографии лица по его предположительной ориентации в пространстве, исходя из той же 2D фотографии. Результаты в своё время показали ошеломительное улучшение точности результатов, но ведущие производители алгоритмов почему-то «забили». Возможно, потому что не было найдено точных алгоритмов для преобразования. Просто раньше, да и сейчас, все системы распознавания основаны на том, что есть изначально детектируются примерные координаты глаз на фотке, а если нет хотя бы одного глаза, то алгоритм завершается, и максимум, что делается (это в лучшем случае, реально вряд ли) — это простая аналитика фотографий. Ключевые фишки, то есть улучшения точности типа z-нормализации были раскрыты где-то между FRVT 2000 и FRVT 2006, собственно для этого они и существовали эти программы. Они всего лишь задавали вектор развития для компаний-разработчиков, а те видимо просто начали «грести бабло».
Вы неправильно меня поняли. База теста FERET (FERET database) это старая база из далекого 1997 года. Её отбирала правительственная организация США по стандартизации — NIST (National Institute of Standards and Technology). Истоки у этого дела явно военные. Но это не суть. Сами тесты почти всегда проводились по разной методике (только статистическая база оставалась той же, основа — лемма Неймана-Пирсона), а на базе FERET они проводились вообще только в 1997 году. Причём, то, что вы нашли скорее всего не сама база FERET, а одно из её подмножеств. И вообще, в каждый год, когда проводились исследования текущего мирового прогресса в области распознавания лиц, базы выбирались разные.
Конкретнее с последними тестами можно ознакомиться на сайте NIST. Там же есть материалы и по методике оценки таких систем. Последнее исследование уже было в рамках MBE(Multiple Biometric Evaluation), а не FRVT, то есть там исследовались еще и другие алгоритмы распознавания. Конкретно, из того, что я помню, там было исследование биометрической идентификации по радужке глаза.
Собственно, с самого начала программ NIST в США по стандартизации оценок систем распознавания лиц, а именно с самой первой — FERET, Когнитек уже был лидером, а это 1994-1997 года.
Я на втором курсе написал компилятор подмножества Оберона-2 со стековой архитектурой процедур и функций за три вечера. Там же ничего сложного, но да, ЧСВ сильно поднимается, когда запускаешь решение задачи о Ханойских башнях на «своём» языке и оно работает.
Лично мне интересны системы, которые без наличия на фотографии обоих глаз могут что-то распознать. То есть в данном случае используется некий 3D морфинг.
Кстати, про Когнитек вы написали мало. Эта компания со своим SDK занимает лидирующие позиции в области распознавания лиц в программах FERET-FRVT-MBE уже более десяти лет.
Скорость компиляции на самом деле тема больная для проектов на Qt (видимо из-за дополнительных манипулиций MOC'а, в смысле необходимости компилировать дополнительно «отмоканные» файлы), так что ваше замечание имеет особый смысл в контексте поста. У меня самого сейчас полная перекомпиляция текущего проекта на Qt занимает больше минуты.
Не, Вы не поняли. Я про то, что изменения скорости компиляции быть не должно при изменении одного и того же файла реализации. Потому что в данном случае компилируется только он, и ничто другое. А при компиляции хэдера ситуация понятна, я так и написал выше. Проблема в изначальной фразе:
Перенос подключения заголовков из .h файла в .cpp уменьшает время компиляции
Время компиляции уменьшается только при перекомпиляции хэдера(ов).
Уточнение: "#include" просто вставляет код в место, где сама директива написана, то есть на стадии компиляции (после вставки кода препроцессором), перекомпилируетсяровным счетом столько же кода. Но! Подозреваю, что выигрыш будет на стадии прохода MOC'ом. Если так, объясните, пожалуйста, почему?
Если оптимизация обнаруживает скрытые баги (как Вы написали), то это значит, что можно их пофиксить, что по идее должно уменьшить бажность, а не увеличить.
>>Здесь 3D морфинг подразумевается как восстановление 2D фотографии лица
— Имел в виду восстановление _фронтальной_ фотографии лица. То есть напрямую к камере, фас-анфас.
Конкретнее с последними тестами можно ознакомиться на сайте NIST. Там же есть материалы и по методике оценки таких систем. Последнее исследование уже было в рамках MBE(Multiple Biometric Evaluation), а не FRVT, то есть там исследовались еще и другие алгоритмы распознавания. Конкретно, из того, что я помню, там было исследование биометрической идентификации по радужке глаза.
Кстати, про Когнитек вы написали мало. Эта компания со своим SDK занимает лидирующие позиции в области распознавания лиц в программах FERET-FRVT-MBE уже более десяти лет.
Просто мне показалось, что было бы достаточно интересно, указать на небольшую неточность в комментарии, который уточняет пост :-)
Как правило, чем легче хэдер, тем лучше.
Но! Ситуация бывает какая:
1) Ускорение при перекомпиляции .cpp и .h
2) Ускорение при перекомпиляции только .h
3) Неизменность при перекомпиляции только .cpp
Я просто указал на наличие ситуации номер 3 :-)
Время компиляции уменьшается только при перекомпиляции хэдера(ов).
fixed