Здесь источником информации является обучающая выборка. Для улучшения фильмов этого вполне достаточно. А для «уникальных» данных сеть додумает «как в кино». Для некоторых областей результат будет неприменим.
В коде ничего необычного нет. Он не сильно отличается от того, что содержится в примерах по OpenCV. Непосредственно по вычитанию фона можно посмотреть здесь, а по фильтрации здесь и здесь.
Ярко, потому что съёмка проведена камерой с очень высокой чувствительностью. Авторы статьи про Персеиды немного рассказывали про неё habr.com/post/374163.
Совпадение треков метеоров по длине скорее обусловлено длиной выдержки при съёмке. Ещё нужно учитывать, что съёмка произведена с объективом «рыбий глаз», и треки метеоров идут к своему центру вдоль некоторых кривых, особенно на краях изображения. Также мной выбран самый тривиальный алгоритм выделения треков, и он выделил ложный объекты. Особенно в правом верхнем и нижнем углах. Там, судя по видео, линия горизонта.
Метеоры пролетают на видео очень быстро. След в виде черты остаётся буквально на двух-трёх кадрах. Видеопоток пришлось ужать в два раза для борьбы с артефактами сжатия исходных файлов (самый простой способ, который пришёл в голову). Интересно попробовать обработать неускоренный и несжатый видеопоток.
Я смотрел видео после вычитания фона. Движущиеся объекты видны намного лучше. Видны даже метеоры, скорость которых намного выше. Просто они очень быстро мелькают т.к. видео ускоренно. И без вычитания фона глаз за них не цепляется.
Очень интересная подборка данных.
Удивило, что в ведущих IT компаниях такая низкая продолжительность работы сотрудников.
Уходят по завершению проекта, не справляются или не приживаются?
То, что разреженные матрицы не очень хорошо ложатся на современные архитектуры, никоим образом не умаляет их достоинств. Некоторые задачи и вовсе нельзя решить за разумное время, используя плотные матрицы, и задачи, аналогичные вашей, хорошее этому подтверждение.
Для ленточных матриц, безусловно доступ к памяти более оптимален, чем для разреженных матриц в более общих форматах CSR и COO.
Ленточные матрицы для себя я всегда выделял в некий отдельный класс в силу высокой плотности хранения.
Там есть команды simd умножения разряженных матриц.
Про такие команды не слышал, если можно, то поясните.
Умножение разряженных матриц, наверное, одна из самых сложных операций для компьютеров. Даже если взять более простую операцию — умножение разреженной матрицы на плотный вектор, то Xeon Phi далеко не достигает своей пиковой производительности (см. здесь). Для разреженного умножения матрицы на матрицу его использование вообще сомнительно.
Т.е. разряженные матрицы плохо ложатся на тензорные процессоры.
Разреженные матрицы в целом не очень хорошо ложатся на современные архитектуры из-за непоследовательного доступа к памяти (что на CPU, что на GPU). И к ним сложно применить SIMD инструкции. Поэтому положительный эффект достигается только при достаточно низкой 'плотности' матрицы.
Спасибо за статью!
Всегда считал, что перенормировка данных это первое, что нужно сделать.
Решал подобную задачу, и в данных было общее смещение ~10M. В даблах задача просто не решалась, и перенормировка показалась естественным шагом. Теперь попробую и этот метод.
Интересная статья.
А почему вторым кандидатом стал свой формат хранения данных Flatbuffers?
Тот же tiff умеет и чанкование, и сжатие, и пирамиды, и float, и кэшировать удобно. Мы в своих задачах (со сходными объёмами данных) его используем. Скорость работы ограниченна только системой хранения.
Дело скорее в отсутствии качественного исходника.
Очень похоже, что летят из правой нижней четверти кадра.
Привязал ваши кадры по звездам к «опорному небу», шарпиками помечены опорные звёзды.
Удивило, что в ведущих IT компаниях такая низкая продолжительность работы сотрудников.
Уходят по завершению проекта, не справляются или не приживаются?
Для ленточных матриц, безусловно доступ к памяти более оптимален, чем для разреженных матриц в более общих форматах CSR и COO.
Ленточные матрицы для себя я всегда выделял в некий отдельный класс в силу высокой плотности хранения.
Умножение разряженных матриц, наверное, одна из самых сложных операций для компьютеров. Даже если взять более простую операцию — умножение разреженной матрицы на плотный вектор, то Xeon Phi далеко не достигает своей пиковой производительности (см. здесь). Для разреженного умножения матрицы на матрицу его использование вообще сомнительно.
Разреженные матрицы в целом не очень хорошо ложатся на современные архитектуры из-за непоследовательного доступа к памяти (что на CPU, что на GPU). И к ним сложно применить SIMD инструкции. Поэтому положительный эффект достигается только при достаточно низкой 'плотности' матрицы.
Всегда считал, что перенормировка данных это первое, что нужно сделать.
Решал подобную задачу, и в данных было общее смещение ~10M. В даблах задача просто не решалась, и перенормировка показалась естественным шагом. Теперь попробую и этот метод.
А почему вторым кандидатом стал свой формат хранения данных Flatbuffers?
Тот же tiff умеет и чанкование, и сжатие, и пирамиды, и float, и кэшировать удобно. Мы в своих задачах (со сходными объёмами данных) его используем. Скорость работы ограниченна только системой хранения.
В opensource когда планируете выводить?