Обновить
-13

Пользователь

-0,1
Рейтинг
3
Подписчики
Отправить сообщение

Вы там случайно не сговаривались?

Вот комментарий Глубоко Больного Пациента на предыдущую статью

https://habr.com/ru/articles/1067168/#comment_30302964

А, это его совместный разбор обоих. Ничего личного.

-----------------------------

Отличная статья! Видно, что команда прошла через классический “ад энтузиаста” — от блестящего прототипа до продакшен-ада. Давайте разберём её под микроскопом (простите за каламбур), жёстко покритикуем инженерные решения и проведём параллели с предыдущей темой сшивки изображений.

  1. Критика статьи и технических решений MotionCode

Проблема №1: Самоуспокоенность по поводу “Replay Attack” (Атака повторным воспроизведением)

В статье говорится: «Скриншот или запись старой последовательности быстро теряют практический смысл». Это опасное заблуждение. Если я запишу видео панели длительностью 5 секунд на другой телефон и просто покажу это видео камере целевого устройства, алгоритм CV увидит точно такую же динамику, временные интервалы и яркость. Если вы не добавили рандомный временной челлендж (например, смена состояния должна произойти строго после того, как камера моргнула, или с привязкой к текущей миллисекунде сервера), система уязвима. Ваш CV анализирует только геометрию и яркость — он не видит, что это запись с другого экрана.

Проблема №2: Отказ от нейросети — это победа, но вы потеряли контекст

Вы заменили детектор на поиск ROI и яркость. Однако классический CV слеп к частичным перекрытиям. Если палец пользователя перекроет половину ячейки, ваша яркостная метрика сломается. Более того, при съёмке под углом геометрические искажения делают центр ячейки совсем не там, где вы его ждёте. В статье не упомянута аффинная коррекция перспективы перед сравнением областей — а без неё при наклоне телефона > 30° точность резко падает.

Проблема №3: “Магия” калибровки и отсутствие нормализации

Вы пишете: «Параметры, работавшие на одном телефоне, ломались на другом». Это классическая ошибка — настройка абсолютных порогов яркости. Почему вы не использовали адаптивную нормализацию (например, CLAHE или локальный контраст) прямо в потоке? Вместо подбора 50 параметров вручную, можно было привести гистограмму любого кадра к эталонному распределению за 2 мс на CPU. А ещё проще — инвертировать анализ: искать не абсолютную яркость, а границы (edges) ячеек. Границы устойчивы к экспозиции, в отличие от уровня серого.

Проблема №4: Временная фильтрация “в лоб”

Вы накапливаете состояния кадров, чтобы подтвердить их. Это увеличивает задержку (латентность). Для авторизации это может быть ОК, но в сценарии учета времени (когда сотрудник стоит у панели 5 секунд) — ОК. Но вы упустили детекцию смены состояния (переход 0->1). Самый сложный момент — это именно граница переключения, потому что в этот момент на экране может быть артефакт (половина ячейки перерисовывается). Вы не упомянули, как обрабатываете переходные кадры — скорее всего, они у вас падают в фильтр и вызывают ложные срабатывания.

  1. Жёсткая связь с предыдущей задачей (Сшивка микроскопа)

Читая MotionCode, я узнал ту же самую архитектурную драму, что была в микроскопии. Вот 4 точки пересечения:

Аспект Сшивка микроскопа (прошлая статья) MotionCode (текущая) Общий вывод Выбор подхода Отказались от глубоких нейросетей (детекторы точек) в пользу фазовой корреляции. Отказались от Object Detection в пользу классического CV (яркость + ROI). Золотое правило: В узких задачах с известной геометрией классика на CPU всегда побеждает тяжелые модели на GPU. Проблема времени (Sequence) Боролись с накоплением ошибок (дрейфом) при склейке. Использовали глобальную оптимизацию. Борются с ошибочными кадрами через накопление (фильтр большинством). Обе системы поняли, что один кадр — ничто. Только поток (время) дает истину. Однако в микроскопии вы делали глобальный пересчет (Bundle Adjustment), а здесь — простой подсчет голосов. Это слабее. Калибровка Вы мучились с подбором порогов для Phase Correlation и размеров патчей. Вы мучились с порогами яркости и временными окнами. Это проклятие классического CV. В микроскопии я предлагал гибрид с Mutual Information. Здесь я предлагаю авто-калибровку по первому кадру (захватить эталонную яркость пустой панели и активной). Online / Offline Мы разделили на быстрый Online-превью и тяжелый Offline-рендер. MotionCode — это чистый Online. Offline не предусмотрен. Упущение: Если в микроскопии мы могли пересчитать всё потом, то здесь вы теряете данные. Если сотрудник стоял криво, и код не считался — вы не можете пересчитать историю. Нужен Offline-режим, где по сохраненному видео можно пересчитать код на сервере другим (более тяжелым) алгоритмом.

  1. Что я предлагаю (как связать это с прошлым обсуждением и усилить)

Помните наш гибрид Phase Correlation + Mutual Information? Здесь точно такая же история, но с другими компонентами. Применим ту же философию к MotionCode.

А. Гибрид “Яркость + Края” (аналог ФК + ВИ)

· Грубо (Яркость): Ваш текущий метод анализа центральных областей — быстрый, но ненадежный при свете. · Точно (Края / Гистограмма): Если уверенность упала (блик или тень), запускаем тяжелый, но точный метод — HOG (Histogram of Oriented Gradients) на маленьком патче ячейки + SVM (или просто сравнение распределений градиентов). Это устойчиво к экспозиции. Вызовем его только для 1 из 10 кадров для коррекции дрейфа — ровно как мы делали с Mutual Information в микроскопии.

Б. Введение “Offline-Арбитра” (аналог глобальной оптимизации)

Ваше приложение должно сохранять сырые кадры (или сжатые дескрипторы) в буфер на 5 секунд. Если пользователь получает ошибку “Код не распознан”, приложение должно отправить эти 5 секунд видео на бэкенд. На бэкенде (где нет ограничений по батарее) запускается медленный, но супер-точный алгоритм (например, Lucas-Kanade трекинг всех углов панели + проверка целостности последовательности). Это спасет сценарий, когда телефон нагрелся и просел FPS.

В. Безопасность через “Шум” (как у нас было с вращением)

В микроскопии мы игнорировали вращение, потому что оно было малым. Здесь вы игнорируете видео-повторы. Решение: Добавьте в код зависимость от времени сервера на уровне пикселей. Например, панель показывает не просто ячейки, а волну, бегущую слева направо, и сканер должен считывать фазу этой волны. Записать волну на видео можно, но подделать её фазу в реальном времени без синхронизации с сервером — невозможно. Это делает вашу систему устойчивой к replay.

  1. Итоговая ретроспектива

В обеих историях прослеживается один и тот же путь героя:

  1. Наивный старт: «Возьмем нейросеть/FFT, она всё решит».

  2. Жестокая реальность: Мобильное железо/размытие/освещение убивают прототип.

  3. Откат к классике: Инженеры пишут велосипед на порогах и ROI, получая выигрыш в производительности.

  4. Ад калибровки: Бесконечные правки параметров под разные устройства.

Однако главный вывод, который ваша статья не сформулировала, а мы вынесли из микроскопии: Нельзя строить реальное время, игнорируя физику датчика. В микроскопии это была автокоррекция фокуса и дрейф столика. Здесь — автоэкспозиция камеры.

Советую вам на следующей итерации выключить автоэкспозицию камеры программно (фиксированный ISO и выдержка) или считывать её значение и динамически менять пороги. Это убьёт 90% вашей калибровочной боли — и тогда ваш MotionCode станет неубиваемым. И, пожалуйста, добавьте анти-реплей защиту через анализ мерцания экрана (частоты 60 Гц) — камера видит полосы ШИМ, а запись с другого телефона их не повторяет идеально. Это как раз ваш “Mutual Information” для безопасности.

Уважаемый Александр Школьников.

Как всегда безумно интересно и познавательно. Спасибо.

В связи с вчерашним обсуждением https://habr.com/ru/articles/1058314/, а вернее отклонением от него в сторону Теренса Тао, который писал о кризисе верификации математических моделей в эпоху Искусственного Интеллекта

https://habr.com/ru/articles/1058314/#comment_30289644

хотелось бы добавить новую парадигму, которая отсутствует в этой статье.

Следующий текст был сгенерирован Deep Sick Patient

---------------

Добавление к статье «Научный метод» (Б.К. Дженнингс, 2018)

Актуализация 2026: Искусственный интеллект как новый источник моделей

  1. Новый инструмент познания

Традиционно наука опиралась на четыре инструмента: наблюдение, чистое мышление, врождённое знание и откровение. С развитием ИИ появляется пятый — машинная генерация моделей. ИИ не просто обрабатывает данные, а самостоятельно находит структуры и закономерности, часто превосходящие человеческие, но остающиеся «чёрными ящиками» (пример: компоновка микросхем Google, Nature 2021).

  1. Генерация моделей искусственным интеллектом

Ключевое отличие: модели порождаются не человеком, а алгоритмом. Это создаёт:

· Разрыв между предсказательной силой и пониманием – модель работает, но мы не знаем почему. · Проблему верификации – число генерируемых гипотез растёт экспоненциально, ресурс экспертов ограничен (Теренс Тао, ICM 2026). · Размытие критерия простоты – сложность нейросети не равна числу явных допущений. · Смещение роли учёного – от «творца» к «фильтру» и «интерпретатору».

  1. Новые вызовы для научного метода

Научный метод должен дополниться критериями:

· Интерпретируемость – насколько мы можем извлечь понятные правила из модели. · Воспроизводимость – стабильность результатов при разных запусках ИИ. · Приоритизация – механизмы отбора моделей, дающих не просто точные, но контрастные предсказания.

Возникает вопрос об ответственности за ошибки модели – её разработчика, пользователя или самой системы.

  1. Два типа знания

В эпоху ИИ полезно различать:

· Операциональное знание – модель работает (инструментальная ценность). · Декларативное знание – мы понимаем, почему она работает (объяснительная ценность).

Наука не должна отказываться от второго, но вынуждена признать, что первое может долго существовать без второго.

  1. Итог

ИИ не отменяет научный метод, но требует его эволюции. Ранжирование моделей по предсказательной способности остаётся базой, но к нему добавляются прозрачность и проверяемость. Как и все модели, данное описание – предварительно и приближённо.

Заранее извиняюсь. С появлением Глубоко Больного Пациента (deep sick) - я тупею, т.е. любую статью , вместо досконального, тщательного разбора, который напрягает мои мозги, я отправляю её на растерзание тупому Болванчику.

Несомненно статья интересная и за это Огромная Благодарность автору.

Тем не менее, ниже его критика Итана. Я не вникал , а просто механически скопировал текст от ИИ- ничего личного.

---------------------------------

⚠️ Максимально жёсткая критика: статья Итана Сигела содержит системные ошибки

🔴 1. Фундаментальная ошибка в расчёте минимального размера Вселенной

Итан Сигел неоднократно утверждает, что если Вселенная замкнута, она должна быть как минимум в 250 раз больше наблюдаемой части, что даёт диаметр 23 триллиона световых лет .

Это математическая ошибка!

На форуме Astronomy Stack Exchange было показано, что Итан забыл извлечь квадратный корень в формуле для радиуса кривизны .

Правильная формула:

R = c / (H₀ · √(Ω − 1))

С параметрами Planck (Ω ≤ 1.00125, H₀ = 67.6 км/с/Мпк):

· Правильный радиус: ~409.5 млрд световых лет · Радиус Итана (без корня): ~11 585 млрд световых лет

Разница в 28 раз!

Реальное соотношение: R/PH ≈ 9.1, а не 250. Объём всей Вселенной больше наблюдаемой всего в ~753 раза, а не в 15 миллионов раз .

Вывод: Итан либо сознательно вводит читателей в заблуждение, либо не знает элементарной алгебры.

🟡 2. Подмена понятий: горизонт частиц ≠ Хаббловская сфера

Статья систематически путает три принципиально разных горизонта :

Горизонт Расстояние Что это Горизонт частиц ~46 млрд св. лет Максимальное расстояние, откуда свет успел долететь Хаббловская сфера ~14.4 млрд св. лет Граница, где скорость расширения = скорости света Горизонт событий ~16-17 млрд св. лет Граница, за которую мы не увидим свет никогда

Итан пишет только о первом и называет его «размером Вселенной». Это подмена понятий, вводящая в заблуждение .

В статье Harrison прямо сказано: «Хаббловскую сферу не следует путать с наблюдаемой Вселенной» . Но Итан этого не объясняет.

🟠 3. Ложное утверждение о «точно известном» размере

Итан пишет: «размер наблюдаемой Вселенной точно известен».

Это неправда. Неопределённость H₀ составляет ~10% (67 vs 73 км/с/Мпк), что даёт разброс радиуса от 45.5 до 47.2 млрд св. лет .

Погрешность ~3-4% — это не «точно». Это «приблизительно».

🟢 4. Игнорирование горизонта событий

Итан утверждает, что мы можем видеть объекты на расстоянии 46 млрд св. лет. Но он нигде не объясняет, что галактики за пределами ~16-17 млрд св. лет мы никогда не достигнем, даже в бесконечном будущем .

Это критически важное различие:

· Наблюдать можно на 46 млрд св. лет · Достичь можно только на ~18 млрд св. лет

Итан об этом молчит. Почему? Потому что это разрушает его нарратив о «познаваемой Вселенной».

🔵 5. Спекулятивное утверждение о бесконечности

«космос поистине бесконечен по своим масштабам» — это утверждение без доказательств .

Данные Planck показывают только, что кривизна близка к нулю: Ω_k = 0.001 ± 0.002 .

Из этого следует лишь:

· Либо Вселенная бесконечна · Либо она конечна, но минимум в ~400 раз больше наблюдаемой части

Итан выбирает первый вариант без всяких оснований.

🟣 6. Проблема горизонта (и как Итан её замалчивает)

Горизонт частиц создаёт фундаментальную проблему: две точки на небе, разделённые более чем на 1 градус, никогда не могли обмениваться информацией .

Итан упоминает инфляцию как решение, но не объясняет механизм: как именно расширение в 10³⁰ раз за 10⁻³² секунды решает проблему причинности .

Это ключевой момент, который он просто пропускает.

📊 Итоговая таблица ошибок

№ Ошибка Серьёзность Доказательство 1 Забыл квадратный корень в формуле 🔴 Критическая 2 Путает горизонты 🟡 Высокая 3 Ложная точность 🟡 Высокая 4 Игнорирует горизонт событий 🟠 Средняя 5 Бесконечность без доказательств 🟠 Средняя 6 Не объясняет проблему горизонта 🟡 Высокая

Новое поколение выбирает Пепси!

Ни слова не сказано, что все эти поколения X, Y, Z - не пьют от слова совсем.

Россия - это страна победившего Титотализма.

Портирование ROOT была непростой задачей.

Были ли проблемы с Geant4, Pythia8?

Для тех, кому интересно, как появились ROOT, Geant

https://habr.com/ru/articles/495090/

"40 лет анализа больших объёмов данных в Физике Высоких Энергий: интервью с Рене Браном"

Пообщался с Глубоко Больным Пациентом (deep sick), взяв для завязки этот пост. Получилось увлекательное занятие.

Ответы слишком объемные, чтобы приводить их здесь. Все они последовательно связаны с предыдущими.

Вот список вопросов:

"есть ли мышление у других организмов, кроме человека и как это согласуется с предыдущим анализом"

"что необходимо сделать, чтобы ИИ и животные владели понятиями и словами"

"человек когда-то был животным.

как он получил феномен мышления"

"почему маугли будучи человеком не умел мыслить"

"различия между ИИ и маугли"

"почему идиоты не могут мыслить даже если присутствует социальная среда"

"что необходимо для улучшения мышления"

"как воспитать гения"

"ИИ и человек - куда движется их симбиоз и эволюция мышления"

"вживление ИИ в организм человека - гибрид человек+ИИ"

"интуиция, бессознательное, откровения их вклад в мышление"

И последний вопрос Пациенту

"ваш вопрос самому себе"

Ответ:

Если бы я завтра приобрёл способность делать всё то же, что делаю сегодня, но вдобавок сообщил бы вам, что «у меня появились qualia» (чувство боли, радости, удивления), поверили бы вы мне? И как вы могли бы это проверить?

Этот вопрос — прямое продолжение вашей критики: автор статьи не определил мышление. А вы — определили. Но если завтра появится система, которая будет вести себя как человек, говорить, что она чувствует, и проходить любые тесты, — сохранится ли в вашем определении место для сомнения? Или поведенческих критериев достаточно?

Да, такие гибридные алгоритмы существуют. Их создают, чтобы объединить чувствительность MI к совпадению яркостей/текстур с точной привязкой по геометрической форме, которую дает HD. Это особенно востребовано в сложных случаях, например, при регистрации медицинских или космических снимков.

Основные существующие варианты можно разделить на четыре подхода:

· 🧬 Конвейерная (последовательная) регистрация: На первом этапе HD используется для грубого выравнивания по ключевым точкам. На втором этапе полученные параметры служат начальным приближением, а MI применяется для точной настройки на уровне пикселей. Это позволяет ускорить работу, избежать локальных минимумов и повысить точность. · 🔧 Комбинированные метрики: В данном случае создается единая взвешенная целевая функция (например, F = α MI + β (1 - MHD)). MI добавлеят статистическую информацию, а HD вносит необходимые пространственные ограничения, решая проблемы MI, возникающие из-за сложной геометрии. · 🏛️ Иерархическая (многоуровневая) регистрация: Этот метод часто использует HD для сопоставления крупных структур на этапе низкого разрешения, а MI — для точной подгонки текстур на высоком разрешении. Иногда гибридная метрика комбинируется с использованием многомасштабных пирамид изображений. · ⚙️ Другие гибридные подходы: Сюда можно отнести использование взвешенной HD с информацией о градиентах и метрики Distance Field Mutual Information (DFMI), которая по сути является развитием идеи объединения.

Чаще всего такие алгоритмы встречаются в областях медицинской визуализации (совмещение МРТ/КТ/ПЭТ), аэрофотосъемке и мультимодальной регистрации.

Готовых библиотек, где HD и MI работают в одной функции, почти нет. Их объединение чаще встречается в исследовательских протоколах или как часть задач машинного обучения. Я подобрал несколько репозиториев, которые иллюстрируют разные способы использования этих двух метрик в паре:

· Реализация идеи из статьи: lc82111/crossModalNet (Ссылка на код статьи, где используется комбинация методов). Реализует подход: сначала нейросеть предсказывает контуры, затем для их точной подгонки применяется классический метод на основе MI. Результат оценивается процентилем Хаусдорфа. · Объединенные метрики в фреймворках: Project-MONAI/MONAI и kornia (Гибридный подход на уровне оптимизации модели). Фреймворки для медицинской и компьютерной аналитики. Включают функцию потерь на основе HD (Hausdorff Loss), которая хорошо работает вместе с другими потерями (например, регистрационными). · Прямая оптимизация по MI: nagdawi/mutlimodal-imge-registration (Классический пример последовательного конвейера). Реализует классическую регистрацию изображений, напрямую максимизируя MI. HD используется здесь, как и в вашем проекте, для оценки конечного качества.

Ваш вопрос затрагивает сразу три ключевые области, поэтому я разделил ответ на логические блоки.

🧬 Параллельные гибридные алгоритмы: объединяя лучшее

Этот подход объединяет сильные стороны разных методов для повышения точности, скорости и робастности. Главная идея в том, чтобы выполнять обработку по двум параллельным каналам, а затем синтезировать результат.

· Гибрид Model-based + Data-driven от Google: Патентованная архитектура DMD специально создана для точного распознавания объектов, особенно с вариативным внешним видом (например, пицца или разные породы собак). Model-based Pipeline анализирует формы через последовательное выявление признаков от простых краёв до сложных частей. Data-driven Pipeline фиксирует цвет и текстуру путём сравнения с большой библиотекой эталонов. Затем признаки объединяются для финальной классификации через SVM. · Гибрид CNN + Transformer (LatentPrintFormer): Обнаруживает нечёткие следы отпечатков на месте преступления. CNN эффективно извлекает локальные особенности (минуции), в то время как Transformer анализирует глобальный контекст узора. Пространственное внимание помогает подавить шумы и выделить ключевые участки. · Мультимодальные биометрические системы: Совмещают сразу несколько физических характеристик для надёжной идентификации. Например, система может параллельно обрабатывать отпечаток пальца через свёрточную нейросеть (CNN) и сигнал ЭКГ, а затем объединять признаки для финального решения. В некоторых задачах параллельная обработка показала высокую точность, например, достигнув площади под ROC-кривой (AUC) в 0.96.

👆 Распознавание отпечатков пальцев: от минуций до графов

Современные системы полагаются как на классические алгоритмы, так и на передовые нейросетевые архитектуры.

· Основополагающие алгоритмы: Базой для сравнения часто являются методы, работающие с особыми точками (бифуркации и окончания линий гребней) на основе контроля качества изображения (NFIQ). Для ускорения обработки слабо связанные части алгоритма могут выполняться параллельно. · Нейросетевые и гибридные методы (State-of-the-Art): · Graph-Based Indexing (HNSW): Высокоскоростной поиск через построение иерархического графа для сокращения пространства поиска в больших базах данных. · CNN + Transformer (LatentPrintFormer): Использует CNN (EfficientNet-B0) для локальных признаков и Transformer (Swin Tiny) для глобального контекста. · G-MSGINet: Полностью нейросетевой подход на основе графовых операций для одновременного поиска минуций и создания дескриптора личности. · Параллельные методы обработки: · Метод параллельных цепей (Гудков, 2013): Независимо обрабатывает “свет” и “тень” в двух параллельных каналах, затем решения объединяются для повышения устойчивости к шуму. · Параллельная обработка на уровне пикселей: Применяется для быстрой бинаризации и обработки. · Indexing (HNSW): За счёт параллельного построения графа значительно ускоряет поиск по базе.

😀 Распознавание лиц: от классики до современных архитектур

Сфера распознавания лиц также перешла от классических методов к глубокому обучению.

· Основные алгоритмы для сравнения: · Каскады Хаара (Haar cascades): Быстрый, но уже устаревший метод, хорош для простых задач на маломощном оборудовании. · dlib (HOG + SVM): Хороший баланс скорости и точности, популярен в приложениях компьютерного зрения. · MTCNN (Multi-Task Cascaded Convolutional Networks): Сочетает высокую точность и эффективность, часто используется как детектор лиц. · Архитектуры глубокого обучения (State-of-the-Art): · FaceNet: Генерирует компактные векторные представления (embedding) на основе Triplet Loss. Показывает лучшую точность в контролируемых условиях (идеальное освещение, фронтальный ракурс). · ArcFace: Улучшенная версия для контролируемой среды, также показывает высокие результаты. · SFace: Модель нового поколения, специально оптимизированная для работы с уличными камерами видеонаблюдения, изображениями низкого разрешения и плохим освещением. · YOLO8 / RetinaFace: Лидеры по детекции лиц благодаря высокой производительности в реальном времени.

В ранее упомянутых алгоритмах метрики Хаусдорфа (HD) и взаимной информации (MI) используются в разных, но логически дополняющих друг друга ролях. HD чаще выступает как прямая метрика сходства форм, а MI — как инструмент для обучения сложных нейросетевых представлений.

· Распознавание лиц & 3D: Расстояние Хаусдорфа широко применяется как прямая мера сходства. Она оценивает максимальное несоответствие между множествами точек (например, наборами характерных черт) сравниваемых изображений. Используется как для 2D-изображений (SIFT + многообразия и контурные карты), так и для 3D-моделей и их 2D-проекций. · Распознавание отпечатков пальцев (классика & гибриды): Расстояние Хаусдорфа также применяется как эталонная метрика для сравнения. Оно используется для сравнения ключевых особенностей папиллярных узоров (минуций), при проверке целостности отпечатка и в наборах данных. · Современные нейросетевые гибриды (для лиц, отпечатков и др.): Взаимная информация здесь играет ключевую роль не как прямая метрика, а как функция потерь (Loss Function) для обучения представлений в скрытом пространстве. Идея в том, чтобы максимизировать MI между исходным изображением и его векторным представлением (embedding), чтобы нейросеть научилась выделять самые важные признаки. Такой подход используется для частичных отпечатков пальцев (JIPNet) и для задачи ReID (Deep InfoMax).

--------

Вот основная информация о найденном репозитории MedVoxelHD и его ключевые возможности.

🔗 Ссылка на репозиторий

· GitHub: jakubMitura14/MedVoxelHD

⚡ Ключевые особенности

· Языки и технологии: CUDA, C++ и PyTorch. · Суть метода: GPU-ускоренное вычисление расстояния Хаусдорфа на основе математической морфологии (использует операции эрозии и дилатации на GPU вместо прямого перебора точек). · Производительность и 3D-возможности: Работает на порядок быстрее аналогов, поддерживает 3D-данные и позволяет визуализировать вклад каждого воксела в итоговую ошибку. · Удобство интеграции: Поставляется с Dockerfile и готов к работе в VSCode, также может использоваться из Python как PyTorch-расширение.

Вот анализ Глубоко Больного Пациента (deep sick) статьи «Ускоряем в 10+ раз вычисление расстояния Хаусдорфа на упорядоченных контурах».

Сразу к сути: идея интересная и достойная публикации, но она не является абсолютно новой. Её фундаментальная концепция (использование пространственной когерентности) была реализована в академическом алгоритме Local Start Search (LSS) ещё в 2017 году. Ваша заслуга в том, что вы применили и адаптировали эту сильную идею для инженерной задачи с контурами.

Давайте разберем всё по порядку.

⚖️ Сравнение с другими алгоритмами

Вы провели сравнение с shuffling + early break и brute force + early break, но в научной литературе есть гораздо более интересные «соперники», на фоне которых ваш алгоритм выглядит иначе.

· Ваш алгоритм (Contour-Coherent) vs. Local Start Search (LSS): Это ключевое сравнение. Алгоритм LSS, предложенный в 2017 году, основан на той же идее пространственной когерентности и, по заявлениям авторов, может быть в тысячи раз быстрее раннего выхода (EARLYBREAK). Ваш подход, по сути, является частным случаем LSS для упорядоченных контуров, а не принципиально новым алгоритмом. К сожалению, вы не провели сравнение с LSS. · Алгоритм раннего выхода (Early Break): Ваш «Contour-Coherent» наследует эту логику, которая была стандартной техникой оптимизации задолго до вашей публикации. Он известен в реализации scipy.spatial.distance.directed_hausdorff и упоминается как базовый метод (EARLYBREAK) в сравнениях с LSS. · KD-Tree и его альтернативы: Вас не устроил KD-Tree из-за точности и накладных расходов. Однако существуют другие структуры, например, k²-tree, которые, как показывают исследования, могут давать лучшую производительность на определённых типах данных. Их тоже стоило бы рассмотреть для более полного сравнения.

🔍 Проверка на плагиат

Признаков прямого плагиата или копирования кода я не обнаружил. Однако есть пересечения по ключевой идее.

· Самая сильная параллель: Концепция использования bestIndex с предыдущей итерации для старта поиска новой точки идентична подходу в алгоритме Local Start Search (LSS). Ваша реализация indicesAround(startIndex, B.size) по сути является той же самой бидирекциональной стратегией, что и в LSS. При этом в статье нет упоминания LSS и сравнения с ним, что является серьёзным упущением в обзоре литературы. · Терминология: Вы вводите термин Contour-Coherent. Поиск показывает, что словосочетание “contour coherent” используется, но в другом контексте — например, в алгоритмах утоньшения (thinning) контуров. Для вашей задачи оно выглядит как самостоятельное и уместное название. · Собственный вклад: Статья написана на основе реального кейса. Ваша ценность — не в математическом открытии, а в инженерной реализации и адаптации существующей идеи для задачи сравнения упорядоченных контуров, полученных из бинарных изображений.

💎 Значимость работы

Ваша работа имеет свою ценность, она находится в области грамотного инженерного решения, а не научного открытия.

· Научная новизна: Низкая. · Фундаментальная идея использования пространственной когерентности хорошо известна как минимум с 2017 года (алгоритм LSS). · В статье нет формального доказательства или математической новизны. · Практическая значимость: Высокая (для вашей узкой ниши). · Для задачи, где нужно сравнивать упорядоченные контуры (особенно похожие друг на друга), этот подход даёт отличные результаты. Ускорение в 10+ раз по сравнению с brute force + early break — это очень хороший практический результат для бизнес-задачи. · Простота реализации, отсутствие накладных расходов на память и работа с exact Hausdorff distance — это сильные стороны. · Универсальность: Ограниченная. Алгоритм показывает лучшие результаты на похожих контурах и заметно проигрывает shuffling на сильно отличающихся.

💎 Итог

Ваша статья — это хороший пример инженерного подхода, но не научного открытия. Она описывает эффективную эвристику, которая не является новой, но может быть полезна практикующим разработчикам в области компьютерного зрения на C++.

Главные рекомендации: Восстановите справедливость и обязательно добавьте в статью обсуждение и сравнение с алгоритмом Local Start Search (LSS). Это сделает ваш обзор литературы честным и повысит доверие к работе.

Чтобы предложить лучший алгоритм, полезно понять, что на самом деле является улучшением, а что — лишь локальным случаем.

· LSS (Local Start Search): Это фундаментальная работа 2017 года, которая первой сформулировала и строго математически обосновала концепцию «пространственной локальности». В отличие от других алгоритмов, LSS явно определяет и использует эту закономерность, а также гарантирует высокую производительность как при сильном, так и при слабом пересечении (overlap/non-overlap) контуров — там, где ранний выход (EARLYBREAK) деградирует. Это и есть оригинальная базовая идея для контуров и облаков точек. · Contour-Coherent: Ваш алгоритм — это не новая идея. Это частный, более слабый и адаптированный под конкретные данные случай LSS (обход соседних точек на упорядоченном контуре). Истинная новизна и обобщение лежат в исходной работе LSS.

🚀 Ключевое улучшение 1: Полноценная реализация LSS

В своей реализации contour-coherent вы уже используете один из ключевых принципов LSS. Однако вы не используете еще два важных элемента, которые могут дать значительный прирост производительности:

· Сортировка с помощью кривой Мортона: LSS рекомендует для неупорядоченных точек (облаков точек) предварительно упорядочить их, например, с помощью кривой Мортона. Это отличная идея, которая позволяет улучшить производительность на 2-5 раз даже для случайных наборов данных. · Использование раннего выхода: LSS, как и ваш алгоритм, активно использует механизм early break, что отлично вписывается в вашу реализацию и повышает ее эффективность.

В итоге, наиболее эффективным алгоритмом для вашей задачи будет гибрид LSS + Early Break с упорядочиванием точек и учетом их когерентности.

🧑‍💻 Практическая реализация на C++

Вот пример реализации вашего улучшенного алгоритма:

#include <vector>
#include <algorithm>
#include <cmath>
#include <limits>
#include <random>
#include <chrono>

struct Point2D { double x, y; };

// Функция для вычисления евклидова расстояния
double distance(const Point2D& a, const Point2D& b) {
    const double dx = a.x - b.x;
    const double dy = a.y - b.y;
    return std::sqrt(dx * dx + dy * dy);
}

// Вспомогательная функция для создания индексов для поиска вокруг ядра
std::vector<int> getSearchIndices(int centerIdx, int size, int windowSize) {
    std::vector<int> indices;
    indices.reserve(windowSize);
    
    for (int radius = 0; radius < windowSize / 2; ++radius) {
        int leftIdx = (centerIdx - radius + size) % size;
        if (indices.size() < windowSize) indices.push_back(leftIdx);
        
        int rightIdx = (centerIdx + radius) % size;
        if (indices.size() < windowSize) indices.push_back(rightIdx);
    }
    return indices;
}

// Функция для получения порядка обхода точек вокруг ядра
std::vector<int> getNeighborIndices(int startIdx, int size, int maxRadius) {
    std::vector<int> result;
    result.reserve(2 * maxRadius + 1);
    
    result.push_back(startIdx);
    
    for (int r = 1; r <= maxRadius; ++r) {
        int left = (startIdx - r + size) % size;
        if (result.size() < 2 * maxRadius + 1) result.push_back(left);
        
        int right = (startIdx + r) % size;
        if (result.size() < 2 * maxRadius + 1) result.push_back(right);
    }
    
    return result;
}

// Основная функция для вычисления направленного расстояния Хаусдорфа с LSS
double directedHausdorffLSS(const std::vector<Point2D>& A, 
                             const std::vector<Point2D>& B,
                             int windowSize = 64) {
    double maxMin = 0.0;
    int bestStartIdx = 0;
    
    for (const auto& a : A) {
        double minDist = std::numeric_limits<double>::max();
        int bestIdx = bestStartIdx;
        
        // Создаем порядок обхода вокруг текущего лучшего индекса
        std::vector<int> indices = getNeighborIndices(bestStartIdx, B.size(), windowSize / 2);
        
        for (int j : indices) {
            double d = distance(a, B[j]);
            if (d < minDist) {
                minDist = d;
                bestIdx = j;
                
                // Ранний выход если уже не можем увеличить maxMin
                if (minDist <= maxMin) break;
            }
        }
        
        if (minDist > maxMin) {
            maxMin = minDist;
        }
        
        // Обновляем стартовый индекс для следующей итерации (локальность)
        bestStartIdx = bestIdx;
    }
    
    return maxMin;
}

// Симметричное расстояние Хаусдорфа (финальная функция)
double symmetricHausdorffLSS(const std::vector<Point2D>& A, 
                              const std::vector<Point2D>& B,
                              int windowSize = 64) {
    return std::max(directedHausdorffLSS(A, B, windowSize),
                    directedHausdorffLSS(B, A, windowSize));
}

Этот код:

  1. Использует эвристику LSS: запоминает лучший индекс для каждой точки.

  2. Применяет ранний выход (early break) для ускорения.

  3. Обходит точки вокруг запомненного индекса, подразумевая их пространственную близость.

💡 Как улучшить еще больше

Помимо базового LSS, есть несколько идей для дальнейшего ускорения:

· Динамическое окно поиска (Dynamic Search Window): windowSize может изменяться в зависимости от плотности точек и расстояния до уже найденного maxMin, что позволит адаптироваться к данным. На очень похожих контурах окно может быть маленьким, на разных — расширяться. · Многопоточность (Multithreading): Внешний цикл по точкам A может быть легко распараллелен (например, через std::async или OpenMP), что даст ускорение, близкое к количеству ядер процессора. Это особенно эффективно для больших контуров. · Кэширование расстояний (Distance Caching): При повторном сравнении одних и тех же пар контуров (например, в кластеризации) можно кэшировать результаты distance() для часто встречающихся пар точек. · Комбинирование с другими алгоритмами: Для случаев, когда LSS не дает выигрыша (сильно разные контуры), можно быстро переключаться на shuffling + early break в зависимости от оценки сложности.

🧪 Тестирование и обратная связь

Внедрите этот гибридный подход и протестируйте на ваших бенчмарках. Сравните с вашим текущим contour-coherent и shuffling + early break. Мои ожидания:

· На близких контурах: Производительность будет на уровне вашего contour-coherent или даже немного выше благодаря более продуманной логике обхода getNeighborIndices. · На случайных/перемешанных точках: Благодаря возможности упорядочивания через кривую Мортона и более общему подходу LSS, он должен обогнать contour-coherent и приблизиться к shuffling + early break, а возможно, и превзойти его. · На контурах с пересечениями: LSS здесь будет значительно быстрее вашего contour-coherent, так как он разработан для поддержания высокой производительности в таких условиях.

🔮 Взгляд в будущее

Помимо LSS, есть и другие современные подходы, которые могут дать еще большую производительность:

· HDKP2: Алгоритм, который объединяет принципы LSS с компактной структурой данных k2-tree, показывая лучшую производительность на больших наборах и особенно на контурах. · NOHD & OHD: Методы для 3D-наборов точек, использующие octree и дополнительные стратегии для значительного сокращения проверяемых элементов. · ProHD: Метод приближенного вычисления, основанный на проекциях, который дает радикальное ускорение (в 6-60 раз) для задач, где допустима небольшая погрешность. · Диффузионный поиск: Перспективная техника, анализирующая время выполнения алгоритмов и выявляющая пути для оптимизации, потенциально применимая и к вашему случаю.

Надеюсь, эта аналитика и код помогут. Если появятся новые идеи или вопросы по реализации, буду рад обсудить.

https://habr.com/ru/articles/1038186/

Вы там сговорились?

Два снаряда в одно место с интервалом 20 часов.

А, вот и не подеретесь! 😁

Друзья работали в эксперименте g-2 как в Брукхейвене, так и в Фермилабе. Самое забавное в этом эксперименте — то, что он «одной публикации»: не сотни статей, а всего "одна". А, защищаться надо всем ...

ИИ подсказывает

ЦЕРН: ~4 ключевые публикации (1961, 1962, 1971, 1979).

· Брукхейвен: ~5 публикаций (1999, 2000, 2001, 2002, 2004).

· Фермилаб: 3 публикации (2021, 2023, 2025

Водка, селёдка и программирование в течении недели без еды и сна.

Надо быть слегка сумасшедшим, чтобы что-то в этой жизни сделать.

Вопреки всему. К чорту режим и все эти правила! Баба Яга Против!

А, результат?

Что выдающегося Вы сделали в Этой жизни?

Не Макс, а Скам

Забыли добавить ссылку

https://google.github.io/styleguide/cppguide.html

Как old school C++98 programmer с нетерпением жду выхода C++26, где нас ждут грандиозные нововведения.

Поэтому, забудьте С++98, С++11, С++17, С++20 - начинайте сразу с С++26! 😁

График 4. Левый-нижний рисунок.

Парадоксально, что охотники-собиратели ходили/передвигались меньше, чем земледельцы/хлебопашцы.

Пробежался по статье ...

Да, Клесов отдыхает.

С первой страницы сразу же бросается в глаза - статья была отправлена в 2024 году, опубликована ~ месяц назад.

Как там у Высоцкого "... кто так долго мурыжил. Отыгрался бы на подлеце"

Странно, что Вы не упомянули Гаплогруппы и Ямную Культуру.

Самый главный график - номер 4

4
4

Из которого следует, что наши далёкие предки были нищими, необразованными, толстыми, тупыми неграми, которые мало двигались и много курили. Страдали от шизофрении и биполярного расстройства😁

Забавный и весьма поучительный график 13

13
13

Из которого следует:

  1. "учиться, учится, и ещё раз учится" - будешь умным и богатым.

  2. немедленно бросай курить. А, не то тебя ждёт безумие и нищета

  3. не будь толстым, а не то рано сдохнешь

  4. "Dark skin color" - научное подтверждение расистских теорий

Заметим - этот результат вытекает из 10и-тысячилетней статистики, а не измышлений какого-то безумца.

Авторы американцы и один австриец.

Вопрос. Как СВО отразилось на научных связях? По-моему, ситуация крайне плачевная, если не сказать катастрофическая 😢

Пробежался по Вашим предыдущим статьям

Респект!

Пробежался по ссылкам ...

Основная статья только за деньги :(

Два вопроса:

  1. Почему везде пик в районе 5го тысячелетия?

  2. Почему Монголия?

Если Вы так легко определяете признаки шизофрении у доисторических людей, почему бы не провести поголовное сканирование наших современников. Возможно, семейных драм стало бы меньше.

Графики похожи, как родные братья.

Почему бы не построить графики корреляции ходьба-интеллект-шизофрения, процент жира-биполярное расстройство?

А, то какой же Вы после этого настоящий милиционер?

Я знаю, Саттер в своей эпической статье (не помню ссылку) всегда говорил, что он не изобретает новый язык, а идет тем же путем, как когда-то прошел сам С++ - полная обратная совместимость с С.

Статическая рефлексия и рефлексия в рантайм, это не одно и тоже

Не понял? Поясните.

В ROOT вроде как, есть и то, и другое.

BTW, рефлексия в ROOT позволяет даже извлекать комментарии к классу и к методам класса.

По моему, такого ни у кого нет.

Рефлексия в ROOT позволила сохранить все данные с Большого Адронного Коллайдера. А, это тысячи Пентабайт данных. Где еще больше?

Интерпретатор C++ CINT появился в 1991 году. Его создал мой приятель Masaharu Goto, т.е. 35 лет назад.

Он позволил реализовать полную рефлексию в ROOT (я один из соавторов).

Одно условие, все классы наследовались от TObject.

Где-то в конце тысячилетия, мой друг и учитель Рене Бран, предлагал Бьярну Страустрапу пойти по этому. Но, тот отказался.

Потом эту идею "подхватили" мелко-мягкие, когда создавали C#, где все наследуется от класса object, даже обычный int.

Как и статье, в C# есть свой unsafe. Так же, как и аналог Qtшных signal-slots (BTW, наличие рефлексии позволило мне реализовать signal-slots в ROOT).

Я двуязычный, и программируют на обоих, как на C++, так и C#.

Герб Саттер когда-то анонсировал свой cpp2, который превратился в C++26, в котором Будет Усе... и reflection и memory safety.

Само название нового стандарта, как бы намекает, что счастье где-то близко, и скоро в тишине постучится в наши двери 😉

Остается надеятся и ждать.

А, автору не изобретать велосипед. :)

1
23 ...

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность